pliego de prescripciones técnicas para la contratación del ... · sistema de información...

Fondo Europeo de Desenvolvemento Rexional

Unha maneira de facer Europa

Pliego de Prescripciones Técnicas para lacontratación del servicio de desarrollo de un

sistema de información analítico en el ámbito delos servicios sociales, cofinanciado por el FondoEuropeo de Desarrollo Regional en el marco delPrograma Operativo FEDER Galicia 2014-2020

(Expte.: 2017/PA/0044)



Tabla de contenidos

1 INTRODUCCIÓN.................................................................................................................................................... 4

2 OBJETO DE LA CONTRATACIÓN........................................................................................................................ 4

3 DESCRIPCIÓN DE LOS SERVICIOS A REALIZAR............................................................................................ 53.1 Plan de ejecución.............................................................................................................................................................................. 6

3.2 Productos a entregar...................................................................................................................................................................... 7

4 CONDICIONES DE EJECUCIÓN........................................................................................................................... 84.1 Equipo de trabajo............................................................................................................................................................................. 8

4.1.1 Marco general........................................................................................................................................................................................................... 84.1.2 Requisitos generales del equipo de trabajo.................................................................................................................................................. 84.1.3 Marco específico del equipo de trabajo.......................................................................................................................................................... 94.1.4 Parámetros técnicos de los medios físicos y lógicos.................................................................................................................................. 9

4.2 Lugar de la prestación del servicio......................................................................................................................................... 10

4.3 Dirección, planificación y seguimiento de los trabajos................................................................................................... 10

4.4 Seguimiento del proyecto........................................................................................................................................................... 11

4.5 Propiedad de los trabajos y productos.................................................................................................................................. 12

4.6 Confidencialidad de la información........................................................................................................................................ 12

4.7 Metodología en la elaboración de los trabajos................................................................................................................... 134.7.1 Formato de la documentación......................................................................................................................................................................... 144.7.2 Horas de formación.............................................................................................................................................................................................. 14

4.8 Control de calidad......................................................................................................................................................................... 15

4.9 Acuerdos de niveles de servicio............................................................................................................................................... 15

4.10 Condiciones de inicio del servicio........................................................................................................................................ 17

4.11 Condiciones de finalización del servicio............................................................................................................................ 17

4.12 Transferencia de conocimiento............................................................................................................................................. 17

4.13 Obligaciones del adjudicatario relativas a la información y publicidad comunitaria......................................18

5 CONTENIDO DE LA PROPUESTA TÉCNICA.................................................................................................. 18

6 ANEXO I: PLATAFORMA TÉCNICA DE SOFTWARE..................................................................................... 196.1 PLATAFORMA CORPORATIVA DE BI...................................................................................................................................... 19

6.2 SISTEMAS OPERACIONALES..................................................................................................................................................... 23

7 ANEXO II: ALCANCE FUNCIONAL DEL PROYECTO..................................................................................... 247.1 INTRODUCCIÓN......................................................................................................................................................................................................... 247.2 ALCANCE FUNCIONAL............................................................................................................................................................................................ 247.2.1 Requisitos funcionales comunes...................................................................................................................................................................... 257.2.1.1 Tipos de estudios soportados........................................................................................................................................................................ 257.2.1.2 Dimensiones comunes...................................................................................................................................................................................... 257.2.1.3. Estadísticas principales................................................................................................................................................................................. 267.2.2 Historia Social Única Electrónica................................................................................................................................................................... 267.2.2.1 Área analítica Tramitación........................................................................................................................................................................... 267.2.2.2 Área analítica Persona.................................................................................................................................................................................... 277.2.2.3 Área analítica Actuaciones............................................................................................................................................................................ 287.2.2.4 Área analítica Prestaciones........................................................................................................................................................................... 287.2.2.5 Área analítica Centros..................................................................................................................................................................................... 297.2.3. SIGAD......................................................................................................................................................................................................................... 297.2.3.1 Introducción........................................................................................................................................................................................................ 297.2.3.2 Áreas analíticas.................................................................................................................................................................................................. 307.2.3.3 Explotaciones habituales............................................................................................................................................................................... 327.2.4 Prestaciones de inclusión................................................................................................................................................................................... 34



7.2.4.1 Introducción........................................................................................................................................................................................................ 347.2.4.2 Áreas analíticas.................................................................................................................................................................................................. 357.2.5 Discapacidad........................................................................................................................................................................................................... 397.2.5.1 Introducción........................................................................................................................................................................................................ 397.2.5.2 Áreas analíticas.................................................................................................................................................................................................. 397.2.6 Servicios sociales comunitarios....................................................................................................................................................................... 407.2.6.1 Introducción........................................................................................................................................................................................................ 407.2.6.2 Áreas analíticas.................................................................................................................................................................................................. 407.2.7 Registro de entidades prestadoras de servicios sociales...................................................................................................................... 427.2.7.1 Introducción........................................................................................................................................................................................................ 427.2.7.2 Áreas analíticas.................................................................................................................................................................................................. 42



1 INTRODUCCIÓN

[1] La Axencia para a Modernización Tecnolóxica de Galicia (en adelante Amtega) es una agencia públicaautonómica, creada por el Decreto 252/2011 de 15 de diciembre, que tiene como objetivos básicos ladefinición, el desarrollo y la ejecución de los instrumentos de la política de la Xunta de Galicia relativa atecnologías de la información y comunicaciones, así como innovación y desarrollo tecnológico.

[2] La Amtega aglutina las competencias que correspondían a la Secretaría Xeral de Modernización eInnovación Tecnolóxica y concentra los recursos humanos, materiales y presupuestarios asociados a lasactuales estructuras TIC dispersas en el sector público autonómico. De conformidad con lo dispuesto enla disposición adicional tercera de la Ley 16/2010, de 17 de diciembre, de organización yfuncionamiento de la Administración general y del sector público autonómico de Galicia, la Amtega estáadscrita a la Presidencia de la Xunta de Galicia.

[3] La Amtega tiene entre sus competencias el diseño y ejecución, en todas las Consellerías y Organismosdependientes de la Xunta, de los proyectos de sistemas y tecnologías de la información que dan soportea su operativa. Resultado de los distintos planes de modernización tecnológica sectoriales elaboradospor la Amtega en colaboración con las Consellerías y Organismos surgen una serie de proyectos dedesarrollo de nuevos sistemas de información. En este contexto se elaboró el Plan Trabe para laModernización Tecnológica de los Servicios Sociales, aprobado por el Consejo de la Xunta de Galicia enabril de 2013. Una de las líneas de actuación identificadas como prioritarias en el citado plan es ladenominada “Centro inteligente de planificación y explotación de la información”. La actuación objetode esta licitación se enmarca en esta línea de actuación, y pretende la incorporación a los sistemascorporativos del ámbito de los servicios sociales de la Xunta de Galicia de un sistema de informaciónanalítico que dé satisfacción a las necesidades de análisis, reporting y explotación de datos globales delárea, en el marco de la Implantación de la Historia Social Única Electrónica.

[4] Otra de las actuaciones contenidas en el Plan Trabe es la de “Historia Social Única. Interoperabilidad eintegración socio-sanitaria”. La Historia Social Única Electrónica, en cuanto sistema que aglutinainformación consolidada en torno a la persona usuaria del sistema gallego de servicios sociales, resultauna fuente de información de especial relevancia para la nueva plataforma analítica objeto de licitación.

[5] Por tanto, en el marco del desarrollo de la Plataforma tecnológica de los servicios sociales definida en elPlan Trabe, y a raíz de la implantación de la Historia social única electrónica, es necesario desarrollar unsistema de información analítico sobre el ámbito referenciado.

2 OBJETO DE LA CONTRATACIÓN

[6] El presente procedimiento tiene como objeto la contratación del servicio de desarrollo e implantaciónde un sistema de información analítico que dé respuesta a los principales requerimientos de análisis dela información, reporting y explotación de datos del ámbito de los servicios sociales de Galicia.

[7] Las tareas incluidas en este servicio son:

Diseño, desarrollo e implantación del sistema de información analítico según el alcancefuncional especificado en el Anexo II de este pliego.

Adecuación a los cambios en la capa de presentación derivados de los cambios organizativos yde estética corporativa que puedan suceder durante la vigencia del contrato.

Mantenimiento de los distintos componentes del sistema, en particular de los procesos deextracción y carga de la información, de modo que se garantice la adaptación del sistemaanalítico a las líneas evolutivas de las fuentes de datos origen.

Página 4/44



Proceso de implantación del sistema de información desarrollado, particularizado para cadadatamart específico, y soporte técnico al mismo.

Desarrollo de nuevas funcionalidades identificadas durante el período que transcurra desde laimplantación hasta la finalización del contrato, en particular en las capacidades de reporting através de la incorporación de nuevos informes en la fase de estabilización y maduración delsistema tras su implantación inicial

Desarrollos de la aplicación descrita, incluidas las modificaciones, mantenimiento evolutivo onuevas funcionalidades que pudieran surgir a lo largo de la ejecución del presenteprocedimiento derivadas de nuevas necesidades funcionales o de cambios normativos.

Desarrollo de la capa de presentación adaptada a la estética corporativa Desarrollo y adecuación de los flujos de trabajo en los sistemas de información derivados de las

mejoras de usabilidad requeridas en los sistemas. Adecuación de lo construido a las normas de calidad que estén en vigor. La adjudicataria tiene

la obligación de acatar todas las normas de calidad que se implanten y de adecuar todo lo yadesarrollado a las normas de calidad en vigor.

Puesta en funcionamiento del sistema de información y soporte a los usuarios sobre elfuncionamiento de la aplicación una vez puesta en producción hasta la finalización del contrato.

Soporte a los usuarios sobre el funcionamiento de la aplicación una vez puesta en producciónhasta la finalización del contrato

Soporte técnico en la explotación y obtención de informes analíticos del sistema de información Propuesta de mejora y optimización de los sistemas existentes

3 DESCRIPCIÓN DE LOS SERVICIOS A REALIZAR

[8] El conjunto de servicios de los que se hará cargo la empresa adjudicataria, y que constituyen el objetodel presente contrato son los siguientes:

1. Identificación detallada en colaboración con los órganos administrativos competentes de losrequerimientos (funcionales y no funcionales), casos de uso, clases de alto nivel, secuenciasfuncionales de alto nivel, interfaces de usuario, estructura de la información, plan depruebas y riesgos.

2. Definición de la arquitectura del sistema. Los distintos subsistemas necesarios parasatisfacer el alcance especificado deberán diseñarse sobre la base de productos queconforman la arquitectura de BI corporativa de la Amtega referida en el Anexo I. Se valorarála propuesta de elementos tecnológicos complementarios, en la medida en que contribuyana completar el alcance funcional previsto, y quedando supeditado su empleo a la posterioraceptación por la Amtega en la fase de arranque del proyecto.

3. En particular deberán diseñarse e implementarse los siguientes subsistemas: procesos ETLde extracción, transformación y carga desde las fuentes de datos operacionales; almacenesde datos orientado al análisis de la información (datawareHouse); cuadros de mando einformes operativos, particularizados para los datamarts que conformen el sistema; cubosanalíticos para el análisis libre de la información.

4. Fase inicial de toma de requisitos y análisis funcional en el que se especificarán y diseñaránlas dimensiones, indicadores, cuadros de mando, informes y cubos analíticos a implementar,junto con el resto de requisitos de tipo tanto funcional como no funcional a tener en cuentaen un proyecto de implementación de un sistema de inteligencia de negocio.

5. Diseño de las interfaces de usuario para todos los roles y casos de uso identificados. Diseñode otros elementos con los que se relacionan los casos de uso como pueden ser documentosde todo tipo, interfaces con elementos externos y con otros sistemas externos.

Página 5/44



6. Creación de productos de todos los elementos diseñados y realización y aprobación depruebas unitarias y funcionales según el plan de pruebas y los procedimientos de calidad desoftware.

7. Formación de usuario, según el plan de formación a elaborar durante la ejecución delservicio. La adjudicataria también realizará un manual para usuarios de la aplicación, el cualvendrá como una parte más de cada entrega de una versión del software y de acuerdo conlas políticas de entrega de documentación establecidas por la Amtega.

8. La licitadora entregará con cada versión toda la documentación del proyecto actualizada deacuerdo con las guías de calidad. Además indicará (según proceda) la relación de cambios, elprocedimiento de instalación desde la versión anterior, el procedimiento de instalacióncompleta, el proceso de migración de datos entre versiones. Estos manuales estaránorganizados seguún afecten a las áreas de producción, explotación, desarrollo, usuario final,CAU, etc.

9. Los procesos de carga iniciales tendrán en cuenta toda la información obrante en lossistemas operacionales origen, incluida la información histórica, debiendo ser autorizadopor el director del proyecto cualquier variación de este planteamiento.

10. Soporte, asistencia a la puesta en funcionamiento y a producción, y mantenimiento desde lapuesta en producción y hasta la finalización temporal del contrato. Los servicios demantenimiento incluirán las cuatro tipologías señaladas en la metodología Métrica v3:correctivo, evolutivo, adaptativo y perfectivo, sobre cada módulo desplegado en producción.

3.1 Plan de ejecución

[9] El proyecto deberá abordar la definición, diseño, desarrollo, implantación y soporte técnico de losdistintos módulos del sistema analítico requerido, según el alcance que se especifica en el Anexo II deeste pliego.

[10] La metodología de desarrollo seguirá un ciclo de vida iterativo incremental. Las actividades dedesarrollo requerirán la realización de tareas de consultoría, análisis y definición previos, así comotareas implícitas a la construcción de los sistemas de información en general, y de sistemas deinformación de tipo analítico en particular. El adjudicatario entregará al inicio del contrato un plan deproyecto con un cronograma donde se hayan reflejado todos los hitos de desarrollo establecidos,incluyendo nuevos requisitos en cada nuevo hito hasta completar el conjunto de los mismos definido enel catálogo de requisitos. La metodología sucesiva en cada una de las fases o hitos definidos en el plande proyecto podrá ser variable, aunque acorde a los marcos metodológicos más comunes (PMBOK,CMMI, Métrica V3, etc.).

