Process Discovery: entender el proceso antes de automatizarlo

Cuando un proyecto de automatización sale mal, rara vez el problema está en la tecnología. El robot funciona, el agente responde, el flujo corre. El problema es que automatizó algo que ya venía mal.

Digitalizar un proceso roto solo lo hace fallar más rápido. Es el principio que guía nuestra forma de trabajar desde hace más de 15 años automatizando operaciones en 7 países de LATAM: entendemos su proceso primero, automatizamos después.

Eso, en la práctica, es lo que llamamos Process Discovery.

Automatizar sin entender el proceso reproduce los errores a escala

Un proceso lleva años funcionando de una manera. El equipo conoce los atajos, los pasos que en papel deberían ocurrir pero en la práctica se saltan, y las excepciones que nadie documentó porque "siempre lo resolvió tal persona".

Cuando llega la automatización, el robot ejecuta lo que encuentra. Si el proceso tiene pasos redundantes, los repite. Si tiene excepciones sin dueño, las falla. Si tiene datos de mala calidad, los procesa igual y los errores salen en lote, no de a uno.

El síntoma más común no es un fallo técnico espectacular: es que el equipo termina haciendo más trabajo manual que antes, corrigiendo lo que el sistema automatizó incorrectamente. La automatización no liberó tiempo, lo redistribuyó en forma de correcciones.

La raíz del problema es siempre la misma: no se entendió el proceso real antes de tocarlo.

Qué hace exactamente un Process Discovery

Process Discovery es el trabajo de mapear y entender un proceso antes de diseñar cualquier solución. No parte del organigrama ni del manual de procedimientos: parte de cómo el equipo ejecuta el trabajo en la práctica.

Las fuentes de un Discovery bien hecho son tres:

Entrevistas con quienes ejecutan el proceso. Las personas que hacen el trabajo a diario conocen los pasos que no están en el manual, las validaciones que hacen "porque una vez salió mal", y los sistemas que en teoría no deberían usarse pero son indispensables. Esa información no aparece en ningún log.

Observación directa del proceso. Pedir que alguien describa cómo hace su trabajo y ver cómo lo hace son dos cosas distintas. La observación directa revela los micro-pasos, las esperas, el copiar y pegar entre sistemas y las decisiones que el equipo toma de forma tan automática que ya no las cuenta como trabajo.

Análisis de datos del proceso. Los logs de los sistemas (ERP, CRM, plataformas operativas) muestran tiempos reales, frecuencia de excepciones, volumen de correcciones manuales y cuellos de botella que no son visibles en las entrevistas. Es la capa cuantitativa que complementa lo cualitativo.

La salida de un Process Discovery no es un diagrama bonito: es un mapa del proceso real con sus excepciones identificadas, sus puntos de fricción medidos y una clasificación de qué conviene automatizar, qué conviene rediseñar primero y qué conviene dejar como está.

Cómo funciona el relevamiento paso a paso

Un Discovery estructurado sigue cuatro etapas que se superponen más que se suceden:

Mapeo del proceso as-is. El equipo de relevamiento trabaja junto al equipo operativo para documentar el proceso tal como ocurre hoy: cada paso, cada sistema involucrado, cada decisión, cada excepción conocida. El objetivo es representar la realidad, no el ideal.

Identificación de cuellos de botella y pérdidas. Con el mapa as-is en mano, se analiza dónde se acumula el tiempo, dónde ocurren los errores con mayor frecuencia y cuáles son sus causas. Algunos cuellos de botella vienen de pasos innecesarios; otros, de datos de mala calidad que llegan de un sistema upstream; otros, de excepciones que se resuelven a criterio de una persona sin estar documentadas.

Clasificación de oportunidades. No todo lo que se puede automatizar conviene automatizarlo. La clasificación evalúa cada oportunidad por volumen (cuántas veces ocurre), complejidad (cuántas excepciones tiene), impacto (cuánto tiempo o costo representa) y riesgo regulatorio. Esa matriz es la base para priorizar.

Diseño del proceso to-be. Antes de elegir la tecnología, se rediseña el proceso: se eliminan pasos redundantes, se definen los dueños de cada excepción y se establece cómo se va a medir el proceso automatizado. Solo con el to-be definido se elige la solución correcta (RPA, agente de IA, integración vía n8n, plataforma BPM).

