Cómo implantar un software PRL/SST: fases, responsables y criterios para empezar a utilizarlo
Por Pablo Rodríguez
La implantación de un software PRL/SST empieza cuando la empresa acuerda cómo quiere trabajar. Configurar pantallas es una parte del proyecto. También hay que asignar responsabilidades, revisar datos, preparar usuarios y decidir qué debe funcionar antes de iniciar la operación.
Un plan útil conecta cada fase con un entregable y una persona que lo acepta. La ficha de digitalización de la PRL sitúa este cambio dentro de la gestión preventiva. El calendario debe ajustarse al alcance y a los recursos disponibles; no existe un plazo universal que garantice una buena implantación.
Diagnóstico: elegir un problema que merezca resolverse
Reúne ejemplos del trabajo actual: una evaluación, una medida, una inspección y un informe. Sigue su recorrido entre personas y aplicaciones. Identifica dónde aparecen esperas, duplicaciones o falta de criterio. Diferencia una limitación de herramienta de una decisión organizativa que todavía no está tomada.
Define el alcance inicial con procesos, centros, perfiles e idiomas. Escribe también qué queda para fases posteriores. Un proyecto que comienza con planificación y medidas necesita criterios distintos de otro centrado en contratistas. El responsable de Prevención valida el contenido; el patrocinador confirma prioridades y capacidad del equipo.
Diseño y configuración: acordar antes de copiar
Dibuja los pasos del proceso elegido e identifica quién prepara, decide, ejecuta y comprueba. Define estados que tengan un significado compartido. Si una actividad figura como cerrada, todos deberían entender qué evidencia y revisión sustentan ese estado.
A continuación, configura estructura, permisos, catálogos y comunicaciones dentro del alcance contratado. Aprovecha el proyecto para retirar campos sin uso y duplicaciones. La ficha de gestión del cambio en SST ayuda a considerar los efectos de modificar responsabilidades o procedimientos, además del cambio tecnológico.
Datos e integraciones: preparar una base confiable
Asigna propietarios a los datos de personas, centros y actividades. Acuerda cuál será su fuente de referencia y cómo se corregirán discrepancias. No automatices un intercambio antes de entender qué información necesita cada proceso y con qué frecuencia debe actualizarse.
La migración requiere un trabajo específico de inventario, correspondencias y validación. Nuestro artículo sobre migración de históricos y evidencias desarrolla esas tareas. En el plan general, reserva un hito para aceptarlas y un procedimiento para gestionar cambios posteriores a la carga inicial.
Piloto: probar trabajo completo, incluidas excepciones
Selecciona un centro o equipo representativo y utiliza casos que recorran todo el proceso. Incluye una actividad normal, un vencimiento, una reasignación y una evidencia que necesita corrección. Un piloto solo con registros perfectos puede ocultar problemas que aparecerán el primer día de uso.
- Prevención comprueba la lógica técnica del proceso y sus registros.
- Los usuarios ejecutan tareas sin depender continuamente del implantador.
- TI verifica accesos, intercambios de datos y recuperación conforme al alcance acordado.
- El responsable del proyecto registra incidencias, decisiones y pruebas pendientes.
- La dirección o patrocinador confirma la preparación de recursos y responsables.
Distingue errores que impiden operar de mejoras que pueden programarse. Para cada incidencia, conserva prioridad, responsable y condición de resolución. No conviertas una lista de deseos abierta en un bloqueo permanente del proyecto.
Formación y arranque: preparar a cada perfil
La formación debe reproducir tareas habituales. Un mando necesita saber actuar sobre una medida; un administrador necesita gestionar estructura y permisos. Pide que cada participante complete un ejercicio y deja una referencia breve de ayuda con el canal al que acudir.
Antes del arranque, comprueba datos, usuarios, soporte, comunicaciones y reglas de transición. Documenta quién autoriza empezar y qué condiciones se han cumplido. Después, revisa los primeros ciclos de trabajo: tareas completadas, incidencias repetidas y dudas que requieren ajustar configuración o instrucciones.
Un proyecto termina cuando el trabajo se sostiene
Un ejemplo ilustrativo: si el objetivo era seguir medidas preventivas, la aceptación debe incluir creación, asignación, ejecución y revisión con usuarios reales del proceso. Tener cuentas creadas no acredita ese resultado. La ficha de indicadores de SST ayuda a definir qué información observar después del despliegue.
Relaciona el plan con el RFP y los criterios de demostración para mantener los compromisos de compra. Al valorar el software PRL de Sabentis, solicita un alcance de implantación con entregables, responsables y aceptación: la puesta en marcha será más fácil de gobernar.
Lista práctica para decidir el arranque del software
Utiliza esta comprobación en la reunión de puesta en marcha. Cada respuesta debería remitir a una prueba o una decisión registrada, con una persona que pueda explicar su resultado.
- Comprueba que una incidencia crítica tiene una definición acordada y que ninguna permanece abierta sin una decisión expresa.
- Solicita a un usuario de cada perfil completar una tarea habitual con su propia cuenta y sin instrucciones del implantador.
- Confirma quién atenderá el primer vencimiento, cambio de responsable y error de carga que aparezcan después del arranque.
- Ensaya el canal de soporte con una consulta ficticia para verificar recepción, clasificación y persona encargada de responder.
- Agenda una revisión tras el primer ciclo de trabajo y fija qué datos permitirán decidir si ampliar el despliegue.
Preguntas frecuentes sobre la implantación de software PRL/SST
¿Qué diferencia hay entre una demo y un piloto?
La demo ayuda a evaluar una propuesta antes de contratar o concretar su alcance. El piloto comprueba la configuración y el procedimiento previstos para tu operación con usuarios representativos. Sus incidencias deben quedar registradas y resueltas según criterios de aceptación, no solo comentadas durante una presentación.
¿Puede arrancarse con incidencias pendientes?
Depende de su efecto sobre la operación, la protección de datos y los procesos preventivos. Distingue los bloqueos de las mejoras aplazables. Cualquier aceptación condicionada debe identificar la limitación, una alternativa operativa adecuada, el responsable y la fecha de resolución; no basta con anotar «pendiente».
¿La formación en el software sustituye la formación preventiva?
No. Aprender a registrar una medida o consultar un expediente no equivale a adquirir los conocimientos preventivos necesarios para una tarea. Planifica ambos aprendizajes según las responsabilidades del perfil y comprueba su aplicación, manteniendo las exigencias de formación que correspondan en España o Colombia.
¿Quién debería aceptar la implantación?
La aceptación debe reunir la conformidad de las personas responsables de los procesos incluidos, de los datos y de la operación tecnológica. El patrocinador autoriza el arranque con esas evidencias. El proveedor aporta resultados y resuelve incidencias, pero no debería aceptar unilateralmente el trabajo en nombre de la empresa.
Normativa y fuentes consultadas
- Ley 31/1995 de Prevención de Riesgos Laborales: España, artículos 16 y 19: integración de la prevención y formación preventiva; el proyecto tecnológico no sustituye esas obligaciones.
- Colombia: Decreto 1072 de 2015: Colombia, capítulo 2.2.4.6: responsabilidades, capacitación y gestión del sistema. El calendario tecnológico debe convivir con el funcionamiento del SG-SST.
Fuentes consultadas el 6 de octubre de 2026. Las listas y ejemplos son propuestas prácticas de aplicación.
