Cuando nada más ayude: Reinicie

Los resultados son cruciales a la hora de rediseñar un concepto de autorización. Se clasifican en distintos niveles de riesgo. A su vez, también es relevante la rapidez con que pueden eliminarse los riesgos.

Un ejemplo de defecto son los parámetros del sistema que no tienen la configuración correcta. El informe RSPARAM muestra los parámetros del sistema. Aquí se pueden mostrar ajustes como el registro general del sistema, que generalmente debe estar activado, ya que de lo contrario se violarán las leyes (alto riesgo, pero se puede rectificar rápidamente).

También se pueden comprobar allí los ajustes relativos a la longitud y complejidad de las contraseñas o al control de los usuarios estándar de SAP y corregirlos en caso necesario.

Otro ejemplo son las autorizaciones asignadas. Aquí también podemos encontrar autorizaciones críticas asociadas a un riesgo elevado. Por ejemplo, el objeto de autorización S_SCD0 con la actividad 06.

Este objeto de autorización puede utilizarse para borrar documentos de modificación (prohibición de borrado). Esto infringiría el HGB en un sistema relevante desde el punto de vista financiero.

¿Qué es lo realmente crítico?

La evaluación del riesgo de las autorizaciones asignadas depende de muchos factores. Un factor son, por supuesto, las autorizaciones jurídicamente críticas, como se muestra en el ejemplo anterior.

Estas cuestiones de autorización son relativamente fáciles de asignar a un nivel de riesgo. Sin embargo, también hay riesgos que dependen de la empresa. En este caso, debe analizarse de antemano exactamente dónde existen datos de la empresa relevantes para el riesgo.

Por ejemplo, un banco que realiza sus operaciones bancarias fuera de SAP y sólo encamina sus flujos de caja internos a través de SAP no considera que el sistema financiero interno sea tan crítico. Otro ejemplo sería una empresa química que almacena sus recetas en SAP.

Esta empresa lo consideraría muy crítico y, por tanto, lo clasificaría como riesgo muy alto. Por tanto, los riesgos deben definirse en función de cada empresa.

Catálogo de riesgos específicos de la empresa

El esfuerzo necesario para rectificar los problemas de autorización detectados puede ser muy elevado en determinadas circunstancias. Esto suele estar relacionado con la estructura de la autorización.

Resulta difícil, por ejemplo, si los roles de autorización se han establecido de forma demasiado gruesa o demasiado granular. También se producen incoherencias si no se respeta sistemáticamente un concepto de autorización definido.

Es necesario que los expertos realicen un análisis preliminar detallado para determinar si pueden corregirse las deficiencias e incoherencias del actual sistema de autorización o si sería mejor crearlo desde cero.

La pregunta entonces es: ¿son mayores el tiempo y los costes de una corrección que de un rediseño del sistema?

Etapas del rediseño

Un rediseño requiere un alto nivel de compromiso por parte de los empleados. En particular, los administradores de autorizaciones y el departamento especializado están muy implicados. Esto supone una gran carga de trabajo adicional para los empleados, además de su trabajo cotidiano.

A menudo también se recurre a empresas externas, lo que supone costes adicionales para un proyecto de este tipo. Si es necesario rediseñar el concepto de autorización, los costes deben reducirse al mínimo.

Para ello, examinamos cómo puede llevarse a cabo el rediseño, qué riesgos entraña y qué herramientas de SAP on-board pueden utilizarse. Los programas informáticos especializados pueden complementar las herramientas integradas de SAP en muchos puntos o automatizar por completo algunos pasos del proceso.

Esto puede reducir aún más el esfuerzo necesario. Debería estudiarse la posibilidad de utilizar este tipo de software.

Primer paso:

Como parte de un rediseño de la autorización, primero debe examinar detenidamente la documentación existente para cualquier concepto de autorización existente y completarla si es necesario.

Esta documentación también debe definir las convenciones de nomenclatura, la administración de usuarios (por ejemplo, bajas por maternidad) y la creación de funciones mediante el generador de perfiles, por ejemplo.

El mayor reto a la hora de crear un concepto de autorización es sopesar las opciones: Por un lado, deben incluirse todos los puntos importantes. Por otro lado, los puntos que cambian con frecuencia no deben escribirse con demasiado detalle.

