Comece pelo trabalho, não pelo anúncio. Quando uma empresa apresenta uma nova ferramenta
sem explicar qual problema resolve, as equipas ouvem mais uma tarefa a acrescentar. A
resistência cresce. Pessoas que já lidam com prazos, clientes e sistemas incompletos
passam a criar atalhos, manter ficheiros paralelos e evitar o novo fluxo sempre que a
pressão aumenta. O problema não é falta de vontade. É falta de clareza, tempo e
confiança na decisão. Observe uma jornada completa antes de definir o plano. Acompanhe
como um pedido entra, quem o valida, onde espera e como é encerrado. Registe as dúvidas
que surgem, os dados consultados e as tarefas repetidas. Depois, descreva a mudança numa
frase concreta: que passo desaparece, que passo muda e quem continua responsável pela
decisão. Evite dizer apenas que a empresa vai “trabalhar de forma mais inteligente”.
Explique que uma equipa passará a receber uma fila priorizada, que um relatório será
atualizado a partir de uma fonte comum ou que uma classificação terá revisão antes de
seguir. A descrição precisa de corresponder ao dia de trabalho. Crie um mapa de funções
com quatro pontos: responsável pela entrada, pessoa que verifica, utilizador do
resultado e responsável por corrigir falhas. Em empresas pequenas, uma pessoa pode
assumir mais de um papel, mas isso deve ficar visível. A adoção também exige espaço para
dúvidas. Reserve sessões curtas junto do processo, recolha exemplos reais e registe
perguntas que ainda não têm resposta. O custo é evidente: durante algum tempo, a equipa
trabalha com dois métodos enquanto compara os resultados. Esconder esse período só cria
frustração. Uma mudança bem desenhada não promete eliminar o esforço. Mostra onde o
esforço muda e por que razão vale a pena testar.
Teste com pessoas que conhecem o processo. Um grupo criado apenas por quem desenhou a
solução tende a confirmar pressupostos que o trabalho diário desmente. Inclua
utilizadores de funções diferentes, níveis de experiência diversos e alguém que possa
contestar a sequência sem receio. Dê-lhes um cenário realista, uma tarefa clara e um
prazo razoável. Observe onde hesitam, que informação procuram e que decisão tomam quando
o sistema apresenta uma exceção. Não corrija tudo durante o teste. Primeiro, registe o
comportamento. Uma dificuldade pode estar na interface, mas também pode revelar uma
regra confusa, um campo mal definido ou uma responsabilidade que nunca foi atribuída.
Organize o retorno em três grupos: bloqueio que impede a tarefa, atrito que aumenta o
tempo e preferência que não altera o resultado. Resolva primeiro os bloqueios. Esta
separação evita gastar energia a discutir detalhes enquanto um problema estrutural
permanece. Quando utilizar inteligência artificial para resumir, classificar ou sugerir
uma prioridade, mostre exemplos em que a saída é útil e outros em que falha. Explique
que a revisão humana faz parte do fluxo, não é uma punição para quem usa o sistema.
Defina uma forma simples de rejeitar uma sugestão, corrigir a informação e indicar a
causa. Sem esse caminho, as pessoas aprendem a aceitar o resultado ou a abandonar a
ferramenta. Meça o teste com indicadores que a equipa reconheça: tempo até concluir,
número de correções, pedidos de ajuda, tarefas abandonadas e frequência com que o fluxo
antigo é retomado. Não avalie apenas quantas pessoas abriram a aplicação. Uso sem
confiança não é adoção. A mudança pode reduzir um tipo de trabalho e criar outro, como
revisão, validação ou registo de exceções. Diga isso antes de começar. A honestidade
torna a avaliação mais útil e permite que você ajuste a capacidade necessária, em vez de
atribuir cada dificuldade a uma suposta falta de empenho.
A adoção precisa de acompanhamento depois do lançamento. Muitos projetos acabam quando a
ferramenta fica disponível, mas a verdadeira prova começa quando surge um pedido fora do
padrão ou quando a pessoa que conhecia o piloto deixa de estar presente. Crie um período
de observação com responsáveis definidos, horários para recolher dúvidas e uma lista de
problemas priorizados. Publique respostas curtas junto do fluxo de trabalho. Um
documento distante da operação raramente resolve uma dúvida no momento em que ela
aparece. Mantenha também uma versão simples das regras: qual fonte usar, quando rever
uma saída, quem aprova uma exceção e como comunicar uma falha. Atualize o registo quando
o processo mudar. Se as instruções ficam antigas, a equipa cria interpretações próprias
e a qualidade começa a variar. Acompanhe diferenças entre áreas, turnos e tipos de
tarefa. Uma média geral pode esconder que um grupo enfrenta mais erros ou precisa de
mais tempo para concluir o mesmo passo. Converse com essas pessoas antes de alterar a
ferramenta. Talvez falte acesso, contexto ou uma definição comum; talvez o processo não
seja adequado para aquele caso. Proteja quem levanta problemas. Se cada alerta for
tratado como oposição, os erros deixam de ser comunicados até causarem impacto maior.
Estabeleça um canal para contestar classificações, corrigir dados e suspender uma
automação quando houver sinais de falha. Registe a decisão e a causa para evitar
repetição. Reveja os efeitos ao fim de um período acordado: tempo de execução,
qualidade, carga de revisão, utilização real e incidentes. Se o custo de manter o fluxo
ultrapassar o valor observado, reduza o alcance ou retire a funcionalidade. Parar uma
abordagem que não serve também é uma decisão competente. A transformação sustentável não
depende de entusiasmo permanente. Depende de regras que sobrevivem à pressão,
responsáveis que respondem e dados que permitem ver o que mudou. Quer levar a mudança
para o trabalho real? Prepare a equipa.
