Árbol de páginas

Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 18 Siguiente »

Condiciones de inicio

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

Inventariado de trámites

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.

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.

Alta tarea JIRA: "Inventariado y modelado de trámites asociados al proyecto"
Tipo de tarea:"Gestión"Pórtico:Asociado al Proyecto
Disciplina:"P3. Inicio del Proyecto"Proceso:"Inventariado y modelado de trámites"

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:

  1. Se inicia por parte de un interesado o de oficio;
  2. Tiene una duración limitada en el tiempo,
  3. Incluye un conjunto de fases / etapas o actos administrativos.
  4. 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).
  5. 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. También puede verse como que un procedimiento está asociado a un tipo de expediente.
  6. En el caso de procedimientos complejos, podría estar formado por procedimientos internos (en forma de subprocesos) o servicios.
  7. Tiene una norma y/o legislación reguladora, bien a nivel nacional, regional o de la propia Universidad.

Alcance del proyecto actual

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:

  1. Identificarlo y darlo de alta en Inventario.
  2. Modelar las fases generales, sin profundizar en ellas, entre las que se encontrará el sub procedimiento o servicio asociado a este proyecto.
  3. Identificar y dar de alta en Inventario en sub procedimiento o servicio específico a este proyecto.
  4. Modelar de manera completa esta parte.
  5. 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

Trámites: ¿Procedimiento o servicio?

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....); podríamos dar un servicio para el cambio de los datos personales de un miembro del PAS o del PDI; o un servicio que, si se cumplen las condiciones, permita la emisión de la TUI para un miembro de la comunidad universitaria.

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:


Metodología de Inventario

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 aquellos 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, o en la fase de subsanación o reclamación. 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.

Concepto de Plantilla Documental

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:

  • Código identificativo
  • Nombre de la plantilla
  • Conjunto de metadatos comunes 
  • (Opcional) Conjunto de metadatos propios

Existen un conjunto de Plantillas Documentales Genéricas (predefinidas y definidas por el ENI) que pueden ser utilizadas directamente, que son las siguientes:

 

Código para su utilización en ELECTRA

Una vez asociado el documento a una Plantilla Documental, se generará un código con el formato:

  • COD_TRAMITE#COD_PLANTILLA#Númeracion

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:  

Alta de Plantillas Documentales Propias

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.

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 grupo, se debe solicitar su alta a través de JIRA:

Alta tarea JIRA
Tipo de tarea:"Petición de Servicio"Proyecto JIRA:BPM
Resumen:Solicitud alta RTP en adonis-editores
Descripción:
  • Correo del usuario que se desea dar de alta en la herramienta.
  • Proyecto/s en los que es RTP

En la siguiente URL 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 el atributo del mismo nombre, dentro de la Pestaña Descripción del trámite, en el 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/procesos (opcional)

Los mapas de procesos son un tipo de diagrama que permite mostrar un conjunto de procesos relacionados, SIN MOSTRAR los detalles internos; podría mostrar los procesos de un área, de una unidad, de un software, etc. Pueden ser interesantes si queremos mostrar gráficamente los trámites identificados asociados al proyecto que estamos construyendo. 

Contenido de los mapas de proceso

Los diagramas de mapa de proceso permiten "dibujar" elementos básicos como carriles, formas básicas, así como procesos y otros mapas de procesos contenidos.

Así, podríamos tener una jerarquía completa de mapas de procesos, que a su vez contienen otros mapas de procesos, y que finalmente muestran los procesos finales para los usuarios.


Podemos ver un ejemplo en el siguiente mapa que muestra todos los trámites y procesos identificados dentro de la Gestión de Títulos Oficiales de la Universidad de Murcia:

Otro ejemplo podría ser el conjunto de trámites identificados en las ayudas sociales para el PAS y PDI de la Universidad:

En el siguiente ejemplo lo que se muestran son un conjunto de los trámites de un área de la Universidad, en particular a ATICA:


Para crear un mapa de procesos, nos situaremos en el Grupo de Modelos en el que queremos crearlo, y tras pulsar con el botón DERECHO sobre el mismo, pulsaremos sobre "Crear modelo en grupo". Tras ello, en la ventana siguiente seleccionaremos "Mapa de procesos":

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)

El modelo raíz o padre del trámite se modelará acorde a lo documentado en la siguiente página.

Cuando es un proceso complejo, contará con subprocesos, que se enlazarán desde este modelo padre tal como se describe en la documentación anterior.

En el siguiente ejemplo, vemos un trámite complejo que representa la promoción de proyectos y acciones de innovación, desde su inicio hasta su fin:

En el modelo se muestran algunas partes concretas del proceso, pero muchas de ellas se ocultan los detalles, siendo modelados posteriormente en otros subprocesos. Son las siguientes:

  • Presentación y valoración de solicitudes
  • Presentación y valoración de la memoria
  • Registro de asistencia y emisión certificado

4.5. Creación de submodelos

Los submodelos que se creen del proceso se añadirán en el mismo grupo de modelos que el proceso raíz (definido en el apartado 4.2). 

Se modelarán de manera análoga al subproceso padre, acorde a lo documentado en la siguiente página.

Eventos de fin en subprocesos

Una buena práctica de modelado en los subprocesos es identificar los posible estados finales en los que pueden finalizar, distinguiendo por tanto distintos eventos de fin (con distintos nombres).

En el proceso raíz, tras la invocación al subproceso, existirá un gateway exclusivo que debería redirigir el flujo acorde a estos posibles finales del subproceso anterior.

Ejemplo:

  • Tenemos un subproceso llamado "Fase de presentación de solicitudes" con los dos siguientes estados finales:
  • En el proceso padre, debería estar modelado algo como lo siguiente:


Los subprocesos se deben crear con el siguiente formato:

  • COD_INVENTARIO - Denominación del subproceso / fase / subtrámite

Para enlazarlos en el proceso raíz, se puede realizar "arrastrando" directamente, desde el panel lateral izquierdo, el fichero con el subproceso a un subproceso en el diagrama del proceso raíz. Si todo se ha realizado correctamente, al pulsar sobre el símbolo (más)  de este subproceso, se abrirá el diagrama con los detalles del subproceso.

Se puede comprobar el proceso que está enlazado abriendo el panel de propiedades del subproceso en el proceso raíz (haciendo doble clic sobre la caja del subproceso):

Hay que mirar en el atributo "Subproceso solicitado".

Un consejo interesante es que desde la pestaña Representación, se puede cambiar si se quiere visualizar el nombre del diagrama real del subproceso (Valores visualizados→ Referencia), o el nombre asignado al artefacto con el subproceso (Valores visualizados → Nombre):

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:

  1. Compartir un enlace al modelo desde ADONIS. Para ello se pulsa sobre el botón COMPARTIR cuando se está editando el modelo:
  2. En la pestaña que se abre, se debe COPIAR el enlace que se ha generado:
  3. 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

Solicitud de soporte al inventariado

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 esta sección

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.



  • Sin etiquetas