Por que razao as implementacoes de ERP falham - e porque e que uma API muda a equacao

Sete padroes de falha que se repetem em projetos de ERP, a contramedida para cada um e um relato factual de quais deles sao eliminados por um nucleo de contabilidade centrado em API.

As implementacoes de ERP falham por uma lista curta de razoes que se repetem de projeto para projeto: ambito que continua a crescer, personalizacao que substitui o processo padrao, dados que ninguem limpou, ausencia de alguem com autoridade para decidir, um unico fim de semana de transicao (cutover) que nao pode ser anulado, dependencia do roteiro (roadmap) de um unico fornecedor e requisitos fiscais ou de declaracoes descobertas apos a entrada em producao (go-live). Nenhum destes e um problema tecnologico no sentido estrito. Cada um e uma decisao tomada, ou nao tomada, antes de se configurar o primeiro ecrã.

Este artigo analisa estas causas uma a uma, indicando o que fazer em alternativa. Em seguida, apresenta um argumento especifico e limitado: quando o nucleo de contabilidade do sistema e uma API com a qual o seu proprio software se integra, varias destas causas sao removidas do projeto em vez de mitigadas, porque o trabalho a que estao associadas deixa de existir.

As causas recorrentes

1. Ambito que e descoberto em vez de decidido

Um projeto assinado para "financas e inventario" absorve aprovacoes de compras, custeio de projetos, um portal de clientes e uma camada de relatorios porque cada um deles e "quase a mesma coisa". O orcamento e a data foram definidos para o ambito original.

Em alternativa: escreva primeiro a lista de aceitacao. A lista de documentos, relatorios e declaracoes que o novo sistema tem de debitar corretamente para um mes encerrado e o ambito. Tudo o que nao estiver nessa lista e um segundo projeto.

2. Personalizacao que recria o sistema antigo

A frase mais cara num projeto de ERP e "o novo sistema tem de fazer as coisas da maneira que fazemos agora". Cada personalizacao tem de ser especificada, construida, testada, documentada e novamente testada em cada atualizacao. Os projetos que comecam por replicar os ecras antigos tendem a nunca terminar essareplicacao.

Em alternativa: aceite o processo padrao do fornecedor para cada fluxo em que a empresa nao seja genuinamente diferente, e mantenha uma lista escrita das excecoes com a justificacao para cada uma. Se a lista for longa, o produto e que esta errado, e nao a configuracao.

3. Dados que ninguem limpou

Duplicados de parceiros, artigos sem unidades, um plano de contas com centenas de codigos dormentes, faturas abertas que foram regularizadas ha anos mas nunca reconciliadas. A migracao nao pode avancar mais depressa do que a limpeza, e a limpeza e feita por pessoas que tambem tem de fechar o mes.

Em alternativa: faca a limpeza antes de o projeto comecar. Decida se pretende migrar o historico completo ou saldos de abertura juntamente com itens em aberto. Valide o pacote de migracao ate passar sem erros antes de escrever uma unica linha no novo sistema.

4. Ausencia de um responsavel pelo processo

Quando todas as decisoes sao remetidas para um comite de direcao, as decisoes demoram semanas. Quando ninguem e responsavel pelo processo de vendas a cobranca (order-to-cash) de ponta a ponta, o modulo de vendas e o de contas a receber sao configurados por pessoas diferentes com pressupostos diferentes.

Em alternativa: nomeie um unico responsavel por processo com autoridade para decidir, e utilize um registo de decisoes semanal que sirva de base tanto para o fornecedor como para a equipa.

5. Transicao total (big-bang cutover) sem alternativa de retorno

Ativar todas as entidades e todos os modulos num unico fim de semana concentra todo o risco num unico momento. Se o primeiro fecho de contas do mes falhar, nao ha sistema antigo para o qual recuar nem nenhuma implementacao parcial que permita retirar ensinamentos.

Em alternativa: efetue a transicao (cutover) num limite de periodo com um balancete de fecho reconciliado, mantenha o sistema antigo consultavel e, se existirem varias entidades, coloque uma delas primeiro em producao.

6. Dependencia de fornecedor (vendor lock-in) que se manifesta ao terceiro ano

Exportacoes de dados que exigem a contratacao de servicos profissionais, integracoes que so funcionam atraves do middleware do proprio fornecedor, precos por utilizador que crescem com o numero de trabalhadores em vez do trabalho efetuado, e um roteiro (roadmap) sobre o qual nao tem influencia. Nada isto e visivel no momento da assinatura; tudo isto se torna evidente na renovacao.

