Porque existen problemas de Autorizaciones ?

 

 

 

La Pregunta sin respuesta

 

Quizá resulta absurdo tener que hacernos esta pregunta si es que sabemos que hemos construido los roles (papeles) y perfiles correctamente. También sabemos que hemos asignado los perfiles de autorizaciones a los respectivos usuarios de la manera correcta y por tanto, nada debería fallar: Sin embargo, ¡ hay problemas de autorizaciones ! cuando un usuario ejecuta alguna transacción.

 

La experiencia nos dice que existen dos momentos críticos durante la implementación de uno o varios módulos de SAP donde se siente la gravedad de este tipo de problemas: 

  • Durante la salida en vivo. Es el momento donde los problemas radican en la falta de autorización y ello genera preocupación a todos los participantes del proyecto por lo trascendental del momento.

  • Durante un periodo estable. Es el momento donde se detecta que los usuarios tienen más autorizaciones que las que necesitan y muchas veces obliga a discusiones porque nadie quiere asumir la responsabilidad.

Cada uno de los momentos tiene sus propias características, y el nivel de gravedad también estará en función del modelo o esquema de autorizaciones elegido. Como se dijo en un artículo anterior, elegir un modelo no está dentro de los planes de implementación y generalmente se usa el modelo de "Crear roles por función", es decir, se determinan funciones principales de proceso y que implica un pequeño conjunto de transacciones. Cada una de estas funciones se transforma en rol o papel y luego, al usuario se le asigna un grupo de estas funciones (o roles). Este esquema en el cual a un usuario se le asigna varios roles, podría traer consecuencias negativas y que se percibe durante el mantenimiento y las mejoras continuas. En un siguiente artículo se revisará un poco más a detalle el tema de "Esquema de autorizaciones". Por ahora. centraremos nuestro interés en los momentos críticos de autorizaciones indicado líneas arriba.

 

Durante la salida en vivo

 

Durante la salida en vivo, se generan muchos problemas de falta de autorización cuando el usuario inicia las operaciones o procesos por medio de la ejecución de transacciones. Es clásico que en cualquier momento aparece el tradicional mensaje "Falta autorización para ejecutar la transacción". El usuario se frustra porque piensa que está ejecutando algo indebido o que no sabe manejar la operación. El jefe superior inmediato, así como los funcionales piensan lo mismo y cuando comprueban que la operación está correcta, dirigen la mirada hacia el creador de usuarios y autorizaciones porque asumen que es el responsable y algo hizo mal. Lo cierto es que a esas alturas no queda más que ejecutar el clásico "/NSU53" para detectar la autorización que falta y asignarle a uno de los roles que tiene el usuario. Luego el usuario debe salir del sistema y volver a ingresar para volver a ejecutar el proceso. En algunos casos, la operación culmina satisfactoriamente o de repente aparece nuevamente el famoso mensaje de falta de autorización y tiene que volver a repetir el proceso del "/NSU53", corregir y empezar de nuevo.

 

Muchos se preguntaran porque sucede esto y la respuesta es simple: Las pruebas antes de salir en vivo no estuvieron realizadas adecuadamente. Esto lógicamente molestará a los funcionales responsables pero es la pura verdad. Siempre debemos tener presente que el Funcional responsable (que puede ser el que participó en la configuración ó el gerente del área) es el que define quien debe tener cual o tal autorización, porque es el único que sabe las funciones que realiza cada uno de los empleados del área. El Administrador de Autorizaciones es el que se encarga de crear los roles y asignar las autorizaciones que ha definido el Funcional.

 

Pero, porque decimos que las pruebas no estuvieron realizadas adecuadamente ? y la respuesta también es simple: Porque si los procesos que nos están generando problemas de autorización en la salida en vivo, lo hubiésemos hecho durante el periodo de prueba, el error se hubiese presentado en ése momento y lo hubiéramos corregido.

 

En el periodo de prueba, no basta con poner la transacción, dar intro y ver que aparece la pantalla para llenar los datos. Muchas veces pensamos que es suficiente y decimos: "ya tengo acceso a la transacción". Pero no es así. Debemos llenar los datos y concluir con el ciclo completo de la transacción hasta finalizar, ejecutando incluso las distintas funciones que nos proporciona por medio de botones, selecciones etc. Incluso, aún habiendo realizado todo el ciclo, volverlo a ejecutar probando con distintos datos (Sociedad, almacén, sector, etc. que también son llamado Niveles organizacionales), para asegurar que la transacción nos permite trabajar con distintos valores.

 

Cuando se ejecuta una transacción, en realidad lo que se ejecuta internamente son programas y que pueden existir muchas funciones asignadas para una transacción. A su vez, cada una de las funciones realiza ciertos chequeos de verificación e incluso llamadas a otras transacciones. La única manera de poder detectar todas estas variantes es tratando de ejecutarlas durante el periodo de prueba. Debemos recordar entonces que mientras más pruebas sometan a las transacciones, menor impacto de problemas se tendrá a la hora de salir en vivo. Para ello, es necesario elaborar un Plan de trabajo donde exista el compromiso de la Gerencia para su elaboración y ejecución. En dicho plan se debe establecer los tiempos y todas las variedades de pruebas que se puedan realizar. Son los funcionales los llamados a definir esta variedad puesto que como ellos han participado en la configuración, conocen las transacciones y los diferentes valores que tienen definido los diferentes campos o niveles organizacionales.

 

