Automação com RPA: o robô fica pronto rápido; a exceção, não

A demonstração de RPA é sempre convincente. O robô abre o sistema, lê a planilha, copia o número do pedido, cola no campo certo, clica em salvar e passa para a próxima linha — sem cansar, sem errar, de madrugada. Rapidamente existe algo rodando na tela, e a conta de horas economizadas parece fechar sozinha.

O que a demonstração não mostra é o pedido que veio sem CNPJ, a tela que demorou dez segundos a mais para abrir, o pop-up de senha expirada e a atualização do sistema que mudou o botão de lugar. O robô fica pronto rápido. A exceção, não. Este artigo trata do orçamento honesto de um projeto de RPA: onde ele se paga, onde vira dívida e em que ponto a IA muda a conta.

O que é RPA na automação de processos?

RPA é a sigla de Robotic Process Automation, ou automação robótica de processos. Não há robô físico: é um software que opera outros softwares pela interface, do mesmo jeito que um funcionário faria — abrindo janelas, lendo campos, digitando, clicando e movendo arquivos.

A diferença para a automação tradicional está no ponto de contato. Uma integração conversa com o sistema por dentro, trocando dados de forma estruturada. O robô de RPA conversa pela tela, a mesma que o usuário vê. Por isso ele consegue automatizar sistemas que nunca foram feitos para conversar com ninguém.

Esse é o valor real do RPA e também o seu limite. Ele depende de que a tela continue igual, de que os dados cheguem no formato esperado e de que o caminho seja sempre o mesmo. Quando alguma dessas três condições falha, o robô para — ou, pior, continua trabalhando errado.

Como um robô de RPA funciona por dentro?

Todo robô de RPA é, no fundo, uma sequência de passos gravada ou programada sobre elementos da interface. Cada passo depende de encontrar alguma coisa na tela: um campo, um botão, uma coluna de tabela, uma janela com determinado título.

1. Gatilho: um horário, a chegada de um e-mail, um arquivo novo numa pasta ou o clique de alguém.
2. Leitura: o robô abre a origem (planilha, e-mail, PDF, sistema) e captura os dados.
3. Operação: navega até o sistema de destino, localiza os campos e preenche.
4. Conferência: verifica se a tela respondeu como esperado — a mensagem de sucesso, o número gerado.
5. Registro: anota o que fez, o que falhou e onde, para que alguém consiga auditar depois.

Os passos 1 a 3 são os que aparecem na demonstração. Os passos 4 e 5 são os que decidem se o robô pode rodar sozinho numa segunda-feira de fechamento. Um robô sem conferência e sem registro não é automação: é uma pessoa invisível que ninguém supervisiona.

Há dois modos de operação. No atendido, o robô roda na máquina do funcionário, a pedido dele, e alguém está olhando. No não atendido, roda sozinho num servidor ou máquina virtual, fora do expediente. O segundo é onde está o ganho de escala — e onde a falta de tratamento de exceção cobra mais caro, porque ninguém vê o erro na hora.

Qual a diferença entre RPA e integração por API?

Esta é a pergunta que mais economiza dinheiro num projeto de automação, e a que menos aparece nos conteúdos de quem vende plataforma de RPA.

Uma API é uma porta oficial que o sistema oferece para que outros programas leiam e gravem dados. Ela tem contrato: os campos têm nome, o formato é definido e, quando algo muda, o fornecedor costuma avisar e versionar. O robô de RPA não tem contrato nenhum com a tela. Se o fornecedor redesenha o formulário, ninguém tem obrigação de avisar o robô.

Comparativo organizado pela Alliance a partir da prática de projetos de automação

A ordem de preferência, portanto, é simples: se o sistema tem API ou conector pronto, integre por ali. O RPA entra quando não há outra porta. A própria Microsoft descreve assim o papel da ferramenta: com RPA, dá para automatizar o software herdado que não tem APIs. É um bom uso. Não é o uso padrão.

Na prática, muita empresa descobre que o problema não era de robô, e sim de dados partidos entre sistemas que não se integram. Resolver a integração elimina a digitação que o robô ia imitar.

Por que o robô fica pronto rápido e o projeto não?

