Cómo calcular el ROI de la automatización: un marco práctico

El ROI de una automatización es el coste anual que elimina, menos el coste anual de mantenerla en marcha, dividido entre lo que costó construirla. Lo difícil no es la aritmética. Es que casi todos los casos de negocio que vemos sobrestiman el primer término, olvidan el segundo y tratan el tercero como una cifra única cuando no lo es. Si quieres una respuesta defendible, necesitas cuatro datos: una línea base con el coste manual totalmente cargado, una estimación honesta de la tasa de excepción tras automatizar, el coste de ejecución continuo y una declaración clara de qué forma adoptan realmente los ahorros.

Aquí va la versión resumida. Mide el proceso actual en coste laboral totalmente cargado, no en número de personas. Añade los costes que nunca aparecen en un parte de horas: retrabajo, corrección de errores, penalizaciones por tiempo de ciclo y el coste de las soluciones improvisadas que la gente ha montado alrededor del proceso. Después asume que la automatización no va a gestionar todos los casos y valora las excepciones restantes a la misma tarifa totalmente cargada. Resta el coste de ejecución. Si lo que queda no es claramente mayor que el coste de construcción en un horizonte de dos a tres años, la respuesta honesta suele ser que todavía no deberías automatizar esto. Nuestra calculadora de valor recorre los mismos datos si prefieres trabajar con una cifra en lugar de leer sobre ella.

Paso uno: establece bien la línea base del proceso manual

El error de línea base más habitual es usar el salario en lugar del coste totalmente cargado. Totalmente cargado significa salario más beneficios, cotizaciones sociales, herramientas y licencias, espacio de trabajo, gastos generales de gestión, y selección e incorporación amortizadas sobre la permanencia media. En puestos con rotación significativa, este último concepto no es un redondeo menor. Si tu línea base se basa solo en el salario base, subestimarás el coste real de cada hora que consume el proceso y harás que la automatización parezca sistemáticamente peor de lo que es.

El segundo error de línea base es medir solo el camino ideal. Pregunta a un equipo cuánto tarda una tarea y describirán la versión en la que todo sale bien. Esa versión suele no ser la costosa. Necesitas la distribución completa: cuánto tardan los casos limpios, con qué frecuencia los casos no son limpios y cuánto tardan esos. En la mayoría de los procesos con mucho documento y muchas excepciones, una minoría de casos consume la mayor parte del tiempo total.

Cosas que hay que contar y que los equipos suelen pasar por alto:

• Retrabajo. Trabajo que se hace, se detecta que está mal y se vuelve a hacer. Cuenta ambos pases más el tiempo dedicado a descubrir el error.
• Coste del error aguas abajo. Un valor mal introducido no cuesta la pulsación de tecla. Cuesta el abono al cliente, el pago duplicado que se recupera meses después, el hallazgo de auditoría, el contacto con soporte y, en algunas funciones, una consecuencia regulatoria.
• Penalizaciones por tiempo de ciclo. Los procesos lentos llevan un precio asociado: recargos por pago tardío, descuentos por pronto pago perdidos, ingresos reconocidos más tarde, clientes que se van mientras esperan, inventario que se queda parado.
• Sobrecarga de coordinación. Perseguir el estado, correos de traspaso, la reunión recurrente que existe solo porque el proceso es opaco, la hoja de cálculo que alguien mantiene para seguir lo que el sistema de registro no puede.
• Costes de cola y de picos. Si el volumen se dispara mensual, trimestral o estacionalmente, el proceso está dimensionado para el pico o falla en el pico. Ambas opciones son costosas.
• Tiempo de gestión y control de calidad. Supervisores que muestrean resultados, aprobadores que aprueban, responsables de equipo que desbloquean. Este tiempo se carga a una tarifa más alta que el tiempo de procesamiento que supervisa.

Obtén estos datos de la observación directa y de los sistemas, no de una encuesta. Las marcas de tiempo de los sistemas origen, el historial de tickets y unas horas observando el trabajo en marcha superarán siempre a las estimaciones autodeclaradas. Los informes autodeclarados comprimen las partes aburridas y olvidan las interrupciones.

Paso dos: modela el estado tras la automatización, no una fantasía

