domingo, 1 de junio de 2014

¿Qué es SAP Audit Information System (SAP AIS)? ¿Por qué los auditores no usan esta funcionalidad?

Algunos se preguntan ¿Qué es SAP AIS? sobre todo auditores que se ven enfrentados a tener que auditar procesos de negocio donde el sistema SAP ERP pasa a ser clave en el flujo de información o en los "Input, Process & Output" que fluyen en forma sistemática en esos procesos, pero para entender bien qué es realmente esta funcionalidad que posee el sistema SAP, a continuación les comentaré algunos tips y buenas noticias que de seguro les ayudará a comprender mejor esta funcionalidad.

SAP Audit Information System (en sus siglas en inglés AIS) es una funcionalidad  de auditoría que le permite evaluar los procesos implementados en SAP ERP, pudiendo ser utilizada con mucho énfasis en los procesos "BackOffice", es decir, procesos asociados a los módulos FI-CO-MM-SD-HR y procesos tecnológicos asociados al aplicativo que se implementan en el módulo BC (Basis Components) de SAP, por lo que puede ser utilizada tanto por auditores de sistemas como de procesos, debido a la  gran cantidad de variadas funcionalidades que ofrece, tales como para auditar:

Ámbito Auditoría de Sistemas ==>

- Configuración de bases de datos.
- Configuración de sistema operativo.
- Configuración de parámetros de seguridad de accesos.
- Rendimiento del sistema "performance".
- Procesos de fondo.
- Seguridad de roles y perfiles de usuario (incluida una herramienta de análisis de segregación de funciones SoD) a la cual se le puede incorporar reglas SoD.
- Monitoreo de ejecución de transacciones en línea e históricas.
- Activación de log de auditoría para el tracking de información de ciertos usuarios.
- Trace de seguridad de usuarios y autorizaciones.
- Auditoría de tablas y diccionario de datos.
- Auditoría a los programas ABAP y control de cambios (desarrollos Z).
- Etc...

Ámbito Auditoría de Procesos ==>

- Revisión de controles configurados o automáticos de los procesos de negocio. Ejemplo: límites de tolerancia en la gestión de stock de materiales o para desviaciones entre pedidos de compra y facturas de proveedor.
- Revisión de reportes de excepción relacionados con chequeos de consistencia de los flujos de información de procesos.
- Revisión de reportes de gastos y aprobaciones de los mismos.
- Revisión de movimientos de activos fijos.
- Revisión de ajustes de inventarios.
- Revisión de transacciones inusuales con indicios de fraude.
- Revisión de la segregación funcional de los privilegios otorgados a los usuarios de los procesos por medio de roles y perfiles.
- Revisión de ajustes de inventario y desviaciones del físico versus el teórico.
- Revisión de las propuestas de pago masivo a proveedores.
- Revisión de aspectos tributarios.
- Etc...

Estos ejemplos, representan algunas de las herramientas que SAP AIS le ofrece al auditor para que pueda desarrollar auditorías independientes y obtener la información desde la fuente de origen, pensando en el "escepticismo profesional" y en la mitigación de los riesgos de detección y auditoría.

Con la funcionalidad SAP AIS, los auditores podrán realizar auditorías tanto para la ejecución de pruebas de cumplimento o sustantivas en el ámbito de sistemas de información o de procesos de negocio.

Las ventajas que ofrece el uso de SAP AIS para los auditores:

- Funcionalidad es parte de SAP ERP, por lo que no se compra por separado.
- Podrá ser utilizado por auditores externos, internos (sistemas / procesos) y oficial de seguridad de la información CISO.
- El uso de SAP AIS no depende del área de sistemas de la empresa, por lo que el auditor podrá utilizarla y obtener información cuando quiera.
- Los reportes que posee SAP AIS son bastante intuitivos y con la misma interfaz gráfica de usuario que ofrece SAP ERP.  Salvo que se trate de reportes relativos al módulos BC que es tecnológico y el análisis e interpretación de los resultados debe ser revisado por un auditor de sistemas y/u oficial de seguridad de la información.

Algunas consideraciones importantes:

