RFP per a contractar programari PRL/SST: requisits, ponderació i guió de demostració
Per Pablo Rodríguez
Un RFP, o sol·licitud de proposta, serveix perquè diversos proveïdors responguin a la mateixa necessitat. En programari PRL/SST, el seu valor està a convertir expressions com a «gestió integral» o «fàcil d’usar» en proves concretes. El document pot ser breu si permet entendre l’abast, comparar respostes i decidir amb evidències.
Abans de redactar-ho, acorda quins processos entren en la compra. La fitxa de programari PRL/SST ofereix una referència d’abast; el RFP ha de baixar aquest marc al funcionament de la teva empresa. Involucra a Prevenció, usuaris operatius, TI i Compres des del principi.
Descriu primer el problema de treball
Explica la situació actual sense convertir-la en una llista de marques o preferències tècniques. Per exemple: les mesures es reben en informes, es reparteixen per correu i no existeix una visió compartida de la seva execució. Descriu després el resultat esperat: cada mesura ha de tenir responsable, termini, evidència i revisió de tancament.
Afegeix dimensions de l’operació: societats, seus, perfils, idiomes i fonts de dades. Distingeix necessitats actuals d’escenaris futurs. Si un creixement és possible però encara no està aprovat, demana una opció econòmica separada i evita tractar-ho com a abast inicial obligatori.
Redacta requisits que admetin una prova
Cada requisit pot tenir un identificador, procés, prioritat, descripció, prova i responsable de valoració. No n’hi ha prou amb contestar «sí». Sol·licita indicar si la resposta està disponible, requereix configuració, necessita desenvolupament o queda fora de l’oferta. Demana descriure dependències i condicions en el mateix punt.
- Requisit operatiu: assignar una mesura a un responsable i verificar el seu tancament amb evidència.
- Prova: crear-la, canviar el seu termini amb motiu i comprovar quin historial queda disponible.
- Requisit d’accés: limitar la consulta als centres autoritzats per a cada perfil.
- Prova: intentar consultar un expedient d’un altre centre amb un usuari de demostració.
- Requisit de sortida: recuperar dades i documents inclosos en el contracte.
- Prova: revisar una exportació de mostra i la seva explicació de camps.
La fitxa de evidència digital en PRL ajuda a concretar què necessites conservar. Aquests exemples són proposades d’avaluació, no funcionalitats atribuïdes a una solució concreta.
Separa condicions essencials de criteris puntuables
Un requisit imprescindible ha d’actuar com a condició d’acceptació. No convé compensar una restricció d’accés inadequada amb una interfície atractiva. Defineix prèviament com tractaràs una resposta parcial i quina evidència permetrà resoldre-la. Mantingues el mateix criteri per a tots els participants.
Per als aspectes puntuables, utilitza categories com a adequació funcional, facilitat de treball, implantació, integració, suport i cost total. Assigna pesos segons la prioritat de la teva organització i publica internament la lògica abans de veure ofertes. No existeix una ponderació universal vàlida per a totes les empreses.
Registra per separat la puntuació i la seva justificació. Una impressió favorable durant la presentació no equival a una tasca completada per un usuari. Quan dues opcions s’acostin, revisa les evidències que sustenten la diferència en lloc d’afegir decimals sense significat.
Utilitza un guió de demostració comuna
Lliurament un cas fictici amb un centre, diversos llocs i una mesura pendent. Demana recórrer-ho des de l’entrada de la dada fins a l’informe final, incloent-hi un canvi de responsable i una excepció. Reserva temps perquè una persona del teu equip completi part del recorregut.
Afegeix una prova de connexió amb les dades d’RR. HH. si forma part de l’abast. La fitxa de integració amb ERP i RR. HH. permet preparar preguntes sobre origen, actualitzacions i errors. No usis informació personal real per a una demostració comercial.
Tanca la comparació amb compromisos clars
El resultat del RFP ha de recollir abast inclòs, exclusions, fites, lliurables i dubtes resolts. Vincula cada compromís rellevant a un document contractual o de projecte. Conserva la versió dels requisits amb la qual es va adjudicar per a evitar que l’abast canviï sense una decisió expressa.
Completa l’avaluació amb la guia de cost total del programari i el pla d’implantació. Si estàs valorant el programari PRL de Sabentis, utilitza el RFP per a sol·licitar una demostració centrada en els teus processos i una proposta que permeti verificar els acords.
Llista pràctica per a tancar el RFP abans d’enviar-ho
Revisa el document des de la perspectiva de qui ha de respondre i de qui haurà d’acceptar la solució. Les preguntes ambigües solen produir ofertes que després no es poden comparar.
- Elimina requisits duplicats i assigna un identificador estable per a seguir cada resposta fins a la seva prova d’acceptació.
- Demana que les funcions previstes per al futur es distingeixin de les disponibles en la versió que es contractaria.
- Defineix com es tractarà una excepció a un requisit obligatori i qui pot autoritzar-la abans de puntuar l’oferta.
- Inclou un procediment comú per a distribuir aclariments a tots els proveïdors que participin en la comparació.
- Comprova que l’annex econòmic utilitza els mateixos centres, perfils, volums i lliurables que el guió funcional.
Preguntes freqüents sobre el RFP de programari PRL/SST
Un RFP intern equival a un plec de contractació pública?
No. Una sol·licitud de propostes d’una empresa pot organitzar una comparació comercial, però no substitueix els documents ni els procediments exigibles a una contractació pública. Si l’organització està subjecta a aquestes regles, els responsables de contractació han d’adaptar l’expedient i els seus criteris.
Com valorar una funció promesa per a una versió futura?
Registra-la com a compromís pendent, amb data, abast i condició d’acceptació. No la puntuïs com una funció disponible si encara no pot demostrar-se. Quan sigui imprescindible per a l’arrencada, la decisió de contractació ha de resoldre expressament aquesta dependència i les conseqüències d’un retard.
Quants requisits hauria de contenir el document?
Els necessaris per a decidir amb evidència, sense convertir cada preferència visual en una condició de compra. Prioritza processos complets i excepcions rellevants. Un requisit hauria de justificar una necessitat i una prova; si ningú sap com verificar-lo ni quina decisió canvia, convé reformular-lo o retirar-lo.
Què demanar sobre dades personals en la proposta?
Sol·licita descriure les dades tractades, els rols de les parts, els accessos, la subcontractació i la sortida del servei. Quan s’apliqui el RGPD, concreta l’encàrrec conforme a l’article 28. L’avaluació contractual ha de correspondre a l’operació real, no sols a un document estàndard.
Normativa i fonts consultades
- NIST SP 800-146: Síntesi i recomanacions sobre la computació al núvol: guia tècnica de NIST per a valorar oportunitats, riscos i condicions dels serveis en el núvol; referència metodològica, no normativa espanyola o colombiana.
- Unió Europea: Reglament General de Protecció de Dades: article 28: garanties i condicions quan un proveïdor tracta dades per compte d’un responsable dins de l’àmbit del reglament.
Fonts consultades el 6 d’octubre de 2026. Les llistes i exemples són propostes pràctiques d’aplicació.
