MUNDOSAP

Regresar   MUNDOSAP > NOTICIAS SAP - ABAP IV > NOTICIAS PRINCIPALES
Nombre de Usuario
Contraseña
Home Descargas Registrar FAQ Miembros Calendario Buscar Temas de Hoy Marcar Foros Como Leídos




 
Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Viejo 21/03/14, 20:53:50
cubarnes cubarnes is offline
Junior Member
 
Fecha de Ingreso: mar 2014
Mensajes: 1
La mejor manera de generar roles y perfiles

Estimados

En la empresa que trabajo actualmente tuvimos una salida en vivo exitosa ya que trabamos 1 rol 1 transacción y no trabajamos por 1 rol n transacciones ósea por cargo por las siguientes razones:

Desventajas

• La administración se hace muy tediosa utilizando un costo muy alto referente al tiempo utilizado a la hora de revisar cada una de las autorizaciones que genera cada tx insertada en este rol.
• Muy complicado y engorroso se hace la modificación o visualización en la PFCG de las autorizaciones que contiene el rol generado por cada una de las tx presentes en este Rol, la pregunta es tienes claro cuál de estas son para cada tx, claro que si te respondes las veo en la tabla AGR_1251 y AGR_1252 pero ojo esta no contiene la información completa.
• Tienes claro que valores debe llevar cada rol en sus respectivas tx para su operatividad correcta y no subsidie o potencie alguna otra autorización.
• Los rediseños y creaciones de roles y perfiles permanentes.

Ventajas

• El bajo costo en tiempo en la administración de sus autorizaciones, solo veras las autorizaciones en la PFCG (objetos campos y valores de autorización) que acarrea solo una tx para su correcta operatividad y administración de ella.
• si nos ponemos a revisar los roles que contienes muchas transacciones ósea un rol por cargo, para revisar cada tx las cuales utilizan muchos objetos de autorización para su operatividad “correcta” ,por si llegase a insertar una nueva tx o modifico un valor a alguna autorización puedo potenciar alguna otra tx que solo por ejemplo tiene acceso solo para ver órdenes de venta de Chile pero ahora con algún valor de alguna autorización de la tx insertada se potencia para ver las de Argentina es por eso que muchos que trabajamos en R&P nos preguntamos como puedo asegurarme de que al realizar una modificación o inserción de un nuevo valor o inserción de una nueva tx no me subsidie otra autorización a otra tx (transacción) y cada vez que hago alguna inserción modificación o insertar una nueva tx debo probar cada tx de este rol para saber si alguna se potencio en su funcionalidad si se me potencio una o mas tx debo nuevamente revisar, ojo que todas las revisiones son en ambiente DEV y una vez que reviso debo transportar a QAS y probar y si vuelvo detectar que se potencio debo probar y probar y probar, el tiempo que se ocupa es demasiado y si es lo pudes solucionar imagínense u rol 50 tx, osea tienes que revisar las 50 transacciones antes para saber si alguna se potencio en su sabor.

En el mismo caso si un usuario necesita ver solo las órdenes de ventas de Chile pues creo un rol solo para Chile y necesito que solo vea las de argentina creo otro para argentina.
Es la misma metodología para todos los roles al momento de querer segregarlos ya sea en clase condición, materiales deudores, liberación de pedidos etc.

• Contamos con una herramienta Z que extrae las trazas del sistema (valores de autorizaciones), extrae todas las autorizaciones ojo que en ese momento el usuario tiene Permisos amplios (en ambiente DEV M120 pruebas unitarias) no así permisos para las autorizaciones protegidas por sistemas, grupos de autorizaciones y customising para poder probar la tx (programa) en toda su funcionalidad y así poder alimentar a la base de conocimiento solo con los valores que le corresponde para operar y no entregar otros valores sin que los necesite y evitar que potencie a otras tx, es por esto la importancia de alimentar bien y con los valores precisos la base de conocimiento, por otro lado te preguntaras y como protejo los valores reservados ya sea sistema, customising grupos de autorizaciones y valores de autorización reservados solicitados por los Jefes de proceso de cada módulo, también tenemos menciona una herramienta Z la cual realiza lo siguiente:


