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.
Tags: Nomenclatura, PFCG, roles, SAP, Seguridad
[...] Seguridad SAP I, II [...]
Hola, creo que a partir de la versión 4.5 ya no es necesario que los roles comiencen con Z; pero nunca pueden empezar con SAP_ dado que son los roles estándar de SAP.
En mi empresa estamos utilizando los siguientes items dentro de la nomenclatura:
- la empresa o país (*): recomiendo utilizar 4 caracteres dado que Company Code tiene ese tamaño; también pueden usar ese tamaño para el país, como ARGE, MEXI, BRAS, etc.; si el rol es Global, pueden usar los caracteres GLOB o GLBL.
- módulo (*): recomiendo 2 o 3 caracteres. Tener en cuenta que existen módulos de 3 o más caracteres, como BCS, APO, etc. Nosotros estamos utilizando 2 caracteres pero dentro de la “descripción del rol” ponemos el código del módulo completo..en lo posible;
- tipo de rol: si es de Visualización, Administración, Modificación, Autorización, Gestión, Impresión, etc., en la medida de lo posible. Por ejemplo usar los códigos DISP (Display), ADM (administrator), UPD (update), AUT (authorizer) o REL (releaser), etc.
Pero existen roles que poseen el nombre de un puesto de trabajo “Vendedor”, “Comprador”, “Analista Contable”, y esto es válido también; en este caso formará parte del “resto” del código del rol. En nuestra empresa tenemos ambos casos y son válidos.
- resto: texto libre para identificar al rol.
- código del sistema del rol (opcional): para identificar el servidor al que pertenece el rol. No se refiere a si es Development, QAS o Production, sino el tipo de Servidor como R3, CRM, SCM, XI, HR, BW, etc. Esto nos ha sido muy útil para los roles de IT que poseen el mismo nombre en todos los sistemas, incluyo tenemos casos de roles de usuarios finales que aplican para más de un sistema a pesar que posean transacciones diferentes.
- tipo de rol (opcional): para identificar si es un rol Padre, Derivado o Compuesto. Esto nos es de mucha utilidad al momento de sacar reportes con el objetivo de identificar de una forma más fácil el tipo de rol.
Recomiendo que el código del rol debe ser legible no solo por los Analistas de Seguridad sino también por el resto de IT y hasta usuarios finales en caso que la empresa tenga un esquema de autorización de asignaciones de roles complejas.
Espero que esto haya sido de utilidad.
Saludos. Pablo
Gracias por el aporte! Todas son alternativas válidas, la idea básica es plantear la necesidad imperiosa de pensar una nomenclatura al momento de empezar a trabajar para ahorrarse dolores de cabeza después, y que los mismos sean entendibles por por la mayor cantidad de gente posible, lo más rápido posible. Muchas gracias de nuevo por tu participación!
Saludos!
Excelente Aporte!
Hay diversos metodos y criterios.
Pregunta:
Es conveniente que convivan Roles Simples y Roles Compuestos?
Saludos Jorge
Es posible crear nombre de roles con el primer caracter diferente de Z o Y.
Para una empresa revise que utilizan como primer caracter el Sistema en el cual se está creando el rol.
ERP = E
Portal = P
BW = B