Estamos pasando de un paradigma de operaciones empresariales donde reinaba el taylorismo a uno donde va a reinar la gestión de procesos de alta variabilidad.

Esto hace que el enfoque de modelado de procesos de negocio centrados en el proceso se quede inoperativo cuando lo enfrentemos a este otro tipo de casuística más compleja.

¿Por qué no sirve? Porque no escala bien cuando la aparición de excepciones es la norma ya que obliga a crear nuevos caminos para cada excepción. Si os habéis enfrentado al modelado de un proceso con excepciones os sonarán las frases como «Eso pasa muy poco», «Vamos a aplicar el 80/20» o «Vamos a definir primero el camino normal y eso ya lo haremos después».

Cuando eso nos da un proceso que finalmente acaba siendo inútil, nos da una pista de que puede que hayamos querido modelar un proceso más complejo de lo normal con una herramienta que no está hecha para eso.

Por este motivo, se propone usar el enfoque artifact-centric. ¿Por qué? ¿Qué tiene de especial?

Primero, que al estar centrada en el dato en todo momento tenemos todos los datos necesarios para decidir qué hacer con el artefacto.

Segundo, que al definir un ciclo de vida posible, sin intentar prever lo que pasará nos da mucha flexibilidad para poder gestionarlo y que sea principalmente el humano quién decida qué hacer con él. Esto resuelve también la gran cantidad de posibles excepciones ya que irá pasando de estados a otros y podremos ver en todo momento cómo está el artefacto y podremos decidir sobre él.

Comprendido esto, podemos pasar a ver el framework BALSA que nos lleva a contemplar la panorámica completa de este enfoque artifact-centric.

BALSA significa Business Artifacts, Lifecycles, Services (tasks) y Associations.

• Business Artifacts: el objeto de negocio cuyos datos queremos trabajar. Como me explicaba Sylvia, es un expediente completo con los que un humano puede hacerse una composición de lugar.
• Lifecycle: los estados por los que pasa este artefacto desde que se crea hasta que se destruye. Aquí la diferencia frente al process-centric es que no predecimos el flujo que seguirá entre estados, solo definimos los posibles caminos que hay de unos estados a otros. Además un punto muy interesante que me dio Sylvia fue la visión de que hay tantos ciclos de vidas como actores implicados, ya que cada actor ve el ciclo de vida del artefacto respecto a lo que a él le interesa (Este punto de vista es muy potente).
• Services (tasks): las tareas que hacen evolucionar los datos del artefacto.
• Associations: las restricciones que imponemos de funcionamiento sobre cómo estas tareas afectan al artefacto y a su ciclo de vida.

Desde este punto de vista podemos empezar a ver la luz sobre cómo podemos modelar funcionamientos de negocio con esta herramienta.

Aunque como también me comentó Sylvia, la mejor forma de modelar procesos nuevos es de la forma más natural que salga.

Aquí no voy a no hacerle caso, si no que voy a comentar formas de poder concebir estas partes del modelado que puede que nos sean más cercanas.

El artefacto se podría modelar como un diagrama entidad-relación donde se definirían los datos que contiene un artefacto.

El ciclo de vida lo podemos ver como un diagrama de estados donde definimos los posibles estados y caminos entre ellos.

Las tareas son el trabajo que hay que realizar sobre el artefacto para ir operando sobre él.

Las Associations son restricciones sobre las acciones de las tareas como posibles condicionantes de valores o el mismo orden de ejecución de esas tareas en un cierto estado.

Terminando, el framework BALSA nos ayuda a comprender todas las partes que entrarían en juego en la definición de un proceso artifact-centric. Estas serían los artefactos, el ciclo de vida, las tareas y las restricciones.

Con esto, podríamos empezar a definir modelos para operar PAVs (procesos de alta variabilidad) al poder gestionar miles de excepciones sin así tener que definirlas de antemano. Además aprovechamos la gestión de estas excepciones para poder incluir agentes estocásticos como LLMs o simplemente complejos como humanos, sin miedo a que todo se rompa.

La semana que viene será mucho más práctico y exploratorio ya que intentaré pondré en producción una aplicación que corra bajo esta lógica.