ADR / 004

Separar la aprobación comercial de la validación financiera

Dos decisiones con distintos responsables, evidencias y SLA no deben compartir un único paso de aprobación, aunque un mismo formulario recoja los datos de ambas.

Patrón de referencia

Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.

01Contexto

Una organización comercial hace pasar cada cliente nuevo por una única ‘aprobación de cliente’. Los responsables de ventas aprueban condiciones que saben valorar, y también datos fiscales y exposición de crédito que no. Finanzas lo vuelve a revisar todo después, así que el paso ni protege a Finanzas ni agiliza a Ventas.

02Factores de decisión

  1. F01

    Un único responsable último por decisión

  2. F02

    Quien aprueba solo ve evidencias que puede valorar

  3. F03

    Los rechazos vuelven a la etapa que puede corregirlos

  4. F04

    SLA medibles por decisión

03Opciones consideradas

Descartada

Una aprobación combinada

Organizaciones pequeñas en las que un mismo rol es realmente responsable de ambas decisiones

Coste: Quien aprueba firma evidencias fuera de su competencia
Elegida

Decisiones separadas y secuenciales

Las condiciones deben cerrarse antes de dimensionar el crédito

Coste: Recorrido más largo, salvo que cada SLA tenga responsable
Según el contexto

Decisiones en paralelo con una puerta conjunta

Alto volumen en el que las condiciones rara vez cambian tras la validación

Coste: Retrabajo cuando la revisión de crédito cambia las condiciones

04Decisión

Modelar la aprobación comercial y la validación financiera como dos decisiones con responsables, evidencias, SLA y estados de retorno propios. La aprobación comercial decide si comprometerse con estas condiciones; la validación financiera decide si esta entidad legal puede operar. Un resultado de crédito que cambia las condiciones vuelve a la aprobación comercial, no al principio.

05Consecuencias

  • Los responsables de ventas dejan de aprobar datos fiscales y de crédito que no pueden evaluar.
  • Cada rechazo lleva un código de motivo y vuelve a la etapa que puede corregirlo.
  • La antigüedad de las aprobaciones y la validación a la primera pasan a medirse, y a tener responsable, por separado.
  • El CRM muestra dos estados distintos en lugar de un ambiguo ‘pendiente de aprobación’.

06Cuándo revisarla

01

Un mismo rol pasa a ser responsable último del riesgo comercial y del de crédito.

02

La exposición de crédito se preaprueba por segmento, lo que hace determinista la validación.

07Dónde se aplica esta decisión

Casos que adoptan esta decisión, y por qué importa en cada uno.

  1. Caso de arquitectura / 002Diseñar un modelo operativo global de lead a clienteUn caso centrado en el proceso para una empresa B2B global ficticia: etapas, derechos de decisión, aprobaciones, excepciones y medición, diseñados antes de configurar ningún sistema.Arquitectura de ProcesosArquitectura de Sistemas y CRMModelo Operativo DigitalEscenario ficticio · 20 min
  2. Caso de procesos / 02Diseñar un proceso de oferta a pedido con responsabilidades clarasVincular las aprobaciones a versiones de oferta, adelantar la validación del ERP y dar un responsable a los pedidos rechazados.Arquitectura de ProcesosArquitectura de Sistemas y CRMAutomatizaciónEscenario ficticio · 9 min
  3. Caso de automatización / 05La automatización de aprobaciones como máquina de estadosDos decisiones—aprobación comercial y validación financiera—modeladas como una única máquina de estados con rechazo, devolución y reentrada explícitos, reglas de invalidación cuando cambian los datos, relojes que escalan y un historial completo.AutomatizaciónArquitectura de ProcesosModelo Operativo DigitalEscenario ficticio · 8 min