500.000 SKUs heredados de proveedores: cómo enfrento proyectos de normalización masiva

Cuando trabajo con catálogos industriales de gran volumen, mi primera tarea no es corregir datos: es entender de dónde vienen, qué patrones se repiten y qué parte del desorden realmente necesita normalización. Porque medio millón de SKUs no se limpian fila por fila. Primero hay que encontrar una lógica que permita trabajar con ellos sin perder el criterio en el camino.

Hay algo bastante intimidante en abrir por primera vez una base con cientos de miles de registros.

Podés desplazarte por la planilla durante varios minutos y seguir viendo filas. Abrís otra pestaña y aparecen más. Después otra. En una columna hay medidas, en otra descripciones, en otra algo que parece una especificación técnica pero solamente está completo en una parte del catálogo.

Un proveedor escribe “acero inoxidable”. Otro, “inox”. Otro, stainless steel. Uno expresa una dimensión en milímetros y el siguiente en pulgadas. Hay #N/D, guiones, espacios en blanco, abreviaturas que nadie documentó y valores que alguien cargó hace siete años y ya nadie sabe muy bien qué significan.

Y, en algún momento, alguien pregunta:

“¿Cuándo podemos tener todo esto limpio?”

Mi respuesta mental suele ser otra pregunta:

¿Qué significa exactamente “limpio” para este catálogo?

Porque 500.000 SKUs no se normalizan corrigiendo 500.000 filas una por una. Si encaro un proyecto así pensando registro por registro, perdí antes de empezar.

Lo primero que necesito encontrar son los patrones.

Cuando el volumen asusta, no empiezo mirando las filas. Dejo de mirar productos individuales y empiezo a buscar patrones.

¿Qué miro antes de empezar a normalizar un catálogo industrial?

Antes de cambiar un solo valor, hago diagnóstico.

Esta parte puede generar cierta ansiedad porque todavía no hay nada “arreglado”. Seguimos viendo el mismo archivo desordenado, los mismos atributos repetidos y las mismas inconsistencias. Pero para mí es una etapa indispensable: si empiezo a limpiar antes de entender el problema, corro el riesgo de ordenar muy prolijamente algo que estaba mal planteado desde el inicio.

Primero quiero saber qué tengo delante.

¿Cuántos atributos existen? ¿Cuántos realmente se usan? ¿Cuáles aparecen solamente en una familia de productos? ¿Qué porcentaje de registros tiene información? ¿Cuántos valores distintos existen dentro de cada campo? ¿Hay atributos con nombres diferentes que parecen describir la misma característica? ¿Qué campos tienen tantos valores distintos que probablemente estén funcionando como texto libre aunque no deberían?

También miro lo contrario: campos aparentemente importantes que casi nunca tienen datos.

En uno de los proyectos industriales en los que trabajamos, el modelo original tenía 5.364 atributos. Después del análisis y la depuración quedaron 658.

El problema, entonces, no consistía simplemente en completar mejor esos miles de atributos. Primero había que preguntarse por qué existían.

En el mismo trabajo revisamos más de 141.000 valores: corregimos inconsistencias, errores ortográficos, valores incompatibles con el atributo al que estaban asociados y residuos bastante clásicos como #N/D.

Pero el orden importa.

Primero entendimos la estructura.

Después empezamos a limpiar.

¿Todo lo que viene en una columna merece convertirse en atributo?

Esta es una de las preguntas que más repito en proyectos de distribución industrial.

Los proveedores entregan información con la estructura que les resulta útil a ellos. Y está bien. El problema aparece cuando recibimos esa estructura y asumimos que tenemos que reproducirla exactamente dentro del PIM.

Proveedor A tiene una columna. Entonces creamos un atributo. Proveedor B tiene otra. Creamos otro. Proveedor C trae una especificación que aparece en quince productos. Otro atributo.

Si repetimos ese mecanismo durante años, terminamos con un modelo enorme, difícil de completar y todavía más difícil de mantener.

No todo dato merece convertirse en atributo estructurado.

Hay información que necesito comparar, filtrar, buscar o distribuir a un canal. Esa tiene muchísimo sentido como atributo.

Hay otra que describe una particularidad puntual de un producto y que probablemente pueda conservarse como información de detalle sin obligar a modificar toda la arquitectura.

En uno de nuestros proyectos industriales, justamente terminamos creando un campo de Detalle para conservar información específica que no justificaba crear nuevos atributos cada vez que aparecía una excepción.

Me gusta esa solución porque evita dos extremos que me parecen igual de problemáticos: perder información o sobrediseñar todo el modelo para conservarla.

El objetivo de normalizar no es convertir cada dato que recibimos en un atributo. Es decidir qué información necesita estructura y cuál simplemente necesita conservarse.

¿Qué hago cuando cada proveedor habla un idioma distinto?

