Saltar al contenido
Pynbot Vision: la operación completa en una sola vista.

Metodología

Cómo elegir qué automatizar primero

Los criterios que usamos para priorizar candidatos: volumen, estabilidad, número de sistemas, excepciones y consecuencia del error.

Lectura
8 min
Tipo
Metodología

La primera automatización de una empresa importa más que las siguientes, porque define si habrá siguientes. Elegir mal —un proceso vistoso pero inestable, o crítico pero mal entendido— cuesta el presupuesto y la credibilidad al mismo tiempo.

Cinco criterios, en este orden

  • Volumen y frecuencia

    Qué buscamos
    Muchos casos, con cadencia predecible: diario, semanal, por corte.
    Señal de alerta
    Menos de 20 casos al mes o frecuencia impredecible.
  • Estabilidad de la regla

    Qué buscamos
    El criterio de decisión no cambió en el último año.
    Señal de alerta
    La regla se negocia caso por caso.
  • Estabilidad de la interfaz

    Qué buscamos
    Los sistemas involucrados no cambian de pantalla cada mes.
    Señal de alerta
    Aplicación en migración o rediseño activo.
  • Excepciones acotadas

    Qué buscamos
    El 80% de los casos sigue el mismo camino.
    Señal de alerta
    Cada caso es una excepción distinta.
  • Consecuencia del error

    Qué buscamos
    Un error se detecta y se corrige sin daño irreversible.
    Señal de alerta
    Un error implica pago indebido o incumplimiento regulatorio sin revisión posterior.

Mide el proceso antes de automatizarlo

Sin línea base no hay resultado que reportar. Antes de construir, conviene tener tres números: cuántos casos se procesan al mes, cuántos minutos toma cada caso y cuántas personas participan. Con eso se calcula el tiempo total invertido hoy, que es la única referencia honesta para medir el después.

Ese cálculo también sirve de filtro. Un proceso de 15 minutos por caso y 400 casos al mes son 100 horas mensuales. Uno de 15 minutos y 12 casos al mes son 3 horas. El segundo puede ser molesto, pero no es donde conviene empezar.

Habla con quien lo ejecuta

El proceso documentado y el proceso real casi nunca coinciden. Quien lo ejecuta todos los días conoce los atajos, los casos que se resuelven por WhatsApp y el paso que oficialmente no existe pero sin el cual nada funciona. Ese detalle es exactamente lo que rompe una automatización construida a partir del diagrama.

Define qué queda fuera

Un alcance sano incluye explícitamente lo que el robot no va a hacer. El caso con firma del director, el proveedor con condiciones especiales, el mes con cierre atípico: identificarlos y enrutarlos a revisión humana es parte del diseño, no una falla.

Un buen primer proceso es aburrido, medible y de alguien que quiere que funcione.

Y el patrocinador

El criterio menos técnico es el más determinante: que el área dueña del proceso quiera automatizarlo. Un proceso técnicamente ideal en un área que no participa termina en un robot que nadie usa. Uno moderadamente bueno con un dueño involucrado termina en producción.

Seguir leyendo

Las otras guías.

  • Guía

    Qué es RPA (y qué no es)

    Robotic Process Automation en términos operativos: qué hace un robot de software, en qué se diferencia de una integración y cuándo no es la respuesta.

  • Referencia

    Glosario de automatización

    Bot, agente, runner, orquestador, cola, excepción, proceso atendido. Los términos que aparecen en cualquier conversación de RPA.

De la teoría a tu proceso.

La conversación útil empieza cuando ponemos un proceso concreto sobre la mesa.