En una frase: determina dónde una sola persona puede ejecutar un proceso completo sin control cruzado.

Se conecta a su SAP en modo solo lectura y responde una pregunta de negocio: qué usuarios acumulan funciones incompatibles —crear un pedido y aprobarlo, dar de alta un proveedor y pagarle, mantener un maestro y contabilizar contra él—. Son las combinaciones que permiten que una sola persona cierre un circuito entero sin intervención de terceros.

No modifica nada. Analiza, concluye, y de cada caso informa tres puntos: quién lo tiene, por qué asignación se originó y qué corrección lo resuelve con el menor impacto operativo — porque casi siempre hay más de una forma de remediarlo y no todas cuestan lo mismo.

Trabaja sobre la última fotografía que se extrajo de su sistema, y la fecha de esa fotografía está siempre arriba, en la cabecera. Nada de lo que verá aquí es una estimación: todo sale de tablas que su equipo puede volver a consultar.

Dónde mira exactamente, y con qué tablas — para que su equipo pueda repetirlo a mano.

En la cadena de autorizaciones de siempre, recorrida como la recorre un auditor: parte de la persona y baja hasta el valor del campo, porque es ahí abajo donde se decide si dos funciones se pueden separar de verdad.

Todo sale de las tablas que usted consultaría en SUIM: AGR_USERS (quién tiene cada rol), AGR_TCODES (qué transacciones concede), AGR_1251 (con qué objetos y con qué valores) y USR02 (si esa persona entra al sistema). Y de nada más.

Tres cosas que se miran con cuidado porque son las que hacen fallar a una revisión hecha a mano: los roles compuestos, que esconden lo que conceden sus hijos; los rangos —un rol que da «de F110 a F199» concede transacciones que nadie escribió—; y los comodines en el valor de un campo, que es donde un permiso aparentemente acotado se vuelve total.

Un conflicto no nace en cualquier sitio: nace en un eslabón concreto, y ese eslabón decide cómo se arregla.

Por eso el riesgo tiene tres orígenes. Es la clasificación que verá en «Origen del riesgo» y la que ordena el plan de remediación, porque cada origen se corrige en un sitio distinto y con un costo distinto.

Y hay un segundo eje: permisos que son peligrosos ellos solos, sin necesidad de combinarse. Tener SAP_ALL, poder depurar con reemplazo de valores o cambiar la clave de otros usuarios ya es un hallazgo por sí mismo — son las autorizaciones críticas, medidas con el mismo catálogo que usa el EarlyWatch de SAP. Y una cuenta genérica o compartida, de la que nadie puede decir quién la usó, es un hallazgo aunque no tenga ningún conflicto.

Lo primero que se pregunta de cada hallazgo no es cuán grave es, sino si está vivo.

Es la división que ordena todo el trabajo y la primera cifra del Dashboard, porque cambia quién tiene que decidir y cuánto cuesta cerrarlo.

Un hallazgo expuesto no es un hallazgo menor: una cuenta sin uso con accesos vivos es justo la que se usa sin que nadie lo note, porque no hay actividad normal contra la cual comparar. Es más barata de contener, no menos importante.

Y «con candado» tampoco es «resuelto». Bloquear una cuenta o dejarle vencer la validez son las dos formas que tiene SAP de detenerla —lo que un Basis ve en USR02—, pero el rol sigue asignado y el conflicto sigue escrito. Retirar los roles es lo único que lo cierra del todo.

Y las unidades no se mezclan, porque los números no van a cuadrar si se confunden: un hallazgo es una persona × una combinación; el rol es el objeto que se corrige en PFCG; la cuenta es la persona, que se decide en SU01. Un rol produce conflictos en varias personas — por eso el número de roles y el de hallazgos no coinciden ni tienen por qué.

Pruebe el cambio antes de pedírselo a su equipo SAP.

Puede ensayar tres cosas: habilitar una transacción a alguien, asignar o retirar un rol, o copiar los accesos de otra persona —el caso típico de «que Gómez quede como Rivas» cuando alguien cambia de puesto—.

