Como calcular o ROI de um projeto de RPA (incluindo o custo que todo mundo esquece)

O business case de RPA costuma ser apresentado assim: o processo consome 40 horas por mês, o robô custa X para desenvolver, logo ele se paga em Y meses.

A conta está incompleta, e a parte que falta é justamente a que decide se o projeto se paga ou não.

A fórmula completa

Ganho anual = (horas mensais economizadas × 12 × custo-hora carregado) + ganho por redução de erro

Custo total no primeiro ano = desenvolvimento + licença anual + infraestrutura + manutenção anual + custo de gestão

ROI ano 1 = (ganho anual − custo total ano 1) ÷ custo total ano 1

Cada termo merece atenção.

Horas economizadas

Meça, não estime. A estimativa de quem executa o processo tende a ser otimista sobre o tempo gasto — a pessoa lembra do tempo de execução, não das interrupções, das correções e das conferências.

E desconte a parcela que continua manual: exceções que o robô não trata, e o tempo de conferência do que ele fez.

Custo-hora carregado

Não é o salário dividido por 176. É o custo total do profissional para a empresa — salário, encargos, benefícios e provisões — dividido pelas horas efetivamente trabalhadas no ano, já descontando férias e feriados.

Usar o salário nominal subestima o ganho de forma significativa. Usar um custo inflado para fazer o business case fechar é pior: destrói a credibilidade do programa de automação inteiro na primeira revisão.

Redução de erro

Mais difícil de medir, frequentemente maior que a economia de horas. Se o processo manual gera retrabalho, multa, pagamento em duplicidade ou nota fiscal rejeitada, essa é a economia relevante.

Levante o histórico real de incidentes antes de estimar. Um número plausível e defensável vale mais que um número grande e questionável.

Manutenção anual — o termo esquecido

Todo robô consome horas ao longo do ano: ajuste por mudança de tela, tratamento de exceção nova, correção de falha, adaptação a mudança de regra de negócio.

Robôs simples, sobre sistemas estáveis, consomem pouco. Robôs que navegam por muitas telas, atravessam vários sistemas ou dependem de portais externos consomem consideravelmente mais.

Este é o termo que decide o business case. Um robô com desenvolvimento barato e manutenção alta pode ter retorno negativo já no segundo ano — e a maioria das planilhas de ROI simplesmente não tem essa linha.

Custo de gestão

Alguém precisa monitorar execução, tratar falha, medir resultado e priorizar a fila. Em um programa com poucos robôs isso se dilui; a partir de certa escala, vira função.

Exemplo numérico

Um processo de conciliação executado diariamente:

Ano 1: ganho de R$ 37.700 contra custo de R$ 49.000 — retorno negativo. Ano 2: ganho de R$ 37.700 contra custo de R$ 21.000 — retorno positivo de 79%. Acumulado em 2 anos: positivo em R$ 5.400.

A leitura correta: este robô não se paga no primeiro ano, e isso está bem. O erro seria apresentá-lo como retorno imediato e perder credibilidade quando o número real aparecer.

Note também o peso da licença. Em programas com um único robô, ela costuma ser o maior custo recorrente — o que reforça a lógica de construir uma fila de processos antes de investir em plataforma.

Os três erros mais comuns

1. Esquecer a manutenção. Já tratado, e é o principal.

2. Contar economia de headcount que não vai acontecer. Se ninguém vai ser desligado, não existe economia de folha — existe capacidade liberada. Isso é valioso, mas é um argumento diferente, e apresentá-lo como economia de custo produz um business case que não se confirma no orçamento.

3. Ignorar o custo de oportunidade do time de TI. As horas gastas construindo o robô sairiam de onde?

Um critério simples

Se o payback estimado passa de 18 meses, provavelmente vale mais investigar por que o processo é assim antes de automatizá-lo. Processos com payback longo costumam ser processos que deveriam ser simplificados ou eliminados — não acelerados.