[11] Para el nuevo sistema a desarrollar, se establece un primer hito obligatorio a los 2 meses de comienzodel proyecto que llevará asociado un despliegue de una versión Beta en el entorno de pruebas de losservidores de la Amtega que incluya, además del esqueleto de la aplicación ya desarrollado(autenticación y autorización, look&feel, gestión de auditoría, gestión de ayudas, etc.), un porcentaje delos requisitos implementados que se definirá en el Plan de Arranque del Proyecto: estos requisitos aimplementar en este primer hito obligatorio estarán claramente identificados en el plan de proyectoentregado al inicio del contrato.

[12] A partir del primer hito con despliegue Beta en el entorno de pruebas Amtega se establecerá unapolítica de entregas de versiones Beta incremental. El tiempo entre entregas sucesivas deberáestablecerse en el cronograma inicial, no siendo nunca superior a 1 mes.

Página 6/44



[13] Para los nuevos sistemas a desarrollar, el adjudicatario deberá hacer entrega de la aplicación con lasfuncionalidades completas establecidas como escenario inicial en el Plan de Arranque del Proyecto enun plazo inferior al que será definido, para cada proyecto, en dicho plan. Esta primera versión de laaplicación deberá ser completa, entendiendo por completa que dé soporte a la totalidad de losrequisitos identificados en la fase de análisis, y que haya superado las pruebas de integración, carga,velocidad y usabilidad.

[14] Las actividades de soporte incluirán todas aquellas tareas relacionadas con el soporte técnico a losusuarios, como atención de incidencias, resolución de problemas, apoyo a la explotación u operación delsistema.

[15] El plazo de duración del contrato será de 1 año.

3.2 Productos a entregar

[16] Además de la documentación resultante del desarrollo de los trabajos y de las actividades realizadas seentregará la siguiente documentación:

1. Plan de proyecto.

2. Documentación técnica de la aplicación: análisis, diseño funcional, diseño técnico y plan depruebas.

3. Manual de usuario de las aplicaciones y módulos (internos/externos).

4. Manuales de explotación de las aplicaciones y módulos.

5. Plan de formación.

6. Guías de usuario (con ejemplo(s) práctico(s) que cubran todos los procesos para laformación de usuarios).

7. Planes de implantación: paso a producción y marcha atrás, resultados de las pruebas deaceptación, de carga y de seguridad, procedimientos de soporte.

8. Códigos fuente, librerías, objetos y demás componentes de la aplicación.

9. Procedimientos, scripts y cualquier elemento necesario para la construcción o compilacióndel proyecto o sistema a partir de los códigos fuente indicados en el punto anterior.

10. Ejecutables compilados de las aplicaciones.

11. Licencias, en caso de que se utilice dentro de la solución software licenciable. En este caso sesuministrarán las licencias necesarias para la operación, y soporte por un período de tresaños desde la puesta en funcionamiento del sistema (incluyendo las actualizaciones quepuedan darse de las mismas y del software referido). Esta particularidad debe hacerseconstar expresamente en la oferta o, si es una decisión adoptada posteriormente, contar conla aceptación formal y por escrito del Director Técnico del Proyecto. Asimismo, sesuministrará el código fuente y toda la documentación requerida por la Dirección delProyecto de todos los productos, incluido el software licenciado si lo hubiese, estableciendolos acuerdos jurídicos oportunos que garanticen que la Xunta de Galicia no podrácomercializar ni ceder a terceros dicho software licenciado si así se requiere, pero símantener, evolucionar y/o integrar el software recibido, por sí misma o a través de terceros.

[17] La documentación se subirá al repositorio de documentación que la Amtega disponga a tal efecto.Deberá adaptarse a las plantillas para cada tipo de documento definidas por el departamento de calidadde la Amtega y publicadas en https://xuntatic.xunta.es.

Página 7/44



4 CONDICIONES DE EJECUCIÓN

4.1 Equipo de trabajo

4.1.1 MARCO GENERAL

[18] Para la realización de estas actividades el equipo de trabajo estará formado por un mínimo de perfilesque figuren en la oferta y deberá necesariamente cumplir los requisitos específicos del equipo detrabajo. La empresa adjudicataria deberá determinar en la propuesta la dedicación de cada uno de losmiembros del equipo de forma que cubran como mínimo la franja de servicio normal especificada en elapartado correspondiente y garanticen los acuerdos de nivel de servicio demandados y ofertados y losrequisitos de desarrollo fijados en el pliego.

[19] El adjudicatario deberá determinar en su propuesta el número de integrantes del equipo de trabajo quegaranticen los requisitos de las prestaciones demandadas, entendiendo como responsabilidades deladjudicatario garantizar las tareas prestadas. En todo caso es responsabilidad de la empresa garantizarla adecuada prestación de servicios y consecución en plazo de los resultados especificados en el pliego,por lo que tendrá la obligación de organizar la prestación del servicio y de dimensionar y reforzar elequipo de trabajo asignado al proyecto en aquellas situaciones o períodos que lo precisen.

[20] De modo orienta tivo, la Amtega considera necesario un equipo de personas que pueda realizar unesfuerzo de como mínimo 13.475 horas durante la vigencia del contrato (12 meses).

[21] Sirviendo esto como orientación mínima en cuanto al alcance del esfuerzo en horas de los trabajos quese demandan. Esta referencia de dedicación corresponderá a personal experto con ampliosconocimientos técnicos y funcionales y con elevada experiencia en este entorno de negocio. Ladedicación real de los recursos con toda seguridad superará estos mínimos, en función de parámetroscomo la formación y experiencia del personal que preste el servicio.

[22] Las horas de esfuerzo representan horas de un perfil medio calculado con los perfiles tipo queparticipan en las fases de desarrollo de un proyecto software tipo y los porcentajes medios departicipación de cada perfil.

4.1.2 REQUISITOS GENERALES DEL EQUIPO DE TRABAJO

[23] Los perfiles integrantes del equipo de trabajo dispondrán de conocimientos técnicos suficientementeelevados en las plataformas tecnológicas –detalladas en el Anexo I- y funcionales para poder responderde modo satisfactorio y ágil con los requisitos de proyecto y con las tareas encomendadas. En esesentido los perfiles del equipo de trabajo propuesto deben garantizar que en su conjunto aseguran elconocimiento de todas y cada una de las tecnologías indicadas en dicho Anexo I. En el consumo de horasno se computarán las horas derivadas de la formación, adaptación tecnológica y de negocio, malasprácticas, errores o cualquier otra circunstancia, siendo solo computable el tiempo necesario paracumplir con las tareas encomendadas de un modo óptimo. El desconocimiento técnico por parte delequipo de trabajo podrá generar un incumplimiento reiterado de los acuerdos de nivel de servicio conlas sanciones pertinentes, incluida la rescisión del contrato en casos de incumplimiento graves.

[24] Los conocimientos técnicos del equipo de trabajo tienen condición de obligación contractual esencial, yde acuerdo con el artículo 223 punto f del TRLCSP, la falsedad o incumplimiento será causa deresolución.

Página 8/44



[25] Los recursos del equipo de trabajo deberán manejar los idiomas gallego y castellano. Asimismo, losrecursos deberán disponer de conocimientos de inglés suficientes como para manejar y comprender eneste idioma documentación técnica relacionada con el objeto del servicio.

[26] El equipo de trabajo deberá estar formado, como mínimo, por los recursos relacionados en la ofertaadjudicataria. La realización de cambios en la composición del mismo requerirá la notificación previacon un mínimo de 1 mes de antelación al responsable del área, estando la modificación ademáscondicionada a los siguientes requisitos:

Justificación detallada y suficiente, en la que se explique el motivo del cambio y sutemporalización.

Presentación de posibles candidatos con un perfil de cualificación técnica y funcional igual osuperior al de la persona que se pretende sustituir.

Aceptación del candidato por parte de la Dirección Técnica del proyecto (Amtega).

Por cada recurso sustituido, existirá un mínimo de 200 horas de penalización que nocomputarán en el consumo del equipo de trabajo

4.1.3 MARCO ESPECÍFICO DEL EQUIPO DE TRABAJO

[27] El equipo de trabajo estará formado por los perfiles indicados en la oferta del licitador, que deberáincluir como mínimo los indicados en el apartado P – Compromiso de adscripción de medios del PCAP.

[28] Durante todo el período de ejecución del servicio, el equipo de trabajo deberá cumplir losrequerimientos recogidos en el apartado P – Compromiso de adscripción de medios del PCAP, así comolas mejoras sobre los perfiles indicados como mínimos que, de ser el caso, hayan sido objeto devaloración, de acuerdo con lo establecido en el apartado K del PCAP.

4.1.4 PARÁMETROS TÉCNICOS DE LOS MEDIOS FÍSICOS Y LÓGICOS

[29] Durante las fases de los trabajos que se desarrollen en las dependencias de la Xunta de Galicia, secumplirán las siguientes condiciones:

a. Con la finalidad de garantizar los mecanismos de seguridad y los estándares corporativos, laAmtega le proporcionará a los recursos responsables de la ejecución del servicio los equiposinformáticos necesarios para el desarrollo de las actividades objeto del servicio.

b. Todos los elementos tecnológicos utilizados por la empresa adjudicataria para el desarrollo delservicio deberán configurarse según los estándares y las medidas de seguridad que la Amtegadetermine, permitiendo la instalación de los productos que la Amtega considere necesarios parala vigilancia y control.

c. En caso de que para el desarrollo de las tareas la empresa adjudicataria requiriese la instalaciónde hardware o software adicional en las instalaciones o en el equipamiento propiedad de laAmtega, esta deberá ser solicitada por escrito y autorizada por el responsable del equipamientoo instalación. La empresa adjudicataria pondrá a disposición del proyecto los recursos queconsidere necesarios, con una formación técnica y organizativa suficiente para la realización delas tareas descritas.

[30] La formación del personal del adjudicatario correrá por cuenta de este, no asumiendo la Amtega enningún caso cualquier coste derivado de la formación.

Página 9/44



4.2 Lugar de la prestación del servicio

[31] Los trabajos serán realizados desde las dependencias de la empresa adjudicataria, salvo aquellosespecíficos que para tareas de coordinación o seguimiento, fundamentalmente reuniones para laidentificación de contenidos o reuniones periódicas de seguimiento, deban hacerse donde establezca laAmtega.

[32] El adjudicatario deberá contar con los medios propios, de toda índole, necesarios para llevar a cabo conéxito los trabajos objeto del contrato.

[33] Dada la necesidad continua de toma de requisitos, evaluación de los mismos e interrelación con lasunidades técnicas y funcionales de la Xunta de Galicia implicadas en esta contratación, se consideranecesario que la empresa adjudicataria pueda atender peticiones de presencia en las instalaciones de laXunta de Galicia, en un tiempo no superior a 2 horas desde la comunicación de esta.

[34] El horario de prestación de la asistencia es el necesario para cumplir el nivel de servicio establecido, conindependencia de festivos locales, vacaciones o licencias de cualquier naturaleza.

[35] En los casos de contingencia o en situaciones puntuales la asistencia se prestará en las dependenciasque a tal efecto designe el área responsable de empleo de la Xunta de Galicia. La empresa contratistapodrá solicitar en situaciones puntuales la prestación de las tareas desde instalaciones adecuadas de laXunta de Galicia. Este permiso podrá denegarse. Todos los costes correrán a cargo del contratista.

[36] La empresa contratista facilitará el acceso a las instalaciones donde sea realizada la prestación delservicio al personal autorizado por el responsable del contrato, para tareas de inspección ycomprobación de lo exigido en el presente pliego y ofertado por la empresa.

[37] En caso de que las instalaciones estuviesen fuera de la Comunidad Autónoma, la Administraciónrepercutirá los gastos de desplazamiento, alojamiento y manutención a la empresa contratista.

4.3 Dirección, planificación y seguimiento de los trabajos

[38] La Amtega nombrará un responsable TIC del contrato, que realizará las funciones de Dirección delProyecto y que será el interlocutor con el adjudicatario. El adjudicatario deberá nombrar un jefe deproyecto, para que coordine el equipo que realice los trabajos recogidos al amparo de esta contratacióny sea el interlocutor con la Dirección del Proyecto.

[39] El jefe de proyecto designado por la empresa adjudicataria deberá realizar informes periódicos, y todosaquellos informes que, a petición de la Amtega, pudiesen servir para la óptima consecución de losobjetivos previstos.

[40] Mediante el jefe de proyecto designado por la empresa adjudicataria se notificarán a la Amtega losresultados de la gestión interna de todas aquellas actuaciones intransferibles en relación al equipo detrabajo e inherentes a la entidad empleadora (selección de personal, fijación del precio de la contrata,conformación de la ejecución de prestación contratada, condiciones de trabajo, horario de lostrabajadores, etc.).

[41] Para el desarrollo de los trabajos, se mantendrán las reuniones de trabajo precisas con los agentes,instituciones, empresas, y los centros directivos de la Xunta de Galicia con el fin de obtener toda lainformación requerida para la correcta ejecución de los trabajos.

[42] Se establecerán reuniones periódicas frecuentes del jefe del proyecto y, en su caso, de los miembros delequipo de la empresa adjudicataria, con el personal que la Amtega designe al efecto, para un correctoseguimiento y dirección de los trabajos.

Página 10/44



4.4 Seguimiento del proyecto

[43] La empresa adjudicataria deberá facilitar al área competente de la Amtega la siguiente relación deinformes periódicos:

a. Informe de seguimiento y evaluación del progreso de los trabajos objeto del contrato, tareas yactividades planificadas para la realización de los trabajos.

b. Coordinación de las reuniones e informes del proyecto.

c. Verificación del cumplimiento de los requisitos establecidos para la prestación del servicio.

[44] El área competente de la Amtega podrá requerir en cualquier momento a la empresa contratista losinformes que considere necesarios para el seguimiento de su actividad, o bien convocar las reunionesque considere oportunas con el coordinador de los trabajos del adjudicatario u otros responsables de laempresa contratista para analizar la información facilitada durante el desarrollo del proyecto.

[45] La Amtega podrá realizar en cualquier momento una auditoría de seguridad sobre los proyectos objetode este pliego. La empresa contratista tiene la obligación de facilitar en tiempo y forma cuantainformación le sea requerida. En caso de que hayan sido detectados problemas de seguridad en laaplicación, procedimientos o configuración, el adjudicatario tiene obligación de solventarlos, nopudiendo computarse estas tareas como carga de trabajo.

