O problema raramente é só técnico
Projetos ERP atrasam quando decisões de negócio chegam tarde, escopo fica aberto e o dono do processo não aparece.
Introdução
Parece óbvio dizer que projetos de ERP atrasam por causa de escopo, decisão, alinhamento e participação do negócio.
Mas, na prática, esse ponto continua sendo subestimado.
Quando um projeto de Microsoft Dynamics 365 Finance & Operations (D365 F&O) atrasa, a primeira explicação costuma cair no técnico: desenvolvimento X++, integrações, performance, dados, infraestrutura, relatórios, ambiente, deploy, dependências externas ou bugs.
Tudo isso pode atrasar um projeto.
Mas raramente é a história inteira.
Muitas vezes, o atraso começa antes do código. Começa quando uma decisão de negócio não chega, quando o dono do processo não aparece, quando o escopo muda sem critério, quando uma exceção vira customização, quando o usuário-chave não valida, quando a regra fiscal ou operacional é discutida tarde demais ou quando todo mundo espera que o sistema resolva uma indefinição que a empresa ainda não resolveu.
Projetos ERP não atrasam apenas porque o time técnico demora.
Muitas vezes atrasam porque a decisão que alimenta o trabalho técnico chega tarde demais.
Essa diferença muda a conversa.
O atraso técnico muitas vezes é consequência
É claro que existem problemas técnicos reais.
Integrações podem ser mais complexas do que pareciam. Migração de dados pode revelar inconsistências antigas. Customizações podem exigir mais desenho. Ambientes podem falhar. Performance pode precisar de ajuste. Relatórios podem depender de regras ainda não mapeadas.
Mas, em muitos projetos, o problema técnico aparece como sintoma de uma decisão de negócio mal resolvida.
Um desenvolvimento atrasa porque ninguém definiu a regra final.
Uma integração atrasa porque o processo entre áreas ainda não está claro.
Um teste atrasa porque o usuário-chave não consegue validar o cenário.
Uma especificação muda porque a exceção operacional só apareceu quando o sistema foi demonstrado.
Um relatório volta para retrabalho porque os indicadores não tinham dono.
O ponto é simples: o técnico não trabalha no vazio.
No D365 F&O, cada decisão funcional puxa impacto em dados, segurança, contabilidade, fiscal, estoque, compras, vendas, workflow, integrações, relatórios e governança.
Quando a decisão chega tarde, o atraso aparece no técnico. Mas a origem pode estar no processo.
1. Escopo mal definido vira retrabalho
Todo projeto começa com algum nível de incerteza.
Isso é normal.
O problema começa quando a incerteza vira escopo aberto.
Em D365 F&O, frases como "isso é simples", "é só adaptar", "depois a gente vê", "faz igual ao sistema antigo" ou "o usuário resolve no teste" costumam esconder decisões importantes.
O sistema antigo pode ter regras que ninguém documentou.
O processo atual pode depender de controles manuais.
A exceção pode ser mais frequente do que o time imaginava.
O campo aparentemente simples pode impactar imposto, contabilização, workflow, integração ou auditoria.
Quando isso aparece tarde, o projeto paga a conta em forma de retrabalho.
Escopo bom não é escopo gigantesco.
Escopo bom é escopo compreendido, priorizado e governado.
2. Decisões pendentes bloqueiam execução
Projetos ERP dependem de decisões.
Decisões sobre processo.
Decisões sobre dados.
Decisões sobre papéis.
Decisões sobre exceções.
Decisões sobre padrão global versus necessidade local.
Decisões sobre customizar, configurar, integrar ou mudar o processo.
Quando essas decisões ficam pendentes, o time técnico até pode continuar trabalhando por algum tempo. Mas ele passa a trabalhar com hipóteses.
E hipótese em ERP custa caro.
Uma hipótese errada pode gerar desenvolvimento desnecessário, teste inválido, retrabalho em integração, ajuste de dados, atraso em UAT e desgaste entre as áreas.
O atraso não acontece apenas quando alguém demora para codar.
Também acontece quando alguém demora para decidir.
3. Falta de dono do processo cria ambiguidade
Uma pergunta simples costuma revelar muito:
quem é o dono desse processo?
Se a resposta for vaga, o risco é alto.
Em muitos projetos, várias áreas participam do mesmo fluxo, mas nenhuma assume a responsabilidade final pelo desenho.
Compras aponta para financeiro.
Financeiro aponta para fiscal.
Fiscal aponta para operação.
Operação aponta para TI.
TI aponta para a consultoria.
A consultoria pede decisão do negócio.
E o projeto fica girando.
D365 F&O é um ERP integrado. Isso é uma força, mas também expõe ambiguidades.
Se ninguém é dono do processo, qualquer decisão parece provisória.
E decisão provisória vira solução provisória.
4. Baixa participação do negócio derruba a qualidade do projeto
ERP não é um projeto que o negócio pode terceirizar para TI.
TI, consultoria e arquitetura ajudam a transformar necessidade em solução. Mas quem conhece a operação real é o negócio.
Quando o usuário-chave entra tarde, valida pouco ou participa apenas para "aprovar tela", o projeto perde qualidade.
Porque a parte mais importante da validação não é dizer se a tela está bonita.
É confirmar se o processo funciona na vida real.
O pedido passa pelas aprovações certas?
A regra fiscal está correta?
A contabilização reflete o negócio?
O estoque fica consistente?
O fechamento não cria retrabalho?
O relatório responde à decisão que precisa ser tomada?
Sem participação real do negócio, o projeto pode até avançar no cronograma por um tempo.
Mas a conta aparece no teste integrado, no UAT, no go-live ou no suporte pós-entrada em produção.
5. Excesso de customização pode mascarar falta de decisão
Customização não é vilã.
Em D365 F&O, existem cenários em que customizar faz sentido. Especialmente quando há requisito regulatório, diferenciação operacional, integração específica ou necessidade clara de controle.
O problema é customizar para evitar uma decisão.
Customiza-se porque ninguém quer mudar o processo.
Customiza-se porque cada área quer manter seu jeito.
Customiza-se porque a exceção virou regra.
Customiza-se porque o sistema antigo fazia assim.
Customiza-se porque decidir padrão seria politicamente difícil.
Esse tipo de customização não apenas aumenta esforço técnico. Ela aumenta teste, documentação, suporte, regressão, dependência de especialistas, custo de upgrade e risco operacional.
A pergunta não deve ser apenas:
é possível customizar?
A pergunta deveria ser:
essa customização resolve um problema estratégico ou apenas protege uma indefinição?
6. UAT não deve ser o primeiro momento de descoberta
UAT deveria validar uma solução.
Não descobrir o processo inteiro.
Quando regras essenciais aparecem apenas no teste de aceite, o projeto entra em modo reativo.
O time descobre exceções tarde.
O usuário descobre impacto tarde.
A arquitetura descobre dependências tarde.
A gestão descobre risco tarde.
E o cronograma vira negociação permanente.
Isso não significa que tudo precisa estar perfeito antes do UAT. Nenhum projeto real funciona assim.
Mas o UAT não pode ser usado como substituto de desenho de processo.
Teste bom confirma hipóteses bem trabalhadas.
Teste ruim tenta compensar decisões que nunca foram tomadas.
Um mapa simples das causas reais de atraso
| Sintoma visível | Causa provável | Consequência |
|---|---|---|
| Desenvolvimento parado | Regra de negócio indefinida | Código baseado em hipótese ou retrabalho |
| Integração atrasada | Fronteira entre sistemas não definida | Mapeamento muda várias vezes |
| UAT sem avanço | Usuário-chave sem tempo ou sem autonomia | Validação superficial e decisões tardias |
| Muitas mudanças de escopo | Processo real não foi compreendido | Backlog cresce e prioridade muda |
| Customização excessiva | Baixa disposição para mudar processo | Mais custo, teste e risco de upgrade |
| Reuniões repetidas sobre o mesmo tema | Falta de dono claro | Decisão circula, mas não fecha |
O que bons projetos fazem diferente
Projetos melhores não são aqueles sem problema.
São aqueles que descobrem problemas cedo, dão dono para decisões e protegem o time contra ambiguidade permanente.
Algumas práticas ajudam muito:
- definir dono de processo por fluxo crítico;
- registrar decisões e pendências com data e responsável;
- separar requisito real de preferência operacional;
- questionar customizações antes de estimar esforço;
- envolver usuários-chave desde o desenho, não apenas no UAT;
- validar cenários ponta a ponta antes de detalhar exceções;
- tratar decisão pendente como risco de projeto, não como detalhe administrativo;
- manter arquitetura, funcional, técnico e negócio na mesma conversa quando o tema afeta várias áreas.
Isso não elimina atraso automaticamente.
Mas muda a qualidade da gestão.
O projeto deixa de fingir que tudo é técnico e passa a tratar as causas reais.
IA pode ajudar, mas não substitui decisão
Com IA, agentes, copilotos e automações, muita coisa pode ficar mais rápida em projetos ERP.
IA pode ajudar a resumir atas, comparar requisitos, analisar backlog, identificar pendências, organizar evidências, revisar especificações, sugerir cenários de teste, explicar impactos e acelerar documentação.
Mas IA não resolve ausência de dono.
IA não decide prioridade política.
IA não assume responsabilidade por regra de negócio.
IA não substitui governança.
Na verdade, quanto mais IA entra no ERP, mais importante fica ter processos bem definidos.
Porque automatizar ambiguidade não cria eficiência.
Cria velocidade para errar.
Conclusão
Projetos D365 F&O atrasam por motivos técnicos, sim.
Mas o problema raramente é só técnico.
Muitas vezes, o atraso nasce em decisões que não foram tomadas, processos que não tinham dono, escopos que ficaram abertos, usuários-chave que chegaram tarde e customizações que tentaram compensar indefinições de negócio.
O ERP apenas torna isso visível.
Por isso, maturidade em projeto D365 F&O não é apenas ter bons desenvolvedores, bons consultores funcionais ou boa infraestrutura.
É ter clareza de processo, dono de decisão, participação real do negócio e coragem para separar o que precisa ser customizado do que precisa ser repensado.
No fim, um projeto ERP não atrasa apenas quando o código demora.
Atrasa quando a empresa demora para decidir como quer operar.