La decisión sobre el sistema de gestión de auditorías que la mayoría pasa por alto

Muchas organizaciones ven la elección de un sistema de gestión de auditorías como una simple tarea operativa más, pero en realidad es una decisión estratégica. Después de veinte años trabajando en todo el continente americano, rara vez he visto que esta decisión se gestione adecuadamente. El resultado depende más del proceso que de la tecnología en sí.

Esto es lo que suele ocurrir: el director de auditoría asiste a una conferencia, ve una demostración de un proveedor, queda impresionado y lleva la idea a su equipo. El proyecto de selección de software se delega a los líderes del equipo. El proceso de selección comienza, pero se trata más de cuidar las apariencias que de realizar una evaluación rigurosa. Algunos proveedores presentan sus diapositivas y demostraciones de productos, al equipo le gustan las mejores presentaciones y se toma una decisión. De seis a dieciocho meses después, el equipo está buscando discretamente soluciones alternativas para trabajar al margen del sistema en lugar de usarlo como se había previsto.

“Un sistema de gestión de auditorías no es un software que se utiliza para respaldar esta área. Es el entorno operativo en el que el equipo vive. Si te equivocas en esto, todo lo demás se vuelve más difícil.”

Lo que hace que esta decisión sea tan trascendental es su alcance. Cada función central de un departamento (la planificación, la programación, el trabajo de campo, la gestión de documentos, la documentación de hallazgos, el seguimiento de problemas, la elaboración de informes y las métricas de rendimiento) se ejecuta a través del sistema o está condicionada por lo que este puede y no puede hacer. Una incompatibilidad entre la plataforma y el flujo de trabajo no constituye un problema de software. Produce un problema de calidad en el trabajo.

Las organizaciones que logran hacerlo correctamente tienen una cosa en común: abordan el proceso de selección con la misma disciplina que utilizan en sus proyectos principales. Establecen requisitos claros antes de reunirse con los proveedores, separan las necesidades reales de los simples deseos, prueban la plataforma con sus propios flujos de trabajo en lugar de depender de las demostraciones del proveedor, e incluyen en la toma de decisiones a las personas que realmente usarán el sistema.

Eso suena obvio. Sin embargo, rara vez ocurre en la práctica. Y el costo de no hacerlo no se mide en el precio de las licencias por usuario, sino en años de fricción, soluciones improvisadas y un trabajo que podría haber sido mucho mejor.

Vale la pena reflexionar:

¿Cuándo fue la última vez que su equipo evaluó si el sistema actual realmente favorece sus flujos de trabajo, o si simplemente están buscando cómo evitar usarlo? Si no está seguro de la respuesta, es hora de analizarlo más de cerca.