A demonstração corre sempre bem. Pega-se no processo tal como funciona no dia da reunião, automatiza-se, cronometra-se e mostra-se o número: «de 40 horas por mês para 8». Três semanas depois do arranque muda uma regra de descontos, o fornecedor redesenha o formato das suas guias de remessa e alguém das finanças acrescenta um campo ao relatório. A automatização continua lá, mas já não automatiza o processo: automatiza a versão do processo que existia no dia da demonstração.
A tese numa linha: o critério que falta em quase todas as listas de «o que automatizar» não é o volume nem a poupança, é a estabilidade. Um processo que muda todos os meses consome em manutenção o que liberta na execução, e o cálculo do retorno faz-se sempre sobre uma versão congelada que já não existe. Se o processo se mexe mais depressa do que a tua capacidade de o reajustar, não o automatizes ainda: estabiliza-o primeiro.
Automatizar um processo que muda com frequência custa mais do que liberta
As listas de candidatos pontuam três coisas: quantas vezes a tarefa se repete, quanto tempo demora e quanto custa o erro. As três medem o processo hoje. Nenhuma pergunta o quanto se vai parecer consigo próprio daqui a seis meses, que é precisamente o que decide se a automatização envelhece bem ou se transforma numa fatura recorrente. Por isso um processo pode ter a nota mais alta em volume e a pior em retorno real.
A resposta curta à pergunta que nos fazem: sim, pode automatizar-se um processo que muda com frequência, mas não compensa quando o custo de o reajustar a cada mudança se aproxima das horas que liberta. E a manutenção raramente é orçamentada, porque no momento da demonstração ainda não ocorreu nenhuma mudança.
A aritmética: horas libertadas menos horas de reajuste
A conta cabe numa linha: horas líquidas por mês = horas libertadas por mês − (mudanças por ano × horas por mudança ÷ 12). Uma «hora por mudança» inclui o que quase nunca se regista: perceber o que mudou, alterar o fluxo, testá-lo de novo com casos reais e pô-lo em produção sem estragar o que já funcionava. Um exemplo com números inventados só para mostrar a conta (substitui-os pelos teus), num processo que consome 40 horas por mês à mão e que uma automatização estável deixa em 8:
| Como se comporta o processo | Mudanças por ano × horas por mudança | Horas de reajuste por mês | Horas líquidas libertadas por mês |
|---|---|---|---|
| Estável | 1 × 10 | 0,8 | 31,2 |
| Muda todos os trimestres | 4 × 12 | 4 | 28 |
| Muda todos os meses, mudanças de parâmetro | 12 × 20 | 20 | 12 |
| Muda todos os meses, mudanças de estrutura | 12 × 40 | 40 | −8 |
Repara na última linha: o processo automatizado custa mais do que fazê-lo à mão. Não é um caso exótico, é o que acontece quando a mudança não é um valor que se ajusta, mas uma forma de trabalhar que se refaz. E a conta nem sequer inclui a supervisão, que se subtrai à parte, como explicamos em porque é que as horas libertadas não são poupança.
O que significa «muda» (nem todas as mudanças custam o mesmo)
Dizer que um processo «muda muito» não serve: há mudanças que se absorvem em minutos e mudanças que obrigam a reescrever. A diferença está no que se mexe:
- Mudam os valores. Um limiar, uma tarifa, uma lista de exceções. Se esses valores vivem numa tabela fora do fluxo, a mudança custa minutos. Se estão escritos dentro da lógica, custa uma intervenção.
- Muda o formato do que entra. Um fornecedor que redesenha a fatura ou um cliente que muda o modelo. O custo depende da robustez da leitura à entrada, e é a mudança que mais estraga em silêncio.
- Muda o sistema por onde passa. Uma migração de ERP, um CRM novo, uma API que é retirada. É uma mudança de estrutura: custa dias, não minutos.
- Muda o critério de quem decide. O que ontem se aprovava sozinho, hoje é revisto por uma pessoa. É a mais cara, porque o fluxo continua a funcionar e produz decisões erradas sem que dispare nenhum alarme.
Como medir a estabilidade antes de automatizar: quatro perguntas
Não é preciso um modelo. São precisas quatro respostas, que se obtêm numa tarde com a pessoa que executa o processo:
- Quantas vezes mudou nos últimos doze meses? Com datas. Vê o histórico da instrução de trabalho, os e-mails de «a partir de agora faz-se assim» e as ocorrências abertas. Se ninguém se lembra de uma mudança, provavelmente são muitas pequenas.
- O que se mexeu de cada vez: um valor, um formato ou a estrutura? Classifica cada mudança com a lista acima. Três mudanças de valor e uma de estrutura não pesam como quatro de estrutura.
- Quem decide a mudança e avisa antes? Se a mudança vem de fora (um fornecedor, um regulador, um cliente) e sem aviso, o reajuste será sempre urgente e sempre tardio.
- O processo está escrito? Um processo que só existe na cabeça de quem o executa não se pode reajustar: primeiro é preciso extraí-lo. É por isso que documentar as tuas automatizações não é burocracia, é o que torna barata a mudança seguinte.
O que fazer com o processo que muda todos os meses
Há quatro saídas, e a primeira quase ninguém a considera porque parece não fazer nada:
- Estabilizá-lo primeiro. Congelar uma versão durante um trimestre, decidir quem autoriza as mudanças e juntá-las numa só janela. Às vezes o processo muda todos os meses porque ninguém decidiu como deve ser, não porque o negócio o exija.
- Automatizar o núcleo estável e deixar a cauda variável a uma pessoa. 80 % dos casos seguem a regra de sempre; os 20 % que mudam resolve-os alguém. É menos espetacular na demonstração e muito mais barato de manter.
- Tirar as regras do fluxo. Que limiares, tarifas e exceções vivam numa tabela que o responsável pelo processo possa editar sem tocar na automatização.
- Esperar. Se a grande mudança já vem a caminho (uma migração, uma nova norma), automatizar agora é pagar duas vezes.
Qualquer que seja a saída, o reajuste precisa de uma rede: cada mudança deveria passar por um teste antes de tocar na produção, porque um processo instável com uma automatização sem testes é exatamente onde nascem as ocorrências que o cliente descobre.
Quando compensa automatizar mesmo que mude
Há exceções razoáveis. Se o volume é muito alto e as mudanças são quase sempre de valor (não de estrutura), o reajuste dilui-se e a conta sai. Se o custo do erro é muito grande, pode compensar pagar a manutenção pela rastreabilidade. E se o processo muda porque o negócio está em plena transformação, automatizar o núcleo estável e deixar o resto a uma pessoa continua a ser melhor do que esperar que tudo acalme. O que não é razoável é descobrir o custo de manutenção depois de ter assinado o projeto.
Por onde começar
Pela lista, antes da ferramenta: acrescenta uma coluna de estabilidade ao teu critério de seleção e pontua-a com as quatro perguntas. O guia sobre que processos automatizar com IA explica como ordenar candidatos por tarefa; esta coluna decide quais entram primeiro. E se preferires que alguém o meça contigo nos teus processos reais, é exatamente o que fazemos ao auditar os teus processos para IA: o que é adequado, quanto custa de facto e em que ordem entra, com a estabilidade como filtro desde o primeiro dia.
A frase para levar é a do início: a demonstração faz-se contra o processo de hoje, e tu vais conviver com o de daqui a seis meses. Escolhe primeiro o que menos se vai mexer.