Ninguna automatización gestiona el cien por cien del volumen sin intervención humana, y los casos de negocio que asumen que sí son los que fallan. La cifra que decide tu ROI es la tasa de procesamiento directo: el porcentaje de casos que se completan sin intervención humana. Todo lo demás es una excepción, y las excepciones son más caras por caso que la línea base manual, porque ahora una persona tiene que hacerse cargo de un caso desconocido a mitad de proceso, entender qué hizo el sistema y terminarlo.

Modélalo en tres categorías. Los casos de procesamiento directo solo te cuestan cómputo y licencias. Los casos asistidos, en los que el sistema hace la mayor parte del trabajo y una persona confirma o corrige, cuestan una fracción del tiempo de gestión de la línea base. Las excepciones reales, en las que el sistema delega por completo, cuestan más que el caso base. Estima la mezcla y luego calcula tu ROI con una mezcla notablemente peor que tu estimación. Si el caso se sostiene incluso con una tasa de procesamiento directo pesimista, tienes un caso real. Si solo funciona con una tasa casi perfecta, tienes una esperanza.

Lo que determina la tasa de procesamiento directo no es, en su mayor parte, la tecnología. Es la variabilidad de las entradas, la calidad de los datos aguas arriba, cuántas excepciones de política genuinas ha aceptado tolerar el negocio y si las reglas de decisión están realmente escritas en algún sitio. Un proceso con entradas estructuradas limpias y reglas documentadas funcionará con una tasa de procesamiento directo mucho más alta que uno en el que la respuesta vive en la cabeza de una persona con experiencia. Por eso nuestro trabajo en inteligencia documental y de datos suele empezar con una muestra de documentos reales en lugar de con una especificación: la muestra te dice la variabilidad, y la variabilidad marca el techo.

Una cosa más que modelar: la tasa de excepción no es estática. Empieza alta y mejora a medida que encuentras y corriges los patrones, y luego se estabiliza. Un caso de negocio que asume el rendimiento del primer día durante todo el primer año es demasiado pesimista; uno que asume el rendimiento en régimen estable desde el lanzamiento es demasiado optimista. Modélalo como una rampa.

Paso tres: contabiliza el coste de ejecución con honestidad

La automatización no es una compra de capital que luego se queda ahí quieta. Es software en producción, y tiene un coste operativo. Los equipos que se saltan esta partida la descubren en el segundo año, normalmente en el mismo momento en que descubren que nadie es responsable de ella.

El coste de ejecución incluye:

• Infraestructura y consumo de modelo o de API, que escala con el volumen en lugar de mantenerse plano.
• Licencias de cualquier componente de plataforma, que a menudo escalan por bot, por usuario o por transacción.
• Monitorización y soporte: alguien tiene que darse cuenta cuando algo se rompe, de noche, en festivo, durante el cierre.
• Mantenimiento frente al cambio. Los sistemas de origen se actualizan, los proveedores cambian el diseño de sus formularios, un portal añade un paso de inicio de sesión, la normativa cambia. Cada punto de integración es una superficie que puede moverse.
• Capacidad de gestión de excepciones, dotada de personal y formada. Es un equipo real, aunque sea pequeño.
• Gobernanza: revisiones de acceso, evidencias de auditoría, control de cambios, validación periódica de que el sistema sigue haciendo lo que dijiste que hacía. Si tu proceso toca datos regulados o sensibles, lee cómo gestionamos la seguridad y el cumplimiento antes de dimensionar el proyecto, porque añadir controles después cuesta más que diseñarlos desde el principio.

Una regla práctica: si nadie puede nombrar a la persona responsable de la automatización doce meses después de su puesta en marcha, tu estimación del coste de ejecución está equivocada, y la automatización se degradará en silencio hasta que alguien vuelva al proceso manual. Presupuesta la propiedad del sistema de forma explícita.

Paso cuatro: sé preciso sobre qué tipo de ahorro estás reclamando

Aquí es donde la mayoría de los casos de negocio de automatización pasan de optimistas a ficticios. Las horas ahorradas no son dinero ahorrado. El dinero se ahorra cuando la organización deja de gastarlo, y eso solo ocurre de unas pocas formas.

La trampa es disfrazar la reasignación de capacidad de ahorro de plantilla. Automatizar veinte minutos al día repartidos entre cien personas no elimina ningún puesto; le da a cien personas veinte minutos más, que son reales pero no son dinero. Ese tipo de beneficio merece perseguirse, pero debe reclamarse como capacidad o calidad, no como una partida de coste, y no debe usarse para justificar un proyecto grande. La credibilidad de todo tu programa de automatización depende de que el primer caso entregue lo que prometió, en la moneda que prometió.

