He limpiado más de 200.000 registros entre ERPs y catálogos: esto es lo que encuentro siempre

Cuando una empresa intenta vender con datos pensados solo para operar, el catálogo empieza a fallar. En este artículo explico cuáles son las inconsistencias que encuentro una y otra vez al reconciliar el dato de compra del ERP con el dato de venta del catálogo, por qué frenan la publicación y qué orden mínimo hace falta antes de hablar de integración o PIM.

El problema no es que falten datos: es que no están listos para vender

Cada vez que empiezo un proyecto y me dicen “los datos ya están en el ERP”, sé que todavía falta una parte importante del trabajo.

Tener datos no es lo mismo que tener información de producto lista para vender. El ERP suele resolver bien la compra, la logística, el stock o la facturación. Pero el catálogo, el eCommerce o el marketplace necesitan otra cosa: datos claros, comparables, filtrables y publicables.

Esa diferencia entre el dato de compra y el dato de venta es una de las causas más frecuentes del desorden. No porque el ERP esté mal, sino porque fue diseñado para cumplir otra función. Cuando una empresa intenta publicar sin traducir ese dato operativo a un lenguaje comercial y estructurado, empiezan a aparecer errores que se repiten proyecto tras proyecto.

Después de limpiar más de 200.000 registros entre ERPs, planillas, PIMs y catálogos heredados, encontré un patrón constante: el problema rara vez está en un solo sistema. Lo que suele fallar es la reconciliación entre sistemas, equipos y criterios.

La primera inconsistencia: el producto tiene código, pero no identidad clara

En muchos catálogos el producto existe, pero no está suficientemente identificado. Tiene un SKU interno, sí, pero no siempre queda claro cómo se relaciona con sus variantes, con su GTIN, con el código del proveedor o con el identificador que exige cada canal.

Entonces aparecen escenas conocidas: el mismo producto con dos códigos distintos, variantes que comparten identificador con el padre, registros sin GTIN, o productos que se entienden dentro del ERP pero no conversan con ningún otro sistema. El resultado es una base difícil de conciliar y todavía más difícil de publicar.

Un identificador útil no solo distingue. También permite responder rápido qué producto es, de dónde viene y a qué otros registros o sistemas se vincula. Cuando eso no está resuelto, todo lo demás se vuelve más frágil.

El nombre de compra casi nunca sirve como nombre de venta

Otra inconsistencia muy común aparece en el nombre del producto. En el ERP encuentro nombres comprimidos, llenos de abreviaturas y pensados para velocidad operativa. Eso puede servir hacia adentro. Hacia afuera, no.

Un catálogo no puede depender de nombres que solo entiende quien ya conoce el negocio. El nombre de venta tiene que ayudar a identificar, comparar y decidir. Tiene que decir con claridad qué es el producto y por qué se diferencia. Si el nombre nace para compras, casi siempre necesita una traducción antes de salir al canal.

Muchas empresas creen que ya tienen la ficha casi resuelta porque el producto tiene nombre, precio y marca. Pero cuando uno revisa el contenido con criterio comercial, aparece el problema real: el producto está cargado, pero no está presentado para vender.

Los atributos existen, pero están mal ubicados

Este es uno de los errores que más complican la escalabilidad. El dato está, pero no en el campo correcto. El color aparece dentro del nombre, la medida está escondida en una descripción larga, el material vive en observaciones y la compatibilidad técnica quedó enterrada en un PDF.

Cuando eso pasa, el catálogo pierde estructura. Y cuando pierde estructura, también pierde reutilización. Ya no se puede filtrar bien, cuesta mapear a otros canales, se rompe la navegación y todo ajuste posterior se vuelve manual.

Un atributo bien diseñado no solo guarda un valor. También define cómo ese valor va a ser encontrado, validado, reutilizado y publicado. Si el dato está mezclado, el problema no es de completitud: es de modelado.

Los duplicados casi nunca son exactos

El duplicado perfecto no es tan frecuente. Lo que aparece una y otra vez es el duplicado sucio: dos registros que parecen distintos, pero representan el mismo producto. Cambia una abreviatura, una unidad, un guion, una forma de escribir la marca o una variante mal separada.

Ese tipo de duplicado es especialmente dañino porque fragmenta la información. Un registro tiene la imagen correcta, otro tiene la medida correcta, otro tiene el código correcto. Ninguno reúne todo. Entonces el trabajo ya no consiste solo en limpiar, sino en reconstruir una versión confiable del producto.

Por eso detectar duplicados no es suficiente. También hay que decidir cuál es la fuente válida, qué información se conserva y cómo se consolida sin volver a multiplicar errores.

Sin vocabulario controlado, el catálogo se vuelve inconsistente

Cuando no existe una regla clara para nombrar atributos, valores, marcas o variantes, cada persona carga los datos como puede. El resultado es un catálogo que usa varias formas para decir lo mismo y que obliga a corregir una y otra vez problemas que deberían haberse prevenido.