[46] Periódicamente se realizará una reunión de seguimiento. La empresa contratista enviará 24 horas antesde la reunión un informe de base para dicha reunión. Los despliegues de versiones Beta de la aplicaciónen el entorno de pruebas tienen que llevar necesariamente asociada una reunión de seguimiento. Losinformes de seguimiento tendrán como mínimo los siguientes apartados:

a. Resumen de actividades realizadas desde el último hito.

b. Resumen de actividades previstas hasta el próximo hito.

c. Resumen del esfuerzo en horas (tipificado o no) desde el hito anterior.

d. Resumen de las peticiones de cambio realizadas desde el hito anterior.

e. Desviaciones de plazo con respecto al cronograma inicial derivadas de las peticiones de cambioy plan de proyecto modificado

f. Métricas de control de calidad establecidas y tomadas desde el hito anterior.

g. Riesgos identificados

[47] Las reuniones de seguimiento se realizarán con la periodicidad establecida por la Amtega.

[48] Posteriormente a la reunión, el jefe de proyecto de la empresa adjudicataria elaborará un acta de lareunión que enviará para su aprobación a todos los asistentes a la reunión de seguimiento. Las actas,una vez aprobadas, deben subirse al gestor documental del proyecto.

[49] El director técnico o responsable TIC del proyecto designado por la Amtega podrá modificar las fechas,lugar y horas de reunión mediante un correo electrónico al responsable del proyecto en la empresaadjudicataria con antelación de una semana. El director técnico podrá aumentar o disminuir lafrecuencia de las reuniones de seguimiento según la evolución del proyecto. Las reuniones deseguimiento tendrán lugar en las dependencias de la Amtega en Santiago de Compostela.

4.5 Propiedad de los trabajos y productos

[50] Todos los informes, estudios y documentos elaborados por la empresa adjudicataria como consecuenciade la ejecución del presente contrato, serán propiedad exclusiva de la Amtega, quien podrá

Página 11/44



reproducirlos, publicarlos y divulgarlos total o parcialmente sin necesidad de la aprobación deladjudicatario.

[51] Todos los informes, código fuente, estudios y documentos, o productos derivados, obtenidos comoconsecuencia de la ejecución del presente contrato por cualquier actor participante en el mismo, seránpropiedad, tanto física como intelectualmente, exclusiva de la Amtega, quien podrá reproducirlos,publicarlos y divulgarlos total o parcialmente o liberarlos, sin necesidad de la aprobación del actorparticipante, con independencia de la naturaleza de la relación del actor con el proyecto.

[52] Asimismo, en caso de que la adjudicataria deseara utilizar código fuente, librerías o componentes decualquier otra naturaleza que esté protegido por sus derechos de autor, deberá solicitarlo expresamenteen la oferta e indicar en qué afectan estos elementos a la titularidad de los derechos de los productosresultantes de este contrato. El uso de estos elementos podrá rechazarse y en consecuencia rechazarsela oferta.

[53] Asimismo, la empresa adjudicataria no podrá conservarlos, ni facilitarlos a terceros sin expresaautorización de la Amtega.

[54] La empresa contratista estará obligada a seguir los protocolos existentes de liberación de software encaso de que la Amtega decidiese liberar cualquier elemento, total o parcialmente, que haya sidoobtenido como resultado de este procedimiento. El proceso de liberación y la liberación final nosupondrá un aumento de coste del contrato, mientras esta sea indicada al principio de la ejecución delcontrato o del elemento a liberar.

4.6 Confidencialidad de la información

[55] La empresa adjudicataria queda expresamente obligada a realizar sus trabajos bajo las cláusulas delsecreto profesional y, en consecuencia, a mantener absoluta confidencialidad y reserva sobre latotalidad de los documentos que le sean confiados o que sean elaborados en el transcurso del proyecto.Estando terminantemente prohibido extraer información de los sistemas, excepto en los casosestrictamente necesarios para la realización de tareas asignadas, previo consentimiento formal ydocumentado del responsable del servicio.

[56] La empresa adjudicataria deberá firmar un acuerdo de confidencialidad y no revelación de lainformación a la que pueda tener acceso al ejecutar este contrato. Igualmente será responsable de quelos empleados que tengan acceso a la información relacionada con el proyecto firmen elcorrespondiente acuerdo de confidencialidad y no revelación.

[57] Esta confidencialidad es extensible a cualquier dato que pudiera conocer con ocasión del cumplimientodel contrato, especialmente los de carácter personal, que no podrá copiar o utilizar con un fin distinto alque figura en este pliego, ni tampoco ceder a otros ni siquiera a efectos de conservación. Asimismo, laempresa adjudicataria no podrá utilizar las redes de comunicaciones ubicadas en las dependencias de laXunta de Galicia para transmitir datos procedentes de los archivos de esta última con destino a tercerosy, en caso de que dichas redes sean de la titularidad de la empresa adjudicataria, esta adoptará sobre lasmismas las medidas de seguridad necesarias para evitar el acceso de terceros no autorizados.

[58] La empresa adjudicataria tratará los datos de carácter personal única y exclusivamente conforme a lasinstrucciones de la Amtega, comprometiéndose a dar traslado al personal que presta el servicio de suobligación de secreto profesional respecto de los mismos y de su deber de guardarlos, obligaciones quesubsistirán aún después de finalizar su relación con el servicio a prestar.

[59] Asimismo, el adjudicatario quedará obligado al cumplimiento de la legislación vigente en materia deprotección de datos de carácter personal, en todo lo que sea de aplicación al presente proyecto,debiendo declarar documentalmente que se responsabiliza de que el tratamiento de datos de carácter

Página 12/44



personal que se pueda realizar en el marco de la prestación del servicio se realizará conforme a lodispuesto en las leyes y decretos que se relacionan a continuación:

Ley orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el reglamento de desarrollode la Ley orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

Las disposiciones de desarrollo de las normas anteriores en materia de Protección de Datos queestén en vigor en la adjudicación de este contrato o que puedan estarlo durante su vigencia.

[60] En caso de incumplimiento de lo estipulado, la entidad contratante y los técnicos destacados seránresponsables de las infracciones que se deriven.

4.7 Metodología en la elaboración de los trabajos

[61] Todas las actividades, operaciones y productos del servicio deberán realizarse bajo los siguientesparámetros de acuerdo con el contrato y los pliegos, conforme a la metodología y estándares definidos,aprobados y publicados por la Amtega y según las instrucciones que para su interpretación estaproporcione.

[62] En particular se hace referencia a las siguientes herramientas:

a. Registro de tareas y planificación de las mismas utilizando la herramienta de gestión de tareasRedmine del Área de Soluciones Tecnológicas Sectoriales.

i. El control y el seguimiento de las tareas técnicas asociadas al proyecto se hará a travésde Redmine, siendo necesario reflejar todas las tareas técnicas asociadas al desarrollodel proyecto, así como el registro de las horas imputadas a cada tarea.

ii. Redmine debe reflejar la planificación del proyecto con las sucesivas versiones o hitosdel mismo.

iii. Se actualizará el progreso de las tareas registradas en el Redmine con una periodicidadmínima semanal.

iv. Todas los nuevos requisitos o modificación de los existentes deben estar estimadospreviamente al inicio de las tareas técnicas asociadas a los mismos.

v. Las estimaciones se reflejarán y se justificarán utilizando las tareas correspondientesen el Redmine.

vi. La imputación de horas en el Redmine se utilizará como única prueba documental parajustificar el consumo de horas.

b. Repositorio de código

i. La empresa adjudicataria utilizará la herramienta Subversion del Área de SolucionesTecnológicas Sectoriales como repositorio de código durante el desarrollo.

ii. Las entregas del código fuente se harán en el Subversion utilizando la política deetiquetado y versionado del Área de Soluciones Tecnológicas Sectoriales.

iii. Todos los miembros del equipo de trabajo de la empresa adjudicataria que hagancambios en el código fuente asociado al proyecto apuntarán sus herramientas dedesarrollo contra el SVN corporativo, y registrarán en el mismo todos los cambios en elcódigo que hagan durante el proceso de desarrollo.

Página 13/44



iv. Todos los “commits” al repositorio del proyecto (Subversion) se asociarán comomínimo con la tarea técnica correspondiente en el Redmine.

4.7.1 FORMATO DE LA DOCUMENTACIÓN

[63] En relación con el formato de la documentación resultado del servicio, la empresa adjudicataria deberárealizar sus actividades de acuerdo con las siguientes normas:

a. Toda la documentación deberá realizarse en formato ODF (OASIS Open DocumentFormat,norma ISO/IEC 26300). En caso de que la empresa adjudicataria solicitase entregar ladocumentación en otro formato, deberá ser solicitado por escrito y autorizado por el DirectorTécnico del proyecto. Si la solicitud fuese autorizada, los costes de adquisición de las licenciasnecesarias correrán por cuenta del contratista.

b. El Director Técnico del proyecto podrá solicitar a la empresa adjudicataria que entregue ladocumentación en otro formato de amplia difusión.

c. Toda la documentación técnica referente al proyecto seguirá las plantillas aprobadas ypublicadas por el departamento de seguridad y calidad de la Amtega. No se admitirá ningúndocumento técnico que no se ajuste a dichas plantillas.

4.7.2 HORAS DE FORMACIÓN

[64] Las actividades formativas irán dirigidas al personal responsable de la ejecución del servicio, tantodesde un punto de vista funcional como técnico. La formación comprenderá un número variable demódulos de formación dirigidos a los distintos perfiles que hayan participado en la aplicación, tantodesde un punto de vista técnico como funcional (no inferior a las 50 horas anuales durante el períodode ejecución del contrato).

[65] El plan de formación contendrá necesariamente los siguientes elementos:

Planificación de los módulos a impartir (fecha de comienzo, fecha de fin y número de horas)

Dependencias donde se imparte el módulo

Número máximo de alumnos por módulo

Perfiles de usuario a los que va dirigido cada módulo

Contenidos docentes de cada módulo

Actividades de cada módulo

Breve CV del formador o formadores

[66] El plan de formación deberá ser comunicado y aprobado previamente por el director técnico delproyecto en la Amtega.

4.8 Control de calidad

[67] Todas las actividades, operaciones y productos del servicio deberán realizarse bajo los siguientesparámetros:

a. Durante la ejecución del servicio, la Amtega podrá establecer las acciones de aseguramiento dela calidad sobre la actividad desarrollada y los productos que estime necesarios. A tal fin sepodrán incorporar a la realización de las tareas encomendadas al contratista los recursos que seestimen oportunos para garantizar su correcta ejecución.

Página 14/44



b. Deberán ser seguros, y no comprometer la seguridad, integridad y confidencialidad de lossistemas informáticos y de los datos manejados. En caso de que hayan sido detectadosproblemas de seguridad en los sistemas informáticos objeto del servicio, la empresaadjudicataria tendrá la obligación de solventarlos en el menor tiempo posible.

c. Deberán ser óptimos y eficientes en términos de rendimiento y uso de recursos.

d. Deberán encuadrarse bajo criterios adecuados de disponibilidad, escalabilidad, mantenimientoy gestionabilidad.

e. No tendrán coste adicional para la Amtega.

[68] Cuando el proyecto sea incluido en el servidor de integración continua, el adjudicatario deberápresentar un plan de adecuación del proyecto al sistema de integración continua.

[69] El adjudicatario realizará un cometido de mejora continua de la calidad del código y adecuación a lasbuenas prácticas, según lo indicado en los documentos de normas y estilos. Con la obligación deactualizarse de forma continuada a las buenas prácticas publicadas por el departamento de calidad dela Amtega.

[70] El software a desarrollar en el transcurso del contrato cumplirá con las normas de calidad establecidasen la gerencia de proyectos del área sectorial competente.

[71] La empresa adjudicataria propondrá las mejoras de calidad que estime oportunas, para optimizar laactividad desarrollada durante el tiempo de ejecución del presente contrato.

4.9 Acuerdos de niveles de servicio

4.9.1 NIVEL DE SERVICIO[72] A continuación, se indican los valores que representan el menor nivel de servicio admitido para los

diferentes parámetros de servicio:

Parámetro Tiempo máximo

Resolución de incidencias de prioridad baja 48 horas

Resolución de incidencias de prioridad normal 24 horas

Resolución de incidencias de prioridad alta 8 horas

Resolución de incidencias de prioridad urgente 4 horas

Presentación en las dependencias de la Xunta de Galicia 2 horas

[73] Esta tabla muestra los valores máximos admitidos para los diferentes parámetros del servicio. Se indicael tiempo máximo en que la empresa adjudicataria deberá solucionar una incidencia atendiendo a suprioridad, a contar a partir del momento de comunicación de las mismas y dentro de la franjas deservicio normal o especial establecidas.

[74] Se define una incidencia como cualquier reducción de los parámetros medios de rendimiento o bien lainterrupción no planificada de cualquier proceso, funcionalidad o servicio asociado a las aplicacionesobjeto del servicio, y que se encuentren en producción.

[75] La Amtega definirá la prioridad de las incidencias atendiendo a la gravedad del servicio, proceso ofuncionalidad interrumpido o de la pérdida de calidad del mismo.

Página 15/44



4.9.2 FRANJA DE SERVICIO NORMAL[76] A efectos de valorar el cumplimiento de los acuerdos de nivel de servicio, se considera como franja de

servicio normal el tramo horario en el cual se desarrollará el servicio habitualmente. Este tramo horariose desarrollará de 8:00 a 20:00 de lunes a viernes, excluidos los días festivos de ámbito nacional,autonómico y local.

4.9.3 FRANJA DE SERVICIO ESPECIAL

[77] La franja de servicio especial conforma tramos horarios singulares no fijos, fuera de la franja delservicio normal, y establecidos a discreción por la Amtega, en función de la planificación de los trabajos,de cargas puntuales o de incidencias que precisen una atención especial. Esta franja de servicio especialoperará en función de los siguientes criterios:

