FAQ's de SIU: Estructura de la información en SIU y PAU
- Integración OTRS y JIRA
Aunque SIU y PAU son dos aplicaciones separadas, están íntimamente ligadas y es difícil separar funcionalmente lo que está en una y lo que está en otra. Por este motivo se explica la información que contienen de forma conjunta.
Respecto a cambiar esto, hay que tener en cuenta que son sistemas legados con muchos integradores y esto dificulta los cambios de arquitectura de forma transparente para todas esas aplicaciones que consumen esta información.
El organigrama correspondiente a la estructura orgánica de la Administración de la Comunidad Autónoma de Aragón
Los sucesivos Gobiernos establecen la estructura orgánica de la Administración de la Comunidad Autónoma de Aragón según el reparto de competencias con el que quieran trabajar a lo largo de la legislatura. Esta estructura se determina en Decretos que se publican en el BOA.
Esta estructura se recoge en SIU y puede ser consultada por las herramientas que necesiten esta información.
La estructura se representa en forma de árbol, de manera que hay un nodo raíz (no tiene padre, no “cuelga“ de nadie) y cada nodo puede tener cero, uno o varios hijos. Para almacenar estas relaciones, cada organismo tiene la referencia del organismo del que depende (por ejemplo, el Departamento de Sanidad tiene la información de que su padre es el organismo Diputación General de Aragón).
Esta estructura se corresponde también con la estructura recogida en SIRHGA, que actúa como “maestro“ de la información, es decir, cuando se hace algún cambio en el organigrama en SIRHGA, se detecta desde SIU y se programan los cambios necesarios para dejar las dos estructuras iguales. Esto nos permite tener la correspondencia entre los organismos almacenados en SIU y los almacenados en SIRHGA (en el organigrama de SIU de la imagen que se adjunta más abajo se puede ver en cursiva el organismo de SIRHGA correspondiente y en el organigrama de SIRHGA se puede ver en cursiva el organigrama de SIU correspondiente). Éste es el motivo por el que los cambios de estructura se hacen primero en SIRHGA y después en SIU, tomando como referencia lo que se ha hecho en SIRHGA. De esta manera además, evitamos tener dos organigramas diferentes en herramientas de la misma Administración.
|  |
Otros organismos que no forman parte de la estructura orgánica como tal
No todos los organismos que hacen falta para el trabajo diario que se desarrolla en la Administración de la Comunidad Autónoma de Aragón están recogidos en SIRHGA. Es el caso de los tribunales de oposición, algunos Consejos como el Consejo Asesor de Investigación y Desarrollo o algunas comisiones como la Comisión Interdepartamental de Administración Electrónica. Estos organismos pueden necesitar que sus miembros utilicen distintas aplicaciones que hacen uso de los organismos, por ejemplo para firmar actas de las reuniones. En estos casos, el organismo está dado de alta en SIU pero no le podemos asociar ningún organismo SIRHGA (por eso vemos el texto “Código SIRHGA sin asignar“).
| 
|
Histórico de organismos
Cuando se produce un cambio en cualquiera de los organismos recogidos en SIU (que puede ir desde un cambio puntual a un cambio completo en la estructura orgánica de la Administración de la Comunidad Autónoma de Aragón), la información correspondiente a la situación anterior se almacena en SIU en forma de histórico.
Hay que tener en cuenta que hasta el 21 de junio de 2023, cualquier cambio en un organismo A provocaba que el código de organismo de ese organismo A se diera de baja y se crease un nuevo organismo con un nuevo código de organismo diferente del anterior (incluidos el renombre y el cambio de padre). Además, existía una restricción que obligaba a que el código de un organismo fuese más bajo que cualquiera de los códigos de organismo de sus hijos. Esto hacía que el proceso de cambio de estructura tuviese un coste computacional muy alto y que tuviera un riesgo muy elevado por el volumen de cambios que el comportamiento de SIU forzaba a realizar. El 21 de junio de 2023 se desplegó en PRODUCCIÓN la versión 3.16.0 de SIU, con cambios profundos en el funcionamiento interno de SIU, con tres objetivos principales:
Mantener el código de organismo todo lo posible, dando respuesta así a una demanda histórica por parte de los integradores de SIU.
Mejorar el proceso de cambio de estructura de manera que un cambio en un organismo sólo afecte a ese organismo en lugar de afectar a toda la parte del organigrama que esté por debajo de ese organismo.
Esta mejora reducirá el coste computacional de realizar cambios en el organigrama y también reducirá el riesgo de los cambios, que actualmente es muy elevado.
Para poder conseguir esto, es necesario eliminar la restricción que obliga a que el código de un organismo sea menor que el código de organismo de cualquiera de sus hijos y por tanto hay que revisar todos los servicios que hacen uso de esta restricción para asegurar que el cambio es lo más transparente posible para los integradores de SIU.
Mantener la capacidad de tener un histórico del organigrama del Gobierno de Aragón.
Se puede consultar el detalle completo del funcionamiento de SIU ante un cambio de organismos el siguiente documento:
Puestos de trabajo (jobs)
Dentro de cada organismo, puede haber cero, uno o varios puestos de trabajo asociados. Estos puestos de trabajo pueden ser puestos que están en SIRHGA o puestos que no están en SIRHGA. Por eso, distinguimos entre puestos RPT (los que están en SIRHGA) y puestos NO RPT (los que no están en SIRHGA).
Para los puestos que están en SIRHGA, al tener una correspondencia organismos SIU-organismos SIRHA, podemos detectar los cambios y movimientos que se realicen (cambios de nombre, movimiento de un organismo a otro, etc.) y trasladarlos automáticamente a SIU. Esta sincronización se realiza tres veces a la semana. Actualmente sólo se sincronizan los puestos de Administración General (es decir, no se sincronizan los puestos correspondientes a los colectivos de Educación, Justicia, Salud…)
La sincronización con SIRHGA nos permite tener información de más calidad, ya que mientras no estuvo esta sincronización, el mantenimiento de la información se realizaba bajo demanda (tenía que ser un usuario el que explícitamente solicitara una baja, un movimiento…) y la experiencia que teníamos es que las altas se solicitaban pero las bajas, con carácter general, no. La información de los puestos NO RPT no puede obtenerse de SIRHGA y por tanto, su mantenimiento sigue siendo manual, con los riesgos que esto conlleva. Por este motivo, la creación de puestos NO RPT debe limitarse a aquellos que sean estrictamente necesarios (que además son aquellos que reflejan la realidad):
El puesto NO RPT correspondiente al Secretario del Tribunal de la Oposición A, si necesita firmar electrónicamente actas como Secretario, se creará en SIU.
Si ya existe el puesto Administrador Superior en el Servicio de Diseño y Desarrollo de Servicios Públicos (sería un puesto RPT), no deberíamos crear un puesto NO RPT correspondiente a ese puesto Administrador Superior en la Dirección General de Administración Electrónica y Aplicaciones Corporativas por ejemplo para que pueda hacer no sé qué tarea en una aplicación. Es la aplicación la que tendrá que tener en cuenta que la va a usar un Administrador Superior que está en el Servicio de Diseño y Desarrollo de Servicios Públicos. Si se crease el puesto NO RPT que comentamos, sería un puesto NO RPT “ficticio“, que no refleja la ubicación real del empleado y que va a dificultar, entre otras cosas, el mantenimiento de la información. Por todo esto, ese puesto NO RPT no se crearía en SIU.
Empleados (users)
Utilizamos el término empleados puesto que, en principio, los usuarios que vamos a almacenar son empleados del Gobierno de Aragón.
Los usuarios ocupan normalmente un puesto RPT (el que se corresponde con el puesto “oficial“, podríamos decir que es el puesto en base al que le pagan la nómina), aunque hay usuarios que no ocupan ningún puesto RPT. Este último sería el caso de tener una persona externa al Gobierno de Aragón que por algún motivo necesita acceder a las herramientas (por ejemplo porque es un agente del CAU y necesita acceso para poder ejercer su trabajo). Este tipo de usuarios tienen asociado un puesto no RPT y no tienen asociado un puesto RPT.
En principio, un usuario sólo puede ocupar un puesto RPT y un puesto RPT sólo puede estar ocupado por una persona, aunque en ocasiones puntuales nos encontramos con casos que no cumplen esto y que se resuelven manualmente para que la información sea coherente.
Un usuario puede ocupar varios puestos no RPT aunque un puesto no RPT sólo puede estar ocupado por una persona.
En un organismo determinado, un usuario sólo puede ocupar un puesto (independientemente de si es un puesto RPT o no RPT).
Para los usuarios que están en SIRHGA y ocupan puestos RPT, también se pasa un proceso automático tres veces por semana para detectar las altas, bajas y movimientos, de manera que se reduce la necesidad de tener que hacer estas peticiones a demanda.
Permisos sobre aplicaciones (roles) y procedimientos (procedures)
Cada puesto (sea un puesto RPT o un puesto NO RPT) puede tener asociados permisos para utilizar aplicaciones de SDA y procedimientos recogidos en SEDA. Aunque estamos hablando de procedimientos, en SEDA lo que recogemos son servicios y variantes. Hay que tener en cuenta que en SIU/PAU, a un puesto, le asociamos servicios, pero las aplicaciones trabajan con las variantes (entre otras cosas para asegurar un correcto metadatado que facilite posteriormente el desglose de información al ciudadano). Los servicios de SIU/PAU tienen en cuenta esto a la hora de devolver la información a las aplicaciones.
Por ejemplo, en SEDA tenemos un servicio Registro industrial de Aragón (3318), que tiene una variante División A - Establecimientos y empresas. Comunicación de alta (38).
En SIU/PAU, si vemos los permisos que tiene el puesto que ocupa un usuario, veremos el servicio: Registro industrial de Aragón (3318).
Y si vamos a PFI, a la hora de seleccionar el procedimiento para metadatar el documento, nos aparecerá la variante (con el nombre del servicio concatenado por delante): Registro industrial de Aragón - División A - Establecimientos y empresas. Comunicación de alta (38).
Como los permisos están asociados al puesto, si cambia el ocupante del puesto, la persona que lo ocupe ahora “heredará“ esos permisos que estuvieran configurados y la que abandone ese puesto dejará de tener esos permisos (pasará a tener los que tenga el puesto que ocupe a partir de ahora).
