Cómo participo en un proceso de selección de PIM: mi rol, mis criterios y mis preguntas al vendor

Elegir una plataforma PIM no es solo una decisión técnica ni únicamente comercial. En este artículo, comparto cómo participo en procesos reales de evaluación: qué observo en una demo, qué preguntas hago a los vendors y qué señales me permiten detectar si una plataforma realmente va a funcionar en operación cotidiana.

Hay algo que me pasa bastante seguido en procesos de selección de plataformas PIM: la conversación empieza hablando de funcionalidades… y termina hablando de personas.

Porque sí, claro, una plataforma puede tener APIs robustas, dashboards impecables, workflows avanzados y una demo visualmente perfecta. Pero después aparece la pregunta incómoda:

¿Quién va a trabajar todos los días dentro de esto?

Y ahí cambia completamente la conversación.

Con el tiempo entendí que mi rol dentro de una evaluación PIM no es el mismo que el del área técnica, ni el del vendor, ni el del decisor financiero. Yo observo otra cosa. Veo  lo que pasa después de la firma. Lo que sucede cuando el proyecto entra en operación y alguien tiene que sostener el catálogo todos los días.

Porque un proyecto PIM no fracasa solamente por problemas técnicos. Muchas veces fracasa porque el equipo nunca logra adoptar realmente la herramienta.

Y eso pocas veces aparece en una demo comercial de una hora.

El error más frecuente: evaluar un PIM solo por lo que promete

En muchos procesos de selección aparece una fascinación inicial bastante comprensible. Las plataformas muestran sus mejores escenarios posibles: todo se ve rápido, limpio, ordenado y automatizado, pero una demo no representa la realidad operativa de un catálogo.

La realidad incluye datos incompletos, atributos inconsistentes, proveedores que entregan archivos caóticos, taxonomías mal diseñadas, workflows que cambian sobre la marcha, variantes complejas, publicaciones urgentes e integraciones que no sincronizan correctamente.

Ahí es donde realmente aparece el valor —o las limitaciones— de una plataforma, por eso, cuando participo en una evaluación, intento mover la conversación desde:

¿Qué puede hacer el sistema?

↓

 ¿Cómo se comporta este sistema cuando entra el catálogo real?

Porque no es lo mismo.

Lo primero que necesito validar: cómo se siente trabajar dentro del sistema

Antes de hablar de conectores, APIs o arquitectura, hay algo mucho más básico que necesito entender:

¿Cómo se siente trabajar ahí adentro?

Puede parecer una pregunta menor, pero no lo es.

Un PIM es una herramienta de uso intensivo. Los equipos pasan horas:

• enriqueciendo productos,
• validando atributos,
• corrigiendo inconsistencias,
• gestionando assets,
• organizando variantes,
• revisando publicaciones,
• exportando datos,
• manteniendo criterios de normalización.

Si la experiencia de uso es lenta, confusa o excesivamente técnica, el desgaste aparece muy rápido. Y cuando aparece el desgaste, suele pasar algo todavía peor: la gente empieza a trabajar “por afuera” del sistema.

Vuelven los Excels paralelos.
Los documentos compartidos.
Las correcciones manuales.
Los procesos temporales que terminan convirtiéndose en permanentes.

Ahí el proyecto empieza a perder consistencia operativa. Por eso presto muchísima atención a cuestiones como:

• cuántos clics requiere una tarea simple,
• qué tan intuitiva es la navegación,
• cómo se visualizan los atributos,
• si los errores son comprensibles,
• cómo responde el sistema con catálogos grandes,
• qué tan clara es la gestión de variantes,
• cómo se sienten los flujos de enriquecimiento.

Hay plataformas extremadamente potentes que operativamente resultan agotadoras. Y hay otras más simples que permiten trabajar muchísimo mejor. La diferencia importa más de lo que muchas veces se admite en una evaluación.

El criterio que más me interesa: qué tan bien resiste el caos real

Hay una frase que repito bastante en proyectos:

“Cualquier sistema funciona bien con datos perfectos.”

El problema es que los datos perfectos casi nunca existen.

Por eso, durante una evaluación, intento entender cómo responde la plataforma frente al desorden real:

• imports incompletos,
• atributos faltantes,
• productos mal clasificados,
• estructuras heredadas,
• taxonomías cambiantes,
• vocabularios inconsistentes,
• múltiples canales con reglas distintas.

Ahí aparecen las preguntas verdaderamente importantes.

¿La plataforma ayuda a ordenar el caos… o simplemente lo almacena?

Porque no es lo mismo.

En proyectos reales, gran parte del trabajo operativo consiste justamente en construir consistencia:

• normalizar información,
• sostener vocabularios controlados,
• evitar duplicados,
• definir criterios claros,
• mantener coherencia semántica entre equipos y canales.

Y eso depende muchísimo de cómo está pensado el modelo de datos y de la flexibilidad real de la plataforma para gobernar información de producto.

Las preguntas que siempre termino haciéndole al vendor

Con el tiempo fui armando una especie de lista mental de preguntas incómodas.

No porque quiera “poner a prueba” al vendor, sino porque ciertas respuestas revelan rápidamente la madurez real de una plataforma.

