Por Danilo Toro, Fundador de Robotipy
Cómo priorizar qué procesos automatizar primero
Cómo priorizar qué procesos automatizar cuando hay diez candidatos y presupuesto para dos: inventario, puntaje de cinco preguntas y orden de los proyectos.
Una empresa que ya decidió automatizar rara vez tiene pocos candidatos. Lo normal es que aparezcan doce procesos, casi todos automatizables, cada uno defendido por su jefe de área, y un presupuesto que este año da para dos o tres. Hay que decidir en qué orden hacerlos y cuáles no hacer nunca.
Esa decisión suele tomarse en una reunión, y la gana el gerente que más insiste o el proceso que más problemas dio el mes pasado. Es comprensible, pero sale caro, porque el orden de los proyectos influye más en el retorno del programa que la calidad de cada robot.
El inventario de procesos
Antes de puntuar hay que saber qué procesos existen. La base de cualquier assessment de automatización es una tabla de procesos reales con cuatro datos por fila: quién lo hace, con qué frecuencia se ejecuta, cuántas horas consume a la semana y qué sistemas toca. Un proceso al que le falta alguno de esos datos todavía es una intuición, y queda fuera de la evaluación hasta completarlo.
El inventario lo arma la empresa, entrevistando a quienes ejecutan cada tarea. Si se le pregunta al gerente, lo más probable es que estime menos tiempo del real. Esa diferencia aparece en casi todos los inventarios y suele ir en la misma dirección, porque nadie contabiliza los reprocesos.
Impacto, complejidad y reutilización
Con el inventario listo, cada proceso se puntúa por impacto (horas liberadas al año, errores evitados, riesgo reducido) y por complejidad. La complejidad crece con el número de sistemas y de excepciones, y también cuando la interfaz cambia con frecuencia. Arriba de la lista quedan los de alto impacto y baja complejidad. Los del cuadrante opuesto se descartan aunque su área presione.
Esa es la matriz de priorización clásica de RPA, la que aparece en cualquier presentación del tema. Le falta la reutilización, que en la práctica es el criterio que más pesa en el orden. Si un proceso usa el mismo login a SAP, lee el mismo Excel de entrada y escribe los resultados igual que otros cuatro de la lista, su puntaje de impacto lo subestima, porque lo que se construye ahí queda hecho para los siguientes. Con las seis semanas de ese proyecto se paga un robot más la mitad de la biblioteca que usará el resto del programa.
En los proyectos que hacemos con Rocketbot, la conexión a SAP, las rutas y el manejo de credenciales viven en subrobots de inicialización separados. El segundo robot que necesita SAP los llama en vez de construirlos de nuevo. Por eso, si en una evaluación quedan tres candidatos empatados y uno comparte sistema con la mitad de la lista, conviene hacerlo primero aunque su ROI individual sea el más bajo de los tres, porque así el programa completo termina antes.
Un puntaje de cinco preguntas
Para puntuar basta con asignar un valor de 1 a 5 a cada una de estas preguntas y sumar los resultados. Una fórmula ponderada de nueve variables sería trabajo de más.
- ¿Cuántas horas a la semana consume hoy?
- ¿Se hace siempre de la misma forma o depende del criterio de quien lo ejecuta?
- ¿Cuántos sistemas distintos toca? ¿Alguno tiene API disponible?
- ¿Cuántas excepciones reales tiene? Cuenta las que ocurrieron este mes y deja fuera las teóricas.
- ¿Qué tan estable fue durante el último año y hay algún cambio planificado?
La quinta pregunta elimina candidatos que en la hoja de cálculo se ven perfectos. Si el sistema de origen de un proceso se migra en seis meses, ponerlo primero es perder dinero, por mucho impacto y poca complejidad que tenga. Antes de priorizar, pregunta por el roadmap de TI. Un proveedor apurado por cerrar la venta puede no hacer esa pregunta, porque la respuesta podría costarle el proyecto.
Procesos que hay que eliminar en vez de automatizar
En casi todas las listas de diez candidatos aparecen uno o dos procesos que sobran. Suelen ser cosas como un reporte semanal que nadie abre desde hace un año, una doble carga que existe porque dos áreas no se han puesto de acuerdo en cuál es el sistema oficial, o una conciliación manual que nació cuando alguien desactivó una integración en 2023.
Automatizarlos funciona y el ROI cierra en la hoja de cálculo, pero el presupuesto se gastó en conservar un problema que se podía resolver. Un buen assessment marca esos casos aunque eso reduzca el proyecto que el mismo proveedor está cotizando. Para detectarlos, pregunta por qué existe cada proceso. Si la respuesta empieza con "porque en su momento...", revísalo con más cuidado antes de puntuarlo. Los criterios para descartar este tipo de candidatos están en el artículo sobre cuándo no conviene automatizar un proceso.
Cómo ordenar la secuencia de proyectos
Con los puntajes listos falta el calendario, y el proceso con mejor puntaje no siempre es el que debe ir primero.
Supón que el candidato número uno depende de un dato que hoy carga a mano el área menos dispuesta a colaborar, y que el número tres no depende de nadie. Es mejor empezar por el tres aunque tenga menos puntaje, porque llega antes a producción. Ese robot en operación es evidencia interna que la hoja de cálculo no registra, y para las áreas que todavía dudan pesa más que cualquier presentación de ROI proyectado.
El orden que recomendamos:
- Un proceso corto que el equipo pueda terminar sin depender de otras áreas y cuyo resultado se note en la empresa, para generar confianza desde el primer robot.
- El de mayor reutilización, que abarata los siguientes.
- El proyecto grande, el que toca cuatro áreas y exige que todos colaboren, cuando los dos anteriores ya están en producción y nadie discute si la automatización sirve.
Revisión del inventario cada seis meses
La priorización se revisa porque los procesos cambian, aparecen candidatos nuevos y algunos descartados se vuelven viables cuando la biblioteca del programa ya creció.
Revisa el inventario cada dos trimestres con los datos reales de los robots que ya operan: cuánto tardó cada uno en construirse frente a lo estimado y cuánto mantenimiento ha consumido. El dato de mantenimiento es el que más corrige el modelo, así que hay que registrarlo robot por robot. Si un tipo de proceso resultó el doble de caro de mantener de lo previsto, debería bajar en la lista.
Si tu programa está en su etapa inicial y todavía no tienes estos números, revisa primero cómo empezar un proyecto de automatización. Los tropiezos que más hemos visto en esa etapa están reunidos en errores comunes al implementar RPA.
