Pasar el catálogo de Excel a un PIM y empezar a tener registro de los cambios

Alguien de tu equipo pregunta cuál es el archivo bueno.

Hay uno con la fecha en el nombre. Otro que termina en _v2_final. Otro que alguien descargó el martes para mandarle una lista de precios a un proveedor.

Tú sabes la respuesta, y ese es justamente el problema, porque no la sabe nadie más. Lo que estorba nunca fue la cantidad de archivos: es que la única copia fiable de la verdad la llevas en la cabeza.

Este es uno de los trabajos para los que construimos nuestro PIM. Parte de lo que viene sirve para la herramienta que elijas y el resto es específico del nuestro; esta página va diciendo cuál es cuál.

El problema de llevar un catálogo en hojas de cálculo

Aquí está la parte incómoda, y por eso esta página empieza por ahí y no por las ventajas.

Una migración de catálogo rara vez se rompe con ruido. El archivo se importa, el sistema dice que todo fue bien y los productos aparecen. Semanas después alguien nota que a una categoría entera le falta el peso de envío, y nadie recuerda haber tocado ese campo, porque nadie lo tocó.

Hay un segundo motivo por el que esto se pospone un año, y tiene menos que ver con los datos que con la memoria. La hoja de cálculo es hoy lo único que recuerda algo: un comentario que alguien dejó en una celda en marzo, una fila en amarillo que significa algo preciso para las dos personas que acordaron qué significa el amarillo, un historial que sabe quién tocó el archivo el jueves pasado.

Así que mudarse parece cambiar una memoria mala por ninguna memoria. Es un miedo razonable, y también apunta al sitio equivocado.

Qué puede salir mal durante una importación

Dos comportamientos de importación causan casi todo el daño, y ninguno es evidente hasta que ya te ha costado algo.

Toda herramienta tiene que decidir sobre el primero. En el segundo, las herramientas se diferencian bastante.

Una celda vacía significa dos cosas opuestas

Deja una celda en blanco y no habrás dicho nada. También habrás dicho algo muy concreto. Cuál de las dos cosas es depende por completo de para qué sirve el archivo.

Cuando el archivo es una corrección, una celda vacía significa "no te estoy diciendo nada sobre este campo, déjalo como está". Exportaste cuarenta columnas, editaste dos y prefieres que las otras treinta y ocho sobrevivan al viaje.

Cuando el archivo es una foto completa, esa misma celda vacía significa lo contrario: este valor ahora está vacío. Dejar el número de ayer haría que tu catálogo dijera algo que el origen ya no dice, y así es como acabas anunciando inventario que no tienes.

El mismo archivo. La misma celda en blanco. Dos respuestas correctas que se contradicen.

Una edición masiva puntual suele ser una corrección y un feed de proveedor suele ser una foto, pero no es la frecuencia lo que lo decide. Depende de una sola cosa: ¿este archivo es una corrección o una foto completa? Un archivo que armaste a mano puede ser perfectamente una foto completa.

Ahora lleva eso a lo que vas a hacer tú. Tu primera actualización de verdad va a mapear cuatro columnas, porque para eso sirve una edición masiva: corregir los títulos, poner una referencia de proveedor, arreglar la categoría de ochocientas filas de una vez.

Todo campo que decidiste no mapear debería quedar fuera de esa actualización. Lo que plantea la pregunta siguiente, que es la que conviene hacer en voz alta: ¿el sistema deja esas columnas en paz, o las reconoce por su cuenta?

El archivo que exportaste no vuelve a entrar igual

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

Salvo que el archivo lleva cabeceras de columna que ese mismo sistema reconoce, y algunos flujos de importación tratan una cabecera reconocida como una instrucción en sí misma en lugar de pedirte que mapees cada campo.

Donde eso pasa, un viaje de ida y vuelta que parece la edición de dos celdas puede cambiar en silencio un ajuste en todas las filas, porque todas llevaban una columna que nadie pensó en mirar.

Los ajustes suelen delatar esto antes que los valores. Se pasan por alto con más facilidad en una hoja de cálculo, y el control de inventario es el ejemplo con el que casi todo el mundo se topa primero.