- SAP AIS si bien es una funcionalidad propia de SAP ERP, debe ser configurado por un equipo de especialistas con expertise en SAP AIS, antes de ser utilizado por los usuarios finales (auditores, seguridad de la información, etc.)
- Los usuarios finales de SAP AIS deben entrenarse antes de utilizar sus funcionalidades.
- Se debe acotar el uso de herramientas a utilizar y es recomendable partir por las más esenciales y poco a poco ir sumando otras más específicas. Esto en materia de ejecución de reportes estándar que ofrece SAP AIS.
- El área de TI también debe ser entrenada en SAP AIS, a fin de que pueda cubrir los requerimientos posterior a la configuración y go live (salida a productivo de SAP AIS)
- La ejecución de log de auditoría debe ser coordinado con las áreas de TI, a fin de definir un almacenamiento masivo de información de log práctico, certero y eventualmente apoyado con un dispositivo de almacenamiento externo.  
- No es recomendable hacer log masivos y se debe acotar con la ayuda de especialistas tecnológicos o especialistas en SAP AIS.
- Se debe auditar los ambientes Desarrollo, Prueba y Productivo, por lo que SAP AIS debe estar activado en los 3 ambientes de SAP ERP.
- La obtención masiva de información de tablas se debe hacer con mucho cuidado para no mermar el performance de SAP ERP. Se recomienda obtener información masiva en procesos de fondo. (Tablas con más de 100.000 registros)

Algunos auditores me han comentado que cuando le piden al área de TI la configuración de SAP AIS para ser utilizado en las auditorías de proceso o sistemas, por desconocimiento se le responde: "no se puede porque merma el performance, hay que comprar el módulo y no fue presupuestado, no es parte del alcance de la implementación SAP y no se puede usar, están prohibidos los log de auditoría, etc." Muchas de estas respuestas son por desconocimiento, ya que ni siquiera la gran mayoría de los implementadores de SAP ERP saben configurar SAP AIS o no saben de su existencia y es por eso que el uso que se le da a esta funcionalidad es muy limitado o nulo.

Por último, se debe tener presente que SAP AIS se complementa muy bien con las Computer-assisted audit techniques (en sus siglas en inglés CAATs) ACL, IDEA, ACCESS, etc., para la obtención de tablas que serán utilizadas para ejecución de pruebas sustantivas o analíticas y/o procedimientos de detección de fraudes, pero una no reemplaza a la otra. 


Para más información me pueden escribir a: pdhernandez@deloitte.com

miércoles, 1 de enero de 2014

6 lecciones aprendidas de implementaciones de reglas automáticas de monitoreo continuo en SAP GRC Process Control

Ya muchas empresas durante el 2013 ejecutaron proyectos de implementación de modelos de monitoreo continuo a través de la solución SAP GRC Access y/o Process Control.

En el caso de SAP GRC Access Control, este tipo de iniciativas han sido más sencillas, dado a la madurez del producto con sus reglas de segregación funcional (siglas en inglés SoD), las cuales generan conexiones con SAP ERP de forma mucho más natural y estable, pero tratándose de SAP GRC Process Control, la experiencia ha sido distinta y un tanto más compleja, es así como a partir de las vivencias en implementación de reglas de monitoreo continuo en SAP GRC Process Control, les comparto las siguientes lecciones aprendidas:

1.- Privilegios adecuados en ambiente de Desarrollo SAP GRC Process Control y SAP ERP.

Se debe contar con un mandante de Desarrollo SAP GRC Process Control y SAP ERP con privilegios adecuados para el diseño, construcción y pruebas unitarias de las reglas. El no contar con este requisito esencial, pone en serio riesgo el éxito del proyecto y el cumplimiento de las expectativas del mismo.

2.- Apoyo de equipo funcional SAP ERP.

Otros de los factores críticos de éxito tratándose de implementación de reglas automáticas de monitoreo continuo, es el involucramiento de los líderes funcionales o key users de los módulos SAP ERP a los que se les aplicará reglas, de lo contrario el diseño de estas reglas puede ponerse en riegos por el conocimiento funcional específico que se requiere de los modelos de datos de cada aplicación funcional de SAP ERP.  

El diseño y construcción de reglas requiere de mucho conocimiento del modelo de datos del módulo (bases de datos lógicas, tablas físicas, campos claves, etc.).

En algunos casos, es necesario crear ciertos controles automáticos que emanan de programas y tablas Z (desarrollos no estándar a la medida), ya que las reglas de control estándar que vienen con SAP GRC Process Control, eventualmente puede que no cubran  completamente la necesidad de monitoreo de la entidad y en ese caso, se hace necesario crear un control más ad hoc.

