Diseño de roles en SAP: de las normas a la realidad del negocio
20 de noviembre de 2025
Proyectos SoD en SAP: desafíos, riesgos y claves para abordar con éxito (desde nuestra experiencia)
Autor: Victor Morales García
Cargo: PMO
Fecha: Diciembre 2025
Cargo: PMO
Fecha: Diciembre 2025
La segregación de funciones (SoD) en SAP es mucho más que un requisito técnico o una recomendación de auditoría. En APLIRH entendemos estos proyectos como una iniciativa de gobernanza corporativa cuyo objetivo es proteger es un mecanismo de control que protege a la organización frente a fraudes, errores y sanciones regulatorias, a la vez que permite aliviar el esfuerzo su gestión una vez llevado a cabo.
El éxito no depende de cómo se configuren los roles en SAP, sino de la capacidad de la organización para entender sus riesgos, decidir y validar un modelo que equilibre seguridad y operatividad. Y es precisamente en ese punto, donde pueden aparecer múltiples desafíos que, si no son gestionados adecuadamente, pueden comprometer su éxito.
¿Con qué desafíos es habitual lidiar con este tipo de proyectos?
La mayor parte de las organizaciones anticipa dificultades técnicas. La realidad es distinta: lo técnico, dentro de su dificultad, es lo más sencillo de solventar; lo complejo está en la coordinación, la toma de decisiones y la gestión del cambio.
1
SAP es un ecosistema complejo
La gran cantidad de módulos, transacciones y autorizaciones hace que la definición de accesos se convierta en un reto. El problema aparece cuando la complejidad del negocio no está clara, documentada ni consensuada.
2
Es un proyecto multidisplinar
Que requiere una coordinación entre distintas áreas: IT, auditoría y negocio, cada una con intereses enfrentados u opuestos.
3
Encontrar el equilibrio entre seguridad vs operatividad
(el enfrentamiento perpetuo entre auditoría y negocio) Que en muchos casos requiere de soluciones de compromiso: restringir demasiado los accesos puede ralentizar los procesos; ser demasiado permisivo abre la puerta a riesgos. El objetivo no es alcanzar riesgo cero, imposible e ineficiente, sino definir qué riesgos se aceptan, cuáles se mitigan y cuáles deben eliminarse.
4
Existe una resistencia al cambio
Los usuarios finales pueden percibir la segregación como una limitación en su trabajo diario.
5
Uno de los mayores obstáculos, sino el mayor, es la ausencia o incapacidad de decisión
Más allá de la complejidad técnica, la principal barrera para el éxito de estos proyectos radica en la resistencia interna a decidir, lo que genera bloqueos y traslada la responsabilidad al proyecto en lugar de asumirla como parte de la gobernanza. Sin decisiones internas, el proyecto pasa de ser un desafío a un imposible.
¿Cuáles son los principales riesgos?
Estas carencias se manifiestan fundamentalmente en varios puntos del proyecto
- La falta de validación de la matriz de riesgos (en los casos en los que su construcción se incluya en el alcance del proyecto), que aboca a una ausencia de entendimiento de los riesgos que se acepta que apliquen la organización, y que además condicionan la construcción del nuevo modelo de autorizaciones.
- La falta de validación del modelo de autorizaciones, cuyo resultado conduce a un modelo que la organización no reconoce como propio y que, por tanto, no le es útil.
1
Una reducida implicación de los Key Users (usuarios clave): Es necesario contar con su implicación para que puedan ofrecer claridad sobre los procesos propios, y ayudar en la validación del modelo.
2
Falta de patrocinio interno: Sin un patrocinio fuerte, el proyecto pierde impulso para ejecutar los cambios, además de dificultar el cumplimiento de objetos y la toma de decisiones. Sin el apoyo adecuado, el proyecto se convierte en un ejercicio técnico sin impacto real.
3
La delegación excesiva de decisiones al equipo técnico: decisiones clave que debería tomar la propia organización (algunas mencionadas anteriormente) se “fían” al equipo de proyecto. El equipo técnico puede plantear alternativas, pero nunca tendrá la visión completa de los procesos y procedimientos internos, así como de la realidad de la organización
4
Poca permisividad sobre riesgos de usuarios: Es complicado evitar que algunos usuarios mantengan permisos con riesgos. Para esos casos, se recomienda establecer procedimientos de aprobación y controles mitigantes, marcando unos objetivos de mejora de riesgos razonable que permita realizar estos cambios de manera progresiva sin suponer una paralización o ralentización del proyecto.
5
Tiempos de implementación insuficientes: Si se es exigente con los riesgos y, además, se pretende realizar el cambio de roles de los usuarios a un ritmo excesivamente rápido, el posible volumen de incidencias crecerá exponencialmente, dificultando la capacidad de su gestión, y poniendo en riesgo el resultado y la percepción del proyecto. Se debe establecer un calendario de cambio de roles secuencial y escalonado, teniendo en cuenta la calidad y el resultado de las pruebas realizadas en ambientes preproductivos.
6
Pruebas del modelo: Se debe probar de forma realista todas las autorizaciones que involucren a un proceso de negocio. Por seguridad, en la construcción de roles se utiliza el criterio de mínimo privilegio, siendo ampliado según las necesidades que surjan como resultado de las pruebas.
¿Qué factores son determinantes para el éxito de un proyecto SoD en SAP?
Otras consideraciones
Dependiendo del nivel de madurez de la organización en términos de gobernanza, criterios de riesgo y capacidad de toma de decisiones, no siempre es recomendable abordar un rediseño completo del modelo de roles desde cero totalmente alineado con la matriz de riesgos, que implica, en última instancia, decisiones sobre la forma de trabajar de los usuarios. Por ello, desde APLIRH apoyamos con alternativas intermedias que reducen la carga de intervención de los Key Users y disminuyen significativamente la necesidad de tomar decisiones complejas.
Ofrecemos enfoques basados en el análisis del uso transaccional real, que permiten remediar y optimizar el modelo existente de manera automatizada y no intrusiva, reduciendo riesgos sin necesidad de modificar la forma de trabajar de los usuarios.
Estas soluciones no buscan riesgo cero, pero sí proporcionan una mejora inmediata del cumplimiento, una reducción del volumen de conflictos SoD, una reordenación del modelo que permita disminuyendo disminuir el esfuerzo de validación y una transición más suave hacia un modelo más maduro
Conclusiones
Aunque un proyecto de segregación de funciones (SoD) en SAP venga motivado en muchos casos por requerimiento de auditoría, este tipo de proyectos debe considerarse como una oportunidad para fortalecer la seguridad, mejorar la eficiencia en gestión de autorizaciones y simplificar su mantenimiento, tanto desde un punto de vista técnico como de gobernanza.
Al final, se trata de encontrar un equilibrio en el modelo de autorizaciones donde se consiga una reducción de riesgos evidente, al mismo tiempo que sea lo suficientemente flexible y sencillo para su gestión y mantenimiento, siendo reconocible para la organización. Los proyectos SoD no fracasan por la dificultad técnica del sistema, sino por la falta de compromiso interno para decidir y validar.
La metodología APLIRH y sus herramientas ponen el foco precisamente en eso: decisiones, gobernanza y sostenibilidad, porque la técnica solo funciona cuando la organización asume su papel en el modelo.Por ello, ofrecemos alternativas intermedias, igualmente válidas y más realistas en muchos escenarios, que permiten avanzar de manera progresiva sin modificar la operativa diaria de los usuarios ni requerir un volumen elevado de decisiones.
La clave es entender que no existe el “modelo perfecto”, sino “el modelo más adecuado” para cada organización.
