Quantas variantes tem o processo que você vai automatizar?
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.
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 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. Onde fica a fronteira entre manual e automático é assunto de quando manter processos manuais e automação 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, 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.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico