Todo sistema corporativo guarda, com data e hora, cada etapa pela qual passa um pedido. Para André de Barros Faria, engenheiro formado pela Universidade de Brasília e CEO da Vert Analytics, esse rastro costuma ser o ponto de partida mais negligenciado na automação de processos, porque revela como o trabalho acontece de verdade, e não como foi desenhado.
A diferença parece técnica, mas define o resultado de qualquer projeto de modernização. Quem automatiza o fluxograma oficial acelera um processo que, muitas vezes, não existe na prática. Quem começa pelos registros enxerga onde o tempo realmente se perde. O caso a seguir é hipotético, construído a partir de situações comuns nesse tipo de projeto, e ajuda a mostrar como essa escolha muda o desfecho.
O processo que existia no papel
Um órgão público responsável por emitir licenças recebia em média 3 mil pedidos por mês, e cada um levava cerca de 20 dias para ser concluído. O fluxograma oficial tinha cinco etapas: recebimento, conferência de documentos, análise técnica, aprovação e emissão.
A primeira proposta da equipe foi direta. Se a análise técnica era a etapa mais trabalhosa, bastaria colocar um agente de IA para fazê-la. O plano fazia sentido no papel, e o investimento parecia fácil de justificar.
O problema é que fluxogramas envelhecem. Como demonstra André Faria, eles são desenhados uma vez, em geral numa reunião, e não acompanham os atalhos, as exceções e as devoluções que a rotina vai criando. Com o tempo, o documento passa a descrever a intenção da organização, e não o caminho que os pedidos de fato percorrem.
O que os registros mostraram?
Antes de começar o desenvolvimento, a equipe cruzou os registros dos sistemas envolvidos com técnicas de inteligência analítica. O retrato foi outro. Quase metade dos pedidos voltava ao solicitante pelo menos uma vez por falta de documento, e cada devolução acrescentava, em média, oito dias ao prazo.

A análise técnica, alvo original do projeto, consumia menos de três dias. O gargalo estava num laço de retrabalho que o fluxograma sequer representava, porque ninguém o havia desenhado como etapa. Ele simplesmente acontecia.
Essa é a lógica que André Faria descreve como decisão orientada a dados aplicada ao próprio processo: medir antes de escolher o que automatizar. Sem esse passo, o agente de IA teria acelerado a parte que já funcionava razoavelmente bem.
O que foi automatizado e em que ordem?
A prioridade mudou. A primeira intervenção foi colocar, no momento do envio, um agente autônomo de IA capaz de ler os documentos anexados, apontar o que faltava e orientar o solicitante antes que o pedido entrasse na fila. O pedido incompleto deixava de existir dentro do processo.
Só depois veio a análise técnica, agora com hiperautomação integrando os sistemas de consulta que o analista acessava manualmente, um a um. O analista continuou decidindo. O que mudou foi o tempo gasto reunindo informações. No cenário simulado, o prazo médio cairia de 20 para menos de dez dias, e mais da metade do ganho viria da primeira etapa, a menos sofisticada tecnicamente. Para o cidadão, a diferença aparece como menos idas e vindas e uma resposta mais previsível.
O que o caso ensina sobre modernização?
A tentação de qualquer projeto de tecnologia é começar pela parte mais impressionante. O caso mostra o contrário: o maior retorno costuma estar no ponto mais simples, desde que ele tenha sido encontrado com dados, e não com intuição.
Para André de Barros Faria, a tecnologia própria só entrega valor quando a pergunta certa vem antes da ferramenta. Automatizar é a parte visível do trabalho, mas a decisão que separa um ganho marginal de uma mudança real acontece antes, quando alguém se dispõe a olhar o processo como ele é.
