Sistema de Auditoría
Cuando las empresas empiezan a tener un volumen considerable de movimientos, buscan tener el apoyo de sistema informáticos que les ayuden con el manejo de ese volumen y que les permitan realizar las tareas de manera más eficiente y ordenada.
La automatización de procesos nunca acaba, por el contrario, siempre hay necesidad de realizar mejoras en la automatización de proceso, y durante los mismos, surge una nueva necesidad, que consiste en poder monitorear y analizar los cambios que sufren los datos a través de los sistemas, requiriéndose conocer, por ejemplo, quién hizo que y cuando se hizo.
El módulo de auditoría fue desarrollado por PROINTEC con el fin de suplir esta necesidad, y desarrollado de tal manera que fácilmente se pueda responder a esas preguntas, así como, poderlo hacer de forma amigable y de fácil acceso para el usuario.
Este módulo es independiente del sistema que se encuentre en operación en la organización, pudiéndose integrar fácilmente con estos, para cumplir con la promesa de facilidad de uso y administración. Una vez instalado el modelo de datos y la aplicación, basta que a través del módulo se agregue la tabla que pertenezca al sistema que se quiera “auditar”.
Este producto ya está en la lista de solicitar cotización
Más información
Una vez que se agrega al módulo la tabla por auditar, solo resta indicar que se quiere llevar auditoría de cambios a la tabla, aplicar el “agente” (trigger) que realiza el monitoreo y registro de cambios, y eso es todo. El módulo divide el concepto de auditoría en tres tipos que son: 1. Auditoría general de datos: Este es el esquema más simple, ya que simplemente se carga una tabla y “listo”, sin embargo, con este, se puede indicar si se quiere auditar los “insert”, “update” o “delete”, y en el caso del update se puede indicar que columnas se quieren auditar. Tomando en consideración que, aunque estén seleccionas todas las columnas de la tabla, el módulo solo registra las columnas que sufrieron cambios. 2. Bitácora: Esta modalidad lo que permite es auditar cambios de estados de manera muy especial, conociendo detalles del funcionamiento de la solución. Por ejemplo, en Cuentas por Pagar del CODISA-NAF, hay un campo para bloqueo de pago con el respectivo motivo, sin embargo, se puede desbloquear y volver a bloquear tantas veces que se quiera. A través de este mecanismo, y con un poquito de programación en el módulo de auditoria, se puede registrar cada bloqueo y desbloqueo, de manera que se puede tener el registro de quién y cuándo lo hicieron, así como el motivo de cada bloqueo realizado. 3. Bitácora de procesos: Esta modalidad permite mostrar quién y cuándo se ejecutó un proceso del sistema transaccional. Para esto la solución provee un procedimiento para que el programar del transaccional lo llame y se registre esa acción. Por ejemplo, Cierres mensuales, Cálculos de diferencial cambiario, y otros similares. Lo anterior es lo que el módulo permite auditar, sin embargo, es conveniente mencionar otras características importantes y claves también, como son: • Permite llevar auditoria de cambios de datos sobre la metada del sistema. • Provee una opción para cargar del diccionario de la base de datos, las tablas que se quieran auditar. • Si en el quehacer diario un programador desactiva el trigger de auditoria a nivel de base de datos, procesos automáticos que provee el módulo, lo reactivaran a la hora en que esos procesos automáticos se ejecuten. • Se propone que el acceso a la auditoría y bitácora sea a través de botones desde el toolbar o botones que se habiliten en las pantallas de consultas del sistema transaccional, permitiendo tener siempre a mano la información requerida. • El módulo permite inactivar temporalmente y hasta “permanente” la auditoria. (Estas acciones quedan registradas en la auditoria del sistema). • Posee una función de limpieza automática de auditoría antigua. La cantidad de años de historia que debe mantener el módulo es configurable por el usuario. • Aunque va en contra del objetivo de auditoria, se estableció como premisa de que cualquier error que se presente durante el registro de auditoría de datos y bitácora, no interrumpa la operatividad del transaccional, por lo que se deja que el sistema siga. Lo que se hace es registrar en un “log” la falla.
