Lista de comprobación RFP para proveedores de software

Un RFP de desarrollo de software debe fijar el problema, los requisitos funcionales y no funcionales, las necesidades de seguridad y de datos, las condiciones comerciales y el método de puntuación antes de que un proveedor responda. Puntúe los criterios ponderados en lugar de discutir después, compruebe las referencias en lugar de creerse los casos de éxito y haga un piloto pagado corto antes de firmar algo que comprometa presupuesto.

¿Qué debe contener un RFP de software?

El documento existe para que las respuestas sean comparables. Un proveedor solo puede responder a lo que está escrito; un RFP que describe una visión y pide un precio invita a propuestas que todas suenan excelentes y ninguna de las cuales puede evaluarse con las demás. El contenido funcional, las restricciones y la regla de puntuación tienen que fijarse antes de que llegue la primera respuesta, o la evaluación se convierte en una negociación sobre criterios.

Hay además un punto de secuencia que ahorra meses: el RFP no es donde usted descubre lo que necesita. Los requisitos salen del trabajo interno: los responsables del proceso describiendo cómo funciona de verdad el negocio, finanzas diciendo lo que debe conciliar, la gente que va a usar el sistema a diario diciendo dónde duele hoy. Ese trabajo es lento y político, y ocurre antes de que aparezca ningún proveedor. Los equipos que lo externalizan en el primer proveedor que llega acaban con requisitos escritos en el lenguaje del producto de ese proveedor, y eso hace que todas las demás propuestas parezcan un encaje pobre, no porque lo sean, sino porque el patrón de referencia se redactó en torno a uno de los licitantes.

Una distinción más que conviene mantener, entre tres documentos que suelen confundirse. Un RFI pregunta al mercado qué existe; es corto, precede a los requisitos y no compromete a nadie. Un RFP pide una propuesta contra requisitos definidos y un método de evaluación declarado. Un RFQ pide un precio contra un alcance definido. Hacer un RFQ antes de que exista el alcance es la manera más común de comparar tres cifras que significan tres cosas distintas.

Cinco cosas que hace un RFP completo y que un RFP incompleto no hace:

• Define el problema, no la solución. «Reducir el tiempo de elaboración del informe consolidado mensual de días a un número definido de horas» es un enunciado de problema; «constrúyanos un almacén de datos» es una suposición de solución que quizá no lo resuelva.


• Separa los requisitos de las preferencias. Imprescindibles que deciden el paso, muy deseables que deciden el rango y deseables que no deciden nada. Los proveedores responden en serio solo cuando esa distinción está a la vista.


• Nombra las restricciones. Sistemas existentes que hay que integrar, datos que hay que migrar, obligaciones de auditoría y de conservación, ventana de puesta en marcha y quién aprueba.


• Declara de antemano el método de evaluación. Criterios ponderados, quién evalúa, qué evidencia se exige y cuándo los proveedores no seleccionados reciben un resumen de sus puntuaciones.


• Fija las fechas del proceso. Fecha límite de preguntas, ventana de aclaraciones, fecha límite de entrega, periodo de evaluación y fecha de decisión. Un proceso sin fechas atrae a proveedores que ya están ocupados.

Estructura del RFP

Requisitos funcionales y no funcionales

Los requisitos funcionales describen lo que hace el sistema: qué procesos, para qué roles y con qué salidas. Los no funcionales describen cuán bien los hace, y son los que más a menudo faltan; después se exigen, a un precio alto, o no se exigen en absoluto.

Vale la pena declararlos de forma explícita en la mayoría de los proyectos B2B:

• Rendimiento. Tiempos de respuesta bajo una carga declarada, para las operaciones que importan: entrada de pedidos, generación de informes y cierre de mes.


• Disponibilidad. Qué disponibilidad necesita el negocio, ventanas de mantenimiento y qué ocurre cuando el sistema está caído: un objetivo sin descripción del tiempo de caída aceptable no es un requisito.


• Recuperación. RTO y RPO en lenguaje llano: con qué rapidez se reanuda la operación después de un incidente y cuánto trabajo puede perderse. Las dos cifras pertenecen a la evaluación y no solo al contrato.


• Registro de auditoría. Quién cambió qué y cuándo, cuánto tiempo se conserva y quién puede recuperarlo; especialmente donde se mueven dinero, existencias o datos personales.


