Quando cada filial decide de um jeito, o ERP deixa de ser controle e vira apenas registro

TL;DR

• Em uma operação com 40 unidades de negócio, ERPs distintos e condições comerciais diferentes, o problema não estava nos sistemas locais, mas na ausência de uma regra comum acima deles.
• O ERP executa e registra. Ele não necessariamente governa preço, crédito e catálogo conforme cliente, região e momento da negociação.
• Trocar todos os sistemas pode ampliar o risco sem corrigir a origem da inconsistência. A alternativa é separar sistema de registro de sistema de decisão.
• A autonomia local pode ser preservada, desde que opere dentro de regras centrais, explícitas e auditáveis.

O seu ERP controla a operação ou apenas registra decisões tomadas em outros lugares?

Para o CEO de uma operação B2B com várias filiais, a fragmentação raramente aparece primeiro como um problema de arquitetura.

Ela surge na margem que varia sem explicação clara, no limite de crédito interpretado de maneiras diferentes, no catálogo que muda entre canais e na condição comercial que depende de quem está disponível para aprovar.

O diagnóstico mais imediato costuma apontar para os sistemas: há ERPs diferentes, integrações acumuladas e particularidades em cada unidade. A conclusão parece lógica, padronizar tudo em um único ambiente.

Mas um caso público identificado como LI-042 mostra outra leitura. A operação tinha 40 unidades de negócio, ERPs distintos e condições comerciais diferentes em cada filial. Segundo o relato, não se tratava de uma operação desorganizada. Faltava algo acima dos sistemas locais para definir o que era permitido.

Cada ERP cumpria sua função de execução. Nenhum havia sido projetado para governar os demais.

Essa distinção muda a decisão de investimento. Se o problema for tratado apenas como diversidade tecnológica, a organização pode iniciar uma substituição ampla sem responder à pergunta central: quem determina, de forma consistente, qual preço, crédito e catálogo são válidos para cada negociação?

O conflito não é entre centralização e autonomia

Preço, crédito e catálogo não são dados estáticos. No caso LI-042, esses três elementos dependiam de quem comprava, de onde comprava e do momento da negociação.

Isso significa que uma tabela central, isoladamente, não resolve o problema. A organização precisa relacionar contexto e política comercial antes que a filial execute a condição.

Sem essa capacidade, dois extremos se tornam comuns:

• A matriz tenta centralizar cada exceção, criando filas e dependência de aprovação.
• As filiais ganham liberdade sem um limite comum, aumentando a variação e reduzindo a rastreabilidade.

Nenhum dos extremos produz boa governança. Centralizar toda ação paralisa a ponta. Descentralizar regras torna o resultado imprevisível.

No caso LI-042, o mecanismo adotado foi uma camada de orquestração acima dos ERPs existentes. Os sistemas locais não foram substituídos nem migrados. Continuaram como sistemas de registro de cada filial, enquanto a camada superior passou a centralizar as regras comerciais e financeiras.

Antes de praticar uma condição, cada filial consultava essa camada. A resposta já considerava o que estava autorizado para determinado cliente, região e momento.

O resultado relatado foi consistência sem eliminar a autonomia local onde ela era necessária.

Sistema de registro e sistema de decisão cumprem papéis diferentes

O ERP registra estoque, pedido e demais efeitos operacionais da transação. A governança comercial precisa atuar antes, no intervalo em que a intenção de compra ainda está sendo convertida em uma condição possível.

É nesse espaço que surgem as perguntas relevantes para o board:

• O preço está dentro da política aplicável àquele cliente e canal?
• O crédito disponível permite essa condição?
• O catálogo oferecido corresponde à região e ao contexto da compra?
• A exceção está autorizada?
• A decisão pode ser reconstruída posteriormente?

O artigo da CWS Platform, “Seu ERP não é o problema”, sustenta a mesma separação: o ERP funciona como sistema de registro, enquanto uma camada de governança decide preço, crédito e aprovações antes que o pedido seja confirmado.

A arquitetura, portanto, não precisa disputar espaço com os sistemas instalados. Ela precisa definir o que esses sistemas têm permissão para executar.

A demora comercial também pode ser um problema de arquitetura

A ausência de regras formalizadas não produz apenas inconsistência. Ela transforma cada negociação em uma sequência de consultas.

Outro caso público do acervo, identificado como LI-038, relata uma operação em que responder a uma cotação levava cinco dias úteis. O processo dependia de consultar tabela, verificar estoque, solicitar aprovação de crédito e confirmar prazo por e-mail.

Segundo o caso, quando preço, limite de crédito e exceções foram formalizados no fluxo digital, o ciclo passou de cinco dias para minutos, sem substituir o vendedor e sem exigir intervenção humana na maioria das situações.

A comparação ajuda a tornar o diagnóstico mais preciso. O gargalo não era falta de esforço da equipe. A lógica comercial existia, mas estava distribuída entre pessoas, planilhas e aprovações informais.

