Cases / BPO financeiro
Implementação de IA em processo
Um BPO financeiro de cinco pessoas que já usava três ferramentas de IA e continuava presa na operação. O que devolveu uma semana por mês para a dona do negócio não foi a tecnologia. Foi ter processo definido antes de automatizar.
O problema
Quando começamos, a empresa já usava três ferramentas de IA pagas e a dona já escrevia código com elas. Não era o caso clássico de quem nunca tinha experimentado.
Mesmo assim, a rotina continuava manual. Lançamento entrando na mão, nota emitida na mão, DRE montada em Excel, conciliação conferida olho a olho.
A frase que ela usou no briefing explica melhor que qualquer diagnóstico meu: perdia tempo explicando para a IA o que precisava e dependia de muitos ajustes no que estava sendo construído.
Ela tinha passado um dia inteiro tentando automatizar a integração com um dos sistemas financeiros e terminado o dia sem resultado.
O gargalo não era a ferramenta. Era pedir para a IA resolver um processo que ninguém tinha definido antes.
O que a análise mostrou
Não existia contexto persistente. Cada conversa com a IA começava com ela reexplicando o que é a empresa, quem é o cliente, como funciona o processo, o que é cada conta do plano de contas.
Também não existia biblioteca de instrumentos. Cada automação era construída do zero, usada uma vez e perdida. Na semana seguinte, tudo de novo.
E havia um erro de fronteira que derrubava a parte mais cara do trabalho. O trabalho determinístico, cruzar, somar, conciliar, estava sendo entregue para a IA resolver solta. É exatamente o tipo de tarefa em que ela erra sem avisar.
Código para o que é determinístico. IA para o que é ambíguo. Foi misturar os dois que fez a automação do livro caixa falhar.
O que eu fiz
Não foi treinamento de ferramenta e não foi serviço feito por mim. Ela já tinha tentado sozinha e falhado, então coaching não resolveria. E entregar pronto manteria a dependência, que é o oposto do contratado.
O formato foi construir junto, uma hora por semana, sempre em cima de um caso real daquela semana.
Primeiro montamos a fundação: o contexto da empresa escrito uma vez, em lugar fixo, para parar de reexplicar. Depois a biblioteca de instrumentos reaproveitáveis. Depois a integração por API com os dois sistemas financeiros. Por último o portal onde o cliente dela acessa o próprio resultado.
Cada sessão terminava com alguma coisa funcionando. Não com um plano para a semana seguinte.
O resultado que ela mediu sozinha
Na quarta sessão, sem que eu perguntasse, ela estimou o ganho da operação desde o começo do projeto.
Cerca de uma semana por mês em agilidade.
O motivo que ela deu é a parte que interessa. Antes construía tudo em Python puro e mantinha várias frentes abertas ao mesmo tempo, sem terminar nenhuma. Agora gera o que precisa, coloca para resolver, confere, libera e passa para o próximo.
Repare que a mudança não é de ferramenta. É de fluxo. Uma frente por vez, com começo, conferência e fim.
Em um BPO financeiro, uma semana por mês é aproximadamente um quarto da capacidade da pessoa que sustenta o negócio inteiro. É capacidade que volta para atender mais cliente, ou para sair de cima da operação.
O resumo
Comparação entre a rotina relatada no briefing de junho e a operação rodando ao fim da quinta sessão.
Onde a IA entra e onde ela não entra
Uma das rotinas resistiu por semanas. Compra parcelada no cartão, dois documentos fiscais para um mesmo pagamento, e o script não conseguia amarrar uma coisa na outra.
Cada caso novo virava uma exceção dentro da regra. A regra ia inflando. Quanto mais o script melhorava, mais casos continuavam de fora.
Então ela puxou a lista completa de divergências, olhou o tamanho real do problema e fez a pergunta certa para a pessoa certa. Perguntou ao contador se aquela regra precisava mesmo existir.
Não precisava. A compra podia ser lançada inteira no mês de emissão da nota, e semanas de manutenção de script deixaram de ser necessárias.
A IA devolve tempo. Ela não decide qual é a regra do seu negócio.
É por isso que implementação de IA não é sair automatizando tudo. Parte do trabalho é separar o que ganha tempo com automação do que só precisa de uma decisão bem tomada. Quando essa separação está clara, o que sobra para automatizar funciona de primeira e rende exatamente o que prometeu.
O critério que decidiu a arquitetura
A empresa cuida do financeiro de outras empresas. O que está em jogo não é o dado dela, é o dado dos clientes dela.
Por isso o portal foi desenhado sem banco de dados. A extração e o cálculo acontecem na máquina dela, e o que vai para a internet é só o documento consolidado, protegido por acesso com e-mail e código.
Descartamos o caminho de aplicativo com login e banco por três motivos na mesma ordem: risco, custo e complexidade. Também descartamos planilha compartilhada em nuvem e framework de front-end. O que ela tem hoje é simples, funciona e ela entende sozinha. Esse é o critério.
Toda decisão de arquitetura aqui passou primeiro pela pergunta de segurança, e só depois pela de conveniência.
O princípio
Quase todo mundo que me procura para falar de IA já tem IA. Já paga assinatura, já testou, já usou para escrever texto e resumir reunião. E continua com a mesma quantidade de trabalho manual na mesa.
O que produz ganho medido em semana, e não em impressão, é a parte chata. Escrever o contexto uma vez para parar de reexplicar. Definir onde acaba o determinístico e começa o ambíguo. Perguntar se a regra que está sendo automatizada precisa mesmo existir. Transformar tentativa em instrumento que se usa de novo.
Nada disso é sobre o modelo de IA que você usa. Tudo isso é sobre processo.
Ferramenta de IA em processo indefinido devolve retrabalho mais rápido. Em processo definido, devolve uma semana por mês.
Próximo passo
Me conta qual é a rotina que mais consome a sua semana. Eu digo se ela está pronta para ser automatizada ou se o problema é a regra por baixo dela. Se for a regra, eu falo isso na primeira conversa, antes de qualquer proposta.