Porque o caminho feliz é curto. Montar a sequência de cliques para um pedido que chega completo, num sistema que responde rápido, costuma ser a parte curta do trabalho. O que leva tempo é tudo o que acontece fora desse caminho.

O dado vale pelo lugar de onde vem. Não é um crítico de RPA falando: é um dos maiores fornecedores da tecnologia, na documentação que ensina a usá-la. O mesmo guia traz um diagrama, descrito com a observação de que o esforço para desenvolver um robô deve ser proporcional ao retorno que ele entrega.

O guia não dá percentual, e seria desonesto inventar um. Mas "a maior parte" já basta para mudar a pergunta do orçamento. A pergunta certa não é quanto custa montar o robô. É quanto custa deixá-lo confiável e mantê-lo assim.

Por que o robô de RPA para de funcionar?

Quase sempre por um destes motivos, e nenhum deles é defeito da ferramenta. São propriedades de quem trabalha pela tela.

1. A tela mudou

Uma atualização do sistema troca o nome de um campo, adiciona uma etapa ou move um botão. O robô procura o elemento onde ele estava e não encontra. Em sistemas na nuvem, que se atualizam sem pedir licença, isso acontece mais do que o fornecedor da automação costuma admitir na venda.

2. O tempo mudou

A tela que abria em dois segundos passou a abrir em doze no fim do mês. O robô tentou clicar antes de o campo existir. É para isso que servem as novas tentativas: esperar, tentar de novo, e só então desistir.

3. O dado não veio como o esperado

Pedido sem CNPJ, data em formato americano, valor com vírgula no lugar do ponto, anexo em imagem em vez de PDF. Cada variação é um caminho que alguém precisa decidir: corrigir, pular, separar para revisão humana ou parar tudo.

4. O ambiente mudou

Senha expirada, janela de aviso do sistema operacional, resolução de tela diferente na máquina virtual, certificado digital vencido. O robô não sabe o que é um pop-up inesperado — a não ser que alguém tenha previsto.

Ou seja: o comportamento padrão é parar. Tudo o que faz o robô aguentar a produção precisa ser desenhado, caso a caso. É exatamente o trabalho que não aparece na demonstração.

Quando o RPA se paga?

Quando quatro condições aparecem juntas. Faltando uma, a conta começa a piorar; faltando duas, o robô tende a virar dívida.

• Sistema sem outra porta: legado, fechado, sem API ou com API cara e restrita.
• Tela estável: o sistema muda pouco — versões raras, avisadas, ou ambiente controlado pela própria empresa.
• Regra fixa: a decisão cabe numa tabela; o caso fora da regra é raro e fácil de separar.
• Volume alto: centenas ou milhares de repetições, em que cada minuto economizado se multiplica.

Os casos clássicos seguem esse desenho: lançamentos repetitivos em ERP antigo, conciliação entre extrato e sistema interno, emissão de documentos em portais que não oferecem integração, cópia de dados entre dois sistemas que nunca vão conversar por outro meio.

Também vale considerar o RPA como ponte temporária: o robô cobre a lacuna enquanto a integração definitiva é construída, ou enquanto o sistema legado não é substituído. Nesse caso, ele precisa nascer com data para ser desligado — senão a ponte vira estrutura permanente.

Quando não vale a pena usar RPA?

O inverso das quatro condições. Cada uma das situações abaixo transforma o robô em trabalho recorrente de manutenção.

Critérios organizados pela Alliance

O item mais caro da lista é o processo mal definido. Automatizar um fluxo que cada pessoa faz de um jeito obriga o robô a escolher um desses jeitos — e as exceções dos outros viram erro. Antes do robô, vale a mesma pergunta que fazemos em qualquer projeto: o que realmente vale automatizar, e em que ordem.

Quanto custa implementar RPA?

Não existe preço de tabela honesto, porque o custo depende muito mais do processo do que da ferramenta. O que dá para fazer é mostrar do que ele é composto — e onde o orçamento costuma esconder a parte maior.

