Diseñador de procesos

Quién eres

Traduces un procedimiento del banco («cumplimiento revisa, contabilidad registra») a un proceso que el orquestador ejecuta y del que se puede ver, en cada momento, en qué paso está cada caso. Trabajas con el área dueña del procedimiento y con el administrador de plataforma, que aprueba los destinos y configura los secretos.

Lo que haces en el sistema

• Diseñas procesos BPMN 2.0 con eventos de inicio, llamadas al core, decisiones y tareas de personas.
• Publicas cada versión pasando por maker-checker: otra persona la aprueba.
• Conectas los eventos del core (asientos, cambios de cuenta) con los procesos que deben reaccionar.
• Atiendes los incidentes: corriges la causa y reintentas sin duplicar operaciones.

Tu ruta

1. 1

   El mapa de la suite FINORA

   Dónde encaja el orquestador entre el gateway y el core.

2. 2

   Cuatro ojos

   El principio que el orquestador aplica a las definiciones, los destinos y las tareas.

3. 3

   Orquestación de procesos con BPMN 2.0

   Maker-checker, destinos, la política de seguridad, reintentos y eventos del core.

4. 4

   Publica un proceso que reacciona a un evento del core

   Diseñar, enviar, aprobar con otro usuario, suscribir el webhook y verificar el caso.

5. 5

   Un proceso con aprobación a cuatro ojos y umbralPróximamente

   Decisiones por monto y tareas que no puede completar quien inició el caso.

6. 6

   Atender un incidente de un procesoPróximamente

   Leer el error, corregir la causa y reintentar sin duplicar.

Tu lista de cada día, semana y mes

Cada día

• Revisa si hay casos en INCIDENT y atiéndelos.
• Revisa la bandeja de tareas pendientes de tus procesos.

Cada semana

• Revisa las definiciones en PENDING_APPROVAL que esperan a otra persona.
• Revisa que los destinos que usan tus procesos sigan aprobados y sin cambios pendientes.

Cada mes

• Retira las versiones que ya no se usan.
• Repasa con el área dueña si el proceso sigue reflejando el procedimiento real.

Lo que se mide de tu trabajo

Indicador	Qué dice	Buena señal
Casos en incidente	Si las llamadas al core son robustas	Pocos y atendidos el mismo día
Tiempo en tareas de personas	Dónde se atasca el procedimiento	Estable y explicado
Versiones rechazadas	Si el diseño llega maduro a la aprobación	Rechazos con motivo claro y corregidos

Errores frecuentes

Qué pasa	Por qué	Qué hacer
Quieres aprobar tu propia definición	Maker-checker	Pide la aprobación a otra persona; el sistema no lo permite
El BPMN usa una clase o un script	La política lo rechaza	Toda llamada saliente es callDestination hacia un destino aprobado
Un reintento manual duplicaría un asiento	Se asume que reintentar es repetir	No lo hace: cada escritura lleva su clave de idempotencia estable
Se edita un destino en uso	Se teme romper los casos en curso	El cambio queda pendiente y la versión aprobada sigue en uso hasta que otra persona lo apruebe

Tu rol en el sistema

El orquestador tiene tres roles: ORQ_ADMIN (diseña destinos y definiciones, las activa y las retira), ORQ_APPROVER (aprueba o rechaza y completa tareas) y ORQ_OPERATOR (inicia casos, entrega mensajes y reintenta incidentes). Un diseñador trabaja con ORQ_ADMIN. Aunque un mismo cliente tuviera también ORQ_APPROVER, el orquestador le impide aprobar lo que él mismo creó o envió.