Por que a automação de processos falhou, e não foi a ferramenta

A empresa contratou a ferramenta, pagou a implantação e treinou o time. Meses depois o processo voltou a ser feito na mão. Ou, pior, é feito nos dois lugares ao mesmo tempo: alguém lança no sistema e alguém confere na planilha, por garantia. Quando o assunto volta para a reunião de diretoria, a conclusão costuma ser a mesma, a ferramenta não serviu. Quem pesquisa por que a automação de processos falhou geralmente já está nesse ponto, decidindo se troca de fornecedor ou se abandona o projeto.

A resposta fácil é culpar o software. Ela é confortável porque coloca o problema do lado de fora. E costuma estar errada. Na maioria dos casos a ferramenta fez exatamente o que foi contratada para fazer. O que não existia era o processo que ela deveria executar.

Automatizar não corrige, amplia

Um processo manual ruim tem um amortecedor embutido, que é a pessoa. Quando o pedido chega com o dado errado, ela percebe, liga para o cliente e corrige antes de seguir. Esse conserto não está escrito em lugar nenhum. Não aparece no fluxograma, não entra no custo, não vira indicador. Ele apenas acontece, todos os dias, e mantém o processo de pé.

Quando o fluxo é automatizado, esse amortecedor sai. O dado errado passa. Passa rápido e passa sempre. O que antes era um caso isolado, resolvido por quem conhecia o cliente, vira um problema de escala que ninguém vê acontecer. A automação não criou o erro. Ela removeu o único controle que existia sobre ele.

Por isso a pergunta útil, depois de um projeto que não entregou, não é qual ferramenta trocar. É o que a ferramenta passou a executar que antes era decidido por alguém.

Três falhas diferentes que se parecem por fora

Visto de longe, todo projeto de automação que não pegou parece a mesma coisa: o time voltou a fazer na mão. Por dentro, são causas distintas, e cada uma pede uma correção diferente.

O processo nunca foi definido, foi descrito

O fluxo foi automatizado do jeito que o time contou na reunião, não do jeito que ele acontece. São coisas diferentes. A descrição é a versão limpa, a que a pessoa lembra. A execução real tem passos que ninguém menciona porque já viraram hábito, e tem decisões que mudam conforme quem está fazendo. Automatizar a descrição produz um fluxo que funciona no caso ideal e trava em todo o resto.

O sinal típico é a automação rodar bem nos primeiros dias e passar a acumular pendência conforme aparece caso fora do padrão.

A exceção não tinha caminho

Todo processo tem exceção. O cliente que paga fora do prazo combinado, a nota que precisa de ajuste, o pedido que sai do padrão por decisão comercial. Um fluxo automatizado precisa de rota explícita para esses casos, com alguém do outro lado, prazo definido e registro do que foi decidido.

Quando essa rota não existe, a exceção vira travamento silencioso. O caso para em algum ponto do fluxo e ninguém é avisado, porque o sistema não considera aquilo um erro. A empresa descobre semanas depois, pelo cliente.

O sinal típico é o número de casos concluídos não fechar com o número de casos que entraram, sem ninguém saber dizer onde ficou a diferença.

Ninguém ficou dono do que roda sozinho

Processo manual tem dono por natureza, que é quem executa. Processo automatizado perde esse dono justamente no dia em que passa a rodar bem. A pessoa que fazia foi realocada. O fornecedor entregou e saiu. A TI cuida do ambiente, não da regra de negócio.

Então a regra muda, como toda regra muda, e o fluxo continua executando a versão antiga. Ele não quebra. Ele fica errado, que é pior, porque erro que não quebra não avisa.

O sinal típico é a automação funcionar e o resultado dela ter deixado de ser usado para decidir.

Como descobrir qual das três foi

O diagnóstico não exige ferramenta nova. Exige comparar três coisas que a empresa já tem em algum lugar.

A primeira é o volume que entrou no processo e o volume que saiu completo, no mesmo período. A diferença é o tamanho real do problema, e já separa falha pontual de falha estrutural.

A segunda é a lista dos casos que não saíram. Ler alguns deles, um a um, revela o padrão. Se compartilham a mesma característica de negócio, o problema é exceção sem rota. Se são casos comuns que travaram por motivos variados, o problema é processo mal definido.

A terceira é a data da última vez que alguém revisou a regra que o fluxo executa. Se ninguém souber responder, o problema é de responsabilidade, e a correção é organizacional antes de ser técnica.

Esse levantamento leva poucos dias e responde à pergunta que a troca de fornecedor não responde.

O que isso muda na decisão

Trocar de ferramenta sem esse diagnóstico é repetir o projeto com outro nome. A empresa paga de novo pela implantação e recebe de volta o mesmo resultado, porque a causa continua onde estava.

Quando a falha é de definição, a correção é mapear a execução real antes de reconstruir o fluxo. Quando é de exceção, a correção é desenhar a rota alternativa e passar a medir quantos casos vão por ela. Quando é de responsabilidade, a correção é nomear quem responde pela regra e definir com que frequência ela é revisada. Nenhuma das três depende de comprar nada.

O que fica com a empresa

Um projeto de automação que não entregou é caro, mas é informativo. Ele expõe as decisões que estavam sendo tomadas por pessoas sem estar escritas em lugar nenhum. Essa lista é o ativo, e ela continua valendo qualquer que seja a ferramenta escolhida depois.

A ordem que funciona é a mesma de antes: entender o processo, medir, e só então automatizar. É o mesmo raciocínio de o que medir antes de automatizar um processo, aplicado agora a um fluxo que já existe e já falhou. É esse trabalho de processo, e não a escolha de plataforma, que sustenta o Zyon Flux.