Cuando un sistema muestra opciones como “pendiente”, “en proceso”, “aprobado” o “cerrado”, parece estar resolviendo algo simple. Sin embargo, detrás de esas etiquetas hay una decisión importante: definir qué puede pasar con cada registro, quién puede hacerlo y qué condiciones deben cumplirse.
Si esas reglas no se diseñan antes, el software termina reflejando improvisaciones: casos que saltan pasos, registros cerrados sin revisión, tareas que nadie puede retomar y estados que significan cosas distintas para cada persona. Esta guía propone un método para diseñar un flujo útil sin convertir una operación cotidiana en un laberinto.
Empezá por el objeto que cambia, no por las pantallas
Un flujo describe la evolución de un objeto concreto: una solicitud, un pedido, una factura, una incidencia, una inscripción o un expediente. Antes de pensar en botones, completá esta frase: “Queremos saber en qué situación está cada ___ y qué falta para resolverlo”.
El concepto de máquina de estados ofrece una base práctica: representa el comportamiento mediante estados conectados por transiciones que ocurren ante eventos. No hace falta dibujar modelos complejos para aprovechar la idea; alcanza con usarla para separar con claridad la situación actual de una acción que cambia esa situación. La especificación UML de OMG describe precisamente este enfoque de estados, transiciones y eventos.
Definí pocos estados que respondan una pregunta operativa
Un buen estado responde: ¿en qué situación verificable está este caso ahora? No debería ser una nota vaga ni el nombre de una persona. Por ejemplo, para solicitudes de compra podrían servir: borrador, enviada, en revisión, aprobada, rechazada, recibida y cancelada.
- Borrador: todavía puede modificarse sin iniciar el circuito.
- En revisión: requiere una comprobación definida.
- En espera: falta información o una respuesta externa.
- Resuelto: el objetivo se cumplió y no quedan acciones normales pendientes.
- Cancelado: el caso no seguirá adelante, con un motivo registrado.
Evitar estados como “varios”, “urgente” o “hablar con Juan” ayuda a no mezclar situación, prioridad y asignación. Esos datos pueden existir, pero en campos distintos.
Un estado útil no cuenta toda la historia: indica cuál es la próxima decisión posible.
Escribí cada transición como una regla comprobable
El paso relevante no es solo el estado, sino la transición: el cambio desde un estado hacia otro. Para cada una, definí cinco elementos:
- Origen y destino: de “en revisión” a “aprobada”.
- Disparador: aprobar, enviar, cancelar, vencer un plazo o recibir un dato.
- Responsable: qué rol o integración puede ejecutarlo.
- Condiciones: qué debe existir o validarse antes.
- Consecuencia: qué se guarda, notifica, crea o bloquea después.
Por ejemplo: “Una solicitud pasa de en revisión a aprobada cuando un aprobador asignado confirma la decisión, el importe está informado y se registra fecha, usuario y comentario opcional”. Esa frase permite conversar con operación, diseño y desarrollo sin depender de interpretaciones.
Diseñá excepciones y finales desde el principio
Los procesos reales no siempre avanzan en línea recta. Puede faltar información, vencer una solicitud, detectarse un error o requerirse volver a una etapa anterior. No hace falta anticipar toda excepción imaginable, pero sí las frecuentes, costosas o riesgosas.
La documentación de AWS Step Functions ilustra una distinción útil: algunos estados realizan trabajo, otros deciden entre caminos, esperan, o finalizan correctamente o con error. Trasladado a un sistema de negocio, esto invita a distinguir una tarea pendiente de una decisión, una pausa y un cierre definitivo.
Revisá especialmente estas preguntas:
- ¿Qué ocurre si alguien carga datos incorrectos?
- ¿Quién puede reabrir un caso y bajo qué motivo?
- ¿Un registro cancelado puede volver al circuito?
- ¿Qué estados son terminales y cuáles admiten retorno?
- ¿Qué sucede si nadie actúa durante un plazo acordado?
Probalo con casos reales antes de automatizar
Tomá entre cinco y diez casos recientes, incluyendo uno normal, uno urgente, uno incompleto y uno que terminó mal. Recorré el flujo paso a paso y anotá cada duda. Si el equipo no sabe qué estado elegir o quién debe moverlo, el problema no se arreglará agregando más botones.
También conviene medir señales simples: cantidad de casos detenidos por estado, tiempo hasta la resolución, reversiones y motivos de cancelación. No son métricas para vigilar personas; sirven para detectar reglas confusas, cuellos de botella o trabajo que todavía ocurre fuera del sistema.
Conclusión: primero claridad operativa, después automatización
Un flujo bien diseñado hace visible el trabajo sin obligar al equipo a adaptarse a etiquetas arbitrarias. Empezá con pocos estados, documentá transiciones concretas, tratá las excepciones como parte del proceso y validá el modelo con casos reales. Recién entonces decidí qué avisos, validaciones o automatizaciones vale la pena construir.
Si tu proceso depende de planillas, mensajes y decisiones difíciles de rastrear, un software a medida puede convertir esas reglas en un sistema claro, con el alcance adecuado para tu operación.
