Aunque no es estrictamente un proceso implementable desde el punto de vista de la gestión, vamos a describir el proceso de modelado de un proceso con BPMN.
Antes comenzar a describir el siguiente diagrama, recordemos algunos símbolos de BPMN.
El momento justo antes de iniciarse el proceso. Es un estado, algo que ha ocurrido.
O XOR. En base al valor de ciertas variables, solo uno de sus flujos de salida se activará —el primero que evalúe a cierto su condición—. Debe definirse un flujo por defecto para evitar que no se active ninguno. Por lo general, tendrá otra compuerta de mezcla, de "cierre"; aunque puede no utilizarse, en muchos casos es necesario para que el diagrama no sea confuso.
O AND. No necesita variables ni condiciones puesto que todos los flujos de salida se activarán. Se dice que es una compuerta de separación (split), entra un token de datos y salen varios clones de ese token. Por eso, en la mayoría de los casos, necesita una segunda compuerta de mezcla (merge) y sincronización que vuelve a unificar ese token original.
U OR. Vuelve a ser una compuerta que activa aquellos flujos que hacen verdadera una condición, habitualmente basada en expresiones con las variables del proceso. En este caso todos, algunos o incluso ningún flujo puede activarse. De ahí que sea altamente recomendable definir un flujo por defecto. Igual que con la compuerta AND, en la mayoría de los casos es necesaria una compuerta adicional de mezcla.
Utilizada en los niveles descriptivos del proceso, no tiene un tipo asignado.
Es necesaria la intervención de un operador, rellenando y enviando un formulario web.
Tarea de ejecución automática, normalmente por un script en el lenguaje de programación base de la plataforma de desarrollo. Groovy, Javascript, Java...
Estas tareas se instancia tantas veces como sea necesario. Por decirlo de otra forma, se ejecutan varias veces, mientras que las tareas "normales" solo se ejecutan una vez.
En ocasiones por simple desarrollo top-down, en el que pasamos de una definición genérica a otra específica, en ocasiones por lógica de negocio, ciertas tareas se agrupan en subprocesos integrados dentro de un proceso padre. En nuestro caso, porque todas estas tareas se repetirán varias veces —instancia múltiple, tantas veces como tareas a configurar haya—.
Se comportan igual que una tarea simple, solo que, internamente, tienen la complejidad de un flujo de secuencia: un proceso dentro de otro proceso.
Estos eventos no afectan en nada al proceso, son un recurso estético para enlazar diversas partes de un diagrama excesivamente complejo para una única página.
Visión de alto nivel, resumida, de todo el proceso. Se evita la lógica de negocio compleja que se describirá en los siguientes niveles de complejidad.
En general —aquí ya depende del estilo de cada diseñador— comenzaremos con la ficha del proceso, una descripción textual del objetivo del proceso y el detalle de sus tareas o actividades. Aquí lo presentamos como texto estructurado, más adelante utilizaremos un formato tabla. Lo importante no es el formato sino la información que ofrezcamos.
Hablando así, en general, los pasos básicos son:
Definir, si no se ha hecho previamente, el modelo de datos de negocio (BDM)
Dibujar el diagrama
Declarar las variables del proceso, habitualmente variables de negocio
Configurar la instanciación, que consiste en
Definir el contrato de instanciación del proceso y
Definir el formulario de instanciación
Para cada tarea de intervención humana definir el contrato a partir de las variables del proceso y
Generar el formulario de la tarea
A la hora de crear formularios podemos decidir no hacerlo, dejar a Bonita que vaya creando formularios básicos cada vez que ejecutamos, Esto viene bien para hacer una prueba rápida de nuestro proceso y dejar para más tarde la personalización de formularios.
Entiéndase que queremos ofrecer una pauta genérica, no se hace referencia a muchos aspectos del modelado y configuración de procesos en Bonita, como las compuertas, sin ir más lejos, u otros tipos de tareas.
FECHA INICIO: 01/07/2019 MODIFICADO: 07/07/2021
RESUMEN: definición básica del proceso de desarrollo de un proceso. Muchos de estos pasos (tareas) deben llevar la coletilla "si fuera necesario", depende de cada caso concreto, pero este es el escenario básico general que vamos a abordar.
No se contemplan algunas otras tareas, entre ellas la definición de la organización, y el manejo de restricciones en el proceso en general y en las tareas en particular.
RESPONSABLE*: Profesorado GPS
* en este punto de la descripción del proceso, por responsable entendemos al "dueño" del proceso, al encargado o encargados de su diseño; no debe confundirse con el responsable de cada tarea, que viene a ser la persona o grupo de personas que la deben ejecutar.RESPONSABLE: desarrollador
DESCRIPCIÓN
El modelo de datos de negocio (BDM, Business Data Model) es la estructura que almacenará los valores generados durante el proceso. En general, tiene forma de tabla de base de datos relacional, por lo que definiremos las columnas necesarias y el tipo de datos de cada una. En procesos más complejos, definiremos varias tablas o será el propio sistema (Bonita) el que las cree.
Este paso previo es necesario para poder definir, posteriormente, variables de negocio, cuyos valores se almacenarán como filas en estas tablas de forma persistente.
Si bien es previo a esa definición de variables, puede hacerse en paralelo al dibujado del diagrama en el orden que queramos.
ENTRADAS: diseño del esquema lógico relacional (tablas)
SALIDAS: uno o varios BDM disponibles para definir variables de negocio
RESPONSABLE: desarrollador
DESCRIPCIÓN
Aunque para algunas de las tareas posteriores no es necesario tenerlo completado, sí que es imprescindible haber creado el diagrama al menos. En todo caso, es preferible dibujar todo lo que se pueda aunque lo modifiquemos después por cualquier razón.
ENTRADAS: diseño del proceso
SALIDAS: diagrama BPMN
RESPONSABLE: desarrollador
DESCRIPCIÓN
Se definen aquí las variables de negocio y de proceso, las que tienen como alcance todo el proceso. En especial, las de negocio son las basadas en el BDM previamente definido, y constituyen los datos persistentes del proceso. Las variables de proceso, con igual alcance, son variables de trabajo que no nos interesa almacenar en base de datos.
Un efecto importante de las variables de negocio es que son las únicas que se pueden ver al examinar el caso una vez terminada la ejecución del proceso.
ENTRADAS: diseño del proceso
SALIDAS: variables de negocio y proceso definidas
RESPONSABLE: desarrollador
DESCRIPCIÓN
Muchos de nuestros procesos comenzarán con un formulario de introducción de datos, una solicitud, por ejemplo. En un plano más técnico, constituye la creación de las variables en memoria y la asignación de sus valores iniciales. Esto último también puede conseguirse sin formulario de instanciación, si el proceso lo requiere.
Tal y como está diseñado BonitaBPM, el uso de formularios y la recogida de los datos que introducimos en ellos necesita de un artefacto que llaman contrato. La inicialización de variables depende de dicho contrato.
ENTRADAS: diseño del proceso, variables
SALIDAS: contrato y formulario de instanciación, y script de inicialización de variables.
RESPONSABLE: desarrollador
DESCRIPCIÓN
Las tareas del proceso han de configurarse en función de su tipo y necesidades: conectores de entrada y salida, contratos, formularios, operaciones y, en determinados casos, otros parámetros particulares.
En realidad, modelamos tareas y eventos, aunque la mayor parte del trabajo es con las primeras.
ENTRADAS: diseño del proceso, diagrama, variables
SALIDAS: tareas configuradas
RESPONSABLE: desarrollador
DESCRIPCIÓN
Cuando todo está preparado, el proceso se despliega y se ejecuta. Desplegarse consiste en añadirlo al servidor web para su ejecución. Aún estando en Bonita Studio se produce ese despligue aunque sea en el servidor de desarrollo. Tiene más importancia en servidores en producción ya que determina que un proceso ha sido suficiente probado y está preparado para los usuarios finales.
En un entorno de desarrollo como el que estamos utilizando, esta tarea es, realmente, la prueba sistemática de nuestro proceso.
ENTRADAS: proceso desarrollado
SALIDAS: resultados de la ejecución
A continuación, el diagrama BPMN que establece la secuencia de todas las actividades descritas.
Una vez descrito el modelado de procesos de forma genérica, vamos a introducir algo más de lógica de negocio, en este caso, simplemente detallar un poco más en qué consisten algunas tareas y subprocesos. Aún así, sigue siendo una descripción somera que no tiene en cuenta muchos aspectos del desarrollo. Por ejemplo, no diremos nada de eventos o de la resolución de errores al modelar y probar del proceso; y muy poco de tareas que no sean de intervención humana. Sirva, nada más, para hacernos una idea general del proceso de modelado.
BonitaBPM es un entorno low code. Esto significa que no necesitamos programar, al menos para la mayoría de situaciones y problemas a resolver mediante el despliegue de un proceso. El entorno nos proporciona herramientas que generan automáticamente el código necesario para que todo funcione y, además, lo deja preparado para su ejecución. Es por ello aún más importante tener claros una serie de conceptos a la hora de poner en marcha nuestro proceso.
Un proceso se instancia en el evento de inicio. Una situación muy común es empezar con un formulario inicial, por ejemplo la solicitud de un servicio —aunque no es obligatorio hacerlo así, podemos diseñar procesos sin formulario de instanciación—. En el momento en que pulsemos el botón "enviar" del formulario, se instanciará la variable de negocio; la variable de negocio recogerá los primeros datos necesarios para el funcionamiento del proceso. La instanciación, si lo queremos ver así, está asociada el evento de inicio del proceso.
La variable de negocio se basa en un modelo de datos de negocio definido previamente. Es una estructura que contiene un conjunto de atributos, cada uno de un determinado tipo de datos. Algo así como un vector de variables o la definición de una tabla de base de datos.
La variable de negocio está accesible durante todo el proceso y puede ser persistente. Las variables de proceso dependen de su ámbito de declaración y se destruyen una vez finaliza el proceso.
Los contratos son una herramienta de BonitaBPM que permite declarar qué variables se van a utilizar en un formulario. El lema es —al menos en los casos más habituales— "si vas a utilizar un formulario, necesitas un contrato".
Las operaciones, entre otras cosas, sirven para recuperar los datos introducidos en un formulario de tarea y asignarlos a las variables del proceso, de negocio o de otro tipo, y poder trabajar con esos valores. Normalmente, al definir contrato y formulario en una tarea, se generan las operaciones automáticamente, pero podemos editarlas, eliminarlas o añadir otras.
Los contratos y formularios son propios de tareas de intervención humana. Otros tipos de tarea no necesitan contrato.
Para procesos en desarrollo, Bonita BPM proporciona:
UIDesigner para la creación de formularios
Portal, como aplicación web de gestión donde, entre otras cosas, podemos tomar control de un proceso en ejecución y comprobar sus resultados finales.