Se você está montando uma loja Sana Commerce e pergunta "quem a constrói?", a resposta honesta é que a pergunta tem duas respostas, e a maioria dos projetos Sana só aloca pessoal para uma delas. O ecossistema de parceiros da Sana é construído em torno dos parceiros de implementação de ERP: as firmas que já vivem dentro da sua instância de Business Central, S/4HANA, NAV ou F&O. Elas são a escolha natural para conectar a Sana ao ERP, porque esse é o trabalho que fazem todos os dias. Mas "conectar a Sana ao ERP" e "construir uma loja que converte" não são o mesmo trabalho, e o segundo raramente vem junto com o primeiro.
Nós fazemos trabalho de Sana como agência de web, design e desenvolvimento. Não somos um VAR de ERP, e não fingimos ser. Essa distinção é todo o propósito deste ensaio, porque entendê-la é a forma de evitar a maneira mais comum pela qual um projeto Sana decepciona em silêncio: uma integração precisa parafusada a uma loja que ninguém projetou.
Por que a lacuna existe (é estrutural, não preguiça)
A Sana vende por meio de um canal de parceiros, e esse canal é dominado por parceiros de ERP por um bom motivo. A promessa central da Sana é o comércio integrado ao ERP: preços, estoque e lógica de cliente em tempo real servidos diretamente do ERP. Vender e entregar essa promessa exige parceiros capazes de dialogar com fluência com o lado do ERP. Por isso, os incentivos da Sana, suas certificações e suas ações de venda conjunta orientam-se todos para os implementadores de ERP. É um negócio sólido. Também é a origem da lacuna.
Porque eis o que acontece com as firmas de implementação de ERP: o centro de gravidade delas é a correção, não a conversão. Elas são excelentes em deixar o preço certo, o imposto certo, a lógica de bloqueio por crédito certa, as regras de local de entrega certas. Isso é inegociável e genuinamente difícil. Mas o ofício do front-end (a tipografia, o layout responsivo, a acessibilidade, o orçamento de velocidade de página, o merchandising, o trabalho de fricção no checkout) é outra disciplina, com outro grupo de talentos. Pedir a um parceiro de ERP que também seja um estúdio de front-end de primeira linha é como pedir ao seu engenheiro estrutural que também seja seu designer de interiores. Algumas firmas têm as duas coisas. A maioria não tem, e não há vergonha nisso.
Os dois trabalhos em um projeto Sana
Ajuda nomear os dois trabalhos com clareza, porque assim que você os enxerga como separados, a decisão de alocação de pessoal se responde sozinha.
O trabalho um é a integração. Mapear usuários web para registros de cliente do ERP, validar que a lógica de preços, ATP e crédito retorne correta para cada segmento de cliente, lidar com a bagunça de dados mestre de cliente que sempre aparece, construir complementos dentro do próprio framework da Sana para que sobrevivam às atualizações trimestrais. Este é território do parceiro de ERP. Se você tentar fazê-lo com uma firma puramente web que nunca tocou no seu ERP, vai sentir na pele.
O trabalho dois é a loja. Arquitetura de informação, design visual, a construção do front-end, acessibilidade conforme WCAG, Core Web Vitals, merchandising, o caminho de conversão, o conteúdo. Este é território da agência. Se você tentar fazê-lo com uma firma puramente de ERP, vai obter uma loja correta e esquecível. O correto importa. O esquecível custa receita a cada dia em que está no ar.
Quem é dono de quê: a divisão limpa
Os projetos que dão certo são aqueles em que a linha entre esses dois trabalhos é traçada explicitamente já no primeiro dia. Esta é a divisão que aplicamos, e a que recomendaríamos mesmo em projetos dos quais não fazemos parte.
O parceiro de ERP é dono de
- O conector do ERP e a saúde da integração. Preços, estoque, ATP, bloqueios por crédito, condições de pagamento, catálogos específicos por cliente em tempo real. Os dados precisam estar certos; essa é a missão deles.
- A relação com os dados mestre de cliente. O mapeamento de usuário web para cliente do ERP, local de entrega vs faturamento, limpeza de duplicados, o trabalho de qualidade de dados que ninguém coloca no escopo e com o qual todos esbarram.
- A lógica de negócio do lado do ERP e os complementos que tocam dados do ERP. Construídos sobre o framework de complementos da Sana para que sobrevivam às atualizações.
- O ambiente do ERP, os dados de teste e a validação de que os preços retornam corretamente por segmento.
A agência web é dona de
- A arquitetura de informação e a UX. Navegação, busca, exploração por facetas, a experiência do comprador autenticado, o caminho do pouso até a recompra.
- O design visual e a construção do front-end. O tema da Sana, o layout responsivo, o design system, a expressão de marca dentro dos templates da Sana.
- A acessibilidade e o desempenho. Conformidade com WCAG, caminhos de teclado e leitor de tela, Core Web Vitals, o orçamento de velocidade de página que uma loja alimentada pelo ERP torna mais difícil, não mais fácil.
- A conversão e o merchandising. O layout da página de produto, a redução de fricção no checkout, os fluxos de requisição e recompra, o conteúdo, as coisas que movem o número.
- Os complementos de front-end e a lógica de apresentação. Construídos sobre o framework da Sana, mas voltados a como a loja aparece e se comporta, não ao que o ERP diz.
Compartilhado, e merecedor de uma reunião fixa
- A costura entre os dados do ERP e a apresentação. Como um bloqueio por crédito é exibido, como uma linha em falta se comporta no checkout, como os catálogos específicos por cliente conduzem a navegação. Nenhum dos dois lados é dono disso sozinho, e é onde os projetos quebram quando ninguém está de olho.
- O caminho de atualização. Ambos os lados escrevem complementos. Ambos os lados precisam mantê-los seguros para atualizações. Um único plano de testes de atualização trimestral, não dois.
O modo de falha quando uma só firma tenta fazer as duas coisas
A decepção Sana mais comum que nos chamam para consertar é a construção integral do parceiro de ERP: a integração é impecável e a loja parece um painel de administração de 2014. O preço está certo até o centavo. O comprador não acha o produto, o layout móvel está quebrado, o checkout tem três passos evitáveis e a auditoria de acessibilidade falha já na primeira varredura automática. Nada disso é uma crítica ao parceiro de ERP. É o resultado previsível de pedir a uma disciplina que entregue duas.
A falha oposta também existe, e é pior. Uma agência puramente web sem fluência em ERP assume o projeto inteiro, trata a Sana como se fosse Shopify, escreve integrações à mão fora do framework de complementos e entrega algo que quebra na próxima atualização da Sana e que nunca retornou preços corretos para os clientes com condições contratuais. Não aceitamos esses projetos sem um parceiro de ERP na integração, e você também não deveria entregar um projeto dessa forma.
A versão citável: um VAR de ERP deixa o preço certo; uma agência web faz a loja vender. Um projeto Sana precisa dos dois, e a maioria só tem pessoal para um.
Como alocar o pessoal, na prática
Se você conduz a contratação, a estrutura mais limpa são dois contratos com uma costura explícita. Seu parceiro de ERP (muitas vezes o seu implementador atual) é dono do escopo de integração. Sua agência web é dona do escopo da loja. Você define a costura (a lista compartilhada acima) por escrito antes de qualquer um começar, e coloca os dois líderes no mesmo standup semanal. É isso. O custo extra de duas firmas é real, mas pequeno, e sai muito mais barato do que o retrabalho quando uma única firma generalista entrega de menos na metade para a qual não foi feita.
Se você prefere ter um só responsável a quem cobrar, tudo bem, mas faça do contratante principal aquele cuja fraqueza você possa custear melhor. Se o seu ERP é complicado e a sua marca é simples, deixe o parceiro de ERP ser o principal e subcontratar o design. Se o seu ERP é um Business Central limpo e suas metas de marca e conversão são ambiciosas, deixe a agência ser a principal e subcontratar o conector. Só não finja que a metade fraca não existe porque há um único logotipo na fatura.
Onde o fato de a Sana ser amigável a agências realmente ajuda
É preciso reconhecer: a plataforma da Sana não briga com o papel da agência. O modelo de temas e complementos dá a uma equipe de front-end espaço real para trabalhar sem tocar na lógica do ERP, que é exatamente a separação de responsabilidades de que essa divisão de trabalho precisa. Uma agência disciplinada pode ser dona de toda a camada de apresentação e jamais colocar uma segunda fonte de verdade à frente do ERP. É a arquitetura funcionando como pretendido: o ERP segue sendo o sistema de registro, a agência é dona da experiência, e os dois se encontram em uma costura documentada.
O que isso significa para os compradores
Se você só lembrar de uma coisa: quando um parceiro de Sana disser que vai "cuidar de tudo", pergunte em qual metade ele é realmente bom. A integração com o ERP e a loja são dois ofícios. A plataforma foi construída supondo que ambos apareceriam. O canal de parceiros foi construído supondo que o primeiro apareceria. Cuide dessa lacuna de propósito, aloque pessoal para as duas, e você obtém o que a Sana de fato promete: uma loja precisa, alimentada pelo ERP, da qual as pessoas também querem comprar.
Somos uma agência de web, design e desenvolvimento certificada pela Sana, e a metade da loja é o trabalho que fazemos. Se você já tem um parceiro de ERP definido e precisa da metade que eles não cobrem (ou não tem certeza de como dividir), comece uma conversa. Você também pode ler mais sobre como trabalhamos como agência de Sana Commerce, nossas capacidades mais amplas em Sana Commerce, ou como a Sana se compara à BigCommerce se você ainda estiver escolhendo a plataforma.