Primera parte http://www.auditool.org/blog/auditoria-interna/267-matrices-de-control-buenas-practicas-parte-i
Continuamos con la segunda entrega de este tema.
Muy bien, seguimos con la segunda entrega referente al armado de matrices de control. Hasta ahora volcamos en nuestra incipiente planilla, los siguientes datos:
- Proceso
- Subprocesos
- Objetivo de Control
- Actividades de Control
- Riesgo mitigado
Seguiremos sumando columna a nuestra “criatura” para hacerla lo mas completa posible, por lo cual el siguiente punto a incluir sería:
- EVIDENCIA: Más allá que nuestra actividad de control lo detalle es necesario dejar explicito TODOS los documentos que servirán como evidencia del control ejecutado. Contar con este dato es muy importante ya que, pensando en el período de testing, el requerimiento de información a los usuarios será realmente sencillo porque sabremos exactamente que pedir sin entrar en confusiones o malentendidos.
Vamos con el ejemplo. Si mi actividad de control dijera que
“Mensualmente, el Analista de Compras emite un reporte con las altas y modificaciones del periodo registradas en el sistema a través de la transacción XXX cruzando el mismo vs. los formularios de Alta/Modificacion de proveedores a los fines de controlar la exactitud de los datos ingresados.
Se guarda copia del mismo (indicando fecha, firma y aclaración del comprador, el Jefe de Abastecimientos y Jefe de Finanzas) como evidencia del control realizado.”
Nuestra columna “EVIDENCIA” debería decir: “Reportes mensuales emitidos por el Departamento de Compras debidamente firmado por personal autorizado” 
- PROCEDIMIENTO RELACIONADO: Como lo dice su nombre, toda actividad de control debería estar incorporada a un procedimiento operativo, y éste haber sido circularizado al personal del sector y áreas relacionadas. Es una buena práctica incluir entonces el procedimiento relacionado y efectuar un control “cruzado” a fin de verificar si ambos documentos (Matriz y Procedimiento) se encuentran alineados o han sufrido modificaciones uno que el otro no refleja.
- TIPO DE CONTROL: Bueno señores, acá empezamos con los (necesarios) tecnicismos. Y debemos definir si nuestro control, por ejemplo es del tipo AUTOMÁTICO O MANUAL.
¿Y por que es necesaria esta clasificación?
Entre otras cosas, para definir la muestra del mismo al momento de su testeo. Un control automático (en la medida que se den por satisfechos otros supuestos) se entiende que funciona bien “en todo su ciclo de vida” por lo cual alcanza y podemos descansar en su efectividad solamente con ser probado UNA VEZ.
Ahora bien. Si nuestro control es manual, ya es necesaria una muestra de X casos para evaluar su efectividad, y el número de casos a testear dependerá del UNIVERSO (lo veremos mas adelante).
Resumimos entonces que un control es automático si no depende de la “discrecionalidad” de una persona, por lo cual un conjunto de instrucciones lógicas ejecutadas por un software se encargan de su ejecución.
Por complemento, un control es manual si es ejecutado por una persona y, por lo tanto, depende de ella para ser llevado a cabo.
ACLARACIÓN: No confundir un control “per se” con la herramienta para llevarlo a cabo. En el ejemplo citado anteriormente vimos que el Analista de Compras efectúa un control de monitoreo mensual sobre las actualizaciones efectuadas al maestro de proveedores. Si bien el reporte es emitido en forma AUTOMATICA por el sistema de gestión X el control en si mismo es la revisión por parte del Analista y la verificación de sus superiores, pro lo tanto el CONTROL ES MANUAL (aunque apoyado en un listado automático).
- IF AUTOMATED: ¿Qué pasa si nuestro control es automático? Es necesario recabar ciertos datos de la plataforma tecnológica que lo soporta, para asi ejecutar previamente con los controles de IT pertinentes y avanzar entonces con nuestra auditoria en los controles de la aplicación.
Los datos mínimos que recabaremos en el caso de un control automático serían:
a) Aplicación: Ejemplo SAP/ORACLE FINANCIAL/JD EDWARDS/ etc.
b) Plataforma: Sistema Operativo y Versión sobre el cual corre la aplicación, también el motor y versión de Base de Datos.
c) Ubicación Fisica: Del servidor que contiene la aplicación detallada en A)
d) Transacción: En caso de grandes sistema ERP (ej SAP) las actividades operativas son desarrolladas por medio de transacciones. Ejemplo: Una recepción de mercadería se registra en SAP a través de la transacción “MIGO”. Esto es de gran ayuda para el auditor ya que al momento de ejecutar el “testing” sabrá que el usuario debe tipear MIGO en su estación de trabajo y no “entrar” a través de otra transacción (y si es así, el auditor atento toma nota en su block)
e) Inherente? (SI/NO): Otro detalle no menos importante es saber si nuestro control automático es inherente o “customizado”. ¡Que significa esto? Fácil, un control es inherente si el mismo ya se encuentra “embebido” en la aplicación por lo cual su funcionamiento sabemos ya esta literalmente confirmado.
Por otro lado un control es “customizado” cuando la compañía decidió desarrollar por sus propios medios o bien configuró manualmente, alguna actividad de control que el sistema de gestión “por defecto” no trae activo. De más esta decir que en aquí deberemos prestar mayor detalle que en el primer caso.
- DISPARADOR (O TRIGGER): ¿Que es lo que “dispara” nuestro control? ¿Es un evento? ¿O es una frecuencia preestablecida?
Deberemos responder esta pregunta, y nuevamente lo hacemos pensando en el paso siguiente a la definición de controles que es su testeo. Al saber que es lo que dispara nuestro evento estaremos en condiciones de delimitar nuestro UNIVERSO para luego seleccionar una MUESTRA y hecho esto efectuar nuestras tareas de auditoria sobre los casos seleccionados.
Esta columna a su vez alimentara otras dos columnas de nuestra planilla donde indicaremos, si el disparador es un evento, cual es éste, y si es una fecha, su frecuencia.
Siguiendo con “Mensualmente, el Analista de Compras emite un reporte con las altas y modificaciones del periodo registradas en el sistema a través de la transacción XXX cruzando el mismo vs. los formularios de Alta/Modificación de proveedores a los fines de controlar la exactitud de los datos ingresados.
Se guarda copia del mismo (indicando fecha, firma y aclaración del comprador, el Jefe de Abastecimientos y Jefe de Finanzas) como evidencia del control realizado.”
Acá vemos que este control tiene como DISPARADOR a la FECHA y su FRECUENCIA es MENSUAL.
Ahora bien si volvemos a uno de los ejemplos de la primera entrega de este articulo donde decíamos
“Cada vez que el Analista de Cuentas a Pagar registra un nuevo proveedor, el sistema XXX valida que no exista un registro cargado anteriormente con el mismo número de CUIT. Tal configuración se encuentra documentada en el módulo ZZZ”
Acá el DISPARADOR es un EVENTO. Y ese evento es “Cada vez que el Analista de Cuentas a Pagar ingresa un nuevo proveedor”.
- CONTROL OWNER: Acá definimos al responsable de EJECUTAR el control detallado. Hay colegas que optan en esta columna de la matriz poner nombre y apellido de la persona que ocupa tal cargo. Otros (quien escribe) prefiere solamente detallar el cargo. Solamente lo hago en mi caso por un tema de mantenimiento del documento, ya que si existe alta rotación de personal deberíamos estar modificando varia veces nuestra matriz si es que figura la “persona física”.
¿Y que pasa si el control es automático? ¿Quién es el CONTROL OWNER? Fácil “No aplica” o “N/A” para los usuarios asiduos de Ms Excel® 
- PROCESS OWNER: Este es el dueño del proceso, podría ser también el superior inmediato al “Control Owner”, ESTA PARTE SI ES PARA DEBATE Y ESPERO SUS APORTES.
Verán que nuestra matriz va ganando columnas y columnas y cada vez se vuelve mas “compleja”.
Seguiremos agregando mas información en próxima entrega, esperando que esta información les sea de utilidad.
CONTINUA EN PRÓXIMA ENTREGA!
Aportado por:
Luis M. Romero
Socio en Zen Consultoría y Servicios Profesionales Miembro de la Junta en AAC - Asociación Argentina de Consultoría Fundador en PortalContar - Comunidad de Contadores, Ejecutivo financiero con amplia experiencia en todos los aspectos de contabilidad, auditoría, impuestos y tecnología de la información. La experiencia directa con las industrias de la logística y el proceso de auditoría empresarial. Colaborador de Auditool.
Buenos Aires, Argentina
Y luego Agregar a la pantalla de inicio.