AS-IS vs TO-BE: la base de todo proyecto de automatización que nadie quiere hacer

Es el paso menos atractivo de cualquier proyecto de automatización y el que más veces marca la diferencia entre una solución que dura años y una que hay que rehacer en seis meses. Hablamos del mapeo AS-IS / TO-BE.

Qué es cada uno

El AS-IS es el proceso tal como funciona hoy, sin maquillaje: quién hace cada paso, en qué sistema, cuánto tarda, cada vez que se copia y pega, cada aprobación que en realidad nadie lee, cada excepción que alguien resuelve por WhatsApp. No es el proceso del manual, es el proceso real. Casi siempre aparecen dos o tres pasos que nadie de la gerencia sabía que existían.

El TO-BE es el proceso rediseñado, antes de automatizar nada. Se define qué pasos se eliminan porque no aportan valor, cuáles se combinan, cuáles se reordenan y cuáles quedan para automatizar. El TO-BE no es "lo mismo pero con un bot": es una versión más corta del proceso.

Por qué los equipos técnicos se lo saltan

Por dos razones muy humanas. La primera es que mapear se siente improductivo: no hay entregable visible, no hay demo, y frente a un cliente ansioso parece que no estamos avanzando. La segunda es que automatizar el proceso actual es técnicamente más fácil: no requiere negociar con nadie, no cuestiona decisiones de otras áreas y no obliga a conversaciones incómodas sobre por qué existe una aprobación que nadie usa.

El resultado es previsible. Vemos automatizaciones que replican con precisión quirúrgica pasos que no deberían existir: un flujo que genera una planilla intermedia porque el proceso manual la generaba, un bot que espera una aprobación que siempre se otorga, una integración que copia datos de un sistema a otro cuando en realidad podrían leerse una sola vez. El proceso queda más rápido, sí, pero también más rígido: ahora cambiarlo requiere tocar código, y sus problemas quedaron cristalizados.

Cómo hacerlo simple, sin parálisis de análisis

El riesgo opuesto es igual de real: equipos que pasan dos meses documentando y no automatizan nada. Nuestro criterio es acotado: un proceso por vez, una sesión de 90 minutos con quienes lo ejecutan de verdad, y un mapa que entre en una hoja. Si el diagrama no se entiende de un vistazo, está demasiado detallado.

Un ejemplo real y simplificado, un proceso de facturación de cinco pasos:

1) Ventas avisa por mail que se cerró un trato. 2) Administración carga los datos en una planilla de control. 3) Administración vuelve a cargar los mismos datos en el sistema de facturación. 4) El responsable del área aprueba la factura. 5) Alguien envía la factura al cliente y la archiva en una carpeta compartida.

Sobre ese mapa marcamos tres cosas. Se eliminan: el paso 2, porque la planilla de control duplica información que el sistema ya tiene y solo existe por costumbre. Se combinan: los pasos 1 y 3, porque si el CRM dispara la creación de la factura con los datos del trato, el aviso por mail y la carga manual son el mismo evento. Se automatizan: el paso 5 completo —envío al cliente y archivo— y la aprobación del paso 4 queda, pero con una regla: aprobación automática por debajo de cierto monto, y humana por encima.

El proceso pasó de cinco pasos manuales a un disparador, una excepción con criterio y dos acciones automáticas. Nótese que lo más valioso no lo hizo la tecnología: lo hizo la decisión de borrar un paso y fusionar otros dos.

El costo de saltearlo

Automatizar el AS-IS cuesta más de lo que parece. Cada paso innecesario es código que hay que escribir, probar, monitorear y mantener. Cada integración que sobra es un punto de falla adicional y una dependencia más de una API ajena. Y cuando el proceso cambia —siempre cambia—, hay que rehacer todo eso también.

En cambio, un TO-BE bien hecho suele reducir entre un 20% y un 40% de los pasos antes de escribir una línea. Esa reducción baja el costo de implementación, acorta el payback y hace que la solución sea más fácil de explicar a quien la va a usar.

Cómo lo aplicamos

En Linger AI este paso está incluido siempre antes de automatizar, en el Discovery Workshop y en cada proyecto de Análisis y Automatización de Procesos. No lo cobramos aparte ni lo tratamos como opcional, porque es la parte del trabajo que define si lo que construimos después tiene sentido. Nunca automatizamos un proceso que no mapeamos primero.