Ecommerce B2B para mayoristas: ¿qué debe sincronizar realmente tu ERP?
Montar un ecommerce B2B para mayoristas parece sencillo hasta que intentas decidir qué información tiene que llegar desde el ERP.
La lista parece razonable. El problema es que esas cinco cosas no son independientes.
En un ecommerce B2C puedes publicar un producto por 49,90 € y mostrarlo igual a prácticamente cualquier persona que visite la tienda.
En una empresa mayorista puede que la pregunta ni siquiera sea:
¿Cuánto cuesta este producto?
Sino:
¿Cuánto cuesta este producto para este cliente, comprando esta cantidad y bajo estas condiciones?
Ahí cambia el problema.
En B2B, el cliente forma parte del producto
Imaginemos una empresa que distribuye material profesional.
En su ERP tiene un artículo:
REF-1842 — Guante industrial
Tiene 600 unidades.
Y un precio base de 8,40 €.
Podríamos enviar esos tres datos al ecommerce:
Guante industrial
8,40 €
600 disponibles
Pero llega el primer cliente.
Es un distribuidor que tiene asignada la tarifa PROFESIONAL-2.
Para él, el precio es 6,75 €.
El segundo cliente pertenece a otra tarifa y además tiene unas condiciones comerciales diferentes.
Para él son 7,10 €.
Un tercero no debería poder comprar esa familia de productos.
Y quizá ninguno de ellos debería saber que físicamente existen 600 unidades en el almacén.
El artículo sigue siendo REF-1842.
Pero lo que puede comprar cada cliente ya no depende solamente del artículo.
Depende de relaciones.
Producto + cliente + tarifa + condiciones + disponibilidad
Eso es lo que acaba convirtiéndose en una oferta B2B.
Esta complejidad no es exclusiva de un ERP o una plataforma concreta. Las propias plataformas B2B contemplan la integración con sistemas externos para sincronizar clientes, pedidos, inventario, Catálogo y precios.
El catálogo del ERP tampoco es necesariamente el catálogo de la web
Este es otro error habitual al plantear el proyecto:
“Tenemos 25.000 artículos en el ERP. Los subimos a la tienda.”
¿Los 25.000?
Un ERP puede contener referencias descatalogadas, artículos internos, componentes, servicios, productos sin información comercial suficiente o familias que solo vende el equipo comercial.
Incluso cuando un artículo debe publicarse, los dos sistemas pueden entenderlo de forma diferente.
El ERP puede trabajar con:
Artículo → talla → color → referencia
mientras el ecommerce necesita:
Producto → variantes
O puede tener familias diseñadas para organizar internamente el catálogo que no tienen ningún sentido como navegación de una tienda.
Por eso sincronizar catálogo no significa necesariamente:
copiar artículos.
Significa decidir qué parte del modelo del ERP debe convertirse en el modelo comercial que necesita el canal.
Y qué parte debe quedarse donde está.
El precio B2B no siempre pertenece al producto
En muchos ecommerce B2C podemos pensar aproximadamente así:
SKU → precio
En B2B esa relación puede convertirse en:
SKU + cliente + tarifa + cantidad + descuento + fecha → precio
No todos los ERP implementan exactamente estas dimensiones ni todas las empresas utilizan todas ellas.
Ese es precisamente el punto.
No deberíamos diseñar la integración suponiendo que existen.
Hay que mirar qué utiliza realmente la empresa.
Puede que tenga diez tarifas creadas pero solo tres activas.
Puede que haya cientos de clientes con una tarifa asignada y unas pocas excepciones negociadas.
Puede que el descuento relevante esté asociado al cliente, a la familia, al artículo o a una combinación de condiciones.
Antes de preguntar cómo sincronizamos los precios, necesitamos responder:
¿Cómo obtiene hoy esta empresa el precio correcto para un cliente?
Solo entonces sabemos qué debe llegar al ecommerce.
Existencias y disponibilidad no son lo mismo
Supongamos que el ERP dice:
Existencias: 127
¿Publicamos 127?
No necesariamente.
Podría haber:
- 80 unidades en el almacén principal;
- 27 en otra delegación;
- 20 en una ubicación que no sirve pedidos ecommerce;
- unidades comprometidas en pedidos todavía no expedidos;
- mercancía pendiente de recibir;
- un stock mínimo que operaciones quiere conservar.
La tienda no necesita conocer necesariamente toda esa estructura.
Necesita una respuesta:
¿Cuántas unidades puedo vender ahora a través de este canal?
Por eso hay una diferencia importante entre existencias y disponibilidad.
La primera describe una situación del ERP.
La segunda responde a una pregunta comercial.
Un ecommerce B2B para mayoristas necesita normalmente la segunda.
Entonces, ¿qué debe sincronizarse?
La respuesta incómoda es:
depende.
Pero no es un “depende” de consultoría.
Podemos averiguarlo.
Empezamos por el proceso.
Un cliente entra en la tienda.
Se identifica.
Consulta un producto.
Ve un precio.
Comprueba disponibilidad.
Realiza un pedido.
Para que ese proceso funcione necesitamos identificar qué información interviene en cada paso.
Por ejemplo:
Cliente
↓
identifica quién compra
Catálogo
↓
determina qué puede comprar
Tarifa y condiciones
↓
determinan a qué precio
Stock
↓
determina qué puede servirse
Pedido
↓
devuelve la operación al ERP
La integración aparece alrededor del proceso, no al revés.
No empieces con un Excel de 200 campos
Una forma tradicional de abordar estos proyectos consiste en reunir a varias personas y empezar a construir una enorme tabla.
- Campo ERP.
- Campo ecommerce.
- Transformación.
- Obligatorio.
- Longitud.
- Observaciones.
Y después intentar imaginar todos los procesos que podrían existir.
Hay situaciones en las que ese trabajo es necesario.
Pero es un mal punto de partida.
Porque estamos diseñando una representación de la empresa antes de mirar cómo funciona realmente.
Si el ERP ya contiene 12.000 artículos, cuatro almacenes, seis tarifas y 2.000 clientes, tenemos una fuente de información bastante mejor que una pizarra.
Podemos empezar preguntando:
¿Qué hay realmente aquí?
- ¿Qué tipos de artículos existen?
- ¿Qué tarifas se están utilizando?
- ¿Cuántos almacenes tienen stock relevante?
- ¿Qué información tienen los clientes?
- ¿Qué relaciones aparecen en los pedidos reales?
Primero observamos.
Después diseñamos.
La diferencia parece pequeña, pero cambia completamente la conversación.
Tampoco necesitas sincronizar todo lo que encuentres
Este es el error contrario.
Descubrimos que el ERP tiene 180 campos de artículo y decidimos que necesitamos mapear 180 campos.
No.
Una integración no tiene como objetivo construir una réplica del ERP.
Tiene que proporcionar los datos necesarios para ejecutar un proceso.
Si el ecommerce necesita doce atributos para publicar correctamente un producto, que el ERP tenga otros cincuenta no convierte esos cincuenta en requisitos.
Si utiliza dos de los seis almacenes para servir pedidos online, quizá los otros cuatro ni siquiera deberían participar en esa tarea.
Y si determinadas condiciones comerciales solo son relevantes cuando se factura, no necesariamente tienen que viajar hasta el ecommerce.
Más datos no significan mejor integración.
Con frecuencia significan más acoplamiento.
El ecommerce no debería convertirse en un segundo ERP
Este es probablemente el riesgo más importante en un proyecto B2B.
Una tienda empieza siendo un nuevo canal.
Después copiamos las tarifas.
Después las reglas de descuento.
Después la disponibilidad.
Después las condiciones de cliente.
Después parte de la lógica fiscal.
Al cabo de un tiempo tenemos dos sistemas capaces de responder a las mismas preguntas.
Y entonces aparece una pregunta nueva:
¿cuál tiene razón?
Si una tarifa cambia en el ERP y alguien modifica el mismo precio en ecommerce, tenemos dos versiones de la realidad.
Si una regla comercial existe en ambos sistemas, tenemos dos lugares donde mantenerla.
Si un cliente cambia de condiciones, tenemos que garantizar que ambas implementaciones evolucionen igual.
La integración empieza a resolver el problema que ella misma ha creado.
Una arquitectura más sostenible suele mantener la autoridad sobre cada información donde ya tiene sentido mantenerla y proporcionar al resto de sistemas el resultado que necesitan.
No significa que el ERP tenga que mandar sobre todo.
Significa que debemos saber quién manda sobre cada cosa.
El ERP tampoco tiene que mandar sobre todos los datos
El ERP probablemente sea una buena autoridad para:
- referencias
- tarifas
- clientes
- stock
- condiciones comerciales
Pero quizá no lo sea para:
- fotografías
- contenido enriquecido
- vídeo
- copy comercial
- SEO
- determinados atributos de merchandising
Esos datos pueden vivir mejor en el ecommerce, en un PIM o en otro sistema especializado.
Por eso hablar de “ERP maestro” puede ser demasiado simplista.
La pregunta útil es:
¿Dónde se mantiene correctamente este dato hoy y qué sistemas necesitan utilizarlo?
Para stock la respuesta puede ser el ERP.
Para una descripción SEO, el ecommerce.
Para una fotografía, un DAM.
Para un pedido recién realizado, inicialmente el ecommerce.
La integración debe respetar esas responsabilidades, no borrarlas.
Un pedido B2B tampoco es simplemente un Order
Cuando finalmente el cliente pulsa comprar, aparece el flujo contrario.
Hasta ahora gran parte de la información viajaba:
ERP → ecommerce
Ahora tenemos:
ecommerce → ERP
Pero un Order del ecommerce no necesariamente equivale directamente a un pedido del ERP.
Hay que relacionar:
- cliente
- dirección de facturación
- dirección de entrega
- referencias
- cantidades
- precios
- descuentos
- impuestos
- portes
- forma de pago
- referencias externas
Y además resolver situaciones menos felices:
¿Qué ocurre si el cliente ya existe?
¿Y si una referencia no existe?
¿Si el mismo pedido llega dos veces?
¿Si el precio recibido no coincide con el esperado?
¿Si una línea no puede procesarse?
La integración real empieza precisamente donde termina el diagrama bonito de dos cajas conectadas por una flecha.
Automatizar no significa quitar al comercial
En empresas mayoristas aparece a veces otra preocupación.
Si el cliente puede consultar precios, comprobar stock y hacer pedidos solo, ¿qué ocurre con el comercial?
Probablemente pueda dejar de hacer algunas cosas bastante poco comerciales.
Buscar una disponibilidad.
Enviar una tarifa.
Copiar un pedido recibido por email.
Introducir referencias.
Confirmar que un producto existe.
El ecommerce puede convertirse en una interfaz de autoservicio para las operaciones repetitivas sin sustituir la relación que existe detrás.
Un cliente importante seguirá negociando.
Seguirá preguntando.
Seguirá necesitando asesoramiento.
Pero quizá no necesite llamar para saber si quedan doce cajas de una referencia que compra todos los meses.
La automatización no tiene que eliminar la relación comercial.
Puede eliminar trabajo manual alrededor de ella.
Antes de integrar, observa
La pregunta con la que empezamos era:
¿qué debe sincronizar realmente un ecommerce B2B para mayoristas con su ERP?
No existe una lista universal.
Pero sí existe una forma bastante razonable de averiguarlo:
1. Identifica el proceso.
¿Qué intenta hacer el cliente? ¿Consultar un producto, aplicar una tarifa, comprobar el stock o realizar un pedido?
Distillsync ayuda a traducir ese proceso en una integración concreta entre el ERP y el ecommerce, definiendo qué información debe viajar, en qué dirección y bajo qué condiciones.
2. Identifica las entidades que participan.
Producto, cliente, precio, stock, pedido, tarifa, disponibilidad…
Distillsync conecta estas entidades y automatiza las tareas necesarias para que los datos se creen, actualicen y relacionen correctamente entre sistemas, sin depender de cargas manuales ni de procesos aislados.
3. Mira los datos reales.
Distillsync trabaja sobre la estructura y los datos reales de cada sistema: campos, identificadores, estados, reglas y relaciones. A partir de ahí, permite mapear la información, detectar incompatibilidades y automatizar su sincronización de forma controlada.
4. Decide dónde está la autoridad.
Quién crea y mantiene cada información.
5. Sincroniza solamente lo necesario.
No conviertas cada campo disponible en un requisito.
6. Mantén determinista la ejecución.
Cuando ya sabemos qué significa cada dato y qué tiene que ocurrir, el mismo evento debe producir el mismo resultado.
Esta es también la diferencia entre diseñar una integración sobre papel y construirla alrededor de una empresa que ya está funcionando.
La integración debería adaptarse al negocio, no al revés
a3ERP, Sage 50, Sage 200, Odoo o Business Central representan productos, tarifas, clientes y documentos de maneras diferentes. Por ejemplo, ya hemos analizado con más detalle qué implica conectar a3ERP con un ecommerce cuando el ERP está dentro de la infraestructura de la empresa.
PrestaShop, Shopify, WooCommerce y Magento también.
Pero el mayorista sigue pensando en cosas bastante reconocibles:
producto
cliente
precio
stock
pedido
Esa capa intermedia es importante.
En Distillsync utilizamos un modelo común para representar esas entidades y transformar después cada aplicación hacia él.
No para esconder cómo funciona el ERP.
Sino para evitar que cada nueva combinación ERP–ecommerce obligue a volver a inventar el mismo proceso desde cero.
Porque el objetivo final no es sincronizar dos bases de datos.
Es bastante más sencillo:
que el cliente vea lo que puede comprar, al precio que le corresponde, y que el pedido termine donde tiene que terminar.