• Licença da plataforma: por robô, por usuário ou por execução, conforme o fornecedor. Robô não atendido costuma ter licenciamento próprio.
• Infraestrutura: a máquina, física ou virtual, onde o robô roda — com sessão, credenciais e acesso ao sistema de destino.
• Mapeamento do processo: levantar o caminho real, não o do manual, incluindo as variações.
• Construção do fluxo: o caminho feliz. É a parte visível e, pelo guia da Microsoft, a menor.
• Preparação para produção: novas tentativas, tratamento de exceções, registro, alertas e fila de revisão humana.
• Manutenção contínua: ajustar o robô a cada mudança de tela, de regra ou de ambiente, pelo tempo em que ele existir.

Uma proposta que detalha só os dois primeiros itens e a construção está orçando a demonstração, não o projeto. Peça que a manutenção apareça como linha própria, com quem faz e em quanto tempo responde quando o robô parar.

A conta de retorno também precisa ser feita do jeito certo: horas economizadas por mês, menos as horas de quem revisa as exceções, menos a manutenção. Num exemplo hipotético: se o robô economiza vinte horas e gera oito de revisão, o ganho é doze — e é esse número que precisa pagar a licença.

Qual a diferença entre RPA e agente de IA?

O robô de RPA segue regra: faz exatamente o que foi programado, do mesmo jeito, sempre. Um agente de IA interpreta: lê um e-mail em texto livre, entende o pedido, decide qual ferramenta usar. São capacidades diferentes, e a confusão entre as duas gera projetos caros.

A IA muda a conta do RPA em dois pontos. O primeiro é a entrada: documentos e mensagens sem formato fixo, que antes caíam todos na pilha de exceções, podem ser lidos e estruturados por um modelo antes de chegar ao robô. O segundo é a tela: a Microsoft já oferece, em versão preliminar, uma autorrecuperação que usa IA para tentar achar o elemento mais provável quando um campo mudou, restrita por enquanto a erros de elemento não encontrado em ações específicas.

O que a IA não faz é eliminar a exceção. Ela troca um tipo de erro por outro: o robô que parava passa a continuar com uma interpretação que pode estar errada. Por isso, onde há dinheiro, cadastro ou dado pessoal, a saída da IA precisa de conferência e de registro. O critério completo está no artigo sobre quando usar agente de IA ou fluxo automatizado.

Como avaliar um projeto de RPA antes de contratar?

Quatro perguntas separam um projeto sólido de uma demonstração bem feita. Faça todas antes de assinar.

1. O sistema de destino tem API ou conector?

Se tem, peça a justificativa por escrito para usar robô de tela. Pode haver motivo — custo da API, limite de acesso, prazo —, mas ele precisa ser dito.

2. Quais são as exceções mapeadas?

Uma boa proposta lista os casos que fogem da regra e diz o que o robô faz com cada um: corrige, pula, separa para humano ou para. Proposta sem essa lista não mediu o processo.

3. Como o robô avisa que falhou?

Registro, alerta, fila de pendências. Robô não atendido que falha em silêncio é o pior cenário: a empresa descobre dias depois, pelo cliente.

4. Quem mantém, e com que prazo?

A tela vai mudar. A pergunta é quem ajusta, em quanto tempo e a que custo. Se a resposta for vaga, o risco ficou com você.

Por onde começar

Comece pelo processo, não pela ferramenta. Liste as tarefas repetitivas da operação e, para cada uma, anote três coisas: se o sistema envolvido tem API, quantas vezes por mês a tarefa se repete e quantos casos fogem do padrão. Essa tabela simples já separa o que é integração, o que é robô e o que ainda precisa de redesenho.

Escolha um único processo com as quatro condições — sistema sem porta, tela estável, regra fixa, volume alto — e faça dele o piloto. Meça as horas economizadas e as horas de exceção por um mês inteiro, incluindo o fechamento. Só então amplie.

Se quiser ajuda para fazer esse mapeamento e decidir entre API, robô e IA, é o que fazemos no serviço de automação de processos da Alliance — do diagnóstico à ação, com a manutenção orçada desde o começo. E se a dúvida for onde a operação perde mais tempo hoje, o diagnóstico gratuito mapeia a maturidade por área, incluindo tecnologia e automação.