Aplicaciones para la gestión de la Seguridad y Salud ¿cual es la mejor? (II)

El tiempo estimado de lectura es de 3 minutos

Siguiendo el hilo de nuestro anterior post, en esta aportación ofreceremos los criterios que, a nuestro entender, deben evaluar los directivos que pretendan implantar una aplicación para la gestión de la seguridad y salud en su organización.

En primer lugar debemos plantear la siguiente pregunta: ¿qué necesidad pretendo cubrir con esta aplicación?

  • La generación de un registro sencillo que permita una mejor visualización de los contenidos a transmitir podrá ser resuelta con una herramienta ofimática estándar (Word, Excel o Power Point).
  • Si pretendemos gestionar un aspecto concreto de la gestión preventiva (evaluaciones higiénicas, coordinación de actividades empresariales, auditorías, etc) precisaremos una aplicación específica concreta.
  • En cambio, si nuestro objetivo es definir un marco desde el cual poder manejar el ciclo completo de la gestión preventiva y que además se integre transversalmente con otros sistemas de la organización deberemos optar por una aplicación específica generalista o incluso por un desarrollo “Ad hoc” de un ERP existente.

Es segundo lugar debemos evaluar el alcance de la implantación de la herramienta.

  • Una solución local se aplicará a una actividad concreta, un centro de trabajo o incluso un número limitado de técnicos de seguridad y salud.
  • Una solución multi empresa y multi usuarios podrá dar respuesta a la necesidad de gestionar varios centros de trabajo o varias empresas del mismo grupo, con la posibilidad que múltiples usuarios puedan trabajar a la vez incluso en varios idiomas.

En tercer lugar es fundamental ser realista con los recursos de los que disponemos para implementar nuestra herramienta de gestión.

  • El tiempo de implantación directamente proporcional a la complejidad de la solución adoptada. Una solución específica concreta pueda ejecutarse en pocos días mientras que una aplicación generalista precisará alguna semana y un desarrollo “Ad hoc” seguramente varios meses.
  • En la misma línea definimos la inversión económica necesaria para la puesta en marcha del software. Las implantaciones más costosas son las que implican desarrollos específicos de ERP de gestión.

Además de lo anterior es conveniente tener en consideración otros elementos funcionales de la aplicación y de los desarrolladores / implantadores de la misma.

  • El entorno de comunicación entre la aplicación y el usuario (interfaz) debe ser claro, ágil e intuitivo. Este punto es especialmente crítico si pretendemos que nuestra aplicación se “abra” a usuarios No técnicos del área de seguridad y salud.
  • Si la política de seguridad informática de nuestra organización lo permite, es valorable el acceso a la aplicación en una modalidad de “software as a service”. Amén de ser la tendencia predominante en estos momentos, simplifica los procesos de actualización, soporte y resolución de incidencias.
  • Es importante tener presente la capacidad de del software para crecer y adaptarse a los cambios normativos o técnicos de nuestro entorno.
  • Por ello, es conveniente conocer y evaluar la experiencia y trayectoria del implantador / desarrollador de la aplicación en el campo de la gestión de la seguridad y salud. Es una buena idea revisar su panel de referencias comerciales y buscar implantaciones de la aplicación que nos interesa en organizaciones similares a la nuestra.
  • Finalmente no hay que olvidar el “día después” a finalizar el proceso de implantación. Evaluar los servicios de soporte y resolución de incidencias nos ahorrará sorpresas futuras.

Es conveniente que exista un compromiso mínimo de resolución de incidencias del sistema y un teléfono o mail de atención inmediata de dudas (si es posible en el país donde nos encontramos o en el mismo idioma en que trabajamos)

Prevencontrol

PrevenControl es la firma especializada en seguridad y salud laboral que propone soluciones eficaces e innovadoras para la mejora del negocio y la reputación de sus clientes a través de la consultoría, el uso de la tecnología y la formación.
¡Contáctanos!

Dejar un comentario

*