La simulación usa la última fotografía de auditoría: toma sus asignaciones, les aplica el cambio que usted plantea y vuelve a pasar el motor completo sobre el resultado. Después responde primero lo que usted quiere saber —si se puede o no— y solo entonces explica qué conflictos abre y cuáles cierra.

No cambia nada en SAP. Deja una constancia con su huella (SIM-…) para quien tenga que aprobar el cambio, y esa constancia dice contra qué datos se corrió y cuándo — así nadie aprueba sobre una simulación de la semana pasada.

Un límite que conviene saber antes: si un usuario de referencia ya arrastra conflictos, copiarlo se los pasa al otro. La pantalla marca esos casos con su semáforo, pero la decisión de copiarlo igualmente es suya.

A veces el negocio decide convivir con un riesgo. Eso también es una decisión, y queda escrita.

Un hallazgo no siempre se cierra arreglándolo. Hay casos donde separar las funciones no es posible hoy —una planta con dos personas en administración, un cierre de mes en marcha, un proyecto a medias—. La respuesta correcta ahí no es esconder el hallazgo: es aceptarlo por escrito y compensarlo.

Para registrar una excepción hacen falta seis cosas, y son obligatorias todas: el responsable que la asume, la vigencia —hasta cuándo—, el motivo, el control compensatorio que se ejecutará mientras tanto, su frecuencia y la evidencia que ese control debe dejar. Una excepción sin fecha de caducidad no es una excepción: es una renuncia.

El registro vive como Activo, Vencido o Cerrado, y el vencimiento se calcula solo contra la fecha de hoy. No se puede borrar desde la pantalla — cerrarlo conserva la historia, porque lo que un auditor pregunta no es qué excepciones tiene hoy, sino qué decidió y cuándo.

El menú separa ambos trabajos. En Políticas se consulta qué reglas producen los hallazgos y quién puede aprobar. En Remediación se trabaja el plan, los lotes pendientes y el registro de decisiones o excepciones.

El ciclo que un auditor externo pide: que un responsable revise y firme.

Una campaña toma la foto de las asignaciones de un alcance —un departamento, un módulo, un grupo de roles o una lista de personas elegida a mano— y le pide al responsable que decida, acceso por acceso.

Solo hay tres respuestas posibles: Mantener si el acceso sigue justificado, Revocar si debe retirarse, o Excepción si se conserva con una justificación explícita. Las dos últimas exigen motivo: nadie revoca ni salva un acceso sin decir por qué.

Cada decisión se firma en una bitácora encadenada, de modo que alterarla después rompe la cadena y se nota. Al cerrar la campaña —y no se puede cerrar con decisiones pendientes— se sella el acta y salen dos entregables: el certificado en PDF para el expediente y la lista de revocaciones para el equipo Basis.

Esa lista es una instrucción, no una ejecución: revocar no escribe en SAP. El retiro lo hace su administrador por sus canales de siempre, y así la revisión y el cambio quedan en manos distintas — que es justo lo que la recertificación existe para demostrar.

Lo que esta herramienta no hace, dicho antes de que usted lo descubra.

No cambia nada en su SAP. No crea ni borra usuarios, no asigna ni retira roles, no toca una autorización. Todo lo que usted decida aquí lo ejecuta su equipo allá, por sus canales controlados. La conexión es de solo lectura y esa es la promesa central del producto.

No decide por el negocio. Le dice que dos funciones no deberían convivir; qué función necesita cada cargo lo sabe su supervisor, no una herramienta. Por eso el plan propone y ordena, pero nunca da un caso por resuelto solo.

No rellena huecos. Cuando un dato no se pudo medir, lo dice con esas palabras en vez de mostrar un cero tranquilizador. Un cero mudo es la única forma que tendría este producto de mentirle, y preferimos una pantalla que reconoce lo que no sabe.

No demuestra qué rol autorizó una ejecución. SAP no lo registra: si dos roles conceden la misma transacción, lo honesto es decir que ambos la conceden, y eso es lo que verá.