Cómo trata nuestro PIM una actualización parcial

Antes de la respuesta, una distinción que merece la pena hacer, porque "perder el historial" son en realidad dos preocupaciones distintas con el mismo abrigo.

Los datos. Una actualización parcial que borra en silencio lo que no mencionaba. Es la que cuesta dinero, y depende por completo de cómo lea tu herramienta el archivo.

El rastro. Quién cambió esto, cuándo y qué decía antes.

El segundo se siente como una pérdida y casi siempre es una ganancia. No porque las hojas de cálculo no tengan historial: las modernas suelen saber decirte que una celda cambió, cuándo y qué decía. Es que su historial va del archivo. Describe ediciones de un documento, en lugar de llevar un registro por producto que reúna en el mismo sitio las ediciones a mano, las importaciones, los feeds de proveedor y los canales conectados.

La primera preocupación se resuelve con una herramienta que se niegue a adivinar.

En la nuestra, las columnas que mapeaste son todo el contrato. Una columna que no mapeaste no se lee, diga lo que diga su cabecera, y vaciar un valor es un modo aparte que eliges a propósito en lugar de algo que te hace una celda en blanco por accidente.

Así que una actualización parcial puede añadir y puede cambiar. Lo que no puede es borrar en silencio.

Es una sola frase, y es la frase que deberías poder sacarle a cualquier proveedor de tu lista.

Qué pasa con tu historial de cambios

Cada cambio en un producto, una marca, una categoría, una etiqueta o una especificación se guarda como una versión, y una importación se guarda igual que una edición hecha a mano.

Así que el registro empieza en el momento en que llega tu catálogo. La primera entrada es la llegada.

Cada versión registra quién causó el cambio y cómo llegó al catálogo: una persona editando directamente, una persona ejecutando una importación, un feed de proveedor con nombre, un canal conectado con nombre, o el propio sistema actuando solo.

En esa distinción está todo el valor. Una importación que corrió de madrugada no es el mismo hecho que alguien editando un título en su escritorio, y un registro que no sabe distinguirlos acabará diciéndote algo falso.

Las ediciones hechas en una ráfaga corta se juntan en una sola versión, a nombre de quien escribió el último y con la cuenta de cuántos cambios cubrió. Eso es lo que mantiene legible un catálogo movido, y es un intercambio real: el registro responde a "quién tocó esto por última vez", no a "quién lo tocó a las 14:32".

Los productos, las marcas, las categorías, las etiquetas y las especificaciones llevan versiones así.

Qué se puede restaurar y qué no

Abres un producto, miras su historial, pones dos versiones lado a lado y ves qué campos cambiaron. Si la antigua era la buena, la restauras. Ver el historial requiere permiso de lectura y restaurar requiere permiso de edición, que son dos permisos distintos a propósito.

Restaurar te devuelve donde estabas, salvo donde el mundo se haya movido mientras tanto. Un nombre que desde entonces ocupó otro. Un código de barras que ahora usa otro producto. Una jerarquía de categorías que ya no tiene la misma forma.

Una restauración no se detiene por nada de eso. Aplica todo lo que puede y te entrega la lista de lo que se saltó, que es justo el comportamiento que quieres al final de una tarde mala.

Cuánto dura. El historial se guarda treinta días por elemento, con un tope de doscientas versiones cada uno. Caduque lo que caduque, la versión más reciente de cada elemento vivo se queda siempre. Esa última avanza cada vez que editas, así que es una foto de dónde está el producto ahora y no un sitio al que volver; existe para que ningún elemento se quede sin ninguna versión guardada.

Así que conviene ser preciso sobre qué protege esto. Protege lo que hagas de ahora en adelante, dentro de una ventana de treinta días.

Cambias algo hoy, descubres la semana que viene que estaba mal, y el estado anterior está ahí esperando. Si la versión que quieres es de hace cuatro meses, ya no está. No adelgazada: no está. No se guarda nada en su lugar, así que el registro ni puede devolverte ahí ni puede decirte que aquel cambio ocurrió.

Que es un argumento para mirar dentro de la ventana y no después, y una migración es justo el tipo de trabajo donde eso importa.