Nos podríamos preguntar. ¿Por qué debemos diseñar y construir reglas de controles para el monitoreo continuo con SAP GRC Process Control, si el producto las trae incorporadas de forma estándar?. La respuesta es, porque simplemente las reglas estándar no necesariamente cubren todas las necesidades de reglas de control que requieren las entidades y de ahí nace la necesidad de tener que crear reglas más acorde a los procesos de negocio.

3.- Conocimiento de los módulos funcionales de SAP ERP del equipo implementador y de la empresa donde se implementarán las reglas de control.

A lo menos se debe involucrar como parte del equipo de consultores, un especialista conocedor del módulo funcional donde se aplicarán las reglas, es decir, dentro de este equipo debe existir un grupo multidisciplinario entre consultores especialistas en SAP GRC Process Control y un especialista funcional del módulo SAP ERP que corresponda aplicarle reglas.

Es importante que el equipo multidisciplinario conozca de modelos de control interno y de esa forma se facilita de sobremanera el éxito de las reglas de control. 

Respecto a este punto, es importante saber que hay empresas que si cuentan con equipos de consultores funcionales internos (módulo FI, CO, MM, SD, etc.) y que conocen muy bien los atributos funcionales de estos, pero es factible encontrarse con empresas donde no necesariamente existirá este tipo de especialistas y eso implica un riesgo para el proyecto, salvo que este se mitigue con la incorporación de un consultor externo funcional y el conocimiento de los procesos de negocio se obtiene de los "key users", líderes funcionales o dueños de procesos de la entidad.

4.- Claridad en el diseño de los controles y el objetivo que se quiere cubrir sobre los procesos de negocio.

En algunas situaciones se tiende a diseñar controles que no necesariamente cubren lo que se desea controlar y este tipo de issues puede impactar en la relación del control con la regla SAP GRC  Process Control, por lo que es necesario validar con los dueños de proceso de forma exhaustiva el diseño y la relación de este con la regla de control automático que quedará asociada a SAP GRC Process Control.  

Recordemos que cuando los auditores internos o externos, auditen estos controles de procesos, lo harán sobre la base de validar en primera instancia el diseño de los mismos y si este es deficiente, estaremos frente a una debilidad de control que puede ser alta, media o baja (leve, material o significativa), dependiendo de que tan clave es el control y el proceso para la entidad.

5.- Conocimiento funcional especialista de SAP GRC Process Control.

Es factor relevante el hecho que los consultores asesores conozcan las funcionalidades de la solución SAP GRC Process Control en lo relativo a creación de frameworks, manejo de los workfkows, alertas, configuración de las reglas de controles automáticos estándar y cuatomizadas (Z). No basta involucrar a consultores especialistas en SAP GRC Access Control, ya que se trata de funcionalidades distintas y que apuntan a otros ámbitos distintos a los que cubre Access Control y en eso debe ser cuidadoso y el perfil de profesionales que debe involucrarse en proyectos de SAP GRC Process Control, es más relacionado con procesos de negocio de diversas industrias que tecnológico, por lo que es importante involucrar a profesionales con dichas skills y formar equipos multidisciplinarios.


6.- Diseñar escenarios de pruebas integrales de los controles automáticos y ejecución de las mismas en un ambiente de prueba (QAS).

La confección de escenarios de pruebas integrales y el hecho de ejecutar las mismas en un ambiente QAS, es de suma importancia en un proyecto de implementación de controles automáticos en SAP GRC Process Control y en algunas implementaciones me ha tocado ver, que ciertas empresas no contemplan un ambiente "QAS" de pruebas dado a que ven erróneamente que es un sistema que no lo requiere y en rigor si lo requiere alineado con buenas prácticas de control de cambios.

Lo otro, se debe contar con datos de prueba funcionales adecuados para verificar que las reglas de controles automáticos interactúan adecuadamente con el modelo transaccional funcional de SAP ERP, de lo contrario es factible que la información que arroja la regla, fracase y no cumpla el objetivo de mantener un adecuado monitoreo continuo de los controles claves de SAP ERP.

De no considerar estos factores críticos de éxito, es probable que su proyecto de implementación de reglas de controles automáticos en SAP GRC Process Control, no llegue a cubrir las expectativas deseadas y no sólo para SAP GRC Process Control, sino que para cualquier iniciativa de implementación de controles automáticos de monitoreo continuo, se deben tener estas consideraciones.