| Tabla de contenidos |
|---|
| Info | ||
|---|---|---|
| ||
Este proceso se debería iniciar en las etapas iniciales del proyecto, pues puede conllevar bastante trabajo durante el desarrollo del mismo. |
Diagrama
1. Identificación de trámites asociados al proyecto
| Advertencia | ||
|---|---|---|
| ||
El Inventariado de los trámites (procedimientos y servicios) que están asociados al producto que se quiere construir con el proyecto es un imperativo tanto LEGAL (Ley 39/2015) como técnico (para permitir la utilización de gran parte de los servicios y aplicaciones de Administración Electrónica de ATICA): necesitan un código de trámite de Inventario que se encuentre en estado PUBLICADO. |
| title | Imputación del tiempo trabajado |
|---|
El Responsable técnico principal debe crear una tarea en JIRA en el que imputará todo el trabajo realizado durante esta actividad, llamándola Inventariado y modelado de trámites asociados al proyecto. Esta tarea incluye todo el tiempo de gestión de este proceso, así como el análisis realizado con las herramientas de modelado. Si se considera necesario, se pueden crear subtareas específicas para cada trabajo.
| |
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
| Nota | ||
|---|---|---|
| ||
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
| Advertencia | ||
|---|---|---|
| ||
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:
| Info | ||
|---|---|---|
| ||
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
| Advertencia | ||
|---|---|---|
| ||
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:
| Info | ||
|---|---|---|
| ||
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 se representa a través de la conexión con flechas continuas de TODOS los artefactos que existen en el proceso.
Es posible que en determinados momentos, este flujo se divida (diverge), pudiendo dirigirse el mismo por distintas "ramas", y posteriormente estos flujos se unan de nuevo (converge). 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 lo que representan) están perfectamente conectados:
6. Tareas, sus tipos y subprocesos
6.1. Definiciones
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:
En ADONIS, podemos cambiar el tipo de la tarea haciendo clic sobre la misma, y luego seleccionando el icono de la llave inglesa:
| 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 | Representan la interacción de una persona con elemento TI |
| Tareas automáticas | Representan la ejecución automática a través de un sistema informático de una tarea, sin intervención humana. |
Además, las tareas y los subprocesos 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 | Esta tarea se ejecuta múltiples veces, incluido la ejecución paralela de la misma. Ejemplo: la solicitud paralela de múltiples interesados cuando se abre una convocatoria de empleo, etc. |
| Ejecución en bucle (secuencial) | Esta tarea se repite varias veces, pero de manera secuencial (bucle). |
| Nota | ||
|---|---|---|
| ||
En ADONIS, para poder marcar una tarea o un subproceso como una tarea paralela o una ejecución en bucle, debemos abrir la vista de PROPIEDADES (doble CLICK) , y buscar la pestaña Propiedades del objeto, que por defecto NO es visible. Para verla, pulsaremos en la primera pestaña por la parte superior, para seleccionar Mostrar todo:
Una vez realizado, ya tendremos acceso a esta pestaña (y otras adicionales):
|
Finalmente, los subprocesos pueden representarse de las dos siguientes maneras:
| Tipo de subproceso | Qué representa |
|---|---|
| Contraído | No se muestran los detalles internos del subproceso; éstos pueden mostrarse en otro diagrama y enlazándolo en este subproceso, tal como se describe en esta sección. |
| Expandido | Se pueden visualizar los detalles internos del subproceso directamente en este diagrama. Esto es especialmente útil cuando queremos poner eventos intermedios en la frontera del subproceso que interrumpan (o no) el mismo. Para poder mostrar un subproceso de manera expandida, debemos abrir la ficha de Propiedades del subproceso (doble CLICK), y en la pestaña Representación, marcar sobre Subproceso expandido:
|
6.2. Asignación de un rol a una tarea
| Info | ||
|---|---|---|
| ||
Aunque en BPMN no se dice nada sobre que tipos de tareas pueden tener un rol asignado, en el contexto del modelado de los trámites, nosotros SOLO asignaremos Roles a las tareas que son de tipo MANUAL o ELECTRÓNICA. Se entiende que las tareas automáticas no son realizadas por humanos, y por tanto no deberían tener un rol asignado. |
Para asignar un rol a una tarea, se puede realizar de dos maneras:
- Se abre en el panel lateral derecho el árbol de modelos. Buscamos el rol que necesitamos (o se crea si es necesario), y lo ARRASTRAMOS directamente sobre la tarea. Se mostrará la siguiente ventana contextual, en la que seleccionaremos Responsable:
- Otra manera es hacer doble CLICK para abrir el panel de Propiedades de la tarea, y buscar la pestaña Responsabilidades (RACI). En la sección Responsable , encontraremos el icono
, que nos permitirá buscar en el árbol de objetos para seleccionar el Rol deseado.
Si se quiere QUITAR un rol a una tarea, solo es posible a través del panel de propiedades, en donde deberemos pulsar sobre el rol que deseamos eliminar, y luego en el botón (X).
| Info | ||
|---|---|---|
| ||
Actualmente SOLO estamos utilizando el campo "Responsable" de la pestaña "Responsabilidades (RACI)" , que representa quién es el que ejecuta la tarea. Sin embargo, ADONIS soporta el modelo completo RACI, con el cual podríamos diferenciar y asignar 4 roles diferentes para cada tarea:
|
6.3. Asignación de un elemento de TI a una tarea
| Info | ||
|---|---|---|
| ||
En el contexto del modelado de los trámites, nosotros SOLO asignaremos elementos de TI a las tareas que son de tipo ELECTRÓNICA o AUTOMATICA. |
Para asignar un elemento TI a una tarea, se puede realizar de dos maneras:
- Se abre en el panel lateral derecho el árbol de modelos. Buscamos el elemento TI que necesitamos (o se crea si es necesario), y lo ARRASTRAMOS directamente sobre la tarea. Se mostrará la siguiente ventana contextual, en la que seleccionaremos Elementos de sistemas TI referenciados:
- Otra manera es hacer doble CLICK para abrir el panel de Propiedades de la tarea, y buscar la pestaña Sistemas/Productos. En la sección Elementos de sistema TI referenciados, encontraremos el icono , que nos permitirá buscar en el árbol de objetos para seleccionar el elemento TI deseado.
Si se quiere QUITAR un elemento TI a una tarea, solo es posible a través del panel de propiedades, en donde deberemos pulsar sobre el que deseamos eliminar, y luego en el botón (X).
7. Eventos intermedios
7.1. Clasificación de los eventos intermedios
Un evento intermedio es un evento que se dispara en mitad del flujo del proceso. Se representan con una doble línea continua, y pueden ser de diferentes tipos.
A su vez, estos eventos pueden clasificarse en:
- Eventos intermedios de flujo. Se ubican en mitad del flujo principal del proceso.
- Eventos intermedios del límite / frontera de las tareas/subprocesos. Estos se ubican en el borde de una tarea o un subproceso que se muestre de manera implícita. A su vez pueden ser de dos naturalezas: interrumpir o no interrumpir.
7.2. Eventos intermedios de flujo
Existen una gran variedad de eventos en BPMN, pero nosotros nos limitaremos a los siguientes:
| Tipo de evento intermedio de flujo | Qué representa |
|---|---|
| Evento intermedio de tiempo | Representa una parada de X tiempo en un proceso. Es como un "delay" en programación. |
| Evento intermedio de mensaje | Representa que el proceso queda parado hasta recibir un mensaje externo. |
7.3. Eventos intermedios de límite que interrumpen
Estos eventos se asocian a una tarea o a subproceso que se muestra de manera expandida. Se tienen que interpretar como que se lanzan si se produce el evento, interrumpiendo cualquier tarea a la que esté vinculado (o tareas si se trata de un proceso) , desviando el flujo por las tareas que vienen a continuación del evento.
| Nota | ||
|---|---|---|
| ||
Para poder visualizar los eventos intermedios de límite en ADONIS, es necesario mostrar todos los elementos de modelado en la paleta de iconos. Para ello, pulsamos sobre el segundo icono en la paleta de iconos cuando estamos modelando, y seleccionamos BPMN (Estandar):
Posteriormente, cuando queramos añadir el evento, debemos fijarnos que en la paleta que estamos seleccionando el evento intermedio (límite); este evento lo podemos arrastrar directamente sobre una tarea o sobre un subproceso, quedando así vinculado:
|
El siguiente ejemplo muestra un esquema de este tipo de eventos:
7.4. Eventos intermedios de límite que no interrumpen
Estos eventos se asocian a una tarea o a subproceso que se muestra de manera expandida. Se tienen que interpretar como que se lanzan si se produce el evento, pero no interrumpiendo cualquier tarea a la que esté vinculado (o tareas si se trata de un proceso) , generando un flujo paralelo con las tareas que vienen a continuación del evento.
| Nota | ||
|---|---|---|
| ||
Para cambiar un evento de límite a un evento que NO interrumpe, simplemente pulsaremos sobre el mismo, y pinchamos en la llave inglesa. Ahí buscaremos aquel tipo de evento que ponga sin-interrupción:
|
El siguiente ejemplo muestra un esquema de este tipo de eventos:
7.5. Ejemplo completo
El siguiente ejemplo de un proceso mas avanzado, muestra un escenario en el que se mezclan eventos intermedios de límite que interrumpen y que no interrumpen.
En el mismo, se interpreta que el Interesado tiene que acceder al contenido de una notificación en la carpeta ciudadana. A los 5 días, si no ha accedido, la tarea sigue activa para el usuario, pero se genera una tarea automática que envía un recordatorio de que tiene pendiente acceder. Si transcurren 10 días, la tarea dejará de estar disponible para el usuario (se interrumpen), y la carpeta ciudadana realizará un conjunto de pasos para rechazar la notificación, y en cualquier caso, se realizará la generación y firma del acuse de recibo o la de notificación rechazada.
8. Bifurcando y convergiendo el flujo de secuencia: gateways
8.1. Introducción a los gateways
Los gateways son artefactos que permiten "jugar" con el flujo del proceso, haciendo que se tomen caminos alternativos o paralelos (diverja) y luego estos caminos se junten cuando se considere necesario (converjan).
Se representan con un rombo que puede tener un símbolo en su interior, siendo este símbolo (o la ausencia del mismo) el que dice la naturaleza del gateway.
En ADONIS, se añaden desde la paleta de herramientas, desde uno de estos dos símbolos:
Posteriormente, es posible cambiar el tipo del gateway pulsando sobre la llave inglesa tras hacer clic en el gateway:
8.2. Decisiones exclusivas (basadas en datos)
Estas decisiones dividen el flujo y hace que continúe por una y sólo una de sus salidas, en base a una condición/pregunta que se pone en el artefacto, y las posibles respuestas que se ponen en los flujos salientes.
Cuando se ponen tras la división del flujo, sincronizan los flujos entrantes haciendo que continúe tras la llegada desde cualquiera de los flujos.
Ejemplo:
8.3. Decisiones paralelas
Estos gateways dividen el flujo en tantas ramas paralelas como se desee. No es necesario realizar ninguna pregunta en el gateway ni en las ramas salientes, pues el flujo se va a dividir sin ninguna condición.
Cuando se ponen tras la división del flujo, permiten sincronizar todos los flujos del proceso, haciendo que no continúe hasta que terminen todos los flujos entrantes. Es posible indicar en el diagrama que es un flujo convergente, pulsando sobre la llave inglesa y marcando "Convergente":
Ejemplo:
8.4. Decisiones inclusivas
Estos gateways dividen el flujo paralelamente de manera "inteligente", ejecutando aquellas ramas que cumplen cierta condición. Las preguntas y/o condiciones se ponen directamente en los flujos de salida.
Cuando se ponen tras la división del flujo, permiten sincronizar todos los flujos del proceso que se han abierto en el gateway divergente. Si se ejecutaron 3 ramas del proceso, este gateway convergente esperará hasta que se completen estas tres ramas para hacer que pueda continuar el proceso.
En ADONIS, para poder dibujar un gateway inclusivo, primero necesitamos poner un gateway paralelo, y posteriormente pulsando sobre la llave inglesa, lo transformamos en uno inclusivo.
También es posible marcarlo como Convergente, de manera similar al gateway paralelo.
Ejemplo:
9. Eventos de finalización
Un evento de fin representa un estado de finalización del proceso (o subproceso). Existen también diferentes tipos, aunque nosotros utilizaremos básicamente los siguientes:
| Tipo de evento de fin | Qué representa |
|---|---|
| Evento de fin vacío | No se quiere mostrar detalles adicionales sobre como acaba el evento. Representa un estado de fin. Es el único permitido en los subprocesos. |
| Evento de fin de mensaje | El proceso finaliza enviando un mensaje a un actor / entidad externa. |
| Evento de fin de terminación | Si se alcanza este evento de fin, representa que se finaliza CUALQUIER flujo abierto en el proceso. Es como un "kill -9" en LInux. Mata cualquier tarea abierta. |
Para CADA trámite identificado, se deberán repetir los pasos 2 y 3 que se describen a continuación.
1.1. Identificar el procedimiento administrativo en el que se utiliza el producto a construir
Desde un punto de vista formal, un Procedimiento Administrativo es:
- Una secuencia de trámites que finalizan en un acto administrativo en sentido amplio como declaración de la voluntad de la administración, esté o no sujeto a impugnación, siendo en este caso la Universidad de Murcia la que actúa como Administración Pública.
En la práctica, hay que pensar en un Procedimiento Administrativo como un proceso que:
- Se inicia por parte de un interesado o de oficio;
- Tiene una duración limitada en el tiempo,
- Incluye un conjunto de fases / etapas o actos administrativos.
- Acaba con un decisión tomada por la Universidad, normalmente expresada en forma de notificación, publicación en TOUM o en un diario oficial como el BORM o el BOE. Aunque es cierto que, aún no siendo correcto, en muchos casos identificaremos procedimientos que finalizan con una simple comunicación al interesado (por ejemplo un correo electrónico).
- Está vinculado a una serie documental, que es una entrada en el árbol de clasificación funcional de la Universidad de Murcia. Este vínculo lo establecerá el responsable de Archivo de la Universidad, y será revisado por la Comisión de Valoración y Expurgo.
- En el caso de procedimientos complejos, podría estar formado por procedimientos internos (en forma de subprocesos) o servicios.
- Tiene una norma y/o legislación reguladora, bien a nivel nacional, regional o de la propia Universidad.
| Advertencia | ||
|---|---|---|
| ||
Es posible que el producto que se esté desarrollando solo se utilice en uno de los sub-procedimientos o servicios que forman parte del procedimiento administrativo general. Aún así, y aunque requiera más esfuerzo, es NECESARIO identificar el procedimiento administrativo completo. |
Si el inventariado del procedimiento general es inabordable en ese momento, sería suficiente con al menos:
- Identificarlo y darlo de alta en Inventario.
- Modelar las fases generales, sin profundizar en ellas, entre las que se encontrará el sub procedimiento o servicio asociado a este proyecto.
- Identificar y dar de alta en Inventario en sub procedimiento o servicio específico a este proyecto.
- Modelar de manera completa esta parte.
- Completar el Inventario del sub procedimiento o servicio.
En el ejemplo siguiente , vamos a suponer que el proyecto actual es el desarrollo de una herramienta que facilite información a las empresas que se quieren presentar a una licitación de la Universidad de Murcia. Si no profundizamos lo suficiente, podríamos pensar que el procedimiento administrativo es la licitación y adjudicación de un contrato por parte de la Universidad de Murcia. Sin embargo, el Procedimiento Administrativo completo conlleva muchas más fases, tal como se puede ver en el siguiente mapa de procesos:
En nuestro caso, estamos centrando el desarrollo en la fase 02: Procedimiento de licitación y adjudicación de contratos, que por tanto deberemos modelar e inventariar. Pero además, deberíamos ser capaces de identificar (con ayuda de los responsables funcionales) el procedimiento completo, darlo de alta en inventario y al menos llegar a modelar un diagrama como el anterior, en el que se muestran todas las fases.
1.2. Identificar sub procedimientos y/o servicios
| Info | ||
|---|---|---|
| ||
| Definiremos un Servicio como una actuación administrativa que se agota en sí misma, constituida por esa única actuación . Ejemplos: pago de tasa, consulta de datos, descarga de solicitudes, emisión de certificados. |
Muchas veces, el trámite asociado al proyecto será un servicio. Por ejemplo, podríamos estar construyendo una aplicación que emite certificados de cualquier naturaleza para los usuarios (PDI, PAS, Estudiantes....).
Sería posible centrar nuestra atención en inventariar este servicio, pero hay que tener presente que el mismo formará parte (la mayoría de veces), de un procedimiento administrativo mayor, que hay que identificar tal como se refleja en el apartado anterior.
2. Impulso inventariado del trámite
En aras de impulsar el Inventariado de los trámites, el Responsable Técnico Principal deberá contactar con el responsable funcional de los mismos (en los proyectos de desarrollo suele coincidir con el Director del Proyecto y/o el Promotor) .
Le debe transmitir la necesidad de iniciar este trabajo, llegando si es necesario a dar de alta el trámite de manera conjunta en la aplicación https://inventario.um.es.
| Info | ||
|---|---|---|
| ||
Se puede consultar la metodología para el inventariado de los trámites en la siguiente dirección . |
Durante el inventariado, el Responsable Técnico Principal (o los Responsables técnicos y/o Miembros del equipo de desarrollo en los que delegue), realizarán los trabajos específicos que se describen en este proceso
- 3. Identificación Plantillas Documentales.
- 4. Modelado de los trámite.
Cuando dichos trabajos hayan finalizado, el Responsable Técnico Principal deberá pedir soporte a la Unidad de Gestión de Procesos para completar la validación del trámite en inventario, y que dicha unidad pueda incorporar el trámite para su aprobación en sus reuniones mensuales.
Esto lo realizará en la pantalla de edición del trámite, pulsando sobre Solicitar soporte a la UGP:
3. Identificación plantillas documentales
Este paso es imprescindible en a quellos proyectos que conlleva la utilización de expedientes y documentos electrónicos que se guardarán o se encuentran almacenados en el Archivo Electrónico de la Universidad de Murcia, siguiendo la Política de Gestión de Documentos de la Universidad de Murcia .Para la utilización del Archivo Electrónico, es necesario dar de alta los documentos que manejará el trámite en la pestaña Valoración Documental durante la edición del trámite en Inventario, y dentro del bloque Conservación, Acceso y Clasificación ENS:
El alta de estos documentos se realizará en dos bloques, distinguiéndose si:
- Son documentos que son presentados por el interesado:
- Son aquellos documentos que se adjuntan en el inicio del trámite. Por ejemplo, las solicitudes que dan pie al inicio de un procedimiento administrativo.
- Son documentos que son generados durante la tramitación:
- Son documentos generados durante la vida del trámite, posterior al inicio.
- MUY IMPORTANTE: Si el documento necesita firma con un sello electrónico de órgano, se introducirá en este grupo.
- Los documentos de este bloque, podrán ser firmados administrativamente de una de estas tres maneras:
- Generados por el funcionario en el ejercicio de su competencia. Esta opción se debe elegir si el documento será firmado por un funcionario o cargo, de manera personal, por ejemplo a través del Portafirmas.
- Autenticado con sello de Órgano. Esta opción se debe elegir si el documento será firmado con un Sello Electrónico de Órgano como consecuencia de una actuación administrativa automatizada. En este caso, y para que el documento pueda ser utilizado técnicamente, se debe solicitar el permiso para ello, tal como se describe en el Apartado 2.1. Utilización de sellos electrónicos. Se debe elegir el Sello de Órgano que se utilizará. También es posible solicitar la creación de nuevos sellos de órgano, como también se describe en el Apartado 2.1.
- Obtenidos desde la Plataforma de Intermediación de Datos (PID). Si elegimos esta opción, el documento será obtenido desde otra Administración Pública, a través de la Plataforma de Intermediación de Datos de la Administración General del Estado, bien de forma automatizada desde una aplicación de la propia Universidad de Murcia o bien mediante consulta por un funcionario a través del aplicación Volantes. Para utilizarlo, se deben realizar las gestiones administrativas descritas en el apartado 2.2. Utilización de volantes de datos personales.
En cualquiera de los dos casos anteriores, los documentos hay que asociarlos a una Plantilla Documental existente en Archivo Electrónico de la Universidad.
| Info | ||
|---|---|---|
| ||
Se define una Plantilla Documental como la descripción de un expediente o un documento a través de sus metadatos. Una plantilla documental contiene:
|
. Existen un conjunto de Plantillas Documentales predefinidas (definidas por el ENI) que pueden ser utilizadas directamente, que son las siguientes:
| Advertencia | ||
|---|---|---|
| ||
Una vez asociado el documento a una Plantilla Documental, se generará un código con el formato:
Como en el siguiente ejemplo: Este código es el que se debe de utilizar para la inserción de estos documentos en los servicios de ELECTRA. |
Si fuera necesario, es posible crear Plantillas Documentales Propias, tal como se describe a continuación:
| Nota | ||
|---|---|---|
| ||
SOLO en aquellos casos que se quiera utilizar la búsqueda de metadatos dentro del Servicio de Archivo de la Plataforma de Administración Electrónica (ELECTRA), y se quiera tener un conjunto de metadatos PROPIOS y específicos al tipo de documento que maneja el proyecto, se debería solicitar el Alta de una Plantilla Documental Propia. Este proceso requiere un flujo de aprobación y utilización mas largo, y solo se recomienda en casos muy específicos. Esta solicitud se realiza a través de la aplicación Archivo de Oficina , y aunque debería realizarse por los Responsables Funcionales, se admite actualmente la solicitud de alta por los Responsables Técnicos de los proyectos. Una vez completado el alta de la Plantilla Propia, todavía se debe de asociar dicha plantilla a los documentos del trámite, tal como se ha descrito en los párrafos anteriores. La descripción para realizar la solicitud se puede encontrar aquí. |
4. Modelado del trámite
4.1. Introducción
El Responsable Técnico Principal deberá realizar el modelado del trámite vinculado al proyecto, y enlazar este modelado en el Inventario del Trámite.
| title | ADONIS BPM Suite |
|---|
Para el modelado de los trámites, se utilizará la herramienta ADONIS BPM Suite, cuyo URL es:
Para poder utilizarla en modo de edición, es necesario ser Responsable Técnico Principal del proyecto, y formar parte del grupo UMU "adonis-editores", que administra MNCS. Si no se forma parte de dicho , se debe solicitar su alta a través de JIRA:
- Correo del usuario que se desea dar de alta en la herramienta.
- Proyecto/s en los que es RTP
En la siguiente URL de MNCS se encuentra una introducción general a la interfaz de usuario que podemos encontrar en el escenario "Diseñar y Documentar", que es el que utilizaremos para modelar los trámites:
4.2. Identificación y creación del grupo de modelos
Los modelos para Inventario de trámites deben ser creados bajo el Grupo de modelos raíz siguiente:
- Modelos → Universidad de Murcia → Inventario de trámites administrativos
Y dentro de ese grupo, hay que identificar cual es la Unidad Organizativa Responsable del trámite, que coincidirá con la que se establezca en dicho atributo de Inventario de trámites.
Por ejemplo, si los trámites que vamos a modelar son responsabilidad del Área de Recursos Humanos y Servicios Generales, se crearán colgando del siguiente grupo de modelos:
Dentro de este grupo de modelos, a su vez, se creará un grupo de modelos que va a contener todos los modelos de proceso que se utilicen en este trámite, con la siguiente estructura:
- COD_INVENTARIO - Denominación interna del trámite en inventario
Por ejemplo, si estamos trabajando en el modelado del trámite de "Reconocimiento de carrera profesional del PAS", tendríamos la siguiente carpeta colgando del "Área de Recursos Humanos y Servicios Generales":
4.3. Creación de un mapa de trámites (opcional)
4.4. Creación del modelo raíz o padre del trámite
El modelo raíz de un trámite debe contener la visión general del mismo, desde su inicio hasta al final. Dependiendo de la complejidad, y si se considera necesario, se podrá descomponer en las fases del mismo, y modelar cada fase en un subproceso diferentes, enlazándose estos subprocesos desde este modelo raíz.
Se debe crear con el siguiente formato:
- COD_INVENTARIO - Denominación interna del trámite en inventario (Completo)
4.4.1. Roles participantes
4.4.2. Sistemas e infraestructura
4.4.3. Inicio del trámite
4.4.4. El flujo de secuencia
4.4.5. Tareas, sus tipos y subtareas
4.4.6. Eventos intermedios
4.4.7. Decisiones exclusivas
4.4.8. Decisiones paralelas
4.4.9. Decisiones inclusivas
4.4.10. Fusión/convergencia de flujos de secuencia
4.4.11. Flujos de excepción que interrumpen
4.4.12. Flujos de excepción que no interrumpen
4.4.13. Eventos de fin
4.5. Creación de submodelos
4.6. Vinculación del modelo en el Inventario
En Inventario, el Responsable Técnico Principal debe vincular el trámite con el modelo que estamos desarrollando en la herramienta de ADONIS.
Esto se realizará de la siguiente manera:
- Compartir un enlace al modelo desde ADONIS. Para ello se pulsa sobre el botón COMPARTIR cuando se está editando el modelo:
- En la pestaña que se abre, se debe COPIAR el enlace que se ha generado:
- Editamos el trámite en Inventario, y en la pestaña Descripción del trámite, en el campo "URL de diagrama detallado del trámite", pegamos la dirección anterior:
4.7. Solicitud de revisión y validación a la UGP
| Advertencia | ||
|---|---|---|
| ||
Además de la validación metodológica del modelado, hay que recordar que también se debe solicitar la revisión del trámite en Inventario por parte de la UGP, tal como se describe en:
|
Una vez que se considere completado el modelado del trámite, deberíamos pulsar sobre Aprobar → Enviar a revisión metodológica. Esto realizará una validación semántica del diagrama (a nivel de BPMN), y si todo es correcto, lo dejará listo para su revisión por parte de la UGP.
