How Long Does ERP Implementation Take? Realistic Timelines

A phase-by-phase answer to how long an ERP project takes, the things that make it longer, and a contrasting timeline for an accounting core you integrate through an API.

Uma pequena empresa que transita para um ERP na cloud com módulos padrão necessita tipicamente de três a seis meses desde a assinatura até ao arranque (go-live). Uma empresa de média dimensão com várias entidades, fluxos de trabalho personalizados e integrações precisa habitualmente de seis a doze meses. Uma implementação numa grande multinacional demora entre um a três anos, frequentemente dividida por vagas consoante a região ou a unidade de negócio. Estes intervalos estão alinhados com o que os parceiros de implementação publicam e as equipas financeiras reportam; não resultam de um inquérito e um projeto específico pode situar-se fora destes limites em qualquer uma das direções.

O número único que toda a gente procura não existe, pois a "implementação" divide-se em nove partes distintas, sendo que a duração de cada uma depende de decisões tomadas pelo comprador antes do arranque do projeto. Este artigo divide o cronograma nessas mesmas partes, demonstra o que prolonga cada uma delas e apresenta um calendário alternativo: aquele que obtém quando o núcleo de contabilidade é uma API com a qual o seu próprio software comunica, em vez de um sistema que necessita de ser configurado.

As nove fases e o respetivo motor de duração

Fase	Duração típica	O que determina a duração
Seleção	1–3 meses	Número de fornecedores pré-selecionados, rondas de demonstrações, chamadas de referência, regras de contratação pública
Conceção	2–8 semanas	Quantos processos devem ser mapeados, se a equipa está de acordo quanto aos mesmos, o nível de aceitação do fluxo padrão do fornecedor tal como está
Migração de dados	4–16 semanas	Qualidade dos dados mestres (master data), quantos anos de histórico são migrados, número de sistemas de origem
Configuração	4–12 semanas	Número de entidades, planos de contas (plano de contas), países, regimes de IVA, fluxos de aprovação
Integração	4–20 semanas	Contagem de sistemas a ligar (banco, salários, comércio eletrónico, CRM, armazém), qualidade da API de cada uma das partes
Testes	3–8 semanas	Número de cenários de ponta a ponta (end-to-end), realismo dos dados de teste, quantidade de defeitos detetados na primeira passagem
Formação	2–6 semanas	Número de colaboradores, diversidade de funções, grau de diferenciação entre o processo novo e o antigo
Arranque (Go-live)	1–2 semanas	Método de transição (big-bang ou faseado), alinhamento temporal com o fecho do período
Acompanhamento reforçado (Hypercare)	4–12 semanas	Contagem de defeitos em aberto no arranque, fecho do primeiro mês, primeira declaração de IVA a partir do novo sistema

Na prática, as fases sobrepõem-se. A integração começa enquanto a configuração ainda decorre; a formação coincide frequentemente com os testes. Um plano realista não corresponde à soma da coluna, mas o caminho crítico passa habitualmente pela migração de dados e pela integração, sendo precisamente nestas duas áreas que ocorrem a maioria dos atrasos.

O que torna o processo mais longo

Personalização. Cada alteração ao comportamento padrão do fornecedor tem de ser especificada, desenvolvida, testada, documentada e testada novamente em cada atualização futura. Um projeto que aceita o processo padrão em 90% dos fluxos e personaliza o resto tende a terminar com sucesso; um projeto que começa por replicar os ecrãs do sistema antigo tende a falhar.

Dados mestres incorretos. Clientes duplicados, fornecedores com três grafias diferentes, artigos sem unidade de medida, um plano de contas que cresceu de forma desordenada ao longo de uma década. A migração nunca pode ser mais rápida do que a limpeza de dados, e esta tarefa é realizada por pessoas que também têm as suas funções diárias. Esta é a causa mais comum de derrapagem na data de arranque e a menos visível no plano original.

Múltiplas entidades. Cada entidade jurídica exige o seu próprio plano, numeração, registo de IVA, contas bancárias e fecho de período. Os fluxos intragrupo (intercompany) entre as mesmas exigem um desenho próprio. Multiplique a fase de configuração pelo número de entidades e adicione depois o desenho da consolidação por cima.