Segundo paso:

El siguiente paso es realizar una comprobación de autorización en los sistemas. Lamentablemente, esto sólo es posible de forma muy limitada con las herramientas integradas de SAP. Esto se debe a restricciones técnicas y a informes estándar propensos a errores.

Paso 3:

A continuación viene la fase de implementación, en la que tres preguntas son decisivas: ¿QUÉ tiene que hacer un usuario en el sistema SAP, CÓMO tiene que hacerlo y DÓNDE tiene que hacerlo?

El "qué" suele asignarse a través de la transacción. El "cómo" se regula mediante los valores de campo correspondientes (por ejemplo, actividades de "Lectura" o "Modificación").

El "dónde" se controla a través de las denominadas unidades organizativas. Es decir, la sociedad en la que deben efectuarse las contabilizaciones. La pregunta de qué puede hacer un usuario, es decir, qué operación necesita, puede responderse con un análisis del puesto de trabajo.

Esto significa que usted se sienta con cada empleado de la empresa y repasa las transacciones individuales que el usuario necesita y toma nota de ellas.

Se trata de un proceso que lleva mucho tiempo. Para acelerarlo, puede utilizar la información disponible en el sistema. Para ello existen tres métodos principales:

1. a través de la transacción ST03N. En este punto, el sistema registra qué transacción ha sido llamada por qué usuario. En la mayoría de los casos, la información está disponible desde los últimos tres meses en el sistema SAP.

Consejo: El plazo puede ampliarse a unos 14 meses. De este modo, las operaciones también se tienen en cuenta para los estados financieros anuales.

2. los favoritos creados por el usuario también pueden utilizarse para análisis posteriores. Las transacciones Z* o Y* poco utilizadas que no se muestran en el análisis ST03 suelen almacenarse aquí. Los favoritos pueden leerse de forma centralizada a través de una tabla. Tabla: SMEN_BUFFC

3. transacciones que un usuario tenía en sus antiguos roles (tabla AGR_1251 y tabla AGR_USERS). Esta información también puede utilizarse. Sin embargo, hay que tener en cuenta que los roles antiguos suelen contener demasiadas transacciones.

Una vez determinada y analizada esta información sobre todos los usuarios a partir del sistema, hay que filtrarla y evaluarla. El riesgo es que la información se olvide o se malinterprete.

El uso de un producto de software adicional puede ser muy útil en este punto. Una vez hecho esto para todos los usuarios y departamentos, puede empezar a estructurar las funciones de autorización correspondientes en función de las subtareas de los departamentos y añadir las transacciones asociadas.

Hay que asegurarse de que las funciones se asignan posteriormente a personas responsables (propietarios de los datos). Por ello, las funciones de autorización deben ser lo más independientes posible de los módulos.

Uno de los mayores retos es determinar qué tareas deben realizar los distintos departamentos fuera de su ámbito de responsabilidad.

El área de responsabilidad se refiere aquí al módulo SAP. Por ejemplo, los empleados de finanzas trabajan tanto en un módulo COM como en un módulo HCM.

Tras este paso del proyecto, se crearon todos los roles en relación con las áreas especializadas correspondientes con las transacciones. En el siguiente paso, deben definirse las funciones creadas.

Hay que aclarar el cómo y el dónde. También en este caso el departamento especializado está muy implicado y hay varias opciones para definir las funciones creadas.

Una opción es aprovechar la experiencia de los empleados de los departamentos especializados y definir las funciones en consecuencia. Sin embargo, como la definición de las funciones suele ser muy técnica, enseguida se llega al límite.

La siguiente opción es utilizar la información de seguimiento (ST01) que se genera en el sistema SAP. Tras la activación, los resultados pueden leerse y utilizarse para la caracterización de funciones. Sin embargo, se considera que esta opción requiere mucho tiempo.

Dado que para definir las funciones se requiere mucha experiencia y que las herramientas estándar sólo son de ayuda limitada, la experiencia demuestra que en la mayoría de los casos las funciones se definen con demasiados derechos.

El área de controlling plantea un reto particular. Las empresas suelen tener varios centenares de centros de costes que deben separarse por funciones organizativas.

