Introducción
Módulo principal del SGI que implementará el ciclo de gestión de convocatorias (ayudas a la investigación y becas), solicitudes, proyectos (incluyendo contratos y convenios) y grupos de investigación.
La filosofía de base del SGI será la homogeneización y unificación de entidades y flujos. Esto permitirá el diseño de un sistema que permita dar cobertura de manera horizontal a las necesidades de las diferentes unidades de gestión y a los diferentes criterios organizativos que marquen la existencia de éstas dentro de cada Universidad particular.
En base a esta premisa, el flujo principal del módulo CSP responde al siguiente esquema:
Las convocatorias serán registradas en el SGI por el personal de administración y servicios de las diferentes unidades de gestión que estarán estructurados atendiendo a la definición de perfiles especificada en CSP - Actores que toma como base la estructura general del SGI GEN - Actores. Sobre las convocatorias se registrarán las solicitudes. Este registro será realizado por el personal investigador o en su defecto, si no se habilita esta opción, por el personal de las unidades de gestión. El proceso de registro de las solicitudes en el SGI, a excepción de las de plan propio, será independiente del proceso de tramitación de las solicitudes en los organismos convocantes.
Las solicitudes concedidas darán lugar a los proyectos. Los proyectos podrán crearse en el SGI sin necesidad de que exista el flujo previo de creación de la convocatoria y registro de solicitudes.
La gestión económica de los proyectos será realizada en el Sistema de Gestión Económica propio de cada Universidad. El SGI deberá recibir del SGE el listado de operaciones contables, a modo informativo, vinculados a cada proyecto, así como todo el detalle de las facturas y gastos. Cualquier operación contable y/o factura/gasto deberá ser registrada desde el propio SGE.
La premisa de homogeneización ha de mantenerse a lo largo del diseño de todo el SGI, en el caso del módulo CSP se materializa en evitar la particularización de las entidades convocatorias, solicitudes y proyectos de acuerdo a la naturaleza de las mismas. Se debe de tener en cuenta que las particularizaciones minimizarán la posibilidad de adaptación a modelos futuros. Por ello, la propuesta es disponer de una entidad común "proyecto" que englobe cualquier modalidad bajo la que se pueda desarrollar la actividad (proyecto de investigación financiado, ayuda de contratación de RRHH, contrato artículo 83, convenio, contrato de licenciamiento, acuerdo de colaboración, etc.).
El modelo de dominio, a alto nivel, al que responderá este módulo es:
Se unificarán bajo la entidad Convocatoria todas las tipologías de las mismas, independientemente de su naturaleza, con la correspondiente clasificación atendiendo a diferentes criterios pero compartiendo todas ellas la misma estructura de información. Como ejemplo:
- Clasificación según modelo de ejecución (ayuda, contrato, convenio) CSP - Modelo de ejecución
- Clasificación según la finalidad del proyecto o actividad resultante a desarrollar (ejemplo: proyecto I+D, asesoría, servicio ténico, royalties, infraestructuras, congresos, contratación de RRHH, etc.). Esta clasificación queda implícita en CSP - Modelo de ejecución
- Clasificación según la unidad de gestión que coordinará la gestión del proyecto (ejemplo: UGI, OTRI, OPE, etc). Esta clasificación, queda también implícita en CSP - Modelo de ejecución
Cada convocatoria registrada quedará vinculada a una unidad de gestión (UGI, OTRI, OPE, etc.) de forma que se limite la visibilidad de la misma al personal de gestión perteneciente a dicha unidad (o cuyo usuario de acceso al SGI esté asociado a la unidad de gestión).
En el proceso de registro de la convocatoria se configurará la posibilidad o no de habilitar el registro de solicitudes en el SGI para el personal investigador.
Las solicitudes quedarán asociadas a la convocatoria y aquellas que resulten concedidas quedarán trazadas con el proyecto resultante.
Los proyectos tendrán asociado un equipo de proyecto, donde cada miembro tendrá un rol dentro del equipo de investigación y unas fechas de pertenencia al equipo.
La producción científica derivada de la ejecución del proyecto quedará vinculada al mismo y a sus autores, desde el módulo de PRC (Producción científica).
La configuración de los proyectos permitirá activar o no el registro de las horas de trabajo por parte de cada miembro del equipo de investigación.
El módulo CSP contará con las siguientes opciones de menú:
- Convocatorias
- Solicitudes
- Proyectos
- Participación en proyectos externos
- Grupos de investigación
- Ejecución económica
- Notificación de presupuestos a SGE
- Configuración
Descripción
- CSP - Actores
- CSP - Modelo de ejecución
- CSP - Convocatorias
- CSP - Solicitudes
- CSP Proyectos, contratos, becas y ayudas
- CSP - Participación proyectos externos
- CSP - Grupos de investigación
- CSP - Notificación presupuesto SGE
- CSP - Ejecución económica
- CSP - Timesheet
- CSP - Casos de uso
- CSP - Interfaz de usuario
- CSP - Comunicados
- CSP - Glosario de términos
3 Comentarios
Usuario desconocido (hercules.ehu.anton.romo)
Reflexión de Anton Romo
Al margen de lo que se pueda añadir en los diferentes apartados del módulo de convocatorias, me surge la duda de si, se ha dejado de considerar la cuestión de que los diferentes catálogos de modelos de ejecución, tipos de fase de gestión, tipos de documentos, tipos de enlace, tipos de finalidad, unidades de gestión, tipos de hitos de convocatoria, tipos de hitos de solicitudes, tipos de hitos de proyectos, etc., pudieran ser compartidos entre los diferentes SGI que vayan instalándose en el Estado.
La necesidad que me surge, es consecuencia de que por todas partes se hace un gran esfuerzo para estandarizar estructuras que sin embargo, si no hace nada al respecto, puede ocurrir que, por ejemplo en la tabla de tipos de documentos, cada Universidad les llame como se le ocurra, aunque esos tipos de documentos sean perfectamente homologables a los de otras Universidades.
Quizá deba pensarse en que en un SGI cualquiera debería existir, bien la posibilidad de importar tablas de estructuras ya predefinidas en otra Universidad o bien de que se pueda indicar en un SGI operativo que sus estructuras son consultables desde otros sistemas SGI.
Esa posibilidad implicaría un grandísimo esfuerzo de definición de estructuras y de rebote, una gran estandarización a nivel Estatal entre los diferentes SGI que se pongan en marcha.
Usuario desconocido (jesus.ruiz.ticarum)
Hola.
Haría una pequeña indicación y es que en la app de gestión de la Universidad de Murcia, un proyecto (Ayuda) podía tener antes n códigos UNESCO asociados, pero ahora sólo puede tener uno. No sé si es que con el análisis se ha llegado a esa conclusión o no, pero me da la impresión de que es una diferencia de HERCULES con GINVES y aquí os la dejo por si os sirve.
Usuario desconocido (covadonga.garcia)
Gracias, Usuario desconocido (jesus.ruiz.ticarum). En las reuniones de análisis deduje que cada proyecto solo se vinculará a un código UNESCO. Usuario desconocido (hercules.juana.menchon) ¿Podríais, por favor, poner un caso funcional en el que un proyecto pueda tener más de un código UNESCO? ¿Cual es la situación que conlleva a que un proyecto puede tener más de un código UNESCO? ¿Ocurriría lo mismo con el código NABS?