Só se automatiza o que se conhece: você conhece o seu próprio processo?

Nunca vi tanta gente empolgada pra automatizar. Nos workshops que dou, a frase mais comum é alguma variação de "quero colocar IA em tudo". A empolgação é legítima — a tecnologia nunca foi tão capaz nem tão acessível. Mas existe uma pergunta que faço antes de qualquer conversa sobre ferramenta, e ela desarma a sala inteira: me descreve, passo a passo, o processo que você quer automatizar. No papel. Do jeito que uma pessoa que nunca pisou na sua empresa conseguiria executar.

Em dez anos entregando automação em produção, posso contar nos dedos quantas empresas passaram nesse teste de primeira. E é exatamente por isso que este artigo existe.

Por que a empolgação com IA atropela o processo?

Porque a promessa é sedutora e o diagnóstico é chato. Comprar a ferramenta, assinar a plataforma, contratar o projeto — isso é rápido e dá sensação de progresso. Sentar com o time e descrever como o trabalho realmente acontece hoje — com as exceções, os "jeitinhos" e os casos que só a Fulana sabe resolver — é lento, expõe bagunça e não rende post no LinkedIn.

Esse atropelo não é novidade da era da IA. Em 1990, Michael Hammer publicou na Harvard Business Review um dos artigos mais influentes da história da gestão, com um título que já entrega a tese: "Reengineering Work: Don't Automate, Obliterate". O alerta de Hammer, 36 anos atrás, era contra empresas que usavam tecnologia para acelerar processos ruins em vez de repensá-los — cimentando a ineficiência dentro do software. Trocou-se o mainframe pelo LLM; o erro continua o mesmo.

"A primeira regra de qualquer tecnologia usada num negócio é que a automação aplicada a uma operação eficiente amplifica a eficiência. A segunda é que a automação aplicada a uma operação ineficiente amplifica a ineficiência."

Frase atribuída a Bill Gates — a origem exata é incerta; a verdade dela, não

E o preço de ignorar isso é conhecido: a pesquisa da McKinsey sobre transformações organizacionais aponta que 70% delas fracassam — e entre as causas está justamente a distância entre a aspiração do topo e a realidade operacional de quem executa. Automatizar sem conhecer o processo é a versão em miniatura desse fracasso, repetida em cada projeto.

O que acontece quando você automatiza um processo que ninguém conhece?

Três coisas, nessa ordem:

• O erro ganha escala. Um funcionário que executa um processo bagunçado erra na velocidade humana — algumas vezes por semana, e geralmente percebe. Um sistema que executa o mesmo processo bagunçado erra na velocidade da máquina: centenas de vezes por dia, com convicção, sem levantar a mão. O computador executa o caos mais rápido.
• As exceções invisíveis explodem. Todo processo real tem casos que "a pessoa resolve na hora": o cliente que paga diferente, a nota que vem com o CNPJ da matriz, o fornecedor que manda a planilha em outro formato. Enquanto o processo é manual, essas exceções são absorvidas em silêncio. Quando vira sistema, cada exceção não mapeada é uma parada, um dado errado ou um cliente mal atendido — e ninguém sabe explicar por quê, porque a regra nunca foi escrita.
• A automação denuncia que o processo não existia. É o desfecho mais comum e o menos esperado: no meio do projeto, descobre-se que cada pessoa do time executava o "mesmo" processo de um jeito, que ninguém concorda sobre qual é o certo, e que metade das regras mora na cabeça de uma única pessoa — que, aliás, sai de férias em janeiro.

Repare que nenhum desses três problemas é de tecnologia. Por isso trocar de ferramenta não resolve nenhum deles.

A receita de bolo: o teste que quase nenhuma empresa passa

A melhor analogia que conheço pra maturidade de processo é a receita de bolo. Todo mundo "sabe" fazer um bolo — até precisar escrever a receita pra outra pessoa executar sem poder tirar nenhuma dúvida.

Tenta. O resultado da primeira versão é sempre algo como: "mistura os ingredientes, bate bem e asse até ficar pronto". Agora entrega isso pra alguém que nunca fez um bolo na vida:

• "Mistura os ingredientes" — quais? Quanto de cada um? 3 ovos ou 4? Farinha de trigo comum ou com fermento? Em que ordem — e a ordem importa? (Importa.)
• "Bate bem" — na batedeira ou na mão? Velocidade alta ou baixa? Por quanto tempo? O que acontece se bater demais? (A massa solha. Você sabia; a receita, não.)
• "Asse até ficar pronto" — forno pré-aquecido? A quantos graus? Por quantos minutos? Untou a forma com o quê — manteiga e farinha, ou desenforma tudo grudado? E "pronto" é o quê: o palito que sai limpo? A cor da casca?

