Diagrama de flujo del proceso de aprobación de compras (matriz por umbral)

¿Qué es diagrama de flujo del proceso de aprobación de compras (matriz por umbral)?

Una aprobación de compra es la decisión de que un compromiso de gasto puede seguir adelante, tomada antes de que exista una orden de compra y no después. El disparador es una necesidad de compra con un importe aproximado y una categoría asignada, y el diagrama sigue una solicitud desde ese punto hasta el momento en que se convierte en una orden de compra o se rechaza formalmente: disponibilidad de presupuesto, el tratamiento capital frente a operativo, una matriz de aprobación por delegación de autoridad que enruta según el importe, una comprobación de si aplican ofertas competitivas o un proveedor preferente, y una revisión especializada para las categorías que la necesitan. El sentido de dibujarla es convertir una matriz que normalmente vive repartida entre varios documentos de política en una sola ruta que cualquiera puede seguir.

Este diagrama es solo la capa de gobierno de la aprobación, y se sitúa deliberadamente entre otros dos procesos en lugar de duplicar ninguno de ellos. No cubre cómo se especifica, se imputa o se devuelve para corrección una solicitud: esa mecánica documental pertenece al proceso de solicitud de compra, y este diagrama asume que ya existe una solicitud con un importe y una categoría. Tampoco continúa más allá de la orden de compra hacia la recepción de mercancía, la conciliación de facturas o el pago: esa cadena transaccional pertenece al proceso de orden de compra, al que este diagrama entrega en el mismo paso. Y no es la decisión de abastecimiento más amplia de fabricar o comprar, licitación frente a pedido abierto o negociación de contrato, que es el territorio del proceso de compras. Lo que este diagrama posee es más estrecho y fácil de pasar por alto en una política escrita: quién tiene que firmar, a qué importe, para qué categoría, y qué ocurre cuando una compra no supera una de esas puertas. Trátalo como un punto de partida que adaptar bajo tu propia tabla de delegación de autoridad, plan de cuentas y controles financieros, no como un sustituto de ellos.

Tres decisiones sostienen el proceso. La decisión capex o opex está justo al principio, porque el gasto de capital suele regirse por una tabla de umbrales distinta y un ciclo de evaluación más lento que el gasto operativo, y fundir ambos en una sola cadena es el fallo más habitual en una matriz de aprobación. La decisión del responsable directo está en el carril Responsable de presupuesto / responsable directo con tres ramas en lugar de dos: aprobar, rechazar o escalar al carril Aprobador superior cuando el importe supera lo que el responsable puede firmar, que es lo que convierte el diagrama en una auténtica matriz de aprobación por delegación de autoridad y no en una sola puerta de umbral. La decisión de revisión especializada llega tarde, en el carril Compras, porque depende de la categoría registrada justo en el primer paso, y es la puerta que impide que una compra con dimensión de datos, seguridad o legal llegue a una orden de compra solo con una aprobación de importe.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles (Solicitante, Responsable de presupuesto / responsable directo, Compras, Finanzas y Aprobador superior (según umbral)) repartidos en seis fases: solicitud y clasificación, control presupuestario, matriz de aprobación, controles de abastecimiento, revisión especializada, y decisión y emisión de la orden de compra.
• La decisión '¿Compra capex u opex?' justo al principio hace que el gasto de capital se registre para evaluación de inversión con finanzas antes del control presupuestario, mientras que el gasto operativo entra directamente en él, en lugar de tratar ambos como una sola vía.
• La decisión '¿El responsable directo aprueba dentro de su facultad?' tiene tres ramas, no dos: aprobar directamente, rechazar directamente o escalar al carril Aprobador superior (según umbral) en cuanto el importe supera lo que el responsable puede firmar, que es lo que convierte esto en una matriz de aprobación por delegación de autoridad y no en una simple puerta de sí o no.
• Controles de abastecimiento situados dentro de la propia aprobación: la decisión '¿Se requieren ofertas competitivas por encima del umbral?' y la decisión '¿Proveedor preferente registrado?', con la evaluación de riesgo de un proveedor nuevo registrada antes de que la solicitud llegue a la puerta de revisión especializada.
• La decisión '¿Se requiere revisión especializada para la categoría?' deriva ciertas categorías a TI, seguridad o legal antes de que la solicitud pueda continuar, con el visto bueno registrado como un paso propio en lugar de darse por supuesto a partir de un sí verbal.
• Un bucle '¿Reducir el alcance o cancelar la solicitud?' cuando no hay presupuesto disponible, y un único paso de registro de rechazo por el que pasa cualquier vía de rechazo, ya sea en presupuesto, en el responsable directo o en el aprobador superior, antes de 'Solicitud de compra cancelada', de modo que el registro muestre por qué se detuvo una solicitud y no solo que se detuvo.

