Blog
automatización de procesos y ROI (cuarta pasada: las variantes y el volumen que fijan el punto de equilibrio)

¿Cuántas variantes tiene el proceso que va a automatizar?

Marlon TrettinPublicado el 8 min de lectura
Gerente de espaldas en la terraza de vidrio de un edificio alto, de noche, mirando la ciudad abajo, donde tres avenidas anchas de luz ámbar concentran el tráfico y cientos de calles estrechas se ramifican en puntos turquesa

El retorno de una automatización depende de dos cuentas que suelen quedar fuera de la conversación sobre el alcance: cuántas veces va a correr el proceso y cuántas variantes tiene. Con muchas variantes y pocas ejecuciones de cada una, cubrirlas todas cuesta más de lo que ahorra. Automatice el núcleo frecuente y diseñe una ruta para la cola.

¿Por qué el retorno de la automatización depende de dos cuentas?

Porque la automatización tiene un costo de construcción y un ahorro en cada ejecución, y la cuenta solo cierra después de un número mínimo de ejecuciones. Brown y Hellerstein lo formalizan en el artículo de IBM. En su modelo, la automatización compensa cuando el número de ejecuciones a lo largo de la vida del proceso supera el costo adicional de construirla dividido por el ahorro por ejecución.

El artículo llama dificultad de generalización a la razón entre el costo de automatizar y el costo de una ejecución manual. Cada variante del proceso exige regla, prueba y manejo de errores propios. Esa lectura es nuestra, no del artículo: cuantas más variantes, mayor el costo de construcción, y menos ejecuciones recibe cada una para pagarlo.

¿Qué midió IBM al automatizar en la práctica?

Los autores parten de una frase que sirve de advertencia: la automatización no necesariamente reduce el costo de las operaciones. Dan tres motivos. Implantar y mantener la infraestructura de automatización da trabajo. Las entradas estructuradas exigen diseño y prueba de antemano. Y detectar y corregir errores es más difícil en un proceso automatizado que en uno manual.

Su caso es la distribución de software en centros de datos. De los paquetes construidos, el 25% se instaló en menos de 15 servidores a lo largo de su vida. De las solicitudes de instalación, el 19% terminó en fallo. Con costos que ellos mismos estimaron, el punto de equilibrio queda entre 5 y 20 servidores, de donde sale la conclusión de que entre el 15% y el 30% de las instalaciones no debería haberse automatizado.

Hay dos límites que declarar. El punto de equilibrio sale de rangos de costo estimados por los autores, no de un análisis completo de datos, así que vale como orden de magnitud. Y el contexto es la operación de TI en 2005, lejos de una pyme. Lo que se aprovecha es el método de cálculo, no los porcentajes.

¿Qué son las variantes de un proceso y por qué la cola es larga?

Variante es cada camino distinto que un caso recorre en el proceso. El pedido que sigue derecho, el que vuelve para corrección y el que pide una aprobación extra son tres variantes del mismo proceso.

Fischer, Hofmann, Imgrund, Janiesch y Winkelmann estudiaron cuatro registros de ejecución de procesos (atención de TI, solicitudes de préstamo en dos períodos y licencias de obra) de tres organizaciones neerlandesas, dos financieras y un organismo público. Dividieron las variantes en una cabeza, el 20% con la puntuación más alta en el conjunto de indicadores, y una cola, el resto. La cola respondió por cerca de dos tercios de los valores de los indicadores que calcularon, y sus variantes tenían menos contactos con el cliente, menos ejecuciones y más partes involucradas.

Los autores no concluyen que se deba ignorar la cola. Concluyen que hay que tratarla de otra manera: gestionar de forma central los procesos principales y mejorar el resto poco a poco, donde se ejecuta. La lectura para la automatización es nuestra. Una variante con pocas ejecuciones y muchas partes involucradas tiene poco volumen y un costo de construcción alto, la peor combinación para el punto de equilibrio. Los datos son de tres organizaciones neerlandesas, sin un recorte para pymes.

¿Qué queda para las personas después de automatizar?

Queda lo que el proyecto no cubrió, y suele ser lo más difícil. En 1983, Lisanne Bainbridge escribió en Automatica que la automatización puede ampliar en lugar de eliminar los problemas del operador humano. Según ella, el diseñador aún deja al operador las tareas que no supo cómo automatizar, y el operador termina con una colección arbitraria de tareas.

El texto trata del control de procesos industriales, y la aplicación es nuestra. En una operación de oficina, la cola que quedó fuera de la automatización se vuelve esa colección arbitraria cuando nadie diseñó la ruta: cada persona lo resuelve a su manera, en una planilla propia, y el caso no entra en ninguna cuenta.

