Encomendas de ecommerce no ERP: 4 arquiteturas de integração

Uma integração de ecommerce é uma pequena peça de software com um raio de falha desproporcionado. Quando funciona, ninguém pensa nela. Quando falha, um cliente pagou por algo que o armazém não sabe que existe, a área financeira retém rédito que não pode reconhecer, e o número na loja online e o número no ERP não coincidem — o que significa que, durante algum tempo, ninguém na empresa sabe o que foi efetivamente vendido.

Existem essencialmente quatro arquiteturas para levar as encomendas de uma loja online até um ERP. Todas as quatro estão em produção em empresas mid-market reais neste momento. Todas as quatro são a escolha correta em determinada circunstância e desastrosas noutras, e a falha quase nunca está no código: está no desajuste entre a arquitetura escolhida e o volume, o número de canais e a tolerância ao erro do negócio que a utiliza.

Este artigo apresenta as quatro, o ponto em que cada uma se quebra e como saber qual deveria estar a utilizar.

Por que razão isto importa

Três forças tornaram esta decisão mais difícil para as empresas mid-market do que era há cinco anos.

O número de canais cresceu mais depressa do que os orçamentos de integração. Uma empresa que vendia através de uma loja online vende agora através de uma loja online, dois ou três marketplaces, possivelmente um portal B2B e um canal social. Cada um tem o seu próprio esquema de encomenda, o seu próprio modelo de liquidação e a sua própria ideia do que é um cliente. Uma arquitetura que era adequada para um canal é muitas vezes silenciosamente inadequada para cinco.

O volume de encomendas é irregular, não linear. O ecommerce mid-market é sazonal, promocional e cada vez mais orientado por campanhas. Uma integração por lotes confortável com 200 encomendas por dia de forma estável pode não sobreviver a 3 000 numa tarde — e o pico de vendas é precisamente o momento em que a falha é mais cara.

As expectativas do cliente já incluem o back office. A disponibilidade de stock em tempo real, as promessas de entrega precisas e a visibilidade imediata do estado da encomenda são todas funções da rapidez e da fiabilidade com que o ERP e a loja online concordam entre si. A latência de integração passou a ser um atributo visível para o cliente.

Num relance: as quatro arquiteturas

Em termos gerais: a opção 1 é onde a maioria das empresas mid-market deveria começar, a opção 3 é onde a maioria acaba, a opção 2 é onde a maioria fica presa, e a opção 4 está correta menos vezes do que os seus defensores sugerem.

As quatro em detalhe

1. Conector nativo.
Uma integração pré-construída, normalmente mantida pelo fornecedor da loja online, pelo fornecedor do ERP ou por um terceiro. A mais rápida a implementar — semanas em vez de meses — e a mais barata por larga margem. A contrapartida é que herda o modelo de outra pessoa sobre como uma encomenda deve fluir.

Falha de três formas. A sua lógica de negócio excede o que o conector expõe: uma regra de preços, um tratamento fiscal, uma divisão de expedição para a qual não foi concebido. O número de canais cresce e vê-se a operar três conectores com três comportamentos diferentes de tratamento de erros e sem qualquer visão consolidada. Ou o roteiro do fornecedor afasta-se das suas necessidades e fica à espera de uma funcionalidade que pode nunca chegar.

2. Desenvolvimento à medida point-to-point.
Código específico direto entre dois sistemas. Controlo total, exatamente a lógica que especificou. Esta é a resposta correta quando um único canal é estrategicamente crítico e a sua lógica é genuinamente invulgar — e existe um engenheiro que o mantém.

A falha é aritmética. Cada novo sistema multiplica as ligações, e cada ligação traz a sua própria lógica de repetição, gestão de credenciais e reporte de erros. Uma alteração de tabela de preços toca em todos os desenvolvimentos. O conhecimento documentado vive com quem o escreveu, e as empresas mid-market raramente retêm essa pessoa durante toda a vida da integração. É a arquitetura em que mais frequentemente encontramos empresas presas, precisamente porque funcionou tão bem no primeiro canal.

3. Plataforma de integração.
Uma plataforma central intermedeia todos os canais: transformação num só lugar, tratamento de erros consistente, lógica de repetição, monitorização e um registo de auditoria. Acrescentar um quarto canal passa a ser configuração em vez de projeto. Para uma empresa mid-market com vários canais e requisitos em mudança, esta é normalmente a arquitetura correta, e é onde se concentra o nosso trabalho com clientes — tipicamente sobre uma plataforma de integração da qual a Atypical Tech é parceira, com agentes de IA a tratar da classificação e do encaminhamento de exceções em vez de despejar as falhas numa fila que ninguém lê.

