Cómo gestiono los activos digitales dentro de un proyecto PIM: el flujo que funciona
La imagen correcta, en el formato correcto, vinculada al producto correcto. En este artículo describo el flujo de trabajo que sigo para identificar, organizar, aprobar y distribuir activos digitales dentro de un proyecto de catalogación.
Cuando hablamos de calidad de información de producto, solemos pensar primero en categorías, atributos, descripciones y especificaciones técnicas. Las imágenes aparecen después, casi como si fueran un complemento visual que se agrega cuando la ficha ya está terminada.
En la práctica, no funcionan así.
Una fotografía, un manual, un certificado, una ficha técnica, un video o un render también forman parte de la información del producto. Cada archivo tiene una identidad, una función, una versión, una relación con una entidad concreta y unas condiciones de publicación.
Por eso, un activo no está correctamente gestionado solo porque fue cargado al PIM. Debe ser el archivo vigente, estar vinculado con el producto adecuado, ocupar la posición que le corresponde y cumplir los requisitos del canal donde aparecerá.
El flujo que intento construir en cada proyecto puede resumirse así:
Relevamiento → normalización → clasificación → vinculación → validación → aprobación → distribución → control posterior
La secuencia parece lineal. Casi nunca lo es. En los proyectos reales encuentro imágenes duplicadas, documentos sin identificar, variantes que comparten recursos, archivos antiguos mezclados con los vigentes y canales que necesitan representaciones diferentes del mismo producto.
Mi trabajo consiste en convertir ese conjunto de archivos en un sistema que el equipo pueda comprender y mantener.
Una carpeta llena de imágenes no es una biblioteca de activos. Para que pueda gestionarse, cada archivo necesita identidad, contexto, función y una relación verificable con el producto.
¿Qué es un activo digital dentro de un proyecto PIM?
Un activo digital es cualquier archivo relacionado con un producto que sirve para identificarlo, describirlo, venderlo, documentarlo o distribuirlo.
Las fotografías son el ejemplo más evidente, pero no son el único. Dentro de un proyecto PIM puedo trabajar con:
- Imágenes principales y secundarias.
- Videos de producto, instalación o uso.
- Manuales.
- Fichas técnicas.
- Certificados.
- Documentos de garantía.
- Renders.
- Infografías.
- Tablas de medidas.
- Archivos 3D.
- Planos o documentos CAD.
- Imágenes del empaque.
- Recursos para catálogos impresos.
Cada activo cumple una función diferente. Una imagen principal permite reconocer el producto. Una fotografía de contexto muestra cómo se usa. Un detalle visual ayuda a comprender el material o la terminación. Una ficha técnica permite comparar especificaciones. Un certificado puede ser necesario para validar una propiedad o cumplir un requisito comercial.
El problema aparece cuando todos esos archivos se almacenan sin distinguir para qué sirven.
Si el PIM contiene recursos llamados imagen1.jpg, imagen2.jpg, ficha.pdf, ficha_nueva.pdf y final_ahora_si.pdf, los archivos existen, pero el sistema no conoce realmente su significado.
¿Por qué una imagen debe tratarse como un dato?
Una imagen tiene propiedades que determinan cómo debe usarse.
Necesito saber a qué producto pertenece, qué representa, si corresponde a una variante, cuál es su orden, si está aprobada y en qué canales puede publicarse. También tengo que distinguir si se trata de una vista frontal, una fotografía de detalle, una imagen de ambiente o una tabla de medidas.
Esa información sobre el archivo forma parte de sus metadatos.
| Metadato | Ejemplo |
|---|---|
| Producto relacionado | SKU-45892 |
| Tipo de activo | Imagen de producto |
| Función | Principal |
| Vista | Frontal |
| Variante | Azul marino |
| Orden | 1 |
| Estado | Aprobado |
| Canales | Shopify, VTEX y Mercado Libre |
| Mercado o idioma | Global |
| Vigencia | Activo |
Sin estos metadatos, la relación depende del nombre del archivo, de la carpeta donde quedó guardado o de que alguien recuerde de dónde vino.
Eso puede sostenerse durante un tiempo en un catálogo pequeño. Cuando el volumen crece, se convierte en una operación frágil.
El archivo contiene la imagen o el documento. Los metadatos explican qué representa, para qué sirve y dónde puede publicarse.
¿Dónde deben vivir los activos: en el PIM o en un DAM?
No todos los proyectos necesitan un DAM separado.
Un DAM, o sistema de gestión de activos digitales, está diseñado para almacenar, clasificar, versionar, transformar y distribuir imágenes, videos y documentos. El PIM, en cambio, se enfoca en la información de producto y en la relación entre esos activos y las entidades del catálogo.
Algunas plataformas PIM, como Akeneo, Plytix o Sales Layer, ofrecen capacidades para almacenar y relacionar activos dentro del propio catálogo. En proyectos de complejidad media, esas funciones pueden ser suficientes.
En operaciones más amplias, el DAM puede actuar como repositorio maestro. El PIM conserva la relación entre el archivo y el producto, mientras el DAM administra versiones, metadatos, permisos, transformaciones y derechos de uso.
Para decidirlo, observo variables como:
- La cantidad y diversidad de archivos.
- El número de equipos que intervienen.
- La necesidad de manejar versiones.
- Los flujos de aprobación.
- Los derechos de uso y fechas de vencimiento.
- La cantidad de marcas, mercados e idiomas.
- La necesidad de generar formatos derivados.
- El volumen de videos, renders o archivos editables.
La pregunta central no es solamente dónde guardar el archivo. Es qué sistema tiene autoridad para aprobarlo, reemplazarlo y determinar cuál es su versión vigente.
¿Cómo empiezo el diagnóstico de los activos existentes?
Antes de migrar o reorganizar los archivos, necesito saber qué existe realmente.
No me alcanza con revisar la carpeta más prolija del equipo de marketing. También necesito observar los recursos que circulan entre producto, diseño, proveedores, eCommerce, marketplaces y catálogos impresos.
Durante el relevamiento busco:
- Archivos duplicados con nombres diferentes.
- Imágenes distintas con el mismo nombre.
- Fotografías sin SKU ni identificador.
- Versiones anteriores mezcladas con las vigentes.
- Productos sin imagen.
- Activos vinculados con productos discontinuados.
- Documentos vencidos.
- Archivos con baja resolución.
- Variantes que muestran otro color.
- Recursos sin responsable definido.
Después comparo los archivos con el catálogo.
Una carpeta puede contener miles de imágenes y dar una sensación de abundancia. Pero si no puedo relacionarlas con los productos activos, esa cantidad no representa cobertura real.
Durante el diagnóstico observo cuatro dimensiones:
Cobertura: cuántos productos tienen los activos necesarios.
Identificación: cuántos archivos pueden relacionarse con una entidad concreta.
Calidad: cuántos cumplen los requisitos técnicos y visuales.
Vigencia: cuántos representan la versión actual del producto.
Estas dimensiones me permiten distinguir entre un problema de cantidad y uno de organización. A veces no faltan fotografías: faltan relaciones confiables.
¿Cómo defino una nomenclatura que el equipo pueda mantener?
El nombre del archivo no debería ser la única fuente de información, pero sigue siendo importante.
Una nomenclatura clara facilita la carga masiva, la búsqueda, la detección de errores y la relación automática con productos o variantes.
Un esquema posible es:
Identificador + función + variante + orden
Por ejemplo:
SKU45892_PRINCIPAL_AZUL_01.jpg
SKU45892_DETALLE_AZUL_02.jpg
SKU45892_MANUAL_ES.pdf
No existe una fórmula universal. Depende del tipo de producto, del modelo de variantes, de los canales y de las capacidades de la plataforma.
En Akeneo, Plytix o Sales Layer puedo modelar las relaciones de distintas maneras, pero el criterio previo sigue siendo el mismo: cada componente del nombre debe tener un significado documentado.
Evito incluir datos que puedan cambiar con frecuencia, como una categoría comercial, una temporada promocional o un texto de campaña. Si el producto cambia de categoría, no quiero renombrar todos sus archivos.
También evito nombres demasiado largos o difíciles de interpretar. La nomenclatura debe ayudar al flujo, no agregar otra capa de complejidad.
Una nomenclatura clara no reemplaza los metadatos, pero reduce errores y permite automatizar relaciones que de otra manera dependerían de una revisión manual.
¿Cómo vinculo cada activo con el producto correcto?
Esta es una de las decisiones más importantes del flujo.
Un activo puede pertenecer al producto padre, a una variante, a una familia o a un conjunto de referencias. Vincularlo en el nivel equivocado genera duplicaciones, herencias incorrectas y publicaciones que muestran imágenes de otro producto.
En indumentaria, por ejemplo, la tabla de tallas puede pertenecer al producto padre. Las fotografías de cada color deben relacionarse con el nivel correspondiente a esa variante. Los SKU de talla pueden heredar las imágenes del color, porque fotografiar cada combinación de color y talla no suele tener sentido.
En un catálogo industrial, un manual puede aplicarse a una línea completa. Una ficha técnica o un plano, en cambio, podría corresponder a una referencia específica.
Antes de crear una relación, me pregunto:
- ¿El activo representa a todo el grupo?
- ¿Depende de una variante?
- ¿Puede compartirse entre varios productos?
- ¿Debe heredarse?
- ¿Qué ocurre cuando se reemplaza?
- ¿Quién puede modificar la vinculación?
Cuando el nombre del archivo contiene un SKU o un identificador estable, puedo automatizar parte de la asociación. Pero incluso en esos casos necesito controles.
Un archivo puede cumplir el formato, la resolución y la nomenclatura esperada y, aun así, estar relacionado con el producto equivocado. Es un error difícil de detectar porque la integración puede ejecutarse sin devolver ninguna alerta.
¿Cómo diferencio la función y el orden de las imágenes?
No todas las imágenes cumplen el mismo propósito, aunque tengan el mismo formato.
Suelo distinguir entre:
- Imagen principal.
- Vista frontal.
- Vista lateral.
- Vista posterior.
- Detalle.
- Ambiente o contexto.
- Infografía.
- Empaque.
- Tabla de medidas.
- Imagen específica del canal.
Esta clasificación me permite decidir qué recursos se publican, en qué orden aparecen y a qué destinos se envían.
La imagen principal requiere una atención especial. Es la primera representación del producto en una página de detalle, un listado o un marketplace. No debería definirse simplemente por el orden en que los archivos fueron cargados.
También puede ocurrir que una misma fotografía no sea adecuada como principal en todos los canales. Mercado Libre, Amazon, Shopify o VTEX pueden mostrar los activos de manera distinta y aplicar reglas diferentes.
Por eso, cuando el proyecto lo necesita, separo el orden maestro del orden por canal.
El primero conserva una secuencia central. El segundo adapta esa secuencia a la experiencia y a las condiciones de cada destino.
¿Cómo gestiono formatos, tamaños y versiones derivadas?
Uno de los errores más comunes es crear manualmente muchas copias del mismo archivo:
producto_alta.jpg
producto_web.jpg
producto_web_chica.jpg
producto_marketplace.jpg
producto_marketplace_final.jpg
El problema no es solo el espacio que ocupan. Es la pérdida de control sobre cuál es la versión correcta.
Cuando cambia el archivo original, alguien debe recordar actualizar todas las copias. Si una queda afuera del reemplazo, los canales empiezan a mostrar imágenes diferentes.
Siempre que la arquitectura lo permite, prefiero trabajar con un archivo maestro y generar desde allí las versiones necesarias.
El archivo maestro conserva la mejor calidad disponible. A partir de él se producen tamaños, proporciones, formatos o niveles de compresión específicos para cada canal.
Cuando el proceso no puede automatizarse, documento qué versiones deben crearse, dónde se almacenan y cómo se relacionan con el original.
También reviso el resultado visual. Una transformación técnicamente correcta puede recortar una parte importante del producto, deformar una proporción o volver ilegible una tabla.
El objetivo no es solamente cumplir con un tamaño. Es mantener una representación fiel del producto.
¿Qué estados necesita el flujo de aprobación?
No todos los activos deberían publicarse en el momento en que ingresan.
Un flujo posible es:
Recibido → en revisión → requiere corrección → aprobado → publicado → archivado
No todos los proyectos necesitan tantos estados. En un equipo pequeño, un proceso muy complejo puede convertirse en una carga. En una operación con varias áreas, publicar cualquier archivo apenas se carga también puede ser riesgoso.
Necesito definir:
- Quién produce o recibe el activo.
- Quién valida su calidad técnica.
- Quién verifica la relación con el producto.
- Quién aprueba el contenido.
- Quién autoriza la publicación.
- Quién puede reemplazarlo.
- Quién revisa archivos vencidos.
Marketing puede aprobar la presentación visual. Ingeniería puede comprobar que la imagen represente correctamente una configuración técnica. En sectores regulados, también pueden intervenir equipos legales o de cumplimiento.
El PIM o el DAM deberían reflejar ese proceso hasta donde aporte control. La herramienta tiene que sostener la operación, no sumar pasos que el equipo no entiende ni cumple.
¿Cómo reemplazo un activo sin dejar versiones viejas en circulación?
Actualizar una imagen no consiste solamente en cargar un archivo nuevo.
También tengo que revisar:
- Qué versión queda vigente.
- Qué productos usan el activo.
- En qué canales fue publicado.
- Si cambia la URL.
- Si existen copias en caché.
- Si el archivo anterior debe archivarse.
- Si el nuevo recurso conserva el mismo orden.
- Si necesita una nueva aprobación.
En un flujo bien diseñado, el reemplazo conserva la relación con el producto y activa la actualización en los destinos correspondientes.
En uno desordenado, el archivo nuevo se suma como otro activo. El anterior continúa vinculado, Shopify muestra una versión, Mercado Libre conserva otra y el catálogo PDF sigue tomando la primera.
Reemplazar una imagen no es subir un archivo nuevo. Es retirar una versión, activar otra y comprobar que el cambio llegó a todos los canales donde ese activo estaba en uso.
¿Qué reviso después de publicar los activos?
No considero terminado el proceso cuando el conector informa que las imágenes fueron enviadas.
Necesito revisar el resultado en el canal.
Compruebo si:
- La imagen principal es la correcta.
- El orden se mantiene.
- Cada variante muestra el color correspondiente.
- Los documentos se pueden abrir o descargar.
- No aparecen duplicados.
- La calidad visual es suficiente.
- El recorte no elimina información importante.
- Las versiones anteriores dejaron de mostrarse.
- Los productos sin activos quedan identificados como excepciones.
También reviso diferentes contextos: la página de detalle, el listado, la búsqueda, la vista móvil, el marketplace y el catálogo impreso cuando corresponde.
Una imagen puede verse correctamente en la ficha y quedar mal recortada en la tarjeta del listado. Un manual puede existir en el PIM y no haber llegado al eCommerce. Una variante puede mostrar bien su miniatura y abrir una fotografía de otro color.
La validación debe reproducir la experiencia real de quien consulta el producto.
¿Qué aprendí en proyectos con grandes volúmenes de activos?
En un proyecto regional de indumentaria multimarca se trabajó con miles de productos padre, decenas de miles de variantes y miles de imágenes.
El desafío no consistía solamente en cargar los archivos. Había que mantener la relación entre modelos, colores, tallas y canales. Los activos debían alimentar un eCommerce multitienda, un punto de venta, un marketplace y un flujo de catálogo editorial.
Ese tipo de ecosistema deja algo muy claro: la relación entre producto y activo forma parte del modelo de datos.
En otro proyecto industrial se reorganizaron las imágenes publicadas en dos tiendas Shopify Plus alimentadas desde Plytix. La revisión también incluyó productos, colecciones, menús y campos personalizados. Trabajar solo sobre las fotografías no habría resuelto el problema, porque la presentación visual dependía de todo el modelo.
También participamos en una reimplementación donde fue necesario reingresar decenas de miles de productos y activos. En una migración de ese tamaño, una nomenclatura débil o una relación poco clara puede convertir la carga en una revisión manual interminable.
Estos casos confirman algo que aparece una y otra vez: los activos no pueden organizarse al final del proyecto como si fueran un agregado visual. Deben formar parte del diseño desde el principio.
¿Cuál es el flujo que mejor funciona para gestionar activos digitales?
El flujo que intento construir es sencillo de explicar, aunque requiera bastante trabajo inicial:
- Recibo o localizo el activo.
- Verifico su identidad y calidad.
- Normalizo el nombre y los metadatos.
- Defino su función.
- Lo vinculo con la entidad correcta.
- Lo someto a revisión cuando corresponde.
- Genero las versiones necesarias.
- Lo distribuyo a los canales.
- Reviso el resultado visible.
- Mantengo su vigencia y sus reemplazos.
La plataforma puede ser Akeneo, Plytix, Sales Layer u otra. Puede existir un DAM independiente o una biblioteca integrada en el PIM. El detalle técnico cambia, pero la lógica se mantiene.
El flujo funciona cuando cualquier persona autorizada puede responder con claridad:
- ¿Cuál es el activo vigente?
- ¿A qué producto pertenece?
- ¿Qué función cumple?
- ¿Quién lo aprobó?
- ¿Dónde está publicado?
- ¿Qué ocurrirá cuando sea reemplazado?
Cuando esas respuestas dependen de abrir varias carpetas y preguntarle a la única persona que “sabe dónde está todo”, todavía no existe una gestión de activos. Existe una colección de archivos.
La imagen correcta no llega al producto correcto por casualidad. Llega porque el activo fue identificado, clasificado, vinculado, aprobado y distribuido mediante reglas que el equipo puede comprender y mantener. Cuando ese flujo está bien diseñado, las imágenes y los documentos dejan de ser archivos sueltos y se convierten en una parte confiable de la información de producto.
