Proyectos: Metodologa de Construccin de Roles en SAP

A lo largo de un proyecto de implementacin de SAP o una reingeniera de la seguridad del sistema nos encontramos con distintas tareas a realizar para construir los roles que le sean funcionales a la organizacin. En el presente post evaluaremos una alternativa metodolgica para trabajar utilizada en varios proyectos exitosos de implementacin de la seguridad de SAP.

El grfico que vemos arriba representa el proceso completo el cual pasamos a detallar:

Etapa 1 Identificacin de Roles

Entradas: Mapa de Procesos de la organizacin Tareas: Una vez que los procesos se encuentran modelados se comienzan a identificar las actividades indivisibles que pueden ser agrupadas en roles. A su vez sobre estos roles se realizar un primer anlisis de segregacin de funciones para detectar Salidas: Mapas de procesos con roles asignados a las actividades. Actores: Analistas de Procesos, Analistas Funcionales SAP, Usuarios Clave, Control Interno, Administracin de Seguridad.

Etapa 2 Seleccin de Transacciones

Entradas: Mapas de procesos con roles asignados a las actividades. Tareas: Definicin de transacciones necesarias para ejecutar las actividades definidas en el mapa de procesos. Armado de roles y anlisis de Segregacin de Funciones por cdigo de transaccin. Apertura de roles de negocio en roles del sistema de acuerdo a las necesidades de mantenimiento u optimizacin (agrupar actividades de visualizacin, incorporar reportes necesarios para ejecutar la actividad principal, etc.)

Salidas: Definicin de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorizacin a completar. Actores: Analistas Funcionales SAP, Control Interno, Administracin de Seguridad

Etapa 3 Definicin de Variantes

Entradas: Definicin de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorizacin a completar. Tareas: Elaboracin de una planilla de criterios de apertura por niveles organizativos u otras necesidades especficas. Definicin de las necesidades de apertura basndose en la confidencialidad, requerimientos del negocio, distribucin geogrfica, y control interno. Construccin de las variantes. Salidas: Variantes de rol construidas y listas para las pruebas. Actores: Usuarios Clave Control Interno, Administracin de Seguridad, Analistas Funcionales SAP (apoyo)

Etapa 4 Prueba de Roles

Entradas: Roles y variantes construidos (al menos uno de prueba). Tareas: Elaboracin de los casos de pruebas positivas y negativas (que no tiene que poder hacer). Ejecucin de las pruebas. Registracin de resultados y correccin de errores. Salidas: Roles Aceptados y Construidos. Actores: Usuarios Clave, Control Interno, Administracin de Seguridad, Analistas Funcionales SAP.

Etapa 5 Asignacin a Usuarios

Entradas: Planilla de Roles y Variantes (Puede comenzar el relevamiento de asignacin antes de la finalizacin de la prueba) Tareas: Relevamiento de asignacin de usuarios a roles. Puede hacerse un relevamiento previo para validar el criterio de roles con el negocio, y luego abrirlo en las variantes respectivas. Anlisis de Segregacin de funciones en la asignacin.

Salidas: Seguridad creada y documentada. Actores: Usuarios Clave, Control Interno, Administracin de Seguridad.

Comentarios sobre el proceso:

- Es de suma importancia incorporar una actividad anterior a todas estas etapas, involucrando a los participantes del proyecto desde el lado funcional, para comentarles como es el proceso, cual sera su participacin y el grado en que debern involucrarse en el proceso. Del xito, y la comprensin de esta charla depender mucho el xito final del proyecto.

- Las dos revisiones de segregacin de funciones a lo largo del proyecto atacan problemas distintos. El primero trata que los roles en si mismos no contengan problemas de segregacin, de ser as, la simple asignacin del rol estara dndole un problema al usuario al que se le asigna. Este caso no puede ocurrir nunca porque implicara una mala definicin del rol por parte de los responsables. La segunda revisin es ya para controlar que a un usuario no se le presenten problemas de segregacin de funciones por poseer ms de un rol y estos entren en conflicto entre s, y es distinto al control anterior. Espero que les sea til el presente post y espero sus comentarios.