Durante la implementación de una plataforma HSE, las responsabilidades suelen estar relativamente bien definidas y rara vez se pregunta quién es el dueño de la plataforma HSE o cómo debe funcionar la gobernanza de plataformas HSE. Existe un equipo de proyecto, responsables funcionales, usuarios clave, IT, administradores, consultores o implementadores y, cuando es necesario, la participación del fabricante de la solución. El equipo debate, valida y sigue las decisiones porque existe un objetivo común: poner la plataforma en funcionamiento.
Sin embargo, tras la puesta en producción, esta estructura puede desaparecer rápidamente. El equipo de proyecto vuelve a sus funciones habituales, las reuniones se vuelven menos frecuentes y la organización pasa a tratar la plataforma como parte de la operación. Es precisamente en ese momento cuando surge una de las cuestiones más importantes para la sostenibilidad de la solución: ¿quién es responsable de garantizar que la plataforma sigue siendo correcta, coherente y alineada con la organización?
El dueño de la plataforma HSE difícilmente debería ser una única persona o departamento. De hecho, una plataforma HSE combina tecnología, procesos, datos, requisitos, usuarios y decisiones operativas. IT puede ser responsable de la seguridad, la autenticación o las integraciones, pero no debe definir por sí solo los criterios de cumplimiento. HSE conoce los procesos y los riesgos, pero puede no ser responsable de la administración técnica. Operaciones conoce la realidad del terreno, pero no debe modificar unilateralmente los estándares corporativos. El administrador sabe configurar, pero eso no significa que deba decidir por sí solo lo que la organización pretende controlar.
Por eso conviene entender el ownership de forma más amplia. La plataforma HSE no necesita solo un “dueño”. Necesita un modelo claro de responsabilidades.
Dueño de la plataforma HSE: La responsabilidad funcional no es administración técnica
Una de las decisiones más importantes tras la implementación es separar claramente quién decide lo que debe ocurrir de quién ejecuta la configuración correspondiente.
Imagine que una organización quiere añadir un nuevo requisito documental a una determinada función. Técnicamente, el cambio puede ser relativamente sencillo. Un administrador puede crear el requisito, definir su caducidad, asociarlo a un perfil y ponerlo en producción. Pero la decisión tiene consecuencias que van más allá de la configuración. Por ejemplo, puede cambiar el estado de trabajadores ya activos, generar nuevas pendencias o condicionar futuras movilizaciones.
Por eso, quien tiene autoridad sobre el proceso debe decidir la cuestión funcional. El administrador debe garantizar que la plataforma refleja correctamente esa decisión.
Esta distinción se aplica a muchos otros casos: modificar un flujo de trabajo, crear un nuevo estado, cambiar un permiso, retirar una aprobación o introducir una nueva clasificación. Es decir, el hecho de que una persona tenga permisos para ejecutar el cambio no significa que tenga automáticamente autoridad para decidir que ese cambio debe existir.
Cuando esta separación no está clara, surgen dos riesgos. En un extremo, cualquier cambio exige un proceso excesivamente burocrático y la plataforma pierde agilidad. En el otro, alguien realiza continuamente pequeños cambios sin evaluar su impacto y, al cabo de un tiempo, la solución empieza a acumular excepciones e incoherencias.
Por eso, una gobernanza eficaz debe encontrar el equilibrio entre estos dos modelos. El equipo puede ejecutar con autonomía los cambios sencillos y de bajo impacto. Por el contrario, los cambios que afectan a procesos, cumplimiento, seguridad o distintas áreas deben seguir un nivel de validación proporcional a su impacto.
Los datos también necesitan un dueño en la plataforma HSE
Además, la responsabilidad sobre la plataforma no termina en los flujos de trabajo y las configuraciones. Los datos también necesitan un modelo claro de ownership.
¿Quién decide cómo identificar a una empresa? ¿A quién corresponde evitar duplicados? ¿Quién controla la nomenclatura de los equipos? ¿Y quién puede crear una nueva categoría documental? ¿Quién decide si un determinado campo sigue siendo necesario? ¿Y a quién le toca resolver las diferencias cuando dos sistemas contienen información contradictoria?
Estas cuestiones se vuelven cada vez más relevantes a medida que la plataforma integra distintos procesos. Una empresa puede estar relacionada con trabajadores, equipos, contratos, documentación y proyectos. Un trabajador puede estar asociado a formación, competencias, actividades y requisitos. Por tanto, un error en un dato maestro puede propagarse por distintas áreas de la plataforma.
Así, sin ownership, la tendencia natural es la degradación progresiva de la información. Aparecen nuevas denominaciones para la misma realidad, categorías duplicadas, estados similares y excepciones locales. Individualmente, cada decisión puede parecer poco significativa; en conjunto, reducen la calidad de los cuadros de mando, dificultan las integraciones y aumentan el esfuerzo de mantenimiento.
La gobernanza de datos debe definir quién establece los criterios para cada conjunto de información y quién es responsable de asegurar su coherencia. No obstante, esto no significa centralizar todo el mantenimiento en una sola persona. Significa garantizar que existe alguien con autoridad para decidir cuando surgen dudas o conflictos.
Esta responsabilidad debe mantenerse a lo largo del ciclo de vida de la plataforma. La migración inicial puede crear una base limpia, pero solo un modelo continuo de gobernanza consigue preservar esa calidad.
Cliente, implementador y fabricante tienen responsabilidades diferentes
Además, otro punto importante es distinguir claramente los papeles de quien utiliza, implementa y desarrolla la tecnología.
El cliente debe ser el propietario de los procesos y de las decisiones de negocio. Es la organización la que conoce sus riesgos, requisitos, estructura y prioridades. Por otro lado, el implementador traslada esas necesidades a la plataforma, apoya la parametrización, asesora sobre el diseño funcional y ayuda a evaluar impactos. El fabricante es responsable de la tecnología, de la evolución del producto y de la corrección de los problemas propios del software.
Esta distinción es importante porque no todas las incidencias deben llegar al mismo nivel.
El equipo interno o el soporte funcional pueden resolver una duda de uso. A su vez, el administrador o el implementador pueden encargarse de un cambio de configuración. Una decisión sobre un requisito debe corresponder al cliente. Un fallo técnico del producto puede requerir la intervención del fabricante.
Cuando estos niveles no están definidos, las solicitudes circulan entre equipos, el tiempo de respuesta aumenta y los usuarios dejan de saber quién debe resolver cada situación.
Un modelo maduro busca resolver cada cuestión en el nivel adecuado y escalar solo cuando es necesario. Esto reduce la dependencia y mejora la autonomía sin eliminar el acceso al conocimiento especializado.
También protege a la organización de un riesgo frecuente: convertir al administrador interno en el responsable de todo. Un usuario experimentado puede conocer a fondo la plataforma, pero no debe concentrar por sí solo la configuración, el soporte, la definición funcional, la calidad de los datos y la decisión sobre todos los procesos. Esa dependencia crea vulnerabilidad operativa y puede llevar a que se tomen decisiones importantes de manera informal solo porque una persona conoce mejor el sistema.
La gobernanza de plataformas HSE debe continuar tras la implementación
Durante la fase de proyecto suele haber más disciplina. Los equipos debaten, prueban y validan los cambios. Tras la puesta en producción, en cambio, puede surgir una lógica más reactiva: alguien pide un cambio, el administrador lo resuelve y el proceso sigue.
Así es como muchas plataformas empiezan, poco a poco, a alejarse del modelo definido inicialmente.
Un nuevo proyecto exige una excepción. Otro equipo pide un estado adicional. Después, un cliente solicita un documento específico. Y un usuario quiere una vista diferente. Sin embargo, ninguna de estas decisiones es necesariamente problemática. El riesgo surge cuando alguien resuelve cada solicitud de forma aislada, sin comprobar si la necesidad es local, temporal o lo bastante relevante como para modificar el modelo global.
Por eso, la gobernanza no debe terminar cuando termina el proyecto de implementación. Debe acompañar la evolución de la plataforma.
Con todo, no es necesario crear estructuras pesadas. En muchas organizaciones, basta con definir responsables, criterios para los cambios, un registro de los cambios relevantes y revisiones periódicas. Lo importante es que la evolución sea intencionada.
También debe existir cierto nivel de trazabilidad. Cuando cambia una regla importante, debería ser posible saber qué ha cambiado, por qué y quién validó la decisión. Sin ese contexto, la plataforma empieza a depender de la memoria de las personas, y esa memoria se pierde cuando hay cambios en el equipo.
La gobernanza debe garantizar la continuidad.
El verdadero dueño de la plataforma HSE es un modelo de responsabilidades
Preguntar “¿quién es el dueño de la plataforma HSE?” es útil porque obliga a la organización a identificar responsabilidades que a menudo permanecen implícitas.
IT puede ser responsable de la arquitectura y la seguridad. HSE puede ser propietario de los procesos funcionales. Operaciones puede encargarse de la ejecución sobre el terreno. Gestión Documental puede controlar determinados requisitos y criterios. Los administradores pueden gestionar la configuración. El implementador puede apoyar la evolución y la optimización. El fabricante garantiza la tecnología.
Sin embargo, ninguna de estas responsabilidades, por sí sola, es suficiente.
De hecho, el valor está en la forma en que se articulan.
Una plataforma HSE es un sistema vivo. La organización cambia, los requisitos evolucionan, entran nuevos usuarios y surgen nuevas necesidades. Sin gobernanza, esta evolución se produce de forma fragmentada. Con gobernanza, en cambio, la plataforma puede adaptarse manteniendo la coherencia, la calidad de los datos y la alineación con la operación.
Las preguntas esenciales son sencillas:
¿Quién decide? ¿Quién configura? ¿Y quién mantiene los datos? ¿Quién presta soporte? ¿Quién aprueba los cambios críticos? ¿Y quién supervisa el uso? ¿Y quién garantiza que la plataforma sigue alineada con los objetivos de la organización?
Responder a estas preguntas es tan importante como elegir la tecnología.
Porque, tras la puesta en producción, la plataforma deja de ser solo un proyecto.
Pasa a ser una infraestructura operativa.
Y una infraestructura de este tipo necesita responsabilidades claras, decisiones estructuradas y un ownership continuo para seguir siendo útil a lo largo del tiempo.
Para profundizar: Plataforma HSE y digitalización HSE: Guía completa.
Lea también: Cuanto más configurable es la plataforma HSE, mayor debe ser la gobernanza y Cómo medir si una plataforma HSE se está adoptando realmente.
Para más información sobre normas internacionales de gestión, consulte la Organización Internacional de Normalización (ISO).