¿Qué limitaciones aparecen cuando el catálogo crece?

Todos muestran demos con pocos productos.

Yo necesito entender qué pasa cuando aparecen:

• 100.000 SKUs,
• miles de assets,
• cientos de familias,
• múltiples canales,
• workflows simultáneos,
• equipos trabajando en paralelo.

La escalabilidad no se mide en marketing. Se mide en operación cotidiana.

¿Qué parte del workflow suele necesitar personalización?

Cuando una plataforma responde: “No hace falta customizar nada”, desconfío un poco.

Todos los proyectos reales tienen particularidades. Prefiero vendors que expliquen honestamente:

• qué resuelven muy bien,
• qué requiere adaptación,
• dónde suelen aparecer límites,
• y qué tipo de soporte operativo termina siendo necesario.

¿Cómo manejan los errores de integración?

Esta pregunta parece puramente técnica, pero tiene muchísimo impacto operativo.

Porque cuando una integración falla, alguien tiene que detectar:

• qué producto falló,
• por qué,
• en qué momento,
• y cómo corregirlo.

Los proyectos más sanos son los que tienen trazabilidad clara y mecanismos de validación comprensibles incluso para perfiles no técnicos.

¿Cómo gestionan variantes complejas?

Hasta que un catálogo entra en matrices reales, las variantes parecen sencillas. Después aparecen talles, colores, packs, configurables, bundles, relaciones padre-hijo, compatibilidades técnicas.

Y ahí muchas implementaciones empiezan a sufrir.

El modelo de variantes suele revelar rápidamente qué tan flexible es realmente una plataforma PIM.

¿Qué tareas terminan resolviendo los clientes fuera del sistema?

Esta pregunta me encanta porque rompe bastante el discurso comercial. Y además revela muchísimo.

Si muchos clientes terminan exportando constantemente a Excel para resolver tareas operativas básicas, probablemente exista una fricción importante dentro del producto.

Y eso es información valiosa antes de tomar una decisión.

Las señales que me generan dudas durante una evaluación

Hay ciertos patrones que aprendí a detectar bastante rápido. No significan automáticamente que una plataforma sea mala. Pero sí me obligan a profundizar mucho más.

Cuando todo depende del equipo de desarrollo

Si tareas operativas simples requieren constantemente soporte técnico, el proyecto puede volverse muy difícil de sostener para los equipos de negocio.

Cuando la demo evita mostrar procesos completos

A veces se muestran interfaces muy lindas… pero nunca workflows reales.

Yo necesito ver:

• imports,
• validaciones,
• edición masiva,
• correcciones,
• publicaciones,
• manejo de errores,
• gobernanza,
• procesos de revisión.

Ahí vive el trabajo cotidiano.

Cuando el modelo de datos parece demasiado rígido

Los catálogos evolucionan constantemente.

Nuevos atributos.
Nuevos canales.
Nuevas líneas de producto.
Nuevos requerimientos regulatorios.
Nuevas necesidades del negocio.

Si modificar estructuras básicas parece excesivamente complejo, probablemente el costo operativo futuro sea alto.

Cuando la UX parece pensada solo para especialistas

Un proyecto PIM rara vez involucra únicamente perfiles técnicos.

Participan:

• marketing,
• catálogo,
• eCommerce,
• contenido,
• producto,
• operaciones,
• comercial,
• proveedores.

Si el sistema intimida a la mitad del equipo, la adopción se vuelve mucho más difícil.

Lo más importante que aprendí participando en selecciones PIM

Probablemente esto:

No existe “el mejor PIM”.

Existe el PIM correcto para:

• ese catálogo,
• ese nivel de madurez,
• esa complejidad operativa,
• ese ecosistema tecnológico,
• y ese equipo específico.

Vi plataformas simples funcionar increíblemente bien porque estaban alineadas con las necesidades reales del negocio.

Y también vi implementaciones enormes fracasar porque la elección se hizo pensando únicamente en funcionalidades enterprise.

La plataforma correcta no siempre es la más potente.

Muchas veces es la que logra el mejor equilibrio entre:

• flexibilidad,
• usabilidad,
• gobernanza,
• integración,
• mantenimiento,
• y adopción operativa.

La pregunta importante no es solamente qué puede hacer una plataforma, sino cómo se comporta cuando entra el catálogo real: datos incompletos, variantes complejas, múltiples canales y procesos imperfectos.

Y hay una última pregunta que casi nunca aparece en las demos, pero que para mí debería estar al principio de cualquier proceso de selección:

“¿Cómo va a cambiar el trabajo cotidiano de las personas que sostienen el catálogo?”

Porque implementar un PIM no significa solamente ordenar datos. Significa cambiar procesos, responsabilidades y formas de trabajo. Significa redefinir cómo una organización construye, mantiene y distribuye información de producto.

Y si esa parte no se contempla desde el principio, incluso la plataforma más potente puede terminar convirtiéndose en otro sistema más que nadie quiere usar.

Para nosotros, en CRITERIA, participar en evaluaciones PIM implica justamente eso: entender no solo qué tecnología necesita el negocio, sino qué estructura operativa puede sostener realmente en el tiempo.