Impostos multi-país. Uma empresa que vende para vários Estados-membros da UE tem de garantir que o novo sistema aplica corretamente as regras de localização das prestações, a inversão do sujeito passivo (reverse charge), a declaração OSS e os formatos de submissão locais antes de entregar a primeira declaração. Se a localização do fornecedor para um determinado país tiver sido construída por um parceiro em vez de ser nativa, a disponibilidade desse parceiro passa a integrar o caminho crítico.

Integrações com APIs fracas. Um ERP que apenas disponibiliza importações baseadas em ficheiros obriga todos os sistemas ligados a funcionar num padrão por lotes (batch), sendo que cada padrão por lote exige uma lógica de reconciliação que alguém terá de programar e testar.

Uma data de arranque definida antes do âmbito. Quando a data é fixada por razões políticas e o âmbito é descoberto mais tarde, o projeto acaba por reduzir os testes ou adiar a data. Ambas as opções são dispendiosas.

O que encurta o processo

Aceitar os processos padrão do fornecedor nos domínios em que a empresa não difere substancialmente da norma.
Limpar os dados mestres antes de o projeto começar, e não durante o mesmo.
Migrar os saldos de abertura juntamente com os itens em aberto, em vez do histórico completo, mantendo o sistema antigo acessível para consultas.
Escolher uma data de transição coincidente com o limite de um período, com um balancete de fecho validado e reconciliado.
Nomear um único responsável por processo em cada módulo, com poder de decisão.
Testar com documentos reais dos últimos doze meses, em vez de amostras fictícias.
Escolher um sistema cuja API permita desenvolver e testar integrações em paralelo com a configuração, e não apenas após esta.

Um calendário diferente: o núcleo de contabilidade centrado na API (API-first)

Os cronogramas descritos anteriormente referem-se a um sistema que as pessoas configuram através de ecrãs e que utilizam igualmente por essa via. Existe outro modelo de projeto, regido por um ritmo temporal distinto. Quando o núcleo de contabilidade é uma API de contabilidade, o trabalho de integração avança para o início e a maior parte da fase de configuração desaparece, pois há muito menos parâmetros a configurar: o plano de contas, as regras fiscais e os formatos de submissão já vêm integrados no produto.

Eis como isso se traduz no Nordlet, descrito através do que o produto já faz hoje e não sob a forma de promessa:

Dia um: uma empresa sandbox. É criada uma empresa sandbox diretamente a partir da aplicação ou através de uma única chamada à API. O seu comportamento é idêntico ao de uma empresa real, dispondo dos mesmos módulos e pontos de extremidade (endpoints), sendo possível criar quantas forem necessárias. O guia de introdução acompanha os primeiros comandos.

Dias um a cinco: o primeiro fluxo funcional. Criar um parceiro, criar uma fatura, emitila, registar um pagamento e ler o lançamento de diário gerado pela emissão. Cada operação consiste numa chamada POST /v1/{module}/{resource}/{action} com um corpo em JSON, existindo kits de desenvolvimento de software (SDKs) com tipos definidos para nove linguagens, pelo que o primeiro fluxo se resume a algumas dezenas de linhas de código. As repetições (retries) são seguras, uma vez que o cabeçalho Idempotency-Key repete a resposta guardada em vez de criar uma segunda fatura.

Semana dois: o histórico. O importador de migração recolhe o plano de contas, parceiros, artigos, saldos de abertura ou o histórico completo de diários, faturas de clientes e fornecedores em aberto, ativos fixos com as respetivas depreciações acumuladas até à data, bem como o stock existente, gravando tudo numa única transação de base de dados. O ponto de extremidade exclusivo de validação (migration/books/validate) executa todas as verificações sem gravar dados, permitindo iterar o pacote até que não reporte quaisquer erros, momento em que se executa o comando migration/books/import uma única vez. Se alguma linha falhar, nada é armazenado.

Semanas dois a quatro: o resto da integração. Canais de dados bancários (bank feeds) através de ligações PSD2, importação de extratos camt.053, exportações do Stripe e webhooks como sale_invoice.paid, permitindo que o sistema reaja a eventos em vez de efetuar consultas periódicas (polling). Cada componente constitui um ponto de extremidade independente e pode ser desenvolvido em paralelo por programadores diferentes.

