RFP técnica para una implementación PIM: las preguntas que el vendor no quiere responder
Las malas decisiones en un proyecto PIM rara vez se explican por lo que el vendor mostró en demo. Casi siempre aparecen en lo que nadie preguntó con suficiente precisión técnica. Por eso una RFP bien hecha no debería confirmar que la plataforma “puede”, sino revelar cómo lo hace, con qué límites y con qué costo real de implementación y operación.
Cuando una empresa entra en proceso de selección de un PIM, suele encontrarse con demos prolijas, matrices de funcionalidades, promesas de integración rápida y bastante discurso sobre escalabilidad. El problema es que muchas decisiones equivocadas no nacen de una mentira explícita, sino de una omisión. No fallan por lo que el vendor dijo, sino por lo que nadie lo obligó a explicar en serio.
Y en un proyecto PIM eso se paga caro. Se paga en retrabajo, en integraciones frágiles, en sobrecostos, en dependencias mayores de las previstas y en una arquitectura que parecía razonable hasta que empezó a convivir con la operación real.
Desde mi lado, trabajando en integraciones entre PIM, ERP, eCommerce, DAM, marketplaces y otros sistemas, hay una idea que se volvió bastante clara con el tiempo: una RFP técnica no sirve para validar que una plataforma tiene capacidades en abstracto. Sirve para entender cómo se comportan esas capacidades cuando se las lleva al terreno concreto del negocio.
Casi todas las plataformas enterprise o mid-market van a responder que tienen APIs, webhooks, conectores, workflows o extensibilidad. Lo que importa de verdad es otra cosa: si esas capacidades están maduras, si son consistentes, si están bien documentadas y si resisten el tipo de arquitectura que tu empresa realmente necesita sostener.
La primera pregunta no es si tiene API, sino qué integración soporta de verdad
Esta es, probablemente, una de las trampas más comunes en cualquier proceso de evaluación. Casi cualquier vendor serio va a decir que tiene API. Pero “tener API” no explica casi nada.
Una plataforma puede ofrecer REST y, aun así, no comportarse bien con grandes volúmenes. Puede tener GraphQL, pero no contar con una capa madura de eventos. Puede ofrecer webhooks con restricciones por versión, por tipo de producto o por edición. Incluso puede tener API pública y, al mismo tiempo, recomendar otro mecanismo para ciertos escenarios críticos.
Por eso, la pregunta útil no es si existe una API. La pregunta útil es qué capa de integración recomiendan para cada caso, qué límites reconocen y qué parte del problema no aconsejan resolver por API aunque técnicamente sea posible.
Ese matiz cambia todo. Porque una cosa es mostrar conectividad como feature comercial, y otra muy distinta es explicar con criterio técnico cuál es la vía correcta para una arquitectura real.
Si el vendor responde “sí, tenemos API” y eso cierra la conversación, la RFP ya arrancó mal. La pregunta útil no es si existe. La pregunta útil es para qué casos la recomiendan, para cuáles no, y qué límites reconocen sin maquillaje.
El modelo de datos revela más que cualquier demo bien armada
Hay otra zona donde muchas evaluaciones se quedan en la superficie: el modelado. En demo, casi todas las plataformas parecen resolver bien categorías, atributos, familias, variantes y canales. El problema aparece cuando el negocio sale del caso estándar y empieza a exigir estructuras menos cómodas.
Ahí es donde la RFP tiene que tensar de verdad el producto. Conviene preguntar cómo resuelve la plataforma familias, herencia, variantes, entidades de referencia, relaciones complejas, taxonomías múltiples, atributos localizables, atributos por canal y estructuras no lineales. Pero no en abstracto. Hay que pedir que lo expliquen con ejemplos que se parezcan al catálogo real de la empresa.
Esto importa porque el modelo de datos no es un detalle técnico secundario. Es una de las decisiones más estructurales de cualquier implementación PIM. Si una plataforma necesita demasiadas excepciones, plugins o desarrollo adicional para representar el tipo de producto que maneja el negocio, esa limitación va a aparecer tarde o temprano, aunque la demo haya sido impecable.
En proyectos reales esto se ve con bastante claridad. Cuando la arquitectura de salida incluye múltiples canales, mercados, sistemas o formatos, el modelo deja de ser una definición interna y pasa a condicionar directamente la calidad de las integraciones posteriores.
Paginación, límites y concurrencia: lo que define el techo real de una integración
Una plataforma que se presenta como integrable debería poder responder con claridad cómo pagina, qué límites aplica y qué pasa cuando se supera la capacidad esperada. Y sin embargo, muchas veces estas preguntas aparecen demasiado tarde, cuando ya se está diseñando o implementando.
Desde mi lado, esta es una de las validaciones más importantes. No porque sea una discusión operativa menor, sino porque ahí aparece el techo real de una integración.
Conviene preguntar cómo se pagina, cuál es el límite máximo por request, si existe un mecanismo robusto de cursoring o search-after, qué límites de concurrencia existen por conexión o por instancia, cómo se notifica el throttling, qué estrategia de backoff recomiendan y cómo sugieren resolver importaciones o exportaciones masivas.
Una integración puede verse razonable en desarrollo con un catálogo pequeño. La conversación cambia bastante cuando aparecen cientos de miles de productos, varios canales y sincronizaciones delta repetidas a lo largo del día. En ese punto, los límites dejan de ser detalles de documentación y se transforman en una parte central del diseño.
Webhooks y eventos: no alcanza con que existan
Otra zona donde los vendors suelen responder con bastante optimismo es la de eventos, webhooks y automatización. Muchas plataformas ya traen algo de eso. El problema no es la existencia, sino la madurez.
Para una RFP técnica, la pregunta no debería ser solo si tienen webhooks. La pregunta debería ser qué garantizan, cómo fallan, qué visibilidad ofrecen y cuánto trabajo extra va a tener que absorber tu equipo cuando algo no llegue como debería.
Ahí conviene bajar mucho más al detalle. Qué eventos existen de forma nativa, cuáles no, si son transaccionales o eventualmente consistentes, qué sistema de reintentos aplica la plataforma, cómo se firma o valida el webhook, si existe replay, si hay trazabilidad histórica de entregas fallidas y si el vendor recomienda usar ese mecanismo en producción o prefiere otra estrategia para ciertos flujos.
“Tenemos webhooks” no es una respuesta técnica. Es apenas el comienzo. Lo importante es saber qué garantizan, cómo fallan, qué observabilidad ofrecen y cuánto trabajo extra va a tener que absorber tu equipo cuando algo no llegue.
En muchas arquitecturas, la diferencia entre una integración robusta y una frágil no está en la presencia de eventos, sino en la calidad con la que ese mecanismo está resuelto y documentado.
La documentación y el manejo de versiones hablan del vendor antes de firmar
Hay una validación que para mí vale muchísimo porque es muy simple y muy honesta: leer la documentación oficial como si el proyecto ya hubiera empezado. Ahí aparecen enseguida señales que la venta no muestra.
Cuando una plataforma publica cambios por release, diferencia documentación por versión, aclara breaking changes, define políticas de soporte y ofrece entornos claros para prueba, está mostrando una disciplina técnica que importa tanto como cualquier feature.
Por eso, en una RFP, preguntaría algo muy concreto: cómo gestionan releases, dónde publican cambios, cómo comunican breaking changes, qué política de soporte por versión manejan y si existe un sandbox real para probar integraciones antes de tocar producción.
La calidad de la documentación y del release management no es un “plus”. En proyectos PIM, forma parte de la capacidad de integración de la plataforma. Una herramienta mal documentada o con cambios poco gobernados puede convertir una arquitectura razonable en una fuente permanente de incertidumbre.
El vendor debería explicar cómo se monitorea una integración, no solo cómo se construye
Hay una obsesión bastante comprensible en selección de software: cómo se implementa. Pero a veces se habla muy poco de cómo se opera después. Y eso, para mí, es un error serio.
Yo quiero saber si la plataforma ofrece logs útiles, dashboards, trazabilidad de ejecuciones, feedback loops, notificaciones de falla, auditoría de cambios y visibilidad sobre qué se publicó, qué no y por qué. Porque una integración no fracasa únicamente cuando no se puede construir. También fracasa cuando no se puede operar con claridad.
Este punto suele aparecer recién después de la implementación, cuando la integración ya existe pero nadie puede seguirla con suficiente precisión. Entonces empiezan las zonas grises: no se sabe qué falló, dónde se cortó el flujo, qué dato quedó afuera o por qué un destino recibió información diferente.
Una RFP técnica bien hecha debería anticipar eso. No para pedir una perfección imposible, sino para entender cuánta observabilidad trae la plataforma y cuánta observabilidad vas a tener que construir vos.
Hay que separar lo que resuelve el producto de lo que termina viviendo en código
Esta es otra pregunta que cambia por completo la evaluación. Porque muchas veces el vendor muestra una capacidad como si fuera estándar, cuando en realidad depende de servicios profesionales, módulos pagos, partner o desarrollo a medida.
Por eso conviene pedir una separación muy clara: qué parte del requerimiento se resuelve con configuración estándar, qué parte con módulo oficial, qué parte con partner y qué parte con desarrollo propio.
Cuando eso no queda claro, la implementación parece más simple y más barata de lo que realmente va a ser. Recién después aparecen las dependencias, los desarrollos adicionales y el costo real de sostener la solución en el tiempo.
Una de las preguntas más incómodas para el vendor es también una de las más útiles para el comprador: qué parte de lo prometido vive en producto y qué parte va a terminar viviendo en código, partner o servicios adicionales.
Para mí, esa frontera debería estar explicitada desde el principio. No como una aclaración menor, sino como parte del núcleo de la evaluación.
La arquitectura del negocio importa más que el cuadrante del vendor
También hay una pregunta que muchas empresas hacen demasiado poco: en qué arquitectura concreta encaja mejor la plataforma. No en abstracto, ni en una benchmark genérica, ni en el terreno cómodo del brochure comercial. En la arquitectura real del negocio.
Si la empresa va a convivir con ERP, eCommerce, CMS, marketplace, middleware, catálogo impreso, POS, DAM o múltiples fuentes de proveedor, la evaluación tiene que hacerse contra ese mapa. No existe el mejor PIM en abstracto. Existe el PIM que mejor conversa con la arquitectura específica que la organización necesita sostener.
Eso obliga al vendor a salir del demo estándar y entrar en una conversación bastante más útil: cómo recomiendan integrarse con ese stack, qué patrones sugieren, qué límites reconocen y qué parte del trabajo va a recaer sobre el equipo interno o sobre terceros.
Ahí es donde una RFP técnica deja de ser un checklist y empieza a convertirse en una herramienta real de decisión.
¿Qué preguntas no deberían faltar nunca en una RFP técnica de PIM?
Yo no armaría una RFP como un cuestionario infinito. La armaría como una batería breve de validaciones capaces de obligar al vendor a bajar de la promesa al diseño real.
Preguntaría cómo se modelan variantes, relaciones complejas y taxonomías múltiples. Cómo pagina la API y qué límites aplica. Qué estrategia recomiendan para eventos, webhooks, bulk operations y sincronizaciones delta. Qué política de versiones y de breaking changes manejan. Qué observabilidad trae el producto y cuál habrá que construir. Qué parte del alcance vive en configuración y cuál en desarrollo. Cómo recomiendan integrar con la arquitectura real del negocio y no con un caso genérico de demo. Y, sobre todo, qué escenarios oficialmente no recomiendan resolver con su propia plataforma aunque técnicamente sean posibles.
Esa última pregunta me parece especialmente valiosa. Porque cuando un vendor puede decir con claridad para qué no usar cierta API, cierta capa o cierto módulo, normalmente está mostrando madurez. Cuando responde que todo se puede hacer de todas las formas, yo desconfío.
Antes de elegir un PIM, no hace falta pedirle al vendor que convenza más. Hace falta pedirle que incomode mejor. Porque las plataformas no muestran sus límites en la demo; los muestran cuando una RFP técnica las obliga a hablar de paginación, eventos, versionado, observabilidad, arquitectura y costo real de integración. Ahí recién empieza la conversación que de verdad importa.