Tres cosas que no es, dichas sin rodeos:

No es un registro de auditoría para cumplimiento normativo. Responde a "cómo era este producto y quién lo cambió" para la gente que lleva el catálogo. Si necesitas retención inmutable para un auditor, pregúntanos antes de darlo por supuesto.

No hay un botón para deshacer una importación entera. La restauración funciona de un elemento en uno. Si una importación que actualizó dos mil productos sale mal, el registro te dice qué cambió y te deja devolver cualquiera de ellos, pero no revierte el trabajo de un clic. Y si la importación creó productos que no querías, la restauración es directamente la herramienta equivocada: un producto que acaba de nacer no tiene estado anterior, así que esos hay que quitarlos aparte.

Una eliminación queda registrada, y no es un camino de vuelta. El historial te dice que algo se eliminó y quién lo hizo, y esa entrada no es un punto de restauración. Es además el único sitio sin suelo permanente: en cuanto un elemento se elimina, todo su historial caduca a los treinta días.

Cómo probar la migración sin riesgo

Empieza eligiendo el archivo maestro. No el más reciente ni el más completo, sino aquel en el que tu equipo trabaja de verdad todos los días, porque es el que lleva pegadas las costumbres de tu catálogo.

Después importa de ahí una muestra pequeña pero deliberadamente variada. Unas pocas docenas de productos que sean de verdad distintos entre sí. Uno con variantes. Uno con una descripción larga, llena del formato que tu archivo antiguo haya ido acumulando. Uno con atributos que solo aplican a un par de categorías.

Ábrelos después y léelos como los leería un cliente.

Lo que buscas son los desacuerdos pequeños. Una medida que perdió su unidad. Una descripción que llegó con marcas raras pegadas. Un producto sin marca, porque esa marca todavía no existía y le habías dicho a la importación que siguiera en lugar de parar.

Resuelve eso antes de la importación de verdad, en el archivo de origen o como una transformación repetible, para que producción no sea el primer sitio donde se hace la limpieza.

Cargar suele ser la parte rápida. El tiempo se va en decidir qué significan de verdad tus atributos, que es la pregunta que la hoja de cálculo lleva tiempo dejándote esquivar.

Qué se queda en la hoja de cálculo

Los comentarios, los colores de las celdas y el historial de versiones del propio archivo no suelen trasladarse en una importación de catálogo. Describen el archivo de trabajo, no el modelo de producto.

Casi todos los consejos te dicen que mantengas los dos sistemas en paralelo una semana o dos. Tener el nuevo en marcha junto al viejo, para contrastarlo contra algo en lo que confías, tiene sentido y merece el tiempo. Lo que evitaríamos es que los dos sigan siendo editables.

Dos catálogos editables es exactamente el problema del que vienes, reintroducido con tu permiso. Alguien va a editar el equivocado y nada te lo va a decir.

Pasa una familia de productos cada vez. Cuando una familia se haya mudado, deja de editar esas filas en la hoja de cálculo y deja que el sistema nuevo sea su única casa de trabajo.

Guarda el archivo, eso sí. No como copia de trabajo ni como sitio donde la gente sigue editando, sino archivado donde puedas abrirlo. Resuelve la única pregunta que el sistema nuevo no puede contestar, que es qué decía el viejo.

Preguntas frecuentes

Hay dos preguntas que merece la pena hacerle a cada proveedor de tu lista, nosotros incluidos. ¿Qué pasa con una columna que no mapeé? ¿Y qué me vas a poder contar de este producto dentro de cuatro semanas?

Esas dos son justo alrededor de las que está construido nuestro PIM para este trabajo, y por eso lo de arriba se puede escribir en lugar de prometer.

Y merece la pena decir cómo se ve el otro lado, porque responde a la pregunta con la que abría esta página. Las hojas de cálculo vuelven a ser lo que se les da bien, que es mover datos de aquí para allá. El catálogo tiene una sola casa de trabajo. Y nadie tiene que ser la persona que sabe cuál es el archivo bueno, porque la respuesta dejó de vivir en la cabeza de alguien.