"Até dar o ponto" é a frase que separa quem sabe fazer de quem sabe ensinar a fazer. Você reconhece o ponto porque já fez o bolo cem vezes — o conhecimento está na sua mão, não no papel. Máquina não tem mão treinada. Máquina não sabe o que é ponto. Pra máquina, ou o critério está escrito ("35 minutos a 180°C, palito limpo no centro"), ou não existe.

Agora troque o bolo pelo seu processo de cobrança, de emissão de nota, de resposta a orçamento. A versão que o seu time descreve na primeira tentativa é o "asse até ficar pronto" corporativo: "aí a gente confere, ajusta o que precisar e manda pro cliente". Confere o quê? Ajusta como? Manda quando? E — a pergunta que mais derruba processo — o que acontece quando não dá certo?

E tem o passo mais revelador de todos, presente em quase toda descrição de processo que já ouvi: "aí o Fulano resolve caso a caso". Quando a receita tem esse passo, você não tem um processo — você tem uma pessoa. O negócio não sabe cobrar, quem sabe cobrar é a Fulana. E o dia em que a Fulana sair, o "processo" sai junto, pela mesma porta.

O que é POP (Procedimento Operacional Padrão)?

A boa notícia: esse problema tem solução conhecida há décadas, com nome, sobrenome e método. Chama-se POP — Procedimento Operacional Padrão: um documento que registra, de forma objetiva e sequencial, como uma atividade rotineira deve ser executada, por quem, com que frequência e com qual resultado esperado. É, literalmente, a receita de bolo do processo.

Uma curiosidade que reforça a analogia: a definição legal mais citada de POP no Brasil vem da vigilância sanitária — a RDC 216/2004 da Anvisa, criada para cozinhas profissionais, define POP como "procedimento escrito de forma objetiva que estabelece instruções sequenciais para a realização de operações rotineiras e específicas". O e-book do Sebrae-RS sobre POP — feito exatamente para serviços de alimentação — resume o que não pode faltar: instruções sequenciais das operações, frequência de execução e o responsável por cada atividade. A lei brasileira exige receita escrita na cozinha do restaurante; o seu financeiro merece o mesmo rigor.

Fora da cozinha, o POP é filho da gestão da qualidade. A ISO 9001 consagrou o princípio por trás dele — "um resultado desejado é alcançado com mais eficiência quando as atividades e os recursos são gerenciados como um processo" — e trata a documentação como ferramenta de consistência, não burocracia. Um POP bem escrito, como resume o Blog da Qualidade, contém:

• Objetivo: o que este processo entrega e por que ele existe;
• Gatilho e entrada: o que dispara o processo e o que precisa existir antes dele começar;
• Passos sequenciais: a ordem exata das ações, sem "etc." e sem "entre outros";
• Responsáveis: quem executa cada passo — cargo ou função, não "alguém do time";
• Frequência: quando e quantas vezes o processo roda;
• Exceções: o que fazer quando o passo não pode ser executado — e quem decide;
• Saída e critério de pronto: como saber, objetivamente, que o processo terminou certo.

Esse último item é o "palito limpo no centro" do seu processo. Se o critério de pronto não é objetivo, cada pessoa termina o processo num ponto diferente — e a máquina não termina nunca, ou termina sempre errado.

Como escrever a "receita de bolo" do seu processo?

Não comece documentando a empresa inteira — esse é o erro oposto ao da empolgação, e termina num fichário que ninguém abre. Escolha um processo (o que mais dói ou mais consome horas) e faça o seguinte:

• 1. Quem executa, escreve. Não o gestor — o executor. O gestor descreve o processo como ele deveria ser; o executor descreve como ele é. A distância entre as duas versões é, sozinha, um diagnóstico.
• 2. Filme a execução real. Uso essa provocação com clientes: se eu colocasse uma câmera filmando esse processo por um dia, o que eu veria? Peça pra pessoa executar o processo narrando cada passo em voz alta — inclusive os atalhos e as gambiarras. É nos "aqui eu dou um jeitinho" que mora o processo de verdade.
• 3. Colecione exceções por uma semana. Cada vez que alguém disser "esse caso é diferente", anota. No fim da semana você tem o mapa do que a automação vai precisar tratar — ou explicitamente deixar pra um humano.
• 4. Desenhe o fluxo (o workflow). É o mapeamento de processos na sua forma mais útil — caixinhas e setas resolvem: onde o processo começa, que decisões existem no caminho, onde ele termina. Se o desenho tiver um losango de decisão sem resposta escrita ("depende"), achou um buraco.
• 5. Aplique o teste do funcionário novo. A prova final da receita: uma pessoa recém-chegada, entregando só o documento, executa o processo sem tirar nenhuma dúvida? Se sim, você tem um POP. Se não, volte ao passo onde ela travou — o buraco está lá.

Há ainda um teste mais rápido, que recomendo antes de qualquer projeto: peça pra duas pessoas do time descreverem o mesmo processo, por escrito, separadamente. Compare. Se as descrições divergem — e divergem —, a empresa ainda não conhece o próprio processo. Conhece duas versões dele.

