Aqui está meu veredito de saída: quando você integra ERP e WMS, os dados mestres vêm primeiro. Sempre. Já conduzi mais de 30 go-lives, e todos os projetos que tentaram «vamos ativar primeiro as interfaces de pedidos e limpamos os dados mestres depois» explodiram na noite do go-live. A única exceção não teve sorte — simplesmente atrasou o bastante para alguém terminar o trabalho de dados mestres direito.

Pense nisso como estradas e tráfego. A integração coloca seus pedidos de compra e pedidos de venda em movimento entre o ERP e o WMS — essa é a estrada. Os dados mestres são a sinalização: códigos de item, códigos de endereço, cadastros de clientes. Se a placa do ERP diz «SKU-48213» e o WMS lê «SKU48213», o tráfego colide. Ter as interfaces no ar não significa estar pronto para o go-live. Esse roteiro exato eu vi se desenrolar três vezes.

Por que «dados mestres por último» sempre detona

Verão de 2024. Uma marca de beleza com armazém próprio em Riverside, Califórnia — 50,000 pés quadrados, cerca de 4,000 pedidos por dia. O diretor de TI do cliente decidiu: «A limpeza dos dados mestres demora demais. Vamos ativar primeiro as interfaces de PO e SO e preenchemos os dados mestres depois do go-live.»

Três dias antes do go-live, o ERP enviou um pedido de compra para o WMS. Erro: item não encontrado. O número do item do ERP era «SKU-48213»; o WMS o havia importado como «SKU48213» — faltando um hífen. Nenhum dos dois lados cedia, porque a especificação da interface dizia apenas «repassar o número do item». Lixo que entra, lixo que sai.

Piorou. O ERP tinha mais de 6,000 SKUs ativos, incluindo mais de 400 itens zumbis — descontinuados, ressuscitados, descontinuados de novo, mas ainda sentados nas tabelas de preço. Na manhã do go-live, a primeira onda de recebimento bateu numa parede de erros de «item não mantido» na doca. Os caminhões se acumulavam. Só começamos a operar às 4 PM, com 12 carretas engarrafadas nas portas. A correção: congelar a criação de itens no ERP naquela noite, declarar o WMS mestre de itens e sincronizar de volta para o ERP. O go-live escorregou duas semanas e queimou três semanas extras de consultoria.

Contrastem com um 3PL de artigos para o lar em Ohio no ano seguinte. No dia um, travamos três padrões de codificação — itens, clientes, endereços — oito semanas antes do go-live. Qualquer SKU novo entrando no prédio tinha que passar primeiro por uma revisão de dados mestres. As interfaces de pedidos foram integradas por último, nas duas semanas finais. Na noite do go-live tivemos exatamente dois incidentes. Um foi um descasamento de tamanho de campo — 20 caracteres no ERP, 30 no WMS — corrigido com uma regra de truncamento em meia hora. Foi um dos go-lives mais tranquilos que já conduzi.

Lado a lado, a resposta é óbvia: dados mestres primeiro não é a opção cautelosa, é a única opção que sobrevive ao contato com a realidade. Os dados mestres são a língua comum dos dois sistemas. Se a língua não está unificada, conversas mais rápidas só produzem mal-entendidos maiores.

Como eu conduzo integrações ERP-WMS: a sequência em sete passos

O mesmo manual em todos os projetos. Siga-o e ficará bem:

  1. Trave os padrões de codificação antes de tudo. De oito a dez semanas antes do go-live, finalize o padrão de codificação de itens, o padrão de codificação de endereços e o padrão de codificação de clientes/fornecedores — assinados pelas três partes. Quem assina assume qualquer mudança posterior. Depois da assinatura, congelado: casos especiais passam por solicitação de mudança, não por conversa de corredor.

  2. Dê a cada domínio de dados mestres um único dono. ERP e WMS precisam dos dados de itens, mas só um sistema é a fonte da verdade. Minha divisão usual: itens pertencem ao ERP (finanças e compras vivem lá), endereços pertencem ao WMS (o armazém conhece suas racks), clientes pertencem ao ERP, fornecedores pertencem ao ERP. O dono cria e mantém; os sistemas a jusante leem.

  3. Faça uma conciliação completa dos dados mestres. Sem atalhos: percorra os itens ativos do ERP linha por linha contra o estoque físico do WMS. Cace três coisas — códigos que não batem, nomes/especificações que não batem, e itens zumbis sem atividade mas ainda aparecendo nos documentos. Num projeto a limpeza revelou 7% de zumbis. Deixe-os vivos e o go-live vira um explosivo com timer.

  4. Assine o documento de mapeamento de campos campo a campo. Nada de «mais ou menos funcionando» — cada cabeçalho, linha de pedido, código de item, unidade de medida, número de lote e data de validade recebe uma origem, um destino e uma regra de conversão. Unidades de medida especialmente: fiz quatro projetos em que o ERP usava caixas e o WMS usava peças. Erre o fator de conversão uma única vez e um lote inteiro de documentos vira lixo.

  5. Suba as interfaces de dados mestres antes das transacionais. A sequência não é negociável: sincronização do mestre de itens no ar e conciliada → endereços/clientes/fornecedores no ar → documentos de negócio (POs, ASNs, SOs, devoluções) por último. Inverter essa ordem é testar contra falsos positivos.

  6. Teste com dados sujos de verdade. Os cenários de teste devem incluir os suspeitos habituais: um código de item com um dígito a mais, um nome de cliente com um espaço no fim, um número de lote longo demais. Uma integração testada só com dados limpos é uma integração não testada.

  7. O checklist da véspera do go-live (uso em todos os projetos):

    • Os três padrões de codificação estão congelados, com zero solicitações de mudança abertas?
    • A conciliação completa de itens ERP→WMS terminou com zero divergências?
    • Os mestres de endereços estão sincronizados com o WMS, e os endereços vazios foram verificados?
    • Os itens zumbis estão marcados como inativos, e novos documentos não podem mais referenciá-los?
    • Os fatores de conversão de unidades foram revisados item por item?
    • A reprodução completa de um dia de negócio (PO → recebimento → endereçamento → wave → expedição → callback) rodou verde de ponta a ponta?
    • Qual é o plano de rollback se as interfaces caírem em massa no dia do go-live?

