Los sistemas de gestión de procesos de negocio BPM (ver iniciativa BPMi de la OMG - Business Process Management Initiative -), antes conocidos como sistemas de work-flow, no acaban de materializar las grandes expectativas depositadas en ellos, siendo pocos los casos de éxito.

El problema principal es la incapacidad para modelar la esencia del modelo de negocio que se esconde "detras del escenario"; incapacidad habitualmente solventada desde costosas integraciones con otros sistemas ERP externos.

El desarrollo de sistemas DynaGent permite diseñar procesos BPM limpios, centrados en la esencia del negocio, reducidos y sostenibles, robustos y ágiles ante el cambio. Esto es posible gracias a la capacidad de modelar unificadamente todos los aspectos de una organización, incluido los flujos de trabajo. Así, con DynaGent, gran parte de las secuencias o nodos, habituales en los diseños BPM, son obviados por ser deducibles a partir de ciertos aspectos, o dimensiones, del modelo de organización de fondo.


Los flujos BPM se pueden anidar en módulos, pero siempre el programador debe contemplar todos los casos posibles en un único hilo de programación. A este tipo de programación se denomina "imperativa". Los sistemas de este tipo exigen la programación combinada, a la vez, en un único hilo de programa, de todos los casos presentes en los distintos aspectos del flujo.

La interrelación de varios aspectos de negocio, en un mismo código, o hilo de programación, se conoce como puntos de entrelazamiento, y resultan en alta rigidez en el código. En general, para evitarlo, son necesarios sistemas basados en reglas, sistemas conocidos como "declarativos" (frente a los imperativos), donde sea posible el modelado de aspectos de forma aislada y la programación de reglas independientes que controlen cada aspecto por separado.

Incluso muchas de las tareas que habitualmente se “dibujan” en un BPM, pueden ser modeladas como transiciones válidas de una máquina de estados en un sistema de reglas, exigiendo mucho menor mantenimiento evolutivo. En la siguiente figura se aprecia el tratamiento en aspectos aislados como distintas dimensiones de la lógica de negocio que coexisten.



El sistema DynaGent permite modelar separadamente los siguientes aspectos de un negocio:
1. Unificación de modelo de solicitud-pedido-proveedor-catálogo
2. Modelo de autorizaciones en cascada
3. Flujos y máquina de Estados en asignación de responsabilidades
4. Secuencias BPM de negocio


La mayoría de sistemas ERP soportan, de forma incrustada, sofisticados procesos de pedido/albarán/catálogo de productos y servicios/proveedores, y sin embargo, los sistemas de flujos de trabajo se basan en pobres modelos de “solicitudes” que no se benefician del modelo de pedido de un software ERP, por el contrario, las integraciones BMP-ERP se tratan como sistemas externos a interconectar entre sí, valiéndose de interconexiones que se adaptan a medida de cada flujo. El resultado:

- la necesidad de un esfuerzo de interconexión y adaptación añadida,
- lógica/datos duplicados entre software ERP y BPM,
- y código BPM entrelazado y rígido desarrollado a medida por no permitir la programación de aspectos de forma aislada.

La propuesta de DynaGent para dar soporte a procesos de negocio comienza por ampliar “las clases” de conceptos “a pedir” desde el flujo básico de pedido/proveedor de un ERP. En general las ontologías en las que se basa DynaGent permiten especializar cualquier concepto, en particular es posible especializar artículos de un catálogo para modelar productos muy verticales, o como en este caso, ampliar el modelo de catálogo con autorizaciones/derechos/títulos (ver figura) presentes en la mayoría de los flujos.




El sistema DynaGent permite modelar el “derecho” o autorización a, por ejemplo un proyecto, como parte de un catálogo de recursos proporcionados por un departamento o rol corporativo, departamento que actuaría como proveedor de dicho recurso.

Mediante reglas es posible definir distintos niveles o capacidad de autorización, por ejemplo en base el importe total, el tipo de proyecto, la zona, etc. Así mismo es posible modelar las distintas condiciones que debe cumplir un proyecto para ser autorizado por cada rol y capacidad de autorizar. Así el sistema de forma genérica administra los flujos de autorización, por niveles, en base al tipo de proyecto, no siendo necesario que el programador BPM incruste esta lógica en el flujo diseñado (ver figura siguiente).



Existe una dimensión o aspecto adicional que afecta al flujo de tareas dentro de una organización, como es todo el proceso de aceptación/reasignación/trasferencia/rechazo/diagnóstico de una tarea pendiente entre distintos usuarios de igual o distinto rol o departamento.

Así, por ejemplo en una gestión de incidencias, un usuario puede rechazar una tarea asignada reclasificando el asunto como argumento de rechazo. En otras ocasiones puede ser válido “un rebote” en la asignación de tareas por falta de recursos temporales para acometer una tarea (balanceo). Todos estos actos modifican el flujo de tareas y conviene tratarlos como una máquina de estados de transferencia de responsabilidades mediante reglas, no siendo necesario diseñar toda la combinación de secuencias BPM posibles.


Por último, es necesario modelar la lógica de negocio “pura” que, habitualmente, impone la interacción con terceros, como pueda ser, por ejemplo, un registro civil, una subcontrata, etc., que exige una secuencia de acciones encadenadas. Este es el aspecto esencial o “de negocio” de un flujo, y que justifica un modelado BPM. Por tanto el enfoque DynaGent nos permite centrarnos aisladamente en el negocio a modelar, en cada aspecto por separado, sin ser necesario incrustar en el BPM de negocio aspectos y flujos de carácter organizativo, y que suelen ser aspectos reutilizables en distintos BPM de negocio, resultando en un código BPM "limpio", reducido y sostenible, robusto y ágil ante los cambios organizativos y estratégicos corporativos.