¿Qué es realmente un HR Triggers? En resumidas cuentas, es una solicitud que se lanza de manera automática por parte de GRC Access Control cuando se realiza un cambio específico en los datos maestros de HR.
Los HR Triggers son muy utilizados para tener controladas las bajas de empleados en una compañía, ya que cada vez que desde RRHH se tramité la baja, GRC estará lanzando una solicitud automática en el mismo momento del cambio grabado por RRHH, actualizando la fecha de validez en todos los sistemas SAP conectados a GRC en los que exista el usuario por la fecha de final de contrato. Lógicamente existen más posibilidades, todas en las que una organización quiera monitorizar cambios en infotipos de HR, por ejemplo: lanzar solicitudes tipo:
- Solicitud de eliminación y/o bloqueo de cuenta por baja en la compañía.
- Solicitud de nueva cuenta por alta en la compañía.
- Solicitud de cambio de cuenta por cambio de en algún valor de un infotipo (por ejemplo, posición, sociedad, etc.).
- Solicitud de cambio de cuenta (fecha de validez) por baja en la compañía.
Base de funcionamiento
Ampliando un poco más este concepto, el funcionamiento es bastante sencillo, desde el sistema en el que el cliente tenga los datos maestros de HR (normalmente el sistema central de ECC), se crea una cola con todos los cambios realizados en los infotipos de HR, esta cola contiene el infotipo, el campo modificado, el valor anterior y el nuevo. Esta cola se pasa a GRC a través de una conexión RFC, el cual lee todos los cambios a través de un BRF y detecta aquellos que que el cliente quiere tener controlados, y una vez se realiza uno de esos cambios, automáticamente GRC abrirá una solicitud de GRC ARM con el formato que el cliente quiera diseñar.
Requisitos de Configuración
¿Y cuáles son los prerrequisitos? Antes de comenzar un proyecto de configuración de HR Triggers en GRC, hay que tener en cuenta que será necesario asegurar que los siguientes puntos están ya configurados. Son varios puntos los que hay que tener en cuenta:
- Deben de estar instalados los componentes GRCPIERP & GRCPINW en el sistema de HR.
- Debe estar implementado el módulo de Access Request Management, para que GRC pueda lanzar las solicitudes automáticas (en el sistema de GRC).
- Todos los empleados a los que les pueda afectar los HR Triggers deben de tener correctamente mantenido el SAP ID en el infotipo 105 (dato que se encuentra en el sistema de HR, normalmente el sistema central ECC). Este punto requiere de una explicación más amplia, ya que es muy importante. En el infotipo 105 se mantiene la relación SAP ID con el nº de empleado, y en el momento que GRC localice un cambio en un campo que sea necesario monitorizar, buscará en este infotipo el SAP ID del nº de empleado actualizado y lanzará la solicitud automática para este SAP ID.
- La importancia de mantener este atributo (SAP ID en el infortipo 105) a nivel de empleado se explica con dos ejemplos:
- Baja no ejecutada: imaginemos que tenemos configurados los HR Triggers para dar de baja empleados, si se diese un caso de que un empleado no tuviese SAP ID asignado en el infotipo 105, aunque desde RRHH se le diese de baja, nuca iba a poder gestionarse la solicitud automática, ya que GRC no encontraría su SAP ID.
- Baja ejecutada de manera incorrecta: si el SAP ID mantenido fuese el de otro empleado distinto, se estaría dando de baja al empleado incorrecto.
Puntos clave
En resumidas cuentas, con los HR Triggers se pueden automatizar cambios en infotipos que la organización necesita que sean controlados siempre, sin excepciones y sin posibles errores humanos por olvido, evitando que se realicen acciones, como las bajas de usuarios, que son imprescindibles para el buen funcionamiento de una organización.
Los HR Triggers son solicitudes pueden tener las etapas de aprobación que considere el cliente, pero por ejemplo, para las bajas suelen ser solicitudes sin etapas de aprobación, es decir, que tan rápido se abren ya están completadas, en las que se actualiza la fecha de validez del usuario en los sistemas SAP. De esta manera, cuando expire el contrato, la validez del usuario habrá expirado.
Adicionalmente hay un programa estándar de SAP, que .bloquea los usuarios expirados, por lo que, si este programa se ejecuta en un job diario, el sistema de bajas es muy efectivo.