Comments on: Proyectos: Metodología de Construcción de Roles en SAP

By: Francisco

Francisco — Mon, 06 Feb 2012 22:57:58 +0000

Hola

Creo que esta metodologia que comentas es muy practica a la hora de enfrentar un proyecto de reingenieria de roles en SAP, sin embargo creo que tambies es importante considerar algunas otras variables que tienen un alto impacto dentro de un proyecto de estas magnitudes.
Si bien creo importante tener claro el modelo de negocio a fin de ir alineando los roles a estos modelos, pues una de las claves es tener muy semejantes los roles a como esta estructurada la organización; tambien es sumamente importante el tema de “definición de variantes” y me refiero al tema de la definición de los valores que tendra cada uno de los objetos de autorización que tiene definidos cada transaccion code. Este punto es clave , ya que en organizaciónes grandes, complejas como pudiera ser una planta productora de autos, en donde tienen un sistema sap con muchos niveles organizacionales, la comprension adecuada de estos niveles y su correcta implementación seran claves para el exito de este tipo de proyectos.
Para ser mas claros, existen algunas transacciones que no son exclusivas de un rol o funcion especifica dentro de la organización, por ejemplo , el uso de la transaccion FBL1. Esta transacción pudiera ser utilizada por un area de cuentas por pagar para verificar el edo de cuenta de un proveedor, sin embargo quiza tambien puede ser utilizada por un area de compras o incluso un area de logistica quienes son los que probablemente tengan mayor contacto con los proveedores.
Pero si bien quiza las 3 areas necesiten el acceso a esta transacción, evidentemente cada una de ellas la necesita para fines distintos, la cuenta por pagar la necesita para checar los pagos de los proveedores y quiza necesite modificar algunos items del edo de cuenta, los de compras quiza solo necesiten visualizar o cambiar solo determinados datos y la logistica quiza solo requieran actividades de visualización
Ante esta necesidad lo mas conveniente es crear roles distintos para cada una de las áreas, a fin de si tengan acceso a la fbl1 pero que dicho acceso unicamente este limitado a los requerimientos de sus funciones dentro de la empresa, de no serlo asi, podriamos caer en problemas de accesos a transacciones criticas y segregación de funciones.

Para compartir comentarios http://www.pakoaguirre@hotmail.com

By: Carlos Dìaz

Carlos Dìaz — Wed, 01 Jun 2011 02:24:31 +0000

Excelente Post, la verdad que siempre lo repaso, incluso ahora me encuentro en otro proyecto de roles, en realidad formar parte de un proyecto de upgrade de SAP. Es toda una nueva estrategia alinear estos dos proyectos por el gran impacto que tienen ambos tanto para las pruebas integrales como puesta en productivo.
Si bien el modelo de roles no pierde su consistencia si la asignaciòn de los roles a los usuarios al momento de realizar las pruebas integrales las autorizaciones no pueden ser tan restrictivas dado que podria retrazar las fechas estimadas para las pruebas. Igualmente para la salida en productivo. Este es un tema tan critico para los encargados de seguridad ya que no prima el modelo de seguridad sino el nivel operativo.

Gracias por los aportes amigos.

By: Liliana

Liliana — Wed, 22 Dec 2010 18:16:35 +0000

Buenas Tardes:

Muchas gracias por los consejos, estan muy buenos.

Por otro lado me gustaría, de ser posible si podrías ampliar mas el concepto de segregación de funciones, como se lo arma si es que no existe en la empresa etc.

Muchas Gracias

By: Eugenio

Eugenio — Tue, 28 Apr 2009 16:24:56 +0000

Buen día,
Esta muy bien el procedimiento, pienso utilizarlo para una implementación con Oracle.
Con respecto a tener disponibles los procesos de negocios creo también que es una parte fundamenteal y si no se tienen entonces el proyecto debe iniciar por la elaboración del mapeo de los procesos, de esa manera el proceso pudiera ser utilizado tanto para la mejora de los procesos, así como para la segregación de funciones.

Saludos

By: Diego

Diego — Wed, 22 Apr 2009 20:35:30 +0000

Y si es verdad! es poco común tener los procesos disponibles y hay que luchar mucho por darle la importancia que merece a este tema. Esperemos con el tiempo poder “evangelizar” algo más en seguridad! Saludos!

By: Mosquito

Mosquito — Thu, 16 Apr 2009 18:56:06 +0000

Buenas!
esta muy bien este procedimiento, yo quisiera agregar que en mis años de consultoria en seguridad. solo en un solo proyecto tuve los procesos de negocio como imput para armar las agrupaciones de actividaes.
normalmente no existe dicha estructura. los funcionales no le dan importancia al tema y los key users no estan muy involucrados.
entonces el equipo de autorizaciones tiene que evaluar los organigramas. hacer un relevamiento de uqe se usa. y extrapolar de algun otro proyecto o de los roles standar de sap.
me hubiera encantado tener los procesos y es algo que siempre trato de tener. pero la verdad es que nunca se dio.
saludos
Mosquito

By: Diego

Diego — Thu, 02 Apr 2009 23:44:03 +0000

Buenas! Gracias por tu participación! La realidad es que es la reseña de una metodología. La idea es, en posteriores posts, profundizar sobre cada uno de esos pasos, o al menos sobre los más importantes. Puntualmente el tema de SoD lo pensaba tratar en otro post aparte pero estoy tratando de armar algo interesante al respecto. Sobre la construcción de roles por tareas indivisibles y no por puestos de trabajo jajaja siento que escucho las mismas palabras que repetí tantas veces (y creo en algún post lo dije antes). Pero es TAN DIFICIL hacer entender ese concepto y separarlo del “puesto”… Aunque con paciencia y algunas cosas aprendidas se puede hacer. De nuevo muchas gracias por el aporte! Saludos! Diego

By: ISH

ISH — Thu, 02 Apr 2009 07:36:56 +0000

Echo en falta varios puntos fundamentales:
- Definir la matriz de segregación de funciones a utilizar (si no, es imposible realizar un análisis de SoD) que es diferente en cada CIA especialmente en lo que respecta a transacciones z (aunque las funciones incompatibles sean fácilmente reutilizables en todos los casos)
- Definir y poner en marcha los procedimientos que garanticen que el modelo definido inicialmente sin incompatibilidades se mantiene en el tiempo (qué normas seguimos al modificar los roles o crear nuevos y cuáles son los pasos para asignar nuevos roles a los usuarios, que deben incluir siempre una validación de que se mantienen los criterios de SoD)
También es relevante aclarar un problema común en muchas organizaciones: en el paso 1 – identificación de roles, se tiende a asociar “rol” con puesto organizativo. Esto es un tremendo error que puede llevar al fracaso cualquier modelo, ya que los roles organizativos evolucionan y cambian en el tiempo, obligando a continuas modificaciones del rol SAP. Lo correcto es identificar aquellos grupos de tareas indivisibles que en general siempre se utilizan juntas y serán necesarias para un mismo usuario (ej. mantenimiento de materiales).

Un saludo

By: Amigo

Amigo — Wed, 01 Apr 2009 14:21:31 +0000

Para complementar lo relacionado a la segregación de funciones, existen mejores prácticas en este contexto y que etán incluidas en SAP GRC Access Control. Son reglas de incompatibilidad de transacciones en los roles de usuarios.

Quien quiera acceder a estas reglas envíeme un mal a amigogratis@gmail.com y se las haré llegar.

Saludos y muy bueno el post.

By: Julio

Julio — Mon, 30 Mar 2009 18:58:15 +0000

Diego: impecable como siempre todo lo suyo, felicitaciones.

Abrazo