SU56 SAP: cómo resetear el buffer de usuario
9 de julio de 2026
S_TABU_DIS en SAP: riesgos, limitaciones y uso de S_TABU_NAM
13 de agosto de 2026
Seguridad SAP · SoD · Gobierno de accesos · Roles SAP
¿Por qué fracasan los modelos de Segregación de Funciones en SAP?
Escrito por
José Luis Muñoz Palomo
Consultor Senior en APLIRH Consulting
La mayoría de las organizaciones entienden perfectamente el concepto de Segregación de Funciones, también conocida como SoD. Sin embargo, existe una diferencia importante entre comprender un riesgo y ser capaz de implantar un modelo sostenible que permita controlarlo.
Desde un punto de vista teórico, resulta fácil comprender que una misma persona no debería poder controlar de principio a fin un proceso crítico sin supervisión independiente.
Del mismo modo, resulta razonable evitar que un usuario pueda ejecutar actividades incompatibles que puedan facilitar errores, incumplimientos o situaciones de fraude.
Idea clave
La mayoría de los problemas no aparecen al definir la matriz de riesgos, sino cuando llega el momento de llevar esa teoría a la realidad operativa.
Nuestra experiencia en proyectos de gobierno de accesos, diseño de roles y segregación de funciones nos ha demostrado que la dificultad real suele aparecer cuando el modelo debe integrarse en el día a día de la organización.
De la teoría a la operación
Cuando el riesgo deja de ser teórico
Durante los talleres de definición de riesgos suele existir un elevado consenso. Es fácil aceptar que crear un proveedor y posteriormente realizar pagos sobre ese proveedor constituye un riesgo.
También resulta sencillo comprender que una misma persona no debería aprobar un pedido, registrar la recepción de mercancía y procesar posteriormente la factura correspondiente.
El problema aparece cuando estos riesgos deben materializarse técnicamente dentro de SAP
¿Qué transacciones deben formar realmente parte de cada proceso?
¿Qué ocurre cuando una transacción interviene en varios procesos distintos?
¿Qué usuarios necesitan realmente cada actividad?
Es habitual que riesgos ampliamente aceptados desde el punto de vista teórico comiencen a cuestionarse cuando afectan a la operativa diaria de determinados departamentos. No porque el riesgo no exista, sino porque las consecuencias de implantar los controles empiezan a ser visibles.
Fase de remediación
La resistencia al cambio no suele estar en Auditoría
En muchos proyectos se asume que la principal dificultad consiste en definir una matriz de riesgos adecuada. Sin embargo, en nuestra experiencia, el verdadero reto suele aparecer durante la fase de remediación.
Es relativamente sencillo acordar que determinados procesos son incompatibles. Es mucho más complejo decidir qué accesos deben retirarse, qué funciones deben redistribuirse y qué cambios organizativos son necesarios para adaptarse al nuevo modelo.
Preguntas legítimas que aparecen desde el negocio
La segregación de funciones no es únicamente un ejercicio técnico. Implica cambios en la forma de trabajar de las personas y, por tanto, requiere una adecuada gestión del cambio.
Error frecuente
Tener una matriz SoD no significa tener un modelo SoD
Uno de los errores más frecuentes consiste en considerar que el proyecto termina cuando se dispone de una matriz de riesgos validada.
La matriz constituye únicamente el punto de partida. Un modelo de segregación sostenible requiere además:
Roles alineados con procesos de negocio
Procedimientos de gestión de accesos
Controles sobre nuevas asignaciones
Gestión de excepciones
Revisión periódica de usuarios y autorizaciones
Procesos de aprobación claramente definidos
Gobierno continuo del modelo
Cuando alguno de estos elementos no existe, la matriz acaba convirtiéndose en un documento de auditoría con escasa aplicación práctica en el día a día.
Visión equivocada
El error de considerar SoD como un proyecto
Muchas organizaciones impulsan iniciativas de segregación de funciones como respuesta a una auditoría o a un proyecto de cumplimiento normativo.
Se analiza la situación actual. Se corrigen los conflictos detectados. Se rediseñan los roles. Y se da el proyecto por finalizado.
Pero una organización cambia constantemente
Se incorporan nuevos empleados, se crean nuevas sociedades, aparecen nuevos procesos, se implantan nuevas aplicaciones, se desarrollan transacciones específicas y se realizan adquisiciones o roll-outs internacionales.
Cada uno de estos cambios puede introducir nuevos riesgos si no existe un procedimiento que garantice la aplicación continua de los criterios SoD definidos.
Deterioro del modelo
Cuando los proyectos posteriores ignoran el modelo
Este es probablemente uno de los motivos de deterioro más habituales. Tras realizar un importante esfuerzo de reingeniería y limpieza de accesos, la organización inicia nuevos proyectos.
Con frecuencia, estos proyectos no incorporan las validaciones SoD establecidas durante la iniciativa original.
Como consecuencia, comienzan a aparecer nuevos conflictos que nunca fueron analizados. Con el tiempo, el modelo termina alejándose progresivamente de la situación diseñada inicialmente.
Revisión continua
La falta de mantenimiento de la matriz de riesgos
La matriz de riesgos tampoco es un elemento estático.
Una matriz que no se revisa periódicamente acaba perdiendo representatividad respecto a la realidad operativa de la compañía.
Riesgo principal
La organización cree estar controlando sus riesgos cuando en realidad está evaluando escenarios que ya no reflejan completamente su operación actual.
Comunicación y adopción
La importancia de la sociabilización del modelo
Otro aspecto frecuentemente infravalorado es la comunicación. Muchos proyectos finalizan con éxito desde un punto de vista técnico: los roles han sido redefinidos, los conflictos han sido analizados y las autorizaciones han sido ajustadas.
Sin embargo, los responsables de negocio desconocen cómo debe mantenerse el nuevo modelo.
No entienden los criterios utilizados para diseñar los roles
No conocen el procedimiento para solicitar nuevos accesos
No saben cuándo una excepción requiere validación
No comprenden las implicaciones de determinados riesgos
Cuando esto ocurre, el modelo comienza a degradarse desde el primer día. La sostenibilidad de un modelo SoD depende tanto de las personas como de la tecnología.
Control recurrente
La ausencia de revisiones periódicas
Un modelo de segregación no puede mantenerse únicamente mediante controles preventivos. También necesita mecanismos de revisión periódica.
Las recertificaciones de usuarios, roles y accesos permiten detectar situaciones que inevitablemente aparecen con el tiempo:
Usuarios que han cambiado de función
Accesos heredados de proyectos anteriores
Roles sin uso efectivo
Excepciones que ya no son necesarias
Riesgos aceptados que deben revisarse
Las organizaciones más maduras no son necesariamente las que tienen menos conflictos, sino aquellas que disponen de procesos recurrentes para identificar, revisar y gestionar dichos conflictos.
Conclusión
Los modelos SoD no suelen fracasar por la matriz, sino porque dejan de gobernarse
La mayoría de los modelos de segregación de funciones no fracasan por una mala matriz de riesgos ni por limitaciones de la herramienta utilizada.
Fracasan porque dejan de gobernarse.
La segregación de funciones no es un ejercicio puntual de auditoría ni un proyecto que termina con la puesta en producción de nuevos roles. Es una disciplina continua que requiere mantenimiento, revisión, adaptación al cambio y compromiso por parte de negocio, auditoría e IT.
Las organizaciones que entienden esta diferencia consiguen que su modelo siga aportando valor años después de la implantación. Las que no lo hacen terminan enfrentándose nuevamente a los mismos riesgos que intentaron resolver al inicio del proyecto.
Un modelo SoD sostenible no se implanta una vez: se gobierna de forma continua.
