Cinco erros que tornam caro um projeto de automação numa PME

Ao longo dos últimos anos vimos bastantes projetos de automação a correr mal. Quase nenhum falhou por a tecnologia não funcionar. Falharam por decisões tomadas antes de existir uma única linha de configuração.

1. Automatizar um processo que devia ser eliminado

É o erro mais caro e o mais comum. Existe um relatório que alguém monta todas as semanas há quatro anos. É trabalhoso, portanto automatiza-se. Ninguém perguntou quem o lê — e a resposta, com frequência incómoda, é ninguém.

Antes de automatizar qualquer coisa, vale a pena a pergunta ingénua: o que acontece se deixarmos simplesmente de fazer isto? Uma parte surpreendente dos processos não sobrevive à pergunta. Automatizar desperdício produz desperdício mais rápido.

2. Começar pelo processo mais visível em vez do mais caro

O processo que mais irrita é raramente o que mais custa. Irrita porque é chato, ou porque é feito por quem tem voz na organização. O que custa é muitas vezes uma tarefa banal repetida cinquenta vezes por dia por alguém que nunca se queixou.

Medir antes de decidir resolve isto. Sem medição, a ordem das prioridades acaba a ser definida por quem reclama mais alto.

3. Não envolver quem executa o trabalho

A pessoa que faz a tarefa todos os dias sabe coisas que não estão em lado nenhum: as três exceções, o cliente que exige tratamento diferente, o passo que existe porque uma vez correu mal. Um projeto desenhado só com a chefia descobre estas exceções em produção, que é o pior momento possível.

Há ainda a questão política. Automação sem conversa lê-se como ameaça ao posto de trabalho, e a resistência passiva de quem conhece o processo é suficiente para inviabilizar qualquer sistema. Quando o objetivo é libertar tempo e não reduzir pessoas, isso tem de ser dito explicitamente e cedo.

Um sistema que a equipa não quer usar não é um sistema. É uma subscrição.

4. Automatizar o caos em vez de o arrumar primeiro

Se o processo atual tem quinze passos, seis dos quais existem para corrigir erros dos anteriores, automatizá-lo tal como está cristaliza o problema em código. Fica mais rápido e muito mais difícil de mudar.

A sequência correta é simplificar, depois estabilizar, só depois automatizar. Um processo com sete passos claros automatiza-se em metade do tempo e parte-se muito menos vezes.

5. Não prever o que acontece quando falhar

Toda a automação falha alguma vez: a API muda, o fornecedor tem uma interrupção, alguém altera um campo. A pergunta não é se falha, é quanto tempo passa até alguém dar por isso.

Sem monitorização, a resposta costuma ser "quando o cliente reclamou". Toda a automação deve ter alerta em caso de falha, repetição automática para erros temporários e um caminho manual documentado para quando nada disso resolver.

A lista de verificação antes de começar

1. Este processo precisa mesmo de existir?
2. Quanto custa por ano, em euros, medido e não estimado?
3. Falámos com quem o executa e conhecemos as exceções?
4. O processo pode ser simplificado antes de ser automatizado?
5. Como saberemos que falhou, e em quanto tempo?
6. Quem fica responsável por isto daqui a um ano?

Seis perguntas. Se alguma não tiver resposta clara, o projeto ainda não está pronto para começar — e adiar uma semana custa muito menos do que corrigir depois.