Peter Drucker deixou-nos uma frase que continua a ser das mais desconfortáveis da gestão: não há nada tão inútil como fazer com grande eficiência aquilo que não deveria ser feito de todo. Lembro-me dela sempre que me sento com um empresário que quer avançar para a inteligência artificial e me apresenta, com entusiasmo genuíno, a lista das cinco coisas que quer automatizar já.
O entusiasmo é bom sinal. O problema é que, nessa lista, raramente está em primeiro lugar aquilo que deveria estar. E a escolha do primeiro projeto não é um detalhe — é, na minha experiência, o fator que mais determina se uma empresa continua este caminho ou se desiste dele ao fim de dois meses, convencida de que “aquilo não era para nós”.
O primeiro projeto não é o mais importante — é o que gera confiança
Há aqui uma inversão de lógica que custa a aceitar a quem está habituado a priorizar por impacto. O primeiro processo a automatizar não deve ser o mais crítico do negócio, nem o mais complexo, nem sequer o mais valioso. Deve ser aquele que tem maior probabilidade de correr bem.
A razão é simples e é humana, não técnica. Uma equipa que vê um processo automatizado a funcionar bem no primeiro mês passa a estar disponível para o segundo e o terceiro. Uma equipa que assiste a um projeto ambicioso a arrastar-se durante seis meses aprende, e com razão, que isto “dá muito trabalho e não resolve nada”. A confiança interna é o verdadeiro ativo que se constrói no primeiro projeto. Tudo o resto vem depois.
Cinco critérios que uso para escolher
Quando avalio candidatos a primeiro projeto numa PME, olho sempre para os mesmos cinco pontos.
A frequência, antes do tamanho. Uma tarefa que consome quinze minutos por dia vale mais como candidata do que uma que consome três dias, mas apenas duas vezes por ano. O retorno acumula-se, e o hábito instala-se mais depressa.
A existência de regras claras. Se o processo é executado hoje por uma pessoa que segue critérios que consegue explicar em voz alta, é bom candidato. Se depende de “sensibilidade”, de contexto acumulado ou de julgamento sobre casos que nunca se repetem, deixe-o para mais tarde. Não porque a IA não consiga ajudar, mas porque não é aí que se começa.
A tolerância ao erro. Pergunto sempre o que acontece se o resultado sair errado uma vez em cada vinte. Se a resposta for “alguém corrige em dois minutos”, avançamos. Se for “perdemos o cliente” ou “temos um problema legal”, esse processo não é um primeiro projeto — é um terceiro ou quarto, quando já houver rotina de validação instalada.
A existência de um dono. Todo o processo automatizado precisa de alguém que o conheça, o valide e reclame quando falha. Um processo que hoje não tem dono claro dentro da empresa não passa a ter um só porque foi automatizado. Passa a ter um problema sem responsável.
A capacidade de medir. Se não conseguirmos dizer, antes de começar, quantas horas por semana aquilo consome ou quantos erros gera por mês, não vamos conseguir demonstrar depois que valeu a pena. E um projeto que não se consegue demonstrar dificilmente ganha o segundo.
O que costuma ficar de fora — e porquê
Há três tipos de processo que, por norma, aconselho a adiar. Os que envolvem dados sensíveis sem que a empresa tenha ainda uma política clara sobre que informação pode circular por onde. Os que dependem de sistemas antigos, mal documentados, onde o esforço de integração consome todo o benefício. E os que a equipa já detesta por outras razões — porque nesses casos a automação vira o bode expiatório de um problema que é anterior e é organizacional.
Este último ponto merece um parágrafo próprio. Automatizar um processo mau não o torna bom. Torna-o rápido, o que é frequentemente pior. Antes de qualquer decisão tecnológica, vale a pena a pergunta antiga de Drucker: isto devia sequer estar a ser feito?
O teste que costumo propor
Se tiver de escolher hoje, sem consultores e sem análises longas, proponho um exercício simples. Peça a cada pessoa da equipa que aponte a tarefa que faz todas as semanas e que mais gostaria de deixar de fazer. Cruze as respostas. O que aparecer repetido, for explicável por regras e não puser em risco nenhum cliente se falhar uma vez — é por aí que se começa.
Não é a escolha mais ambiciosa. É a que tem maior probabilidade de ainda estar a funcionar daqui a um ano, e de ter aberto a porta a todas as outras.
E é essa, no fundo, a decisão que só quem lidera pode tomar: não a de escolher a ferramenta, mas a de escolher o problema.
Ajudamos PME’s a fazer exatamente esta escolha antes de escrever uma linha de configuração. Fazemos por si o que já fizemos por nós.
