La automatización de aprobaciones como máquina de estados
Un caso de automatización ficticio: las aprobaciones como estados diseñados, no como correos y casillas.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Cada solicitud está en exactamente un estado visible; los cambios invalidan exactamente las aprobaciones a las que afectan; esperar tiene un reloj y un siguiente aprobador; cada decisión queda registrada.
Las aprobaciones son una cadena de correos: nadie sabe qué decisión está pendiente, las ofertas rechazadas vuelven como ediciones y los precios modificados conservan aprobaciones antiguas.
¿Qué cambios invalidan una aprobación—y dónde debe reiniciarse el proceso?
Modelar las dos decisiones como estados de una única máquina de aprobación, con reglas de invalidación por cambio de datos, en lugar de un único paso de aprobación.
Las operaciones comerciales fuera de las condiciones estándar necesitan aprobación comercial, y una nueva exposición de crédito necesita validación financiera. La automatización actual envía correos y marca una casilla. Los rechazos vuelven como ediciones de la misma solicitud, y un precio cambiado después de aprobar conserva la aprobación.
Un comercial envía una operación fuera de las condiciones estándar o que añade exposición de crédito.
- Decisiones comercial y financiera registradas por separado
- Estado Aprobada válido solo para la versión de datos aprobada
- Los rechazos llevan un motivo
- Escalado disparado cuando se agotó un reloj
02La realidad · situación actual
Qué hace hoy la automatización.
- Nadie sabe qué decisión está pendiente, ni de quién
- Los rechazos y las peticiones de cambios se ven iguales
- Un cambio de precio tras la aprobación conserva la aprobación antigua
- Las aprobaciones esperan indefinidamente cuando el aprobador está ausente
- El historial está repartido entre bandejas de entrada
03Pasos objetivo
Cada paso, con su modo, su actor y su guarda.
- 01Enviada
La versión de los datos se congela con la solicitud.
- 02Revisión comercial
¿Condiciones dentro de la estrategia? Aprobar, rechazar o devolver.
- 03Encaminar a finanzas
Solo cuando cambia la exposición de crédito.
- 04Revisión financiera
¿Crédito y condiciones de pago aceptables?
- 05Aprobada
Aprobación ligada a la versión de datos; se desbloquea lo que va aguas abajo.
04Dimensión clave · Estados de aprobación, invalidación y reentrada
Dos decisiones, una máquina
Rechazada y devuelta son resultados distintos. Reenviar es una decisión nueva sobre una versión nueva—no una edición.
Revisión comercial
A la espera de la decisión del director de ventas, con un reloj.
- Aprobada comercialmenteEl director de ventas apruebaPersona
- Devuelta para cambiosEl director de ventas pide cambiosPersona
- RechazadaEl director de ventas rechazaPersona
- Escalada · comercialSin decisión en dos días laborablesReloj
Se llega desde Enviada, Escalada · comercial, Reenviada.
| Cuando cambia | Reinicia |
|---|---|
| Precio, descuento o mix de productos | La revisión comercial (y la financiera si cambia la exposición) |
| Condiciones de pago o límite de crédito | Solo la revisión financiera |
| Fecha de entrega o contacto | Nada: no forma parte de ninguna de las dos decisiones |
| Entidad legal del cliente | Ambas decisiones |
La delegación es una asignación registrada con alcance y fechas—nunca unas credenciales compartidas. El silencio nunca aprueba.
05Seguridad de la ejecución
Si puede ejecutarse dos veces, está diseñado para ejecutarse dos veces.
Pasos automatizados cortos entre largas esperas humanas; el estado debe sobrevivir días y ser auditable.
- Vínculo con la versión
- La aprobación vale para la versión de datos sobre la que se concedió
- Invalidación
- Declarada por campo: qué cambio reinicia qué decisión
- Temporizador
- Recordatorio y después escalado a un siguiente aprobador con nombre
- Historial
- Cada transición con quién, cuándo, versión y comentario
06Excepciones y recuperación
No todo fallo se resuelve reintentando.
- Aprobador ausente ConfiguraciónFuera de la oficina o sin delegadoEncaminar al delegado declarado o al siguiente nivelOperaciones de ventas
- Datos modificados tras la aprobación Estado obsoletoLa versión no coincideInvalidar solo la decisión afectadaLa automatización
- ERP no disponible al aprobar Dependencia · reintentoFalla la llamada aguas abajoLa aprobación se mantiene; lo de aguas abajo queda en colaEquipo de plataforma
- Rechazo definitivo RechazoDecisión del aprobadorCerrar con motivo; se avisa al comercialComercial
07Las contrapartidas
Opciones creíbles, evaluadas frente a estas premisas.
Un único paso de aprobación para todo
Un aprobador, un tipo de riesgo
Coste: Mezcla dos decisiones; la evidencia no sirve para ningunaAprobaciones por correo
Excepciones muy poco frecuentes
Coste: Sin estado, sin historial, sin relojMáquina de estados de aprobación con invalidación y temporizadores
Aprobaciones recurrentes con dos responsables
Coste: Hay que mantener las reglas de invalidación08La segunda capa
Preguntas que cambian el diseño.
Decisiones
- ¿Representan decisiones distintas la aprobación comercial y la financiera?
- ¿Puede delegarse la aprobación?
- ¿Quién es responsable del escalado?
Cambio
- ¿Qué datos invalidan una aprobación previa cuando cambian?
- ¿Cuándo debe reiniciarse la aprobación?
- ¿Es un reenvío una decisión nueva?
Tiempo y registro
- ¿Qué pasa tras un timeout?
- ¿Cómo se conserva el historial?
- ¿Qué ve el comercial mientras espera?
09Decisiones y entregables
Qué produce el trabajo.
- 01Máquina de estados de aprobación
- 02Matriz de invalidación
- 03Relojes de escalado
- 04Regla de delegación
- 05Modelo de historial de aprobaciones