Qué es un PIM y cómo saber si ya te hace falta

Esta mañana cambiaste la descripción de un producto. La tabla de tallas estaba mal y corregiste la redacción.

Ahora bien: ¿en qué otros sitios vive esa descripción?

Si la respuesta es "en ninguno, lo cambié en el único sitio donde existe", puedes dejar de leer. En serio. Todo lo que viene después trata de un problema que todavía no tienes, y no hay nada aquí en lo que merezca la pena gastar dinero hasta que lo tengas.

Si has tenido que pararte a contar, esto está escrito para ti.

La versión corta

Un PIM, siglas de product information management, es un sitio donde guardar la información de tus productos una sola vez. Cada tienda, marketplace y feed la lee de ahí en lugar de guardar su propia copia.

Esa es toda la idea.

El resto de esta página trata de las partes que nadie te cuenta: cuándo deja de ser un lujo, qué guarda de verdad uno de estos, cuánto cuesta y cómo son los primeros meses.

La prueba que te van a dar es la equivocada

Busca esto y te dirán que necesitas un PIM cuando tu catálogo pase de cierto número de productos. Cien, normalmente. A veces mil.

La prueba es fácil de aplicar, y mide justo lo que no duele.

Un vendedor con 12.000 productos en una sola tienda lo tiene fácil. Todo está en un sitio, se edita en una pantalla, y nada puede contradecir a nada. Catálogo grande, catálogo sencillo.

Un vendedor con 80 productos repartidos entre su tienda, dos marketplaces y un feed de proveedor lo tiene difícil. Cada descripción existe cuatro veces. Cada precio existe cuatro veces. Cuatro copias de la verdad, y nada que las obligue a coincidir.

Cuenta copias, no productos. Coge una frase sobre un producto y pregúntate en cuántos sitios hay que cambiarla para que el cambio esté terminado. Si la respuesta es uno, estás bien. Si es más de uno, ya tienes el problema, y lo único que queda por decidir es cómo lo resuelves.

Ahora mismo lo estás resolviendo con archivos

Casi todo el mundo empieza igual. Exportas una hoja de cálculo, la editas y la vuelves a importar. O mantienes una hoja maestra y copias de ahí a cada canal.

Esto funciona, y funciona durante más tiempo del que la gente espera. Precisamente por eso merece la pena saber qué le hace a tus datos mientras funciona.

El fallo no hace ruido. No se rompe nada, el archivo se importa bien, y parte de tus datos ya no dice lo que tú querías. Hay tres razones mecánicas, y ninguna es evidente.

Una celda vacía significa dos cosas opuestas

Exportas cuarenta columnas y editas dos. Las otras treinta y ocho vuelven vacías, y lo que quieres es que nadie las toque: aquí el hueco significa "no te estoy diciendo nada sobre este campo, deja lo que hay".

Ahora ese mismo archivo llega cada noche de un proveedor y la columna de precio viene vacía. Esta vez el hueco significa que el proveedor ya no tiene ese precio, y dejar el antiguo sería mostrar existencias que no tienes.

El mismo archivo. La misma celda en blanco. Dos lecturas correctas que se contradicen, y cuál de las dos vale depende de un contexto que no está en el archivo por ningún lado.

En nuestro propio sistema de catálogo son dos caminos de código distintos, a propósito. La regla dice: una importación es puntual, así que vacío significa que no hay dato; un feed de proveedor sobrescribe según la política que definas por campo.

Ahora mira la herramienta que usas hoy y pregúntate cuál de las dos reglas sigue. La mayoría elige una, es coherente con ella y nunca te dice cuál. Algunas te dejan elegir en cada importación. Al menos una plataforma conocida borra el valor, y la gente suele descubrirlo la primera vez que una columna a medio rellenar deja un campo en blanco en todo el catálogo.

Exportar y volver a importar no es una operación neutra

El flujo obvio es exportar, editar, importar. No cambió nada salvo tus dos celdas.

