Cuando encontrar el producto correcto es más difícil que comprarlo
Una referencia puede identificar un producto sin decir dónde encaja. Descubre por qué integrar un Catálogo de productos técnicos exige conservar atributos y relaciones. En algunos ecommerce, encontrar un producto consiste en buscar:
“camiseta negra”
En otros:
“filtro compatible con modelo X, versión Y, fabricado entre 2022 y 2024”
Ambos son catálogos.
Pero el segundo tiene un problema adicional:
no basta con encontrar un producto parecido. Tiene que ser el correcto.
Esto ocurre constantemente en automoción, recambios, suministros industriales, ferretería, electrodomésticos, material eléctrico y otros catálogos técnicos.
Y cambia por completo lo que significa sincronizar un producto desde el ERP, lo que significa sincronizar el catálogo entre ERP y ecommerce.
Tabla de contenidos
Una referencia no explica con qué es compatible
Supongamos:
FILT-4821
Filtro de aire.
Precio: 24,80 €.
Stock: 17.
La ficha existe.
Pero un cliente necesita saber:
¿Sirve para mi máquina?
Para responder necesitamos relaciones:
FILT-4821
compatible con
Modelo A / versión 3
Modelo B / versión 2
Modelo C / versiones 1–4
Eso no es simplemente añadir otra descripción.
Es modelar una relación entre entidades.
En un catálogo de productos técnicos los atributos ayudan, pero no siempre bastan
Podemos añadir:
Diámetro: 80 mm
Longitud: 240 mm
Material: X
Rosca: Y
Eso permite filtrar.
Pero:
“80 mm”
no significa necesariamente:
“compatible con máquina Z”.
Un catálogo técnico puede necesitar ambas cosas:
atributos
describen el producto.
relaciones
explican dónde encaja.
Confundirlos suele producir catálogos enormes donde hay mucha información pero sigue siendo difícil encontrar lo correcto.
Un producto puede depender de otro producto
Otro patrón habitual:
Máquina
↓
Recambios
Filtro
Correa
Rodamiento
↓
Accesorios
Kit mantenimiento
Adaptador
↓
Consumibles
Lubricante
Cartucho
Aquí la navegación comercial no depende únicamente de categorías.
Depende de relaciones:
repuesto de
compatible con
accesorio para
alternativa a
requiere
Estas relaciones tienen valor empresarial y deben conservarse cuando el catálogo cambia de sistema.
No es una distinción puramente teórica. Incluso Google Merchant Center permite representar explícitamente relaciones entre productos como accesorio, sustituto o pieza obligatoria, además de identificar el producto relacionado.
La documentación también forma parte del producto
Ficha técnica.
Manual.
Certificado.
Plano.
Ficha de seguridad.
Instrucciones de instalación.
En determinados sectores, un producto sin su documentación está incompleto aunque ERP, precio y stock sean perfectamente correctos.
Pero tampoco significa que debamos guardar todos los PDF dentro del ERP.
Puede existir:
ERP → identidad y operación
PIM → atributos
DAM/documentación → assets
Ecommerce → presentación
Otra vez, la integración debe preservar relaciones, no necesariamente crear copias.
Las categorías son especialmente peligrosas aquí
Imaginemos:
Recambios > Filtros
Es técnicamente correcto.
Pero quizá el usuario no conoce el nombre del recambio.
Conoce:
Marca → Máquina → Modelo → Versión
y quiere descubrir qué piezas sirven.
La taxonomía interna del ERP y la navegación comercial pueden responder a preguntas completamente diferentes.
Copiar familias del ERP como categorías web puede producir un ecommerce técnicamente sincronizado y prácticamente inutilizable.
¿Dónde debe vivir la compatibilidad?
No hay una respuesta universal.
Puede estar en el ERP.
En un PIM.
En una base de datos especializada.
En tablas propias.
Incluso puede provenir de un proveedor.
La pregunta correcta es:
¿dónde se mantiene hoy esta relación con suficiente calidad como para confiar en ella?
Después podemos determinar quién la consume.
¿Y si cambia el producto principal?
Supongamos que un fabricante sustituye una pieza.
FILT-4821
↓
sustituido por
FILT-5910
Ahora tenemos otra relación.
No queremos simplemente borrar la referencia antigua.
Puede seguir siendo necesaria para:
- búsquedas;
- históricos;
- máquinas antiguas;
- equivalencias;
- atención al cliente.
El modelo del catálogo empieza a parecer menos una tabla y más una red.
Y eso es exactamente lo que es.
Un catálogo técnico es un grafo disfrazado de tienda
Productos.
Máquinas.
Modelos.
Versiones.
Recambios.
Accesorios.
Documentos.
Compatibilidades.
Sustituciones.
Todos relacionados.
La ficha de producto que finalmente ve el cliente es solo una vista de esa red.
Esta idea es importante porque cambia cómo abordamos la integración.
No preguntamos únicamente:
¿Qué campos tiene el producto?
También:
¿Con qué otras entidades está relacionado y cuáles de esas relaciones necesita conservar el ecommerce?
El problema aparece en muchos sectores
Automoción
marca → modelo → versión → pieza.
Electrodomésticos
aparato → modelo → recambio.
Industria
máquina → componente → consumible.
Ferretería
producto → medida → material → aplicación → accesorio compatible.
Material eléctrico
producto → potencia → voltaje → conexión → componente compatible.
Climatización
equipo → modelo → capacidad → instalación → repuesto.
Informática y electrónica
dispositivo → configuración → compatibilidad → accesorio.
Los atributos cambian.
Las relaciones también.
Pero todos comparten una característica:
el cliente necesita identificar correctamente el contexto antes de saber qué producto comprar.
Por eso el problema no se resuelve creando una ficha de producto cada vez más larga.
Hay que conservar la estructura que permite llegar hasta el producto correcto.
Más atributos no significan necesariamente un catálogo mejor
Cuando una tienda técnica tiene problemas de búsqueda, una reacción habitual consiste en añadir filtros.
Marca.
Medida.
Potencia.
Material.
Diámetro.
Voltaje.
Modelo.
Año.
Aplicación.
Cuantos más atributos tengamos, más preciso debería ser el catálogo.
En teoría.
En la práctica podemos acabar trasladando al cliente la complejidad de nuestra base de datos.
Un profesional que sabe exactamente qué busca puede utilizar veinte filtros.
Otro cliente quizá solo sabe:
Tengo esta máquina y necesito cambiar esta pieza.
Para el segundo, la relación:
Máquina → Recambios compatibles
puede ser mucho más útil que cualquier combinación de filtros.
La estructura de datos debería servir al proceso de compra, no obligar al comprador a entenderla.
La referencia sigue siendo fundamental
Nada de esto significa que SKU, referencia o EAN pierdan importancia.
Todo lo contrario.
Son identificadores fundamentales para saber de qué entidad estamos hablando.
Pero:
identificar correctamente un producto y entender cómo se relaciona con otros productos son problemas diferentes.
La referencia nos puede decir:
esto es FILT-4821
La relación nos dice:
FILT-4821 sirve para estas máquinas
Y otra relación puede decir:
FILT-5910 sustituye a FILT-4821
Para construir un catálogo técnico útil necesitamos conservar ambas cosas.
Sincronizar relaciones plantea un problema distinto a sincronizar campos
Imaginemos que tenemos:
Producto A → compatible con → Máquina X
Si copiamos Producto A al ecommerce pero perdemos la relación, técnicamente hemos sincronizado el producto.
Comercialmente hemos perdido parte de su significado.
Lo mismo ocurre con:
Producto → accesorio
Producto → repuesto
Producto → documentación
Producto → sustituto
Producto → componente
Por eso una integración de catálogo debería preguntarse no solo:
¿Qué datos tiene esta entidad?
sino también:
¿Qué relaciones necesita conservar?
Esta distinción se vuelve especialmente importante cuanto más técnico es el producto.
No todas las relaciones tienen que llegar al ecommerce
Aquí aparece de nuevo un principio importante.
Que una relación exista no significa que todos los sistemas tengan que conocerla.
El ERP puede necesitar conocer:
Artículo → proveedor
para comprar.
El ecommerce quizá no.
El ecommerce puede necesitar:
Producto → accesorio compatible
para vender.
El ERP quizá no utiliza esa relación en ningún proceso.
Un PIM puede mantener:
Producto → documentación
porque es el sistema donde el equipo de producto gestiona esa información.
La integración no debería intentar construir una réplica universal.
Debería proporcionar a cada sistema las entidades y relaciones necesarias para ejecutar su función.
Y tampoco existe necesariamente un único origen
Un catálogo técnico puede construirse a partir de varias fuentes.
ERP
Referencia
Precio
Stock
Coste
Proveedor
PIM
Atributos
Compatibilidades
Clasificación
Contenido técnico
DAM
Fotografías
Manuales
Planos
Certificados
Proveedor
Fichas técnicas
Equivalencias
Datos especializados
↓
ECOMMERCE
La ficha que ve el cliente puede ser el resultado de todas ellas.
Por eso preguntar:
¿ERP o ecommerce?
puede ser insuficiente.
La pregunta correcta vuelve a ser:
¿quién tiene autoridad sobre cada información y relación?
El ecommerce no debería tener que reconstruir el conocimiento
Este es uno de los riesgos más habituales.
La empresa ya sabe que:
Filtro A
es compatible con:
Máquina B
Pero esa información vive en algún sistema interno.
Al crear el ecommerce, alguien vuelve a construir manualmente las compatibilidades.
Después cambia una referencia.
Se incorpora un modelo.
Un fabricante sustituye una pieza.
Y tenemos dos representaciones independientes de la misma relación.
A partir de ahí, sincronizar precio y stock perfectamente no evita que el cliente termine comprando el recambio equivocado.
La integración debería evitar esa duplicación siempre que exista una fuente suficientemente fiable.
¿Qué debemos descubrir antes de integrar un catálogo técnico?
Antes de empezar a mapear campos, intentaría responder estas preguntas.
¿Qué representa un producto?
¿Artículo, modelo, pieza, componente, kit?
¿Cómo se identifica?
Referencia, SKU, EAN, referencia del fabricante…
¿Qué atributos permiten describirlo?
Medidas, potencia, material, voltaje…
¿Qué relaciones permiten utilizarlo correctamente?
Compatibilidades, accesorios, recambios, sustituciones…
¿Qué documentación necesita acompañarlo?
Manuales, certificados, fichas técnicas…
¿Dónde se mantiene cada información?
ERP, PIM, DAM, proveedor, ecommerce…
¿Qué necesita realmente el comprador?
Buscar por referencia, navegar por máquina, filtrar atributos, encontrar equivalencias…
Solo entonces sabemos qué modelo necesita el canal.
La integración empieza antes de la API
Podemos tener una API perfecta.
Podemos leer cien campos de un producto en milisegundos.
Podemos enviar cada cambio inmediatamente al ecommerce.
Y aun así construir una mala integración.
Porque la pregunta fundamental no era:
¿Cómo envío estos campos?
Era:
¿Qué significa este producto dentro del proceso de compra?
La tecnología transporta el modelo.
No decide cuál debería ser.
No sincronices fichas. Conserva conocimiento.
Cuando un catálogo es sencillo, producto y ficha pueden parecer prácticamente lo mismo.
Cuando crece la complejidad, deja de ser así.
Un producto técnico existe dentro de un contexto:
qué es
qué características tiene
con qué funciona
qué lo sustituye
qué necesita
qué documentación lo acompaña
Ese contexto es parte de su valor comercial.
En Distillsync utilizamos un modelo intermedio para representar las entidades y relaciones que después deben traducirse a cada aplicación.
Pero la idea es independiente de la herramienta:
integrar un catálogo técnico no consiste en conseguir que dos sistemas tengan la misma ficha.
Consiste en conseguir que el significado necesario para encontrar, elegir y comprar el producto correcto sobreviva cuando la información pasa de uno a otro.
Conceptos
Relación, Entidad, Compatibilidad, SKU, Metamodelo, Source of truth.