Se você já passou algum tempo avaliando plataformas B2B, provavelmente chegou à mesma encruzilhada. Opção A: escolher uma loja rápida e moderna (Shopify, BigCommerce, o sabor headless da vez) e escrever integrações que copiem os dados do ERP para dentro dela de forma agendada. Opção B: escolher uma plataforma que converse diretamente com o ERP no momento da requisição. A Sana Commerce está claramente no segundo grupo, e essa única decisão de arquitetura muda quase toda a conversa que vem depois.
O trabalho da loja muda
No modelo de copiar os dados, a loja é dona dos dados. O ERP é uma fonte de retaguarda que mantém a loja abastecida. A loja precisa manter o próprio mecanismo de preços, o próprio estado de estoque, a própria lógica de segmentação de clientes, normalmente como cópias derivadas do que o ERP já sabe. Quando o ERP é a autoridade final de qualquer um desses pontos (e em B2B quase sempre é: faixas de preço, preços por contrato, disponível para promessa, bloqueios por crédito, regras de entrega), a loja vira um lugar onde a verdade do ERP é reinterpretada.
No modelo de ERP primeiro, a loja delega. Quando um cliente autenticado abre a página de um produto, a Sana pergunta ao ERP: "este cliente, este item, hoje, qual é o preço?". O ERP responde. O estoque funciona do mesmo jeito. E também as regras de frete, os bloqueios por crédito, as condições de pagamento e os catálogos específicos por cliente. Não existe uma segunda cópia que possa divergir.
Onde esta é, sem ambiguidade, a escolha certa
Três padrões tornam o "ERP primeiro" a resposta óbvia:
- Preços específicos por cliente que já estão maduros no ERP. Se a sua equipe de vendas passou anos construindo regras de faixas, exceções por contrato e tabelas de desconto por quantidade no NAV / Business Central / S/4HANA, você não vai querer reconstruir esse mecanismo de preços dentro de uma loja, e muito menos vai querer uma cópia que precise ser revalidada toda vez que as regras do ERP mudam.
- Disponível para promessa em tempo real. Um cliente que coloca um pedido de compra com várias linhas precisa ver se o pedido realmente pode ser enviado junto. O disponível para promessa vindo de um ETL periódico é só uma versão pior do que o próprio ERP entrega.
- Bloqueios por crédito e situação da conta. Se o setor de contas a receber coloca um cliente em bloqueio às 15h, a loja não deveria estar vendendo para ele às 15h01.
O compromisso que você está realmente fazendo
A versão honesta da proposta de "ERP primeiro" é: você está trocando um pouco de desempenho de pico por exatidão. Uma loja estática com preços em cache é mais rápida do que uma que vai e volta ao ERP. A Sana ameniza isso com cache e pool de conexões, mas o teto do tempo de carregamento da página é definido pela rapidez com que o seu ERP consegue responder.
Para a maioria dos catálogos B2B (de 1.000 a 100.000 SKUs, de centenas a poucos milhares de compradores autenticados), isso não é o gargalo. Mas se você está empurrando 10 milhões de SKUs em um catálogo público, no qual 95% do tráfego é navegação sem autenticação, vai sentir o peso da integração justamente onde preferiria ter uma página em cache de CDN. A solução não é abandonar o modelo, e sim ser deliberado sobre o que fica atrás do muro de login (e alimentado pelo ERP) e o que fica na frente (e em cache agressivo).
Três coisas para acertar cedo
1. O cadastro do cliente É o contrato de integração
A Sana liga os usuários da web aos cadastros de cliente do ERP. Se o cadastro mestre de clientes do ERP está bagunçado (contas duplicadas, relações pouco claras entre endereço de entrega e de cobrança, atribuições inconsistentes de condições de pagamento), a loja vai expor essa bagunça em lugares que os clientes conseguem ver. Já gastamos mais de um primeiro mês de projeto fazendo limpeza do cadastro mestre de clientes que ninguém havia orçado. Inclua isso no plano.
2. Os complementos vivem sobre o próprio framework da Sana
Se você já construiu em BigCommerce ou Shopify, seu instinto será escrever as integrações à mão como serviços web independentes. A Sana tem o próprio modelo de complementos, e os projetos que o respeitam permanecem fáceis de manter ao longo das atualizações trimestrais da Sana. Os projetos que o contornam acumulam um imposto de atualização e, no fim, acabam tendo que ser reescritos de qualquer forma.
3. Não enfie sorrateiramente uma segunda fonte da verdade
Os projetos de "ERP primeiro" mais caros são aqueles que, no meio do caminho, decidiram colocar um "cache de desempenho" dos dados do catálogo em um serviço separado "só para as páginas de navegação", e então começaram a escrever código de conciliação, depois um painel de sincronização e depois alertas para desvios de sincronização. Agora você tem dois sistemas de registro e perdeu a disciplina de integração pela qual pagou a Sana.
Sana 9.x on-premise versus Sana Commerce Cloud
Se você já está rodando o Sana 9.x, se vale ou não migrar para o Sana Commerce Cloud é uma conversa à parte. A versão curta: o Cloud é um produto diferente, não uma versão hospedada da mesma coisa. O modelo de integração é o mesmo em espírito (ERP primeiro, preços em tempo real, cadastro do cliente como contrato), mas o Cloud usa uma arquitetura SaaS, um stack de frontend mais moderno e um modelo de complementos diferente. Se você personalizou muito o Sana 9.x, "migrar para o Cloud" se parece mais com uma reimplementação do que com uma atualização. Não aceite um discurso de fornecedor que pinte o contrário sem uma avaliação de verdade.
O que isso significa para os compradores
Se você está avaliando plataformas hoje e o seu negócio realmente funciona sobre o ERP, "ERP primeiro" não é uma alegação de marketing, é a decisão de arquitetura que torna o resto do seu programa B2B alcançável sem um exército de engenheiros de integração. Se o seu ERP é leve ou o seu negócio já o superou, as contas são outras. De qualquer modo, o pior desfecho é escolher uma plataforma de "ERP primeiro" e depois tentar usá-la como uma plataforma de copiar os dados. A plataforma não vai brigar com você, mas as pessoas que a mantêm vão se esgotar.
Se você está dimensionando essa decisão em um projeto real, preferimos conversar com você a deixá-lo adivinhar a partir de um post de blog, porque esse é literalmente o trabalho que fazemos. Inicie uma conversa aqui ou saiba mais sobre as nossas capacidades em Sana Commerce.