Durante este artículo, vamos a analizar algunos de los beneficios que proporciona tener en nuestro sistema SAP© un modelo de roles definido en base a las buenas prácticas que recomienda SAP©, así como un modelo de roles compuestos.
Modelo de Roles en Buenas Prácticas
A continuación, revisaremos los principales puntos que debemos tener en cuenta a la hora de definir nuestro modelo de roles:
- Definición lógica Modelo de Roles
- Nomenclatura de Roles
- Matriz de Valores Organizativos
- Estructura Organizativa
- Matriz de Riesgos
- Uso Transaccional
Es importante definir previamente la lógica que queremos que tenga nuestro modelo. Cuando estamos hablando de un sistema ECC, en la mayoría de los casos, es recomendable utilizar un modelo de Padres (Master Roles) e hijos (Derived Roles), utilizando roles habilitadores (Enabler Roles) en los casos que sean necesarios. Por ejemplo, para realizar una restricción específica de un campo que no es valor organizativo o a un objeto custom que habilita una funcionalidad concreta.
Teniendo en mente la lógica que más nos conviene para nuestro modelo, definiremos la nomenclatura de roles. Es importante intentar utilizar los 30 caracteres que permite SAP© al máximo y que todos y cada uno de ellos nos aporten valor. De esta forma nos será muy útil el poder realizar búsquedas a través de tablas o identificar fácilmente los roles que deseamos asignar. Por ejemplo, si dan accesos de modificación o visualización, a que áreas funcionales pertenecen los accesos que contiene, si es un rol padre o hijo, a que business unit aplica, breve descripción de la funcionalidad del rol utilizando abreviaturas…
Dentro de nuestra nomenclatura también es importante dejar caracteres para identificar el valor organizativo (la planta, compañía…) por la que estamos restringiendo nuestro rol derivado. Además, hay que tener muy claro como se relacionan los distintos valores organizativos entre sí para cubrirlos correctamente. Por ejemplo, que derivemos nuestro rol a nivel de planta, no significa que dentro del contenido del rol solamente vaya a tener este valor organizativo, por lo que es importante saber con qué otros valores, por ejemplo organización de ventas o de compras, se relaciona cada planta para no dar permisos a los usuarios a otras unidades organizativas que no deberían poder acceder.
Si tenemos nuestra estructura organizativa a nivel departamento y puestos de los usuarios claramente definida esto nos ayudará a definir nuestros roles compuestos, de los cuales hablaremos más adelante.
Para hacer nuestra clasificación de transacciones en roles, es muy importante que tengamos en mente nuestra Matriz de Riesgos (o en caso de no tener una propia definida la estándar de SAP©) y que nuestros roles estén creados en base a funcionalidades. Por ejemplo, “crear proveedores”. Esto evitará que nuestros roles contengan riesgos de segregación de funciones internos y que podamos reducir los riesgos de nuestro sistema al máximo.
Los accesos deben estar diferenciados en nuestros roles en accesos de visualización o cambio (lo cual debe estar fácilmente identificable en nuestra nomenclatura del rol). Hay ciertas transacciones que pueden tener esta doble funcionalidad y dependerá de las actividades que seleccionemos en los objetos que chequee la transacción.
Para facilitar la asignación de transacciones es recomendable que cada transacción esté como máximo en dos roles, siempre y cuando pueda restringirse a visualización o cambio. Importante verificar que ninguno de nuestros roles de visualización está dando accesos de modificación. En cambio, sí podríamos añadir las transacciones de visualización en los roles de cambio de la misma funcionalidad, de esta forma si un usuario solamente necesita visualizar materiales se le da el rol específico de visualización, pero si necesita modificar materiales con darle el rol de modificación este ya incluiría los accesos tanto de modificar como de visualizar materiales sin necesidad de tener que asignarle dos roles.
Una vez tenemos nuestro modelo de roles definido y creado nos basaremos en el uso transaccional para dar a cada usuario exclusivamente lo que utiliza. Es recomendable utilizar un uso transaccional lo más amplio posible y que cubra cierres de mes y año.
Beneficios Modelo de Roles en Buenas Prácticas
- Creación de un modelo flexible que se adapta a los diferentes requerimientos que la compañía tiene o pueda tener.
- Modelo intuitivo que agiliza la identificación del rol o roles que estemos necesitando.
- Permite la asignación específica a los valores organizativos que requieran los usuarios. De esta forma no podrán ver o modificar datos de otras business unit a las que no pertenecen.
- Facilita la reducción de riesgos en el sistema. Por ejemplo, si a nivel empresa se decide activar un nuevo riesgo que no estaba siendo monitorizado, es sencillo identificar que roles están dando dicho riesgo y poder retirar dicho acceso a los usuarios que no lo requieran.
- Reduce el número de Licencias Profesionales asignadas. Como los accesos en el sistema están muy restringidos, evitamos tener que dar una licencia profesional a un usuario que no la requiere por estar sobreautorizado.
- Simplifica la identificación de accesos en el aprovisionamiento de usuarios.
Modelo de Roles Compuestos
Una vez tenemos nuestros roles con nuestras transacciones creados, SAP© nos permite crear roles Compuestos. Estos son roles que contienen otros roles. Es decir, realizaríamos agrupaciones de nuestros permisos definidos, por ejemplo, a nivel de puestos.
Para la definición de los roles compuestos es imprescindible tener una estructura organizativa clara, y de esta manera poder diseñar correctamente nuestros roles compuestos, evitando así añadir roles que dan acceso a transacciones que no correspondan al puesto.
A continuación, mostramos diferentes ejemplos, a bajo nivel, de cómo se podrían segregar los diferentes puestos por cada departamento.
Como es evidente, todos nuestros usuarios en SAP© deben tener su departamento y puesto de trabajo al que pertenecen debidamente indicado.
La creación de roles compuestos es recomendable pero no imprescindible, sería como una segunda fase de mejora tras tener nuestro modelo de roles en buenas prácticas creado. Resaltar que no se podría crear un modelo de compuestos sin antes realizar todos los pasos comentados al principio del artículo, ya que estos roles compuestos contendrán nuestros roles previamente diseñados y creados.
Nuevamente el uso transaccional será de gran valor para la definición de los accesos que compondrán nuestros roles compuestos. También será necesario tener presente la matriz de riesgos, de cara a reducir al máximo los riesgos por compuesto.
Es posible que sea necesario crear varios roles compuestos por cada Departamento y Posición en base a la segregación de accesos a nivel de valores organizativos. Por ejemplo, en la empresa hay 5 managers de ventas, pero cada uno hace la gestión para cada una de las 5 plantas que tiene la compañía. Por ello, todos deben tener los mismos accesos, pero cada uno restringido a una planta de la compañía en concreto. Esto debe de estar claramente indicado en la nomenclatura de los roles compuestos.
Beneficios Modelo de Roles Compuestos
- Reducción en el número de incidencias a nivel solicitud de accesos. La incidencia reportada se solucionará para todo el departamento, no solamente para la persona que realiza la solicitud.
- Gestión más eficiente de los tickets.
- Los accesos que tienen los usuarios están claramente identificados, facilitando la gestión a la hora de dar de alta un nuevo usuario en SAP©.
- Simplificación del proceso de “movers” dentro de la compañía, puesto que sería fácilmente identificable los accesos del nuevo puesto, y se podría poner una fecha fin de validez al puesto al que dejará de pertenecer mientras se hace la transición.
- Identificación inmediata del tipo de Licencia necesaria por compuesto (Departamento y Posición).
- Automatización del proceso de altas mediante la integración con IDM (Identity Management System). Se crearía una relación entre el puesto de trabajo y el rol de SAP© y el sistema IDM realizaría el aprovisionamiento automático.