• Accesibilidad y usabilidad. Quién usa el sistema, en qué dispositivos y en qué idiomas: un sistema que el almacén no puede operar no está implantado, por muy bien que puntúe.


• Integración y datos. Qué sistemas se conectan, en qué dirección fluye el dato y quién es dueño del registro maestro de cada entidad.

Preguntas de seguridad y cumplimiento: ISO 27001 y OWASP

La seguridad se pregunta mejor como cuestiones con evidencia exigida que como una línea de sí o no. Las que merece la pena incluir:

• ISO/IEC 27001 — ¿lo tiene el proveedor y qué cubre el alcance certificado? Un certificado que cubre a la organización comercial pero no a los equipos de entrega dice algo muy concreto.


• Desarrollo seguro — dónde se sitúa la seguridad en el diseño, la revisión de código y las pruebas, y si la gestión de dependencias y vulnerabilidades es rutinaria.


• OWASP Top 10 — si forma parte de la revisión del proveedor para los componentes expuestos a internet; una pregunta concreta y contestable.


• Control de acceso — quién puede alcanzar sus entornos y sus datos, cómo se concede y se retira el acceso y qué registros de auditoría existen.


• Deberes de protección de datos — KVKK y GDPR donde correspondan; quién es responsable, quién encargado y qué dice el acuerdo de encargo de tratamiento sobre subencargados y notificación de brechas.

Condiciones comerciales y SLA

Pida los precios en una estructura que pueda comparar: qué incluye, qué se cobra aparte y cómo se precio los cambios. Una cifra sola, sin alcance detrás, no puede compararse con otra cifra sola; la página de modelos de coste y precios explica las estructuras habituales y las preguntas que cada una plantea.

Los SLA merecen la misma precisión que los requisitos. Un porcentaje de disponibilidad solo es significativo con su método de medición, sus exclusiones y su remedio; un tiempo de respuesta solo es significativo con sus definiciones de severidad y su horario de atención. Pida a cada proveedor que defina los términos dentro del SLA, y no acepte una página de porcentajes sin definiciones.

Matriz de puntuación de la evaluación

Una plantilla copiable. Los pesos de abajo son un ejemplo: ajústelos a sus prioridades y mantenga el total en 100. Defina qué significan 1, 3 y 5 antes de que alguien puntúe, y no después de que empiecen los argumentos.

Dos disciplinas hacen que esto funcione. Puntúe de forma independiente antes de discutir, para que la primera voz segura no fije el tono de la sala. Y anote una línea de justificación por puntuación: los proveedores que reciben un resumen con motivos aceptan el resultado con mucha más facilidad, y su propio equipo puede defenderlo seis meses después.

Una tercera disciplina se refiere a quién puntúa. El tribunal debe incluir a la gente que va a convivir con el resultado: el responsable del proceso, la persona responsable de los datos, alguien de seguridad o de finanzas si esas funciones existen, y no solo compras. Las evaluaciones fracasan en silencio cuando el tribunal puntúa lo que puede juzgar —la estructura de la propuesta, el pulido del equipo comercial— y aplaza lo que no puede: si el enfoque de integración encaja de verdad con los sistemas actuales. Una persona técnica con autoridad para decir «esto no va a funcionar con lo que nosotros usamos» evita más costes que cualquier descuento.

Las ponderaciones mismas merecen una advertencia más: son una declaración de prioridades que se hace visible para los proveedores. Si la seguridad pesa un 5 % y el precio un 30 %, los proveedores serios con mentalidad de seguridad lo notarán, y también su propio equipo cuando se firme el contrato. Una ponderación puesta de prisa, para rellenar la tabla, se lee como la verdad por todos los que están fuera de la sala; fíjela una sola vez, con los decisores presentes, y cámbiela solo con la misma formalidad con la que la fijó.

Comprobación de referencias y piloto

Los casos de éxito son marketing; las comprobaciones de referencias son evidencia. La llamada que funciona es corta y pregunta por lo que pasó, no por lo que se entregó: ¿se terminó el proyecto?, ¿qué cambió en el alcance?, ¿quién estuvo de verdad en el equipo?, ¿qué harían distinto?, ¿y volverían a empezar el proyecto con este proveedor? Tiempo pasado y respuestas concretas son la señal.

