Com implantar un programari PRL/SST: fases, responsables i criteris per començar a utilitzar-lo

La implantació d’un programari PRL/SST comença quan l’empresa acorda com vol treballar. Configurar pantalles és una part del projecte. També cal assignar responsabilitats, revisar dades, preparar usuaris i decidir què ha de funcionar abans d’iniciar l’operació.
Un pla útil connecta cada fase amb un lliurable i una persona que l’accepta. La fitxa de digitalització de la PRL situa aquest canvi dins de la gestió preventiva. El calendari ha d’ajustar-se a l’abast i als recursos disponibles; no existeix un termini universal que garanteixi una bona implantació.
Diagnòstic: triar un problema que mereixi resoldre’s
Reuneix exemples del treball actual: una avaluació, una mesura, una inspecció i un informe. Segueix el seu recorregut entre persones i aplicacions. Identifica on apareixen esperes, duplicacions o falta de criteri. Diferència una limitació d’eina d’una decisió organitzativa que encara no està presa.
Defineix l’abast inicial amb processos, centres, perfils i idiomes. Escriu també què queda per a fases posteriors. Un projecte que comença amb planificació i mesures necessita criteris distints d’un altre centrat en contractistes. El responsable de Prevenció valida el contingut; el patrocinador confirma prioritats i capacitat de l’equip.
Disseny i configuració: acordar abans de copiar
Dibuixa els passos del procés triat i identifica qui prepara, decideix, executa i comprova. Defineix estats que tinguin un significat compartit. Si una activitat figura com a tancada, tots haurien d’entendre quina evidència i revisió sustenten aquest estat.
A continuació, configura estructura, permisos, catàlegs i comunicacions dins de l’abast contractat. Aprofita el projecte per a retirar camps sense ús i duplicacions. La fitxa de gestió del canvi en SST ajuda a considerar els efectes de modificar responsabilitats o procediments, a més del canvi tecnològic.
Dades i integracions: preparar una base de confiança
Assigna propietaris a les dades de persones, centres i activitats. Acorda quina serà la seva font de referència i com es corregiran discrepàncies. No automatitzis un intercanvi abans d’entendre quina informació necessita cada procés i amb quina freqüència ha d’actualitzar-se.
La migració requereix un treball específic d’inventari, correspondències i validació. El nostre article sobre migració d’històrics i evidències desenvolupa aquestes tasques. En el pla general, reserva una fita per a acceptar-les i un procediment per a gestionar canvis posteriors a la càrrega inicial.
Pilot: provar treball complet, incloses excepcions
Selecciona un centre o equip representatiu i utilitza casos que recorrin tot el procés. Inclou una activitat normal, un venciment, una reassignació i una evidència que necessita correcció. Un pilot només amb registres perfectes pot ocultar problemes que apareixeran el primer dia d’ús.
- Prevenció comprova la lògica tècnica del procés i els seus registres.
- Els usuaris executen tasques sense dependre contínuament de l’implantador.
- TI verifica accessos, intercanvis de dades i recuperació conforme a l’abast acordat.
- El responsable del projecte registra incidències, decisions i proves pendents.
- La direcció o patrocinador confirma la preparació de recursos i responsables.
Distingeix errors que impedeixen operar de millores que poden programar-se. Per a cada incidència, conserva prioritat, responsable i condició de resolució. No converteixis una llista de desitjos oberta en un bloqueig permanent del projecte.
Formació i arrencada: preparar a cada perfil
La formació ha de reproduir tasques habituals. Un comandament necessita saber actuar sobre una mesura; un administrador necessita gestionar estructura i permisos. Demana que cada participant completi un exercici i deixa una referència breu d’ajuda amb el canal al qual acudir.
Abans de l’arrencada, comprova dades, usuaris, suport, comunicacions i regles de transició. Documenta qui autoritza començar i quines condicions s’han complert. Després, revisa els primers cicles de treball: tasques completades, incidències repetides i dubtes que requereixen ajustar configuració o instruccions.
Un projecte acaba quan el treball se sosté
Un exemple il·lustratiu: si l’objectiu era seguir mesures preventives, l’acceptació ha d’incloure creació, assignació, execució i revisió amb usuaris reals del procés. Tenir comptes creats no acredita aquest resultat. La fitxa de indicadors de SST ajuda a definir quina informació observar després del desplegament.
Relaciona el pla amb el RFP i els criteris de demostració per a mantenir els compromisos de compra. En valorar el programari PRL de Sabentis, sol·licita un abast d’implantació amb lliurables, responsables i acceptació: la posada en marxa serà més fàcil de governar.
Llista pràctica per a decidir l’arrencada del programari
Utilitza aquesta comprovació en la reunió de posada en marxa. Cada resposta hauria de remetre a una prova o una decisió registrada, amb una persona que pugui explicar el seu resultat.
- Comprova que una incidència crítica té una definició acordada i que cap roman oberta sense una decisió expressa.
- Sol·licita a un usuari de cada perfil completar una tasca habitual amb el seu propi compte i sense instruccions de l’implantador.
- Confirma qui atendrà el primer venciment, canvi de responsable i error de càrrega que apareguin després de l’arrencada.
- Assaja el canal de suport amb una consulta fictícia per a verificar recepció, classificació i persona encarregada de respondre.
- Agenda una revisió després del primer cicle de treball i fixa quines dades permetran decidir si ampliar el desplegament.
Preguntes freqüents sobre la implantació de programari PRL/SST
Quina diferència hi ha entre una demo i un pilot?
La demo ajuda a avaluar una proposta abans de contractar o concretar el seu abast. El pilot comprova la configuració i el procediment previstos per a la teva operació amb usuaris representatius. Les seves incidències han de quedar registrades i resoltes segons criteris d’acceptació, no sols comentades durant una presentació.
Pot arrencar-se amb incidències pendents?
Depèn del seu efecte sobre l’operació, la protecció de dades i els processos preventius. Distingeix els bloquejos de les millores ajornables. Qualsevol acceptació condicionada ha d’identificar la limitació, una alternativa operativa adequada, el responsable i la data de resolució; no n’hi ha prou amb anotar «pendent».
La formació en el programari substitueix la formació preventiva?
No. Aprendre a registrar una mesura o consultar un expedient no equival a adquirir els coneixements preventius necessaris per a una tasca. Planifica tots dos aprenentatges segons les responsabilitats del perfil i comprova la seva aplicació, mantenint les exigències de formació que corresponguin a Espanya o Colòmbia.
Qui hauria d’acceptar la implantació?
L’acceptació ha de reunir la conformitat de les persones responsables dels processos inclosos, de les dades i de l’operació tecnològica. El patrocinador autoritza l’arrencada amb aquestes evidències. El proveïdor aporta resultats i resol incidències, però no hauria d’acceptar unilateralment el treball en nom de l’empresa.
Normativa i fonts consultades
- Llei 31/1995 de Prevenció de Riscos Laborals: Espanya, articles 16 i 19: integració de la prevenció i formació preventiva; el projecte tecnològic no substitueix aquestes obligacions.
- Colòmbia: Decret 1072 de 2015: Colòmbia, capítol 2.2.4.6: responsabilitats, capacitació i gestió del sistema. El calendari tecnològic ha de conviure amb el funcionament del SG-SST.
Fonts consultades el 6 d’octubre de 2026. Les llistes i exemples són propostes pràctiques d’aplicació.



