Quando um processo complexo é automatizado, a complexidade não desaparece; ela apenas muda de escala e velocidade. Um critério ambíguo aplicado por uma pessoa produz decisões inconsistentes que alguém eventualmente percebe; o mesmo critério ambíguo aplicado por um sistema produz milhares de decisões consistentemente erradas antes que alguém perceba.
Essa mudança de escala é o que torna a automatização de um processo ruim pior do que deixá-lo como estava, e não apenas igual.
O erro deixa de ser detectável por contraste. Em um processo manual, a variabilidade entre pessoas funciona como um sistema de alarme: quando alguém resolve um caso de forma diferente, a diferença é discutida e a abordagem é corrigida. A automação elimina essa variabilidade e, com ela, o sinal de alerta.
A correção deixa de ser pontual. Descobrir um erro três semanas depois não significa corrigir o caso; significa revisar e refazer tudo o que foi processado durante essas três semanas. O custo de reverter o erro aumenta linearmente com o tempo de detecção.
As exceções são multiplicações em vez de decrescimentos. Um processo mal definido gera casos que não se encaixam. Mesmo quando automatizados, esses casos continuam chegando e agora exigem tratamento manual fora do fluxo de trabalho, o que frequentemente resulta em mais trabalho do que antes.
A responsabilidade torna-se confusa. Quando um caso é tratado incorretamente, a resposta se torna "o sistema fez isso". E essa não é uma resposta útil para um cliente ou um auditor, como ficou claro no caso do chatbot da Air Canada resolvido em 2024: a empresa é responsável pelo que seu software faz.
Momento | O que é observado | O que está realmente acontecendo? |
|---|---|---|
Semanas 1-2 | Tudo está funcionando, há entusiasmo. | Os casos simples são processados. |
Semanas 3-6 | Casos "raros" aparecem« | Surgem exceções não planejadas |
Meses 2 a 4 | O trabalho manual paralelo está crescendo. | O processo se bifurcou. |
Meses 4-6 | Foi detectado um erro sistemático. | Os dados históricos precisam ser revistos. |
A sequência é tão repetitiva que serve como ferramenta de diagnóstico. Se um projeto de automação funciona bem nas primeiras semanas e, em seguida, começa a gerar trabalho paralelo no segundo mês, o problema não está na implementação: está no fato de o processo não ter sido definido no momento da automação.
Existe uma verificação preliminar que leva uma tarde e previne a maioria desses casos: Apresente o mesmo conjunto de vinte casos reais a três pessoas diferentes da equipe e compare as decisões delas..
Se os três critérios concordarem em dezoito ou mais, o processo está suficientemente bem definido para ser automatizado. Se concordarem em doze, não há processo: existem três critérios coexistindo, e a automação significa escolher um dos três sem informar ninguém.
Este exercício também possui uma virtude política: transforma uma discussão abstrata sobre a maturidade dos processos em um fato indiscutível.
Descobrir que um processo não está pronto não significa que você precise adiar tudo por seis meses. Existem três intervenções que geram valor rapidamente:
Defina os critérios para os casos frequentes. Nem todas: a seção 80% do volume geralmente se concentra em quatro ou cinco situações. Anotar os critérios para essas cinco situações resolve a maior parte da ambiguidade em uma sessão de trabalho.
Automatize apenas a preparação. Reúna as informações, compare-as e apresente-as de forma que a pessoa possa tomar uma decisão. Isso permite economizar uma quantia significativa e evita a disseminação de informações incorretas.
Instrumentar antes de automatizar. A medição do processo manual ao longo de algumas semanas produz a linha de base e revela a variabilidade real, que é exatamente a informação que faltava para tomar uma decisão.
Os três são compatíveis para seguir em frente. Nenhum deles exige um projeto de reformulação completo antes de qualquer alteração.
É importante quantificar a perda, pois é esse fator que transforma um projeto lucrativo em um fracasso.
Se um sistema processa duzentos casos diariamente e um erro sistemático é detectado após seis semanas, há aproximadamente seis mil casos para revisar. Mesmo que apenas o caso 10% seja afetado, isso representa seiscentos casos para corrigir, além da comunicação com o cliente, ajustes contábeis e impacto na reputação.
Esse cálculo quase nunca aparece na análise de viabilidade do negócio, e é por isso que o tempo até a falha deve ser uma métrica do comitê, como argumentamos em A automação sem observabilidade é irresponsável.
Antes de automatizar qualquer processo, há uma pergunta que orienta a decisão: Se isso estiver sistematicamente errado, quando descobriríamos e quanto custaria desfazer o erro?
Se a resposta for "em horas e com um clique", o risco de automatizar um processo imperfeito é aceitável e vale a pena prosseguir. Se a resposta for "em semanas, e teríamos que revisar os dados históricos", o processo precisa ser definido antes de ser automatizado.
Não é uma questão de prudência. É aritmética.
A desordem muda de escala: um critério ambíguo aplicado por uma pessoa produz decisões inconsistentes que alguém eventualmente percebe, enquanto que, aplicado por um sistema, produz milhares de decisões consistentemente erradas antes que alguém o detecte.
Porque a variabilidade individual funciona como um sistema de alarme: quando alguém resolve um caso de forma diferente, a diferença é discutida e a abordagem é corrigida. A automação elimina essa variabilidade e, com ela, o sinal que permitia a detecção do problema.
Ao apresentar o mesmo conjunto de vinte casos reais a três pessoas da equipe e comparar suas decisões, o processo é definido caso haja concordância em dezoito ou mais casos; caso haja concordância em doze, vários critérios diferentes coexistem, e a automação consiste em escolher um deles sem a necessidade de uma decisão explícita.
Três coisas compatíveis com o avanço: definir os critérios para os quatro ou cinco casos que concentram o volume 80%, automatizar apenas a preparação das informações, deixando a decisão para uma pessoa, e implementar o processo manual por algumas semanas para obter a linha de base.
O volume de trabalho aumenta com o tempo de detecção. Um sistema que processa duzentos casos diariamente, com uma falha detectada após seis semanas, implica na revisão de cerca de seis mil casos; mesmo que apenas o sistema 10% seja afetado, isso representa seiscentas correções, com a respectiva comunicação ao cliente e o ajuste contábil.
Se o sistema cometer erros sistemáticos, quando eles seriam detectados e qual seria o custo para corrigi-los? Se a resposta for "em poucas horas e com um único clique", o risco é aceitável; se levar semanas e exigir a revisão de dados históricos, o processo precisa ser definido antes de ser automatizado.
Seu processo está pronto para ser automatizado? Testamos com casos reais antes de escrever uma única linha de código e informamos qual parte deve ser automatizada e qual deve ser definida primeiro. Vamos conversar →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
