Documentación oficial de ADONIS
En esta página se dará una descripción de los aspectos básicos de modelado que se deberían de utilizar en el contexto de MEDEA v2.0. Para una descripción completa de las posibilidades de ADONIS respecto a BPMN se puede mirar la documentación oficial:
1. Creación de modelos de proceso de negocio
Permisos para la creación de modelos
Para poder crear cualquier modelo en ADONIS (y de procesos de negocio en particular), es necesario tener una licencia asignada en el escenario "Diseñar y Documentar", así como los permisos adecuados en el grupo de modelos en el que se quieren incorporar los mismos.
Por defecto, todos los Responsables Técnicos Principales de proyectos en PORTICO deberían de tener permisos para poder modificar la estructura del grupo "Universidad de Murcia→ Inventario de Trámites".
Para crear un modelo, podemos realizarlo de cualquier de las siguientes maneras:
- Pulsando sobre + Nuevo en la barra superior de herramientas:
- En este caso, seleccionamos Modelo del Proceso de Negocio:
- Una vez abierto el editor, deberíamos ponerle un nombre al diagrama en la parte superior de la pantalla que aparece.
- La primera vez que pulsemos sobre GUARDAR, se nos pedirá la ubicación del Grupo de Modelos en el que debemos guardar el modelo, pudiendo incluso crearlo en ese momento si fuera necesario.
- Pulsando con el botón DERECHO del ratón sobre el grupo de modelos en el que queremos incorporar el modelo,
- Hacer clic sobre "Crear modelo en grupo":
- A partir de aquí, los pasos son parecidos al caso anterior, teniendo que seleccionar el diagrama "Modelo del Proceso de Negocio" y estableciendo el nombre del modelo.
2. Creación de roles participantes en el proceso
Comprobación de roles ya existentes
Antes de crear un rol, debemos asegurarnos que no existe previamente en la herramienta. Para eso, podemos buscarlo en el árbol de Objetos de la parte izquierda:
Por ejemplo, en mi proceso quiero utilizar el Rol "PDI", y no estoy seguro de si existe; debería realizar la siguiente búsqueda:
Como se ve, hay varias entradas relativas a roles de PDI, que es posible que pueda utilizar directamente.
Si necesitamos crear un rol para nuestro proceso, deberemos situarnos en el árbol de objetos, en UNO de estos dos grupos de objetos:
- Objetos → Universidad de Murcia → 01. Estructura → *
- Objetos → Universidad de Murcia → 03. Roles transversales
- Objetos → Universidad de Murcia → 03. Roles transversales
- Objetos → Universidad de Murcia → 08. Unidades Organizativas responsables
- Objetos → Universidad de Murcia → 09. Unidades Gestoras del trámite
Y pulsar con el BOTON DERECHO del ratón, para seleccionar "Crear objeto en grupo":
En la ventana siguiente, seleccionaremos "Rol":
En la ventana que se nos abrirá a continuación, lo único requerido e imprescindible es rellenar el nombre:
Información sobre los roles
Como se podrá ver, es posible guardar una gran cantidad de información sobre los roles; pero de momento solo estamos utilizando este mecanismo para crearlo y únicamente estamos guardando el Nombre.
3. Elementos de sistemas TI utilizados en el proceso
Comprobación de elementos TI ya existentes
Antes de crear un nuevo sistema de TI, debemos asegurarnos que no existe previamente en la herramienta. Para eso, podemos buscarlo en el árbol de Objetos de la parte izquierda:
Por ejemplo, en mi proceso quiero utilizar el software "Sede Electrónica", podríamos realizar la siguiente búsqueda:
Como se ve, hay varias entradas relativas a Sede Electrónica, que podrían utilizarse en el proceso.
Si necesitamos crear un elemento de TI para nuestro proceso, deberemos situarnos en el árbol de objetos, en UNO de estos dos grupos de objetos:
- Objetos → Universidad de Murcia → 02. Infraestructura TI → *
Y pulsar con el BOTON DERECHO del ratón, para seleccionar "Crear objeto en grupo":
En la ventana siguiente, seleccionaremos "Aplicación":
En la ventana que se nos abrirá a continuación, lo único requerido e imprescindible es rellenar el nombre:
Información sobre los elementos TI
Como se podrá ver, es posible guardar una gran cantidad de información sobre los elementos TI; pero de momento solo estamos utilizando este mecanismo para crearlo y únicamente estamos guardando el Nombre.
4. Inicio del proceso
El inicio de un proceso se indica en BPMN con lo que se denomina un Evento de Inicio. Este representa la circunstancia que provoca el comienzo del proceso. A veces también se llama un disparador (trigger) del proceso.
Se representa con un círculo de línea continua fina, y a su vez pueden existir de diferentes tipos en BPMN, aunque nosotros, en el contexto del modelado de trámites, sólo vamos a utilizar los siguientes:
| Tipo de evento | Qué representa |
|---|---|
| Vacío | No es posible definir exactamente las circunstancias que provocan el evento o inicio del proceso. Este es el único que se permite en un subproceso. |
| Condicional | Representa que se tienen que dar ciertas condiciones para que el proceso comience. |
| Mensaje | El proceso comienza porque se recibe un mensaje externo. Este mensaje podría ser desde un correo electrónico, una invocación desde un servicio o aplicación externa, etc. |
| Tiempo | Representa un proceso que se repite periódicamente; por ejemplo, anualmente, en cada convocatoria, por plazos, etc. |
5. El flujo de secuencia
Todos los procesos tienen que tener un flujo continuo que conecta a través de flechas continuas TODOS los artefactos que existen en el proceso.
Es posible que en determinados momentos, este flujo se divida, pudiendo dirigirse el mismo por distintas "ramas", y posteriormente estos flujos se unan de nuevo. Pero en ningún caso, deben existir artefactos "sueltos", y que no tengan flechas que los conecten.
Los eventos de inicio SOLO tendrán una fecha de salida, mientras que los eventos de fin, SOLO tendrán una fecha de entrada. El resto de artefactos debería tener una flecha tanto de entrada como de salida, excepto los eventos intermedios de frontera (ver después), que pueden tener solo una flecha de salida.
El siguiente es un ejemplo de un flujo de secuencia correcto, en el que todos los eventos, tareas y gateways (veremos después) están perfectamente conectados):
6. Tareas, sus tipos y subprocesos
Una tarea representa una acción dada en un proceso. Se utilizan cuando no se quiere mostrar un nivel menor de abstracción en el proceso, o no se quiere descomponer a menor nivel; esto no significa que lo que representa la tarea no sea complejo, sino que simplemente es suficiente con mostrar ese nivel de detalle en ese punto del proceso.
Un subproceso representa una actividad compuesta, que podrá ser descompuesta en un nivel de detalle mayor.
Para el modelado de los trámites, utilizaremos los siguientes tipos de tareas y subprocesos:
| Tipo de tarea | Qué representa |
|---|---|
| Tareas manuales | No es posible definir exactamente las circunstancias que provocan el evento o inicio del proceso. Este es el único que se permite en un subproceso. |
| Tareas electrónicas | |
| Tareas automáticas |
Además, las tareas pueden marcarse con ciertas características que dan más detalle sobre las mismas. En el modelado de los trámites, nosotros utilizaremos las siguientes características:
| Característica en tarea | Qué representa |
|---|---|
| Ejecución paralela | |
| Ejecución en bucle (secuencial) |
Finalmente, los subprocesos pueden representarse de las dos siguientes maneras:
| Tipo de subproceso | Qué representa |
|---|---|
| Contraído | |
| Expandido |
7. Eventos intermedios
8. Bifurcando y convergiendo el flujo de secuencia: gateways
8.1. Decisiones exclusivas
8.2. Decisiones paralelas
8.3. Decisiones inclusivas
8.4. Fusión / convergencia de flujos de secuencia
8.5. Flujos de excepción que interrumpen
8.6. Flujos de excepción que no interrumpen
9. Eventos de finalización