Pida una referencia de un proyecto que se parezca al suyo en tamaño y complejidad, y no la obra de la que el proveedor más se enorgullece: una implantación insignia del doble de su presupuesto le enseña poco sobre cómo se comporta el equipo a su escala. Y compruebe usted mismo la referencia: un contacto que el proveedor prepara de antemano es un testimonio, no una referencia; la llamada útil es aquella en la que el cliente se entera en el momento de lo que usted está preguntando.

Un piloto pagado breve prueba después la parte que ninguna referencia puede probar: cómo trabaja este equipo con su gente cuando los requisitos están incompletos. Las reglas de diseño son las mismas que conviene fijar para cualquier piloto: trabajo real, criterios de aceptación por escrito, un cambio a mitad de camino y una regla de decisión acordada de antemano. La página de externalización trata el diseño de pilotos con más detalle.

Cláusulas contractuales a revisar

• Cesión de propiedad intelectual — derechos sobre código, documentación y derivados que se transfieren a usted desde la creación y no solo en el pago final.
• Titularidad de los datos — sus datos siguen siendo suyos; los derechos del proveedor se limitan a lo necesario para prestar el servicio.
• Aceptación — qué significa la aceptación, quién la declara y el proceso cuando algo no la supera.
• Control de cambios — cómo se piden, se precio y se aprueban los cambios de alcance; sin él, cada cambio se convierte en una disputa.
• Salida y transición — código fuente, accesos, documentación y asistencia al final, y cómo se transfiere el conocimiento si el proveedor cambia.
• Depósito de código (escrow) — donde la continuidad del negocio depende de componentes en manos del proveedor, qué ocurre si el proveedor no puede continuar.
• Responsabilidad — límites, exclusiones y lo que no está cubierto; léala con la misma atención que el precio.
• Terminación — plazos de preaviso, obligaciones después de la terminación y el proceso de devolución o eliminación de datos.

Preguntas frecuentes

¿Debemos enviar primero un RFI o un RFP?

Un RFI cuando el mercado o el problema no están claros: usted pregunta qué existe y cuánto cuesta. Un RFP cuando los requisitos y el método de evaluación están definidos; enviarlo antes solo traslada el trabajo de requisitos a cada propuesta de proveedor, con sus palabras y sus prioridades.

¿A cuántos proveedores debemos invitar?

Pocos enough...

¿Cómo se fijan las ponderaciones?

A partir de sus prioridades, antes de ver ninguna propuesta, y acordadas entre las personas que van a convivir con el resultado. Un fallo habitual es dar el mismo peso a todo, que es una manera de decir que nada importa más que nada; si para usted el precio o el riesgo domina, las ponderaciones deben decirlo.

¿Debe puntuarse el precio?

Sí, pero como un criterio ponderado más, con su alcance fijo, y no como toda la evaluación. Un precio puntuado sin alcance detrás premia al proveedor que asumió menos trabajo; precio primero sus requisitos y después compare totales por lo mismo.

¿Cómo puntúo las respuestas de seguridad?

Por evidencia y no por tono. Tres niveles funcionan: sin posición (1), políticas descritas (3) y alcance del certificado verificado, más desarrollo seguro descrito y evidencia aportada (5). Cuando un proveedor no tiene certificado, pregunte qué controles equivalentes existen por escrito: un «no» honesto con controles documentados puntúa mejor que un «sí» que no puede verificarse.

¿Podemos cambiar requisitos después del RFP?

Antes de las entregas, sí, con el cambio anunciado a todos. Después de las entregas, solo mediante una aclaración formal que reciban todos los licitantes; cambiar requisitos en silencio para un solo proveedor acaba con la comparabilidad en la que se sostiene todo el proceso. Después del contrato, para eso está el control de cambios.

Fuentes y estándares

• ISO — entidad publicadora de ISO/IEC 27001 (gestión de la seguridad de la información); confirme la edición vigente y el alcance de un certificado antes de apoyarse en él.
• OWASP — entidad publicadora de la lista de los 10 riesgos principales de seguridad de aplicaciones web citada en esta página.
• Los principios de la matriz de puntuación siguen la práctica publicada de plantillas de RFP; los pesos mostrados son un ejemplo para editar, no una recomendación. Esta página es orientación de compras, no asesoramiento jurídico, y no se afirma ninguna certificación ni auditoría para WorldwideTradeX.

Páginas relacionadas

Desarrollo de software · Externalización de TI desde Türkiye · Modelos de coste y precios · Auditoría y consultoría de TI · Solicitar presupuesto