Cómo hacer un RFI/RFP que no termine eligiendo al mejor vendedor

Trabajé el proceso de RFI/RFP y benchmark de mercado para seleccionar el nuevo Terminal Operating System (TOS) de Ultramar, junto a gerencia y directorio — uno de los casos que detallamos en la sección de trayectoria de este sitio. La decisión no se tomó comparando hojas de especificaciones de proveedores entre sí; se construyó evaluando cada opción contra la realidad operativa específica de los puertos chilenos y los objetivos que esos puertos tenían a futuro. Esa diferencia — comparar contra tu realidad, no entre proveedores — es la que casi siempre se pierde en un RFP mal diseñado.

El problema típico de un RFI/RFP es que se arma como una lista de funcionalidades deseables, y gana quien marca más casilleros. Eso premia al proveedor con el mejor equipo de propuestas, no necesariamente al sistema que mejor resuelve tu operación. Esto es lo que cambia cuando el proceso se diseña al revés: desde tu realidad hacia las opciones, no desde las opciones hacia una lista genérica de features.

Primero, documentar la operación real antes de escribir un solo requisito. Antes de preguntarle a un proveedor qué puede hacer su sistema, hay que tener claro exactamente cómo opera hoy el negocio — volúmenes reales, excepciones frecuentes, los casos borde que el sistema actual maneja mal. Un RFP escrito sin ese trabajo previo termina pidiendo funcionalidades estándar de la industria, no las que tu operación específica necesita.

Segundo, separar los objetivos de hoy de los de los próximos cinco años. Un sistema que resuelve la operación actual pero no tiene camino de crecimiento hacia donde va el negocio es una migración que vas a tener que repetir antes de lo planeado. Esto exige que quienes definen el RFP hayan conversado con gerencia y directorio sobre hacia dónde va la operación, no solo con el equipo que la opera hoy.

Tercero, pedir evidencia verificable, no capacidades declaradas. Cualquier proveedor puede escribir en una propuesta que su sistema "soporta alta disponibilidad" o "escala horizontalmente". Pide referencias verificables de una operación de tamaño y complejidad similar a la tuya, y habla directamente con esos referentes — no solo con los que el proveedor te ofrece como caso de éxito.

Cuarto, construir el benchmark con los mismos criterios para todos, definidos antes de recibir la primera propuesta. Si los criterios de evaluación se ajustan después de ver las propuestas — aunque sea de forma involuntaria, para favorecer al candidato que ya generó mejor impresión — el proceso deja de ser una comparación objetiva y se convierte en una racionalización de una decisión ya tomada.

Un RFI/RFP bien diseñado toma más tiempo al principio que simplemente pedir tres cotizaciones y comparar precios. Pero la decisión que sostiene — con evidencia, no con la mejor presentación — es la que se puede defender ante un directorio cuando alguien pregunta, un año después, por qué se eligió ese sistema y no otro.