A sexta parte tratou do relatório: como ele deixa de ser um arquivo que você monta ao longo de dois dias e passa a ser uma visão que você abre sobre o momento atual. Isso completa o quadro que construímos ao longo de seis partes: quando uma planilha deixa de ser a resposta, qual arquivo realmente comanda a empresa, a limpeza dos dados antes da migração, a ordem em que as coisas migram, quem vê o quê e o fim do relatório feito à mão.

Resta a parte que decide se tudo isso vai valer a pena: o primeiro mês em produção. E há algo que todo mundo que já tocou um projeto assim sabe. A maioria das migrações não fracassa durante a construção. Elas fracassam nas primeiras semanas de uso. O sistema funciona, os dados estão lá, as telas estão corretas e, mesmo assim, o trabalho real volta discretamente para o arquivo antigo. Esta parte trata do porquê disso e de um plano que evita que aconteça.

Resistência não é teimosia, é cálculo de risco

A primeira coisa que você encontra na primeira semana é a hesitação da equipe. O erro comum é o dono interpretar essa hesitação como resistência à mudança ou preguiça e responder com pressão. Normalmente não é nem uma coisa nem outra.

O funcionário que antes abria um arquivo e concluía a tarefa em dois minutos agora precisa de dez para aprender o caminho na mesma tela. Do ponto de vista dele, está pagando hoje o custo de um benefício de que ouviu falar, mas que ainda não consegue ver, e ele responde ao gestor pela produção de hoje, não pelo sucesso do projeto. A hesitação é totalmente racional.

Ela se intensifica quando o dono do arquivo antigo é alguém cuja posição na empresa foi construída sobre conhecê-lo. Quem era a única referência de um arquivo pode temer que o sistema torne seu papel desnecessário. Ignorar esse medo não o elimina; apenas o empurra para debaixo do tapete. Tratá-lo diretamente funciona melhor: dê a essa pessoa um papel declarado no novo arranjo como responsável pela qualidade dos dados da sua área, para que ela deixe de guardar um arquivo e passe a ser a referência dos próprios dados.

A mudança verdadeira do primeiro mês é que o trabalho se tornou visível. Quando os dados viviam num arquivo, um lançamento atrasado era invisível. Num sistema, quem registrou o quê e quando fica registrado. Isso tranquiliza quem trabalha com regularidade e incomoda quem está acostumado à flexibilidade, e é melhor dizer isso abertamente na primeira reunião do que deixar que seja descoberto duas semanas depois.

A volta silenciosa ao arquivo antigo

O que há de mais perigoso no primeiro mês não acontece de forma barulhenta. Ninguém se opõe ao sistema na reunião, mas uma cópia do arquivo antigo continua aberta no computador de alguém, que registra nela porque é mais rápido, com a intenção de lançar no sistema no fim da semana. Normalmente isso não acontece.

O resultado é o pior possível: duas fontes da verdade em vez de uma. Antes do projeto, você tinha um único arquivo impreciso que todos aceitavam como referência. Agora tem um sistema incompleto e um arquivo incompleto, e ninguém sabe qual é o mais recente. Você está pior do que no começo, e esse é um dos padrões abordados em Por que projetos de ERP fracassam e como fazer o seu dar certo.

Os sinais aparecem cedo se você procurar por eles: um número citado numa reunião que não existe no sistema, um arquivo compartilhado no chat da equipe duas semanas depois do lançamento, um funcionário que pede para exportar os dados para trabalhar fora e nunca os traz de volta. Não trate nenhum deles culpando a pessoa. Faça uma única pergunta: o que o arquivo dava a ela que o sistema não dá? A resposta normalmente é uma etapa que falta, um campo ausente ou um caminho mais longo do que o necessário, e tudo isso pode ser corrigido em dias quando você fica sabendo.

As lacunas que surgem depois da mudança, não antes

Por mais bem que você tenha limpado os dados antes, como a terceira parte explicou, vão surgir lacunas que só poderiam ser descobertas na primeira transação real. A lógica é simples: o arquivo tolerava campos vazios, então uma célula em branco continuava em branco e nada impedia você de emitir a nota fiscal. O sistema exige o campo porque uma etapa posterior depende dele.

O que costuma aparecer nesta fase:

  • Cadastros incompletos de clientes e fornecedores. Um cliente cadastrado só pelo nome, sem número fiscal, endereço ou contato documentado, dados que antes eram pedidos verbalmente quando necessário.
  • Saldos iniciais que não batem. O valor de abertura de um cliente ou de um item diverge do que diz o arquivo antigo, e a diferença aparece no primeiro extrato.
  • Situações que nunca foram classificadas. Um pedido pendente, um pagamento parcial, uma devolução que nunca foi encerrada. No arquivo, eram uma anotação na margem; num sistema, precisam de uma situação definida.
  • Várias unidades e preços. Um item vendido por caixa e comprado por unidade, com preço diferente para uma faixa de clientes e para outra, tudo isso guardado na cabeça do responsável de vendas em vez de estar por escrito.
  • Exceções sem nenhuma regra por trás. Um cliente com condições especiais há anos sem nenhum documento, de modo que ninguém sabe como defini-lo no sistema nem quem tem autoridade para aprová-lo.

