Si estás montando una tienda Sana Commerce y preguntas "¿quién la construye?", la respuesta honesta es que la pregunta tiene dos respuestas, y la mayoría de los proyectos Sana solo asignan personal para una de ellas. El ecosistema de socios de Sana está construido en torno a los socios de implementación de ERP: las firmas que ya viven dentro de tu instancia de Business Central, S/4HANA, NAV o F&O. Son la opción natural para conectar Sana con el ERP, porque ese es el trabajo que hacen todos los días. Pero "conectar Sana con el ERP" y "construir una tienda que convierta" no son el mismo trabajo, y el segundo rara vez viene con el primero.
Nosotros hacemos trabajo de Sana como agencia web, de diseño y de desarrollo. No somos un VAR de ERP, y no fingimos serlo. Esa distinción es todo el propósito de este ensayo, porque entenderla es la forma de evitar la manera más común en que un proyecto Sana decepciona en silencio: una integración precisa atornillada a una tienda que nadie diseñó.
Por qué existe la brecha (es estructural, no por flojera)
Sana vende a través de un canal de socios, y ese canal está dominado por socios de ERP por una buena razón. La promesa central de Sana es el comercio integrado con el ERP: precios, inventario y lógica de cliente en tiempo real servidos directamente desde el ERP. Vender y entregar esa promesa exige socios que puedan dialogar con fluidez con el lado del ERP. Así que los incentivos de Sana, sus certificaciones y sus movimientos de venta conjunta se orientan todos hacia los implementadores de ERP. Es un negocio sólido. También es el origen de la brecha.
Porque esto es lo que pasa con las firmas de implementación de ERP: su centro de gravedad es la corrección, no la conversión. Son excelentes para dejar bien el precio, bien el impuesto, bien la lógica de retención por crédito, bien las reglas de destino de envío. Eso es innegociable y de verdad difícil. Pero el oficio del front-end (la tipografía, el diseño responsivo, la accesibilidad, el presupuesto de velocidad de página, el merchandising, el trabajo de fricción en el checkout) es otra disciplina con otro grupo de talento. Pedirle a un socio de ERP que además sea un estudio de front-end de primer nivel es como pedirle a tu ingeniero estructural que también sea tu diseñador de interiores. Algunas firmas tienen ambas cosas. La mayoría no, y no hay nada de qué avergonzarse.
Los dos trabajos en un proyecto Sana
Ayuda nombrar los dos trabajos con claridad, porque una vez que los ves como separados, la decisión de asignación de personal se responde sola.
El trabajo uno es la integración. Mapear usuarios web a registros de cliente del ERP, validar que la lógica de precios, ATP y crédito regrese correcta para cada segmento de cliente, manejar el desorden de datos maestros de cliente que siempre aflora, construir complementos dentro del propio framework de Sana para que sobrevivan a las actualizaciones trimestrales. Este es territorio del socio de ERP. Si intentas hacerlo con una tienda puramente web que nunca ha tocado tu ERP, lo vas a sentir.
El trabajo dos es la tienda. Arquitectura de información, diseño visual, la construcción del front-end, accesibilidad según WCAG, Core Web Vitals, merchandising, la ruta de conversión, el contenido. Este es territorio de la agencia. Si intentas hacerlo con una firma puramente de ERP, obtendrás una tienda correcta y olvidable. Lo correcto importa. Lo olvidable te cuesta ingresos cada día que está en línea.
Quién es dueño de qué: la división limpia
Los proyectos que salen bien son aquellos en los que la línea entre estos dos trabajos se traza explícitamente desde el primer día. Esta es la división que aplicamos, y la que recomendaríamos incluso en proyectos en los que no participamos.
El socio de ERP es dueño de
- El conector del ERP y la salud de la integración. Precios, inventario, ATP, retenciones por crédito, condiciones de pago, catálogos específicos por cliente en tiempo real. Los datos tienen que estar bien; esa es su misión.
- La relación con los datos maestros de cliente. El mapeo de usuario web a cliente del ERP, destino de envío vs facturación, limpieza de duplicados, el trabajo de calidad de datos que nadie incluye en el alcance y con el que todos se topan.
- La lógica de negocio del lado del ERP y los complementos que tocan datos del ERP. Construidos sobre el framework de complementos de Sana para que sobrevivan a las actualizaciones.
- El entorno del ERP, los datos de prueba y la validación de que los precios regresan correctamente por segmento.
La agencia web es dueña de
- La arquitectura de información y la UX. Navegación, búsqueda, exploración por facetas, la experiencia del comprador autenticado, la ruta desde la llegada hasta el repedido.
- El diseño visual y la construcción del front-end. El tema de Sana, el diseño responsivo, el sistema de diseño, la expresión de marca dentro de las plantillas de Sana.
- La accesibilidad y el rendimiento. Conformidad con WCAG, rutas de teclado y lector de pantalla, Core Web Vitals, el presupuesto de velocidad de página que una tienda alimentada por el ERP vuelve más difícil, no más fácil.
- La conversión y el merchandising. El diseño de la ficha de producto, la reducción de fricción en el checkout, los flujos de requisición y repedido, el contenido, las cosas que mueven el número.
- Los complementos de front-end y la lógica de presentación. Construidos sobre el framework de Sana, pero ocupados de cómo se ve y se comporta la tienda, no de lo que dice el ERP.
Compartido, y digno de una reunión fija
- La costura entre los datos del ERP y la presentación. Cómo se muestra una retención por crédito, cómo se comporta una línea agotada en el checkout, cómo los catálogos específicos por cliente impulsan la navegación. Ninguno de los dos lados es dueño de esto en solitario, y es donde los proyectos se rompen cuando nadie lo vigila.
- La ruta de actualización. Ambos lados escriben complementos. Ambos lados tienen que mantenerlos seguros ante actualizaciones. Un solo plan de pruebas de actualización trimestral, no dos.
El modo de falla cuando una sola firma intenta hacer ambas cosas
La decepción Sana más común que nos llaman a arreglar es la construcción integral del socio de ERP: la integración es impecable y la tienda parece un panel de administración de 2014. El precio está bien hasta el centavo. El comprador no encuentra el producto, el diseño móvil está roto, el checkout tiene tres pasos evitables y la auditoría de accesibilidad falla en el primer escaneo automático. Nada de eso es un reproche al socio de ERP. Es el resultado previsible de pedirle a una disciplina que entregue dos.
La falla opuesta también existe, y es peor. Una agencia puramente web sin fluidez en ERP toma el proyecto completo, trata a Sana como si fuera Shopify, escribe integraciones a mano fuera del framework de complementos y entrega algo que se rompe en la siguiente actualización de Sana y que nunca regresó precios correctos para los clientes con condiciones contractuales. No tomamos esos proyectos sin un socio de ERP en la integración, y tú tampoco deberías repartirlos así.
La versión citable: un VAR de ERP deja bien el precio; una agencia web hace que la tienda venda. Un proyecto Sana necesita ambas cosas, y la mayoría solo tiene personal para una.
Cómo asignar el personal, en concreto
Si tú llevas la contratación, la estructura más limpia son dos contratos con una costura explícita. Tu socio de ERP (a menudo tu implementador actual) es dueño del alcance de integración. Tu agencia web es dueña del alcance de la tienda. Defines la costura (la lista compartida de arriba) por escrito antes de que cualquiera empiece, y pones a ambos líderes en el mismo standup semanal. Eso es todo. El sobrecosto de dos firmas es real pero pequeño, y resulta mucho más barato que el retrabajo cuando una sola firma generalista entrega de menos en la mitad para la que no está hecha.
Si prefieres tener un solo responsable a quien reclamar, está bien, pero que el contratista principal sea aquel cuya debilidad puedas costear mejor. Si tu ERP es complicado y tu marca es simple, deja que el socio de ERP sea el principal y subcontrate el diseño. Si tu ERP es un Business Central limpio y tus metas de marca y conversión son ambiciosas, deja que la agencia sea la principal y subcontrate el conector. Solo no finjas que la mitad débil no existe porque hay un solo logotipo en la factura.
Dónde ayuda de verdad que Sana sea amigable con las agencias
Hay que reconocérselo a Sana: la plataforma no pelea contra el rol de la agencia. El modelo de temas y complementos le da a un equipo de front-end espacio real para trabajar sin tocar la lógica del ERP, que es exactamente la separación de responsabilidades que esta división del trabajo necesita. Una agencia disciplinada puede ser dueña de toda la capa de presentación y nunca poner una segunda fuente de verdad por delante del ERP. Esa es la arquitectura funcionando como se pensó: el ERP sigue siendo el sistema de registro, la agencia es dueña de la experiencia, y los dos se encuentran en una costura documentada.
Qué significa esto para los compradores
Si solo recuerdas una cosa: cuando un socio de Sana diga que va a "encargarse de todo", pregunta en qué mitad es realmente bueno. La integración con el ERP y la tienda son dos oficios. La plataforma se construyó suponiendo que ambos se presentarían. El canal de socios se construyó suponiendo que el primero lo haría. Cuida esa brecha a propósito, asigna personal para ambas, y obtendrás lo que Sana de verdad promete: una tienda precisa alimentada por el ERP de la que además la gente quiera comprar.
Somos una agencia web, de diseño y de desarrollo certificada por Sana, y la mitad de la tienda es el trabajo que hacemos. Si ya tienes un socio de ERP listo y necesitas la mitad que ellos no cubren (o no sabes cómo dividirla), inicia una conversación. También puedes leer más sobre cómo trabajamos como agencia de Sana Commerce, nuestras capacidades más amplias en Sana Commerce, o cómo se compara Sana con BigCommerce si todavía estás eligiendo plataforma.