En la mayoría de organizaciones que no tienen un sistema de compras estructurado, los accesos funcionan así: hay una o dos personas que manejan "el sistema" — que puede ser un correo compartido, un Excel o un chat de WhatsApp — y el resto simplemente hace pedidos sin control real sobre quién puede hacer qué.
Esta informalidad tiene un costo concreto: cuando no hay separación de funciones, aumenta el riesgo de errores, fraudes y hallazgos en auditorías. Y cuando hay un incidente, nadie sabe exactamente quién hizo qué.
El principio de separación de funciones
En gestión de compras, el principio básico es simple: la persona que crea un pedido no debería ser la misma que lo aprueba ni la que confirma que se recibió. Esta separación existe por una razón muy concreta: sin ella, una sola persona puede iniciar, autorizar y cerrar una transacción sin ningún contrapeso.
Caso real: En una empresa con más de 40 empleados, el asistente de compras tenía acceso de administrador al sistema porque "era el que sabía usarlo". Cuando se fue, nadie más podía aprobar pedidos. Y cuando llegó una auditoría, no había forma de saber cuáles pedidos había aprobado él mismo que él había solicitado.
Los roles que necesita cualquier proceso de compras
No se trata de crear una burocracia compleja. Se trata de definir claramente qué puede hacer cada perfil. Estos son los roles mínimos que debe tener un proceso de compras bien estructurado:
Comprador
Puede crear solicitudes de pedido, consultar el catálogo de productos del contrato y ver el saldo disponible de su departamento. No puede aprobar sus propios pedidos ni ver los de otros departamentos.
Interventor / Aprobador
Revisa y aprueba o rechaza pedidos dentro de los límites de monto que tiene asignados. Puede agregar comentarios o devolver un pedido al comprador con observaciones. No puede crear pedidos propios.
Administrador del contrato
Configura contratos, catálogos, fondos y usuarios. Tiene visibilidad total sobre la ejecución, pero no puede aprobar pedidos — mantener separada la gestión del sistema del flujo de aprobación es clave.
Proveedor
Ve solo los pedidos que le corresponden a él. Puede confirmar disponibilidad, actualizar el estado del pedido y programar la entrega. No tiene acceso a información de otros proveedores ni al detalle de los fondos del cliente.
Tabla de permisos recomendada
| Acción | Comprador | Interventor | Admin | Proveedor |
|---|---|---|---|---|
| Crear pedido | ✓ | ✗ | ✗ | ✗ |
| Ver catálogo del contrato | ✓ | ✓ | ✓ | ✓ |
| Ver saldo del fondo propio | ✓ | ✓ | ✓ | ✗ |
| Aprobar pedidos | ✗ | ✓ | ✗ | ✗ |
| Ver pedidos de todos los depts. | ✗ | ✓ | ✓ | ✗ |
| Confirmar entrega | ✓ | ✗ | ✗ | ✓ |
| Configurar contratos y usuarios | ✗ | ✗ | ✓ | ✗ |
| Exportar reportes ejecutivos | ✗ | ✓ | ✓ | ✗ |
Por qué los límites de monto importan tanto como los roles
Un interventor que puede aprobar pedidos de cualquier monto sin restricción es casi lo mismo que no tener interventoría. El control real requiere que los límites de aprobación estén codificados en el sistema — no en la "confianza" de que el aprobador sabrá cuándo escalar.
Buena práctica: Define al menos dos niveles de aprobación: pedidos menores (aprueba el jefe de área) y pedidos mayores (requieren firma de gerencia o interventoría externa). El umbral exacto depende del contrato, pero tener el límite configurado en el sistema es no-negociable.
Lo que cambia cuando los roles están bien definidos
- Las auditorías se vuelven triviales: cada acción en el sistema está firmada por un usuario identificado. No hay lugar para "no sé quién lo hizo".
- Los errores se detectan antes de que cuesten dinero: el sistema rechaza automáticamente acciones fuera de los permisos del usuario.
- El equipo trabaja más rápido: los compradores no necesitan esperar confirmación de que tienen permiso para hacer algo — el sistema ya lo sabe.
- La rotación de personal no paraliza la operación: cuando alguien se va, se desactiva su usuario. No hay que cambiar contraseñas compartidas ni renegociar accesos informales.