Como fazer automação de processos na prática?

Quando me perguntam como fazer automação de processos, a expectativa é que eu comece falando de ferramenta. Começo pelo contrário: são quatro etapas, e três delas acontecem antes de qualquer software.

1. Mapear. É o mapeamento de processos descrito na seção anterior: o fluxo escrito como ele realmente acontece — gatilho, passos na ordem, responsável por cada um, exceções e critério de pronto. Sem esse mapa, as três etapas seguintes não têm sobre o que trabalhar.
2. Medir. Quantas vezes o processo roda por mês, quanto tempo cada execução consome, onde ele trava e quanto custa o erro quando acontece. Medida imperfeita é melhor que nenhuma: é ela que decide o que entra primeiro na fila e é a base da conta de retorno da automação.
3. Cortar. Antes de automatizar, elimine o que só existe por inércia: a conferência que ninguém usa, a planilha intermediária, o e-mail de aviso que ninguém lê. Automatizar um passo que deveria simplesmente deixar de existir é pagar para preservar o desperdício — é o obliterate de Hammer, e é a etapa que mais reduz o preço do projeto.
4. Automatizar o que sobrou. Comece pelo trecho de maior volume e menor julgamento — o pedaço repetitivo, sem "depende". O resto entra por partes, à medida que as regras vão sendo escritas.

Glossário rápido, porque os três termos vivem embaralhados: workflow é o fluxo de trabalho em si — sequência de tarefas, gatilhos e responsáveis — e existe mesmo quando tudo roda no papel. BPMN (Business Process Model and Notation, mantida pela OMG) é apenas uma notação padronizada para desenhar esse workflow, com símbolos definidos para tarefa, decisão e evento. Automação de processos é trocar a execução manual desses passos por software. Dá para automatizar sem nunca desenhar um BPMN; não dá para automatizar sem conhecer o workflow.

E as exceções — quem decide o que a máquina não decide?

Aqui vale ser honesto contra o próprio discurso do mercado: nenhum processo real é 100% automatizável — e não deveria ser. Todo processo tem uma zona de regra (o que se repete igual, ou quase) e uma zona de julgamento (o que exige contexto, negociação ou responsabilidade que a empresa não quer delegar a um software).

O POP maduro documenta as duas zonas. Define alçadas: até tal valor, o sistema decide sozinho; acima, sobe pra aprovação humana. Define fronteiras: o agente de IA classifica e prepara a cobrança, mas a renegociação com o cliente antigo é do gerente. Esse desenho — o que automatiza, o que não automatiza e onde fica a fronteira — é uma decisão de negócio, não de tecnologia, e é ela que separa o que vai de RPA do que pede um agente de IA (e do que fica com gente).

Escrevo isso operando agentes de IA em produção há anos: agente sem fronteira escrita não é automação, é risco com crachá de inovação.

Como saber se meu processo está pronto pra automatizar?

Checklist direto. Responda sim ou não:

• O processo está escrito, e quem executa concorda que a descrição corresponde à prática?
• Duas pessoas descrevendo o processo separadamente produzem a mesma descrição?
• Cada decisão do fluxo tem critério objetivo — ou pelo menos um responsável nomeado quando é julgamento?
• As exceções conhecidas estão listadas, com o tratamento de cada uma?
• Existe critério de pronto mensurável (o "palito limpo")?
• O processo roda com frequência e volume que justifiquem automatizar? (Processo raro e barato se documenta — não necessariamente se automatiza. A conta de quando vale está em quanto custa desenvolver um sistema.)

Seis sins: automatize — o projeto vai ser rápido e o resultado, previsível. Três ou quatro: você está a um bom exercício de mapeamento de distância. Menos que isso: a melhor notícia deste artigo é que você descobriu antes de pagar por um sistema.

"Não passei no teste. E agora?"

Agora vem a parte que eu faria questão de dizer olhando no seu olho: não passar no teste não significa que você está longe de automatizar. Significa que o primeiro passo não é código.

E há uma pegadinha nessa etapa: quem executa o processo há anos é justamente quem tem mais dificuldade de descrevê-lo — o conhecimento virou reflexo, e reflexo não se enxerga. Extrair o processo da cabeça de quem opera, inclusive o que a pessoa não sabe que sabe, é trabalho de método: pergunta certa, na ordem certa, com alguém de fora conduzindo. É exatamente isso que fazemos na Fase 1 — o Diagnóstico de Viabilidade Técnica: para automação de processos ela é uma conversa de 30 minutos, sem compromisso: você apresenta o processo, a gente avalia — o que dá pra automatizar hoje, o que precisa amadurecer antes — e devolve a proposta fechada com preço e prazo. Se a resposta honesta for "documenta primeiro, automatiza depois", você sai sabendo disso numa conversa sem compromisso — e não por R$ 80 mil.

Perguntas frequentes