Imaginem um processo em que um pedido entra, é classificado e segue automaticamente para a equipa responsável. Durante uma demonstração, tudo funciona com rapidez. Depois surge um caso que não cabe nas opções previstas. O sistema continua ativo, mas ninguém sabe quem deve apreciar a exceção. Nesta situação construída, a tarefa foi automatizada sem que a responsabilidade pelo que fica de fora tivesse sido suficientemente organizada.
Quando observo uma proposta de automação, quero perceber esse percurso. A redução de trabalho repetitivo pode ser útil, mas o processo continua a precisar de alguém capaz de compreender uma ocorrência, tomar uma decisão e explicar o resultado. Automatizar não retira importância à responsabilidade humana. Pode tornar ainda mais necessário definir onde ela começa, que informação recebe e que autoridade tem para agir.
Não defendo que cada ocorrência exija uma intervenção individual. Isso poderia eliminar a utilidade da própria automação. Defendo que as situações que pedem julgamento tenham um caminho preparado. A pergunta não é apenas se o sistema consegue executar uma tarefa. É o que acontece quando não consegue, quando a informação é insuficiente ou quando a execução produz um resultado que precisa de ser revisto.
O caso habitual não explica o processo inteiro
Uma demonstração tende a escolher um percurso compreensível, com informação organizada e um resultado esperado. É uma forma legítima de apresentar uma capacidade. Contudo, a decisão de a utilizar precisa de examinar outras condições. Que dados podem faltar? Que respostas podem ser ambíguas? Que parte do trabalho depende de uma confirmação externa? Estas perguntas ajudam a perceber os limites da utilização proposta.
Num exemplo hipotético de encaminhamento de pedidos, uma classificação pode estar correta e o destino não ter condições para responder. A automação realizou a sua função imediata, mas a necessidade da pessoa continua aberta. Se o processo considera concluído tudo o que foi encaminhado, a informação de acompanhamento pode esconder esse intervalo. É importante distinguir a execução da etapa da resolução do assunto que motivou o pedido.
Por isso, procuraria definir estados com significado operacional. Recebido, encaminhado, em apreciação e resolvido não precisam de ser nomes obrigatórios, mas devem representar condições diferentes. Quem consulta o registo deve conseguir perceber o que já aconteceu e o que ainda falta. Uma indicação de atividade técnica não pode ocupar o lugar de uma confirmação que depende do trabalho de outra pessoa ou de outra organização.
Uma exceção precisa de informação suficiente
Quando um caso chega a uma pessoa, importa que ela consiga compreender por que motivo foi encaminhado e que tentativas já aconteceram. Sem essa informação, a intervenção humana começa por reconstruir um percurso que o sistema podia ter preservado. O trabalho repetitivo pode ter sido reduzido numa etapa e reaparecer como investigação manual na seguinte. A avaliação da automação precisa de considerar esta transferência de esforço.
A informação deve ser proporcional à tarefa e respeitar o âmbito em que pode ser utilizada. Não é necessário expor todos os dados a todas as pessoas para tornar o processo compreensível. É necessário identificar o que quem decide precisa de saber, que limites existem e como pode obter uma informação adicional quando ela é indispensável. A clareza de responsabilidade também ajuda a delimitar o acesso.
O destinatário da exceção precisa igualmente de mandato. Receber uma notificação não significa ter autoridade para corrigir o problema ou assumir um compromisso em nome de outra área. Se cada ocorrência chega a alguém que só consegue reenviá-la, a automação pode acelerar a circulação da dificuldade sem aproximar a decisão. O percurso deve encontrar quem consegue agir ou quem tem responsabilidade por obter essa decisão.
Repetir uma tentativa exige conhecer o estado anterior
Uma falha de comunicação pode deixar um resultado incerto. Nessa situação, repetir a ação sem verificar o que aconteceu pode produzir duplicação. O princípio de gestão é simples: antes de tentar novamente, precisamos de compreender se a primeira execução falhou, se foi concluída ou se ainda não existe informação suficiente. A forma técnica dessa verificação depende do processo e deve ser preparada por quem o implementa.
Num exemplo construído de criação de um registo, a ausência de resposta imediata não demonstra que o registo não foi criado. Uma pessoa que recebe a exceção precisa de um caminho para consultar o estado, reconhecer uma execução anterior e decidir se pode repetir. O objetivo não é prometer que nunca haverá falhas. É impedir que a recuperação seja baseada apenas na impaciência perante uma resposta em falta.
A objeção habitual é que preparar tantos percursos torna uma automação simples demasiado complexa. A objeção é válida quando se tenta antecipar todas as possibilidades com o mesmo detalhe. O cuidado deve acompanhar as consequências da ação. Um aviso interno reversível e um compromisso externo exigem níveis diferentes de confirmação. O essencial é identificar os casos em que a repetição ou a omissão teria consequências relevantes.
A utilização precisa de ensinar alguma coisa à equipa
O acompanhamento não deve limitar-se a contar tarefas processadas. Pode observar que exceções surgem, quanto trabalho exigem e se chegam à pessoa adequada. Uma regra que envia muitos casos semelhantes para apreciação pode precisar de ajuste. Uma regra que nunca apresenta exceções também merece atenção, se não existir uma forma de perceber quando produziu uma resposta inadequada. O silêncio do processo não demonstra, por si só, qualidade.
As pessoas que recebem as ocorrências devem conseguir devolver aprendizagem a quem mantém a automação. Que informação faltou? Que decisão se repetiu? Que tipo de caso deveria ter sido reconhecido antes? Esta conversa aproxima a implementação da utilização real. Sem ela, o sistema pode continuar a executar a versão inicial de uma tarefa que a organização já aprendeu a compreender de outra maneira.
É importante, por fim, saber como interromper uma utilização que deixou de oferecer condições suficientes. A responsabilidade não termina na aprovação inicial de uma ferramenta. Alguém deve acompanhar o seu alcance, reconhecer uma alteração relevante e decidir quando é necessário rever o processo. Esta atenção não elimina a autonomia da operação. Dá-lhe um limite compreensível e uma possibilidade de correção antes de a dificuldade se acumular.
Quero uma automação que liberte atenção e entregue as dúvidas a quem pode tratá-las. O valor não está apenas no percurso que corre sozinho, mas na qualidade da passagem quando esse percurso encontra um limite. Se sabemos quem recebe a exceção, que informação acompanha o caso e quem confirma a resolução, a tecnologia passa a fazer parte de uma organização capaz de responder pelo que faz.
Lucas Atanazio é empresário e fundador da ATNZO.