O projeto foi aprovado, o sistema foi construído, a entrega aconteceu. Três meses depois, metade da equipe ainda lança na planilha de sempre e só passa para o sistema no fim do mês, quando alguém cobra. O software funciona. A empresa não mudou.
Esse é o jeito mais comum de um projeto de software fracassar, e quase nunca tem a ver com o código. Tem a ver com adoção, que é a parte que ninguém coloca no orçamento.
A primeira coisa a entender: resistência quase nunca é preguiça. Quem contorna o sistema costuma estar sendo racional dentro da informação que tem. Antes de cobrar, vale descobrir qual dos motivos abaixo é o seu.
Motivo 1: o sistema pediu mais do que devolveu
Este é o mais comum e o mais ignorado. O sistema resolveu a vida da diretoria, que agora tem o número pronto, mas para quem digita ele só acrescentou campos obrigatórios.
Repare na assimetria: uma pessoa paga o custo, outra recebe o benefício. Ninguém sustenta isso por muito tempo só porque foi mandado.
A resposta não é cobrar mais. É devolver alguma coisa para quem alimenta. O vendedor que lança o pedido no sistema deveria ganhar dali a consulta de estoque que antes exigia um telefonema. Quem registra a ordem de serviço deveria ganhar o histórico do cliente na mesma tela. Quando alimentar o sistema economiza tempo de quem alimenta, a cobrança para de ser necessária.
Motivo 2: explicaram o como, não o porquê
O treinamento típico ensina onde clicar. Uma hora de tela, um passo a passo, e pronto. Ninguém explicou por que aquele campo existe.
A diferença aparece no primeiro caso fora do padrão. Quem só decorou o clique trava e volta para a planilha, onde sabe improvisar. Quem entendeu que o campo serve para o fechamento saber a qual obra o custo pertence consegue decidir sozinho o que fazer.
Custa quinze minutos a mais de conversa e muda o resultado: a equipe passa a resolver exceção em vez de fugir dela.
Motivo 3: o caminho antigo continuou aberto
Enquanto a planilha antiga estiver lá, em dia de correria ela vai ganhar. Não por má vontade, por atalho: ela é conhecida e não reclama de campo obrigatório.
Isso pede uma decisão de gestão, não uma conversa. Marque uma data de corte, avise com antecedência, e a partir dela a planilha vira consulta de histórico, somente leitura. Duas fontes convivendo é a receita para ninguém confiar em nenhuma das duas.
Uma ressalva importante: só faz sentido fechar a planilha quando o sistema já cobre o que ela cobria. Cortar antes disso não é firmeza, é criar um problema novo, e queima a confiança que você vai precisar depois.
Motivo 4: o primeiro erro ficou sem resposta
A equipe encontra um problema na segunda semana, avisa, e nada acontece por dez dias. Pronto. A conclusão que se forma no grupo é que o sistema não é confiável e o jeito é se virar por fora.
Adoção se decide nas primeiras semanas, e o que decide é a velocidade da resposta, não a ausência de problemas. Todo sistema novo tem ajuste. A diferença entre o que pega e o que morre está em quanto tempo o primeiro ajuste demorou a chegar.
O que funciona na prática
Comece por quem tem mais a ganhar. Escolha o setor onde o sistema tira mais trabalho manual. Quando ele começa a falar bem, os outros vêm sem empurrão.
Um processo por vez. Entrar com tudo ao mesmo tempo multiplica os pontos de atrito e você não descobre qual deles travou a adoção.
A diretoria pede o número no sistema. Se o dono continuar pedindo a planilha por WhatsApp, a planilha continua sendo o sistema oficial da empresa, independentemente do que foi contratado. Esse é o sinal mais forte que existe, e é de graça.
Meça uso, não opinião. Em reunião todo mundo diz que está usando. Quantos lançamentos entraram esta semana, quantos usuários distintos, quais telas ficaram vazias: isso mostra onde a adoção travou, e normalmente aponta para um dos quatro motivos acima.
O resumo honesto
Sistema não é entregue no dia da instalação. É entregue no dia em que a equipe prefere usá-lo a contornar.
Quem contrata um projeto deveria perguntar ao fornecedor, antes de assinar, o que ele faz nas primeiras semanas depois da entrega. Se a resposta for só treinamento e suporte por chamado, já dá para prever onde o projeto vai emperrar.