Cómo armar el business case para automatizar (y convencer a la dirección)

El gerente de operaciones ya mostró la diapositiva del ROI, las horas que se liberan y el proceso que hoy hacen tres personas a mano. Cerca del minuto doce, alguien de finanzas que no había dicho nada pregunta algo como: "¿En cuánto tiempo se paga solo, contando lo que va a costar mantenerlo el próximo año?".

Si la respuesta es un silencio o un "lo vemos después", el proyecto no se cae en ese momento, pero pierde el impulso que traía. La mayoría de los business case que no se aprueban traen el ROI bien calculado y caen igual, porque nadie preparó la respuesta a esa pregunta. Hemos estado en esa reunión muchas veces y las objeciones se repiten, así que se pueden anticipar al armar el caso.

El caso lo presenta el dueño del proceso

Cuando el business case lo arma o lo presenta el área de sistemas, la reunión empieza en desventaja aunque los números estén bien. La dirección escucha "tecnología" y lo clasifica como gasto de infraestructura.

La conversación cambia cuando lo presenta el gerente cuyo equipo pierde horas en esa tarea. Con él, el proyecto se discute como una decisión de negocio. Ese gerente habla de las horas de trabajo y del dinero que hoy se van en un proceso manual, y lo que pide es recuperar tiempo de su gente para dedicarlo a otra cosa.

Como vimos en cómo priorizar qué procesos automatizar primero, el inventario de candidatos lo levanta la empresa. El business case también lo defiende quien vive el proceso, y el proveedor respalda técnicamente los números.

La cuenta del proceso manual

Antes de la reunión, ten armada la cuenta de lo que cuesta hoy el proceso manual. La fórmula es sencilla:

horas semanales que dedica el equipo × costo de esa hora × 52, más una estimación de lo que cuestan los errores.

La calculadora de ROI hace esa misma cuenta con los datos reales de tu empresa, sin que tengas que pedir nada por escrito.

Los errores casi nunca entran en esa cuenta. Piensa en la factura pagada dos veces, el descuento mal aplicado o el reporte que llegó tarde y le costó una decisión a otra área. Ese costo no aparece en ningún reporte, porque el error se corrige a mano. Es más difícil de estimar que las horas y suele ser una parte importante del argumento, así que inclúyelo aunque la cifra sea aproximada.

Un ejemplo ilustrativo (no corresponde a un caso real): un proceso que ocupa diez horas semanales entre dos personas, con un costo por hora cargado de USD 15, suma unos USD 7.800 al año solo en tiempo. La inversión mínima ronda los USD 6.000, según el desglose de cuánto cuesta automatizar un proceso. Con esas cifras, las cuentas ya cierran con el ahorro de tiempo, sin contar todavía los errores evitados.

El mantenimiento después del primer año

Una vez aceptado el precio del desarrollo, la objeción que frena la aprobación es qué pasa después del primer año: quién mantiene el robot y qué ocurre si el sistema con el que trabaja cambia de versión. Es una objeción legítima. Un robot sin mantenimiento termina fallando, y si nadie lo nota a tiempo, el daño puede superar el beneficio.

El soporte mensual es opcional y no viene escondido en el precio inicial. Cuesta desde USD 300 al mes si se contrata, y hay clientes que prefieren operar el robot con su propio equipo.

Dilo también en la misma reunión: cualquier automatización necesita a una persona interna que revise que el robot se ejecutó y sepa a quién avisar si algo falla. El rol no exige conocimientos técnicos ni sale caro. Cuando no se nombra antes de firmar, se improvisa la primera vez que el robot se cae.

Quién tiene que estar en la sala

Con el gerente del área y el proveedor no basta. Faltan dos personas que cambian el resultado de la reunión.

Pide que alguien de finanzas, el área que controla el presupuesto, revise los números antes de la reunión de aprobación. Si el cálculo llega a la sala sin esa revisión, cualquier duda se discute en vivo frente a quien tiene que decidir, y esa discusión le juega en contra al proyecto.

Invita también a la persona que hace hoy el trabajo a mano, aunque su jefe ya esté en la sala. Ella conoce las excepciones reales del proceso, las que no figuran en ningún documento. Aunque solo asista diez minutos, su presencia le da credibilidad al proyecto, en especial si confirma frente a la dirección que el robot resuelve lo que hoy le complica el día.

Empezar por un piloto

El error más caro en los business case ambiciosos es pedir aprobación para un programa de diez robots antes de tener uno funcionando. La dirección tendría que confiar en una promesa sobre diez procesos sin haber visto operar ni siquiera el primero. Es mucho pedir para una sola reunión, y lo habitual es que termine en un "lo evaluamos el próximo trimestre", que equivale a un no.

Funciona mejor al revés: pide aprobación para un proceso acotado y visible, con retorno claro en pocos meses, y deja el resto del programa para una segunda reunión, cuando ya haya un robot en producción que cualquiera pueda ir a ver. Por qué conviene ese orden lo explicamos en el artículo sobre cómo pasar de un robot a un Centro de Excelencia de automatización.

Qué no prometer en la reunión

Cuando la aprobación se está haciendo difícil, aparece la tentación de prometer de más: cero errores, retorno en un mes, nada de mantenimiento. Ninguna de esas promesas se cumple, y prometerlas es uno de los errores comunes al implementar RPA. Cualquier robot que depende de la interfaz de un tercero puede fallar cuando esa interfaz cambia, y ese día la dirección va a recordar lo que se le prometió.

Comprométete con un número conservador que el robot pueda superar. La primera revisión trimestral va a medir el proyecto contra esa cifra.

Cuándo todavía no conviene armar el business case

El business case parte de las horas que consume el proceso. Si el área todavía está ajustando cómo lo hace y el proceso cambia de forma cada dos o tres semanas, esas horas no se mantienen y no hay una cifra estable que medir. Cualquier número que calcules hoy quedará desactualizado antes de la próxima reunión de directorio.

En ese caso, espera a que el proceso se estabilice antes de armar el caso. Esa etapa la tratamos en cómo empezar un proyecto de automatización.

Preguntas frecuentes