El tiempo concentrado es distinto del tiempo difuso. Si el trabajo recae en un equipo pequeño y dedicado, eliminar la mayor parte de él cambia la plantilla necesaria. Si el trabajo está repartido de forma dispersa entre una población grande, no la cambia. Dimensionamos los casos de forma distinta según esto, y es una de las primeras preguntas que hacemos en cómo trabajamos.

Cuando la respuesta es "todavía no automatices esto"

Esto se lo decimos a los clientes y lo decimos aquí también. Algunos procesos no deberían automatizarse en su estado actual, y lo responsable es arreglar antes otra cosa o directamente no seguir adelante.

• El proceso está a punto de cambiar. Si el sistema subyacente se va a sustituir, la política está en revisión o la unidad de negocio se va a reestructurar dentro del año, estarás construyendo contra un objetivo en movimiento.
• Nadie se pone de acuerdo en las reglas. Si tres personas con experiencia gestionan el mismo caso de tres formas distintas y las tres son defendibles, tienes un problema de política, no de automatización. Automatizarlo solo hace permanente e invisible el criterio de una sola persona.
• El volumen es demasiado bajo. Por debajo de cierto umbral, el coste de construcción y ejecución nunca se recuperará, por muy pesada que resulte la tarea. Pesado y costoso no son lo mismo.
• El coste real está aguas arriba. Si el trabajo existe porque un formulario está mal diseñado o un sistema no valida las entradas, arregla el origen. Automatizar la limpieza aguas abajo institucionaliza el defecto.
• Los ahorros no tienen a dónde ir. Si el tiempo liberado está disperso y ninguna partida de coste va a cambiar, sé honesto: esto es una inversión en calidad o experiencia, y finánciala como tal.
• Existen opciones más sencillas. Un cambio de configuración, un informe, una función del proveedor ya pagada, o eliminar un paso que nadie lee. Comprueba esto antes de construir nada.

Decir que no a los casos débiles es lo que da credibilidad a los fuertes. Los procesos que recompensan la automatización suelen compartir un perfil: volumen alto, decisiones repetibles, entradas estructuradas o semiestructuradas, un equipo concentrado que hace el trabajo y un coste medible de equivocarse. Ese es el perfil que buscamos en los proyectos de automatización inteligente de procesos, y es visible en los patrones de nuestros casos de éxito.

Cómo unir todo el modelo

Construye el cálculo sobre un horizonte de varios años, no de uno solo, porque el coste de construcción se concentra al principio y el beneficio va aumentando poco a poco. Para cada año: el beneficio es igual al coste manual base menos el coste residual de gestión de excepciones menos el coste de ejecución. El retorno de la inversión es el punto en el que el beneficio acumulado supera al coste acumulado. Después haz dos cosas que la mayoría de los casos de negocio se saltan. Primero, calcula un escenario pesimista con una tasa de procesamiento directo peor, una construcción más larga y un coste de ejecución mayor, y comprueba si aun así lo aprobarías. Segundo, anota las mediciones que tomarás después del lanzamiento —volumen, tasa de procesamiento directo, tiempo de gestión de excepciones, tasa de error, tiempo de ciclo— y comprométete a informar de ellas frente a la previsión. Un programa de automatización que se mide a sí mismo mejora su capacidad de previsión. Uno que no lo hace seguirá presentando el mismo caso optimista hasta que alguien deje de creérselo.

Por último, dimensiona por fases. Una primera fase acotada con un resultado real y medido te dice más sobre la verdadera tasa de procesamiento directo y el coste de ejecución del proceso completo que cualquier cantidad de estimación previa. Usa la primera fase para calibrar el modelo y después vuelve a prever el resto con datos que realmente tengas.

Si quieres una segunda opinión sobre un caso de negocio que ya has construido, o ayuda para establecer la línea base de un proceso antes de comprometerte con una cifra, habla con nosotros. Una conversación de alcance suele durar una hora y te dirá rápidamente si el caso es real. También puedes echar un vistazo al abanico de trabajos que realizamos en nuestros servicios.

Preguntas que nos hacen sobre esto