Cuándo usar esta plantilla

• Estáis documentando quién tiene que aprobar una compra antes de comprometer el gasto, y queréis acordar los umbrales de importe y categoría una sola vez en lugar de discutirlos en cada solicitud.
• Las solicitudes de compra se atascan una y otra vez porque nadie se pone de acuerdo sobre si tiene que firmar a continuación el responsable directo, el aprobador superior o un revisor especializado.
• Estáis fijando o reajustando una tabla de delegación de autoridad y necesitáis una sola imagen de quién aprueba qué, a qué importe, en qué categoría.
• Finanzas o un auditor ha preguntado cómo se distinguen las compras de capital y las operativas, y cómo se aprueban de forma distinta antes de asumir cualquier compromiso.
• Estáis configurando un flujo de aprobación de compras o de ERP y necesitáis las reglas de gobierno acordadas sobre el papel antes de que alguien las integre en la herramienta.

Cómo funciona

1. Cambia los carriles por tus roles

   Sustituye Solicitante, Responsable de presupuesto / responsable directo, Compras, Finanzas y Aprobador superior (según umbral) por los roles que existen de verdad en tu organización. En un equipo pequeño, el responsable directo y el responsable de presupuesto suelen ser la misma persona: fusiona esos carriles en vez de dibujar una entrega que nunca ocurre. Usa un carril por decisor, no por persona nombrada, para que el diagrama sobreviva a un cambio de puesto.

2. Fija las tablas de umbrales de capex y opex

   Escribe tus propias cifras en la rama '¿Compra capex u opex?': qué cuenta como capital según tu política contable, quién en finanzas firma la evaluación de inversión y cuánto suele tardar esa evaluación. Si las dos tablas de umbrales convergen de verdad en algún importe, indícalo; si no, mantenlas separadas para que una compra de capital no se apruebe en silencio con un límite operativo.

3. Fija los importes de la delegación de autoridad

   Sustituye 'dentro de su facultad' y 'según el umbral' por las cifras reales de tu tabla de delegación de autoridad, indicadas en una sola moneda. Nombra quién es el aprobador superior en cada banda, y añade un nivel adicional solo si de verdad lo utilizas, porque cada nivel extra añade una entrega y un incentivo para trocear una solicitud y quedarse por debajo de un límite.

4. Declara tus reglas de ofertas y proveedor preferente

   Convierte '¿Se requieren ofertas competitivas por encima del umbral?' en un importe y un número de ofertas concretos según tu política de compras, y enumera qué cuenta como proveedor preferente registrado para que la rama no sea una cuestión de criterio. Decide si la evaluación de riesgo de un proveedor nuevo puede ir en paralelo con la solicitud de ofertas o debe terminar antes, y dibuja lo que de verdad se aplica.

5. Define qué activa la revisión especializada

   Nombra las categorías que deben derivarse a TI, seguridad o legal: normalmente software o SaaS nuevos, cualquier cosa que vaya a tratar datos de clientes o empleados, y un contrato con condiciones no estándar. Indica quién firma cada tipo de revisión y cuánto se espera que tarde, para que '¿Se requiere revisión especializada para la categoría?' se responda a partir de una lista, no de memoria.

6. Decide qué debe registrar un rechazo

   Fija qué debe recoger 'Registrar el motivo del rechazo y notificar al solicitante': qué puerta lo rechazó, el motivo indicado, y si el solicitante puede volver a presentarlo con cambios o debe abrir una solicitud nueva. Un rechazo sin motivo registrado es indistinguible de una solicitud que nadie llegó a atender, y eso es lo que hace poco fiables los informes de tiempo de ciclo y tasa de rechazo.

7. Recórrelo contra una solicitud real

   Coge dos o tres compras recientes, una que pasara sin problema y otra que se atascara o fuera rechazada, y síguelas por el diagrama. Cualquier aprobador que la gente describa y no esté dibujado, o un paso dibujado aquí y saltado en la práctica, es el hallazgo que conviene corregir antes de publicar el diagrama como el proceso acordado.

Preguntas frecuentes

¿Cuáles son los pasos del proceso de aprobación de compras?

