Si has dedicado algo de tiempo a evaluar plataformas B2B, probablemente llegaste a la misma bifurcación. Opción A: elegir una tienda rápida y moderna (Shopify, BigCommerce, la opción headless de moda) y escribir integraciones que copien los datos del ERP de forma programada. Opción B: elegir una plataforma que hable directamente con el ERP en el momento de la solicitud. Sana Commerce está claramente en el segundo grupo, y esa única decisión arquitectónica cambia casi toda la conversación que sigue.
El trabajo de la tienda cambia
En el modelo de copiar los datos, la tienda es dueña de los datos. El ERP es una fuente de oficina trasera que mantiene alimentada a la tienda. La tienda tiene que mantener su propio motor de precios, su propio estado de inventario, su propia lógica de segmentación de clientes, por lo general como copias derivadas de lo que el ERP ya conoce. Cuando el ERP es la autoridad última de cualquiera de esos puntos (y en B2B casi siempre lo es: niveles de precio, precios por contrato, disponible para prometer, bloqueos por crédito, reglas de envío), la tienda se convierte en un lugar donde la verdad del ERP se reinterpreta.
En el modelo de ERP primero, la tienda delega. Cuando un cliente con sesión iniciada abre la página de un producto, Sana le pregunta al ERP: "este cliente, este artículo, hoy, ¿cuál es el precio?". El ERP responde. El inventario funciona igual. También las reglas de envío, los bloqueos por crédito, las condiciones de pago y los catálogos específicos por cliente. No hay una segunda copia que pueda desviarse.
Dónde esta es, sin ambigüedad, la decisión correcta
Tres patrones hacen de "ERP primero" la respuesta obvia:
- Precios específicos por cliente que ya están maduros en el ERP. Si tu equipo de ventas pasó años construyendo reglas de niveles, sobreprecios por contrato y tablas de descuentos por cantidad en NAV / Business Central / S/4HANA, no querrás reconstruir ese motor de precios dentro de una tienda, y mucho menos querrás una copia que deba revalidarse cada vez que cambian las reglas del ERP.
- Disponible para prometer en tiempo real. Un cliente que coloca una orden de compra de varias líneas necesita ver si el pedido realmente puede enviarse junto. El disponible para prometer que viene de un ETL periódico es solo una versión peor del que entrega el propio ERP.
- Bloqueos por crédito y estado de la cuenta. Si el área de cuentas por cobrar pone a un cliente en bloqueo a las 3 p. m., la tienda no debería estarle vendiendo a las 3:01.
El compromiso que en realidad estás haciendo
La versión honesta de la propuesta de "ERP primero" es: estás cambiando algo de rendimiento máximo por exactitud. Una tienda estática con precios en caché es más rápida que una que va y vuelve al ERP. Sana lo mitiga con caché y agrupación de conexiones, pero el límite superior del tiempo de carga de la página lo marca qué tan rápido puede responder tu ERP.
Para la mayoría de los catálogos B2B (de 1,000 a 100,000 SKU, de cientos a unos pocos miles de compradores autenticados), esto no es el cuello de botella. Pero si estás empujando 10 millones de SKU en un catálogo público donde el 95% del tráfico es navegación sin autenticar, sentirás el peso de la integración justo donde preferirías tener una página en caché de CDN. La solución no es abandonar el modelo, sino ser deliberado sobre qué va detrás del muro de inicio de sesión (y alimentado por el ERP) frente a qué va delante (y en caché agresiva).
Tres cosas que conviene acertar pronto
1. El registro del cliente ES el contrato de integración
Sana vincula a los usuarios web con los registros de cliente del ERP. Si el maestro de clientes del ERP está desordenado (cuentas duplicadas, relaciones poco claras entre destino de envío y de facturación, asignaciones inconsistentes de condiciones de pago), la tienda dejará a la vista ese desorden en lugares donde los clientes lo ven. Hemos dedicado más de un primer mes de proyecto a limpiar el maestro de clientes, algo que nadie había presupuestado. Inclúyelo en el plan.
2. Los complementos viven sobre el propio framework de Sana
Si antes has construido en BigCommerce o Shopify, tu instinto será escribir a mano las integraciones como servicios web independientes. Sana tiene su propio modelo de complementos, y los proyectos que lo respetan se mantienen sostenibles a lo largo de las actualizaciones trimestrales de Sana. Los proyectos que lo eluden acumulan una deuda de actualización y, al final, igual hay que reescribirlos.
3. No metas a escondidas una segunda fuente de verdad
Los proyectos de "ERP primero" más caros son aquellos que, a mitad de camino, decidieron poner un "caché de rendimiento" de los datos del catálogo en un servicio aparte "solo para las páginas de navegación", y luego empezaron a escribir código de conciliación, después un panel de sincronización y después alertas por desviaciones de sincronización. Ahora tienes dos sistemas de registro y has perdido la disciplina de integración por la que pagaste Sana.
Sana 9.x on-premise frente a Sana Commerce Cloud
Si ya estás corriendo Sana 9.x, si conviene o no pasar a Sana Commerce Cloud es una conversación aparte. La versión corta: Cloud es un producto distinto, no una versión alojada de lo mismo. El modelo de integración es el mismo en espíritu (ERP primero, precios en tiempo real, el registro del cliente como contrato), pero Cloud usa una arquitectura SaaS, un stack de frontend más moderno y un modelo de complementos diferente. Si personalizaste mucho Sana 9.x, "pasar a Cloud" se parece más a una reimplementación que a una actualización. No aceptes un discurso de proveedor que lo pinte de otra forma sin una evaluación real.
Qué significa esto para los compradores
Si hoy estás evaluando plataformas y tu negocio de verdad funciona sobre el ERP, "ERP primero" no es una afirmación de marketing, es la decisión arquitectónica que hace alcanzable el resto de tu programa B2B sin un ejército de ingenieros de integración. Si tu ERP es ligero o tu negocio ya lo superó, las cuentas son distintas. En cualquier caso, el peor desenlace es elegir una plataforma de "ERP primero" y luego intentar usarla como una plataforma de copiar los datos. La plataforma no se opondrá a ti, pero las personas que la mantienen terminarán quemadas.
Si estás dimensionando esta decisión en un proyecto real, preferimos hablar contigo a que lo adivines a partir de una entrada de blog, porque eso es literalmente el trabajo que hacemos. Inicia una conversación aquí o conoce más sobre nuestras capacidades en Sana Commerce.