O seu modo de falha é organizacional. Como os fluxos são fáceis de criar, proliferam. Em dois anos existe uma camada de lógica de negócio não documentada que ninguém compreende por completo, o que é o mesmo problema da opção 2 com melhor roupagem. As plataformas precisam de responsáveis, convenções de nomenclatura, documentação e revisão periódica: governação, não tecnologia.

4. Middleware orientado a eventos.
Os sistemas publicam eventos; os consumidores subscrevem de forma independente. É genuinamente a resposta correta com volume elevado, tráfego irregular e vários consumidores do mesmo evento de encomenda — um sistema de armazém, uma verificação antifraude, um pipeline analítico e um serviço de notificação ao cliente, todos a reagir a uma única encomenda.

Falha por maturidade organizacional mais do que por tecnologia. A arquitetura orientada a eventos exige pessoas à vontade com consistência eventual, idempotência e replay, e as equipas mid-market muitas vezes não as têm nem as conseguem contratar. Falha também quando o negócio não interiorizou o que significa consistência eventual: «a encomenda existe mas o número de stock ainda não acompanhou» é um estado legítimo nesta arquitetura e inaceitável para um diretor financeiro a quem ninguém o explicou.

O que é preciso admitir com honestidade

A arquitetura raramente é a restrição determinante. Falham mais integrações por qualidade de dados e tratamento de erros do que por escolha arquitetónica. Se a loja online conseguir criar um registo de cliente que o ERP vai rejeitar, nenhuma arquitetura o salva.

Ninguém quer financiar o tratamento de erros. O caminho feliz é talvez 60% do trabalho; os restantes 40% são o que acontece quando o pagamento é bem-sucedido e a encomenda falha, quando um produto não existe no ERP, quando um marketplace envia um reembolso parcial. Os projetos que saltam esta parte entram em produção a horas e consomem pessoal de operações indefinidamente depois.

Migrar de arquitetura é caro e normalmente necessário. Passar de point-to-point para uma plataforma implica manter ambas em paralelo, reconciliar e fazer o corte num período fora de pico. É um projeto a sério. É também a decisão correta mais vezes do que os clientes querem ouvir.

Tempo real não é sempre o mais adequado. A sincronização de encomendas em tempo real é normalmente correta. A sincronização de inventário em tempo real para todos os canais pode gerar carga e condições de corrida desproporcionadas face ao seu valor; um pequeno buffer com lógica de reserva serve muitas vezes melhor o cliente do que o tempo real puro.

Os agentes ajudam nas exceções, não na arquitetura. Um agente de IA que classifica as falhas, resolve as mecânicas e encaminha as restantes com o contexto anexado reduz materialmente o custo operacional de qualquer uma destas quatro opções. Não torna boa uma má adequação arquitetónica.

Quadro de decisão: como escolher a sua arquitetura

Percorra-o por ordem. Pare na primeira correspondência.

1. Tem um ou dois canais convencionais, lógica de encomenda padrão e nenhum plano imediato de acrescentar mais?
Use um conector nativo. Não desenvolva. A engenharia que gastaria é melhor aproveitada noutro sítio, e pode migrar mais tarde se a restrição aparecer.

2. Tem um canal estrategicamente crítico com lógica genuinamente invulgar e um engenheiro de manutenção no quadro de efetivos para o futuro previsível?
Um desenvolvimento point-to-point é defensável. Documente o mapeamento fora do código e defina um gatilho de revisão: no momento em que for planeado um segundo canal, reavalie.

3. Tem três ou mais canais, ou requisitos que mudam mais de uma ou duas vezes por ano?
Use uma plataforma de integração e atribua um responsável identificado antes de construir o primeiro fluxo. A maioria das empresas mid-market que lê este artigo está nesta linha.

4. Tem volume elevado e irregular, vários consumidores independentes dos eventos de encomenda e engenheiros que já operaram sistemas orientados a eventos?
O middleware orientado a eventos é apropriado. Se cumpre as duas primeiras condições mas não a terceira, use uma plataforma e reavalie dentro de um ano — não aprenda esta arquitetura em plena época de pico.

5. Está atualmente em point-to-point com mais de dois canais?
A sua arquitetura é o problema, independentemente de tudo o que vem acima. Planeie uma migração para uma plataforma, sequenciada fora do pico de vendas, a correr em paralelo com reconciliação até ter confiança.