Em alternativa: antes de assinar, exporte tudo a partir de um tenant de teste e verifique o que e obtido. Confirme se a API abrange todas as operacoes executadas pelos ecras ou apenas um subconjunto. Leia o preçario do escalao seguinte e nao apenas o daquele que esta a comprar.

7. Conformidade fiscal descoberta apos a entrada em producao

Um novo registo de IVA noutro Estado-membro, uma obrigacao de faturacao eletronica que entra em vigor em janeiro, um formato de declaracao alterado pela administracao fiscal local. Num projeto tradicional, cada uma destas situacoes implica o envolvimento de parceiros ou uma personalizacao, surgindo cada uma de acordo com o seu proprio calendario.

Em alternativa: liste todas as declaracoes e regimes de IVA a que a empresa esta sujeita, por pais, antes da selecao, e peca ao fornecedor para demonstrar o ficheiro de saida para cada um a partir de um tenant de demonstracao. "Suporta o pais X" e um argumento comercial; uma declaracao gerada e uma prova.

O que uma API muda

O argumento aqui defendido e circunscrito. Um nucleo de contabilidade centrado em API (API-first) nao faz com que um projeto de ERP tenha sucesso por si so. Remove tarefas especificas do projeto, e as causas de falha associadas a essas tarefas desaparecem com elas. Seguem-se funcionalidades que a Nordlet ja disponibiliza atualmente, descritas com base no comportamento real do produto e nao em promessas de resultados.

A integracao e testada antes de assinar. E criada uma empresa em ambiente de testes (sandbox) com uma unica chamada, que se comporta exatamente como uma empresa real com os mesmos modulos e endpoints, aplicando-se a mesma taxa com base no uso (metered rate) que a utilizacao real. O plano de testes de pre-producao e um teste reproduzivel, e nao uma demonstracao. Se a integracao nao funcionar na sandbox, tera descoberto isso antes de qualquer compromisso, o que e o oposto de uma implementacao tradicional em que a integracao e a penultima fase.

As repeticoes de chamadas nao geram duplicados. Cada chamada de mutacao requer um cabecalho Idempotency-Key. A mesma chave com a mesma carga util (payload) reenvia a resposta armazenada; a mesma chave com uma carga util diferente e rejeitada com o erro idempotency_key_reuse. Toda uma classe de defeitos de integracao, como a fatura dupla apos um impedimento de rede (timeout), deixa de poder ocorrer e, por conseguinte, nao podera ser detetada durante o acompanhamento intensivo (hypercare). O glossario sobre idempotencia explica o funcionamento tecnico.

Os eventos substituem as sincronizacoes por lotes (batch). Os webhooks sao gravados numa caixa de saida transacional (transactional outbox) na mesma transacao de base de dados daalteracao, pelo que um documento revertido nunca emite um evento e nenhum evento e perdido. O seu sistema reage a sale_invoice.paid no momento em que ocorre; deixa de existir um ficheiro noturno para reconciliar e qualquer logica de reconciliacao deixa de precisar de ser escrita e testada.

O livro razao deteta erros de integracao por si. A base de dados rejeita um lancamento contabilistico que nao esteja balansear (desequilibrado). Um lancamento contabilizado nao e editado; as correcoes sao estornos associados ao original. Um lancamento com data num periodo bloqueado e rejeitado com o codigo 409. Estas restricoes correspondem ao conceito de livro razao imutavel na pratica, transformando problemas de dados silenciosos em erros de API evidentes durante o desenvolvimento.

As regras de IVA e formatos de declaracoes ficam a cargo da manutencao do fornecedor, e nao da sua personalizacao. O motor de IVA da UE determina o lugar da operacao, a inversao do sujeito passivo (reverse charge), o OSS, o IOSS e a regra do adquirente como devedor do imposto (deemed-supplier rule), devolvendo a respetiva fundamentacao legal com cada resposta. Os formatos de declaracao para 30 paises estao registados no produto; a tabela de suporte a declaracoes indica, para cada prazo, se a Nordlet envia o ficheiro, o gera para carregamento ou apresenta os valores para introducao manual. Quando um formato e alterado, a atualizacao e disponibilizada como uma atualizacao de produto para todas as empresas, sendo as alteracoes do produto registadas no registo de alteracoes (changelog). A conformidade descoberta apos a entrada em producao (causa 7) passa a ser uma questao que consegue esclarecer numa pagina publica antes da selecao.

O preco nao depende do numero de utilizadores (seats). Os planos sao faturados por pedido, incluindo todos os modulos e a API completa em qualquer plano, sem limite de utilizadores ou de empresas. O custo cresce com o trabalho executado pelo sistema, e nao com o numero de pessoas que iniciam sessao, nao existindo nenhum escalao de funcionalidades para o qual tenha de migrar mais tarde. Isto aborda uma das componentes dadependencia de fornecedor (causa 6); nao aborda as restantes, razao pela qual se segue a secao seguinte.

Os dados sao exportados tal como foram inseridos. Os relatorios sao gerados em formato XLSX, PDF ou JSON. As exportacoes do livro razao estao disponiveis nos formatos DATEV, FEC e SIE para os paises que os utilizam. A aplicacao web nao possui endpoints privados, pelo que tudo o que consegue visualizar num ecrã pode ser obtido atraves da API. O teste de exportacao referido na causa 6 pode ser executado na sandbox logo no primeiro dia.

O que uma API nao muda

Os dados mestres continuam a ser da sua responsabilidade limpar. O importador de migracao valida e rejeita pacotes incorretos, mas nao os corrige.
A atribuicao de responsabilidades por processos continua a ser uma decisao de recursos humanos. Uma API torna a questao do "quem decide" mais simples, por haver menos aspetos a configurar, mas nao resolve essa decisao por si.
Alguem tera de escrever codigo. O projeto de configuracao e substituido por um projeto de integracao executado por programadores. Se a sua equipa nao contar com programadores, este tipo de produto apenas transfere o trabalho em vez de o eliminar.
O ambito fora da contabilidade continua a ser ambito. O planeamento de armazem, o planeamento de fabrico e o CRM para alem de contactos comerciais sao modulos independentes da Nordlet que integra da mesma forma ou sistemas separados adjacentes, sendo a integracao entre eles da sua responsabilidade.
Maturidade do fornecedor. A Nordlet encontra-se em acesso antecipado em 2026 e a integrar parceiros de concecao. Um fornecedor jovem constitui um fator de risco que um teste em sandbox nao elimina; apenas torna mensuravel o estado atual do produto.

Uma breve lista de verificacao antes de assinar qualquer contrato

Escreva a lista de aceitacao: documentos, relatorios e declaracoes para um mes encerrado.
Limpe os dados mestres e decida a questao do historico antes de o projeto comecar.
Atribua um unico responsavel por processo.
Execute a integracao num ambiente de sandbox e conserve o conjunto de testes (test suite).
Exporte tudo a partir do tenant de teste e inspecione os ficheiros.
Para cada pais, analise a declaracao gerada e nao a lista de funcionalidades.
Leia o preco do escalao imediatamente acima daquele que esta a comprar, bem como o custo associado a saida.

FAQ

Qual e a razao mais comum para o fracasso de projetos de ERP?

Um ambito que cresce apos o orcamento e a data terem sido fixados, habitualmente atraves de pedidos de personalizacao que recriam o sistema antigo. A qualidade dos dados ocupa o segundo lugar e constitui a causa mais frequente de adiamento da data de entrada em producao.

A escolha de um ERP em nuvem (cloud) evita estas falhas?

O alojamento altera quem gere os servidores. Nao altera o ambito, a personalizacao, a qualidade dos dados nem a titularidade dos processos. Os produtos em nuvem tornam a realizacao de atualizacoes da responsabilidade do fornecedor, o que elimina um custo a longo prazo associado a personalizacao.

De que forma um sistema centrado em API reduz o risco de implementacao?

Transfere a integracao para o inicio do projeto, permitindo testa-la num ambiente de sandbox antes de assumir compromissos; torna as repeticoes e os eventos seguros por construcao; e disponibiliza regras fiscais e formatos de declaracoes como funcionalidades do produto em vez de personalizacoes do projeto. Nao limpa os seus dados nem define os seus processos por si.

Um nucleo de contabilidade centrado em API e um ERP?

Constitui o nucleo financeiro de um ERP: livro razao, documentos, banco, impostos, declaracoes e, no caso da Nordlet, tambem inventario, producao, salarios, ativos imobilizados e encomendas de comercio eletronico. O artigo SaaS ERP vs tradicional aborda esta distincao em detalhe.

O que devemos testar na sandbox?

Emitir uma fatura e consultar o lancamento contabilistico. Enviar o mesmo pedido duas vezes e contar as faturas. Efetuar um lancamento num periodo bloqueado e confirmar o erro 409. Emitir uma nota de credito e verificar o estorno. Gerar a declaracao de IVA para o pais da empresa na sandbox. Exportar o livro razao. Se estes testes forem bem-sucedidos, o nucleo contabilistico funciona; o risco remanescente reside nos seus dados e nos seus outros sistemas.