Los usuarios finales son los que deben realizar las pruebas, ejecutando las transacciones en un ambiente adecuado (generalmente es una instancia de aseguramiento de la calidad) y los funcionales en la labor de supervisión para asegurar dicha ejecución. El administrador de autorizaciones participará recogiendo los problemas y corrigiendo en los roles respectivos hasta que éstos queden totalmente afinado y operativos.

 

Si se cumple con todo lo anterior, en la salida en vivo se presentará uno que otro problema, pero, ya no será traumática porque la mayoría de problemas se detectaron y corrigieron durante el periodo de prueba.

 

Durante un Periodo estable

 

Una vez realizada la salida en vivo, en un periodo que puede variar en muchos o pocos meses, suele presentarse otro fenómeno no previsto: demasiadas autorizaciones para un usuario. En la mayoría de los casos los usuarios ni siquiera lo saben, en otros casos lo saben y hay incluso quienes realizan un mal uso de ellas. Esto provoca una reacción alarmante a nivel ejecutivo porque saben que existe un grave peligro en la seguridad de la información, obligando a una revisión del tema y generando una serie de recomendaciones por parte de las gerencias y auditores logrando con ello una gran preocupación por saber que ha sucedido.

 

Lo cierto es que muchas veces es difícil responder a dicha pregunta porque la respuesta puede ser compleja. Ello depende de muchos factores, siendo uno de ellos, y uno de los más importantes: la rotación fuerte de personal y de funciones de una misma persona. Esto quiere decir que si a una misma persona le cambian mucho sus funciones, implica cambiar constantemente sus roles asignados. Dependiendo del modelo o Esquema de autorizaciones elegido, debemos tener siempre presente que: si asignamos una transacción a un rol, todos los usuarios que tienen asignado dicho rol, también podrán hacer uso de dicha transacción.

 

Durante los siguientes meses, luego de la salida en vivo, el mantenimiento de las autorizaciones se da por 3 razones básicas:

  1. Correcciones: En su labor diaria, el usuario detecta algún problema de falta de autorización que obliga a modificar sus roles. El Funcional es el que decide si debemos dar o no la autorización pero, a veces no se toma en cuenta si las modificaciones pueden afectar a todos los usuarios que tiene también asignado dicho rol. 

  2. Mejoras continuas: Nuevos cambios producto de asignación de nuevas transacciones o de nuevos programas por nuevas implementaciones. Esto obliga también en modificación de roles igual que en el caso anterior.

  3. Rotación de funciones a usuarios. Muchas veces se reasignan nuevas funciones a los usuarios obligando con ello a realizar cambios en los roles, ya sea incrementando otras transacciones o asignando nuevos valores en los niveles organizativos del rol. Ejemplo: Inicialmente un Asistente de compras podía ejecutar sus transacciones restringidas a los centros 001 y 002, pero luego se decide que se amplíe sus facultades para los centros 003, 004 y 005. En este caso, igual que el primero, muchas veces no se toma en cuenta en que puede afectar a los usuarios que tienen asignado el rol que se ha cambiado.

En la implementación inicial, el Funcional responsable define adecuadamente las transacciones y sus valores de niveles organizativos (Sociedad, centro, almacén, etc.) que debe tener cada rol, así como la lista de usuarios con sus roles asignados. Esta definición siempre está documentado en matrices que con el tiempo va quedando desactualizado producto de los cambios indicados líneas arriba. Esto hace que el funcional, jefes y  gerentes, pierdan la visión funcional sobre que autorizaciones tiene cada rol y sobre todo, cada usuario, haciendo cada vez más dificultoso y engorroso su manejo.

 

Lo ideal para salvar estos problemas es que lo documentado en matrices se siga actualizando para que siempre sea el fiel reflejo de lo que está dentro del sap y permita analizar los cambios y sus consecuencias antes de llevarlos al sap. Para ello se requiere metodologías y procedimientos de cambios bien elaborados que aseguren que estos se realizan sin que existan repercusiones futuras. De lo contrario, obligará a un cambio total que en ciertos casos puede resultar una mejor solución.

 

En cualquiera de los casos, el tema de autorizaciones hay que manejarlo con mucho cuidado cuando implementamos nuevos cambios o correcciones, haciendo revisiones periódicas tanto en la documentación como lo que está implementado en sap. Existen herramientas que ayudan a estas revisiones e incluso, de ser necesario, se deben desarrollar programas que ayuden a detectar posibles conflictos que puedan traer consecuencias desagradables en el futuro.  

 

-------------------- 0 --------------------