Casos de uso: qué procesos se trabajan primero

No todos los procesos son candidatos igualmente urgentes. Los que más se benefician de un Discovery antes de automatizar son los que tienen alta variabilidad, muchas excepciones o impacto regulatorio.

Finanzas y tesorería. Conciliación bancaria, validación y aprobación de pagos, gestión de cobranza. Procesos con reglas claras en el manual pero con decenas de excepciones en la práctica (discrepancias de moneda, pagos parciales, devoluciones). Un Discovery bien hecho reduce las excepciones que llegan al automatizador y hace que la solución sea más robusta desde el día uno.

Crédito y apertura de cuentas. Evaluación de solicitudes, KYC digital, reestructuraciones. La regulación define los pasos, pero la operación real incluye validaciones informales, criterios no escritos y datos que llegan de fuentes distintas. Mapear eso antes de automatizar es la diferencia entre un proceso que cumple y uno que genera excepciones regulatorias.

Atención al cliente y PQRs. Los procesos de atención tienen la mayor variabilidad: cada cliente es un caso. Un Discovery clasifica los tipos de consulta por frecuencia y complejidad, y define cuáles pueden automatizarse completamente, cuáles requieren asistencia y cuáles deben quedar en manos del equipo.

Logística y compras. Recepción de mercadería, devoluciones a proveedor, validación de facturas. Procesos con muchos sistemas involucrados (WMS, ERP, proveedores externos) donde la integración es tan importante como la automatización en sí.

Para ver los procesos más frecuentes por área, puede revisar el detalle de nuestro servicio de Hiper-Automatización.

Cuándo conviene hacer Process Discovery y cuándo no

Process Discovery tiene un costo en tiempo y en esfuerzo del equipo. No siempre está justificado en la misma escala.

Conviene hacerlo cuando:

• El proceso tiene más de 20 pasos, involucra varios sistemas o tiene excepciones frecuentes.
• Hay presión regulatoria: el error en el proceso no es solo ineficiencia, es riesgo de cumplimiento.
• El proceso fue diseñado hace más de tres años y nunca se documentó formalmente.
• Proyectos anteriores de automatización en esa área no dieron los resultados esperados.
• El proceso involucra a varios equipos y nadie tiene la visión completa.

No es necesario en la misma profundidad cuando:

• El proceso es simple, bien documentado y ya tiene datos confiables.
• Se trata de una automatización puntual de una tarea repetitiva y sin excepciones (exportar un reporte y enviarlo por correo, por ejemplo).
• El equipo hizo un relevamiento reciente y está vigente.

La regla es proporcional al riesgo: cuanto más complejo, regulado o crítico es el proceso, más imprescindible es el Discovery.

La diferencia entre un Process Discovery bien hecho y uno de papel

Existe una versión light del Process Discovery: una reunión de dos horas con el gerente del área, un diagrama de flujo de alto nivel y una presentación. Cumple un requisito en el papel pero no sirve para automatizar nada.

El Discovery que protege una inversión en automatización tiene estas características:

Involucra a quienes ejecutan el proceso, no solo a quienes lo supervisan. Los gerentes describen cómo debería funcionar el proceso. Los analistas y operadores describen cómo funciona de verdad. Las excepciones reales viven en ese segundo nivel.

Cuantifica, no solo describe. Saber que "la conciliación tarda mucho" no alcanza para priorizar ni para medir resultados después. Cuantificar cuántas transacciones por día, cuántas con discrepancias, cuánto tiempo de corrección manual por caso, eso sí permite establecer una línea base y medir el impacto de la automatización.

Define lo que queda fuera. Un buen Discovery es tan claro sobre qué no se va a automatizar como sobre qué sí. Las excepciones que no tienen dueño claro o que requieren criterio humano se documentan y se dejan en manos del equipo, no se transfieren al robot.

Termina con un plan de acción, no con un informe. El entregable es la priorización de oportunidades y el diseño del proceso to-be, listo para pasar a la etapa de diseño de la solución. Sin ese plan, el Discovery es solo documentación.

Nuestro servicio de Process Discovery sigue exactamente esta metodología: mapeamos su proceso real, identificamos qué conviene automatizar y diseñamos el proceso to-be antes de tocar tecnología. Si está evaluando un proyecto de automatización y quiere saber si su proceso está listo para eso, hablemos 20 minutos sobre su operación.