Antecedentes:
- El framework tiene que servir al problema y nunca al revés
- Lo que no se puede explicar no se entiende. Lo que no se entiende no se puede implementar ni arreglar
Requisitos:
- Cada artefacto tiene un ciclo de vida diferente para cada actor
- Cada actor cuando tiene que gestionar el artefacto debe tener a disposición todos los datos necesarios para operar sobre él
- Debe estar abierto a automatizaciones pero siempre tenemos que basarnos en el humano para modelar la operación
El proceso de diseño tiene que ser natural, ya que una de las cosas que se persigue con este enfoque es que esté hecho por y para la gestión de casos extremos por personas (ya que esto se nos da mucho mejor que a las máquinas).
Yo he identificado que este patrón es el que suelo seguir mentalmente y que más me ayuda
- Identificar los actores
- Identificar el artefacto clave
- Empezar a modelar el ciclo de vida del artefacto a ojos de cada actor. Lo más importante de esto es ver qué datos ve y modifica cada actor en cada estado propio
- Ir añadiendo otros artefactos si es necesario y modelando y encajando su ciclo de vida con los anteriores
Empezamos…
Vamos a modelar e implementar el sistema de operaciones de una empresa de fabricación.
Los actores son el departamento comercial, administración y el taller. Para cada uno de estos actores cada artefacto tendrá un ciclo de vida diferente.
El artefacto clave va a ser el pedido. Es un concepto de empresa que los tres actores van a comprender perfectamente.
Ahora vamos con los ciclos de vida, recordemos que el ciclo de vida es un camino posible entre estado. Es un ejercicio de pensar en posibilidades, no en previsión del flujo completo.
El pedido puede estar en estados como propuesto, confirmado, pendiente de documentación, en fabricación, entregado, facturado, cobrado, cancelado. Cada actor (comercial, administración, taller) interpreta y actúa sobre esos estados según sus responsabilidades, de modo que el mismo artefacto se percibe de manera distinta en cada área y no como un simple traspaso de testigo entre departamentos.
Cada departamento tiene su ciclo de vida y es agnóstico de las «cajas negras» de algunos de sus estados que pueden estar hechos de ciclos de vida completos de otros departamentos.
Además, cada estado dentro de cada departamento tiene unos datos claves asociados solo a ese estado. A la hora de la operativa, este es el punto realmente importante. Que el humano o agente que gestione esto tenga por un lado todos los datos del artefacto completo para hacerse una idea de cómo va y por otro, que en cada estado se pidan los datos necesarios para operar sobre él. Ni más, ni menos.
Matamos dos pájaros de un tiro:
- Información completa para hacerse una composición de lugar. Sin silos de información.
- Los datos justos en el momento correcto. No pedir datos dos veces ni quedarnos sin datos claves
El del departamento comercial sería algo así:
El de administración:
El del taller:
Los casos que añaden valor son estos:
- Si en algún momento el comercial recibe modificaciones del pedido, no lo vamos a hacer pasar por la verificación administrativa, solo por los pasos cuyos datos necesiten ser actualizados por esta modificación. Estas modificaciones parciales son los principales generadores de variabilidad.
- Gestión de estados paralelos sin necesidad de sincronización perfecta ya que cada actor sabe por dónde va en su propio ciclo de vida.
Para un proceso tan simple e intuitivo (que da pereza hasta modelar), los que hemos modelado algo en BPMN nos echamos a temblar cuando empezamos a ver las desviaciones del happy path.
Pero de este modo, basándonos en los artefactos, ciclos de vida y datos parece algo totalmente natural. Un proceso que cualquier humano que lo gestione lo comprende perfectamente.
Llegó lo bueno, esto es una mini-app que he vibecodeado para que podamos trastear un poco con este enfoque. He intentado que sirva para comprender cómo funcionaría una empresa con esto y que os cueste menos tiempo y trabajo haceros una idea práctica de cómo funcionaría.