RFP para contratar software PRL/SST: requisitos, ponderación y guion de demostración

Por Pablo Rodríguez

Un RFP, o solicitud de propuesta, sirve para que varios proveedores respondan a la misma necesidad. En software PRL/SST, su valor está en convertir expresiones como «gestión integral» o «fácil de usar» en pruebas concretas. El documento puede ser breve si permite entender el alcance, comparar respuestas y decidir con evidencias.

Antes de redactarlo, acuerda qué procesos entran en la compra. La ficha de software PRL/SST ofrece una referencia de alcance; el RFP debe bajar ese marco al funcionamiento de tu empresa. Involucra a Prevención, usuarios operativos, TI y Compras desde el principio.

Describe primero el problema de trabajo

Explica la situación actual sin convertirla en una lista de marcas o preferencias técnicas. Por ejemplo: las medidas se reciben en informes, se reparten por correo y no existe una visión compartida de su ejecución. Describe después el resultado esperado: cada medida debe tener responsable, plazo, evidencia y revisión de cierre.

Añade dimensiones de la operación: sociedades, sedes, perfiles, idiomas y fuentes de datos. Distingue necesidades actuales de escenarios futuros. Si un crecimiento es posible pero todavía no está aprobado, pide una opción económica separada y evita tratarlo como alcance inicial obligatorio.

Redacta requisitos que admitan una prueba

Cada requisito puede tener un identificador, proceso, prioridad, descripción, prueba y responsable de valoración. No basta con contestar «sí». Solicita indicar si la respuesta está disponible, requiere configuración, necesita desarrollo o queda fuera de la oferta. Pide describir dependencias y condiciones en el mismo punto.

• Requisito operativo: asignar una medida a un responsable y verificar su cierre con evidencia.
• Prueba: crearla, cambiar su plazo con motivo y comprobar qué historial queda disponible.
• Requisito de acceso: limitar la consulta a los centros autorizados para cada perfil.
• Prueba: intentar consultar un expediente de otro centro con un usuario de demostración.
• Requisito de salida: recuperar datos y documentos incluidos en el contrato.
• Prueba: revisar una exportación de muestra y su explicación de campos.

La ficha de evidencia digital en PRL ayuda a concretar qué necesitas conservar. Estos ejemplos son propuestas de evaluación, no funcionalidades atribuidas a una solución concreta.

Separa condiciones esenciales de criterios puntuables

Un requisito imprescindible debe actuar como condición de aceptación. No conviene compensar una restricción de acceso inadecuada con una interfaz atractiva. Define previamente cómo tratarás una respuesta parcial y qué evidencia permitirá resolverla. Mantén el mismo criterio para todos los participantes.

Para los aspectos puntuables, utiliza categorías como adecuación funcional, facilidad de trabajo, implantación, integración, soporte y coste total. Asigna pesos según la prioridad de tu organización y publica internamente la lógica antes de ver ofertas. No existe una ponderación universal válida para todas las empresas.

Registra por separado la puntuación y su justificación. Una impresión favorable durante la presentación no equivale a una tarea completada por un usuario. Cuando dos opciones se acerquen, revisa las evidencias que sustentan la diferencia en lugar de añadir decimales sin significado.

Utiliza un guion de demostración común

Entrega un caso ficticio con un centro, varios puestos y una medida pendiente. Pide recorrerlo desde la entrada del dato hasta el informe final, incluyendo un cambio de responsable y una excepción. Reserva tiempo para que una persona de tu equipo complete parte del recorrido.

Añade una prueba de conexión con los datos de RR. HH. si forma parte del alcance. La ficha de integración con ERP y RR. HH. permite preparar preguntas sobre origen, actualizaciones y errores. No uses información personal real para una demostración comercial.

Cierra la comparación con compromisos claros

El resultado del RFP debe recoger alcance incluido, exclusiones, hitos, entregables y dudas resueltas. Vincula cada compromiso relevante a un documento contractual o de proyecto. Conserva la versión de los requisitos con la que se adjudicó para evitar que el alcance cambie sin una decisión expresa.

Completa la evaluación con la guía de coste total del software y el plan de implantación. Si estás valorando el software PRL de Sabentis, utiliza el RFP para solicitar una demostración centrada en tus procesos y una propuesta que permita verificar lo acordado.

Lista práctica para cerrar el RFP antes de enviarlo

Revisa el documento desde la perspectiva de quien debe responder y de quien tendrá que aceptar la solución. Las preguntas ambiguas suelen producir ofertas que después no se pueden comparar.

• Elimina requisitos duplicados y asigna un identificador estable para seguir cada respuesta hasta su prueba de aceptación.
• Pide que las funciones previstas para el futuro se distingan de las disponibles en la versión que se contrataría.
• Define cómo se tratará una excepción a un requisito obligatorio y quién puede autorizarla antes de puntuar la oferta.
• Incluye un procedimiento común para distribuir aclaraciones a todos los proveedores que participen en la comparación.
• Comprueba que el anexo económico utiliza los mismos centros, perfiles, volúmenes y entregables que el guion funcional.

Preguntas frecuentes sobre el RFP de software PRL/SST

¿Un RFP interno equivale a un pliego de contratación pública?

No. Una solicitud de propuestas de una empresa puede organizar una comparación comercial, pero no sustituye los documentos ni los procedimientos exigibles a una contratación pública. Si la organización está sujeta a esas reglas, los responsables de contratación deben adaptar el expediente y sus criterios.

¿Cómo valorar una función prometida para una versión futura?

Regístrala como compromiso pendiente, con fecha, alcance y condición de aceptación. No la puntúes como una función disponible si todavía no puede demostrarse. Cuando sea imprescindible para el arranque, la decisión de contratación debe resolver expresamente esa dependencia y las consecuencias de un retraso.

¿Cuántos requisitos debería contener el documento?

Los necesarios para decidir con evidencia, sin convertir cada preferencia visual en una condición de compra. Prioriza procesos completos y excepciones relevantes. Un requisito debería justificar una necesidad y una prueba; si nadie sabe cómo verificarlo ni qué decisión cambia, conviene reformularlo o retirarlo.

¿Qué pedir sobre datos personales en la propuesta?

Solicita describir los datos tratados, los roles de las partes, los accesos, la subcontratación y la salida del servicio. Cuando se aplique el RGPD, concreta el encargo conforme al artículo 28. La evaluación contractual debe corresponder a la operación real, no solo a un documento estándar.

Normativa y fuentes consultadas

• NIST SP 800-146: Cloud Computing Synopsis and Recommendations: guía técnica de NIST para valorar oportunidades, riesgos y condiciones de los servicios en la nube; referencia metodológica, no normativa española o colombiana.
• Unión Europea: Reglamento General de Protección de Datos: artículo 28: garantías y condiciones cuando un proveedor trata datos por cuenta de un responsable dentro del ámbito del reglamento.

Fuentes consultadas el 6 de octubre de 2026. Las listas y ejemplos son propuestas prácticas de aplicación.