Se identifica una necesidad de compra y se registra con una categoría de gasto y un centro de coste, y luego se clasifica como capex u opex; el gasto de capital se registra para evaluación de inversión con finanzas antes de continuar, mientras que el gasto operativo va directo al control presupuestario. Si no hay presupuesto disponible, el solicitante reduce el alcance y vuelve a presentar la solicitud, o la cancela. Si hay presupuesto disponible, el responsable directo la revisa y la aprueba directamente, la rechaza o la escala al aprobador superior cuando el importe supera su facultad; el aprobador superior entonces aprueba o rechaza. Una solicitud aprobada pasa a compras, que comprueba si se requieren ofertas competitivas por encima del umbral de importe, las obtiene si es así, y comprueba si hay un proveedor preferente registrado, registrando antes una evaluación de riesgo si no lo hay. Una decisión deriva entonces ciertas categorías a una revisión especializada de TI, seguridad o legal, con el visto bueno registrado. Finanzas registra el compromiso presupuestario y la pista de auditoría, y compras emite la orden de compra. Cualquier rechazo, en presupuesto, en el responsable directo o en el aprobador superior, se registra con un motivo antes de cerrar la solicitud.

¿Qué diferencia hay entre una aprobación de compra y una solicitud de compra?

La solicitud de compra es el documento interno: la especificación, el centro de coste y la imputación contable, y la comprobación de compras de que está especificada lo bastante bien como para comprar a partir de ella. La aprobación de compra es la decisión de gobierno que se superpone: si el importe y la categoría superan una matriz de aprobación por delegación de autoridad, si la compra es de capital o operativa, si necesita ofertas competitivas o una revisión especializada, y quién firma en última instancia. En la práctica, las dos avanzan juntas, y la solicitud aporta los datos que lee la matriz de aprobación. Este diagrama asume que ya existe una solicitud con un importe y una categoría indicados, y se centra en la propia decisión de aprobación; los pasos de especificación e imputación de la propia solicitud se cubren aparte en el proceso de solicitud de compra.

¿Cuántos niveles de aprobación debería tener una matriz de delegación de autoridad?

Menos de los que la mayoría de las organizaciones fijan al empezar. Dos niveles cubren la mayor parte del gasto: el responsable de presupuesto o responsable directo para todo lo que entra dentro de su facultad firmada, y un aprobador superior por encima de un umbral tomado de tu tabla de delegación de autoridad. Un tercer nivel para importes muy altos o gasto de capital es habitual, pero cada nivel adicional añade tiempo de ciclo y crea un incentivo para trocear una compra en solicitudes más pequeñas y quedarse por debajo de un límite, algo que la propia revisión de la matriz debería vigilar. Las cifras pertenecen a tu propia tabla; esta plantilla las deja como marcador de posición para que las fijes y las revises periódicamente, en lugar de indicar una cifra que sirva para cualquier organización.

¿Qué compras necesitan revisión de TI, seguridad o legal antes de aprobarse?

Lo que debería decidirlo es la categoría registrada al principio de la solicitud, no un criterio aplicado más tarde. Los desencadenantes habituales son software nuevo o una suscripción SaaS, cualquier cosa que vaya a tratar datos de clientes o empleados, una compra que se conecte con sistemas o infraestructura existentes, y un contrato con condiciones distintas de tu plantilla estándar. No todas las compras de esas categorías necesitan la misma profundidad de revisión: una herramienta de bajo importe sin acceso a datos puede recibir una lista de comprobación de seguridad breve, mientras que un sistema que maneje datos personales justifica una revisión más completa y el visto bueno legal del contrato. Enumera tus propias categorías y la revisión que activa cada una, y registra el visto bueno como un paso propio para que una compra no pueda llegar a una orden de compra solo con una aprobación de importe.

¿Cómo deberían aprobarse de forma distinta las compras de capital y las operativas?

Las compras de capital, en general un activo con una vida útil superior a un ejercicio contable, suelen seguir una tabla de umbrales propia, una evaluación liderada por finanzas y un ciclo más lento que el gasto operativo habitual, porque afectan al balance y al plan de amortización y no solo al coste de un periodo. Las compras operativas se suelen aprobar más rápido contra un presupuesto departamental. La línea concreta entre ambas, y los umbrales y bandas de aprobación exactos de cada una, proceden de la política contable y la tabla de delegación de autoridad de tu organización, así que indícalos en el diagrama en lugar de suponer que se aplican cifras genéricas. Lo que importa para el proceso es que la separación ocurra pronto, antes de que cualquiera de las dos vías llegue al control presupuestario compartido, de modo que una solicitud de capital nunca se apruebe por error con un límite operativo.