1.- Existen dos reglas que son las más importantes:
- Regla para valores no reservados
- Regla para valores reservados
- Tenemos también reglas para roles de visualización etc.

• Su trabajo es extraer de la base de conocimiento ya alimentada por nuestras trazas todas las autorizaciones del rol de su respectiva tx, una vez que los inserta estas son reconstruidas y filtrados por medio de las reglas, me elimina por una parte, todas las autorización de sistemas, customising etc. y me cercioro que si y solo si tendrá el rango de valores que no han sido solicitado reservar por los encargados de cada módulo o el basis de la empresa.

• En cambio con la otra regla nos aseguramos que solo el rol con su respectiva tx en su respectiva autorización solo tenga este valor, obviamente que esta regla también tiene insertado el rango de valores no reservados en caso de que algún rol contenga el objeto a proteger para sí y nuevamente lo menciono no potenciara a la otra tx .


• Esto es lo misma filosofía para la derivaciones y segregaciones de roles.

Nota importante: Las trazas con la muy inteligente herramienta Z extrae las trazas diarias y las guarda en un archivo de texto de cada instancia, a la hora de querer regenerar los roles ya tienes las trazas respectivas en tus archivos de textos (historial de trazas) y en caso de alguna falla del sistema alguna actualización de algún parche de SAP destruya los roles y vuelvan a sus valores estándar, solo tomas las trazas alimentas nuevamente la base de conocimiento, y guala, en poco muy tiempo tienes los roles reconstruidos y te evitas de crearlos nuevamente.
Y más paranoico, se borraron los roles por algún error del administrador que se yo, también tenemos una herramienta Z creador de roles en forma masiva.
Solo imagínate; alimentada la base de conocimiento con los valores reales para la correcta operatividad de cada tx mas las reglas o filtros, genero solo una vez los roles de cada una de las tx utilizadas por cada módulo y nuevamente te digo guala tengo nuevamente los roles en mi sistema en muy poco tiempo.


Respecto a la nomenclatura de los Roles decidimos hacerlo de esta manera:

("X_000_00_00_")

"X" : Tipo de Rol: ("O" de objeto, "T" de transacción, "F" de función, "C" de reservado, P de Impresora, etc.)

000: Derivación del Rol: ( es decir, qué Área geográfica utilizará el Rol, cuando va el valor 000, se trata de un Rol padre que puede ver y trabajar con todos sus valores)

00: Se Refiere al Módulo al cual pertenece un Rol (MM, SD, FI, CO, etc)

00: Se refiere a la potencia o los sabores del Rol el cual puede ser: 01(Crear), 02(Modificar), 03 (Visualizar), etc.

< ALGO>: Se refiere a que debe ir indicado el Nombre de la Transacción si el Rol es Tipo "T" o "C", el nombre de la Impresora si es Tipo "P", el nombre del Objeto si es tipo "O"

