Dentro del sistema SAP existen varias posibilidades para poder revisar los cambios realizados sobre información crítica o sensible, como, por ejemplo, maestro de proveedores, maestro de clientes, cuentas contables, bancos. Dichos cambios se clasifican en las siguientes categorías: “Change Documents” y “Change Logs”.
Las principales características son:
- “Change Documents”. Están activos en el sistema por defecto. Para que una modificación en un campo se refleje en “change documents” es necesario que se cumpla lo siguiente:
-
- El campo debe estar asociado a un “Data Element” que previamente haya sido marcado para escribir en “change documents”.
- El campo debe estar asociado a una tabla con un objeto “change documents”.
- La transacción/programa tiene que estar preparado, a nivel de código, para almacenar los documentos de cambio sobre los campos críticos. Pueden existir transacciones Z que no registren estos cambios tal y como lo haría una transacción estándar. Desde la transacción SCDO se realiza la generación del código que será necesario incluir en el programa para que registre los cambios en campos críticos.
- “Change Logs”. Los “Change Logs” están desactivados por defecto. Para que una modificación en una determinada tabla se refleje, se ha de activar, en primer lugar, el parámetro “rec/client” y, posteriormente, se han de definir aquellas tablas en las que se quiera registrar un histórico de cambios. Las activaciones de “Log” en una tabla se pueden realizar a partir de la transacción “SE13”. Esta funcionalidad almacena cualquier tipo de cambio en cualquier campo de una misma tabla, independientemente de qué transacción o programa realiza el cambio.
Una vez que hemos introducido las características de cada uno de los tipos de logs, vamos a ver en qué tablas se guardan cada uno:
- Los Change Documents se revisan, generalmente, a partir de dos tablas:
-
- CDHDR: Tabla resumen (cabecera) de los “change documents”. Se indica información general sobre cierto cambio (usuario que realiza el cambio, fecha, hora y transacción desde la que se realizó el cambio).
- CDPOS: Tabla que contiene el detalle de los “change documents”. Se indica el cambio realizado (Se indicar el valor anterior y nuevo de cada uno de los campos modificados, pudiendo filtrar a nivel de tabla y campo específico).
- La información de los “Change Logs” se revisa a partir de:
- Tabla DBTABLOG: Tabla que contiene directamente el cambio realizado en las tablas marcadas como “Log”. En algunos casos la interpretación directa del cambio a través de esta tabla es complejo. Permite filtrar a nivel de transacción con la que se ha realizado el cambio.
- Transacción SCU3: Transacción que interpreta los cambios que aparecen en la DBTABLOG. Muestra de manera más directa el cambio sin tener la necesidad de interpretarlo. De manera contraria a la tabla DBTABLOG, la transacción SCU3 no permite filtrar a nivel de transacción.
Automatización en SAP GRC Process Control
SAP GRC Process Control contiene todos los elementos para documentar y gestionar un Sistema de Control Interno, independiente del sistema en el que los procesos clave de negocio estén ubicados.
Nos permite automatizar gran parte de las actividades. Una de ellas es el monitoreo continuo a través de controles automáticos (CCM), que ayuda a asegurar que los diferentes procesos de negocio se mantienen fieles al diseño inicial.
Por ejemplo, Continuous Control Monitoring (CCM) nos permite monitorizar si una cuenta bancaria de un proveedor ha sido modificada y, en caso afirmativo, por quién y cuándo. Estos datos se encuentran en diferentes tablas en las que es preciso revisar los cambios que se han llevado a cabo en los campos críticos a través de, entre otros, “Change Logs” o “Change Documents”. CCM genera un informe con todas las cambios que se han llevado a cabo para que, a partir de dicho informe, un usuario capacitado pueda determinar si los cambios críticos son legítimos (han sido aprobado previamente) o no.
Las principales diferencias para utilizar una u otra tecnología a la hora de construir un control automático, se resumen en el siguiente cuadro:
En resumen, la gran ventaja que tiene construir un control automático basado en cambios a partir de “Change Documents” es que la capacidad de implementar una determinada lógica es muy amplia y, por tanto, permite conseguir un control mucho más eficiente que por “Change Log”. Sin embargo, antes de construir un control basado en “Change Documents”, es muy importante garantizar que todos los cambios realizados en los campos críticas quedan registrados.