Esta es, para mí, una de las partes más representativas de los proyectos de distribución. No hablo solamente del idioma literal —aunque también pasa—, sino de la forma de representar la información.

Un proveedor entrega Excel, otro CSV, otro manda un PDF, otro tiene una web perfectamente completa, pero no entrega una base descargable.

Uno llama al atributo “Voltaje”.

Otro, “Tensión”.

Otro, “Volt.”.

Otro ni siquiera tiene una columna: escribió “220 V / 50 Hz” adentro de la descripción.

Y ninguno está necesariamente equivocado. Cada uno construyó su información para su propio proceso.

El problema aparece cuando yo necesito que todos esos productos convivan dentro del mismo catálogo.

En otro proyecto industrial con múltiples marcas nos encontramos exactamente con esta situación. Algunos fabricantes entregaban planillas relativamente estructuradas; de otros, la única fuente disponible era su sitio web. Para poder incorporar esa información hubo que extraerla, traducirla cuando correspondía, transformarla y recién entonces prepararla para el PIM.

Ahí se vuelve evidente algo que a veces olvidamos: recibir información no es lo mismo que poder utilizarla.

Puedo tener miles de datos y, aun así, no tener un catálogo.

¿Por qué normalizar no es hacer “buscar y reemplazar”?

Supongamos que encuentro estos cuatro valores:

• Acero inoxidable
• Acero inox.
• INOX
• Stainless steel

La tentación es bastante obvia: reemplazo todo por “Acero inoxidable” y sigo. A veces funciona. Otras veces no.

Antes necesito saber si realmente estoy mirando cuatro maneras de nombrar el mismo concepto. ¿Hay diferencias de composición? ¿El proveedor está usando “INOX” como una categoría comercial más amplia? ¿Ese valor viene de otro mercado? ¿Se está mezclando material con acabado?

No puedo resolver semántica únicamente porque dos textos se parecen.

Esto se vuelve todavía más delicado con atributos técnicos.

10 mm no es 10 cm.

220 V no es 220 W.

IP44 no es IP54.

Y una abreviatura que parece evidente para mí puede significar otra cosa dentro de determinada industria.

Por eso prefiero pensar la normalización en dos pasos: primero identifico el concepto y después decido cuál va a ser su representación controlada.

Esa distinción es la misma lógica que uso cuando trabajo con vocabularios controlados. No busco borrar las formas en las que los distintos proveedores hablan, sino construir una capa común que permita al catálogo entender que determinadas expresiones representan la misma cosa.

El lenguaje humano tolera bastante bien la ambigüedad.

Los sistemas, bastante menos.

Normalizar masivamente no es reemplazar textos. Es identificar conceptos, decidir equivalencias y recién después aplicar una forma consistente de representarlos.

¿Cómo hago para que 500.000 productos dejen de parecer 500.000 desconocidos?

Los agrupo.

Esta parte me resulta bastante tranquilizadora.

Porque un catálogo de 500.000 productos parece inmanejable cuando lo miro como una masa uniforme. Pero cuando empiezo a encontrar familias de productos que comparten características, la escala cambia de sentido.

Ya no necesito comprender medio millón de productos individualmente. Necesito entender grupos.

• ¿Qué atributos describen correctamente una luminaria?
• ¿Cuáles describen un interruptor?
• ¿Cuáles una herramienta de corte?
• ¿Cuáles una válvula?

Una vez que existe esa estructura, puedo dejar de preguntarme “¿qué hacemos con este producto?” y empezar a preguntarme “¿qué reglas necesita esta familia?”.

En un proyecto para una red de distribución del sector eléctrico hicimos un análisis profundo del estándar ETIM, revisando más de 140.000 entidades entre grupos, clases y características. A partir de ese trabajo se construyó una nueva taxonomía con más de 140 familias y más de 400 atributos, y luego se reingestó la información de más de 50.000 productos y 56.000 assets.

La lógica de ETIM me resulta especialmente útil para entender este tipo de problemas porque organiza productos técnicos mediante clases y características comunes, y además diferencia valores y unidades. No siempre necesito adoptar un estándar externo completo —eso depende del proyecto—, pero sí me interesa muchísimo la idea que hay detrás: productos similares deberían poder describirse con un conjunto predecible de características.

Cincuenta mil productos me resultan mucho menos intimidantes cuando dejan de ser cincuenta mil desconocidos y empiezan a ser grupos que comparten una lógica.

Automatizo lo repetible y me detengo en lo ambiguo

Cuando el volumen es grande, pretender revisar manualmente cada registro no es rigurosidad.

Es ineficiencia.

Hay problemas que puedo resolver con reglas: espacios de más, mayúsculas inconsistentes, valores vacíos representados como #N/D, N/A o -, unidades escritas de distintas maneras, valores conocidos que ya tienen una equivalencia aprobada, caracteres problemáticos, errores de formato o duplicados evidentes.

