Com o avanço de iniciativas de hiperautomação em áreas administrativas, Rolando Bonaccorsi, líder em IA e ciência de dados aplicadas a negócios e operações, avalia que o maior custo de um programa de robôs não está na construção, e sim na manutenção do que já foi entregue. Cada automação em produção vira um componente vivo, sujeito a falha como qualquer sistema.
O engano começa na forma de contabilizar resultado. Programas de automação costumam ser medidos pelo número de processos automatizados e pelas horas economizadas na implantação, sem que o esforço recorrente de sustentação entre na conta. Depois de dois anos, a carteira de robôs consome equipe dedicada apenas para manter funcionando aquilo que foi declarado concluído, sem que o relatório de resultados registre esse consumo em nenhuma linha.
Por que uma automação para de funcionar?
A fragilidade é estrutural em robôs que operam sobre a interface de sistemas. Mudança de posição de campo, renomeação de botão, atualização de versão ou um aviso novo na tela interrompem a execução, porque a automação reconhece elementos visuais e não entende o significado da tela. Nenhuma dessas alterações é tratada como mudança relevante por quem mantém o sistema de origem, já que o robô raramente aparece na lista de consumidores daquela tela.
Rolando Bonaccorsi ressalta que a segunda fonte de quebra é a variação dos dados de entrada, já que o robô foi desenhado para o caso típico observado durante o levantamento. Formatos de data diferentes, campos preenchidos de maneira inesperada e exceções legítimas do processo produzem travamento ou, pior, execução silenciosa com resultado incorreto.
O acúmulo silencioso de dívida de automação
Carteiras de robôs crescem por adição, quase nunca por revisão. Automações criadas para processos que mudaram continuam executando, versões antigas permanecem ativas ao lado de novas e ninguém consegue afirmar quais ainda produzem valor. O inventário vira lista extensa de scripts com dependências cruzadas, mantidos por receio de interromper algo que talvez ainda seja usado por alguma área. A revisão periódica da carteira raramente entra no planejamento, porque desligar robô não gera indicador positivo.
Como analisa Rolando Bonaccorsi, engenheiro de computação com MBA executivo, a dívida se manifesta na capacidade de entrega, porque a equipe que deveria automatizar novos processos passa a dedicar a maior parte do tempo a corrigir os antigos. O programa perde velocidade sem que nenhuma decisão explícita de redução de escopo tenha sido tomada em algum momento.
Monitorar robô é diferente de monitorar sistema
Sistemas indisponíveis geram reclamação imediata de quem os usa. Robôs falham em silêncio, porque o processo que eles executam não tem usuário acompanhando em tempo real. A falha fica registrada apenas no log da plataforma de automação, que ninguém abre por rotina. A descoberta acontece dias depois, quando alguém percebe que a conciliação não foi feita ou que o relatório de fechamento ficou sem os lançamentos daquele período específico, com retrabalho manual para recuperar o atraso acumulado.
O monitoramento adequado observa resultado, não apenas execução. Verificar se o robô rodou é insuficiente, já que a execução concluída com dados errados é o cenário mais custoso. Rolando Bonaccorsi avalia que a prática que funciona combina checagem de volume processado com validação de consistência do resultado contra uma referência independente do próprio robô.
Quando vale corrigir o processo antes de automatizar
Automatizar um processo ruim entrega a velocidade ao erro. Fluxos com retrabalho, aprovações redundantes e campos preenchidos manualmente sem necessidade carregam complexidade que a automação precisa reproduzir passo a passo, o que multiplica os pontos de falha e torna cada manutenção futura mais cara do que a implantação original havia estimado para aquele fluxo de trabalho.
Na interpretação de Rolando Bonaccorsi, a decisão mais econômica frequentemente é eliminar etapas antes de robotizar o restante, mesmo que o ganho apareça mais devagar no indicador de horas poupadas. Automação construída sobre processo simplificado tem menos pontos de contato com telas e arquivos, e justamente por isso sobrevive às mudanças seguintes com ajuste pequeno em vez de reconstrução completa.
