Pliego de requisitos para software de RRHH

Un pliego debe producir respuestas comparables

Copiar cien funciones crea documentos largos y propuestas difíciles de evaluar. Un pliego útil describe decisiones, escenarios, volúmenes, roles y resultados esperados. El proveedor puede entonces explicar cómo responde, qué necesita configurar y qué queda fuera. La empresa obtiene evidencia en lugar de una sucesión de «sí».

Los criterios se ordenan por prioridad: imprescindible para contratar, necesario durante la siguiente fase y deseable. Cada requisito indica actor, entrada, excepción, salida y evidencia de aceptación. Se añaden implantación, seguridad, integraciones, soporte, coste completo y reversibilidad. La marca no recibe puntos por promesas no demostradas.

Escenario: selección para una empresa logística

Una compañía con 600 personas, 22 centros y alta rotación sustituye varias hojas y un portal antiguo. Necesita expediente, documentos, vacaciones y onboarding; mantiene nómina y fichaje. Empleados de almacén comparten dispositivos, managers administran solo su centro y RRHH requiere informes consolidados.

El pliego declara esas condiciones y ofrece datos de volumen: altas mensuales, documentos, usuarios administradores, calendarios e integraciones. En vez de pedir «gestión de onboarding», plantea una incorporación de almacén con documentación, formación obligatoria, cuenta de acceso y comunicación a sistemas externos. Así aparecen permisos, dependencia móvil y tareas de varios equipos.

Prueba y matriz de evidencia

Tres candidatos reciben dos semanas para responder una matriz común. Las opciones válidas son `Nativo`, `Configurable`, `Integración`, `Desarrollo`, `No incluido` y `Pendiente de verificar`. Cada respuesta enlaza documentación, indica módulo y señala responsable de implantación. Los cinco flujos críticos se demuestran con datos anonimizados.

Durante la sesión, la empresa introduce un cambio no anunciado: una persona se traslada de centro después de iniciar el onboarding. Se comprueba cómo se actualizan permisos, tareas y reportes. La aceptación considera resultado, trazabilidad y esfuerzo, sin convertir la demostración en una nota pública ni afirmar que ya se ha probado un producto determinado.

Caso límite: requisito que solo cubre un desarrollo

Un candidato responde afirmativamente a una integración, pero aclara después que requiere desarrollo a medida. Esto no lo excluye automáticamente. Hay que conocer propietario del código, API, plazo, coste, pruebas, mantenimiento y alternativa si cambia una versión. La casilla deja de ser equivalente a un conector estándar.

El pliego debe permitir esta respuesta sin esconderla. Si la integración es imprescindible, el desarrollo forma parte del alcance y de la prueba de aceptación. Si es secundaria, puede posponerse. Tratar todas las vías como un simple «sí» favorece propuestas ambiguas y traslada el riesgo al comprador.

Conclusión: adjudicar por escenarios resueltos

El documento final debería ser breve para leer y suficientemente preciso para decidir. Una tabla de requisitos acompaña pocos escenarios completos, arquitectura actual, condiciones de servicio y reglas comerciales. Las preguntas abiertas quedan visibles hasta recibir evidencia.

La mejor propuesta no es la que marca más casillas, sino la que resuelve los procesos prioritarios dentro del esfuerzo asumible y explica sus límites. Si dos proveedores responden a alcances diferentes, primero se normalizan módulos y servicios. Solo después tiene sentido comparar implantación y coste.

Así se evita adjudicar por ambigüedad comercial.