Nada disso é prova de que a migração fracassou. É o primeiro benefício real dela: o sistema expôs o que o arquivo escondia. Mas lidar com isso exige disciplina. Registre cada item numa única lista declarada, com a pessoa responsável pela resposta e uma data para encerrá-lo. Se você tratar cada caso separadamente numa conversa paralela, ele vai voltar no mês seguinte com outra cara.

Treinamento dado uma única vez não basta

O padrão mais repetido em projetos com dificuldades é o treinamento dado numa única sessão no dia do lançamento, com a presença de todos, percorrendo o sistema inteiro de ponta a ponta. Depois, todos voltam para a mesa tendo esquecido a maior parte, porque ouviram aquilo antes de precisar.

A alternativa que funciona se apoia em três princípios:

  • Treine a função, não o sistema. O contador não precisa das telas do estoque e o responsável de vendas não precisa das configurações de permissão. Cada equipe aprende o caminho que vai percorrer todos os dias, mais curto e muito mais focado.
  • Repita depois de uma semana de uso. A segunda sessão é a que realmente compensa, porque as perguntas que surgem nela são reais, tiradas do trabalho diário, e não hipotéticas. E as perguntas que se repetem entre as equipes mostram exatamente onde uma tela não está clara.
  • Documente com imagens, não com texto corrido. Uma página por função, com as etapas em ordem e capturas de tela, afixada no mural ou enviada a todos. A maioria das perguntas depois do lançamento é de memória, não de compreensão.

Você também precisa de uma pessoa em cada equipe a quem os outros perguntem primeiro, porque o funcionário pergunta a um colega antes de abrir um chamado de suporte. Esse papel informal reduz o tempo de resposta mais do que qualquer canal de suporte externo. Esse tipo de gestão da mudança não é exclusivo de deixar as planilhas para trás, e nós o abordamos como parte das fases de implantação em Como implantar um ERP com sucesso.

A visão da Origami

Tratamos o dia do lançamento como a metade de um projeto, não como o fim. Um sistema não se firma numa empresa só por funcionar; ele se firma quando se torna o caminho mais curto para concluir o trabalho do dia. Cada dia em que o caminho antigo continua mais rápido do que o novo é um dia trabalhando silenciosamente contra o projeto.

Por isso, no primeiro mês, mantemos uma lista declarada de observações com datas para encerrá-las, e medimos o uso real, não as impressões: quem faz login, quais transações são registradas no momento em que acontecem e em que tela as pessoas travam. É o que aplicamos ao desenvolver sistemas sob medida como parte dos nossos serviços, porque corrigir um pequeno travamento na primeira semana custa uma hora, enquanto corrigi-lo depois de dois meses custa a confiança de uma equipe inteira.

Um plano de trinta dias

Este é um plano que você pode executar como está escrito, e sua característica mais importante é que cada etapa tem um fim declarado:

  • Dias 1 a 7: operação em paralelo com prazo. O trabalho é registrado tanto no sistema quanto no arquivo antigo por um único motivo: comparar. No fim da semana, pegue uma pequena amostra, compare os dois números e registre cada diferença pela causa, não pelo tamanho.
  • Dia 8: o arquivo antigo passa a ser somente leitura. Este é o passo mais importante de todo o plano. O arquivo continua disponível para consulta e ninguém escreve nele. Sem uma data de encerramento declarada, a operação em paralelo continua indefinidamente e sempre termina com a vitória do arquivo antigo, porque ele é mais fácil.
  • Dias 8 a 14: segundo treinamento e fechamento de lacunas. Uma sessão curta por equipe sobre as perguntas que realmente surgiram, e o fechamento dos cinco primeiros itens da lista de lacunas.
  • Dias 15 a 21: medir o uso. Veja quem está realmente usando o sistema e quem não está e, para cada transação registrada com atraso, pergunte por quê. O que você aprende é um sinal de quão claro está o caminho, não da disciplina de cada um.
  • Dias 22 a 30: estabilizar e revisar. Encerre as observações restantes, gere o primeiro relatório mensal apenas pelo sistema e sente-se por meia hora com os líderes de equipe para identificar o que ainda acontece fora do sistema e por quê.

A medida honesta do sucesso não é a satisfação da equipe numa pesquisa nem o número de telas em uso. É um único momento: alguém para de abrir o arquivo antigo sem que ninguém peça. Nesse ponto, o sistema já não é um projeto que você gerencia: é a forma como a empresa trabalha.

Encerrando a série

Ao longo de sete partes, percorremos o caminho inteiro: os sinais de que uma planilha passou do limite, o inventário que mostra qual arquivo é de fato o seu sistema, a limpeza dos dados, a ordem em que as coisas migram, a configuração de permissões, a transformação do relatório feito à mão numa visão ao vivo e, por fim, a travessia do primeiro mês.

A conclusão que vale guardar é esta. O Excel é uma ferramenta excelente, e o problema nunca foi a ferramenta, mas o que se pedia que ela carregasse. Migrar para um sistema é menos uma atualização técnica e mais a decisão de que os dados da empresa pertencem à empresa, e não a um arquivo ou a uma pessoa. E tudo começa com um pequeno passo: abra o arquivo que comanda a sua empresa hoje e pergunte quem o atualiza, quando e o que acontece se essa pessoa estiver ausente.

Fontes