3 comentarios

  1. José Luis Fernández

    Estoy de acuerdo con todo el artículo excepto el último párrafo.

    Mi experiencia laboral me demuestra que en estos sistemas las dudas de los usuarios no son sobre el software, son sobre los procedimientos de trabajo de la organización.

    Por tanto, el teléfono/email/portal de soporte debe ser un soporte funcional aportado por la propia organización, no por el proveedor de software, que desconocerá los procedimientos de trabajo de la organización.

    Sólo aquellas incidencias reportadas al soporte funcional estén provocadas por un mal funcionamiento del software deberán ser reportadas al teléfono/email/portal de soporte del proveedor.

    Por tanto, la necesidad de que el proveedor dé soporte local no es tan relevante, ya que desde el punto de vista del usuario final, actuará como soporte de tercera línea. Quien debe dar soporte local es el soporte funcional, soporte que la propia organización debe proveer a sus empleados en primera línea (atención inmediata con una colección de respuestas a consultas habituales, normalmente un call-center) y en segunda línea (atención especializada para dudas más complejas, normalmente alguien de PRL).

    Esto no quita que se negocie el nivel de servicio adecuado con el proveedor de software, ya que en función de la criticidad que se dé al sistema, los plazos de atención o resolución de incidencias deberían ser acordes.

    • Diego Castelar

      Diego Castelar

      Buenos días José Luís,

      Muchas gracias por tu apreciación.

      El artículo hace referencia a aquellas herramientas complejas (herramientas específicas generalistas) que integran múltiples funcionalidades preventivas en la misma plataforma (evaluación, gestión de acciones, formación, notificación de accidentes, auditoria, vigilancia de la salud, gestión de epis, etc).

      A pesar que la tendencia en la implantación de estos sistemas es a realizar formación con metodología “learn by doing”, suelen surgir dudas y preguntas a los usuarios finales si éstos no emplean todas las funcionalidades disponibles de manera habitual.

      En tal caso, contar con un soporte local ayuda a subsanar la brecha horaria entre España y, por ejemplo, América latina.

      • José Luis Fernández

        Creo que no me expliqué bien. Doy por hecho que son herramientas complejas (precisamente me dedico a implantarlas aunque por no hacer publicidad prefiero no decir dónde y para quién), pero esa complejidad no reside tanto en el software como en los procedimientos de la organización para usarlo.

        Por ejemplo, ¿saben los empleados cómo deben clasificar convenientemente una inspección? ¿tienen claro qué se espera que rellenen en los campos de la investigación de un incidente? Esas respuestas no las podrá dar el soporte del proveedor de software.

        El soporte del proveedor de software podrá ayudarte si te falla el acceso a la aplicación o si encuentras algún error en el uso, pero cuándo se rellena un campo con “gravedad alta” y cuando con “gravedad leve” es un tema de procedimiento, no de software. Esas respuestas debe resolverlas un “soporte funcional” que no puede dar el proveedor de software.

        Mi recomendación son tres líneas de soporte:

        – Una primera línea a modo de call-center con cobertura horaria para toda la organización en todos sus emplazamientos. Esta primera línea resolverá dudas funcionales básicas e incidencias con el acceso al software que puedan estar provocadas por la infraestructura de la organización y no por el software (por ejemplo que el PC del empleado no tenga conexión de red y este reporte que no tiene acceso al software). Derivarán a segunda línea las que no puedan resolver.

        – Una segunda línea con conocimientos funcionales, que normalmente serán miembros del departamento de PRL o los que participen en la definición de procedimientos de trabajo. Si no pueden ser ellos directamente, entonces aquí lo habitual es subcontratar personal que se pueda formar en los procedimientos, pero que es ajeno al software. Si el comportamiento funcional es un fallo en el software y no una mala interpretación de un procedimiento entonces escalarán a tercera línea.

        – La segunda línea que se encargue de errores en la infraestructura ajenos al proveedor del software entroncará con personal del departamento de TI de la organización. A partir de ahí lo resolverán como corresponda según cómo se organice el soporte informático convencional de la organización.

        – Una tercera línea -el proveedor del software- que sólo atenderá las cuestiones que las segunda línea funcional les escale.

        Insisto en que mi recomendación es que los usuarios finales -los empleados- no interactúen directamente con el proveedor de software y que se haga a través de la segunda línea que serán los únicos interlocutores adecuados.

        ¿Por qué? Porque la segunda línea funcional parará el 99% de lo que los usuarios reporten ya que son dudas funcionales (esto lo avalo con mi experiencia) y el 1% restante serán incidencias que deba resolver el proveedor de software.

        Si el proveedor de software tienen que recibir el 100% para derivar el 99% le obligas a tener un número de técnicos de soporte desproporcionado para el valor que van a aportar. Y si lo que se espera es que el proveedor de software dé el soporte funcional entonces se le estará pidiendo que se dedique a un negocio distinto, porque ahí no se trata de conocer el software, sino cómo la organización ha decidido usarlo.

        Un cordial saludo.



He llegit i accepto la Clàusula de Consentiment.

Simple Share Buttons