Riesgo: funciones con derechos excesivos

El resultado de la caracterización manual de roles suele ser incompleto e impreciso. Punto importante para la caracterización de roles: En ningún caso debe omitirse el mantenimiento SU24 al definir los valores de los campos.

SU24 se utiliza para establecer los valores por defecto del generador de perfiles (PFCG). Un SU24 correctamente mantenido simplifica y acelera considerablemente la posterior administración de las funciones de autorización.

Esto también aumenta la calidad de las funciones de autorización. Por tanto, este paso debería considerarse en cualquier caso. Sin embargo, el esfuerzo manual que supone es tan elevado que debería utilizarse software especializado.

Calidad y seguridad gracias a los cuidados SU24

Como último paso antes de la puesta en marcha, hay que realizar una prueba intensiva de las funciones. Todo el escenario de la prueba debe planificarse al detalle y ser supervisado por los miembros del proyecto.

Para ello, deben crearse previamente protocolos de prueba que sirvan de guía al empleado y le permitan registrar los resultados. Los resultados de las pruebas deben ser aplicados sin demora por el administrador autorizado.

Una vez corregidos los resultados de las pruebas iniciales, se realizan nuevas pruebas. Este proceso debe llevarse a cabo hasta que no haya más errores de autorización.

También debe realizarse una prueba negativa. En ella se comprueba si los usuarios pueden hacer algo que en realidad no deberían hacer. Por ejemplo, inscribirse en otra sociedad.

A menudo no se realiza esta prueba negativa. Por lo tanto, existe el riesgo de que las funciones con autorizaciones excesivas no se reconozcan y no se ajusten.

Una vez completado el tedioso y laborioso escenario de prueba, las funciones pueden trasladarse al sistema de producción y asignarse a cada usuario.

Antes de poner en marcha un nuevo concepto de autorización, también debe disponerse aquí de una planificación detallada. No se recomienda convertir a todos los usuarios al mismo tiempo.

Se recomienda convertir a uno o dos usuarios de cada área. Esto permite ver si no se han tenido en cuenta todos los pasos en la prueba previa y si esto podría dar lugar a problemas de autorización. Debe planificarse o mapearse un "escenario alternativo" (el usuario recupera su antiguo rol) utilizando un software especial.

Tres o cuatro meses después de la finalización del proyecto, las antiguas funciones de autorización pueden eliminarse del sistema.

El requisito previo es, por supuesto, que las nuevas funciones sean funcionales. Por último, cabe señalar que deben respetarse los procesos definidos previamente en el concepto. Sólo así podrá mantenerse el nuevo concepto de autorización, que se ha desarrollado con tanto esmero.

Conclusión: Si existen graves deficiencias en un concepto de autorización de SAP, un rediseño suele ser la solución más eficaz. Sin embargo, el rediseño requiere mucho tiempo y es arriesgado.

Los programas informáticos especializados pueden ayudar a minimizar el esfuerzo y los riesgos. El resultado es una mayor calidad y menores costes. El software especializado también puede utilizarse para controlar y apoyar la actividad diaria.

Consejo 1

Hay casos en los que puede ser necesario rediseñar completamente un concepto de autorización porque una "rápida puesta en orden" sólo mejora la situación a corto plazo.

Consejo 2

Si el nivel de detalle de los conceptos de autorización es demasiado alto, se requiere una gran cantidad de trabajo de mantenimiento. Las soluciones informáticas pueden ayudar en este sentido.

Consejo 3

Tanto el mantenimiento de los conceptos de autorización como la comprobación pueden realizarse mediante programas informáticos especiales.

Consejo 4

Cree periódicamente una descarga masiva de los roles modificados. Esto le permitirá acceder a una versión anterior de los roles en cualquier momento. Ocurre de vez en cuando que los cambios de roles que llevan mucho tiempo se sobrescriben en caliente.

Consejo 5

Existe el riesgo de que los empleados se vean gravemente perjudicados en su trabajo diario debido a la falta de autorizaciones.

Consejo 6

Al utilizar el software adecuado, es importante asegurarse de que se basa en funciones estándar de SAP, para que las empresas no dependan de soluciones especiales que imposibiliten el mantenimiento manual de las autorizaciones.