Cómo organizo la información de un catálogo de moda: atributos, variantes y temporadas desde Excel
Un flujo práctico que suelo utilizar para estructurar los datos de un catálogo de moda antes de cargarlos en un PIM, con criterios claros para separar productos y variantes, normalizar atributos y organizar colecciones y temporadas.
Un catálogo de moda puede parecer bastante sencillo hasta que intentamos ordenarlo.
Tenemos una remera. Hasta ahí, todo bien. Pero esa remera viene en negro, blanco y verde; cada color está disponible en XS, S, M, L y XL; pertenece a una colección y una temporada determinadas; tiene una composición, instrucciones de cuidado, imágenes según el color y un SKU distinto para cada combinación.
De repente, aquella única remera se convirtió en quince referencias diferentes.
Y todavía no empezamos a hablar de talles regionales, colecciones cápsula, productos permanentes, cambios de nomenclatura entre temporadas o requisitos diferentes según el canal de venta.
Por eso, cuando tengo que organizar información de moda, no empiezo pensando en el PIM. Empiezo pensando en la estructura de los datos. Excel puede ser una herramienta muy útil para hacer este trabajo previo: permite entender qué tenemos, detectar inconsistencias y definir las reglas que después trasladaremos al sistema definitivo.
La clave es no usar la planilla simplemente como una lista gigante de productos. La podemos usar para modelar el catálogo antes de cargarlo.
Un PIM puede administrar muy bien una estructura compleja, pero no puede decidir por nosotros qué significa cada dato. Antes de automatizar el catálogo, necesitamos definir su lógica.
El primer problema: ¿cuántos productos tenemos realmente?
¿Un modelo de prenda es un producto o son muchos?
Esta parece una pregunta básica, pero es una de las primeras que necesitamos resolver.
Supongamos que tenemos una camisa Oxford azul disponible en cinco talles. ¿Tenemos un producto o cinco?
La respuesta depende del nivel desde el que observemos el catálogo. Desde el punto de vista comercial podemos pensar en un modelo de camisa. Sin embargo, desde el punto de vista del inventario y la venta tenemos cinco referencias diferentes, porque cada talle necesita identificarse de manera individual.
En un modelo de datos PIM podemos distinguir entonces entre dos niveles:
- Producto padre o modelo: reúne la información compartida por todas las opciones de la prenda.
- Variante: representa cada combinación concreta que puede diferenciarse o venderse individualmente, por ejemplo por color y talle.
Esta estructura padre-hijo es especialmente importante en moda. Un mismo modelo puede convertirse rápidamente en decenas de variantes y, si repetimos manualmente toda la información en cada SKU, también multiplicamos las oportunidades de introducir inconsistencias.
Por ejemplo, Akeneo utiliza justamente este principio para sus modelos de producto: las variantes heredan los atributos compartidos del padre y conservan a nivel individual aquellos que cambian, como color o talla.
En uno de los proyectos más grandes de CRITERIA, para una empresa de moda multimarcas, se trabajó con más de 5.000 productos padre y más de 20.000 variantes, incluyendo talles numéricos y alfanuméricos. A esa escala, la diferencia entre organizar correctamente el modelo y mantener una lista plana deja de ser una cuestión teórica: afecta directamente la capacidad de administrar el catálogo.
¿Qué información pertenece al producto padre y cuál a la variante?
Antes de crear columnas, separo lo que cambia de lo que no cambia.
Esta es, para mí, la regla más útil para empezar. En ese momento me hago esta pregunta:
¿Este dato describe al modelo completo o describe una variante específica?
Imaginemos una Camisa Oxford Essential disponible en azul, blanco y negro, y en talles S, M y L:
Camisa Oxford Essential
Disponible en:
- Azul / S, M, L
- Blanca / S, M, L
- Negra / S, M, L
Hay información que probablemente se mantenga igual en todas las combinaciones (variantes):
- marca;
- nombre del modelo;
- categoría;
- tipo de prenda;
- género o segmento;
- composición;
- tipo de cuello;
- tipo de manga;
- instrucciones de cuidado;
- colección.
En cambio, hay datos que pueden cambiar entre una variante y otra:
- SKU;
- color;
- talle;
- EAN o GTIN;
- imagen principal;
- estado de publicación de esa combinación.
Separar los datos así evita mantener varias copias del mismo dato o repetir la carga de la misma información que luego tendríamos que mantener manual e independientemente. Por ejemplo, si la composición de la camisa que mencionamos cambia de “100 % algodón” a “98 % algodón, 2 % elastano”, es mucho más seguro actualizarla como una característica común que tener que corregirla manualmente en nueve, quince o cincuenta filas. Lo modificamos una sola vez.
Los sistemas PIM que gestionan modelos y variantes utilizan justamente esta lógica: la información común puede heredarse desde un nivel superior y los datos que efectivamente cambian se administran en los niveles inferiores.
La pregunta más útil para ordenar variantes es muy simple: ¿este dato cambia entre las distintas opciones del producto? Si no cambia, probablemente no necesitemos gestionarlo repetidamente en cada SKU.
¿Cómo estructuro un catálogo de moda en Excel?
¿Cómo preparo la planilla?
Para empezar a trabajar no necesitamos una estructura sofisticada o compleja. Podemos crear una tabla sencilla que nos permita reconocer con claridad qué variantes pertenecen al mismo modelo.
Por ejemplo:
| ID padre | SKU | Nombre | Color | Talle | Temporada | Colección | Composición |
|---|---|---|---|---|---|---|---|
| CAM-OXF-01 | CAM-OXF-01-AZ-S | Camisa Oxford Essential | Azul | S | SS27 | Essential | 100 % algodón |
| CAM-OXF-01 | CAM-OXF-01-AZ-M | Camisa Oxford Essential | Azul | M | SS27 | Essential | 100 % algodón |
| CAM-OXF-01 | CAM-OXF-01-AZ-L | Camisa Oxford Essential | Azul | L | SS27 | Essential | 100 % algodón |
| CAM-OXF-01 | CAM-OXF-01-NE-S | Camisa Oxford Essential | Negro | S | SS27 | Essential | 100 % algodón |
| CAM-OXF-01 | CAM-OXF-01-NE-M | Camisa Oxford Essential | Negro | M | SS27 | Essential | 100 % algodón |
Aunque en este ejemplo todavía estamos repitiendo información, el campo ID padre establece una relación explícita: podemos reconocer qué SKUs forman parte del mismo modelo.
Cuando necesito una estructura un poco más ordenada, prefiero separar la información en dos hojas: productos padre y variantes.
Hoja 1: productos padre
En esta hoja de productos padre puedo tener una fila por modelo con campos como:
- ID padre;
- nombre;
- marca;
- categoría;
- subcategoría;
- género;
- línea;
- composición;
- material principal;
- instrucciones de cuidado;
- colección;
- temporada;
- descripción;
- país de origen.
Hoja 2: variantes
En la hoja de variantes puedo trabajar con una fila por SKU y campos como:
- ID padre;
- SKU;
- GTIN/EAN;
- color;
- código de color;
- talle;
- sistema de talles;
- imagen principal;
- estado
Esta estructura se acerca bastante más a la lógica que después encontraremos en muchos sistemas PIM. No es una plantilla universal. Cada negocio necesitará campos diferentes. Lo importante es que la estructura refleje las relaciones reales entre los datos y que podamos entender por qué existe cada columna.
Una celda debería contener un dato utilizable
Una celda, un dato. Otra regla que intento respetar desde el comienzo es no mezclar varios valores independientes dentro de una misma celda cuando después voy a necesitar procesarlos por separado.
Por ejemplo, evitaría utilizar una columna llamada “Colores disponibles” con este contenido:
Azul / Negro / Blanco
Puede resultar cómodo para leer, pero no es una estructura especialmente útil para importar, filtrar, validar o relacionar información.
Lo mismo sucede con una celda que contiene:
S, M, L, XL
Si cada variante tiene un único talle, prefiero que ese valor aparezca en su propia fila.
Esta idea responde a un principio básico de normalización: cuanto más explícita y atómica sea la información, más fácil resulta posteriormente buscarla, validarla, transformarla e integrarla con otros sistemas.
El ejemplo más sencillo está en el propio Excel. Si tenemos una columna Talle con un valor por fila, podemos filtrar todos los productos M inmediatamente. Si tengo S, M, L dentro de una sola celda, ese filtro deja de ser tan simple.
¿Cómo normalizo los colores sin perder los nombres comerciales?
El color es uno de esos atributos que parecen simples hasta que empezamos a trabajar con datos reales de moda.
Podemos encontrarnos con valores como Azul marino, Navy, Midnight Blue, Azul noche, Blue 402 o Navy Blue.
¿Son seis colores diferentes? Quizás sí. Quizás no.
El problema es que un catálogo puede necesitar dos cosas diferentes al mismo tiempo: conservar el nombre comercial definido por la marca y, además, disponer de un valor consistente para clasificar y filtrar.
Por eso podemos separar:
Color comercial: el nombre particular con el que la marca presenta la variante.
Color normalizado: un término controlado que utilizamos para organizar el catálogo.
Por ejemplo:
| Color comercial | Color normalizado |
|---|---|
| Midnight Navy | Azul |
| Ocean Blue | Azul |
| Black Ink | Negro |
| Snow White | Blanco |
No significa que tengamos que eliminar el nombre creativo, al contrario: puede ser muy importante para la identidad de marca. Simplemente estamos separando cómo se presenta el producto de cómo necesitamos clasificarlo.
Este tipo de vocabulario controlado nos ayuda a evitar que pequeñas variaciones de escritura creen valores diferentes dentro del catálogo.
Repito. No estamos reemplazando el nombre creativo ni eliminando información. Estamos separando presentación y clasificación, porque cumplen funciones diferentes.
Esto también evita que pequeñas diferencias de escritura terminen creando opciones distintas dentro de los filtros: Negro, negro, NEGRO y Black pueden ser perfectamente válidos en ciertos contextos, pero necesitamos decidir cuándo representan un mismo concepto dentro de nuestro catálogo.
Normalizar no significa borrar la riqueza del dato. Un catálogo puede conservar “Midnight Navy” como nombre comercial y utilizar “Azul” como valor normalizado para búsqueda y filtrado.
¿Cómo organizo talles numéricos, alfabéticos y regionales?
Con los talles aparece una dificultad parecida.
S, M y L parecen bastante claros hasta que el catálogo empieza a incorporar 38, 40, 42, 2, 3, 4, XS/S, 28W, 32L o diferentes sistemas nacionales e internacionales.
Por eso, según la complejidad del proyecto, un único campo llamado Talle puede quedarse corto.
Podemos necesitar distinguir entre talle comercial, sistema de talles, mercado y, cuando corresponda, alguna equivalencia.
No significa que todos los catálogos necesiten esas cuatro columnas. La estructura tiene que responder a una necesidad concreta y no debemos agregar complejidad porque sí. Pero sí conviene detectar cuándo un valor aislado deja de ser suficientemente explícito.
Un 40, por ejemplo, puede resultar perfectamente comprensible dentro de un catálogo específico y completamente ambiguo cuando esa misma información tiene que viajar a otros mercados o canales.
¿Temporada, colección y línea son el mismo dato?
Otra fuente frecuente de problemas es concentrar toda la información comercial de un lanzamiento dentro de una única columna.
Podemos recibir algo como:
Primavera Verano 2027 Essential Woman
Para una persona puede ser relativamente fácil interpretar ese texto. Para un sistema, en cambio, acabamos de mezclar varios conceptos.
Podríamos tener:
- Temporada: Primavera-Verano 2027
- Código de temporada: SS27
- Colección: Essential
- Segmento: Mujer
Separarlos permite hacer algo mucho más importante que tener una planilla prolija: permite reutilizar la información.
Podemos preguntar cuántos productos pertenecen a SS27, cuáles forman parte de Essential, qué modelos siguen activos independientemente de su temporada o cuántos productos de determinado segmento tiene una colección.
Además, no todos los productos responden necesariamente a la misma lógica estacional. Un catálogo puede incluir permanentes, básicos, carry over, reediciones o cápsulas. Si esos conceptos tienen funciones diferentes en el negocio, conviene no obligarlos a convivir dentro de un único campo.
Si necesito separar mentalmente un valor para poder responder preguntas sobre el catálogo, probablemente también convenga separarlo en el modelo de datos.
En moda, las imágenes también forman parte de la información del producto
En un catálogo de moda, una fotografía no es simplemente un complemento decorativo.
Una camisa negra y una camisa blanca pueden compartir nombre, composición y modelo, pero necesitan representar visualmente las diferencias que el comprador está eligiendo. La relación entre variante e imagen forma parte, por lo tanto, de la estructura del producto.
En la planilla podemos preparar campos como imagen principal, frente, espalda, detalle, imagen de contexto o muestra de color, según lo que realmente necesite el negocio.
No hace falta almacenar la imagen dentro de Excel. Podemos registrar un nombre de archivo, una URL o un identificador que permita asociarla posteriormente con el producto correcto.
También acá la nomenclatura importa. Un archivo llamado:
CAM-OXF-01-NEGRO-FRONT.jpg
nos da mucha más información y posibilidades de automatización que:
IMG_4587_final_final2.jpg
Cuando trabajamos con grandes cantidades de imágenes, una nomenclatura consistente deja de ser una cuestión estética y se convierte en una regla operativa.
¿Qué valido antes de cargar la planilla al PIM?
Una planilla organizada todavía no significa que los datos estén listos para importar. Antes de cargarlos, hago una revisión enfocada en encontrar inconsistencias estructurales.
Primero verifico los identificadores. Cada SKU tiene que representar la variante que esperamos y los duplicados necesitan revisarse. También compruebo que todas las variantes tengan un producto padre válido y que no existan combinaciones repetidas de los atributos que utilizamos como ejes de variación.
Después reviso los valores controlados. Si un mismo color aparece como Negro, negro, NEGRO, Black y Black color, necesito determinar cuáles son realmente equivalentes y qué criterio vamos a utilizar. Lo mismo ocurre si una familia trabaja con XS, S, M, L y XL y de pronto aparece Medium.
Por último, reviso la completitud de los campos necesarios y la relación con los activos: SKU, identificador padre, color, talle, categoría o cualquier otro atributo que hayamos definido como obligatorio para ese flujo.
No todos los errores se pueden corregir automáticamente. El objetivo de esta revisión es saber cuáles requieren una regla y cuáles requieren una decisión humana.
¿Cuándo Excel deja de ser suficiente para administrar el catálogo?
Todo este trabajo puede hacerse perfectamente en Excel. De hecho, una hoja de cálculo es una muy buena herramienta para analizar, limpiar y preparar datos de producto.
El problema aparece cuando intentamos convertirla en el sistema permanente que mantiene todas las relaciones del catálogo.
Con cien referencias quizás podamos sostenerlo. Cuando tenemos miles de modelos, decenas de miles de variantes, múltiples temporadas, varios equipos trabajando sobre la información y distintos canales de publicación, mantener manualmente esas relaciones se vuelve cada vez más difícil.
Un PIM permite administrar de manera estructurada productos, variantes, atributos, activos y contenido, además de preparar esa información para distribuirla hacia distintos destinos. En los sistemas que admiten herencia, también podemos definir qué datos son comunes al modelo y cuáles se completan específicamente en cada nivel de variación.
Pero hay algo importante: el PIM no corrige por sí solo un modelo de datos mal pensado.
Si ingresamos Primavera Verano 2027 Essential Woman como un único valor porque nunca distinguimos los conceptos que contiene, el sistema seguirá recibiendo un dato difícil de reutilizar.
Por eso la etapa de análisis anterior a la carga es tan importante.
Excel puede ser una excelente mesa de trabajo para preparar un catálogo. El problema no es usar una planilla: es pedirle que mantenga indefinidamente relaciones que ya necesitan un sistema diseñado para hacerlo.
Checklist para preparar un catálogo de moda antes de importarlo
Antes de realizar una carga, conviene poder responder estas preguntas:
- ¿Cada variante tiene un identificador único?
- ¿Puedo reconocer claramente a qué producto padre pertenece?
- ¿Sé qué atributos son comunes y cuáles cambian entre variantes?
- ¿Color y talle tienen valores claros y procesables?
- ¿Los colores siguen un criterio de normalización?
- ¿El sistema de talles puede interpretarse correctamente en su contexto?
- ¿Temporada y colección están separadas cuando representan conceptos diferentes?
- ¿Las imágenes pueden asociarse inequívocamente con los productos o variantes correspondientes?
- ¿Los campos necesarios para la carga están completos?
- ¿Existen duplicados o combinaciones de variantes repetidas?
- ¿Los valores que después utilizaremos para buscar, filtrar o publicar siguen criterios consistentes?
Si todavía no podemos responder estas preguntas con cierta seguridad, probablemente convenga seguir trabajando en la estructura antes de importar.
Ordenar primero nos permite automatizar después
Cuando trabajamos con información de producto aparece rápidamente la tentación de buscar una herramienta que resuelva el problema. Pero una herramienta puede almacenar con mucha eficiencia una estructura equivocada.
Una planilla relativamente sencilla, en cambio, puede ayudarnos a descubrir cuál debería ser esa estructura.
En moda, donde un mismo modelo puede convertirse rápidamente en numerosos SKUs y donde las colecciones se renuevan de manera constante, separar correctamente producto padre, variante, atributo, talle, color, temporada, colección y activo digital nos permite construir una base mucho más estable para todo lo que viene después.
El objetivo no es crear el Excel perfecto. Es utilizarlo para resolver las preguntas importantes antes de llevar el catálogo a un sistema más complejo.
Como cuando ordenamos una biblioteca antes de catalogarla: primero necesitamos entender qué tenemos, qué elementos están relacionados, cómo los vamos a identificar y bajo qué criterio queremos encontrarlos después. Una vez que esas reglas están claras, la tecnología puede ayudarnos a aplicarlas de forma consistente y a escala.
