Diante das mudanças que sistemas novos impõem à rotina de quem trabalha, Rolando Bonaccorsi, engenheiro de computação com MBA executivo, argumenta que gestão de mudança explica mais fracassos de projeto do que qualquer falha de código. A entrega cumpre o escopo, passa nos testes e entra em produção. Seis meses depois, metade da operação continua resolvendo o trabalho na planilha antiga.
Projeto técnico bem feito não garante uso. Entre a disponibilidade de uma ferramenta e a mudança efetiva de comportamento existe um intervalo que nenhum cronograma de desenvolvimento cobre, porque depende de confiança, de hábito e de incentivo. Ignorar a distância é o erro mais caro e menos reconhecido da área, e também o mais difícil de atribuir a um responsável quando o projeto é auditado depois.
Sistema entregue não é sistema adotado
Adoção é um processo com etapas próprias. Quem vai usar precisa entender o que muda, por que muda, o que ganha e o que perde, e precisa de tempo para substituir um procedimento conhecido por outro ainda desconfortável. Rolando Bonaccorsi menciona a fase posterior à liberação como a mais desprotegida dos planos de projeto, geralmente por falta de responsável designado para ela.
A conta aparece no desperdício. Licenças pagas e não usadas, integrações mantidas apenas para sustentar o processo antigo em paralelo, retrabalho de conciliação entre duas fontes de informação que deveriam ser uma. Nada disso consta no relatório de encerramento, que marca o projeto como concluído no dia em que a equipe técnica se desmobiliza e segue para a próxima demanda.
O atrito que faz a equipe voltar ao processo antigo
A causa mais frequente não é resistência, é atrito. Uma tarefa que exigia três cliques passa a exigir oito, um relatório que saía em dois minutos demora quinze, e quem precisa entregar resultado volta ao caminho que funciona. Rolando Bonaccorsi sublinha o mapeamento do trabalho real, feito com quem executa, como condição anterior a qualquer desenho de solução.
Perda de autonomia produz efeito parecido. Quando o sistema novo tira de uma pessoa a possibilidade de corrigir um erro que ela corrigia sozinha, a adoção trava, mesmo que o ganho coletivo seja claro. O desenho precisa prever exceções legítimas, porque processo sem saída de emergência gera atalho informal, e atalho informal gera dado inconsistente.
Treinamento no fim, não no começo
Treinar na véspera da entrada em operação é desperdício de esforço. O conteúdo chega quando ninguém tem contexto para absorvê-lo, e o reforço acontece justamente no período de maior pressão, com o sistema novo cobrando atenção e a meta do mês correndo no mesmo prazo. Envolvimento desde a fase de desenho funciona melhor, porque quem participou da decisão chega ao primeiro dia já sabendo o motivo de cada escolha.
Multiplicadores internos resolvem o que a apostila não resolve. Rolando Bonaccorsi caracteriza o papel de referência local como peça central da transição, uma vez que a dúvida operacional aparece no meio do expediente e raramente sobrevive à espera por um canal formal de suporte. Pessoas reconhecidas pelos colegas sustentam a mudança melhor que qualquer comunicado institucional, e o custo de liberar parte do tempo delas é pequeno comparado ao de um sistema abandonado.
Medir adoção sem olhar apenas para o acesso
Contagem de acessos engana. Alguém pode abrir o sistema todos os dias e seguir fazendo o trabalho de verdade em outro lugar, apenas registrando depois o que já aconteceu. Indicadores úteis medem a conclusão de tarefas dentro da ferramenta, a queda do uso do processo antigo e o tempo gasto em cada etapa, comparado com o período anterior.
Pesquisa curta e recorrente completa a leitura quantitativa. Duas perguntas aplicadas a cada quinze dias revelam atrito específico antes que ele se transforme em abandono silencioso. Rolando Bonaccorsi projeta um desfecho previsível para quem acompanha apenas o painel de acesso, porque o número sobe enquanto a operação se afasta, e o diagnóstico chega quando a correção já custa caro.