Quando a decisão depende de quem está disponível, o organograma se torna parte da infraestrutura tecnológica. Para crescer, a empresa precisa adicionar pessoas capazes de interpretar, validar e costurar regras. A receita pode aumentar, mas a complexidade cresce junto com o custo operacional.

O Custo da Inação

Adiar essa separação entre registro e decisão não mantém a operação neutra. Mantém decisões relevantes fora de uma governança comum.

Os efeitos tendem a aparecer de forma fragmentada:

• Condições comerciais diferentes para contextos equivalentes.
• Tempo de resposta condicionado à disponibilidade de vendedores e gestores.
• Exceções sem um histórico claro de autorização.
• Expansão para novas filiais acompanhada de mais consultas e aprovações.
• Dificuldade para distinguir autonomia legítima de desvio de política.
• Projetos de troca de ERP usados para tentar resolver uma lacuna que não está no registro.

O risco financeiro não está apenas em uma condição incorreta. Está na repetição de pequenas decisões sem uma referência central, algo que dificulta medir o impacto agregado sobre margem, crédito e produtividade.

Também há um custo de oportunidade. Enquanto a liderança discute uma possível substituição de sistemas, a operação continua negociando diariamente pelas mesmas rotas informais.

Princípios para reorganizar a decisão comercial

• Diagnosticar antes de migrar: identificar se a falha está no ERP ou na ausência de uma política comum acima dele.
• Separar regra de execução: os sistemas locais podem executar sem serem proprietários de toda a lógica comercial.
• Centralizar políticas, não toda ação: a ponta deve agir com autonomia dentro de limites previamente definidos.
• Formalizar o que hoje depende de experiência individual: preço, crédito, catálogo e exceções precisam ser traduzidos em regras explícitas.
• Preservar contexto: uma regra central não deve ignorar cliente, região, canal ou momento da negociação.
• Registrar a decisão, não apenas o pedido: a organização precisa saber qual política autorizou cada condição.
• Governar antes de automatizar: acelerar um fluxo sem critérios claros apenas torna a inconsistência mais rápida.
• Preparar o uso responsável de IA: a IA pode ampliar capacidade de análise e resposta, mas precisa operar sobre regras, permissões e registros verificáveis.

FAQ

É necessário substituir os ERPs das filiais?

Não segundo o caso LI-042. Os ERPs existentes foram preservados como sistemas de registro local. A mudança ocorreu com a inclusão de uma camada superior para governar as regras comerciais e financeiras.

Governança central elimina a autonomia das unidades?

Não necessariamente. No caso relatado, a operação ganhou consistência sem abrir mão da autonomia local. A diferença é que a ação passou a ocorrer dentro do que estava autorizado para cada contexto.

Uma tabela única de preços resolve o problema?

Não quando preço, crédito e catálogo dependem de cliente, região e momento. A organização precisa de regras capazes de interpretar esses fatores antes da execução.

Automatizar aprovações é suficiente?

Não. Primeiro é preciso formalizar critérios, alçadas e exceções. A automação deve executar uma governança definida, não substituir a definição da política.

Quem já vive isso

No portal público Capterra, Rodrigo S., Gerente Comercial, resume a relação entre governança comercial e infraestrutura existente:

“A plataforma unificou nossos canais de venda e integrou com nosso ERP sem substituí-lo.”

Fonte: Capterra

Sobre esta publicação

“O Custo da Venda” analisa como decisões, aprovações e exceções afetam a eficiência financeira da operação comercial B2B.

Nesse contexto, o custo de transação não está apenas no processamento do pedido. Ele inclui o tempo e a estrutura necessários para descobrir preço, validar crédito, conferir catálogo e obter aprovação.

A CWS Platform atua como uma B2B Commerce Platform for Governed Negotiation. Sua abordagem é compor com os ERPs existentes, estruturando uma camada de decisão para que a negociação opere com regras explícitas, contexto e rastreabilidade.

O objetivo arquitetural não é retirar decisão das pessoas. É transformar o DNA de negociação da empresa em um ativo governado, capaz de apoiar vendedores, filiais e novas aplicações de IA sem converter toda variação comercial em mais filas, consultas e dependência humana.

Fontes

• LI-042, caso público sobre ERP e orquestração: relato de uma operação com 40 unidades de negócio, ERPs distintos e regras comerciais centralizadas acima dos sistemas locais. Link não fornecido no material-base.
• LI-038, caso público sobre formalização da decisão comercial: caso em que o ciclo de cotação passou de cinco dias úteis para minutos. Link não fornecido no material de apoio.
• CWS Platform, “Seu ERP não é o problema. O que governa o que acontece”: análise sobre a separação entre sistemas de registro e governança da negociação B2B. Acessar publicação
• Capterra, avaliação pública de Rodrigo S., Gerente Comercial: depoimento sobre integração com o ERP sem substituição. Acessar avaliação