Salvo que el archivo salió de un sistema, así que sus cabeceras de columna son los nombres de campo de ese mismo sistema. Suena a comodidad, y es justo donde está la trampa.

Una columna cuya cabecera coincide con el nombre de un campo interno se lee como ese campo, tanto si tú querías como si no. Nos topamos con esto exactamente, y la lección es tajante: una cabecera canónica se parece exactamente al nombre de un campo, la hayas mapeado o no.

Así que un viaje de ida y vuelta que parece dos celdas editadas puede cambiar un ajuste en todas las filas, porque todas llevaban una columna que nunca miraste.

El control de inventario suele ser donde aparece primero. Es un ajuste y no un valor, y nadie repasa una hoja de cálculo fijándose en los ajustes.

Los archivos CSV y las hojas de cálculo no coinciden en dónde está la cabecera

Esta es pequeña y hace perder tardes enteras.

En un archivo CSV, la cabecera es la primera línea que tiene contenido, así que las líneas vacías del principio se descartan antes de que nada las lea. En un archivo XLSX, la cabecera es físicamente la fila uno, esté vacía o no.

Así que un archivo con la primera fila en blanco se lee bien como hoja de cálculo y etiqueta mal todas las columnas como CSV, o al revés. Tuvimos que escribir las dos reglas por separado en nuestro propio lector, una por formato, porque unificarlas rompe una de las dos sin avisar.

Nada de esto es culpa tuya, y no hay cuidado con el archivo que lo evite. Es una propiedad de los formatos.

Qué hace un PIM con todo esto

Elimina las copias.

No las "sincroniza", que es la palabra que usa todo el mundo y que en el fondo significa "mantiene dos copias e intenta que coincidan". Las elimina. La descripción existe una vez, cada canal lee ese único sitio, y ya no queda nada que reconciliar porque no queda nada que pueda discrepar.

Todo lo demás sale de ahí, y las listas de funciones que has leído son en su mayoría consecuencias más que motivos. La edición masiva importa porque ahora editas una vez. Los controles de completitud importan porque hay un único sitio donde un campo está relleno o no lo está. El formato por canal importa porque el mismo producto tiene que verse distinto en Amazon que en tu tienda, y eso es un problema de formato una vez que el dato de debajo es uno solo.

Si un PIM está haciendo su trabajo, lo que cambia en tu semana es pequeño y concreto: deja de aparecer la frase "tengo que acordarme de cambiar eso también en los otros sitios".

Qué guarda de verdad uno de estos

Merece la pena concretar, porque "información de producto" abarca mucho.

El producto en sí. Nombre, descripción, marca, categoría, los identificadores que exige cada canal (código de barras, referencia del fabricante), coste y precio, medidas y peso para el envío. Más o menos lo que uno esperaría.

Los atributos, que son la parte que sorprende. El largo de manga pertenece a las camisas y el tamaño de pantalla pertenece a los monitores, sin que ninguno pertenezca al otro. Un atributo es simplemente una propiedad con nombre que pertenece a un tipo de producto y no a todos, y esto sale a relucir porque el formulario que trae una tienda suele darte un único conjunto plano de campos para todo lo que vendes.

Importa más de lo que parece. Los canales piden atributos por su nombre y piden unos distintos según la categoría, así que si el material está escrito dentro de la descripción como prosa, ningún canal puede leerlo. Si es un atributo, se le puede entregar a cualquier canal que lo pida.

Las variantes, y en concreto las que no existen. Una camisa en tres tallas y cuatro colores sugiere doce variantes. Quizá tengas once, porque la XL solo viene en negro.

Muchos sistemas no te dejan decir eso. Generan todas las combinaciones y esperan que las rellenes todas, o que conserves filas muertas para siempre. Nuestro propio modelo construye las variantes contra las que ya existen en lugar de regenerar la rejilla completa, así que un hueco deliberado es un estado normal y no un error de datos. Si vendes ropa, ya sabes por qué esto importa.

