Es conocido que SuccessFactors es un sistema modular que permite implementar cualquiera de sus módulos tanto siendo el maestro de los datos de los empleados como siendo el receptor de esos datos, y que no es necesario implementar todos. Lo importante para poder disponer del resto de los módulos (Performance & Goals, Learning, Recruiting, etc) es tener la información de los empleados necesaria, pero no es obligatorio gestionar esa información en SuccessFactors.
Sin embargo, el módulo de Empleado Central nos va a permitir tener toda la información que necesitamos para procesar cualquier otro módulo de SuccessFactors así como gestionar toda la información, procesos y necesidades del empleado en nuestra empresa. Es el core de la información de los empleados.
Hasta aquí, toda la parte dedicada a palabras generales sobre SuccessFactors. Cualquier documento preventa de SuccessFactors va a decir los dos párrafos anteriores de forma más bonita pero, ¿de qué se compone realmente Empleado Central a día de hoy?
Por un lado, vamos a ver la funcionalidad general que trae el módulo, y en algunas de ellas entraré a comentar mi opinión y también veremos otras funcionalidades, que se pueden implementar o no. También va incluida parte de la funcionalidad de la plataforma, que al tener Empleado Central, ya se puede utilizar.
Si accedemos a la ayuda de SAP, podemos acceder a la página de Empleado Central (por si caduca el enlace, entrar por esta página y poner en el buscador “SAP SuccessFactors Employee Central”).
Aquí nos vienen identificados casi todos los apartados de Empleado Central, los cuales centrarán estos post. Aunque es verdad, que mucha de la funcionalidad está incluida en la parte de Employee Central Master, las demás funcionalidades hay que activarlas ya que se entiende, que no todas las empresas las utilizarán.
En una entrada anterior, vimos cómo es un proyecto por dentro, cómo se estructura y los distintos hitos que tiene, pero para saber qué partes de Empleado Central queremos implementar (es posible que no necesitemos ni queramos poner todo) necesitamos conocer qué funcionalidades están disponibles.
Obviamente, cuantas más cosas queramos implementar más tiempo y recursos nos llevará, pero siempre será más económico y operativo descartar aquello que no nos haga falta, pero no porque no lo conozcamos, sino porque no lo necesitamos o no “estamos en ese momento” para utilizarlo. Así nos podremos centrar en lo que sí queremos.
En esta primera entrada hablaré solo de la parte de Employee Central Master, lo que creo que da de sobra para un post, así que continuaré después con el resto de funcionalidades disponibles.
EMPLOYEE CENTRAL MASTER
Es la configuración de Empleado Central. Si fuéramos a lo básico (y no tan básico), esto podría centrar todo nuestro proyecto y tendríamos una gran funcionalidad implementada. Vamos a poder definir la apariencia, el logo, y todo lo que verán los empleados, pero me centraré en la funcionalidad.
En primer lugar, no, como empresa no vas a poder configurar Empleado Central. Al menos, no todo.
Hay que realizar varias configuraciones en Provisioning, y ahí solo tienen acceso los consultores certificados. Pero a la hora de mantener el sistema, sí se podrán realizar muchas cosas como reglas de negocio, workflows, permisos, informes, etc. Incluso activar nueva funcionalidad, ya que cada vez SuccessFactors está dando más control al cliente dejando disponible mucha de la funcionalidad que antes solo se podía hacer en Provisioning.
Una parte fundamental, son los permisos. Role-Based Permission. “Básicamente” es permitir ver a cada colectivo solo lo que puede ver y sobre quién pueda verlo. El problema realmente es tener controlados los RBP y que no crezca su gestión repitiendo grupos y permisos.
Modelo de datos. Empleado Central puede tener todos los datos que se requieran, incluso contener documentos adjuntos a procesos. Muchos vienen como campos estándar y muchos otros se pueden añadir como campos de cliente. El sistema tiene preestablecida una estructura de los datos para, a partir de ella, almacenar todos los datos de la empresa.
En este apartado se incluyen los diferentes modelos de datos que tiene el sistema, hasta que todo se pase a MDF. Para muchos de los datos, se pueden modificar y añadir nuevos campos a través de la Configuración Empresarial.
Objetos Metadata Framework, MDF. Una de las mayores virtudes para mí, de SuccessFactors, es poder crear cualquier estructura de datos que nos haga falta para la gestión en el sistema. Y además, se le puede dotar de una o varias pantallas específicas y una lógica que nos permita manejar e insertar esos datos.
En general, se pueden realizar ampliaciones de datos acordes a las necesidades de la empresa. Esto permite adaptar el sistema a casi cualquier necesidad del negocio.
Reglas de negocio. Aunque es un sistema en el que no se programa, las reglas de negocio permiten aplicar lógica a los datos y procesos, de forma que se puedan proponer, modificar, cargar o validar datos, según el proceso o los datos que tiene o se indican al sistema. Además, también se utilizan para lanzar procesos en toda la plataforma, por lo que es utilizado en muchos módulos.
Tener un control interno de la creación de reglas, o al menos, de forma básica, puede permitir al propietario del sistema establecer o quitar controles que se pusieron durante el proyecto, y durante la fase posterior de estabilización y mejoras añadir o adaptar nuevas sin coste adicional. O claro está, llevarlo por soporte.
Workflows. Flujos de trabajo. Se puede poner validadores en el sistema de forma que antes de que un dato sea consolidado alguien tenga que modificarlo, aprobarlo y/o se informe a quien se requiera. Los workflows se pueden definir con todos los aprobadores que se quiera, envío a grupos, reenvíos, envíos automáticos en caso de bloqueo del mismo y reenvío de notificaciones periódicas. Al final y al cabo, un workflow parado o bloqueado es un proceso parado en la empresa.
Alertas. Como buen sistema de Recursos Humanos, hay muchas fechas almacenadas relevantes en los datos de los empleados. El sistema se puede configurar para que avise para cada una de ellas, cuando se necesite y a quien se necesite. Mediante reglas de negocio se pueden establecer avisos previos con X días de antelación al cumplimiento de la fecha.
Event Reason Derivation. Se puede configurar el sistema para que, según los cambios que se realicen en los datos de los empleados, automáticamente se seleccione el motivo de esos cambios. Nuevamente, mediante reglas de negocio el sistema puede detectar los cambios específicos que sirvan para poner un motivo de evento del cambio en particular, o si no hay ninguno específico, poner uno genérico. Esto puede ser muy relevante para ahorrar tiempo del personal encargado de introducir los datos, evitar “el error humano” y/o mantener una lógica en los cambios de datos. Es muy conveniente tener en cuenta el sistema de nómina a la hora de definir estos eventos, aunque realmente sea parte del modelo de datos.
People Profile. Vamos a poder configurar qué y cómo ven los empleados los datos en el sistema, en su perfil del empleado y/o del manager. Y según los datos a los que tengan permisos (RBP), los empleados y manager podrán verlos en el apartado de “Mi perfil”.
En la parte de People Profile se van a poder definir las secciones que verán los empleados, con el orden que se quiera. También es el punto de unión entre los objetos MDF y el empleado.
Como he comentado, configurar toda esta parte, y probarla, ya es un gran proyecto de por sí, así que en los siguientes post hablaré sobre muchas otras funcionalidades que se pueden añadir, si se quiere. Algunas más que recomendables, otras dependerán de los deseos y posibilidades.
