En toda empresa surge la necesidad de guardar nuevos datos de los empleados, ya sea por necesidad de un evolutivo o por un tema legal.
Hace unos cuantos posts creé un objeto MetaData Framework para explicar cómo se podría ampliar la funcionalidad del sistema para gestionar las plazas de garaje en varios edificios. Y cómo podían solicitarla los empleados, con reglas, flujos, tipos de datos, etc. Pero… ¿siempre es necesario hacer todo eso?
Pues depende, como siempre. Si lo que quieres es una funcionalidad que no cubre el estándar (de esto haré una aclaración al final) y que incluya varios campos, flujos, ect, pues es posible que sí. Y según se ve en el post, no son tantas las cosas que hay que hacer, o son muchas las que se pueden hacer.
Sin embargo, en muchos de los casos, tendremos que ampliar alguna funcionalidad estándar con 1 campo, 2 campos, ¿10 campos? ¿30?
En algunos casos, necesitaremos una ampliación de campos porque la administración lo requiere, o porque vamos a querer guardar un dato nuevo en el sistema, o algo que será muy común, queremos integrarnos con otro sistema y para conectarnos con él tenemos que enviar un dato obligatoriamente, que antes no teníamos almacenado. Sea el caso que sea, vamos a un ejemplo práctico.
Imaginad que en vuestra empresa se requiere la entrada al parking con una tarjeta. Esa tarjeta tendría que estar asociada a los empleados de alguna forma. ¿Dónde?
Obviamente, podemos crear un objeto MDF para gestionar la petición, la entrega, y tener el histórico, pero busquemos algo más fácil. Ya tenemos en la empresa la gestión de la petición, así que podemos poner ese campo en algún portlet estándar.
En la configuración empresarial podemos ver todos los portlets con los campos que tiene el sistema.
Podemos ver los campos que tenemos activos y los que no, y su configuración en cada uno de ellos
Y para los casos en los que no encontramos ningún campo en el estándar que nos cubra la necesidad, como ahora, podemos crear campos custom según lo que necesitemos, los que queramos. Solo falta encontrar el portlet en el que lo queremos guardar.
Como se puede ver, hay muchos portlets y muchos campos, por lo que hay que conocer el sistema para “atinar”.
Las recomendaciones a tener en cuenta deberían ser:
- Quiero guardar el histórico de este dato, una opción puede ser el portlet de información personal. O en la parte local del país.
- Si no me hace falta el histórico, puedo usar un portlet sin histórico como la información biográfica
- Quiero guardarlo con el resto de datos de documentación, puede ser en el portlet de información de ID Nacional (añadiendo la opción correspondiente)
Estas son varias preguntas a responder para elegir la mejor opción. En este caso, iré por la primera, quiero tener un histórico. (Y si tienes integración con otros sistemas deberías pensar si te puede afectar antes de decidir el sitio).
Pero dejemos la parte práctica para otro día. Lo primero será ver qué podemos hacer en la configuración empresarial.
La configuración empresarial es la pantalla que nos permite gestionar en SuccessFactors el Succession Data Model y el Country Specific SDM. El que no sepa qué es esto, pues tampoco le hace falta saber mucho más. Básicamente, que es lo más cercano a las tripas que podemos ver del sistema.
El Succession Data Model contiene los campos que va a contener cada portlet, su definición, cómo se relacionan con otros, las reglas por las que se rigen y las restricciones que tienen. Eso de forma básica y rápida. Pero los Data Model solo se pueden gestionar en provisioning.
Así que la Configuración empresarial es la funcionalidad que nos va a permitir gestionar casi todas las características de los campos de cada uno de los portlets estándar. Pero hay más.
La pantalla se divide en 2 secciones.
La parte de la izquierda es donde se encuentran cada uno de los portlets, que al seleccionarlos podemos ver los campos y reglas de negocio que pertenecen a ese portlet en la parte de la derecha. Pero también se encuentra la parte del perfil del empleado, sobre todo los campos que forman parte del perfil y que podrán ser llamados desde otros módulos de SuccessFactors, y los antecedentes (es la traducción estándar de los elementos Background), que básicamente son otros datos de los empleados que no se corresponden con datos personales ni laborales directamente. Como ejemplo serían los relativos a experiencia en otras empresas, en puestos internos de la misma empresa, idiomas y otros muchos datos.
Y además, la pantalla cuenta con un registro de última modificación, a modo de auditoría, por lo que en caso de que haya algún cambio en el sistema, podemos ver si se ha hecho algún cambio reciente y donde.
La verdad es que es una pantalla que tiene muchas opciones y que será básica conocer para poder configurar el sistema, y desde luego, es mucho más cómoda que estar trabajando con los Data Model.
La demostración práctica la dejamos para el siguiente post, y también los pasos posteriores, que no todo puede ser dar a un botón y que todo funcione.
Por último, antes dije que aclararía lo de las cosas que no vienen cubiertas por el estándar. Hay que distinguir lo que es añadir una funcionalidad al sistema, como podría ser una ampliación a través de una extensión desde una cuenta de empresa de SAP Cloud Plarform con una aplicación SAPUI5 que se puede incluir en SuccessFactors, como bien explicó Carlos Blanco aquí, de los campos que nos permite añadir el sistema “de cliente” en un portlet estándar, como se incluye en este post y que estarán integrados como cualquier otro campo, de añadir un elemento de antecedentes y también de los objetos MetaData Framework que comenté anteriormente.
Estaba claro que con un único post no me iba a dar para meter todo
