A esta altura repasamos ya en el blog varios temas básicos, y hasta tuvimos un pantallazo de la transacción PFCG para poder crear y modificar roles (grupos de autorización o papeles).

Pero ahora hay un tema bastante importante que tratar, porque tiene implicancias bastante serias para el éxito o fracaso de un proyecto de seguridad SAP. Este tema es, justamente, el NOMBRE que les vamos a asignar a estos roles, siendo que el mismo está acotado a 30 caracteres como máximo.

El tema es bastante crítico y existen pocas reglas universales a aplicar al momento de bautizar a los pequeños roles, pero vamos a tratar de enumerar algunas pautas importantes:

1 – La única regla universal… TODOS los roles deben empezar con la letra Z (a lo sumo con la Y)… Esta notación nos va a servir como en cualquier ámbito de SAP para diferenciar lo que nosotros creamos, de lo que es estándar de SAP. Adicionalmente. si trabajamos con los roles estándar sin modificar su nombre y el día de mañana actualizamos la versión de SAP (cosa probable), es también altamente probable que sean sobrescritos por los nuevos, entre otros problemas.

2- Se acabaron las reglas universales… y a partir de ahora arranca la creatividad del diseñador de la seguridad para hacer un buen trabajo. Si aunque parezca mentira, algo de creatividad podemos aplicar en este trabajo

3- Si existe el requerimiento organizacional que la seguridad sea descentralizada tenemos que preocuparnos por los primeros caracteres que vienen después de la Z. Por ejemplo… si tenemos que crear una seguridad en donde cada oficina de cada país que acceda a SAP va a tener un administrador propio, podríamos empezar nuestro roles como: “ZAR” para Argentina, ZUY para Uruguay, y así sucesivamente.

De esta manera podemos hacer que cada administrador de seguridad esté limitado a gestionar los roles que comiencen con las siglas de su país. Esto se logra limitando a los administradores de seguridad en el objeto S_USER_AGR. Cómo podrán imaginar esta restricción puede hacerse para muchas cosas y por muchos motivos distintos, por ejemplo, para restringir la modificación de roles de base, restringir la modificación de los roles de seguridad, y un largo etc.

El hecho es que solo vamos a poder hacerlo por el principio del nombre de los roles, con lo cual es importante determinar este requerimiento apenas comenzamos a definir la nomenclatura.

4- Otra alternativa es definir, después de la Z, el módulo sobre el que “mayoritariamente” los roles van a dar acceso. Aunque no soy particularmente afecto a esto ya que depende el criterio que se use para construir los roles puede que este no respete los “límites de los módulos de SAP”. En este caso nuestros roles serían algo como “ZAP*”, “ZTR”, etc.

También puede hacerse uso de criterios que nos ayuden a identificar el proceso al que pertenecen los roles (si se encuentran tipificados en la organización)

5- Las posibilidades para las primeras letras son númerosas y mucho va a depender de las necesidades organizacionales. En algunas ocasiones para facilitar la lectura puede utilizarse un separador, pero siempre tengamos en cuenta que la cantidad de caracteres que tenemos para nomenclar un rol son relativamente escasos. Ejemplo: “ZMM:CMPR”, “ZUY:SLCT”

6- Ahora ya utilizamos los primero para la Z, los segundos para el país y hasta a lo mejor alguno más, y nos encontramos parados después de un separador. El resto va a depender mucho de como construyamos en si los roles, si nos enfocamos en puestos de trabajo, en actividades, etc.

En un próximo artículo vamos a tratar especificamente esto, pero hoy escapa un poco a lo que es la nomenclatura. Lo ideal independientemente de esto sería generar nomencladores estandar de 4 letras (+ o – según las variantes) por ejemplo de manera que un rol se llame: “ZAR:CMPR_SLCT”. Así estaríamos creando un rol propio (Z), para Argentina (AR), el cual pertenece al circuito de COMPRAS (CMPR) y su función es la de SOLICITANTE (SLCT).

7- Hasta aquí identificamos un rol, pero nos faltaría identificar en el mismo las variantes, ya que por ejemplo en este caso podrían existir roles separados por Centro, Organización de Compra, etc. Con lo cual el rol si el centro es A001 podría pasar a llamarse “ZAR:CMPR_SLCT-AR01″. De esta manera si utilizamos roles con herencia (Padre e Hijo) podriamos llamar al padre ZAR:CMPR_SLCT y los sucesivos hijos para cada centro serían *-AR01, *-AR02, etc. Podría seguir extendiendose para posibles variantes con Organización de compra hasta que los caracteres alcancen.

Es importante tomar conciencia que la nomenclatura es sumamente importante a la hora de definir los roles, y que adicionalmente es muy importante instalar el tema, incluso, al momento de realizar las definiciones más “grandes” del proyecto. Ya que la complejidad o simplicidad de la seguridad puede verse muchas veces afecta por la nomenclatura que utilizan los Analistas Funcionales a la hora de definir cosas tan globales para SAP como las Sociedades, Centros, Organización de Compras, Tipos de Documento, Divisiones, y un largo Etc.