a. La Amtega comunicará con un margen de 5 días el establecimiento o alteración de la distribuciónde las horas de la franja de servicio especial.b. Las horas de servicio semanales medias incluidas en la franja de servicio especial podrán seranticipadas o atrasadas en función de la planificación de la Amtega según los requisitos de servicio.c. Se considerará que se ejecutan dentro de la franja de servicio especial todas aquellas tareas que sedesarrollen fuera de los tramos horarios descritos en el apartado 4.9.2 para la franja de servicionormal.d. La Amtega comunicará al jefe de proyecto con una antelación de 4 horas, salvo causas de fuerzamayor o eventos sobrevenidos, aquellos servicios que modifiquen lo establecido para un día concretodentro de la franja de servicio especial.e. La Amtega comunicará al jefe de proyecto con una antelación de 48 horas, salvo causas de fuerzamayor o eventos sobrevenidos, aquellos servicios que, dentro de la franja de servicio especial, debanprestarse en sábado, domingo, o días festivos de ámbito nacional, autonómico y local.

4.9.4 CONSUMO DE HORAS

[78] El consumo de horas semanal podrá variar según las necesidades del servicio, atendiendo alcumplimiento de las fechas de los hitos marcados por la gestión administrativa, o contingenciaspuntuales.

[79] La Amtega comunicará al jefe de proyecto, con una antelación mínima de 3 días, las variaciones en elnúmero de horas semanales a consumir.

[80] De acuerdo con el nivel de servicio indicado en el apartado 4.9.1, la empresa deberá disponer de losrecursos suficientes para poner a disposición de la Amtega el número mínimo de horas semanalesofertadas.

4.10 Condiciones de inicio del servicio

[81] Una vez formalizado el contrato, la empresa adjudicataria deberá comenzar con la prestación delservicio.

4.11 Condiciones de finalización del servicio

[82] Durante el mes último de vigencia del contrato, la Amtega podrá establecer un período transitorio deejecución en condiciones especiales, de modo que se garantice la prestación del servicio de formaininterrumpida, comprometiéndose el adjudicatario a colaborar con la Amtega y, si es el caso, con las

Página 16/44



personas que esta designe a tal efecto, en aquellas actividades necesarias, encaminadas a laplanificación y ejecución del cambio.

[83] El adjudicatario deberá garantizar por el período indicado en el Pliego de Cláusulas AdministrativasParticulares los productos derivados de la presente contratación, contando desde la fecha definalización del contrato, obligándose a realizar durante el período los cambios necesarios parasolucionar las deficiencias detectadas imputadas al adjudicatario si la Amtega lo solicita.

[84] La garantía incluirá la solución de errores ocultos que se pongan de manifiesto en el funcionamiento delas aplicaciones o que se encuentren mediante pruebas o cualquier otro medio, así como la conclusiónde la documentación incompleta y reparación de la que contenga deficiencias. Los productos originadoscomo consecuencia de la reparación de errores deberán entregarse de conformidad con lo exigido eneste pliego.

[85] El tiempo de respuesta ante una solicitud de asistencia por error en los productos obtenidos durante laejecución del presente contrato será de como máximo 24 horas.

4.12 Transferencia de conocimiento

[86] En relación con la transferencia del conocimiento, la empresa adjudicataria deberá realizar susactividades de acuerdo con las siguientes normas:

a. Se considerarán susceptibles de la transferencia de conocimiento todos aquellos elementos deingeniería, componentes software, acciones, razonamientos, habilidades, procesos ydocumentos desarrollados como parte de las actividades objeto del servicio.

b. El plazo de transferencia de conocimiento comprende la duración del contrato y los 6 mesessiguientes una vez finalizado.

c. A petición de la Amtega, y durante el plazo de transferencia de conocimiento, la empresaadjudicataria tendrá la obligación de realizar transferencias de conocimiento sobre losproductos y actividades objeto del servicio.

d. La transferencia de conocimiento podrá realizarse mediante medios telemáticos siempre ycuando la naturaleza de la misma lo permita.

e. La transferencia de conocimiento se realizará a personal de la Xunta de Galicia o a personalperteneciente a terceras partes que requieran de ese conocimiento para desarrollar susactividades para la Xunta de Galicia.

f. Durante el plazo de transferencia la Amtega podrá solicitar la modificación de la documentaciónentregada en caso de que sea insuficiente o incorrecta.

g. Las tareas de transferencia de conocimiento una vez finalizado el contrato estarán sujetas a losmismos niveles de servicio que durante la ejecución del mismo. Una vez finalizado el contrato, laempresa licitadora será responsable de los perjuicios ocasionados por la incorrectatransferencia de conocimiento o errores/omisiones en la documentación entregada.

4.13 Obligaciones del adjudicatario relativas a la información y publicidad comunitaria

[87] El adjudicatario deberá cumplir con la normativa referente a la información y publicidad comunitariaestablecidas en el apartado 2.2 del Anexo XII del Reglamento (UE) nº 1303/2013 del ParlamentoEuropeo y del Consejo de 17 de diciembre de 2013 y en los artículos 4 y 5, así como en el Anexo II, delReglamento (UE) nº 821/2014 de la Comisión de 28 de julio de 2014.

Página 17/44



5 CONTENIDO DE LA PROPUESTA TÉCNICA

[88] Con independencia de que el licitador pueda adjuntar cuanta información complementaria considere deinterés, se recomienda que la propuesta, en su parte técnica, tenga el siguiente esquema:

Índice Identificación y alcance de la oferta

o Identificación (definirá los objetivos y el alcance de la propuesta)o Datos de la empresa

Oferta técnicao Propuesta funcionalo Propuesta tecnológicao Plan y organización de proyecto

Otros

Santiago de Compostela,

Mar Pereira ÁlvarezDirectora de la Axencia para a Modernización Tecnolóxica de Galicia

Página 18/44



6 ANEXO I: PLATAFORMA TÉCNICA DE SOFTWARE

6.1 PLATAFORMA CORPORATIVA DE BI.

El sistema deberá construirse sobre la plataforma corporativa de sistemas de análisis de la información de laAmtega (en adelante plataforma de BI corporativa). De este modo el proyecto deberá integrar los diferentesmódulos de análisis de los ámbitos funcionales que se especifican en este pliego sobre la plataforma de BIcorporativa. Esta dispone de un portal web (portal BI) que unifica el acceso del usuario final a los módulos deusuario que ofrece la plataforma y que se señalan a continuación:

Módulos de usuario final de la plataforma de BI:

Desde el punto de vista funcional, la plataforma de BI está formada por los siguientes módulos de usuario final:

• Cuadro de mando interno: acceso a indicadores y gráficos organizados por módulostemáticos, pensado para obtener una visión integral y sintética de la información

• Cuadro de mando público multitemático: permite publicar en Internet cualquierindicador que esté en la plataforma de BI

• Informes: informes predefinidos que completan la información de los indicadoresmostrados en el cuadro de mando

• Módulo de Análisis Libre: permite construir informes, consultas y analíticas sobre losdatos almacenados en la plataforma de BI en modo autoservicio

• Información estadística sobre mapas: permite representar información numérica yestadística de los cuadros de mando sobre mapas de Google Maps

• Diccionario corporativo: entorno web de consulta de todos los términos e indicadores dela plataforma de BI

• Solución de carga de datos de usuario: permite la carga puntual de información a partirde archivos ofimáticos

• Solución de gestión de la plataforma: permite administrar a usuarios no técnicos lapublicación de cuadros de mando, entre otras capacidades de gestión y administración dela plataforma

Arquitectura y componentes:

Desde el punto de vista de su arquitectura lógica, la plataforma de BI está compuesta por los siguientescomponentes y herramientas tecnológicas:

• Capa de obtención de datos:

◦ Procesos ETL para la obtención de la información desde los orígenes de datosoperacionales

◦ Herramienta de desarrollo: Talen Open Studio

◦ Planificador web: rundeck

◦ Dos tipos de procesos: de incorporación de la información y de enriquecimiento

• Capa de almacenamiento:

◦ Repositorio central corporativo (almacén de datos global o data warehouse)

Página 19/44



◦ Implementado sobre Oracle 12c

Consta de dos partes:

◦ Zona de maniobra, con estructura similar a los orígenes de datos operacionales

◦ Modelo de explotación: diseño en estrella orientado a la explotación y laimplementación de cubos OLAP

• Capa de interconexión con Base de datos:

Capa intermedia entre los sistemas de explotación analíticos y el origen de los datos.Engloba los cubos OLAP y las consultas SQL necesarias para que la siguiente capa obtengalos datos con el formato y agrupación adecuados

Principales tecnologías implicadas:

◦ Servidor Olap: Mondrian (Pentaho Analysis Services)

◦ Drivers jdbc para Oracle

• Capa de explotación:

Formada por los servicios que permiten realizar las funciones principales de explotaciónde la solución de BI:

◦ Módulo de análisis libre: Saiku CE versión 3.7 (incluido en la suite Pentaho CE);

◦ Módulo de informes predefinidos: soportado sobre Pentaho CD 5.4; herramienta dedesarrollo de informes: Pentaho report designer

◦ Cuadro de mando: implementado en Java EE (Spring y Struts) y tecnologías web(HTML5, CSS, JavaScript)

◦ Diccionario: Apache JSPWiki

◦ Introducción de datos: solución integrada en el portal de BI que complementa elsistema de ETL permitiendo la carga manual de indicadores y la carga de hojas decálculo

◦ Administración y gestión: módulo para administrar la publicación de cuadros demando e indicadores

Para la implementación de informes y cubos OLAP a integrar en el portal de BI se utilizarán las siguientesherramientas de escritorio: Pentahoo Report Designer para la elaboración de informes; Secehma workbench parael diseño de cubos. Tanto los informes como los cubos se suben al servidor Pentaho y desde ahí son accesibles através del portal de BI.

La autenticación en la plataforma se realiza a través del DA corporativo.

Esta información puede ampliarse a través de los documentos técnicos que describen la plataforma de BI y losprocedimientos de trabajo relacionadas con la misma, los cuales se mantienen actualizados en el portalcorporativo de difusión de documentación de la Amtega XuntaTic. En concreto, puede obtenerse más detallesobre los modelos físico y operacional de la plataforma de BI en el documentoPATBI_DFT_documentoImplantacionAmtega, a disposición de cualquier licitador que lo solicite.

El siguiente diagrama resume la arquitectura lógica de la plataforma de BI:

Página 20/44



Modelo de explotación:

Se deberán implementar los modelos de explotación específicos que permitan satisfacer los requisitosfuncionales del proyecto. Esto implica contemplar la creación de las tablas de dimensiones y de hechos que seannecesarias, según se establezca en la fase de análisis funcional del proyecto.

Respecto de las tablas de dimensiones cabe clasificarlas en troncales o específicas. Se reaprovecharán aquellasdimensiones troncales de las que ya disponga la plataforma, siempre que resulten adecuadas al proyecto (porejemplo las tablas de dimensión geográfica y temporal). Algunas de las dimensiones que se implementen en esteproyecto podrán ser utilizadas por otros proyectos de BI, incorporándose como dimensiones troncales de laplataforma. Las dimensiones específicas podrán resultar de aplicación a uno o varios módulos de la capa deexplotación, según se establezca tras el análisis funcional.

Respecto de las tablas de hechos, las cuales contienen indicadores de actividad y datos numéricos, para facilitarla administración de las cargas de datos y la corrección de posibles errores se orientará el diseño en la medida delo posible a cargas “ex novo”.

Procesos de extracción y carga:

Se deberán implementar los procesos ETL que permiten la carga de información desde los sistema operacionalesu otras opciones de carga a los modelos de explotación construidos. Estos procesos se documentaránprincipalmente a través de documentos específicos denominados “cuadernos de carga”, los cales ofrecerán unavisión transversal de los orígenes y transformaciones que se aplican a la información operacional hastaconvertirse en dimensiones y hechos de los modelos dimensionales implementados, así como de aspectos comola periodicidad prevista.

Página 21/44



Los proyectos ETL, a implementar en Talend Open Studio, estarán estructurados de manera jerárquica, de modoque los jobs se ejecuten adecuadamente desde el punto de vista del orden y secuencialidad necesarios. Laplanificación de los mismos se realizará a través del rundeck de la plataforma.

Aunque la periodicidad de las cargas deberá establecerse en la fase de análisis funcional, pudiendo variar paracada ámbito funcional concreto, en principio se estima que las cargas serán mayoritariamente semanales omensuales.

La carga de indicadores sintéticos y sus desgloses se realizará ejecutando procesos de carga de indicador, ámbitoo grupo de ámbito, según las normas y metodología vigentes durante la ejecución del proyecto. Estas implican lalectura de una serie de parámetros, entre los que cabe distinguir parámetros comunes que se leen de un ficheroproperties, y parámetros específicos a configurar en tablas específicas del sistema.

Integración de los sistemas de análisis de información requeridos en la plataforma deBI

Describimos a continuación los aspectos técnicos fundamentales a tener en cuenta en relación a la metodología aseguir para la integración en la plataforma de BI de los módulos que se requiere construir en este pliego. Estainformación puede ampliarse en el documento disponible en XuntaTic PLATBI_MU_manualIntegracion.

El desarrollo de las soluciones requeridas implicará cuando menos el desarrollo de cuadros de mando, deinformes predefinidos, y de cubos para el análisis libre.

Cuadros de mando:

Para añadir nuevos cuadros de mando es necesario construir una serie de scritps de actualización de variastablas de configuración del sistema, en concreto las siguientes:

• BI_T_ORIGEN: contiene información de los orígenes de los indicadores, siendo un origenel nombre que se le asocia a un grupo de indicadores.

• BI_T_PERSPECTIVA: contiene información relativa a la tipología en la que se agrupan losindicadores en el cuadro de mando

• BI_T_INDICADOR: contiene el catálogo completo de indicadores de la plataforma BI. Elidentificador de un indicador siempre referencia el código de proyecto establecido para elcuadro de mando.

