RPA na prática: os processos que saem da planilha primeiro

RPA, sigla para Robotic Process Automation, é software que executa tarefa repetitiva imitando a ação de um humano na interface: clicar, copiar, colar, preencher campo, mover dado entre sistema. A definição do Gartner é direta: "RPA é software que automatiza tarefas dentro de processos de negócio e de TI usando scripts que emulam a interação humana com a interface da aplicação" (Gartner, Robotic Process Automation Reviews).

O ponto que separa RPA de agente de IA, tema que já tratamos em Agente de IA: onde funciona de verdade e onde ainda não dá para confiar, é decisão. RPA segue regra fixa e não interpreta ambiguidade: quando o processo sai do script, o bot trava e precisa de humano ou de uma camada de IA por cima para resolver. A Automation Anywhere resume bem essa fronteira: "RPA é a camada de execução que opera dentro de frameworks de automação orientados por IA (...) são os braços e pernas da automação" (Automation Anywhere). RPA é ótimo em copiar dado de um sistema para outro. Não é ótimo em decidir se aquele dado faz sentido.

O tamanho do mercado, e por que ele desacelerou

O mercado global de RPA foi de US$2,6 bilhões em 2022 para US$3,6 bilhões em 2024, segundo o próprio Gartner, um crescimento de 14,5% no último ano medido, mais lento que os anos anteriores porque orçamento que iria para RPA puro está migrando para automação com IA generativa e agente (Gartner, Market Share Analysis: RPA, Worldwide). Isso não significa que RPA parou de fazer sentido. Significa que RPA virou a camada de execução dentro de uma automação mais ampla, não o projeto inteiro.

Do lado do retorno, a McKinsey estima ROI potencial de 30% a 200% já no primeiro ano de um projeto de RPA bem escopado (McKinsey, The next acronym you need to know about: RPA). A pesquisa global de automação inteligente da Deloitte, com 479 executivos em 35 países, mostrou 74% das organizações já implementando RPA, com prazo médio de payback subindo de 16 para 22 meses entre 2020 e 2022, atribuído a expectativa mais ambiciosa de escopo, não a piora de performance da tecnologia (Deloitte, Global Intelligent Automation Survey).

Onde RPA sai da planilha primeiro, por área

RH: onboarding, folha e cadastro multissistema

A Deloitte estima que mais de 50% dos processos padrão de RH são candidatos aplicáveis a RPA, numa pesquisa com mais de 100 líderes de shared services, na qual 74% planejavam investigar RPA no ano seguinte e 22% já tinham piloto ou implementação completa (Deloitte, Human Capital and RPA). Os candidatos mais comuns: onboarding e desligamento de funcionário, atualização de payroll, controle de ponto, e replicação de dado cadastral entre sistema de RH, folha e benefícios, processo que hoje costuma significar digitar a mesma informação três ou quatro vezes.

Atendimento e operações: triagem, status de pedido, extração de documento

A McKinsey documentou uma série de casos reais de automação de operação com RPA: redução de custo entre 30% e 60% em centro de operação que automatiza tarefa manual repetitiva, uma operadora de telecom que cortou 99% do tempo de ciclo de um processo de back-end implementado em 4 dias por 2 desenvolvedores, e outra telco que reduziu custo operacional de centro de rede em 55% (McKinsey, Operations management, reshaped by robotic automation). Os candidatos que mais aparecem nesse tipo de operação: triagem e roteamento de ticket de atendimento, atualização de status de pedido entre plataforma e sistema interno, extração de dado de nota fiscal ou documento recebido por e-mail, e cadastro do mesmo cliente em múltiplos sistemas.

Vale um exemplo de fornecedor para ilustrar o teto do que a tecnologia entrega: num case da UiPath com a integradora Accelirate, 93% das notas fiscais de um grande varejista passaram a ser processadas automaticamente, sem inspeção manual, com confiança de extração de 95% (UiPath, case study). É case de fornecedor sobre o próprio produto, não estatística de mercado independente, então vale tratar como exemplo de resultado possível, não como garantia.

Financeiro: já tratado em profundidade

Contas a pagar, fechamento e conciliação bancária já têm cobertura dedicada aqui no Journal, em Automação financeira: sair do Excel sem quebrar o que funciona e em Conciliação bancária automática. Se o gargalo da sua operação é nessa área especificamente, esses dois posts entram mais fundo do que cabe aqui.

Vendas e comercial: menos maduro, sem dado de mercado sólido ainda

Vale a honestidade: RPA em vendas e comercial (atualização de CRM, geração de proposta, qualificação inicial de lead) é uma área onde não encontramos estatística de adoção de fonte de peso, como Gartner ou McKinsey, especificamente dedicada a esse recorte. Os processos existem e fazem sentido como candidato, mas o volume de caso documentado publicamente ainda é pequeno comparado a RH, operação e financeiro. Trate como território em maturação, não como aposta validada por dado externo.

Por que projeto de RPA falha, com frequência real

Aqui está o número que qualquer projeto de RPA deveria conhecer antes de começar: a EY, numa análise que acompanhou implementação em 20 países, documentou que entre 30% e 50% dos projetos iniciais de RPA falham (citado por CMSWire e ComputerWeekly, com atribuição à EY). Não é uma estatística marginal. É quase metade dos projetos.

O motivo mais citado não é limitação técnica da ferramenta. Segundo análise da comunidade de peritos do Gartner, o padrão de falha se repete: seleção errada de caso de uso (automatizar um processo que muda com frequência, tornando o bot obsoleto rápido), promessa exagerada de fornecedor sobre o que a ferramenta resolve sozinha, e lacuna de habilidade interna para manter o bot depois que ele vai ao ar (Gartner Peer Community, Why many RPA projects fail). A própria McKinsey reforça: quando o projeto de automação robótica tem problema, a causa frequente é desalinhamento entre liderança de TI e liderança de negócio sobre o que o bot deveria resolver.

O padrão prático que evita isso: escolher processo de alto volume, regra estável (que não muda de mês a mês) e baixo julgamento antes de qualquer outro critério. Processo que muda de regra com frequência não é candidato bom a RPA, é candidato a ficar quebrando o bot toda vez que alguém ajusta uma política interna.

O que fazer com isso

Antes de contratar ou construir qualquer bot, vale mapear os processos da sua operação com três perguntas: o volume é alto o suficiente para justificar manutenção do bot? A regra é estável, ou muda com frequência? O julgamento envolvido é baixo, tipo copiar dado de um lugar para outro, ou envolve decisão que ainda precisa de humano? Processo que responde sim, sim e baixo julgamento é o que sai da planilha primeiro. O resto pode esperar, ou pode precisar de uma camada de IA por cima do RPA, não só do RPA sozinho.

Se você reconheceu um processo assim na sua operação, a conversa é de 30 minutos, sem pitch: você mostra o fluxo como ele roda hoje, a gente diz honestamente se RPA resolve, se precisa de IA por cima, ou se o problema nem é de automação ainda.

Fontes

Gartner, Robotic Process Automation Reviews; Automation Anywhere, What is RPA; Gartner, Market Share Analysis: RPA, Worldwide; McKinsey, The next acronym you need to know about: RPA; Deloitte, Global Intelligent Automation Survey; Deloitte, Human Capital and RPA; McKinsey, Operations management, reshaped by robotic automation; UiPath, case study de extração de nota fiscal; CMSWire, Why RPA Implementation Projects Fail (citando EY); Gartner Peer Community, Why many RPA projects fail.