Un orquestador mensual para el rendimiento comercial
Un caso de automatización ficticio: convertir un gran proceso programado en una ejecución mensual observable y reanudable.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Una ejecución por periodo que cualquiera puede abrir para ver su estado, el paso actual, el progreso, los fallos y el responsable—reanudable desde el paso fallido y terminada solo cuando el resultado está conciliado.
Un proceso mensual con ocho pasos dependientes se ejecuta como un único proceso programado: cualquier fallo obliga a empezar de nuevo y algunas cuentas reciben sus acciones dos veces.
¿Cómo se identifica, se reanuda y se termina una ejecución mensual—exactamente una vez?
Modelar el ciclo como un registro de ejecución con máquina de estados y guardas por paso, en lugar de un único proceso programado o una cadena de disparadores.
Cada mes, un ciclo comercial debe actualizar los datos de rendimiento, calcular los KPI, clasificar a los clientes en segmentos, activar esos segmentos en el CRM y en las campañas, generar acciones de seguimiento y confirmar el resultado. La primera versión era un único proceso programado que llamaba a cada paso en secuencia. Cuando fallaba a mitad, un administrador lo relanzaba desde el principio.
Se abre el periodo mensual y ha terminado su actualización de datos.
- Cada cuenta apta tiene un segmento vigente para el periodo
- Las acciones existen una sola vez por cuenta y segmento
- La ejecución termina en Éxito con un informe de conciliación
- El responsable de negocio tiene el resumen
02La realidad · situación actual
Qué hace hoy la automatización.
- Nadie sabe a qué mes pertenece una ejecución, ni si terminó
- Relanzar tras un fallo repite pasos que ya habían ido bien
- Las cuentas reciben tareas duplicadas cuando la generación de acciones se ejecuta dos veces
- El proceso arranca antes de que termine la actualización de datos
- Los fallos solo se ven en un log técnico
- Una ejecución de prueba y una de producción son indistinguibles
03Pasos objetivo
Cada paso, con su modo, su actor y su guarda.
- 01Actualización de datos
Esperar a que termine la actualización del periodo: es una dependencia, no un paso que ejecutemos nosotros.
- 02Cálculo de KPI
Calcular el rendimiento frente al objetivo del periodo.
- 03Clasificación de clientes
Exactamente un segmento por cuenta apta.
- 04Activación de segmentos
Publicar los segmentos del periodo como una versión nueva.
- 05Writeback al CRM
Upsert por lotes con continuaciones; se reanuda desde el último lote completado.
- 06Generación de acciones
Crear tareas y altas en campañas una vez por cuenta y segmento.
- 07Conciliación
Comparar los segmentos y acciones esperados con los reales.
- 08Cierre
Revisar el resumen y cerrar la ejecución—o cancelarla con un motivo.
04Dimensión clave · Registro de ejecución, máquina de estados y reanudación segura
Una ejecución, ocho pasos, una máquina de estados
El registro de ejecución es la memoria del orquestador: qué periodo, qué paso, qué lote, qué falló y quién es el responsable.
En curso
Se está ejecutando un paso o un lote.
- En esperaA la espera de una dependencia o de la revisión del responsableSistema
- FallidaUn paso falló por encima de su presupuesto de reintentosSistema
Se llega desde Creada, En espera, Reanudar.
| Paso | Depende de | Guarda | Si falla |
|---|---|---|---|
| 1 · Actualización de datos | Actualización externa | Esperar con un presupuesto | En espera → Fallida al agotar el presupuesto; responsable: equipo de datos |
| 2 · Cálculo de KPI | Paso 1 | Una vez por clave de ejecución | Reintentar; después, Fallida |
| 3 · Clasificación | Paso 2 | Población = clasificadas | Fallar antes de publicar |
| 4 · Activación de segmentos | Paso 3 | Versión publicada una sola vez | Al reanudar se vuelve a publicar la misma versión |
| 5 · Writeback al CRM | Paso 4 | Cursor de lotes | Reanudar desde el último lote completado |
| 6 · Generación de acciones | Paso 5 | Cuenta + segmento + periodo de entrada | Repetirlo no crea nada dos veces |
| 7 · Conciliación | Paso 6 | Una vez por ejecución | Las diferencias van a sus responsables |
| 8 · Cierre | Paso 7 | Tolerancia cumplida | Decide el responsable: cerrar o cancelar |
¿Puede arrancar dos veces el paso 5? No: la guarda del paso ve que ya está en curso para esta ejecución, y cada lote lleva la clave del cursor.
05Seguridad de la ejecución
Si puede ejecutarse dos veces, está diseñado para ejecutarse dos veces.
El ciclo dura más que una transacción, depende de una actualización que no controla y debe reanudarse en el paso que falló.
- Clave de ejecución
- Periodo + ámbito (p. ej., 2026-09 · todas las sociedades)
- Guarda de arranque
- Una segunda ejecución con la misma clave se rechaza de forma atómica
- Guarda de paso
- Cada paso comprueba su propio estado de «ya hecho para esta ejecución»
- Claves de efecto
- Cuenta + segmento + periodo de entrada para cada tarea y cada alta en campaña
- Simulación
- Misma ejecución, mismas comprobaciones, sin efectos secundarios; genera el informe de lo que ocurriría
- Cancelación
- Un estado final con motivo; los pasos completados siguen registrados
06Excepciones y recuperación
No todo fallo se resuelve reintentando.
- Actualización con retraso DependenciaDependencia incompleta al arrancarEsperar con un presupuesto y después escalarEquipo de datos
- Límite del CRM alcanzado a mitad del writeback Transitorio · reintentoError de límite en un loteEsperar y continuar desde el cursorLa automatización
- Ejecución arrancada dos veces DuplicadoLa clave de ejecución ya existeRechazar el segundo arranqueNadie: se absorbe
- Cuenta sin responsable ConfiguraciónBúsqueda de responsable vacía al generar accionesCola de retención; continuar con el restoOperaciones comerciales
- Clasificación incompleta ValidaciónPoblación ≠ cuentas clasificadasFallar antes de la activaciónOperaciones de ventas
07Las contrapartidas
Opciones creíbles, evaluadas frente a estas premisas.
Un único proceso programado que llama a cada paso
Trabajo corto, local e idempotente
Coste: Reinicio desde cero; duplicados; sin visibilidadUna cadena de disparadores, uno por paso
Dos o tres pasos locales
Coste: Sin identidad de ejecución; los fallos rompen la cadena en silencioRegistro de ejecución, máquina de estados, guardas y continuaciones
Trabajo largo, dependiente y recurrente
Coste: Hay que construir un modelo de ejecución y una pequeña vista de ejecuciones08La segunda capa
Preguntas que cambian el diseño.
Identidad y arranque
- ¿Cómo se identifica una ejecución mensual?
- ¿Cómo se evita un arranque duplicado?
- ¿Cómo se representan las dependencias?
Fallo y reanudación
- ¿Qué pasa cuando falla el paso 4?
- ¿Puede arrancar dos veces el paso 5?
- ¿Cómo se reanuda el proceso?
Finalización y control
- ¿Cuándo se considera completa la ejecución?
- ¿En qué se diferencia una simulación de producción?
- ¿Cómo se representa la cancelación—y quién ve el estado de la ejecución?
09Decisiones y entregables
Qué produce el trabajo.
- 01Modelo y clave de ejecución
- 02Máquina de estados
- 03Tabla de dependencias y guardas por paso
- 04Diseño de continuaciones
- 05Semántica de simulación y cancelación
- 06Vista del estado de la ejecución