Como saber se a automação está funcionando depois que entra no ar

A automação do faturamento roda desde março e ninguém reclama. Em outubro alguém percebe que um grupo de pedidos nunca virou nota, e que isso vem acontecendo há semanas. O fluxo não parou, não deu erro, não disparou alerta. Ele simplesmente deixou de fora os casos que não se encaixavam na regra e seguiu em frente. Quem pergunta como saber se a automação está funcionando quase sempre pergunta depois de um episódio assim, e descobre que a resposta que valia até ali era frágil: ninguém reclamou, então estava funcionando.

Aí está a parte difícil. Automação quebrada é fácil de ver, porque alguém liga avisando que o sistema caiu. Automação que funciona errado é invisível por construção. Ela produz um resultado plausível, no prazo, no formato esperado, e esse resultado entra na operação sem ser conferido justamente porque a conferência era o trabalho manual que foi eliminado. O ganho de tempo e a perda de visibilidade vêm do mesmo lugar.

O erro que não aparece é o que passou pelo caminho certo

Existem dois tipos de falha num fluxo automatizado, e eles pedem resposta diferente. A primeira é a interrupção: a integração caiu, o arquivo não chegou, a credencial venceu. Essa dói rápido, aparece no mesmo dia e tende a ser resolvida, porque a operação para.

A segunda é a que importa aqui. O fluxo rodou até o fim e tratou um caso como se fosse outro. O cadastro tinha duas unidades e ele considerou uma. O pedido tinha desconto condicionado e ele aplicou o padrão. O registro chegou sem a informação que decide a classificação e ele usou o valor preenchido por último. Nada disso é erro técnico. É uma decisão tomada por uma regra que não previa aquele caso, e registrada como sucesso.

Por isso monitorar execução não responde à pergunta. Um painel que mostra que o processo rodou todos os dias, no horário, sem exceção registrada, é compatível com dois cenários opostos: o fluxo está correto, ou o fluxo está errado e nunca percebeu. A informação que separa um do outro não está no log de execução.

A exceção não é defeito do fluxo, é a medida dele

Na maioria dos projetos a exceção é tratada como o que sobrou. O mapeamento desenha o caminho principal, a regra cobre o que é frequente, e o que não se encaixa vai para uma condição final que registra o caso e segue. Funciona no primeiro mês, enquanto quem construiu o fluxo ainda olha o que saiu dele.

O que se perde nessa escolha é o melhor indicador que o processo tem. O volume de exceções, lido ao longo do tempo, diz coisas que nenhuma outra medida diz. Se ele cresce, a regra está envelhecendo em relação à operação real. Se ele é estável e alto, o processo nunca foi padronizado, foi apenas automatizado na parte padronizável. Se ele é zero, a suspeita correta não é que está tudo certo: é que o fluxo está classificando como normal aquilo que deveria estar separando.

Medir exceção exige uma decisão que parece burocrática e é a mais importante do projeto: definir, antes de automatizar, qual caso o fluxo tem permissão para resolver sozinho e qual caso ele é obrigado a devolver. Sem essa linha escrita, cada ajuste de regra amplia o território do automático sem que ninguém decida isso de propósito.

Quem recebe a exceção precisa ter nome

Exceção registrada em relatório que ninguém abre é exceção perdida. Essa é a falha de desenho mais comum, e ela não é técnica, é de responsabilidade. O fluxo foi construído para separar o caso difícil, fez isso corretamente, e o caso difícil ficou parado numa fila sem dono.

A pergunta prática é curta e costuma não ter resposta na empresa: quando o fluxo devolve um caso, para quem ele vai, em quanto tempo essa pessoa precisa olhar, e o que acontece se ela não olhar. Enquanto as três respostas não existirem por escrito, a automação transferiu o trabalho de execução para a máquina e deixou o trabalho de decisão sem lugar.

Vale notar o que isso muda na escolha da ferramenta. Fila com dono, prazo e escalonamento é requisito de processo, não recurso de produto. Ferramenta nenhuma decide quem responde pelo caso que ela não soube tratar.

O controle que prova que o fluxo rodou

Alerta avisa que algo quebrou. Ele não prova que o que não quebrou está certo. Para isso serve outra coisa, e ela vem da controladoria, não da tecnologia: uma conciliação.

A ideia é simples de descrever e dá trabalho de montar. Escolhe-se uma contagem que o fluxo não controla e compara-se com o resultado dele. Pedidos faturados contra pedidos elegíveis no período. Lançamentos gerados contra documentos recebidos. Títulos baixados contra créditos no extrato. O valor da conciliação não está em acusar a diferença grande, que alguém acabaria notando. Está em tornar visível a diferença pequena e constante, que é exatamente a assinatura da falha silenciosa.

Esse controle tem outra vantagem. Ele é independente de quem construiu a automação. Um fluxo conferido pela própria regra que o define não está sendo conferido, está sendo repetido.

O que isso deixa na empresa

Automação não termina quando entra no ar. Ela passa a ser um processo que precisa dos mesmos elementos de qualquer processo controlado: uma decisão escrita sobre o que ela pode resolver sozinha, uma fila com dono para o que ela devolve, e uma conferência externa que não depende dela. Com os três, a pergunta sobre estar funcionando tem resposta em dado. Sem eles, a resposta continua sendo a ausência de reclamação, que não é informação.

Esse é o mesmo ponto que separa o projeto de automação que se sustenta do que foi abandonado depois de alguns meses, assunto de por que a automação de processos falhou, e não foi a ferramenta. É nessa camada, entre o desenho do processo e o controle que o acompanha, que trabalha a Zyon Flux.