¿Te preguntaras como los identifico? te respondo; solo con el nombre de la TX así de fácil y te aseguro que la mesa de ayuda no se perderá a la hora de asignar roles a cada usuario, solo deben solicitar las tx a asignar por su jefe directo y validadas por cada jefe de proceso de cada módulo para llevar un control real de ellas y asegurarnos que solo contenga los roles que solo necesita para su trabajo y te vuelvo a repetir sin el ánimo de polemizar no tendrá ninguna autorización reservada siempre cuando pidan el rol y solo ese rol tendrá ese valor y si es que otro rol asignado al mismo usuario contenga el mismo objeto y campo de autorización pero solo tendrá el resto de valores no reservados como te mencione anteriormente.
Y para finalizar la herramienta de generación de roles en el fondo es la PCFG pero los genera de 1 a x roles automáticamente ojo que solo la utilizas para generar los roles una sola vez para solamente pasarlos por la reglas y insertar los valores y seguirás ocupando siempre lo Standard solo la volverás a ocupar si te solicitan un rol para una tx nueva.
Todas estas herramientas son una ayuda a lo Standard nunca se deja de ocupar, pero más que eso piensa por un momento y claro es difícil ya que has trabajo por mucho tiempo la forma 1 rol n tx el cambio de las funciones de los usuarios acarrea un contante cambio en las autorizaciones de los roles o cuando un usuario reemplaza a otro pero necesita solo realizar una parte de su trabajo y así podemos estar viendo las debilidades del roles por cargo.
Te aseguramos que no tendrás problemas de potenciar alguna autorización de una tx con esta forma de trabajar 1 Rol 1 tx y con todas las herramientas con las que contamos que para nada supedita lo Standard.
con método nuestro te evitaras todo gasto innecesarios, NOSOTROS RESPETAMOS LAS BUENAS PRACTICAS DE SAP Y LAS APLICAMOS SOLO DECIMOS QUE LA FORMA DE SAP QUE PLANTEA DE CÓMO GENERAR LOS ROLES ES DEFICIENTE, ESTA DEFINICION EXPLICADA ES PARA TODAS LAS EMPRESAS QUE OCUPAN SAP, SOLO HAY QUE REEPLANTEARSE Y ANALIZAR LO EXPLICADO Y INSISTO LAS HERRAMIENTAS SON SOLO DE APOYO Y LA REAL ADMINISTRACION LA GENERAS EN LAS REGLAS PARA ASI PROTEGER DE NUENA MANERA INFORMACION DE LA EMPRESA.
Si quieren algún ejemplo no dudes en preguntar o lo podemos realizar por medio de una video conferencia.
Responder Con Cita
  #2  
Viejo 21/09/15, 15:33:15
Avatar de bruky
bruky bruky is offline
Senior Member
 
Fecha de Ingreso: may 2009
Localización: España
Mensajes: 555
Buenas tardes cubarnes,

Perdona que interfiera, pero a mi punto de vista, no veo una buena praxis en ello:

- Crear 1 rol por 1 transacción, los usuarios poseen un numero máximo de perfiles asignados.

Por lo que si creamos roles por transacciones, en cuanto un usuario necesite acceso a multitud de transacciones, este empezará a tener problemas de "desbordamiento" de perfiles, por lo que empezará a tener errores de autorización.

- Si en una empresa grande que tengan implantados varios modulos (FI, CO, MM, SD, WM, PS, etc.), crear un rol por transacción significa crear miles y miles y miles de roles, por lo que se hace imposible la gestión de las autorizaciones.

- Por otro lado, la nomenclatura de roles no estándar deben comenzar por Z/Y.. letras que SAP apruebe como comienzo de algo no estándar.

- SAP, al validar una autorización, chequea en los perfiles del usuario y comprueba el objeto que se está chequeando, si el usuario posee dos roles con el mismo objeto y diferentes valores, por mucho que estén separados en dos roles y se utilicen en diferentes transacciones, SAP chequeará ambos objetos.


Siento que mi punto de vista difiera del tuyo, pero es como lo pienso.
Agradecería que, si estoy equivocado, abriéramos un debate para hablarlo

De nuevo perdona por exponer mi punto de vista.
Saludos.
__________________
Persigue tu objetivo, nunca te rindas!
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Reglas de Mensajes
no puedes crear nuevos temas
no puedes responder temas
no puedes adjuntar archivos
no puedes editar tus mensajes

El código vB está On
Las caritas están On
Código [IMG] está On
Código HTML está On
Saltar a Foro


Husos Horarios son GMT. La hora en este momento es 14:47:30.


www.mundosap.com 2006 - Spain
software crm, crm on demand, software call center, crm act, crm solutions, crm gratis, crm web