Esto se nota enseguida en colores, materiales, autores, medidas, composiciones o unidades. También en nombres de marca, categorías y valores de listas cerradas. Lo que parece un detalle termina rompiendo filtros, reportes, automatizaciones y consistencia entre canales.

Trabajar con vocabulario controlado no es una obsesión editorial. Es una condición básica para que el catálogo funcione como sistema y no como acumulación de celdas.

Los vacíos aparecen justo en los campos que más importan

No todos los campos vacíos generan el mismo problema. Hay ausencias tolerables y hay ausencias que frenan una publicación, rompen una ficha o degradan una experiencia de compra.

Faltan imágenes. Falta una descripción corta. Falta el material. Falta la medida. Falta un atributo obligatorio para el canal. Y muchas veces ese vacío no se detecta hasta el final, cuando el producto no publica o cuando el cliente compra con una expectativa equivocada.

Por eso no alcanza con decir que un catálogo está “bastante completo”. La pregunta útil es otra: qué campos faltan, cuáles son críticos y en qué parte del flujo se detectan. Sin esa priorización, el trabajo de enriquecimiento se vuelve difuso y reactivo.

La categoría interna no siempre sirve para vender

Otra fuente habitual de conflicto aparece en la categorización. La estructura interna suele responder a criterios de compra, abastecimiento o reporting. El usuario final, en cambio, navega según otra lógica. Busca por uso, por tipo de producto, por necesidad o por una combinación de atributos.

Cuando se intenta usar la misma estructura para todo, el catálogo se vuelve incómodo. Aparecen rutas de navegación poco intuitivas, filtros que no ayudan y categorías que funcionan para operar, pero no para vender.

En muchos proyectos esto se resuelve separando dos planos: una lógica interna para gobernanza y una lógica de navegación orientada al canal. No es duplicar trabajo. Es reconocer que una misma estructura no siempre puede resolver objetivos distintos.

Las variantes suelen estar mal entendidas desde el origen

Padres que no son padres. Hijos cargados como productos independientes. Variantes que comparten atributos que no deberían compartir. O, al revés, productos distintos agrupados como si fueran una sola ficha.

Cuando el modelo de variantes está mal resuelto, el problema se expande rápido. Se duplica contenido, se complica el stock, se rompe la experiencia de compra y se vuelven más difíciles las integraciones con eCommerce o marketplaces.

Las variantes no son solo una cuestión visual. Son una decisión de modelado. Y si esa decisión se posterga o se improvisa, después todo el catálogo trabaja con más fricción de la necesaria.

La integración no crea el caos: lo expone

Muchas veces se culpa a la integración por problemas que ya existían antes. Lo que hace una integración es volver visibles inconsistencias que en el origen todavía estaban escondidas: un identificador que no coincide, un valor nulo, un atributo mal tipeado o una taxonomía imposible de mapear.

Por eso me cuesta tomar en serio la idea de “integremos primero y ordenemos después”. Cuando el dato entra mal, la integración no lo corrige. Solo lo distribuye más rápido.

Ordenar antes no es una etapa burocrática. Es la única forma de evitar que el desorden operativo se convierta en desorden multicanal.

La integración no crea el caos: lo expone.

Qué hago antes de tocar una integración

Mi trabajo nunca empieza por el conector. Empieza por el diagnóstico. Primero relevo cómo está armado el catálogo. Después identifico patrones de inconsistencia. Separo dato operativo de dato comercial. Reviso identificadores, familias, atributos, categorías y vacíos críticos. Recién ahí empiezo a pensar en mappings, automatizaciones o publicación.

Ese orden importa porque permite distinguir entre lo que falta, lo que sobra, lo que está duplicado y lo que está mal planteado desde la base. Sin esa lectura previa, cualquier mejora técnica queda apoyada sobre una estructura inestable.

La reconciliación entre ERP y catálogo no es solo un trabajo de limpieza. Es, sobre todo, un trabajo de criterio.

Lo que encuentro siempre

Si tuviera que resumirlo en una sola idea, diría esto: en la mayoría de los proyectos no faltan datos; falta una estructura que los vuelva útiles para vender. El problema no suele ser la ausencia total de información, sino la falta de definición sobre qué sistema gobierna cada dato, cómo se nombra, dónde vive, cómo se valida y para qué canal sirve.

Ese es el punto donde un catálogo deja de ser una acumulación de registros y empieza a convertirse en un activo de negocio. Y también es el punto donde un proyecto PIM deja de ser una simple implementación para convertirse en una decisión de orden.

En la mayoría de los proyectos no faltan datos; falta una estructura que los vuelva útiles para vender. Ese es el punto donde un catálogo deja de ser una acumulación de registros y empieza a convertirse en un activo de negocio.