Imágenes y archivos, vinculados al producto en lugar de subidos canal por canal. Aquí es donde las dos categorías se solapan: guardar bien los archivos es gestión de activos digitales, y algunos PIM la incluyen.

Traducciones, en las herramientas que las admiten. Donde una herramienta las guarda bien, un segundo idioma es otro valor del mismo campo y no una segunda copia del producto, que es la diferencia entre corregir una errata una vez o corregirla una vez por idioma.

Esta es la mayor diferencia entre productos de esta categoría, así que compruébalo en lugar de darlo por supuesto. La nuestra hoy no lo hace. Nuestro contenido de producto es de un solo idioma, y si necesitas mantener el mismo catálogo en dos idiomas, esa es una razón real para mirar otra cosa por ahora.

Cómo llega la información a cada canal

Casi todas las explicaciones se saltan esta parte, y es donde aparece el valor.

Amazon tiene su propio árbol de categorías y sus propios campos obligatorios. Tu tienda tiene plantillas y maquetación. Un feed de compras quiere un archivo plano con nombres de columna concretos. Cada uno quiere el mismo producto descrito de otra manera, así que el producto no cambia, pero sí cambia la forma de la respuesta.

Por eso un PIM guarda un solo producto más un conjunto de reglas por destino sobre cómo hay que expresarlo allí. Qué atributo corresponde a cada campo suyo. Qué descripción sale, porque una publicación en un marketplace y la ficha de tu tienda rara vez son el mismo párrafo. Qué imágenes, en qué orden y a qué tamaño.

Los canales discrepan de verdad en las imágenes. Uno la quiere cuadrada, otro rechaza la animación, otro limita el peso del archivo, y esos límites son reales y todos distintos.

La consecuencia práctica es la misma de antes, vista desde el otro lado. Cambias el producto una vez y cada destino recibe la versión que quiere. Nadie vuelve a teclear nada y nada se desvía, y no por disciplina: es que nunca hubo una segunda copia que pudiera desviarse.

Tres cosas que la gente confunde con un PIM

Merece la pena saberlo, porque comprar la equivocada sale cara y lenta.

Un gestor de feeds no es un PIM. Estas herramientas cogen un catálogo que ya tienes y le dan forma para cada destino, lo cual sirve de verdad y es otro trabajo. Dan por supuesto que tus datos de producto ya están correctos y viven en un solo sitio, y si no lo están, un gestor de feeds reparte el desorden más rápido.

Un ERP no es un PIM, aunque muchos guarden fichas de producto. Un ERP está construido alrededor de transacciones: existencias, pedidos, facturas, coste. Sabe el número de un producto y lo que cuesta. Rara vez está hecho para guardar cuarenta atributos de marketing, descripciones por canal y una docena de imágenes por producto, y los equipos que lo intentan lo descubren unos meses después.

Un DAM tampoco es un PIM. La gestión de activos digitales guarda archivos: imágenes, vídeo, documentos, y algunos PIM incluyen uno. Si tu problema es "cuál es la imagen buena", eso es un problema de DAM; si es "cuál es la descripción buena", no lo es.

Y ninguno sustituye a tu tienda. Un PIM no vende nada y no tiene pasarela de pago. Tu tienda, tus cuentas de marketplace y tu pasarela siguen exactamente donde están. Solo cambia una cosa: de dónde salen el texto y las imágenes del producto.

Cuándo de verdad no te hace falta

Déjalo para más adelante si:

• –Todo vive en un solo sitio y siempre ha sido así. Una tienda, editada desde su propio panel. No hay una segunda copia, así que no hay nada que mantener de acuerdo.
• –Tu catálogo casi no se mueve. Cincuenta productos que cambian dos veces al año se llevan con cuidado y un recordatorio en el calendario, porque el coste de un error es bajo y pasa pocas veces.
• –Estás a punto de cambiar de plataforma. Mudar tu tienda y añadir un sistema encima son dos migraciones a la vez. Haz una.
• –El trabajo es pesado pero no sale mal. Si actualizar tres sitios es tedioso y aun así lo haces bien siempre, estás comprando tiempo y no evitando daños. Es una razón real, y es más débil, así que debería sentirse como una decisión más pequeña.