Conformidade fiscal: já registada. O tratamento em termos de IVA de uma venda intracomunitária é resolvido pelo motor de IVA da UE, ficando o calendário de entrega do país da empresa preenchido com base em regras incorporadas. A tabela de suporte de entregas indica, para todos os 30 países, os prazos que o próprio Nordlet submete, aqueles para os quais gera um ficheiro e os que continuam a exigir introdução manual. Nada disto constitui trabalho de projeto.

O fecho de período como teste. O fecho do primeiro mês representa o momento em que um projeto de ERP prova a sua eficácia. Graças a um registo imutável e ao bloqueio de períodos, qualquer lançamento com data num mês bloqueado é rejeitado com o código 409, o que significa que o fecho passa a ser imposto pelo sistema e não pela disciplina humana, permitindo que eventuais erros de integração que só seriam detetados durante o acompanhamento reforçado venham à tona logo na sandbox.

Limites honestos deste calendário: abrange o núcleo de contabilidade, impostos e obrigações declarativas. Se o seu projeto também necessitar de gestão de armazém, planeamento de produção ou de um CRM, estes correspondem a módulos do Nordlet que integra da mesma maneira (inventário, produção, encomendas de comércio eletrónico, potenciais clientes) ou a sistemas externos, sendo que o trabalho de integração com estes últimos continuará a ser da sua responsabilidade. O Nordlet é também um produto recente, em acesso antecipado em 2026 e a integrar parceiros de conceção, um fator a ponderar em qualquer decisão de fornecedor.

Como estimar o seu próprio projeto

Conte as entidades, países e registos de IVA. Cada um representa trabalho de configuração num ERP tradicional e um registo de empresa num sistema API-first.
Conte as integrações e verifique a API de cada sistema antes de assinar contratos. Uma interface baseada apenas em ficheiros duplica sensivelmente a estimativa de integração.
Decida a quantidade de histórico a migrar. Os saldos de abertura juntamente com os itens em aberto demoram semanas; o histórico plurianual completo demora meses.
Defina a data de transição com base no calendário de períodos, e nunca ao contrário. Um limite de ano ou trimestre com um balancete de fecho reconciliado constitui a transição mais económica possível.
Assuma que o primeiro fecho demorará o dobro do tempo habitual e previstione apoio reforçado (hypercare) para a primeira declaração de IVA e o primeiro processamento salarial gerados pelo novo sistema.
Redija o teste de aceitação antes de o projeto arrancar: a lista de documentos, relatórios e declarações que o novo sistema deve emitir corretamente para o primeiro mês fechado. O plano de testes pré-produção serve de modelo para a vertente contabilística.

FAQ

Uma implementação de ERP pode demorar menos de três meses?

Sim, no caso de uma empresa com uma única entidade que aceite os processos padrão, migre apenas os saldos de abertura e possua uma ou duas integrações. Com um núcleo de contabilidade API-first, o primeiro fluxo funcional mede-se em dias, sendo que a tarefa mais longa remanescente costuma ser o pacote de migração de dados.

Qual é a fase que falha mais frequentemente?

A migração de dados, seguida da integração. Ambas dependem do estado de sistemas que o fornecedor não controla: a qualidade dos seus dados atuais e as APIs dos sistemas que liga.

Devemos migrar o histórico completo ou apenas os saldos de abertura?

Os saldos de abertura e os itens em aberto são suficientes para que o novo sistema fique completo a partir da data de transição, exigindo uma fração do tempo. O histórico completo compensa quando necessita de dados comparativos dentro do novo sistema ou quando o sistema antigo vai ser integralmente desativado. O importador do Nordlet aceita qualquer uma das opções.

Uma implementação faseada é mais rápida do que uma transição do tipo "big-bang"?

As implementações faseadas demoram mais tempo no total, mas acarretam menos riscos em cada etapa e permitem que a equipa aprenda com a primeira entidade antes de avançar para a seguinte. O modelo "big-bang" é mais rápido quando a organização é suficientemente pequena para que um fim de semana de transição cubra tudo.

De que forma a "implementação" difere num produto API-first?

Não existe nenhum projeto de configuração ecrã a ecrã. O trabalho foca-se na integração e na migração, executado por programadores através de uma sandbox, enquanto a camada de conformidade (regras de IVA, formatos de submissão, calendários) já vem incluída com o produto. A contrapartida reside no facto de alguém da sua equipa ter de programar.