# Quantas variantes tem o processo que você vai automatizar?

> O retorno da automação depende de quantas vezes o processo roda e de quantas variantes ele tem. Veja como contar antes de decidir o que automatizar.

- Autor: Marlon Trettin
- Publicado: 2026-10-30 · Atualizado: 2026-10-30
- Idioma: pt-BR
- Canonical: https://yowpi.com/blog/variantes-do-processo-quando-a-automacao-se-paga

---

O retorno de uma automação depende de duas contagens que costumam ficar de fora da conversa de escopo: quantas vezes o processo vai rodar e quantas variantes ele tem. Com muitas variantes e pouco volume em cada uma, cobrir todas custa mais do que economiza. Automatize o núcleo frequente e desenhe uma rota para a cauda.

## TL;DR

- Automação não reduz custo por definição. Brown e Hellerstein, pesquisadores da IBM, mostram que ela se paga quando o processo vive tempo suficiente, é fácil de generalizar a partir do manual e economiza muito a cada execução ([HotOS, 2005](https://www.usenix.org/legacy/events/hotos05/final_papers/full_papers/brown/brown_html/index.html)).
- No caso que eles estudaram, 25% dos pacotes de software foram instalados em menos de 15 servidores. Os autores estimam que de 15% a 30% das instalações não deveriam ter sido automatizadas.
- Fischer e colegas analisaram processos reais e encontraram uma cauda longa de variantes, com menos execuções e mais partes envolvidas por variante ([Information Systems, 2021](https://arxiv.org/abs/2011.13188)). Os autores recomendam tratar a cauda de outro jeito.
- O que a automação não cobre sobra para as pessoas. Conte variantes e volume antes de aprovar o escopo.

## Por que o retorno da automação depende de duas contagens?

Porque a automação tem um custo para construir e uma economia a cada execução, e a conta só fecha depois de um número mínimo de execuções. Brown e Hellerstein formalizam isso no artigo da IBM. Para eles, a automação compensa quando o número de execuções ao longo da vida do processo supera o custo adicional de construí-la dividido pela economia por execução.

O artigo chama de dificuldade de generalização a razão entre o custo de automatizar e o custo de uma execução manual. Cada variante do processo exige regra, teste e tratamento de erro próprios. Essa leitura é nossa, não do artigo: quanto mais variantes, maior o custo de construir, e menos execuções cada uma recebe para pagar a conta.

## O que a IBM mediu ao automatizar na prática?

Os autores partem de uma frase que vale como aviso: a automação não necessariamente reduz o custo das operações. Eles apontam três motivos. Implantar e manter a infraestrutura de automação dá trabalho. Entradas estruturadas exigem projeto e teste antes. E detectar e corrigir erros é mais difícil num processo automatizado do que num manual.

O caso que usam é a distribuição de software em data centers. Dos pacotes construídos, 25% foram instalados em menos de 15 servidores ao longo da vida. Dos pedidos de instalação, 19% terminaram em falha. Com custos estimados por eles, o ponto de equilíbrio ficaria entre 5 e 20 servidores, e daí sai a conclusão de que de 15% a 30% das instalações não deveriam ter sido automatizadas.

Há dois limites a declarar. O ponto de equilíbrio vem de faixas de custo estimadas pelos autores, não de uma análise completa de dados, então vale como ordem de grandeza. E o contexto é operação de TI em 2005, longe de uma PME. O que se aproveita é o método de conta, não os percentuais.

## O que são variantes de processo e por que a cauda é longa?

Variante é cada caminho diferente que um caso percorre no processo. O pedido que segue direto, o que volta para correção e o que pede aprovação extra são três variantes do mesmo processo.

Fischer, Hofmann, Imgrund, Janiesch e Winkelmann estudaram quatro registros de execução de processos (atendimento de TI, pedidos de empréstimo em dois períodos e licenças de obra) de três organizações holandesas, duas financeiras e um órgão público. Dividiram as variantes em uma cabeça, com os 20% de pontuação mais alta no conjunto dos indicadores, e uma cauda, com o resto. A cauda respondeu por cerca de dois terços dos valores dos indicadores que eles calcularam, e suas variantes tinham menos contatos com o cliente, menos execuções e mais partes envolvidas.

A conclusão dos autores não é ignorar a cauda. É tratá-la de outro jeito: gerir os processos principais de forma central e melhorar a maioria aos poucos, onde ela é executada. A leitura para automação é nossa. Variante com poucas execuções e muitas partes envolvidas tem pouco volume e custo de construção alto, a pior combinação para o ponto de equilíbrio. Os dados são de três organizações holandesas, sem recorte de PME.

## O que sobra para as pessoas depois da automação?

Sobra o que o projeto não cobriu, e costuma ser o mais difícil. Em 1983, Lisanne Bainbridge escreveu na *Automatica* que a automação pode ampliar em vez de eliminar os problemas do operador humano. Segundo ela, o projetista ainda deixa para o operador as tarefas que não soube como automatizar, e o operador acaba com uma coleção arbitrária de tarefas.

O texto trata de controle de processos industriais, e a aplicação é nossa. Numa operação de escritório, a cauda que ficou fora da automação vira essa coleção arbitrária quando ninguém desenhou a rota: cada pessoa resolve do seu jeito, em planilha própria, e o caso não entra em nenhuma contagem.

## Como contar variantes e volume antes de aprovar o escopo?

Este é um procedimento que propomos, não um método dos estudos citados. Comece pelos casos reais, não pelo fluxograma do processo. Pegue três meses de casos e agrupe por caminho percorrido. Conte quantos casos cada variante teve e quantos minutos cada execução manual consome.

Em seguida, estime o custo de construir cada variante em horas e divida pelas horas que ela economiza por mês. O resultado é o payback em meses, variante por variante, e não um número único para o processo. O [cálculo de ROI da automação](/blog/roi-automacao-de-processos) funciona melhor assim, porque o número médio esconde a variante que nunca se paga.

Depois, divida em três grupos. O núcleo frequente e estável se automatiza. O meio-termo depende de a regra mudar ou não. A cauda recebe uma rota manual desenhada, com dono e registro no mesmo sistema, para que cada caso continue contando. Medir o payback depende desse registro, tema de [medir o ROI de automação sem um sistema de registro](/blog/roi-de-automacao-sem-sistema-de-registro). Onde fica a fronteira entre manual e automático é assunto de [quando manter processos manuais e automação juntos](/blog/quando-faz-sentido-manter-processos-manuais-e-automacao-juntos).

Decidir o que entra na automação é uma decisão de arquitetura, não de ferramenta. A contagem de variantes é trabalho de quem conhece o processo por dentro, e essa inteligência, a natural, vem antes de qualquer máquina.

## Um exemplo prático: endossos numa corretora de seguros

O cenário é hipotético e os números são premissas ilustrativas, não medições. Uma corretora de seguros com 35 pessoas processa 600 endossos por mês, e cada um consome 12 minutos de trabalho manual. Ao agrupar três meses de casos, a corretora encontra 1.800 endossos e 14 variantes.

As três maiores concentram 1.260 casos, 70% do total. As outras 11 dividem 540 casos, com a maior em 90 e a menor em 8. Suponha, por simplicidade, 40 horas para automatizar cada variante. Se as da cauda custarem mais, como sugere o estudo de Fischer e colegas ao apontar mais partes envolvidas, o payback piora ainda mais.

Nas três maiores, são 420 casos por mês, ou 84 horas economizadas contra 120 horas de construção. O retorno vem em cerca de um mês e meio. Numa variante de 90 casos no trimestre, são 30 por mês, 6 horas economizadas e retorno em cerca de sete meses. Na de 8 casos, são menos de 3 por mês, cerca de 30 minutos economizados, e o retorno leva 75 meses, mais de seis anos.

As 11 variantes juntas custariam 440 horas para economizar 36 horas por mês, um retorno médio de cerca de 12 meses. A média parece aceitável e esconde a variante que nunca se paga. Isso vale ainda mais se a regra de uma variante mudar antes de o payback chegar, porque a automação passa a custar manutenção sem devolver horas.

Esse tipo de contagem exige um registro estruturado do caminho de cada caso. No [case da Repap On](/cases/repap-on), empresa em que a Yowpi tem participação societária, como o próprio case informa, a plataforma de gestão documental nasceu de uma consultoria de processos, e o mapeamento do processo é o ponto de partida do sistema.

## Perguntas frequentes

**Não sei se automação tem retorno financeiro. Como saber antes de contratar?**

Estime, por variante, as execuções por mês, os minutos de cada execução e as horas para construir. Se você não consegue preencher esses três números, a etapa certa ainda é medir. O artigo da IBM lembra que automação não necessariamente reduz custo, e a conta por variante mostra onde ela reduz.

**Minha equipe está acostumada com planilhas. A cauda que fica manual continua na planilha?**

Não precisa continuar. O que fica manual deve ter uma rota desenhada e um registro no mesmo sistema da parte automatizada. A planilha paralela é o que torna a cauda invisível, e uma cauda invisível não entra na próxima decisão de escopo.

**Não tenho equipe qualificada para implementar. Quem faz esse levantamento?**

O levantamento de casos e variantes é trabalho de quem opera o processo, e uma planilha basta. A construção é a parte que exige engenharia, e é nela que entra um parceiro de engenharia. A decisão sobre o que entra no escopo continua sendo sua, e a contagem é o que a sustenta.

## O próximo passo

Se você tem um processo candidato à automação e ainda não sabe quantas variantes ele tem, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para mapear com você onde estão as variantes e o volume antes de qualquer decisão de escopo. Se fizer sentido para o seu caso, [fale com a Yowpi](/contato).