«Está a correr bem» não é uma medição (e a poupança da proposta também não)
Há uma conversa que se repete em todas as empresas que automatizaram alguma coisa há mais de um semestre. Alguém pergunta se aquilo está a dar retorno. Faz-se um silêncio curto. E responde quem a montou: «funciona, não dá problemas». Isso é uma resposta sobre o estado do sistema, não sobre o seu desempenho. Um fluxo pode passar seis meses sem cair e estar a processar metade dos casos de antes, com duas pessoas a rever cada saída por via das dúvidas, e continuar a responder «está a correr bem» à única pergunta que lhe fazem.
O segundo trunfo de mão é pior porque parece um número: a «poupança estimada» da proposta. Vinte horas por mês, dizia o slide. Esse número calculou-se a multiplicar um volume suposto por um tempo unitário suposto, antes de haver um único dado real, e sem descontar o trabalho novo que a automação ia criar —rever exceções, arranjar a integração da terça-feira, explicar o caso esquisito ao sistema—. É uma hipótese de compra, e o seu lugar é na decisão de investir, não na avaliação do investido. Uma previsão não se transforma em medição só porque passaram oito meses.
A linha de base: o único número que não podes ir buscar depois
Aqui está o erro que estraga a medição da maioria das automações, e comete-se antes de escrever a primeira linha do fluxo: ninguém apontou como corria o processo antes. Sem esse «antes», tudo o que medires depois são números absolutos órfãos. Processas oitocentos casos por mês: isso é bom? Não se sabe. Demoras quatro horas por caso: melhor ou pior do que em janeiro? Ninguém se lembra com precisão, e a memória de uma equipa arredonda sempre a favor do que é novo, porque o novo foi montado por alguém que está na sala.
A linha de base tira-se com o processo ainda à mão, durante duas ou três semanas, e não precisa de instrumentação nenhuma: uma folha de cálculo e o compromisso de a preencher. Cinco colunas:
- Volume. Quantos casos entram por semana. Com a sazonalidade anotada se a houver: agosto não conta como outubro.
- Tempo de ponta a ponta. Desde que o caso chega até estar fechado, não o tempo em que alguém está a escrever. A diferença entre os dois números —o tempo que o caso passa à espera na caixa de entrada de alguém— costuma ser metade do total e é onde a sério se ganha.
- Mãos que lhe tocam. Quantas pessoas diferentes intervêm. Cada passagem de testemunho é um sítio onde o caso para.
- Erros e refeitos. Quantos casos há que voltar a fazer. É a métrica que quase ninguém aponta e a que mais engana depois: se automatizas um processo que se refazia 15% das vezes e continua a refazer-se 15%, não melhoraste a qualidade, só a velocidade.
- Casos esquisitos. Quantos saem do caminho normal e porquê. Esta coluna é a que te vai dizer, meses depois, se as exceções da tua automação são as de sempre ou umas novas que criaste tu.
Se já arrancaste sem linha de base —que é o mais provável, porque quase ninguém a tira—, não inventes o «antes». Reconstruí-lo de memória é pior do que não o ter, porque produz um número com ar de dado que ninguém vai voltar a questionar. O honesto é escrever «não há linha de base» no relatório, começar a medir a partir de hoje e usar o mês em curso como ponto de partida: daqui a um trimestre tens comparação. E se ainda vais a tempo, a ordem certa é ao contrário da que toda a gente segue: primeiro mede-se o processo, depois decide-se que processos automatizar, e só então se monta.
As quatro métricas que interessam
Quatro chegam. Não é minimalismo estético: um painel de doze indicadores não se olha, e o que não se olha não existe. Estas quatro cobrem as quatro perguntas diferentes que se podem fazer a um sistema em produção —quanto faz sozinho, quanto encrava, quanto liberta a sério e quanto custa— e cada uma tapa um buraco que as outras três deixam aberto.
| Métrica | O que responde | De quanto em quanto tempo se olha |
|---|---|---|
| Percentagem que passa sozinha | De cada cem casos que entram, quantos saem fechados sem ninguém lhes tocar. É a única que mede quanto do processo está mesmo automatizado. | Semanal |
| Exceções por semana | Quantos casos saem do fluxo e, sobretudo, de que tipo. Distingue o sistema que aprende do que apenas aguenta. | Semanal |
| Tempo real poupado vs. prometido | Horas que já não se fazem menos horas novas de revisão e manutenção, contra o que dizia a proposta. É o único sítio onde a promessa enfrenta o dado. | Mensal |
| Custo por caso | Tudo o que o sistema custa —licenças, tokens, manutenção, tempo humano restante— dividido pelos casos processados. | Mensal |
A ordem interessa: as duas primeiras são de operação e leem-se na reunião semanal; as duas últimas são de negócio e levam-se ao comité. Misturá-las produz o efeito do costume —o comité a discutir exceções pontuais e a equipa técnica às turras com um número de custo que não consegue mexer—.
Como se conta o «passa sozinho» sem te enganares
A métrica de casos que passam de ponta a ponta sem intervenção não fomos nós que a inventámos: vem do mundo financeiro, onde há décadas se mede o straight-through processing —a operação que se liquida sem intervenção manual— e onde não é um indicador de vaidade, é algo que se factura: os bancos cobram comissões pelos pagamentos que não passam sozinhos ou repercutem o custo da reparação manual em quem lhes manda instruções de má qualidade. A exceção tem preço, e por isso ali ninguém a esconde.
A armadilha desta métrica é o numerador, e quase todos caem nela: conta como «passa sozinho» apenas o caso que se completa inteiro sem qualquer intervenção humana. Um processo com a entrada automatizada e a aprovação à mão não passa sozinho: passa metade. Se o fluxo extrai os dados da fatura mas alguém tem de carregar em validar, isso é um caso assistido, não automático. E se medires a percentagem contando a parte automatizada do percurso em vez dos casos fechados, sai-te um 90% lindíssimo que não corresponde à sensação de ninguém que trabalhe ali —e essa dissonância entre a métrica e o que a equipa vê é o que mata a credibilidade de toda a medição—.
As exceções: a métrica que diz se o sistema melhora ou apenas aguenta
Se só pudesses olhar para um número por semana, olha para este. A percentagem que passa sozinha diz-te onde estás; as exceções dizem-te para onde vais. E o truque está em não ficar pelo total: vinte exceções esta semana e vinte na semana passada podem ser duas situações opostas conforme o tipo.
Classifica-as em três baldes, que são também os três motivos pelos quais um caso sai do caminho automático —falta informação, a informação chega num formato que a máquina não percebe, ou o caso cai fora das regras que se decidiu automatizar—:
- Dado incompleto ou sujo. O caso chega sem o que é preciso. Isto quase nunca se arranja na automação: arranja-se a montante, no formulário, no template ou no fornecedor que manda mal o ficheiro. Se cresce, tens um problema de entrada disfarçado de problema de IA.
- Caso legítimo fora das regras. O sistema faz bem em não lhe tocar: é uma devolução fora de prazo, um valor acima do limite, um cliente com condições especiais. Estas exceções não deveriam descer a zero. São o desenho a funcionar.
- Falha do sistema. A integração caiu, o modelo devolveu algo que não presta, o fluxo ficou a meio. Estas são as únicas que contam como dívida: cada uma devia ter nome, causa e arranjo, e a mesma não devia aparecer duas vezes. Detetá-las a tempo é outro assunto e tem mecânica própria em detetar falhas em automações com IA.
A leitura é direta. Se o balde três desce e o dois se mantém, o sistema está a amadurecer: foste fechando falhas e o que sobra é a fronteira que decidiste não atravessar. Se o balde três fica plano mês após mês, o sistema não está a melhorar —está a aguentar, e alguém está a pagar esse aguento em tempo—. E se o balde um cresce, o problema não está na tua automação: está em quem te manda os dados.
É aqui que aparece a despesa que nunca se orçamenta: o tempo de gerir exceções. É trabalho novo, criado pela automação, feito por alguém que antes não o fazia. Se não o contas, a tua poupança é ficção; e se o contas, muitas vezes descobres que metade da poupança prometida é comida pela fila de casos esquisitos. Contá-lo é o que transforma uma medição numa medição.
Afinar, refazer ou desligar: o critério para decidir
Medir sem um critério de decisão definido de antemão é colecionar números. O critério tem de ser escrito antes de olhar para os dados —se não, o número interpreta-se a favor do que já se tinha decidido— e só tem três saídas.
| O que vês | O que significa | O que fazes |
|---|---|---|
| A percentagem que passa sozinha é razoável e as exceções são quase todas do balde 2 (fora das regras). | O sistema está a fazer o seu trabalho e a fronteira está bem posta. | Afinar. Alargar regras caso a caso só se o volume desse tipo justificar o trabalho. Alterações pequenas e testadas. |
| O balde 3 (falhas) não desce em três meses e é sempre pelo mesmo sítio. | Não é um bug: é um problema de desenho do fluxo. Remendar mais vai durar outro trimestre. | Refazer essa parte. Uma redefinição delimitada sai mais barata do que doze remendos, e faz-se com rede: ver testar alterações sem partir a automação. |
| O volume do processo caiu, ou a manutenção custa mais horas do que as que poupa, ou as exceções ultrapassam os casos automáticos várias semanas seguidas. | O que tens é um processo manual com um passo automático que atrapalha e continua a consumir licenças, avisos e atenção. | Desligar. Apagá-lo e documentar porquê. É a saída menos usada e a que mais dinheiro recupera. |
A terceira linha é a incómoda. Desligar uma automação vive-se como admitir que não valia, por isso o fluxo fica ligado «por via das dúvidas» e passa a engrossar o censo de automações zombie: as que correm, custam e já não servem a ninguém. Desligar a tempo não é um fracasso do projeto —é a única prova de que a medição serve para alguma coisa, porque uma medição que só pode confirmar decisões anteriores não é uma medição, é uma cerimónia—.
Como montar a medição esta semana
Nada do que está acima precisa de ferramenta nova. Numa tarde, e por esta ordem: define o que conta como «caso fechado sem intervenção» e escreve-o, porque essa definição é 80% da fiabilidade de tudo o resto; tira do histórico de execuções os casos das últimas quatro semanas e classifica-os em passou sozinho / exceção, com a exceção etiquetada nos três baldes; aponta durante um mês o tempo que a equipa dedica a exceções e a manutenção, ainda que a olho, porque é o lado que ninguém tem; e monta o custo por caso com a fatura real, não com a estimada. Quatro números, uma folha, quinze minutos todas as segundas-feiras.
E um aviso sobre o ritmo: a medição semanal é para operar, não para julgar. Uma semana má não significa nada —entrou um lote esquisito, houve uma queda, foi de férias quem resolvia—. A decisão de afinar, refazer ou desligar toma-se com três meses de dados à frente, nunca com um gráfico de sete dias. Essa disciplina de olhar amiúde e decidir devagar é, de facto, metade da manutenção de uma automação: a outra metade é fazer alguma coisa com o que a medição te diz.
A fronteira honesta: isto está escrito para quem tem uns quantos fluxos e uma folha de cálculo. Quando o que está por baixo são agentes a decidir em direto, com custo por token que dispara sem avisar e qualidade que se degrada em silêncio, a medição deixa de ser uma folha semanal e passa a ser instrumentação com rastos e alertas: isso é monitorizar a IA em produção. E se o que queres é que a linha de base, as quatro métricas e a revisão trimestral fiquem montadas sobre os teus fluxos atuais e sejam levadas por alguém que não és tu, isso é automação de operações: o número, todos os meses, sem teres de te lembrar de o pedir.