Se deberán construir los procedimientos Oracle que implementen el cálculo de cada uno de los indicadores (unprocedimiento por cada indicador, temporalidad (diaria, semanal, mensual, anual) y tipo de sección,correspondiendo cada sección a cada una de las solapas de detalle que aparecen al seleccionar el indicador en elcuadro de mando, permitiéndose de este modo el desglose por distintas dimensiones. La primera solapa siempreserá “evolución”.

Informes:

Para poder integrar informes en la plataforma de BI es necesario construir, además de su construcción yalojamiento en el servidor de informes de la plataforma, una serie de scripts de actuación de varias tablas deconfiguración del sistema, en concreto las siguientes: BI_T_CARPETA; BI_T_INFORME.

Análisis libre:

Para poder integrar y explotar cubos en el módulo de análisis de la plataforma, estos deben ser desarrollados conla herramienta Mondrian, y desplegados en los servidores Pentahoo de la plataforma.

Carga de datos por hoja de cálculo:

Página 22/44



La plataforma de BI dispone de un módulo que permite la carga de datos por hoja de cálculo por usuarios finalesde modo controlado. Añadir la carga de un nuevo fichero implica crear una tabla en la zona de maniobra de labase de datos, la cual contendrá tanto los campos mapeados como otros que emplea la plataforma internamentepara su funcionamiento. Las parametrizaciones que además resultan necesarias pueden hacerse desde laadministración de tablas maestras de la plataforma. Por último debe crearse la ETL que alimente las tablas delmodelo de explotación.

Carga de datos manuales:

Este módulo de la plataforma permite introducir directamente por usuario final mediante formulario web elvalor de determinados indicadores, para que queden a disposición para su empleo en los cuadros de mando o enlos módulos de análisis libre. La inclusión de un nuevo indicador implica establecer ciertas configuraciones envarias tablas del sistema.

Diccionario

Según se establece en la metodología de desarrollo de proyectos sobre la platataforma de BI corporativa, deberácompletarse el diccionario del sistema, en el cual se refleja la descripción desde un punto de vista funcional delos distintos elementos implementados (cubos, cuadros de mando, dimensiones, indicadores, filtros, etc.). Esto esalgo al margen de la documentación funcional y técnica que debe elaborarse en el marco del proyecto según lasnormas metodológicas vigentes en la Amtega, en general para el desarrollo de sistemas de información, y enparticular para el desarrollo de proyectos sobre la plataforma de BI corporativa (documento de arquitecturafuncional-técnico, documentos de requisitos, documentos de diseño funcional, documentos de diseño técnico,cuadernos de carga, etc.).

6.2 SISTEMAS OPERACIONALES

Señalamos a continuación los sistemas de información operacionales que deben nutrir el sistema de informaciónanalítico requerido, indicándose el gestor de base de datos de cada uno de ellos:

• HSUE (historia social única electrónica): Oracle

• SIUSSGAL (sistema de información de usuarios de servicios sociales): Oracle

• SIGAD (sistema de información de atención a la dependencia): MySQL

• CENDIS (censo de discapacitados): Oracle

• PNC/RISGA/AIS (pensiones no contributivas/renta de integración social/ayudas deemergencia social): Informix

• RUEPSS (registro unificado de entidades prestadoras de servicios sociales): Informix

Esto sin menoscabo de que en el análisis funcional se determine la necesidad de complementar los anterioresorígenes con otros que resulten adecuados y necesarios para satisfacer los requisitos funcionales requeridos. Eneste sentido se tendrán en cuenta las funcionalidades ya descritas de la plataforma de BI en relación a la carga dehojas de cálculo o mecanización de indicadores. El listado anterior determina el marco mínimo de datamarts quese requieren, en consonancia con el marco de requisitos funcionales que se establecen en el pliego.

Página 23/44



7 ANEXO II: ALCANCE FUNCIONAL DEL PROYECTO

7.1 INTRODUCCIÓN

El objeto del contrato es el desarrollo e implantación de un sistema de información analítico que dé satisfacción alos principales requerimientos de análisis de la información, reporting y explotación de datos de varios ámbitosde información gestionados por la Consellería de Política Social en el ámbito de los servicios sociales de Galicia.

El sistema de información analítico a construir se desarrollará sobre la plataforma de BI corporativa de laAmtega, empleando las capacidades y la metodología de integración descritas en el Anexo Técnico. Estodetermina que la satisfacción de los requisitos de explotación y capacidad de análisis de la información que sepretenden cubrir se hará fundamentalmente a través de cuadernos de mando, informes predefinidos y cubosOLAP.

Actualmente no se dispone de ningún sistema de tipo BI en el mapa de sistemas que dan servicio a la Conselleríade Política Social. Los sistemas operacionales actuales, por su propia naturaleza, no satisfacen de modo completolas necesidades de explotación del área específica de gestión a la que dan soporte. De este modo se presentancarencias tanto en la explotación y análisis de la información a nivel vertical, como y sobre todo en el análisis deinformación cruzada entre distintos ámbitos. Este proyecto trata de resolver estas carencias a través de lacreación de un sistema de información analítica que incorpore datamarts específicos para varios sistemas desoporte a la gestión de especial relevancia.

Los ámbitos funcionales incluidos en el ámbito del proyecto incluyen varios ámbitos funcionales específicoscomo son dependencia, discapacidad, prestaciones de inclusión y servicios sociales comunitarios, junto con otrosde marcado carácter horizontal como son el derivado del sistema de gestión de la Historia Social ÚnicaElectrónica, y el del registro de entidades prestadoras de servicios sociales.

7.2 ALCANCE FUNCIONAL

El diseño de un sistema analítico del tipo del que se requiere en este proyecto implica, dentro de las tareas deanálisis y diseño, la definición de las dimensiones e indicadores que deben sustentar las capacidades dereporting y análisis. Esto requerirá tanto de un análisis específico para cada área vertical, como de un enfoquehorizontal que permita el establecimiento de dimensiones e indicadores comunes, satisfaciendo no solorequisitos específicos de un área de gestión, los cuales normalmente requieren la explotación del sistema deinformación de referencia concreto que aplique en cada caso, sino requisitos de explotación transversales uhorizontales que normalmente implican la información global del sistema.

En los siguientes apartados se establecerá el marco de requisitos funcionales que debe satisfacer el sistema, elcual se deberá interpretar como un marco funcional mínimo y orientativo. Aspectos como los cuadernos demando concretos a implementar, los indicadores y sus agrupaciones, las dimensiones contempladas y susopciones de desglose, los cubos a implementar, etc., serán determinados en la fase de análisis funcional.

En este anexo optamos por describir el marco de requerimentos mínimos del sistema a través de una descripciónde los mismos desde el punto de vista de los sistemas operacionales concretos que constituyen los principalesorígenes del sistema de información a desarrollar. Es decir, se hace una descripción orientada al desarrollo dedatamarts específicos, aunque deben tenerse en cuenta las consideraciones hechas en los dos párrafosanteriores.

Página 24/44



7.2.1 REQUISITOS FUNCIONALES COMUNES

En este apartado hacemos referencia a requisitos que en términos generales serán de aplicación a todos losmódulos y datamarts a desarrollar.

7.2.1.1 TIPOS DE ESTUDIOS SOPORTADOS

Análisis temporal:

• Evolutivo: consulta de los valores que fue tomando el indicador objeto de estudio a lo largo del tiempo(ejemplo: evolución mensual de horas SAF prestadas)

• Temporal puntual: consulta del valor que tomó el indicador en un momento dado (número de expedientes enestado propuesta)

• Temporal período: consulta del valor del indicador asociado a un período (número de prestaciones de ciertotipo concedidas en el año x).

Análisis Comparativo:

Consulta conjunta de dos tipos de información, de modo que sea posible su contraste.

• Temporal: ejemplo, comparación del valor de un año anterior frente al actual; se definirán indicadores deporcentaje de incremento

• Consecución de objetivos: comparación visual del valor frente al objetivo prefijado

Descriptivos: enfocados a consultar la información de un área para conocer detalle de la situación ycaracterísticas (ejemplo: detalle de las PNC de marzo).

Análisis de flujos de trabajo: consulta de información desde un punto de vista orientado a la gestión (ejemplo:tiempos medios de tramitación de las RISGA solicitadas en el período x).

Rankings: identificación de puntos fuertes y débiles mediante la consulta de valores más destacados (ejemplo:centros con más plazas disponibles).

Análisis de coberturas: consulta de la demanda de prestaciones y servicios y de los equipamientos (entre otroscentros y plazas) por zona geográfica; en concreto se soportará la representación gráfica de los indicadores sobremapas, cuando menos pudiendo indicar los contadores a nivel de ayuntamiento, empleándose elementos visualescomo distintos colores según tramo del indicador. Se pretende también que el sistema permita análisis de ratiosde cobertura, tanto los reales como la comparación con valores objetivo. Para ello se requiere la carga y gestiónpor el sistema de los datos oficiales del censo de población.

Análisis proyectivo: se pretende que en relación al análisis de los ratios de cobertura el sistema permita análisisproyectivos a futuro. Para ello se requiere la carga y gestión por el sistema de datos proyectivos de población.

7.2.1.2 DIMENSIONES COMUNES

En este apartado señalamos dimensiones que a priori resultan comunes a distintas áreas analíticas.

• Dimensiones generales relativas a la persona:

◦ Domicilio (para el análisis de la información desde el punto de vista geográfico)◦ Características básicas (sexo, estado civil, ocupación, nivel estudios, nacionalidad, edad y tramo edad,

colectivo)◦ Vivienda (tipo vivienda, tipo posesión, superficie, metros por persona, número personas, valoración,

entorno)

Página 25/44



◦ Datos económicos (valoración situación económica, ingresos anuales, gastos anuales, capacidadeconómica)

◦ Situación personal (emergencia social, violencia género, situación laboral)◦ Representante legal

• Dimensiones generales relativas a centros:

◦ Centro◦ Tipo centro◦ Centro activo◦ Número plazas

• Dimensiones generales geográficas (provincia, ayuntamiento, mancomunidad, comarca, área sociosanitaria)

7.2.1.3. ESTADÍSTICAS PRINCIPALES

Varios de los ámbitos objeto de análisis disponen de operaciones estadísticas IGE, como se señala en losapartados correspondientes. Estas explotaciones, junto a las que se puedan definir durante el tiempo deejecución del contrato en ámbitos que aún no disponen de operación específica, deberán ser soportadas por elsistema.

También deberán soportarse las estadísticas que se contemplan en la Memoria anual de la Consellería de PolíticaSocial en relación a los ámbitos objeto del proyecto. Puede consultarse, a modo orientativo, el contenido dedichas memorias en el apartado de Estudios e informes de la siguiente dirección:

https://politicasocial.xunta.gal/web/portal/portada-de-recursos.

7.2.2 HISTORIA SOCIAL ÚNICA ELECTRÓNICA

En la fase de análisis funcional del proyecto se determinará la estructura de áreas analíticas más adecuada, juntocon la forma concreta en la que se cubrirán las necesidades de análisis y reporting. Será en esa fase en la que seestablecen los cuadros de mando, cubos, e informes predefinidos a desarrollar. En este sentido los requisitos quese indican a continuación definen un marco funcional meramente orientativo.

Una posible propuesta inicial de las áreas analíticas a las que dará soporte el sistema es la siguiente:

• Área tramitación• Área persona• Área actuaciones• Área prestaciones• Área centros

Debe tenerse en cuenta que el sistema de HSUE carga información procedente de otros sistemas, entre los queestán los sistemas de información específicos contemplados en el proyecto. En este sentido hay análisis yexplotaciones de información que en un área concreta pueden ser resueltas tanto con la información específicagestionada por el vertical en cuestión (en muchos aspectos con mayor nivel de detalle o capacidades deexplotación), como mediante la explotación de la información del repositorio de HSUE. Estas posiblesduplicidades en las capacidades de análisis implementadas en distintos datamarts permitirán contrastar lainformación obrante en el sistema HSUE, debiendo aportar valor como herramienta de análisis de la calidad dedatos del sistema y de posibles problemas en el subsistema de integración de HSUE.

7.2.2.1 ÁREA ANALÍTICA TRAMITACIÓN

Esta área analítica recoge información sobre los expedientes mediante los que se tramitan las distintasprestaciones y procedimientos contemplados en el modelo de información del sistema, soportándose tanto elconcepto expediente como el de tramitaciones dentro de un expediente (trámite inicial, trámite de revisión, etc.).

Página 26/44

https://politicasocial.xunta.gal/web/portal/portada-de-recursos



Indicadores

Algunos de los indicadores recogidos en esta área son los siguientes. Realmente se trata en casi todos deagrupaciones de indicadores. Se señalan a modo de ejemplo orientativo del tipo de indicadores que serán deaplicación:

• Número de personas• Número de expedientes (iniciales y de revisión)• Número de tramitaciones• Número de solicitudes• Número de propuestas• Numero de valoraciones (de dependencia y de discapacidad)• Número de visitas a domicilio para valorar dependencia• Número de resoluciones• Número de expedientes archivados• Número de expedientes suspendidos• Número de recursos (presentados, estimados, rechazados)• Tiempo de valoración (tiempo que pasa desde la solicitud hasta la valoración en expedientes de dependencia

y discapacidad)• Tiempo de propuesta• Tiempo de resolución• Tiempo de resolución de la propuesta PIA desde la valoración de dependencia• Tiempo de tramitación PIA• Objetivo anual tiempo de valoración• Objetivo anual tiempo de propuesta• Objetivo anual tiempo de resolución

Dimensiones

Se señalan a continuación dimensiones que a priori resultarán de aplicación en esta área analítica. Nuevamentese señalan a modo de ejemplo orientativo de los tipos de dimensiones que serán de aplicación:

◦ Dimensiones relativas a la persona (señaladas en un punto anterior)◦ Representante legal◦ Expediente (tipo de expediente; motivo denegación; motivo archivo; motivo extinción)◦ Tramitación (tipo de tramitación; estado de tramitación)◦ Tipo reclamación◦ Tiempo (año, trimestre, mes, día)◦ Tipo discapacidad◦ Grado discapacidad◦ Movilidad reducida◦ Ayuda tercera persona◦ Diagnóstico◦ Grado de dependencia

7.2.2.2 ÁREA ANALÍTICA PERSONA

Esta área analítica está enfocada al análisis de las personas, debiendo señalarse que no será el único espacio en elque consultar información sobre la persona, ya que la persona como dimensión estará presente en el resto deáreas.

Se señalan a título orientativo posibles indicadores de esta área:

• Número de personas• Media de personas de la unidad familiar• Media de capacidades económicas

Página 27/44



• Media de ingresos• Media de gastos• Media de importe de deudas

Las dimensiones ya señaladas sirven de orientación del tipo de dimensiones que resultarán de aplicación en estaárea analítica.

7.2.2.3 ÁREA ANALÍTICA ACTUACIONES

Esta área analítica está enfocada al análisis a los proyectos de intervención gestionados en SIUSSGAL o PGIS(aplicación de soporte del plan gallego de inclusión social, integrada con HSUE).


• Número de proyectos• Número de actuaciones • Tiempo duración del proyecto• Tiempo duración de la actuación


• Proyecto (tipo de proyecto, tipo actuación)• Fecha inicio actuación• Fecha actualización intervención

7.2.2.4 ÁREA ANALÍTICA PRESTACIONES

Esta área analítica está enfocada al análisis de los servicios y prestaciones proporcionados por servicios sociales(en concreto aquellos cuya gestión se registra en los sistemas de información operacionales objeto del proyecto).No se enfoca a estudiar los trámites necesarios, sino la propia asignación de servicios. Se pretende también que elsistema soporte el análisis de información relativa a la demanda de las prestaciones y servicios, la ofertaexistente, la ocupación, y los grados y ratios de cobertura. Para satisfacer esto último es preciso combinarinformación de distintos operacionales. En particular en relación al análisis de servicios del tipo atención encentros se requiere tratar de manera combinada la información registrada en SIGAD y HSUE con la de RUEPSS.


• Número de beneficiarios• Número de prestaciones (idóneo, asignado, prestado)• Número de horas• Media de horas• Número de pagos• Importe de los pagos• Número de copagos• Importe de copagos• % incremento número prestaciones• % incremento horas• % incremento copago• Coste de la prestación• Objetivo anual número prestaciones• Objetivo anual número horas


Página 28/44



• Prestación (tipo prestación, intensidad, fecha inicio vigencia, fecha fin vigencia)• Fecha inicio asignación• Fecha actualización intervención• Dato pago• Concepto de nómina• Sueldo básico• Complemento alquiler• Complemento familiar• Idoneidad• Red de apoyo• Riesgo de claudicación de cuidador• Vive sola• Centro

7.2.2.5 ÁREA ANALÍTICA CENTROS

Esta área analítica está enfocada al análisis de la información de plazas de las distintas tipologías de centrosgestionadas desde el sistema de dependencia, soportándose el análisis de la evolución de la ocupación a lo largodel tiempo. Para el soporte de esta área se requerirá combinar la información de SIGAD, HSUE y RUEPSS.


• Número de plazas totales• Número de plazas disponibles• Número de plazas ocupadas• Número de plazas solicitadas• Número de plazas solicitadas y aceptadas• Tiempo medio de la estancia

Esta área se complementará con el data mart específico que permita analizar la información de SIGAD, donde segestiona la ocupación de ciertas tipologías de plazas y servicios vinculados, tanto por la modalidad de acceso condependencia reconocida como por libre concurrencia, y con el datamart de RUEPSS, lo cual permitirá el análisiscompleto de la oferta global del sistema de atención de servicios sociales.

7.2.3. SIGAD

7.2.3.1 INTRODUCCIÓN

SIGAD es el sistema de información que soporta la tramitación del procedimiento BS201A de reconocimiento dela situación de dependencia. Lo conforman distintos módulos, con tecnologías de desarrollo no homogéneas (enconcreto con una combinación de PHP y JAVA), pero compartiendo un repositorio de datos común. Los distintosmódulos comparten un CAS para autenticación y una línea de diseño común, de modo que funcionalmente sepresenta para el usuario final como un sistema único.

Además de soportar la tramitación de los servicios de dependencia, dispone de varios módulos de extranet,SIGAD-Ayuntamientos y SIGAD-Centros. Al primero acceden trabajadores sociales de ayuntamientos y de salud, yal segundo los centros que conforman la oferta de plazas del sistema. En ambos casos el sistema ofrece tantoinformación de trazabilidad de los expedientes de dependencia o libre concurrencia de aplicación en cadaámbito, como la gestión de los servicios de la cartera asignados desde los Servicios de dependencia perogestionados por otros niveles asistenciales. En concreto nos referimos al servicio de SAF en el caso de losayuntamientos y a los distintos servicios prestados a través de plazas de residencial o de día, de mayores o de

Página 29/44



discapacitados. En estos casos los respectivos módulos soportan el registro de información necesaria para lajustificación de la financiación y facturación de los servicios (nómina de SAF, nómina de Centros).

Por último debemos mencionar que el SIGAD se integra con el sistema de información SAAD del IMSERSO através de servicios web. En concreto dispone de un módulo orientado a usuario final que permite realizar ycontrolar las subidas de información. La información obrante se emplea por parte del IMSERSO para laliquidación del nivel mínimo.

7.2.3.2 ÁREAS ANALÍTICAS


Respecto de la periodicidad de refresco de la información, aunque se determinará en la fase de análisis funcional,a priori resultará suficiente y adecuado una periodicidad, tanto de las cargas como de la posibilidad de análisis anivel de período, mensual.

Estadísticas de tramitación

Se soportarán los datos estadísticos más relevantes en relación a las tramitaciones realizadas en un período,acumuladas hasta una fecha, con posibilidad de desglose por unidad, ayuntamiento, o en general las capacidadesde agrupación geográfica ya mencionadas.

• Estadística total acumulada:

Este cuadro de mando abarcará todos los registros hasta el día de hoy, mostrando el incremento anualy el total acumulado alcanzado a final de año.

Se implementarán indicadores orientados al trámite y orientados (por ejemplo, en la orientación altrámite varias valoraciones de un mismo beneficiario cuentan de forma independiente). Losindicadores principales son: número de solicitudes; número de valoraciones; número de resolucionesde grado (con desglose por nivel para datos históricos); número de resoluciones de grado conderecho; número de resoluciones de PIA (con desglose por modalidad de recurso).

Entre las dimensiones a contemplar están: ámbito geográfico; unidad de tramitación; estado delexpediente de grado; estado de expediente de tramitación del PIA. Se deberán soportar filtros quepermitan tener en cuenta las distintas situaciones de tramitación que se pueden dar (por ejemplo enrelación a la situación de PIA activos o no activos). En este sentido cabe señalar que será necesarioadquirir un conocimiento profundo tanto del modelo de datos de SIGAD como de su evolución en eltiempo, así como de las problemáticas que afectan a cómo figura o puede figurar registrada lainformación en el sistema y distintas situaciones que afectan a la calidad de datos, derivadas de lapeculiar evolución del sistema de protección de la dependencia en general y del sistema SIGAD enparticular (tramitación inicial en el SAAD, desarrollo inicial de una aplicación de soporte a latramitación del PIA, desarrollo posterior de una aplicación de soporte de la fase de grado, desarrollofinal del SIGAD sustituyendo a las dos aplicaciones anteriores, con varias fases de evolución, aún nocontempladas totalmente).

• Estadística total actual:

Este cuadro de mando mostrará una visión del total de tramitaciones realizadas en un período o totalde acumulado hasta la fecha de fin de período. Contemplará distintas posibilidades respecto a sobrequé fecha aplicar la restricción de período seleccionado: fecha de solicitud; fecha de resolución delPIA, etc. Resultan de aplicación las consideraciones señaladas en la estadística anterior respecto de losindicadores y dimensiones a contemplar.

Página 30/44



• Estadística de beneficiarios – histórico anual:

Este cuadro de mando abarcará todos los registros hasta el día de hoy, mostrando el incremento anualy el total acumulado alcanzado a final de año, con orientación al beneficiario (por ejemplo, unbeneficiario valorado en varias ocasiones contabiliza una sola vez).

Resultan de aplicación las consideraciones señaladas en las estadísticas anteriores respecto de losindicadores y dimensiones a contemplar.

• Estadística de beneficiarios – atendidos por período:

Similar al anterior, pero permitiendo filtrar para un período anterior concreto. Resultan de aplicaciónlas consideraciones señaladas en las estadísticas anteriores respecto de los indicadores y dimensionesa contemplar.

• Estadística de beneficiarios – acumulada por beneficiario:

Similar a las anteriores, pero filtrando por personas con expedientes activos, con agrupación por añoshasta la fecha actual. Resultan de aplicación las consideraciones señaladas en las estadísticasanteriores respecto de los indicadores y dimensiones a contemplar.

• Estadística de beneficiarios a una fecha:

Similar a las anteriores, pero orientada al número de personas con expedientes activos atendidas endependencia en la fecha indicada.

• Estadística de gestión:

Este cuadro de mando mostrará una visión de las tramitaciones realizadas teniendo en cuenta lasfechas de mecanización en la aplicación, en vez de las fechas relevantes a efectos de efectividad de lostrámites. Es decir, se orientará a la explotación de indicadores que muestran el trabajo realizado en undeterminado período.

Estadísticas de la in for mación subida al SAAD y del módulo de pago:

El IMSERSO dispone de un módulo de pagos abierto a las CCAA que permite la consulta de la información deliquidación mensual del nivel mínimo, en base a la información obrante en el SAAD, y en particular de lainformación subida al SAAD a través de los servicios web disponibles en el nodo de interoperabilidad delIMSERSO.

El sistema analítico deberá permitir al menos la elaboración en general de las estadísticas de la informaciónsubida al SAAD, y en particular de las estadísticas concretas que permitan contrastar la liquidación del nivelmínimo y la información empleada por el IMSERSO como base del proceso actual de certificación de la gestiónmensual.

Estadísticas de gestión de SAF:

Uno de los principales servicios de la cartera de servicios de dependencia es el SAF, asignado y financiado porDependencia y prestado desde los servicios sociales de los ayuntamientos. El sistema analítico deberá permitir elanálisis estadístico de los principales indicadores asociados en general a la asignación del servicio, y enparticular a la gestión de nómina asociada. Entre los indicadores relevantes cabe citar los siguientes:intensidades asignadas en el PIA, intensidades efectivamente prestadas, horas por modalidades de prestación,distribución diaria, incidencias por tipología, importes financiados y copagados, horas prestadas, horaspendientes de asignar, etc.

Estadística de centros:

Una de las tipologías principales de servicios de la cartera de servicios de dependencia es la de servicios de tiporesidencial o de atención diurna, asignado y financiado por Dependencia y prestado en los distintos tipos de

Página 31/44



centro que conforman la oferta de plazas públicas (centros públicos de gestión pública, centros públicos degestión privada, plazas conveniadas). La gestión de la derivación de las plazas se hace a través del módulo SIGAD-Centros, estando previsto abordar a corto plazo el desarrollo en SIGAD de la funcionalidad de gestión de lanómina de centros. El sistema analítico deberá permitir el análisis estadístico de los principales indicadoresasociados a la asignación del servicio, y en particular a la gestión de la nómina asociada en la medida en que estéimplementada en SIGAD. Entre los indicadores relevantes cabe citar los siguientes: personas asignadas, plazasocupadas, plazas libres, tiempos de estancia y de ausencia, tiempos medios de ocupación de plazas libres,tiempos medios de ocupación, importes financiados y copagados, horas asignadas y horas efectivamenteprestadas (en centros de atención diurna), etc.

En relación a las dimensiones, hay que señalar específicamente el hecho de que en estos servicios operanclasificaciones que determinan ámbitos claros de análisis diferenciado, como son en relación al colectivoatendido mayores y discapacitados, o en cuanto a forma de cobertura acceso por dependencia o por libreconcurrencia.

Estadísticas de análisis de la asignación de servicios:

La asignación de servicios se realiza normalmente (salvo las tramitaciones de emergencia en las que laasignación es directa) a través de los Planes de asignación de recursos (PAR), que operan como listas de acceso alos distintos tipos de servicios o prestaciones de la cartera, según los criterios de acceso establecidosnormativamente. Así están implementados los PAR de Centros, Teleasistencia y SAF. El sistema analítico deberápermitir el análisis estadístico de la asignación efectiva de los recursos. Esto es, de los principales indicadoresasociados a la asignación de los servicios, entre ellos: tiempo medio de estadía en el PAR; tiempos mediosglobales de asignación del servicio (desde la solicitud, desde el reconocimiento de grado, desde la resolución delPIA); tiempos medios en el que el usuario renuncia al PAR de servicios en favor de una prestación económicavinculado al servicio, etc.

Estadísticas y análisis de la demanda y asignación de servicio:

Uno de los aspectos que debe resolver el sistema analítico es el de las capacidades en relación al análisis de lacobertura actual del sistema frente a la demanda. La información principal objeto de análisis es la contenida en laelaboración del Plan Individual de Asignación (PIA), donde figura el recurso o recursos asignados de las distintascarteras vigentes actualmente, junto con sus intensidades, complementado con otra información relevante comolas preferencias mostradas por el solicitante o su perfil socio-económico (capacidad económica, número demiembros de la unidad familiar, personas a cargo, edad, sexo, red de apoyo, situación de emergencia social, etc.).El sistema analítico deberá dar satisfacción a este tipo de análisis, permitiendo tanto el estudio de la demanda ycobertura actual o a una fecha pasada, como estudios de evolución. Permitirá además análisis específicos sobre lavulnerabilidad de colectivos atendidos en razón del riesgo de claudicación de sus cuidadores.

7.2.3.3 EXPLOTACIONES HABITUALES

En este apartado señalamos explotaciones de información que tienen cierto grado de habitualidad, y que deberánser soportadas por el sistema analítico. Se incorporan en este apartado de Informes predefinidos por ser la formade implementación que a priori resulta más adecuada para la mayoría de ellas. La forma en la que cada una deellas quedará cubierta (a través de cuadros de mando, de informes predefinidos, o de análisis libre) variará, yquedará finalmente determinada en la fase de análisis funcional. En todo caso esto no conforma el catálogo deexplotaciones o de informes predefinidos a implementar en el proyecto (la forma de implementación en la que apriori muchos de estos requisitos serán cubiertos) sino que es meramente un listado mínimo y orientativo derequisitos de explotación a satisfacer.

• Explotaciones con el grado como concepto principal:

◦ Expectativas por grados◦ Expedientes fuera de plazo

Página 32/44



◦ Grados sin resolución de PIA◦ Datos acumulados de tramitaciones por año

• Explotaciones con el PIA como concepto principal:

◦ PIA de servicio X sin subir al PAR◦ PIA fuera de plazo◦ Datos de capacidad económica, copago y fecha de resolución PIA, según criterios de flitrado◦ PIA con libranza vinculada (LV) a servicio desglosado por unidades◦ PIA de libranza de cuidados en el entorno familiar (LCEF) para una franja de edades, sin atender / sin

resolver◦ PIA enviadas al SAAD entre fecha y fecha◦ Capacidades económicas de aplicación en Teleasistencias y Geolocalización◦ Importes de capacidad económica y copago por tipos de servicio, según criterios de filtrado◦ Total de importes de LCEF◦ Asignación de centros de días Alzheimer y otras demencias◦ Servicios de atención diurnos terapéuticos◦ Expedientes sin PIA efectivo

• Explotaciones con el PAR como concepto principal:

◦ Pendientes de asignación de centro de día (CD)

◦ Listados de centro de día combinado con SAF

◦ Listados de centro de atención residencial

◦ Listados con totales por ayuntamiento

◦ SAF revisado desde año xxxx

◦ Datos de expedientes en PAR

• Explotaciones con el SAF como concepto principal:

⁰ Usuarios activos de SAF por ayuntamiento

⁰ Listado de modificaciones del SAF asignado

⁰ Listado de SAF por provincia

⁰ Grados xx con expectativa SAF

⁰ Grados xx con SAF de ayuntamiento x

• Explotaciones con la Nómina SAF como concepto principal:

• Importe de la nómina del x trimestre por ayuntamiento/mancomunidad

• Direcciones de beneficiarios de una nómina

• Última nómina trimestral por ayuntamiento

• Explotaciones de tipo general:

◦ Estadística de llamadas de citación del 012

◦ Información de citas

Página 33/44



◦ Listados de usuarios de SIGAD, SIGAD-ayuntamientos, SIGAD-centros

◦ Datos estadísticos del Imserso

◦ Direcciones por DNI

◦ Listado de personas beneficiarias de Geolocalización

◦ Listados y estadísticas de tramitación de expedientes

◦ Información de presentaciones por Sede electrónica

◦ Estatísticas de diagnósticos CIE10

• Explotaciones con destino al IGE:

◦ Número de dictámenes

◦ Número de personas beneficiarias con pleno derecho a la prestación por ayuntamientos

◦ Número de personas beneficiarias con prestaciones concedidas por ayuntamientos

◦ Número de personas beneficiarias con prestaciones concedidas según sexo y tramos de edad

◦ Prestaciones concedidas por tipo

• Estadísticas por año:

◦ Tiempo entre solicitudes/revisiones y valoraciones en año xxxx sobre solicitudes/revisiones de xxxx queno son duplicados y que nunca fueron paralizadas

◦ Tiempo entre valoraciones y resoluciones de grado realizadas en xxxx sobre solicitudes/revisiones de xxxxque no son duplicados y que nunca fueron paralizadas

◦ Tiempo entre solicitudes/revisiones y resoluciones de grado realizadas en xxxx sobre solicitudes/revisiones de xxxx que no son duplicados y que nunca fueron paralizadas

◦ Tiempo entre resoluciones de grado y propuesta PIA realizadas en xxxx sobre solicitudes/revisiones dexxxx que no son duplicados y que nunca fueron paralizadas

◦ Tiempo entre propuestas PIA y resoluciones PIA realizadas en xxxx sobre solicitudes/revisiones de xxxxque no son duplicados y que nunca fueron paralizadas

◦ Tiempo entre solicitudes/revisiones y resoluciones PIA realizadas en xxxx sobre solicitudes/revisiones dexxxx que no son duplicados y que nunca fueron paralizadas

◦ Número de citas emitidas en xxxx por equipo◦ Número de expedientes pendientes de atención (de resolución PIA) que tengan propuesta PIA de

asistencia personal o expectativa de servicio de asistencia personal por provincia◦ Número de expedientes fuera de plazo por equipo◦ Número de expedientes de atención (pendiente de resolución PIA) de menores de xx años a fecha de

solicitud◦ Datos de gestión:

• Número de expedientes a fecha xx/xx/xxxx acumulados por equipos (solicitudes,valoraciones, resoluciones de grado, resoluciones con pleno derecho, propuestas PIA,resoluciones PIA)

• Número de expedientes a fecha xx/xx/xxxx activos por equipos (mismos indicadores queanterior)

• Número de resoluciones PIA por tipo de servicio/prestación a fecha xx/xx/xxxx• Número de tramitaciones por equipo a fecha xxxx

Página 34/44



7.2.4 PRESTACIONES DE INCLUSIÓN


Las principales prestaciones gestionadas en el área de inclusión de la Consellería de Política Social son laspensiones no contributivas (PNC) en sus distintas modalidades y la renta mínima de Galicia (RISGA) y ayudas deemergencia social, ahora denominadas ayudas de inclusión social (AIS). Estas prestaciones se gestionan en dosaplicaciones informáticas independientes, aunque con diseños muy similares (PNC y RISGA/AIS), que ademáscomparten parcialmente el modelo de datos, en concreto comparten las mismas tablas de poblacional. Enrelación a esto último cabe señalar que se ha previsto acometer a corto plazo la integración de estas aplicacionescon la API de servicios de HSUE en lo tocante a la integración a nivel de poblacional (consulta y alta de personas).Estos cambios deberán ser tenidos en cuenta en el diseño del sistema analítico en la medida en que se haganefectivos durante la ejecución del proyecto, bien en la fase de diseño funcional, bien en fases posteriores de ser elcaso, debiendo adaptarse los artefactos necesarios.

Las aplicaciones señaladas dan soporte a todas las fases de tramitación de los procedimientos administrativos dereconocimiento de las referidas prestaciones, nombradamente:

• BS650A, BS650G, BS650F: pensiones de invalidez o jubilación no contributivas; complemento dealquiler

• BS626F: renta de inclusión social de Galicia• BS618D: ayudas de inclusión social

Se soportan las fases de tramitación de los procedimientos involucrados (trámite inicial, requerimiento tanto aciudadano como a servicios sociales de ayuntamientos, revisión a instancia de parte, revisión de oficio, revisiónanual, bajas, paralizaciones, archivos, recursos y reclamaciones), junto con la gestión económica de las propiasprestaciones (gestión de pago único en el caso de AIS, gestión de prestación de pago mensual en el caso de PNC yRISGA: gestión de retenciones judiciales, gestión de indebidos, procesos de validación de nómina, gestión deincidencias, cierre de nómina). En el caso de las PNC la gestión es de la comunidad autónoma y la financiación esestatal. Esto determina el intercambio de ficheros de pago mensuales con el Ministerio de referencia. En el casode RISGA/AIS la financiación es completamente autonómica. En ambos casos (PNC y RISGA/AIS) las aplicacionessoportan la generación de los ficheros técnicos de envío de la información de beneficiarios al RPSP del estado(registro público de prestaciones sociales).



Respecto de la periodicidad de refresco de la información, aunque se determinará en la fase de análisis funcional,a priori resultará suficiente y adecuada una periodicidad, tanto de las cargas como de la posibilidad de análisis anivel de período, mensual.

Estadísticas de tramitación y de análisis de las prestaciones

Se soportarán los datos estadísticos más relevantes en relación a las tramitaciones realizadas en un período yacumuladas hasta una fecha, junto con el análisis de las prestaciones económicas implicadas. Los requisitos acubrir serán similares a los ya descritos en el apartado anterior dedicado a SIGAD, pero adaptados a los flujos de

Página 35/44



tramitación concretos de aplicación en estos procedimientos, y a las prestaciones económicas concretas que segestionan en este ámbito.


Respecto de las dimensiones a contemplar, aunque en términos generales resultará de aplicación lo yacomentado en apartados anteriores, cabe señalar de forma específica para este ámbito las siguientes:

• PNC:

◦ Tipo de pensión◦ Estados de los expedientes◦ Motivos de denegación◦ Rangos de importes de las concesiones◦ Dimensión geográfica (provincia, municipios, agrupaciones por distintos criterios, entre ellos por

rangos de población)◦ Dimensión temporal◦ Sexo◦ Edad (agrupaciones por tramos de edad flexibles; edad calculada en relación al mes de análisis)◦ Nacionalidad (extranjero o no y país de nacimiento; agrupaciones de nacionalidades)◦ Procedencia (altas en el sistema o procedencia de otras prestaciones)◦ Tipo de discapacidad◦ Complemento de tercera persona◦ Suspensión cautelar

• RISGA/AIS:

◦ Tipo de ayuda◦ Estados de los expedientes◦ Motivos de denegación◦ Dimensión geográfica (provincia, municipios, agrupaciones por distintos criterios, entre ellos por

rangos de población)◦ Dimensión temporal◦ Sexo ◦ Edad (agrupaciones por tramos de edad flexibles; edad calculada en relación al mes de análisis)◦ Tipo de convivencia◦ Tipo de vivienda◦ Régimen de tenencia◦ Nivel de estudios◦ Estado civil◦ Situación laboral◦ Problemática específica◦ Proyecto de inserción◦ Tipología (destino de la ayuda aplicable en AIS)◦ Número de conceptos (aplicable en AIS)◦ Retrasos◦ Complemento de inserción ◦ Estado del beneficiario◦ Motivo de baja

Página 36/44



Respecto de los indicadores, aunque en términos generales resultará de aplicación lo ya comentado en apartadosanteriores, cabe señalar de forma específica para este ámbito las siguientes (nuevamente la relación se refiere enla mayoría de los casos a grupos de indicadores):

• PNC/RISGA/AIS:

◦ Número de solicitudes nuevas◦ Número de solicitudes pendientes◦ Total solicitudes◦ Número de solicitudes acumuladas◦ Número de resoluciones por estado◦ Total de resoluciones◦ Tiempo de tramitación de solicitudes◦ Tiempo medio anual de tramitación de solicitudes◦ Tiempo medio acumulado de tramitación de solicitudes◦ Número de beneficiarios◦ Número de beneficiarios con retrasos◦ Número de beneficiarios de RISGA con variantes (complemento familiar, tramo inserción)◦ Importe medio prestación◦ Número de perceptores por sentencia judicial◦ Número de beneficiarios que recibieron IPC◦ Número de beneficiarios en suspensión cautelar◦ Importes mensuales concedidos (hasta desglose por beneficiario)◦ Importes complementos tercera persona (hasta desglose por beneficiario)◦ Importe IPC (hasta desglose por beneficiario)◦ Importe retrasos (hasta desglose por beneficiario)◦ Importe deducciones◦ Importe indebidos◦ Importe deducciones (distinguiendo deducciones por retención judicial)◦ Número de ayudas AIS pagadas◦ Número de facturas AIS◦ Media ingresos Unidad convivencia◦ % de denegaciones◦ % de beneficiarios

Debemos mencionar en relación a la RISGA que la Consellería de Política Social está trabajando en el desarrolloreglamentario de la Ley de inclusión social. Esto hace que sean previsibles variaciones a corto plazo en relación alos distintos tramos de la prestación, lo cual llevará aparejado adaptaciones de calado en la aplicación detramitación, y consecuentemente adaptaciones necesarias en el sistema analítico, tanto a nivel de nuevasdimensiones e indicadores, como de las explotaciones soportadas. Dichos cambios deberán ser atendidos, tantoen la fase de análisis funcional como en fases posteriores, en la medida en que dichos cambios operen durante laejecución del proyecto.

Cabe señalar que los modelos de datos de estas aplicaciones, además de no estar orientados a la explotación de lainformación, presentan carencias en cuanto al registro de información histórica que actualmente incidennotablemente en el esfuerzo necesario para la elaboración de las explotaciones requeridas por las unidadesfuncionales. En este sentido cabe apuntar que será necesario adquirir un conocimiento profundo tanto delmodelo de datos de las aplicaciones PNC/RISGA como de su evolución en el tiempo, así como de las

Página 37/44



problemáticas que afectan a cómo figura o puede figurar registrada la información en el sistema y distintassituaciones que afectan a la calidad de datos, derivadas de la peculiar evolución del sistema (desarrollo inicial deaplicaciones complementarias del SXPA con bases de datos distribuidas, reingeniería posterior de lasaplicaciones, con implantación de aplicaciones web centralizadas en 2013).

Informes predefinidos

Indicamos a continuación, a modo oritentativo, un ejemplo del conjunto de informes predefinidos que deberásoportar el sistema:

• Informes de gestión de expedientes

◦ Informe de seguimiento de estados de expedientes y tiempos de tramitación mensuales para un añodeterminado para PNC/RISGA con valores actuales y acumulados

◦ Número de solicitudes por municipio y rangos de población de los municipios

• Informes mensuales de solicitudes PNC

◦ Informe de solicitudes y acumuladas◦ Informe de resoluciones y acumuladas◦ Tiempo de tramitación de solicitudes (tiempos medios anuales, acumulado)◦ Número de beneficiarios (perceptores por sentencia judicial, beneficiarios que recibieron ipc, en

suspensión cautelar)◦ Importes: mensual, complemento 3ª persona, ipc, retrasos, deducciones, indebidos, deducción por

retención judicial, extra, importe pagado… asociado a un beneficiario en un mes concreto de un añoconcreto

◦ % de denegaciones PNC por motivos denegación

• Informes mensuales de solicitudes RISGA/AIS

◦ Número de solicitudes nuevas, pendientes, totales, acumuladas◦ Número de resoluciones, totales, acumuladas◦ Tiempo de tramitación de solicitudes (tiempo medio anual, acumulado) ◦ Número de beneficiarios asociados a ayudas de RISGA para un mes concreto y año concreto según

importes (risga con retrasos, risga con subsidio básico, subsidio básico + complemento familiar,subsidio básico + complemento familiar + inserción, subsidio básico + complemento familiar, subsidiobásico + complemento familiar + alquiler)

◦ Importe medio salarial RISGA para un mes concreto y año concreto◦ Importe concedido para AIS para un mes concreto y año concreto (importe concedido inicialmente)◦ Importe pagos de ayudas AIS para un mes concreto y año concreto (suma de los importes asociados a

las facturas de la ayuda concedida)◦ Número de ayudas pagadas AIS (número de expedientes diferentes presentando alguna factura) para

un mes concreto y año concreto◦ Número de facturas AIS (número de facturas en un mes de las ayudas concedidas)◦ Número de concesiones AIS (número de expedientes de AIS concedidos inicialmente) en un mes

concreto y año concreto◦ Media ingresos UEC por concesión (media de los importes asociados a un hogar de los expedientes

aprobados) para un mes concreto y año concreto◦ Media ingresos UEC por denegación (media de los importes asociados a un hogar de los expedientes

denegados) para un mes concreto y año concreto y para cualquier motivo de denegación◦ Número de bajas en el sistema RISGA en un mes y año concreto◦ % de beneficiarios RISGA (empleado para estudiar por las dimensiones que tienen varios valores

asociados a un beneficiario: problemática específica, tipología, motivo de baja)◦ % de denegaciones RISGA por motivos de denegación

Página 38/44



• Informes de beneficiarios:

◦ PNC:

▪ Número de beneficiarios por municipio y tipo de pensión▪ Informe de gestión mensual en trámite inicial mensual por provincia para envío a Ministerio▪ Detalle mensual de nómina PNC por año y provincia

◦ RISGA/AIS:

▪ Número de beneficiarios por municipio y tipo de ayuda▪ Detalle mensual de nómina por año y provincia▪ Número de beneficiarios con importe mensual y retrasos por año y provincia▪ Número de beneficiarios por sexo, tramos de edad, estado civil, tipo de convivencia, etc.▪ Distribución de beneficiarios por proyectos de inserción▪ Número de beneficiarios por sexo y municipio▪ Detalle mensual de pagos AIS, número de concesiones y número de facturas por año, provincia y

mes▪ Número de beneficiarios por sexo, tramos de edad, estado civil, tipo de convivencia, etc.▪ Número de beneficiarios AIS por tipología▪ Número de beneficiarios AIS por número de conceptos

Requisitos específicos

Actualmente está vigente una operación estadística con el IGE sobre beneficiarios de RISGA y de ayudas deinclusión social (ficha estadística 25-601). El sistema analítico deberá dar soporte a dicha explotación estadística.

7.2.5 DISCAPACIDAD


El procedimiento de reconocimiento de la situación de discapacidad (BS611A) se gestiona a nivel informático através de la aplicación CENDIS, que soporta todas las fases de tramitación (trámite inicial, revisiones de oficio y lainstancia de parte, citaciones, valoración por el equipo multidisciplinar de valoración, etc.).

Respecto de la valoración del grado de discapacidad, la aplicación soporta tanto las valoraciones específicas dediscapacidad establecidas en la normativa estatal correspondiente (real decreto de 1999), como la valoración denecesidad de ayuda de tercera persona a través de los instrumentos de valoración establecidos en el sistema dedependencia (BVD/EVE).

La valoración de dependencia y la de discapacidad, aún siendo valoraciones diferenciadas, con objetos yregulación específica, configuran un escenario en el que resulta relevante tanto la coordinación, debido a queexisten criterios de homologación entre valoraciones, y debido a lo ya referido de que se comparten en ciertoscasos instrumento de valoración, como el análisis de información cruzada, en línea con lo ya apuntado en elapartado previo dedicado a la HSUE.



Página 39/44



Estadísticas de tramitación y de análisis del censo de discapacitados

Se soportarán los datos estadísticos más relevantes en relación a las tramitaciones realizadas en un período yacumuladas hasta una fecha, junto con el análisis y explotación de la información del censo de discapacitados.Los requisitos a cubrir serán similares a los ya descritos en el apartado anterior dedicado a SIGAD en relación a lagestión de la tramitación y el análisis de la información de reconocimiento del grado, pero adaptados a los flujosde tramitación concretos de aplicación en estos procedimientos, y a las dimensiones e indicadores de análisis queresultan de aplicación al censo de discapacitados.


Respecto de las dimensiones a contemplar, en términos generales resultará de aplicación lo ya comentado enapartados anteriores, en particular en relación al reconocimiento de la situación de dependencia.

En relación a las dimensiones e indicadores específicos de aplicación al estudio de las características de lasdiscapacidades reconocidas, cabe señalar que está prevista la migración a corto plazo en CENDIS a la codificaciónbasada en CIE10, para lo cual se adaptará CENDIS, implementándose mapeos con las tablas de diagnósticosactuales, de modo que se soporte la posibilidad de continuidad de la explotación estadística. Estos cambiosdeberán ser tenidos en cuenta en el sistema analítico, tanto a nivel de nuevas dimensiones e indicadores, como delas explotaciones soportadas, tanto en la fase de análisis funcional como en fases posteriores, en la medida enque dichos cambios operen durante la ejecución del proyecto.

Cabe señalar que se ha previsto acometer en el corto plazo la integración de esta aplicaciones con la API deservicios de HSUE en lo tocante a la integración a nivel de poblacional (consulta y alta de personas). Estoscambios deberán ser tenidos en cuenta en el diseño del sistema analítico en la medida en que se hagan efectivosdurante la ejecución del proyecto, bien en la fase de diseño funcional, bien en fases posteriores de ser el caso,debiendo adaptarse los artefactos necesarios.

Cabe señalar que será necesario adquirir un conocimiento profundo tanto del modelo de datos de la aplicacióncomo de su evolución en el tiempo, ya que además de no estar orientado a la explotación de la información,presenta problemáticas que afectan a cómo figura o puede figurar registrada la información en el sistema yaspectos relacionados con la calidad de datos, derivados de la concreta evolución del sistema (tramitacióndurante un prolongado período de tiempo en una aplicación complementaria del SXPA con bases de datosdistribuidas, puesta en marcha en 2015 de una nueva aplicación web centralizada).


Actualmente está vigente una operación estadística con el IGE denominada Explotación del censo de personascon discapacidad (ficha estadística 25-701). Además debe remitirse información estadística al IMSERSO en unformato prefijado, también con periodicidad anual. El sistema analítico deberá dar soporte completo a ambasexplotaciones estadísticas.

7.2.6 SERVICIOS SOCIALES COMUNITARIOS


Recientemente, dentro del marco del proyecto de desarrollo de la HSUE, se realizó la migración del SIUSS delMinisterio de Sanidad, Servicios Sociales e Igualdad a la Xunta de Galicia, pasando a denominarse SIUSSGAL,siendo esta la herramienta de referencia (aunque no la única) en los servicios sociales comunitarios de Galicia,quedando configurada como un subsistema específico integrado con la HSUE.

En esta aplicación se registra la “ficha social” de los expedientes familiares en este ámbito de atención,permitiendo el registro de la intervención según la metodología de trabajo establecida: registro de la demanda,

Página 40/44



recursos idóneos y asignados, seguimiento de los recursos tras su tramitación, entre otros. El árbol de posiblesrecursos está jerarquizado, siendo el cuarto nivel el correspondiente al nivel de comunidad autónoma. Laaplicación soporta el esquema organizativo actual de este nivel de atención (nivel de unidades de trabajo social(UTS) dependientes de centros de servicios sociales (CSS)). La asignación de ciertos recursos en el móduloprincipal del sistema (denominado Troncal) habilita su gestión y seguimiento en módulos específicos delsistema, de uso menos extendido que el Troncal: módulos de violencia de género, maltrato infantil, y SAF.


Se requiere que el sistema analítico disponga de un datamart específico de la información del módulo Troncal deSIUSSGAL. En la fase de análisis funcional del proyecto se determinará la estructura de áreas analíticas másadecuada, junto con la forma concreta en la que se cubrirán las necesidades de análisis y reporting. Será en esafase en la que se establecen los cuadros de mando, cubos, e informes predefinidos a desarrollar. En este sentido,las referencias a dimensiones, indicadores y requisitos de explotación que se indican a continuación definen unmarco funcional meramente orientativo.


Respecto de las dimensiones a contemplar, señalamos a continuación una aproximación a las dimensionesespecíficas que resultarán de aplicación:

• Dimensión geográfica (provincia, municipio, mancomunidades, agrupaciones de ayuntamientos poráreas geográficas, agrupaciones de ayuntamientos por tramos de población, CSS, UTS)

• Dimensiones que caracterizan tanto a los miembros de los expedientes familiares como a los usuarios dela intervención:

◦ Estado civil (posibilidad de agrupaciones)◦ Nivel de estudios (posibilidad de agrupaciones)◦ Empadronamiento◦ Discapacidad/enfermedad◦ Grado de discapacidad◦ Ingresos (posibilidad de agrupación en tramos)◦ Nacionalidad (posibilidad de agrupaciones)◦ País de nacimiento (posibilidad de agrupación)◦ Relación con el titular del expediente◦ R.A.E (relación de actividad económica; posibilidad de agrupación en tramos)◦ Edad (posibilidad de agrupación en tramos)◦ Sexo◦ Ocupación

• Dimensiones asociadas a los Expediente familiares:

◦ Hacinamiento (posibilidad de agrupación en tramos)◦ Metros cuadrados de la vivienda◦ Equipamiento de la vivienda◦ Habitabilidad de la vivienda◦ Régimen de tenencia◦ Tipo vivienda

• Dimensiones asociadas a las intervenciones:

◦ Causas de no coincidencia con recursos aplicados◦ Gestiones de la intervención◦ Estado de la intervención

Página 41/44



◦ Estado del recurso◦ Sector de referencia◦ Con cargo a sistema de dependencia

• Dimensiones asociadas a las demandas:

◦ Grupo demandas◦ Tipo demandas◦ Demandas 3º nivel◦ Demandas 4º nivel

• Dimensiones asociadas a las valoraciones:

◦ Grupo valoraciones◦ Tipo valoración◦ Valoraciones 3º nivel◦ Valoraciones 4º nivel

• Dimensiones asociadas a los recursos idóneos:

◦ Grupo recursos idóneos◦ Tipo recurso idóneo◦ Recursos idóneos 3º nivel◦ Recursos idóneos 4º nivel

• Dimensiones asociadas a ayudas económicas:

◦ Tipo resolución◦ Tipo ayuda◦ Cuantía (posibilidad de agrupación por tramos)

• Dimensiones asociadas a fechas:◦ Fecha fin intervención◦ Fecha última actualización de la intervención◦ Fecha inicio de la intervención◦ Fecha apertura expediente◦ Fecha cierre/eliminación expediente

Respecto de los indicadores a contemplar, señalamos a continuación una aproximación a los indicadoresespecíficos que resultarán de aplicación:

• Número de expedientes• Número de miembros de expedientes familiares• Número de intervenciones• Número de usuarios de intervenciones • Número de usuarios distintos de intervenciones• Cuantía de ayudas económicas• Número de recursos (idóneos, aplicados)• Número de usuarios de recurso

7.2.7 REGISTRO DE ENTIDADES PRESTADORAS DE SERVICIOS SOCIALES


Un sistema de información de especial relevancia dentro del mapa de sistemas del área de Política Social es elque da soporte al Registro Unificado de Entidades Prestadoras de Servicios Sociales, denominado con elacrónimo de RUEPSS. Su importancia viene derivada del hecho de que este sistema de información contiene, porla naturaleza de la información que registra, y por el carácter obligatorio de la misma, información muy completa

Página 42/44



y actualizada del catálogo de entidades, centros y programas (entre otros conceptos que resultan de aplicación ala caracterización de la información registrada en este Registro) que conforma la oferta de recursos del sistema,en especial en lo tocante a equipamientos (centros y plazas de las distintas modalidades de atención, en virtud desu orientación a colectivos específicos).

Así el RUEPSS da soporte tanto al registro de la información de la oferta de recursos del sistema (tanto públicos,en sus distintas modalidades, como privados) como a la gestión de los procedimientos administrativos queregulan los aspectos sujetos a inscripción (alta de entidad, autorización de inicio de actividad, etc.). Puedeampliarse la información de los procedimientos a los que da soporte en la siguiente dirección web:http://avepss.traballoebenestar.xunta.es/.

El RUEPSS dispone de un perfil de acceso específico para las propias entidades, en las que tienen capacidad demantenimiento autónomo de cierta información, y de un perfil de acceso público, en el que cualquier ciudadanopuede consultar por distintos criterios de búsqueda y filtrado los datos del registro. La dirección de esta web, lacual permite obtener una buena aproximación al dominio de información objeto de este datamart, es la siguiente:https://politicasocial.xunta.gal/XiacWeb/.

Los procedimientos del Registro son competencia de la Subdirección general de inspección de servicios sociales.En este sentido el RUEPSS es la principal herramienta de trabajo de esta Subdirección, dando soporte de modointegrado con la información del registro a módulos específicos relacionados con la actividad inspectora, enparticular el módulo de Inspección, que permite establecer y hacer seguimiento de los planes de inspección delas distintas áreas de actuación.


Se requiere que el sistema analítico disponga de un datamart específico de la información del RUEPSS. En la fasede análisis funcional del proyecto se determinará la estructura de áreas analíticas más adecuada, junto con laforma concreta en la que se cubrirán las necesidades de análisis y reporting. Será en esa fase en la que seestablecen los cuadros de mando, cubos, e informes predefinidos a desarrollar. En este sentido las referencias adimensiones, indicadores y requisitos de explotación que se indican a continuación definen un marco funcionalmeramente orientativo.


Respecto de las dimensiones a contemplar, señalamos a continuación una aproximación a las dimensionesespecíficas que resultarán de aplicación respecto del análisis de la oferta del sistema (respecto del análisis de lagestión de la tramitación de los procedimientos del Registro, tanto dimensiones como indicadores seránsimilares a los indicados para dependencia y prestaciones):

• Entidad• Área• Tipo centro• Tipo usuario• Tipo programa• Categoría / subcategoría• Geográfica (provincia, ayuntamiento, área geográfica)• Tipo de plazas (según enfoque asistencial)• Puntos de atención• Con plazas públicas• Con plazas financiadas• Con plazas disponibles• Con horas disponibles• Con acreditación

Página 43/44

https://politicasocial.xunta.gal/XiacWeb/

http://avepss.traballoebenestar.xunta.es/



• Estado de la entidad• Estado del centro/programa• Instalaciones• Servicios disponibles• Categorías profesionales (por tramos o ratios)


• Número de entidades• Numero de centros• Número de plazas (totales, financiadas, públicas, con acreditación)• Número de horas• Número de personal

Respecto de los tipos de estudios que debe soportar el sistema mencionados en el apartado de “Requisitosfuncionales comunes”, cabe señalar que es en este datamart donde resultan especialmente relevantes los tipos deestudio de análisis de coberturas y de análisis proyectivo.


Actualmente está vigente una operación estadística con el IGE denominada Explotación del registro único deentidades prestadoras de servicios sociales (ficha estadística 25-603). Como referencia del tipo de informaciónque incluye esta estadística pueden consultarse los informes anuales publicados en la siguiente dirección:

http://avepss.traballoebenestar.xunta.es/informacion_estatistica_ruepss.html.

Página 44/44

http://avepss.traballoebenestar.xunta.es/informacion_estatistica_ruepss.html

pliego de prescripciones técnicas para la contratación del ... · sistema de información...

Documents