Cómo diseñar un flujo de aprobaciones auditable

El primer paso es dibujar el flujo como una máquina de estados: una lista cerrada de estados y de transiciones permitidas entre ellos. Cada transición tiene un nombre, unas condiciones y unos responsables. Lo que no esté en la lista, no puede ocurrir. Así se evitan registros que «saltan» de borrador a aprobado porque alguien editó un campo directamente.

Conviene distinguir entre rechazar (el pedido termina) y devolver (vuelve al solicitante para corregir). Mezclarlos produce flujos donde un pedido rechazado se reabre y nadie sabe si la nueva aprobación se refiere al mismo contenido. También hay que prever qué pasa con el tiempo: avisos si una aprobación lleva días pendiente y escalado automático a un suplente según reglas pactadas.

En un flujo de aprobaciones, el permiso rara vez depende solo del rol. Depende del importe, del centro de coste, del tipo de gasto, del proyecto y, sobre todo, de quién es el solicitante. Algunas reglas típicas:

• Segregación de funciones: quien crea una solicitud no puede aprobarla, aunque tenga el rol de aprobador.
• Umbrales: por encima de cierto importe se añade un nivel de aprobación; el umbral es configurable y su cambio también queda registrado.
• Ámbito: un responsable aprueba solo lo de sus centros de coste o proyectos.
• Delegaciones: durante una ausencia, otra persona puede aprobar en nombre del titular, con fechas de inicio y fin, y la traza indica que actuó por delegación.
• Fraccionamiento: detectar varias solicitudes del mismo solicitante y proveedor en poco tiempo que juntas superarían un umbral.

Los permisos deben comprobarse en el servidor en el momento de la transición, no solo al mostrar el botón. Si el responsable cambia de puesto entre que se le asigna la tarea y que la ejecuta, la comprobación debe hacerse con su situación en ese momento.

Es la parte que más se descuida. Si un pedido aprobado puede editarse libremente, la aprobación pierde valor. Pero bloquearlo todo tampoco es práctico: corregir una errata en la descripción no debería obligar a repetir tres firmas.

La solución es clasificar los campos. Los materiales (importe, proveedor, cantidades, centro de coste, condiciones de pago) invalidan la aprobación si cambian: el documento vuelve al estado que corresponda y se pide una nueva firma. Los no materiales (una nota interna, la referencia de entrega) pueden modificarse, pero cada cambio queda registrado. Esa clasificación es una decisión de negocio que debe tomar quien responde del proceso, no el equipo de desarrollo por su cuenta.

Cada aprobación debe referirse a una versión concreta e inmutable del documento. En la práctica, al enviar a aprobación se guarda una instantánea completa: datos, líneas, adjuntos y reglas aplicadas. La aprobación se vincula a esa instantánea, no al registro vivo que podría cambiar después.

• Numerar las versiones y mostrar al aprobador las diferencias respecto a la versión anterior si el documento vuelve tras una devolución.
• Guardar un resumen criptográfico (hash) del contenido aprobado, para poder demostrar que no se ha alterado.
• Registrar también la versión de las reglas: si el umbral era de 5.000 euros cuando se aprobó y luego cambió a 3.000, la aprobación antigua sigue siendo válida según la regla vigente entonces.
• Conservar los adjuntos tal como estaban, no solo un enlace a una carpeta que alguien pueda modificar.

El registro de auditoría es la secuencia de eventos de negocio: creado, enviado, aprobado, devuelto, modificado, delegado, anulado. Cada evento guarda quién, cuándo, sobre qué versión, desde qué estado a qué estado, el motivo o comentario y, en las modificaciones, el valor anterior y el nuevo. Las guías de registro de OWASP recogen ese mismo esquema de quién, qué, cuándo y dónde, y recomiendan proteger los registros frente a manipulaciones.

Técnicamente, el registro debe ser de solo adición: ninguna pantalla ni proceso puede editar o borrar eventos. Es útil separarlo de los registros técnicos de la aplicación, que sirven para depurar errores y suelen rotarse en días, mientras que la auditoría de negocio puede tener que conservarse años. Y debe poder consultarse por quien audita, con filtros por documento, persona o periodo, sin pedir ayuda al equipo técnico.

Un flujo de aprobaciones casi nunca termina en sí mismo. El pedido aprobado tiene que llegar al ERP, el cambio de ingeniería a la gestión documental y el alta de proveedor al maestro de proveedores. La integración debe enviar solo lo aprobado, con referencia a la versión, y registrar la confirmación del sistema destino. Si el ERP rechaza el pedido, ese rechazo también forma parte de la historia del documento.

1. ¿Están escritos los estados, las transiciones y quién puede ejecutar cada una?
2. ¿Se impide que una misma persona solicite y apruebe, y se gestionan las delegaciones con fechas?
3. ¿Está decidido qué campos invalidan una aprobación al cambiar?
4. ¿Cada aprobación apunta a una versión congelada del documento y de las reglas?
5. ¿El registro de eventos es de solo adición y consultable por quien audita?
6. ¿Qué sistemas reciben el resultado y cómo se registra su confirmación?

Si puedes responder a estas preguntas sobre el papel, el desarrollo es mucho más directo. Una forma práctica de empezar es elegir un único flujo con dolor real, como los pedidos de compra, y modelarlo completo antes de generalizar. Nuestra capacidad de workflows y reglas de negocio explica cómo podemos diseñar este tipo de flujos e integrarlos con tus sistemas.