RPA é a sigla de automação robótica de processos, e o nome engana: não há robô nenhum. É um programa que opera outros programas como uma pessoa operaria, clicando em telas, preenchendo campos e copiando valores entre sistemas que não conversam entre si.
Essa característica é a força e a armadilha do RPA ao mesmo tempo. Ele resolve em semanas o que uma integração levaria meses, sem tocar nos sistemas envolvidos, e por isso vira a resposta padrão para qualquer processo manual. Este texto mostra onde ele é a escolha certa, onde é remendo caro, e como decidir entre automatizar com robô, integrar de verdade ou reescrever o processo.
O que RPA faz, e o que ele não é
Um robô de RPA repete uma sequência de passos na interface dos sistemas: abre a tela, lê um campo, digita em outro, salva, avança. Ele não entende o processo, apenas reproduz a sequência que alguém gravou ou programou. É automação por imitação, e é isso que a torna rápida de montar.
Onde ele se encaixa entre as demais opções está em automação de processos empresariais: o robô é o quinto caminho, o que resolve quando nenhum dos outros quatro alcança.
Duas confusões atrapalham a decisão. RPA não é inteligência artificial: o robô não decide nada que não esteja escrito na regra, e não lida com o caso que ninguém previu. E RPA não é integração: a integração faz dois sistemas trocarem dados pela porta dos fundos, enquanto o robô entra pela porta da frente, como usuário. A diferença entre os modelos de integração está em integração de sistemas.
Onde o robô é a escolha certa
Existem quatro situações em que RPA é a resposta certa, e não um atalho.
- Sistema fechado, sem API. Software de terceiro que não expõe nada e não vai mudar. O robô é a única porta.
- Processo estável e de alto volume. A mesma sequência, muitas vezes por dia, sem variação.
- Ponte temporária. Enquanto a substituição de um sistema acontece, o robô segura a operação por alguns meses.
- Regra clara e sem julgamento. Toda decisão do fluxo cabe em condições objetivas.
A primeira é a mais legítima de todas. Quando o sistema do outro lado é intocável, seja por contrato, seja por ser um sistema antigo que ninguém mexe, o robô resolve o que nenhuma outra abordagem alcança. O contexto dessa restrição costuma ser o de sistemas legados.
Onde ele vira remendo caro
O robô quebra por um motivo estrutural: ele depende da tela. Qualquer mudança de layout, um campo que mudou de lugar, uma atualização do fornecedor, uma janela de aviso nova, e a automação para. Não com erro claro: para no meio, deixando metade do lote processado.
| Situação | Por que o robô é a escolha errada |
|---|---|
| Os dois sistemas têm API | A integração custa mais para construir e muito menos para manter |
| O processo muda com frequência | Cada mudança de tela exige refazer a automação |
| O fluxo tem julgamento humano | Exceção sem regra objetiva vira fila de erro, não automação |
| O processo em si está errado | Automatizar o desnecessário é fazer mais rápido o que não deveria ser feito |
| O volume é baixo | O custo de montar e manter supera as horas economizadas |
A quarta linha é a que mais custa dinheiro. Muito processo manual existe porque o sistema é ruim ou porque a etapa nunca foi questionada. Colocar um robô ali congela o processo errado e o torna mais difícil de eliminar depois, porque agora existe um investimento a defender. A pergunta anterior à automação está em quais processos automatizar numa empresa de serviços.
Vale separar dois números antes de aprovar qualquer projeto de RPA: quantas horas por mês o processo consome hoje e com que frequência a tela dos sistemas envolvidos mudou nos últimos dois anos. O primeiro dá o ganho possível; o segundo, a conta de manutenção. Processo de quarenta horas mensais em sistema que muda duas vezes por ano é um caso claro. As mesmas quarenta horas em sistema que recebe atualização a cada seis semanas provavelmente não compensam, e essa comparação raramente é feita antes da assinatura.
Robô, integração ou reescrita
Três caminhos resolvem o mesmo problema com custos muito diferentes ao longo do tempo.
| Caminho | Prazo | Custo de manter | Quando escolher |
|---|---|---|---|
| RPA | Semanas | Alto e contínuo | Sistema fechado, processo estável, ou ponte temporária |
| Integração | Meses | Baixo, com revisão quando um lado muda | Os dois sistemas expõem o que é preciso |
| Reescrever o processo | Meses | Baixo | O processo é do negócio e o sistema atual o limita |
A leitura correta não é qual é o melhor, é qual é o horizonte. Para um problema que existirá por seis meses, o robô é racional. Para um que existirá por cinco anos, ele é a opção mais cara das três, e a conta só aparece no segundo ano.
O que muda na operação quando entra um robô
Um robô em produção não é um script esquecido numa máquina: é um funcionário digital, e ele traz as mesmas perguntas que qualquer funcionário traz.
- Com qual usuário ele entra nos sistemas? Robô que usa a credencial de uma pessoa mistura o que ele fez com o que ela fez, e some junto com ela quando ela sai da empresa. O certo é usuário próprio, com permissão mínima e trilha de auditoria separada.
- Quem é avisado quando ele para? Sem alerta, a descoberta acontece dias depois, quando alguém percebe que o relatório não chegou.
- Onde ele roda? Robô em computador de mesa depende de a máquina estar ligada, sem atualização pendente e sem ninguém usando o teclado.
- O que acontece com o que ficou pela metade? Precisa existir um jeito de saber onde parou e retomar sem duplicar o que já foi feito.
Nada disso é exigência exagerada de área técnica. É o mínimo para que a automação seja confiável o suficiente para que a empresa pare de conferir manualmente o que o robô fez, que é justamente o ganho que se buscava ao contratá-lo. Automação que continua sendo conferida à mão economizou menos da metade do que prometia.
O custo que aparece depois
O orçamento de RPA costuma mostrar licença e construção. Faltam três linhas. A manutenção por quebra, que acontece toda vez que uma tela muda e não avisa. A operação, porque alguém precisa conferir o que rodou, tratar o que falhou e reprocessar. E a dependência, já que o robô costuma ser feito por um fornecedor específico em uma ferramenta específica.
Existe ainda um custo silencioso: o processo automatizado por robô sai do radar. Ninguém mais o revisa, porque ele “já está resolvido”, e ele continua rodando do jeito antigo por anos. A conta do trabalho manual que se pretendia eliminar está em o custo dos processos manuais, e vale refazê-la depois de um ano de robô, para comparar.
Como decidir no seu caso
Quatro perguntas, na ordem. Este processo deveria existir? Se a resposta for não, elimine em vez de automatizar. Os sistemas envolvidos expõem API? Se expõem, integração ganha no médio prazo. O processo vai mudar nos próximos doze meses? Se vai, o robô será refeito. Por quanto tempo esse problema vai existir? Essa é a que decide entre ponte e solução.
Quando a conclusão for automatizar, o panorama das frentes possíveis está em automação de tarefas. Quando a conclusão for que o processo é do negócio e nenhum produto de prateleira o atende, o caminho passa por quando a ferramenta interna vira produto e por desenvolvimento de software.
Perguntas frequentes
O que é RPA?
RPA é a sigla de automação robótica de processos. Na prática, é um programa que opera outros programas como uma pessoa operaria: abre a tela, lê um campo, digita em outro, salva e avança. Ele não entende o processo, apenas repete a sequência que alguém definiu. É automação por imitação, e é isso que a torna rápida de montar e frágil de manter.
RPA é inteligência artificial?
Não. O robô de RPA não decide nada que não esteja escrito na regra e não lida com o caso que ninguém previu. Existem produtos que combinam as duas coisas, usando modelos para ler documentos ou classificar exceções, mas o RPA em si é repetição de passos. Confundir os dois leva a esperar do robô um julgamento que ele não faz.
Qual a diferença entre RPA e integração de sistemas?
A integração faz dois sistemas trocarem dados diretamente, pela porta dos fundos, sem passar pela tela. O robô entra pela porta da frente, como se fosse um usuário. A integração custa mais para construir e muito menos para manter; o robô é rápido de montar e quebra sempre que uma tela muda de lugar.
Quando o RPA é a escolha certa?
Em quatro situações: sistema fechado que não expõe API e não vai mudar, processo estável de alto volume sem variação, ponte temporária enquanto a substituição de um sistema acontece, e fluxo com regra objetiva sem julgamento humano. A primeira é a mais legítima, porque nesse caso o robô é a única porta disponível.
Quando o RPA vira remendo caro?
Quando os dois sistemas têm API disponível, quando o processo muda com frequência, quando o fluxo depende de julgamento humano, quando o volume é baixo demais para pagar a manutenção e, principalmente, quando o processo automatizado não deveria existir. Nesse último caso, o robô congela o desperdício e o torna mais difícil de eliminar depois.
Quanto custa manter um robô de RPA?
Além da licença e da construção, entram três linhas: manutenção por quebra, sempre que uma tela muda sem aviso; operação, porque alguém precisa conferir o que rodou e reprocessar o que falhou; e dependência do fornecedor e da ferramenta em que o robô foi feito. Em horizonte de anos, esse conjunto costuma superar o custo de uma integração.
Por que um robô de RPA para de funcionar?
Porque ele depende da interface. Um campo que mudou de posição, uma atualização do fornecedor, uma janela de aviso nova ou uma lentidão do sistema fazem a sequência falhar. O agravante é que a parada raramente acontece com erro claro: ela ocorre no meio da execução, deixando parte do lote processada e parte não.
O robô precisa de um usuário próprio nos sistemas?
Precisa. Robô que usa a credencial de uma pessoa mistura o que ele fez com o que ela fez, quebra a trilha de auditoria e para de funcionar quando essa pessoa sai da empresa. O correto é usuário próprio, com a permissão mínima necessária e registro separado, tratando o robô como um funcionário digital.
RPA substitui a modernização de um sistema legado?
Adia. O robô contorna a limitação do sistema antigo sem resolvê-la, o que é útil como ponte por alguns meses e caro como solução permanente. A decisão de fundo continua sendo o que fazer com o sistema, e quanto mais robôs forem construídos em volta dele, mais difícil e mais cara fica essa decisão depois.
Como decidir entre robô, integração e reescrita?
Responda quatro perguntas nesta ordem: este processo deveria existir, os sistemas envolvidos expõem API, o processo vai mudar nos próximos doze meses e por quanto tempo esse problema vai existir. A última é a que decide. Para um problema de seis meses, o robô é racional; para um de cinco anos, ele é a mais cara das três opções.
