Diseñar el workflow objetivo y sus estados

El mapa actual explica qué ocurre hoy. El workflow objetivo debe definir qué comportamiento queremos que tenga el sistema mañana. La diferencia es importante: un proceso observado describe hechos; un workflow implementable necesita estados reconocibles, eventos que provocan cambios y reglas que determinen qué transiciones están permitidas.

La notación BPMN puede ayudar a representar eventos, actividades, participantes y flujos, pero el diseño no depende de dibujar un diagrama sofisticado. Lo esencial es que otra persona pueda responder, para cualquier caso, en qué estado se encuentra, qué puede ocurrir a continuación y qué resultado termina el proceso.

Diseña desde los resultados terminales

Empieza por el final. Define qué resultados legítimos puede tener un caso. Una solicitud de presupuesto podría terminar como enviada, rechazada, cancelada o cerrada_sin_datos. Un alta de proveedor podría terminar como aprobada o denegada.

Los estados terminales ayudan a evitar workflows que parecen no terminar nunca. También obligan a distinguir éxito técnico de éxito de negocio. Que una API responda correctamente no significa que el caso empresarial esté cerrado.

A partir de esos resultados, recorre hacia atrás qué estados son necesarios para llegar a ellos.

Define estados de negocio, no pantallas

Un estado debe representar una condición significativa del caso. pendiente_de_datos, validando, requiere_aprobacion o listo_para_envio describen el trabajo. pantalla_2, boton_pulsado o modal_abierto describen la interfaz y no deberían gobernar el proceso.

Un buen estado responde al menos a estas preguntas:

• ¿qué es verdad mientras el caso está aquí?;
• ¿qué acciones están permitidas?;
• ¿quién es responsable?;
• ¿qué evento puede sacarlo de este estado?;
• ¿qué datos deben existir antes de avanzar?;
• ¿qué timeout o escalado aplica, si existe?

No crees estados para cada detalle técnico. El objetivo no es convertir el workflow en un inventario de microeventos, sino conservar las condiciones que importan para controlar el caso.

Convierte hechos en eventos y transiciones

Una transición ocurre porque sucede algo. Ese algo puede ser externo —llega un correo, se recibe una aprobación— o interno —termina una validación, vence un plazo—.

Formula los eventos como hechos observables: solicitud_recibida, datos_completados, precio_obtenido, descuento_aprobado, timeout_superado. Evita eventos vagos como procesar o hacer_validacion, que describen una intención y no un hecho consumado.

Para cada transición define:

1. estado de origen;
2. evento;
3. condición, si existe;
4. acciones asociadas;
5. estado de destino;
6. efecto que no debe repetirse accidentalmente.

Este último punto será importante al diseñar idempotencia.

Explicita las decisiones ocultas

Muchos procesos contienen decisiones que una persona aplica sin haberlas formalizado. El workflow obliga a sacarlas a la superficie.

Por ejemplo: “si el cliente es estratégico, permitir una excepción”. Antes de convertirlo en una transición debes saber dónde se obtiene esa condición, quién mantiene su definición y qué ocurre si el dato falta o es contradictorio.

No conviertas automáticamente toda decisión en una regla. Algunas requieren inferencia con IA y otras deben permanecer en manos humanas. En esta fase basta con identificar el punto de decisión y el tipo de responsabilidad que necesita. La siguiente parte del curso detallará reglas y contratos.

Asigna responsabilidades

Para cada estado identifica quién o qué sistema tiene la responsabilidad operativa. Esto no significa que deba ejecutar todas las acciones, sino que debe quedar claro quién responde de que el caso progrese.

Puedes utilizar categorías simples:

• sistema;
• persona o rol;
• IA asistida;
• servicio externo.

Si un caso entra en requiere_revision y nadie tiene asignada esa cola, el workflow está incompleto aunque el diagrama sea correcto.

Elige la autonomía mínima necesaria

El workflow objetivo no debería maximizar automatización. Debe automatizar únicamente aquello que puede controlar con suficiente fiabilidad.

Una decisión reversible y de bajo impacto puede ejecutarse automáticamente. Una decisión que genera un contrato, compromete dinero o modifica datos críticos puede necesitar aprobación. Una tarea de interpretación puede utilizar IA para proponer una salida sin que esa propuesta sea la acción final.

Diseña primero el grado mínimo de autonomía que produzca valor. Aumentarlo será una decisión posterior basada en evidencia.

Ejemplo: presupuesto B2B

Partiendo del proceso anterior, una primera máquina de estados podría ser:

recibida → validando_datos → pendiente_de_aclaracion → validando_datos → preparando_borrador → requiere_aprobacion → lista_para_revision → cerrada.

No todos los casos recorren todos los estados. Una solicitud completa puede saltar pendiente_de_aclaracion. Una solicitud sin precio vigente puede pasar a requiere_revision_manual.

El punto importante es que cada cambio tenga una causa observable y que no exista un caso “flotando” entre dos responsabilidades.

Comprueba invariantes

Una invariante es una condición que debe mantenerse aunque cambien las rutas. No necesitas formalismo matemático para aprovechar el concepto.

Ejemplos:

• un presupuesto no se envía sin identificador de cliente;
• ningún caso puede estar simultáneamente cerrado y requiere_aprobacion;
• una solicitud cancelada no genera nuevas acciones comerciales;
• una aprobación solo afecta a la versión concreta del borrador que se revisó.

Las invariantes se convertirán después en casos de prueba y controles de implementación.

Ejercicio: diseña la máquina de estados

Usa el perímetro definido en la lección anterior. Entrega:

1. lista de estados;
2. estados terminales;
3. tabla de transiciones;
4. responsable de cada estado;
5. eventos de entrada y salida;
6. tres invariantes críticas;
7. una decisión que seguirá siendo humana en la primera versión y el motivo.

No avances si existen transiciones como “hacer lo necesario” o “validar manualmente” sin especificar quién las ejecuta y qué resultado producen.

Entregable

El entregable es un workflow objetivo cuya ejecución puede seguirse caso a caso. Ya sabes qué estados existen, qué eventos los conectan, quién responde de cada uno y qué condiciones nunca deben romperse. El siguiente paso consiste en definir la forma exacta de los datos y eventos que cruzan esas fronteras.