¿Cómo contar variantes y volumen antes de aprobar el alcance?

Este es un procedimiento que proponemos, no un método de los estudios citados. Empiece por los casos reales, no por el diagrama de flujo del proceso. Tome tres meses de casos y agrúpelos por el camino recorrido. Cuente cuántos casos tuvo cada variante y cuántos minutos consume cada ejecución manual.

Luego, estime el costo de construir cada variante en horas y divídalo por las horas que ahorra al mes. El resultado es el período de recuperación en meses, variante por variante, y no un único número para el proceso. El cálculo del ROI de la automatización funciona mejor así, porque el promedio esconde la variante que nunca se paga.

Después, divídalas en tres grupos. El núcleo frecuente y estable se automatiza. El tramo intermedio depende de si la regla cambia. La cola recibe una ruta manual diseñada, con responsable y registro en el mismo sistema, para que cada caso siga contando. Medir la recuperación depende de ese registro, tema de medir el ROI de la automatización sin sistema de registro. Dónde queda la frontera entre manual y automático es asunto de cuándo conviven procesos manuales y automatización.

Decidir qué entra en la automatización es una decisión de arquitectura, no de herramienta. Contar las variantes es trabajo de quien conoce el proceso por dentro, y esa inteligencia, la natural, viene antes que cualquier máquina.

Un ejemplo práctico: los endosos en una correduría de seguros

El escenario es hipotético y los números son supuestos ilustrativos, no mediciones. Una correduría de seguros con 35 personas procesa 600 endosos al mes, y cada uno consume 12 minutos de trabajo manual. Al agrupar tres meses de casos, la correduría encuentra 1.800 endosos y 14 variantes.

Las tres mayores concentran 1.260 casos, el 70% del total. Las otras 11 se reparten 540 casos, con la mayor en 90 y la menor en 8. Suponga, por simplicidad, 40 horas para automatizar cada variante. Si las de la cola cuestan más, como sugiere el estudio de Fischer y colegas al señalar más partes involucradas, la recuperación empeora todavía más.

En las tres mayores son 420 casos al mes, o 84 horas ahorradas frente a 120 horas de construcción. La recuperación llega en alrededor de un mes y medio. Una variante de 90 casos en el trimestre tiene 30 al mes, ahorra 6 horas y se recupera en unos siete meses. La de 8 casos tiene menos de 3 al mes, ahorra unos 30 minutos y tarda 75 meses en recuperarse, más de seis años.

Las 11 variantes juntas costarían 440 horas para ahorrar 36 horas al mes, una recuperación media de unos 12 meses. El promedio parece aceptable y esconde la variante que nunca se paga. Vale todavía más si la regla de una variante cambia antes de que llegue la recuperación, porque la automatización pasa a costar mantenimiento sin devolver horas.

Este tipo de cuenta exige un registro estructurado del camino de cada caso. En el caso de Repap On, empresa en la que Yowpi tiene participación societaria, como informa el propio caso, la plataforma de gestión documental nació de una consultoría de procesos, y el mapeo del proceso es el punto de partida del sistema.

Preguntas frecuentes

No sé si la automatización tiene retorno financiero. ¿Cómo saberlo antes de contratar?

Estime, por variante, las ejecuciones al mes, los minutos de cada una y las horas para construir. Si no puede completar esos tres números, la etapa correcta sigue siendo medir. El artículo de IBM recuerda que la automatización no necesariamente reduce el costo, y la cuenta por variante muestra dónde sí lo hace.

Mi equipo está acostumbrado a las planillas. ¿La cola que queda manual sigue en la planilla?

No tiene por qué. Lo que queda manual debe tener una ruta diseñada y un registro en el mismo sistema que la parte automatizada. La planilla paralela es lo que vuelve invisible la cola, y una cola invisible no entra en la próxima decisión de alcance.

No tengo un equipo calificado para implementar. ¿Quién hace el relevamiento?

El relevamiento de casos y variantes es trabajo de quien opera el proceso, y una planilla alcanza. La construcción es la parte que exige ingeniería, y ahí entra un socio de ingeniería. La decisión sobre qué entra en el alcance sigue siendo suya, y la cuenta es lo que la respalda.

El siguiente paso

Si tiene un proceso candidato a la automatización y aún no sabe cuántas variantes tiene, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para mapear con usted dónde están las variantes y el volumen antes de cualquier decisión de alcance. Si tiene sentido para su caso, hable con Yowpi.

Cases relacionados

Marlon Trettin

Marlon Trettin

Fundador de Yowpi · 25+ años de ingeniería de software

LinkedIn
Próximo paso

¿Reconociste tu operación en este artículo?

Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.

Agendar diagnóstico