Vou trocar meu sistema principal
Resposta rápida
Trocar um sistema-chave (ERP, CRM, sistema de gestão principal) é projeto que mistura tecnologia, gente e processo — quase sempre é a gente e o processo que decidem o resultado, não o sistema. O caminho seguro tem cinco etapas: escolha com critério (caso de uso real, não brochura), planejamento de dados (o que migra, o que se descarta, o que se ajusta), implantação em paralelo (rodar o novo junto com o antigo por algumas semanas), treinamento intensivo do time e plano de mitigação para o que vai dar errado na primeira semana de produção. Trocar sistema sem paralelo é apostar tudo no go-live perfeito — o que praticamente nunca acontece.
Para quem opera sozinho ou com pouquíssimos ajudantes, a escolha é entre soluções SaaS padronizadas e baratas — não vale customizar, não vale ERP grande. O risco é você ser o responsável pela implantação enquanto também é o vendedor, o atendimento e o financeiro. Reserve duas ou três semanas com agenda reduzida para configurar e migrar dados, priorize os fluxos críticos (emissão de nota, cobrança, controle básico de estoque) antes de qualquer extra e mantenha o sistema antigo acessível como consulta por pelo menos três meses. Treine pelo menos uma pessoa de confiança junto com você — se só você sabe usar e cair doente, a operação para. Rodar em paralelo, mesmo em escala pequena, vale a pena por duas semanas.
Com time pequeno, a escolha costuma ser entre soluções SaaS padronizadas voltadas a PME — não vale customizar muito. O risco é o dono assumir a implantação acumulada com a rotina e atrasar tudo. Defina um responsável dedicado por algumas semanas (interno ou consultor), mantenha cadastro o mais limpo possível antes da migração e priorize fluxos críticos antes do go-live: emissão de nota, cobrança, controle de estoque, folha. Treine o time presencialmente, com casos reais, e nomeie dois ou três usuários-chave por área que dominem o sistema. Rode em paralelo por duas a quatro semanas e mantenha o sistema antigo acessível como consulta por pelo menos três meses depois.
Com áreas estruturadas e gestores, troca de sistema vira projeto formal com sponsor executivo, key users por área e cronograma de meses, não semanas. O risco é cada área tratar como projeto da TI e não como responsabilidade própria — sistema implantado sem dono de negócio acaba subutilizado. Indique um sponsor executivo, defina key users com tempo alocado, exija documentação dos fluxos atuais antes de configurar o novo e congele customizações depois da fase de homologação. Rodar em paralelo é negociável por módulo, mas não por inteiro: financeiro e fiscal não podem ter dúvida no go-live. Para o seu porte, projetos de ERP costumam levar de seis a doze meses para estabilização real — desconfie de cronograma mais agressivo.
A escolha começa antes da demonstração
Erro comum: começar a escolha por demonstração de fornecedor. Toda demo é bonita — o vendedor mostra o que o sistema faz bem, não o que ele faz mal. A escolha precisa começar pelo seu próprio mapeamento: quais são os cinco a dez fluxos críticos do seu negócio hoje, quais relatórios são essenciais, quais integrações são obrigatórias, qual o volume de dados, quantos usuários simultâneos.
Com esse mapeamento na mão, a demo vira teste, não apresentação. Você pede para o fornecedor mostrar o seu fluxo, não o demo padrão. Você pede para emitir o seu tipo de nota, não a nota genérica. Sistema bom em demo padrão pode ser ruim no seu fluxo específico — descobrir isso seis meses depois custa caro.
A migração de dados é metade do projeto
Trocar de sistema mexe com a base de dados acumulada ao longo de anos. Cadastro de clientes, produtos, fornecedores, histórico financeiro, notas fiscais, estoque, contratos. Quase nunca essa base está limpa o suficiente para entrar direto no sistema novo — campos preenchidos diferente, duplicatas, dados que perderam sentido.
Subestimar a migração é o erro mais caro da troca. O cronograma precisa reservar tempo real (semanas, em alguns casos meses) para limpeza, mapeamento, conversão, validação. Tentar migrar tudo no dia do go-live praticamente garante problema na primeira semana.
- Mapeamento de fluxos atuais. Cinco a dez processos críticos documentados como acontecem hoje — não como deveriam acontecer. Esses fluxos viram base para escolha e para teste.
- Definição de requisitos. O que o sistema novo precisa fazer (obrigatório), o que seria bom (desejável) e o que é dispensável. Sem essa hierarquia, qualquer sistema parece insuficiente em alguma coisa.
- Avaliação de fornecedores com teste real. Cinco a dez fornecedores em primeira filtragem, dois a três em demonstração com seus fluxos, um em prova de conceito (POC) com dados reais.
- Planejamento de dados. O que migra, o que se descarta, o que precisa ser limpo. Cronograma com responsável por base. Validação por amostra antes de migração completa.
- Implantação técnica. Configuração do novo sistema, integrações (banco, fiscal, marketplaces), parametrizações específicas do seu negócio. Tempo realista, sem promessa de fornecedor de "vai entrar em duas semanas".
- Treinamento do time. Não apenas o que clicar, mas por que clicar. Pessoa que entende o porquê resolve problema novo; pessoa que decorou roteiro trava na primeira variação. Trilhas por perfil de uso, com material de consulta e canal de dúvidas.
- Paralelo entre sistemas. Pelo menos algumas semanas com os dois rodando ao mesmo tempo nos fluxos críticos. Consome esforço, mas é o que salva quando o novo sistema falha em algo que parecia óbvio.
- Go-live com plano de contingência. Time de plantão nos primeiros dias, canal direto com o fornecedor, lista de cenários que podem dar errado com resposta pronta. Comunicação proativa com clientes que possam ser afetados.
- Estabilização e ajustes. Três a seis meses pós go-live para ajustes finos. Não é projeto que termina no dia de virada — termina quando o time está usando bem e os relatórios fecham com o anterior.
Cronograma realista
Projeto de troca de ERP raramente acontece em menos de seis meses. Projeto de CRM principal raramente em menos de três. Quando o fornecedor promete "implantação em quatro semanas", a promessa cobre a parte técnica — não cobre limpeza de dados, treinamento, paralelo e estabilização, que são o que de fato decide se a troca dá certo.
Sinais de cronograma realista
- Inclui semanas para limpeza e migração de dados
- Reserva tempo para POC com dados reais
- Prevê treinamento por perfil de uso, não palestra única
- Reserva paralelo de algumas semanas com o sistema antigo
- Considera três a seis meses de estabilização após go-live
- Tem responsável interno dedicado (não só fornecedor)
Sinais de cronograma otimista demais
- Promete go-live em poucas semanas após contrato
- Trata migração de dados como detalhe técnico
- Inclui treinamento de algumas horas no total
- Não menciona período de paralelo
- Sugere que o time aprende usando, sem trilha estruturada
- Coloca todo o risco no fornecedor, sem responsável interno
O time decide o resultado
Sistema novo não se usa sozinho. Mesmo o melhor ERP do mercado se torna inútil em time que não entendeu o porquê de cada fluxo. Por outro lado, sistema mediano em time bem treinado e engajado entrega resultado melhor do que sistema topo em time desinformado.
Treinamento que funciona tem três características: é por perfil de uso (financeiro aprende fluxo financeiro, comercial aprende fluxo comercial), é com casos reais do seu negócio (não exemplos genéricos) e tem canal de dúvidas durante o período de adaptação. Treinamento de duas horas no dia anterior ao go-live é a forma mais rápida de garantir que o projeto vai sofrer.
Escolher pelo preço sem entender o custo total. Licença barata pode esconder custo alto de implantação, customização, integração e treinamento. Some todos os custos antes de comparar — o cheap acaba caro quando o desconhecido aparece no orçamento.
Subestimar a migração de dados. Base suja vira sistema novo com base suja. Reserve tempo real para limpeza, mapeamento e validação. Migrar com pressa no go-live é receita certa para problema irreparável na primeira semana.
Pular o paralelo. Rodar o novo sistema sem o antigo de backup é apostar tudo no go-live perfeito. Paralelo cansa, mas salva o projeto quando o novo falha em algo que ninguém previu.
Treinar de menos. Treinamento mínimo no dia anterior gera time confuso na primeira semana, cliente irritado e o dono apagando incêndio. Treine antes, treine por perfil e mantenha canal de dúvidas aberto no início.
Confiar só no fornecedor. Sem responsável interno, o projeto vira teatro de fornecedor — promessas que somem quando o problema aparece. Tenha alguém da casa com mandato e tempo para o projeto, com poder de decisão.
Anunciar go-live em mês crítico. Trocar sistema na semana do fechamento contábil, do encerramento fiscal ou do pico de vendas multiplica risco. Escolha período de baixa atividade para a virada — abril, agosto e novembro costumam ser janelas mais seguras para várias empresas.
- Cinco a dez fluxos críticos mapeados e usados como base para a demo
- POC com dados reais realizada (não apenas demo padrão)
- Cronograma com etapas explícitas de migração de dados, treinamento e paralelo
- Custo total somado: licença, implantação, customização, integração, treinamento
- Responsável interno definido com mandato e tempo para o projeto
- Plano de treinamento por perfil de uso, com casos reais do seu negócio
- Plano de contingência para o go-live, com cenários e respostas
- Período do go-live escolhido em mês de baixa atividade