6. Tudo o que vem acima resolvido e as encomendas continuam a falhar?
O problema é a qualidade dos dados ou o tratamento de erros, não a arquitetura. Instrumente as falhas, classifique-as durante quinze dias e corrija as três categorias principais — que serão normalmente desajustes de master data (dados mestre) e não defeitos de integração.

Custo e esforço indicativos

Pressupõe uma única instância de ERP e um perfil transacional mid-market. Um tratamento fiscal complexo, estruturas multientidade ou a reconciliação de liquidações de marketplace alargam estes prazos. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Podemos começar com um conector nativo e migrar mais tarde?
Sim, e para a maioria das empresas essa é a sequência correta. Reduza agora o custo da migração documentando a lógica do seu fluxo de encomendas fora da configuração do conector, para que, quando migrar, não esteja a fazer engenharia inversa das suas próprias regras de negócio.

Como tratamos as liquidações de marketplace?
Em separado da integração de encomendas, e deliberadamente. Os pagamentos de marketplace chegam líquidos de comissões, agrupados por muitas encomendas e segundo o calendário do marketplace — reconciliá-los com encomendas individuais é um problema distinto que exige a sua própria lógica de correspondência. Tratá-lo como parte da integração de encomendas é um erro comum e caro.

A sincronização de inventário deve ser em tempo real?
Normalmente não em tempo real estrito. Uma atualização quase em tempo real com um buffer de reserva serve melhor o cliente do que o tempo real puro, que é propenso a condições de corrida quando dois canais vendem a última unidade no mesmo segundo. O que importa é que a venda em excesso seja evitada, e a lógica de reserva consegue-o com mais fiabilidade do que a velocidade de atualização.

O que acontece às encomendas que falham na integração?
Esta é a pergunta que separa uma integração que funciona de uma frágil. As encomendas falhadas têm de aterrar em algum lugar visível, com o motivo anexado, um responsável e um caminho de resolução definido — não num ficheiro de log. Se a sua resposta atual é «alguém repara», tem uma lacuna no tratamento de erros independentemente da arquitetura.

Precisamos também de um data warehouse?
Para reporting, com o tempo sim — mas não como parte disto. A integração de encomendas é um fluxo operacional; a analítica é uma preocupação separada. Combiná-las tende a produzir uma integração otimizada para reporting e pouco fiável em termos operacionais.

Com que rapidez se pode realmente implementar uma destas arquiteturas?
Depende de qual. Uma ponte provisória por CSV ou manual são dias; um conector nativo ou uma integração por middleware costuma levar 6 a 12 semanas. A arquitetura de sincronização em tempo real costuma ser a mais rápida de montar tecnicamente — um parceiro certificado como Stacksync pode ter a sincronização bidirecional de pedidos a funcionar em poucas semanas — mas antes é preciso fechar as decisões de mapeamento e tratamento de exceções das secções anteriores, ou terá automatizado rapidamente o fluxo errado em vez do certo devagar.

Fecho — Próximos passos

As quatro arquiteturas não são uma escada de maturidade. Um negócio de canal único que opera bem um conector nativo está em melhor forma do que um negócio de cinco canais com quatro desenvolvimentos à medida, independentemente de qual pareça mais sofisticado. A única pergunta que vale a pena fazer é se a sua arquitetura corresponde hoje ao seu número de canais, ao seu perfil de volume e à sua tolerância ao erro, com um caminho plausível para onde estará dentro de dois anos.

Um ponto de partida prático: conte os seus canais, conte as suas ligações de integração e retire quinze dias de encomendas falhadas com os respetivos motivos. Esses três números dir-lhe-ão em que linha do quadro está e se o problema real é a arquitetura ou os dados.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. É especialista em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas de vendas e financeira. Como parceiro oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e auto-monitorizados.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são a nível de publicação e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de integração e SuiteTalk — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, investigação sobre plataformas de integração e iPaaS (em grande medida de acesso a clientes) — https://www.gartner.com
• Comissão Europeia, VAT in the Digital Age (ViDA) — requisitos de reporte digital e de faturação eletrónica que afetam o ecommerce transfronteiriço — https://taxation-customs.ec.europa.eu
• Agencia Tributaria (Espanha), Suministro Inmediato de Información (SII) — https://sede.agenciatributaria.gob.es
• Experiência de projetos da Atypical Tech, integrações de ecommerce e ERP no mid-market da Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog