Muchos clientes desean remediar la mayoría de los riesgos de SoD (Segregación de Funciones) cambiando el modelo de roles actual que tienen en el sistema SAP. Sin embargo, es fundamental comprender cuáles son las implicaciones de este tipo de proyectos y cuáles son los puntos clave a tratar. Durante este artículo redactado por David Torres, responsable del Departamento de la línea de negocio de SAP en Inprosec, vamos a cubrir los más importantes en función de las diferentes fases de un Proyecto de Diseño de Roles.
Preparación/Análisis
Durante esta fase, se deben definir la Convención de Nombres (Naming Convention), el Enfoque de Diseño de Roles y la Asignación de Roles a los Usuarios (Role Mapping).
- La Convención de Nombres es un aspecto clave que ayudará a todos los involucrados en el proceso de Provisión de Usuarios a entender qué acceso está asociado con cada rol. Es esencial involucrar a todas las partes interesadas en esta tarea. Existe una Lección Aprendida que afirma que la Convención de Nombres es sólo una responsabilidad de IT, lo cual es un gran error, ya que el proceso de Provisión de Usuarios no involucra únicamente al departamento de IT.
- Extraer y entregar los valores organizativos que se están utilizando en la actualidad. El sistema SAP suele almacenar valores como códigos de empresa, plantas, organizaciones de compras, organizaciones de ventas, etc., que pueden estar obsoletos. Permitir que el equipo del proyecto extraiga estos datos sin una revisión previa por parte de los expertos puede llevar a la creación de roles innecesarios.
- Es probable que nuestros usuarios de SAP necesiten transacciones personalizadas, pero en muchos casos estas transacciones no han sido debidamente documentadas, lo que dificulta su incorporación en los roles. Es recomendable dedicar algo de tiempo para que los expertos en procesos ayuden al Equipo de Proyecto a definir correctamente esos roles y aprovechar esta actividad para documentar aquellas Transacciones Personalizadas que aún no cuentan con información completa.
- Los Roles basados en Puestos de Trabajo (Job Position Roles) son siempre un tema complejo cuando se habla de Proyectos de Diseño de Roles. Muchos clientes desean abordar esta cuestión, pero no siempre están preparados para diseñar estos roles. Para lograrlo, se deben cumplir los siguientes requisitos:
- Tener una definición clara del puesto de trabajo. También es importante que dichos puestos hayan sido revisados y aprobados por el departamento de RRHH.
- Cada puesto debe tener, en promedio, más de un usuario. Crear roles basados en puestos de trabajo con un único usuario no sigue las mejores prácticas de diseño de roles.
Testing
Es fundamental comunicar a las personas encargadas de las pruebas que esta es una actividad clave en un Proyecto de Diseño de Roles. Desde la perspectiva del proyecto, se recomienda optimizar la definición de los escenarios de prueba.
Existen dos perfiles clave en la fase de pruebas:
- Expertos en Procesos (BPO – Business Process Owners): Son los responsables de verificar que las transacciones funcionen correctamente. En la mayoría de los casos, las transacciones estándar de SAP ya están documentadas, por lo que este grupo de personas debe enfocarse principalmente en las pruebas de transacciones personalizadas.
- Usuarios Clave (Champion Users): Son quienes poseen mayor conocimiento sobre el uso de SAP desde la perspectiva del usuario. Estos usuarios prueban los roles basados en puestos de trabajo y la asignación de roles definida en la fase anterior.
Gestión de la Comunicación
Dado que un Proyecto de Diseño de Roles afecta a toda la organización, se recomienda definir un Plan de Gestión de la Comunicación. Este plan debe incluir las siguientes actividades:
- Talleres sobre la Convención de Nombres.
- Talleres para la Definición del Diseño de Roles.
- Talleres para la Revisión de los Valores Organizacionales.
- Talleres para la Definición de los Puestos de Trabajo.
- Reuniones de proyecto para la Definición de los Escenarios de Prueba.
- Reuniones de proyecto para el Proceso de Pruebas de Aceptación de Usuarios (UAT).
- Talleres para la Definición de la Comunicación Global sobre la Implementación del Nuevo Modelo de Roles.
- Talleres para la Definición del Proceso de Gestión de Incidentes.
Estos son los puntos clave, pero dependiendo de la cultura organizacional, se pueden incluir otras actividades dentro del Plan de Comunicación.
Despliegue
Esta es una fase crítica, y es importante entender que en este tipo de proyectos aparecerán algunas incidencias. Por esta razón, se incluyó previamente el Proceso de Gestión de Incidentes como una parte clave del Plan de Comunicación.
Como mejor práctica en la gestión de incidentes, es clave:
- Mantener la calma y permitir que el equipo del proyecto trabaje en la resolución del problema.
- Clasificar los incidentes correctamente:
-
- Si el problema no es crítico y algunos usuarios pueden verse afectados pero aún pueden trabajar, el equipo del proyecto analizará el modelo de roles para identificar dónde está el problema y cuál es la solución que deben aplicar.
- Si se trata de un problema importante, se deberá ejecutar el Plan de Reversión (Roll Back Plan), devolviendo temporalmente a los usuarios los accesos previos a la implementación del nuevo modelo de roles. Luego, el equipo del proyecto analizará el problema y restaurará el acceso cuando la solución esté lista.
Ten en cuenta que, si la fase de pruebas se realizó correctamente, los problemas críticos no deberían ocurrir en este tipo de proyectos. Los incidentes más comunes incluyen:
- Falta de valores específicos dentro de los objetos de autorización → Corrección rápida.
- Falta de acceso a transacciones llamadas a través de otras transacciones (ejemplo: FBL1N y FB02) → Corrección rápida.
- Datos de uso transaccional que no tienen en cuenta nuevas transacciones implementadas recientemente → Corrección más compleja.
Por otro lado, y desde la perspectiva del cliente, el compromiso de los stakeholders en esta fase es fundamental. En algunos casos, la persona que tiene un problema con SAP Access podría necesitar resolverlo lo antes posible, y por esta razón, es fundamental contar con un sistema de prioridades dentro del Proceso de Gestión de Incidentes. Sin embargo, es igualmente importante asegurarse de que dichas prioridades se utilicen correctamente. Además, no se pueden marcar todos los incidentes como críticos, ya que esto dificultará que el equipo del proyecto pueda priorizar adecuadamente la resolución de los problemas.
Otro aspecto importante que abordar durante la fase de implementación es la comunicación de los incidentes por parte de los usuarios finales. En algunos casos, los usuarios finales intentarán resolver sus problemas siguiendo el proceso habitual de la empresa, conocido como Business as Usual (BaU). Sin embargo, en este contexto, el proyecto se encuentra en modo de implementación, y el equipo del proyecto ha diseñado un Proceso de Gestión de Incidentes específicamente para esta fase.
Basándonos en nuestra experiencia, es fundamental redoblar los esfuerzos de comunicación en relación con el despliegue del nuevo diseño de roles y el Proceso de Gestión de Incidentes, ya que esto determinará el éxito o el fracaso del proyecto.
En los proyectos de diseño de roles en los que hemos trabajado, una de las mayores preocupaciones desde la perspectiva del cliente ha sido la existencia de incidentes no resueltos debido a que no fueron correctamente comunicados al equipo del proyecto. Esto ocurre porque los usuarios finales no siguieron el Proceso de Gestión de Incidentes, y el equipo de Business as Usual (BaU), que gestiona las actividades diarias de administración de accesos, no tenía el conocimiento necesario para resolver estos problemas específicos. Esto es completamente lógico, ya que no fueron ellos quienes diseñaron el nuevo modelo de roles.
Por lo tanto, es importante asegurarse de que el equipo de Business as Usual esté informado sobre la ejecución del proyecto y que, en caso de recibir incidentes relacionados con autorizaciones, redirijan estos problemas al equipo del proyecto para que puedan ser resueltos de manera adecuada.
5 aspectos clave a tener en cuenta
- El compromiso de los stakeholders es un factor clave para el éxito del proyecto.
- No se deben reducir recursos destinados a las actividades de comunicación, ya que son esenciales para el éxito del Proyecto de Diseño de Roles.
- El equipo del proyecto no es responsable de definir los valores organizacionales en SAP. Validar qué valores son correctos y cuáles están obsoletos es una responsabilidad del cliente.
- La Convención de Nombres de roles no debe ser solo responsabilidad de IT. Los roles en SAP serán solicitados por los usuarios finales, por lo que la convención de nombres debe ser comprensible para ellos.
- La gestión de incidentes es clave para resolver problemas a tiempo. La mayoría de los retrasos se deben a que no se sigue el proceso de gestión de incidentes.
Inprosec, expertos en proyectos de Diseño de Roles
Si estás pensando en rediseñar los roles de SAP en tu empresa, en Inprosec somos especialistas en proyectos de diseño de roles, ayudando a optimizar el acceso a los sistemas y garantizar una correcta segregación de funciones. Nuestro equipo tiene la experiencia y el conocimiento necesario para acompañarte en cada fase del proyecto, desde la planificación hasta el despliegue, asegurando que todo funcione de manera eficiente y segura.
¡Contacta con nosotros aquí y conversemos sobre cómo podemos ayudarte!