El motivo para dar el paso no es haber pasado de cierto número de productos. Es haber dejado de fiarte de tu propio catálogo: salió una publicación con el precio de la temporada pasada, un canal rechazó un producto por un campo que jurarías que estaba relleno, alguien preguntó cuál es la hoja de cálculo buena.

Esa pérdida de confianza es el umbral de verdad, y suele notarse unos seis meses tarde.

Cuánto cuesta, y de qué está hecho ese coste

Los precios publicados en esta categoría van desde decenas de dólares al mes en la parte baja hasta decenas de miles al año en la parte alta, y la diferencia no es sobre todo de funciones.

Es de quién es el comprador. El precio de gama empresarial da por supuesto un proceso de compras, un equipo de servicios y una implantación de varios meses, y está puesto para eso lo necesites tú o no.

El número de la página de precios tampoco suele ser el coste completo. Aparecen otras tres líneas:

• –La implantación. En la gama alta cuesta habitualmente tanto como el primer año de licencia, y en la gama baja se supone que es cero. Si un producto necesita una puesta en marcha de pago para poder usarse, eso forma parte de lo que cuesta.
• –La migración de datos, que se cotiza por lo desordenados que estén tus datos actuales más que por cuántos sean.
• –Tu propio tiempo, que es el que nadie presupuesta y el que de verdad vas a gastar.

Lo nuestro es lo único que podemos afirmar como dato: el PIM es gratis hasta 500 productos, y los planes de pago empiezan en 49 dólares al mes, tarifa plana y sin medición por uso. Eso es una fracción de la gama alta, y la razón honesta es que no estamos hechos para el comprador empresarial, no que hayamos encontrado un truco.

Qué esperar si das el paso

Cuatro avisos honestos, porque los que vas a leer en otros sitios son optimistas.

La primera importación es el trabajo. No la herramienta. Dejar tus datos actuales en una forma que un sistema pueda guardar significa decidir cuáles son de verdad tus atributos, y la mayoría de los catálogos lleva años esquivando esa decisión. Cuenta con que saldrán a la luz desacuerdos sobre tus propios productos. Eso es el valor llegando, de forma incómoda.

Revisa antes de importar, no después. El error caro de todo esto es cargarlo todo y limpiarlo en caliente, porque luego te pasas meses arreglando datos que los clientes ya están leyendo. Mira primero una muestra de lo que tienes y corrige el origen. Es lento, y es la parte que se paga sola.

Cuenta con que la migración tarde más de lo que crees. Es habitual presupuestar un par de semanas y verse a las seis. El tiempo de más casi nunca es técnico: se va en decidir cómo debe ser tu modelo de producto, que es la pregunta que la hoja de cálculo te permitía no contestar.

Vas a seguir exportando cosas. Un PIM no acaba con las hojas de cálculo, y un proveedor te mandará un archivo la semana que viene igualmente. El archivo deja de ser donde vive la verdad y pasa a ser lo que siempre debió ser, que es una forma de meter y sacar datos.

Y uno más, sobre personas y no sobre datos: esto es de quien lleva el catálogo, no del área técnica. Las decisiones que hacen que funcione son editoriales, sobre qué significan tus atributos y cuál es la descripción correcta, y un responsable técnico construirá un sistema que funciona y que responde las preguntas equivocadas.

Preguntas que suelen venir después

Nosotros hacemos uno de estos, así que tómalo como el interés que es. Nuestro propio PIM seguirá ahí cuando hayas decidido. Si lo que te llevas de esta página es que con tu única tienda estás bien y que puedes dejar de leer sobre PIM durante otro año, eso es un buen resultado y es el honesto.