Ese trabajo es repetitivo y, precisamente por eso, tiene mucho sentido automatizarlo. Lo que no quiero automatizar a ciegas es aquello que todavía no entiendo. Si tengo cuatro valores que probablemente sean equivalentes pero no puedo demostrarlo, los separo para revisión. Si encuentro un atributo nuevo que aparece en cinco mil referencias y no sé cómo se relaciona con el modelo actual, lo analizo.

Si dos proveedores utilizan la misma palabra para conceptos distintos, no dejo que una regla haga el desastre más rápido que una persona.

Hay algo de mi manera de trabajar que aparece mucho acá: me gusta sistematizar justamente para poder dedicar más atención a las excepciones.

No quiero gastar una hora corrigiendo espacios si una regla puede hacerlo en segundos. Prefiero usar esa hora para entender por qué un conjunto de productos no entra en ninguna familia existente. Ahí es donde mi criterio aporta más.

¿Por qué las unidades de medida necesitan su propia lógica?

Las unidades son uno de esos temas que parecen fáciles hasta que dejan de serlo.

Si un proveedor usa milímetros y otro pulgadas, puedo convertir. Pero primero necesito saber qué unidad estoy recibiendo. El número 25 sin unidad no me sirve demasiado. ¿Son 25 mm? ¿25 cm? ¿25 pulgadas?

Una normalización correcta necesita conservar tanto el valor como su significado.

Por eso, cuando un dato es numérico, prefiero que el modelo pueda tratarlo como dato numérico en lugar de conservar únicamente textos como:

25 mm
25mm
0,025 m
25 milímetros

Una persona entiende rápidamente que esas expresiones pueden representar lo mismo. Un sistema de filtros, comparaciones o validaciones necesita bastante más ayuda.

En los catálogos industriales esto no es un detalle estético. Muchas búsquedas profesionales se hacen justamente por especificación técnica.

El comprador no siempre busca “una bomba”.

Puede buscar una bomba con determinado caudal, conexión, presión o potencia.

Si esos datos están enterrados dentro de una descripción libre, existen para quien lee la ficha, sí, pero prácticamente no existen para la estructura del catálogo.

¿Cuándo considero terminada una normalización masiva?

Hay una escena que no quiero vivir después de meses de trabajo.

Terminamos de normalizar el catálogo. Definimos atributos. Construimos vocabularios. Unificamos unidades. Corregimos miles de registros. Todo precioso.

Y al día siguiente llega un archivo nuevo de proveedor con exactamente los mismos problemas que acabamos de resolver.

Eso significa que limpiamos datos, pero no solucionamos el proceso.

Para mí, una normalización masiva debería dejar algo más que una base saneada. Tiene que dejar reglas para el dato que todavía no llegó.

• ¿Qué atributos son obligatorios?
• ¿Qué unidades aceptamos?
• ¿Qué formato deben tener?
• ¿Qué vocabularios existen?
• ¿Qué identificadores necesito?
• ¿Qué campos dependen de la familia del producto?
• ¿Qué pasa cuando un proveedor manda un valor nuevo?
• ¿Qué rechazamos y qué aceptamos para revisión?

Acá es donde el onboarding de proveedores empieza a tener muchísimo peso. Si puedo definir requisitos, formatos y validaciones antes de que la información ingrese definitivamente al catálogo, reduzco el trabajo de limpieza posterior y, sobre todo, evito que el mismo problema vuelva a reproducirse.

Para mí, ese es el verdadero punto de madurez.

Si después de normalizar miles de productos el próximo archivo del proveedor vuelve a entrar con los mismos errores, limpiamos datos, pero no solucionamos el proceso.

La escala cambia el método, no el criterio

Después de trabajar con catálogos industriales grandes, hay una idea a la que vuelvo bastante. La escala cambia el método.

Si tengo cincuenta productos, puedo revisar casi todo manualmente. Si tengo quinientos mil, necesito otra forma de pensar.

Busco patrones. Agrupo. Mido. Defino reglas. Automatizo lo obvio. Aíslo las excepciones. Y recién ahí empiezo a avanzar sobre grandes volúmenes.

No porque quiera hacer el trabajo “más rápido” a cualquier costo. Al contrario. Lo hago así porque es la única manera que encuentro de mantener criterio cuando el volumen empieza a esconder los problemas.

Al final, no necesito que medio millón de productos sean idénticos ni que todos los proveedores aprendan a hablar exactamente igual. Necesito construir una estructura capaz de traducir esas diferencias sin perder significado. Y, sobre todo, necesito que el próximo archivo que llegue no me obligue a empezar otra vez desde cero. Para mí, ahí está la diferencia entre limpiar datos y construir realmente un catálogo sostenible.