A frequência de sincronização dos dados mestres também vale a pena fixar. Itens, clientes e fornecedores devem se mover quase em tempo real: um item criado no ERP precisa chegar ao WMS em minutos, não da noite para o dia. Os mestres de endereços vivem dentro do WMS e valem de imediato. Vi um projeto que sincronizava itens em lote à meia-noite; às 10 AM o armazém precisava expedir um produto novo cujo item ainda não havia chegado, então as tarefas de picking não podiam ser criadas. Quase tempo real é o piso: se a latência passar de 15 minutos, a interface deve disparar um alerta.

Sessão de testes de integração no armazém

Quando você pode ir transacional primeiro: a jogada híbrida

Há exceções. Se você estiver diante de: um armazém greenfield, zero estoque legado, menos de 500 itens e só dois tipos de documento — então faça um híbrido: regras de dados mestres e interfaces transacionais em paralelo, mas as interfaces de dados mestres ainda entram no ar primeiro. Isso é na prática «dados mestres primeiro» com um cronograma comprimido.

A única exceção genuína que vi: o ERP é um sistema legado que ninguém pode tocar, e o WMS é a construção nova, com o ERP antigo sem nenhuma governança de dados mestres. Minha jogada ali é entregar toda a autoridade de dados mestres ao WMS — o WMS cria itens, endereços, clientes; o ERP só envia documentos e recebe callbacks. «Os dados mestres seguem o sistema novo» continua sendo unificar a língua antes de começar a conversa.

Alerta de detonação: as armadilhas que detonam na noite do go-live

Armadilha um: tamanhos de campo que não batem. O ERP permite 50 caracteres para o nome curto do cliente; o WMS aceita 30. Ninguém conferiu antes do go-live. Os nomes de clientes foram truncados no trânsito, e o mesmo cliente tinha nomes diferentes nos dois sistemas — conciliação impossível. Correção: escreva o tamanho na tabela de mapeamento para cada campo, e defina a política de estouro (truncar ou erro) — escolha uma.

Armadilha dois: fatores de conversão enterrados no código. Alguns integradores hard-codam «1 caixa = 24 peças». O cliente muda a especificação da embalagem; a interface não dá erro; os dados vão se degradando em silêncio por três meses. Correção: o fator precisa ser um campo nos dados mestres de itens, viajando com o item — nunca hard-codado.

Armadilha três: documentos de devolução referenciando itens mortos. O item foi desativado no ERP, mas uma devolução no WMS ainda o referencia. O documento chega, a interface lança «item não encontrado», e o processo de devolução congela. Correção: antes de desativar um item, confira no WMS os documentos abertos que o referenciam — uma porta de pré-validação.

Armadilha quatro: desalinhamento da dimensão organização. A estrutura organizacional do ERP não mapeia um para um com os códigos de armazém do WMS; a interface passa um código de organização e o WMS o resolve para o prédio errado. Correção: o mapeamento de organizações tem sua própria tabela, nunca misturado no mapeamento de itens.

Para o seu próximo projeto de integração ERP-WMS, faça a primeira linha do quadro branco do kickoff dizer «dados mestres primeiro» — e peça às três partes para assiná-la. Você vai me agradecer. Todo projeto que conduzi nessa ordem teve uma noite de go-live tranquila. Todos os que seguiram a ordem inversa me ligaram em pânico à meia-noite.

Por Lin Xiao, consultor de implementação WMS

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.