1. pliego de prescripciones técnicasxapps.lanbide.euskadi.net/apps/au_gn_upload... · •...

34
DESARROLLO E IMPLANTACIÓN DE UN SISTEMA PARA LA GESTIÓN, SEGUIMIENTO Y CONTROL DE LA PRESTACIÓN DE GARANTÍA DE INGRESOS Y DE LA PRESTACION COMPLEMENTARIA DE VIVIENDA PLIEGO DE CONDICIONES DE CONTRATACIÓN En Vitoria-Gasteiz, 14 de junio de 2011 1. INTRODUCCION La ley 18/2008, de 23 de diciembre, para la Garantía de Ingresos y para la Inclusión Social dio carta de naturaleza al Sistema Vasco para la Garantía de Ingresos e Inclusión Social, como sistema autónomo, constituido como un todo coherente e integrado, que si bien se construía sobre las bases sentadas a lo largo de las últimas décadas por un muy consolidado dispositivo de lucha con la exclusión social, suponía una reformulación del modelo anterior dirigido a su mejor adaptación a la clara evolución de las necesidades sociales y a la aparición de nuevas realidades. En ese modelo han venido jugando un papel clave los servicios sociales municipales y forales, constituyendo en el primer caso además, una red primaria altamente cualificada, que ha venido siendo clave como facilitadora y provisora de prestaciones sociales, incluidas las de carácter económico. Ese recién estrenado marco de estructuración y aplicación de la política de garantía de ingresos y de inclusión social sigue siendo plenamente válido en el momento actual, sin embargo el ejercicio competencial que en materia de activación laboral va a desarrollar la Comunidad Autónoma de Euskadi, y la necesidad de llevarla a cabo en este ámbito de la garantía de ingresos y la inclusión, aconsejan en este momento a dar traslado de esta política al dispositivo de empleo de Lanbide. En la actualidad, la gestión de la RGI y PCV se divide entre tres administraciones: Ayuntamientos (SSB/USB): responsables de la recepción e instrucción de las solicitudes Diputaciones Forales: a las que compete la resolución de las solicitudes Gobierno Vaco: al que corresponde el pago Con fecha 1 de enero de 2011 se han transferido a Euskadi las políticas activas de empleo que van a ser gestionadas por Lanbide-Servicio Vasco de Empleo, lo que permite asumir desde el Gobierno Vasco y, en particular, desde Lanbide, las competencias relacionadas con la tramitación y resolución de las prestaciones de RGI y PCV, así como de la elaboración, propuesta, negociación, suscripción y seguimiento de los convenios de inclusión. La centralización de ambos servicios en un único organismo permitirá reforzar la asociación directa entre ambos, favoreciendo el proceso de activación e inserción laboral de los beneficiarios de estas prestaciones. Actualmente, se encuentra en tramitación parlamentaria una modificación de la ley 18/2008 para atribuir a Lanbide las competencias de gestión de las prestaciones de Renta de Garantía de Ingresos (RGI) y prestación complementaria de vivienda (PCV). Los objetivos principales de la modificación de la Ley son: Garantizar el “doble derecho” que la Ley otorga a la sociedad vasca, por el que se reconoce a las personas, tanto el derecho a acceder a medios económicos suficientes para hacer

Upload: phungdiep

Post on 28-Sep-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

DESARROLLO E IMPLANTACIÓN DE UN SISTEMA PARA LA GESTIÓN, SEGUIMIENTO Y CONTROL DE LA PRESTACIÓN DE GARANTÍA DE INGRESOS Y DE LA

PRESTACION COMPLEMENTARIA DE VIVIENDA

PLIEGO DE CONDICIONES DE CONTRATACIÓN

En Vitoria-Gasteiz, 14 de junio de 2011 1. INTRODUCCION La ley 18/2008, de 23 de diciembre, para la Garantía de Ingresos y para la Inclusión Social dio carta de naturaleza al Sistema Vasco para la Garantía de Ingresos e Inclusión Social, como sistema autónomo, constituido como un todo coherente e integrado, que si bien se construía sobre las bases sentadas a lo largo de las últimas décadas por un muy consolidado dispositivo de lucha con la exclusión social, suponía una reformulación del modelo anterior dirigido a su mejor adaptación a la clara evolución de las necesidades sociales y a la aparición de nuevas realidades. En ese modelo han venido jugando un papel clave los servicios sociales municipales y forales, constituyendo en el primer caso además, una red primaria altamente cualificada, que ha venido siendo clave como facilitadora y provisora de prestaciones sociales, incluidas las de carácter económico. Ese recién estrenado marco de estructuración y aplicación de la política de garantía de ingresos y de inclusión social sigue siendo plenamente válido en el momento actual, sin embargo el ejercicio competencial que en materia de activación laboral va a desarrollar la Comunidad Autónoma de Euskadi, y la necesidad de llevarla a cabo en este ámbito de la garantía de ingresos y la inclusión, aconsejan en este momento a dar traslado de esta política al dispositivo de empleo de Lanbide. En la actualidad, la gestión de la RGI y PCV se divide entre tres administraciones:

• Ayuntamientos (SSB/USB): responsables de la recepción e instrucción de las solicitudes

• Diputaciones Forales: a las que compete la resolución de las solicitudes

• Gobierno Vaco: al que corresponde el pago

Con fecha 1 de enero de 2011 se han transferido a Euskadi las políticas activas de empleo que van a ser gestionadas por Lanbide-Servicio Vasco de Empleo, lo que permite asumir desde el Gobierno Vasco y, en particular, desde Lanbide, las competencias relacionadas con la tramitación y resolución de las prestaciones de RGI y PCV, así como de la elaboración, propuesta, negociación, suscripción y seguimiento de los convenios de inclusión.

La centralización de ambos servicios en un único organismo permitirá reforzar la asociación directa entre ambos, favoreciendo el proceso de activación e inserción laboral de los beneficiarios de estas prestaciones.

Actualmente, se encuentra en tramitación parlamentaria una modificación de la ley 18/2008 para atribuir a Lanbide las competencias de gestión de las prestaciones de Renta de Garantía de Ingresos (RGI) y prestación complementaria de vivienda (PCV). Los objetivos principales de la modificación de la Ley son:

• Garantizar el “doble derecho” que la Ley otorga a la sociedad vasca, por el que se reconoce a las personas, tanto el derecho a acceder a medios económicos suficientes para hacer

frente a las necesidades básicas de la vida, como el derecho a disfrutar de apoyos personalizados orientados a la inclusión social y laboral, al gestionarse desde una misma entidad los apoyos técnicos para la inclusión laboral y las prestaciones económicas.

• Aprovechar las ventajas que ofrece la centralización de la gestión de las prestaciones de RGI y PCV en un único organismo para simplificar el proceso administrativo, haciendo más ágil la gestión de la prestación, lo que permitirá reducir el tiempo de tramitación y, al mismo tiempo, aliviar la carga de trabajo que la gestión de las prestaciones económicas ha supuesto para muchos servicios sociales de base.

Con la nueva ley para la Garantía de Ingresos y para la Inclusión Social, la competencia para la gestión de las prestaciones de RGI y PCV se traslada a Lanbide, que será responsable de la tramitación integral de los expedientes (desde la recepción de la solicitud, hasta la resolución y el pago), así como de su posterior seguimiento y control.

Como parte de esta transferencia de competencias deberá asumir además la gestión de los expedientes que existen actualmente en las tres Diputaciones La nueva ley por la que se establece el nuevo Sistema Vasco de Garantía de Ingresos e Inclusión Social define como instrumentos orientados a la inclusión laboral y social los siguientes:

a) El convenio de inclusión activa considerado como dispositivo básico de articulación del

conjunto de acciones que se estimen necesarias para la inclusión laboral, integrando, asimismo, en su caso, el compromiso de cumplir las acciones orientadas a la inclusión social que puedan arbitrarse desde otros sistemas o políticas públicas.

b) Las medidas específicas de intervención, considerándose como tales tanto los programas, servicios o centros, organizados por LANBIDE, susceptibles de aplicarse, de forma combinada, en el marco de un convenio de inclusión activa, como los programas, servicios o centros organizados desde otros ámbitos de la protección social.

Esta nueva ley, establece un nuevo concepto de la renta de garantía de ingresos definiendo esta prestación como: “una prestación periódica de naturaleza económica, dirigida a las personas integradas en una unidad de convivencia que no disponga de ingresos suficientes para hacer frente tanto a los gastos asociados a las necesidades básicas como a los gastos derivados de un proceso de inclusión laboral o social.” Se establecen novedades en cuanto a las acciones de comunicación para la renovación, y de prórroga automática que deberá realizar LANBIDE, en los supuestos y para los colectivos que se determinen. La nueva regulación refleja el nuevo enfoque preponderante otorgado a la concesión de la renta de garantía de ingresos que estará vinculada al establecimiento con la persona titular de un convenio de inclusión activa al objeto de facilitar su inclusión o mejora laboral estableciendo las excepciones a dicha obligación general. En los casos en que la persona titular u otros miembros de su unidad de convivencia requieran, además de actuaciones orientadas a la inclusión laboral, actuaciones orientadas a la inclusión social que deban ser atendidas por los sistemas de servicios sociales, vivienda, sanidad o educación, el convenio de inclusión activa integrará en sus contenidos el compromiso por parte de la persona titular de cumplir las actuaciones de inclusión social que los distintos sistemas diseñen. Estar empadronadas y tener la residencia efectiva en cualquier municipio de la Comunidad Autónoma de Euskadi en el momento de la presentación de la solicitud y haber estado empadronadas y tener la residencia efectiva en cualquier municipio de la Comunidad Autónoma de Euskadi al menos con un año de antelación a la fecha de presentación de la solicitud.

Si no se cumple ese período mínimo previo, deberán haber estado empadronadas y haber tenido la residencia efectiva en cualquier municipio de la Comunidad Autónoma de Euskadi durante cinco años continuados de los diez inmediatamente anteriores. Se hace mención expresa a la facultad decisoria de LANBIDE para otorgar la condición de titular de la prestación a una persona, en el supuesto de que en una misma unidad de convivencia existieran varias que pudieran ostentar condición. Así como de la asunción de competencia por LANBIDE para realizar de oficio una revisión anual del cumplimiento de los requisitos de acceso a la prestación, sin perjuicio de que pueda proceder a cuantas revisiones estime oportunas para comprobar si se mantienen las causas que motivaron la concesión. La prestación complementaria de vivienda se concederá, en todo caso, previa comprobación, por parte de LANBIDE-Servicio Vasco de Empleo, de la existencia de una situación real de necesidad en relación con los gastos de la vivienda. 2. OBJETIVOS Y ALCANCE DEL PLIEGO 2.1. Objetivos La asunción de las Políticas Activas de Empleo por LANBIDE facilita el desarrollo de las competencias propias relativas a la Garantía de Ingresos e Inclusión Laboral orientada a promover la inserción laboral, incrementar los niveles de empleo y potenciar la estabilidad y calidad en el empleo. Durante los últimos meses LANBIDE ha definido el proceso de Gestión de la Renta de Garantía de Ingresos (RGI) y de la Prestación Complementaria a la Vivienda (PCV). Para la correcta gestión de estas prestaciones es necesario desarrollar un Sistema de Gestión, Seguimiento y Control de la RGI y PCV que funcione en la práctica con eficacia, agilidad y flexibilidad. El sistema de Gestión, Seguimiento y Control de la RGI y PCV cubrirá todo el proceso de gestión de estas prestaciones, desde la recepción de la solicitud de reconocimiento hasta la extinción de la prestación, pero únicamente desde la perspectiva de modelo de negocio. La implementación del procedimiento administrativo correspondiente a dicha gestión se realizará sobre RegexLan, por lo que queda fuera el ámbito del proyecto, pero se implantarán como parte de este pliego, las integraciones entre ambos sistemas. El cómo realizar esta integración se definirá de forma conjunta con la empresa que actualmente realiza RegexLan (bajo la supervisión del área de tecnologías de la información de Lanbide) durante la ejecución del proyecto. A través de la implementación de esta plataforma RGI/PCV, LANBIDE debe lograr la consecución de los siguientes objetivos:

� Lograr la eficacia y la calidad del servicio RGI/PCV ofrecido desde las oficinas, agilizando la recepción y tramitación de solicitudes y la resolución de las mismas.

Cumplir este objetivo, supone:

� Favorecer, en la medida de lo posible, la automatización del procedimiento: cálculos y validaciones automáticas, autocompletado de la información….

� Analizar, desarrollar e implantar los mecanismos que favorezcan la comunicación y colaboración entre las personas involucradas en el proceso

� Facilitar la obtención de información sobre el estado de las prestaciones y situación de la UC

� Recoger toda la información de la solicitud de las prestaciones y la información añadida por el personal de Lanbide como parte de su tramitación

� Vincular el derecho a la prestación a la firma de un convenio de inclusión

� Lograr la integración con otros sistemas que faciliten el seguimiento y verificación del cumplimiento de obligaciones

� Analizar, desarrollar y resolver las necesidades en lo que respecta a la explotación de información por parte de terceros

� Posibilitará a la ciudadanía la obtención de certificados electrónicas de la prestación

� Garantizar la seguridad del sistema de acuerdo a las exigencias del Esquema Nacional de Seguridad.

� Dotará a los miembros del equipo de RGI/PCV y al equipo de dirección de LANBIDE de indicadores e informes clave para la medición de sus niveles de gestión y de la evolución de la puesta en marcha de la RGI/PCV en LANBIDE.

� Facilitará a los empleados públicos la tramitación de los expedientes electrónicos RGI/PCV.

� Contribuirá a la disminución progresiva del papel en las oficinas de LANBIDE.

2.2. Descripción de los trabajos a realizar

1. Implantar un sistema de Gestión RGI/PCV que esté integrado con el Gestor de expedientes. Este sistema deberá contener las funcionalidades necesarias para gestionar el proceso RGI en su totalidad (reconocimiento, suspensión, extinción, modificación, reanudación, renovación, cobros indebidos, revisiones, seguimiento y control, y justificación del pago de la PCV). Además, deberá mantener la trazabilidad con el gestor de expedientes que se encargará de la apertura del expediente y del control de la documentación.

2. El sistema deberá lograr las integraciones entre los distintos módulos desarrollados en

este proyecto o propios de LANBIDE. Las integraciones mínimas que debe tener el sistema son las siguientes:

• Sistema Económico – Financiero (Pago mensual, partidas presupuestaria,

validación de terceros) • Sistema de Gestión de Expedientes • Sistema de Intermediación, Formación y Orientación • Plataforma de Firma • Sistema de Notificaciones • Generación de Documentos • Sistema de Gestión Documental • Maestro de Personas Físicas • Sistema de Autenticación y de Autorización

3. Realizar la migración de los datos de los titulares actuales de la RGI desde las tres diputaciones hasta el sistema de Gestión RGI/PCV en LANBIDE. El objetivo de esta tarea es la ejecución de los procedimientos necesarios para llevar a cabo la migración y carga inicial de datos del sistema. Los procedimientos asociados a la migración y carga inicial de datos son, principalmente, los relacionados con la preparación, la realización y la posterior verificación del proceso de migración desde cada Diputación.

4. Implantar una plataforma de firma. Construir una aplicación que encapsule el acceso

a los Servicios de Firma ofrecidos por Izenpe a través de su plataforma ZAIN y exponer estos servicios como servicios web de consumo interno y no acceder directamente a la plataforma del proveedor (Izenpe). De esta forma, las necesidades de firma electrónica podrán ser integradas dentro de aquellas aplicaciones de LANBIDE que así lo necesiten. La plataforma de firma se deberá integrar dentro de la arquitectura de LANBIDE como un servicio más capaz de ser utilizado por cualquier aplicación. En esta

línea se recubrirán sus métodos de envío y consulta a través de unos servicios web que se integrarán con la arquitectura a través del bus ESB principal.

5. Implantar una plataforma de notificaciones. Se corresponde con un desarrollo a

medida en tecnología J2EE que pudiera proveer al resto de aplicaciones de la organización de servicios para que se pueda realizar toda la gestión de correspondencia postal y los servicios necesarios para la notificación electrónica mediante el uso de SISNOT o de PLATEA. El sistema deberá realizar la gestión de la correspondencia electrónica, con el beneficio de que la gestión centralizada de la correspondencia en un único punto permitirá descargar de esta tarea al resto de aplicaciones, de forma que estas únicamente realicen peticiones de notificación y recogida de acuses de recibo.

6. Utilizar desde el RGI la plataforma de envío de SMS´s. Desde el sistema se utilizará

la plataforma para el envío de SMS’s como valor añadido al Ciudadano para informarle sobre determinados aspectos puntuales de la RGI/PCV. La plataforma de envío de SMS se deberá integrar dentro de la arquitectura de LANBIDE como un servicio más capaz de ser utilizado por cualquier aplicación. En esta línea se recubrirán sus métodos de envío y consulta a través de unos servicios web que se integrarán con la arquitectura a través del bus principal. (Oracle Services Bus).

7. Implantar un Generador de Documentos, que permita definir plantillas que

contengan información de distintas bases de datos que se obtiene a través de orígenes de datos y generar en tiempo de ejecución o fuera del tiempo de ejecución los documentos integrantes del expediente al objeto de formar el expediente digital. Uno de los requisitos es utilizar desde el sistema de gestión RGI/PCV este aplicativo a través de los servicios web que ofrece, con el fin de “solicitar la generación de las resoluciones” y “solicitar la entrega del mismo” al módulo de Notificaciones.

8. Implantar un Sistema de Gestión Documental que permita almacenar en un

repositorio centralizado la documentación asociada a la RGI/PCV. Procediéndose a la clasificación y tipificación de los distintos documentos de acuerdo con la estructura documental que se vaya definiendo a medida que se analicen los documentos asociados con cada procedimiento RGI/PCV. El sistema de Gestión documental se deberá integrar dentro de la arquitectura de LANBIDE como un servicio horizontal capaz de ser utilizado por cualquier aplicación. En esta línea se recubrirán sus métodos claves a través de unos servicios web que se integrarán con la arquitectura a través del bus principal.

9. Inventario, diseño y desarrollo de servicios en el BUS de ORACLE. Se dispondrá de

una arquitectura basada en estándares que fomenten la reutilización de componentes. Para favorecer esta reutilización se basa en los conceptos de abstracción de manera que la arquitectura permite el desacople absoluto de todos los componentes unitarios que la forman. Con esto se tiene una arquitectura capaz de proporcionar herramientas para la mecanización de procesos “de negocio” pero obviando la tecnología empleada que quedará en una capa subyacente.

10. Se construirá un Cuadro de Mando segmentando la información por distintos criterios

(geográficos, funcionales, edad, sexo,…..), que recoja indicadores desde las distintas perspectivas lo que facilitará la mejora de la gestión y la toma de decisiones.

11. Referente al Modelo de Gestión de la Seguridad de la información, el alcance central

son los procesos de seguridad aplicados a los procedimientos RGI/PCV. El modelo de gestión de la seguridad descansará sobre el desarrollo de las Políticas y del Cuerpo Normativo de Seguridad de Sistemas y Tecnologías de la Información de LANBIDE, que serán establecidas con el fin de proteger la información de la ciudadanía y las empresas. De ese modo, se seguirá cumpliendo con el marco normativo propio de las Administraciones Públicas y con las leyes que condicionan el uso de las tecnologías de la información.

12. Se deberá disponer de una plataforma de interoperabilidad en LANBIDE con otras administraciones para facilitar el intercambio de datos. Existentes distintas posibilidades que deberán ser analizadas y finalmente la empresa adjudicataria deberá realizar al menos tres servicios de intercambio con otras AAPP. Al menos tres servicios claves deberán ser implantados.

13. Formación, comunicación, pruebas y despliegues de cada uno de los módulos y de

la solución integrada en la infraestructura de LANBIDE.

14. Se deberá incluir un equipo de cinco profesionales que apoyen el despliegue de la solución dando soporte a los usuarios durante los distintos pasos a producción de la solución

2.3. Hitos clave Para la realización de estos trabajos se definen dos grandes hitos en la evolución hacia el nuevo Sistema Informático de RGI en LANBIDE:

• Octubre 2011: Nuevo Sistema de Información RGI para LANBIDE funcionando con las migraciones de las Diputaciones realizadas.

• Diciembre 2012: Sistema de Información RGI para el Servicio Vasco de

Empleo modernizado, tanto funcional como tecnológicamente. Las empresas que presenten oferta deberán incorporar como parte de la misma la propuesta de infraestructura tecnológica adecuada que permita que el nuevo sistema de información ofertado para LANBIDE funcione de la manera más óptima posible y en alta disponibilidad. 2.4. Alcance Funcional del Sistema

Para facilitar el proceso de análisis se ha dividido el sistema en diferentes subsistemas en base a su ámbito de gestión, y dentro de un subsistema se agrupan funcionalidades homogéneas o relativas al mismo proceso en distintos módulos.

• Subsistema de Gestión de Solicitudes

• Subsistema de Gestión de Prestaciones

Los subsistemas de Gestión de Solicitudes y Gestión de Prestaciones tendrán una fuerte interrelación con RegexLan y la plataforma de servicios de integración con otros sistemas tanto de LANBIDE como de otras entidades, organismos o administraciones.

• Sistema BI del servicio de prestaciones de RGI y PCV

• Subsistema de Explotación de la información del servicio de RGI y PCV para entidades externas

En el punto 3.4 se ofrece una descripción, a alto nivel, de los objetivos y descripción funcional de esos sistemas.

2.4.1. Usuarios del Sistema

2.4.1.1. Control de Acceso al sistema

La autentificación y seguridad de acceso a las aplicaciones es un servicio horizontal que está centralizado en un único componente en LANBIDE.

La autorización es propia de cada aplicación. Como parte de la ejecución del proyecto se especificarán las funcionalidades, necesidades y requisitos que debe cubrir el nuevo sistema y cuáles serán de ámbito del sistema de control de acceso y seguridad corporativa. Seguridad de Aplicación por perfil de usuario.

Sólo Consulta

(Dirección)

Normal (Administrativos, orientadores...)

Administrador (Informático)

Acceso a la aplicación C M M

Gestión de Solicitudes C M M

Gestión de Prestaciones C M M

Catálogo de Maestros C C M

En principio se proponen tres perfiles básicos:

• Consulta

Con acceso a todas las funcionalidades de la aplicación pero únicamente en modo consulta

• Normal

Con acceso a todas las funcionalidades de la aplicación en modo modificación, a excepción del catálogo de maestros al que sólo podrá acceder en modo consulta.

• Administrador aplicativo

Acceso a todas las funcionalidades de la aplicación en modo modificación. Este perfil sólo será necesario si se quiere centrar en una persona (o grupo de personas) el mantenimiento del catálogo de maestros (con el fin de mantener la coherencia de la información: redundancias, formatos de descripciones…)

En la definición del modelo de proceso de gestión a desarrollar se analizará la necesidad de establecer restricciones de funcionalidades por perfil de acceso, por ejemplo:

• si se diferencia entre administrativo general (sólo introduce la información de la solicitud) y administrativo de RGI (administrativos con conocimiento del negocio de la RGI y PCV que además de recepcionar solicitudes, verifican requisitos de acceso a la prestación….) será necesario definir un nuevo perfil que sólo tenga acceso al subsistema de sGS

• si se desea restringir el acceso a funcionalidades con mayor impacto dentro del proceso, como puede ser el cierre de nómina.

2.4.2. Sistemas Corporativos

Para dar soporte integral al proceso de gestión de la RGI y PCV el nuevo sistema se interrelacionará con otros sistemas, tanto internos de LANBIDE como sistemas de terceros:

Los sistemas que actualmente existen en LANBIDE y que por lo tanto no deben ser incluidos en el alcance del presente pliego son los siguientes:

• RegexLan

Sistema de gestión de expedientes corporativo de LANBIDE sobre el que se van a implantar los procedimientos administrativos que conlleva el proceso de gestión de las prestaciones de RGI PCV.

El envío en el sistema de una solicitud de RGI/PCV dará lugar a la creación de un expediente de tramitación en RegexLan, del mismo modo a lo largo de la tramitación de dicho expediente se deberá informar al sistema de gestión de la finalización de las tareas que se hayan considerado hitos de tramitación (para integración de ambos sistemas) y que darán lugar a un cambio de estado de la solicitud.

Si se ha optado por un proceso de resolución mensual (decisión a tomar como parte del modelo de gestión a implantar) el SGP deberá notificar a RegexLan el momento del lanzamiento de la nómina, lo que marcará el paso de las resoluciones en estado provisional a definitivo.

La resolución definitiva de un expediente cerrará el ciclo de vida de la solicitud y se actualizará el subsistema de Gestión, Seguimiento y Control de las prestaciones de RGI y PCV con la información global del expediente (datos de la solicitud más datos de tramitación).

No es parte del alcance del pliego actual.

• Persona física

Estructura que gestiona la información de las personas “clientes” de LANBIDE y en la que deberán integrase los beneficiarios de las prestaciones de RGI y PCV.

Actualmente está unido al concepto de persona empleable por lo que deberá adaptarse a nuevos tipos de clientes, por ejemplo menores.

Incluye información relativa a:

o datos identificativos

o datos sociales (nivel de estudios, ocupación….)

o domicilio (además del domicilio de empadronamiento, incluye también domicilio de notificaciones pero esta información se llevará también en el aplicativo de RGI)

En el ámbito de ejecución del proyecto se especificarán las necesidades, requisitos y funcionalidades derivadas de esta integración.

En principio la actualización de Persona Física se realizará desde el aplicativo actual, desde el sistema de RGI se enlazará con dicha aplicación para recuperar información, lo que significa que todos los beneficiarios de una solicitud/expediente deberán estar dados de alta en Persona Física en el momento del alta de la solicitud/expediente.

No es parte del alcance del pliego actual.

• Sistema de Intermediación, Orientación y Formación de LANBIDE

- Intermediación

El servicio de Intermediación de LANBIDE gestiona las ofertas y demandas de empleo, las personas y empresas inscritas, los emparejamientos entre ellas, servicios a demandantes...

Desde Intermediación se deberá comunicar al servicio de RGI de los rechazos de ofertas de trabajo ya que es motivo de extinción de la prestación de RGI rechazar en tres ocasiones, sin causa justificada, un empleo o una mejora en las condiciones de trabajo que pudiera conllevar un aumento del nivel de ingresos.

- Formación

El servicio de Formación gestiona las acciones formativas del catálogo de acciones formativas de LANBIDE que se proporciona a las personas que buscan empleo.

La formación será uno de los puntos clave en el proceso de activación de los beneficiarios de la RGI.

- Orientación

Uno de los objetivos de la transferencia de la gestión de la RGI y PCV a LANBIDE es garantizar el proceso de activación e inserción laboral de los beneficiarios de estas prestaciones.

La centralización de la gestión de la prestación en la entidad con competencia en políticas activas de empleo permite relacionar de forma directa ambos proceso, agilizando en gran medida el procedimiento (desde el momento de la solicitud se inicia el proceso de activación) y facilitando su seguimiento.

En el procedimiento de reconocimiento de RGI se deriva al expediente al Servicio de Orientación que se encarga de iniciar de iniciar el tratamiento del Plan Personal e Inclusión y del Convenio de Inclusión (para todos los miembros de la UC), a partir de ese momento se establece una interrelación entre ambos servicios:

� desde el servicio de RGI y PCV se deberá notificar al servicio de Orientación la resolución del expediente para iniciar el PPI y CI (no se puede iniciar con carácter previo a la resolución porque los beneficiarios de la RGI tienen carácter preferente que no se tendría en cuenta en caso de denegación)

� desde el servicio de Orientación se deberá comunicar al servicio de RGI de las obligaciones suscritas en el CI ya que son motivo de suspensión de la prestación

El nexo entre estos servicios será la Persona Física.

En el ámbito de ejecución del proyecto se especificarán las necesidades, requisitos y funcionalidades derivadas de esta integración.

No es parte del pliego actual.

• Sistema Económico - Financiero

El siguiente esquema muestra las interfases principales del sistema Gestión Económica y Pagos de Subvenciones con otros sistemas.

.

En verde están indicados los sistemas ya existentes y en amarillo y con trazo discontinuo los previstos desarrollar este año. En este funcional se sustituye la interfaz con Gestión Presupuestaria con la funcionalidad Incorporación de la Partida

Presupuestaria.Plataforma horizontal de pagos de LANBIDE.

El sistema de gestión de RGI y PCV deberá proporcionar al Sistema de Pagos toda la información necesaria para hacer el pago mensual (nómina): perceptor del pago,datos bancarios, importe…

En el ámbito de ejecución del proyecto se especificarán las necesidades, requisitos y funcionalidades derivadas de esta integración.

En este punto será de especial interés determinar:

o nóminas a realizar (nómina única, nóminas independientes para RGI y PCV…)

o desglose del importe (importe único, importe y atrasos, importe RGI, PCV y complemento monoparental…)

Los sistemas que se describen a continuación deben ser desarrollados dentro del alcance de este pliego garantizando su carácter de sistema corporativo LANBIDE, no únicamente respondiendo a las necesidades de la RGI:

• Plataforma de Notificaciones:

Esta plataforma deberá ser capaz de gestionar todas las notificaciones que deban ser emitidas por LANBIDE independientemente del canal por el que deban lanzarse, telemático o postal.

La aplicación consumidora deberá enviar toda la información necesaria para realizar el envío: información del titular, información de la notificación, información del fichero que contiene la notificación e información necesaria para realizar el registro electrónico.

La plataforma registra en base de datos la información de la notificación y de callBack para identificar quién ha realizado dicha petición y a quién hay que informar de los futuros estados de la notificación.

Diariamente, un proceso batch se encarga de obtener de BD las notificaciones pendientes de procesar y para cada una de ellas detecta si dicha notificación es telemática o postal. Si es telemática procede con el envío y si es postal la marca en BD como tal para su posterior procesamiento.

Notificación Telemática:

Las notificaciones deben estar soportadas por un sistema de notificación que usará medios electrónicos seguros, permitiendo acreditar la fecha y hora en la que se produce la puesta a disposición del interesado del acto objeto de la notificación, así como la de acceso a su contenido, momento a partir del cual la notificación se entenderá como practicada a todos los efectos legales. También reportará, en caso de rechazo, el motivo de rechazo y generará un apunte en el registro de salida de LANBIDE.

Este subsistema, en este pliego de condiciones, tendrá por objeto realizar un análisis de alternativas tecnológicas disponibles en el ámbito de las plataformas de notificaciones telemáticas fehacientes y la selección de acuerdo a las necesidades y características de la arquitectura tecnológica de LANBIDE.

Este tipo de servicios realizan el envío y seguimiento de las notificaciones, generando evidencias comprobables de la entrega por parte del emisor y la recepción por el destinatario, conforme al Real Decreto 209/2003 de 21 de febrero por el que se regulan los registros y las notificaciones telemáticas.

Este subsistema se centrará en la actividad siguiente: Estudio y evaluación de diversas soluciones de notificación en base a pilotos, testeando las necesidades de parametrización de las soluciones para adaptarlas a las características de la arquitectura tecnológica de LANBIDE.

Se debe realizar:

Un estudio de las diferentes alternativas.

Elección e integración con los sistemas de LANBIDE de la solución aceptada.

Las posibilidades conocidas son:

Adherirnos a la plataforma de notificación telemática de correos SISNOT. Es una iniciativa del Ministerio de Administraciones Públicas en colaboración con Correos. En un único buzón podrá recibir todas las notificaciones y comunicaciones de la Administración.

Utilizar la plataforma de notificación telemática del Gobierno Vasco: El organismo emisor del trámite habrá incluido los datos de la notificación en la plataforma de notificación del Gobierno vasco. La persona interesada, previa identificación mediante el empleo del certificado electrónico reconocido, podrá acceder a la notificación en la dirección electrónica www.euskadi.net.

Requisitos mínimos a cumplir:

1. Debe gestionar el censo de procesos /personas a notificar electrónicamente.

2. Debe realizar un aviso a la persona interesada de la existencia de la notificación con mero valor informativo.

3. Debe garantizar la autenticidad e integridad de la notificación.

4. Debe acreditar la fecha y hora en que se produzca la puesta a disposición de la persona interesada del acto objeto de notificación.

5. Se debe acreditar la fecha y hora en que la persona interesada accede al contenido de la notificación.

6. Debe generar evidencias comprobables de la entrega por el emisor y la recepción por el destinatario.

7. Debe incluir un sistema de información del estado de las notificaciones.

8. El servicio debe funcionar de forma ininterrumpida las 24 horas todos los días del año. Debe dejar constancia de cualquier interrupción del servicio que imposibilite la práctica de la notificación. Resolviendo esta interrupción en la contabilización de plazos.

9. Se debe obtener una simplificación de la gestión de las notificaciones telemáticas en las aplicaciones corporativas ya que estas sólo deben realizar peticiones de notificación (previa comprobación de que el ciudadano ha solicitado la notificación por dicho canal) y recogida de incidencias.

Notificaciones postales: Enlotado y envío

Como paso previo al envío de las notificaciones postales es necesario determinar el número de lotes pendientes de procesar y enviar las notificaciones postales pendientes. Es necesario generar una base de datos y un interfaces de consulta y de entrada de datos que pueda ser utilizado por la empresa responsable de los envíos postales, tanto para recoger la información como para incluir la información relativa a la entrega.

Periódicamente para postales, la mediación callBack se encarga de informar a las aplicaciones emisoras de notificaciones de los estados de las mismas.

Durante el proceso de envío de la notificación también se informa a la aplicación emisora sobre los eventos relevantes: cuando se determina si la notificación es postal o telemática, cuando se realiza el envío de la notificación telemática.

• Plataforma de Firma:

LANBIDE pretende firmar un convenio con Izenpe para utilizar los servicios de firma que ofrece la plataforma ZAIN. Esta plataforma de servicios de firma ofrece un conjunto completo de servicios de confianza basados en infraestructuras de clave publica (PKI), de una forma estándar y orientada a servicios, los cuales pueden ser usados por cualquier tipo de consumidor, ya sea usuario final, aplicación u otro servicio. Estos servicios se ofrecen mediante web services para ser invocados por las aplicaciones de LANBIDE.

Para evitar el uso directo de estos servicios web de la plataforma ZAIN por parte de nuestras aplicaciones, y conseguir encapsular, desacoplar e independizarlas de la plataforma ZAIN, LANBIDE necesita desarrollar una plataforma horizontal de firma.

Además de evitar la dependencia de la plataforma ZAIN, esta plataforma propia de LANBIDE permitirá utilizar la plataforma ZAIN de manera fácil y segura por el resto de aplicaciones, unificando la forma de acceso y simplificando los mantenimientos futuros.

El proyecto consiste en construir una aplicación que encapsule el acceso a los Servicios de Firma ofrecidos por Izenpe a través de su plataforma ZAIN y exponer estos servicios como servicios web de consumo interno y no acceder directamente a la plataforma del proveedor (a día de hoy Izenpe).

De esta forma, las necesidades de firma electrónica podrán ser integradas dentro de aquellas aplicaciones que lo necesiten. Esta nueva aplicación tendrá las siguientes particularidades:

1. Gestión de entes, aplicaciones y certificados de autenticación y firma: Debe controlar los entes (sociedades, organismos…) y aplicaciones que están autorizadas a usar la plataforma y el certificado de autenticación y firma que puede utilizar cada ente y aplicación.

2. Registrar intentos de firma y sellado de tiempo (Correctos e Incorrectos):

Debe registrar cada intento de firma y sellado de tiempo en ZAIN en una base de datos para su posible explotación, indicando si ha sido válida o no la acción.

3. Registrar verificaciones de firma de acto administrativo (NO de firma para logon): Debe registrar cada verificación de firma que se realice contra ZAIN, siempre y cuando no sea una firma para hacer logon en un sistema.

4. Encapsular las funcionalidades de ZAIN: Debe encapsular todas las llamadas a los servicios web de ZAIN ((Plataforma de Servicios de Firma de Izenpe), simplificando las llamadas.

5. Encapsular las funcionalidades del Servicio de Constancia de Publicación de Izenpe : Debe encapsular las llamadas a los 2 servicios web expuestos por Izenpe relativos al servicio de Servicio de Constancia de Publicación de Izenpe.

6. Gestión de errores de la plataforma: Debe tratar y registrar todos los errores que se produzcan en la plataforma.

• Generador de Documentos

Se estima que existen aproximadamente 255 plantillas diferentes que deberán utilizarse dinámicamente en función de los requisitos y estados del expediente para generar más de 60.000 documentos anuales. Para ello el adjudicatario deberá plantear una solución que permita una sencilla creación de documentos en función de las variables establecidas por la aplicación de gestión de la RGI/PCV. Estas funcionalidades se enumeran a continuación:

• Edición. • Composición de documentos, de 2 tipos: Interactiva o en servidor

(background). • Firma digital o biométrica. • Conversión a PDF / publicación

Una vez generados los documentos deberán ser almacenados en el gestor documental con los metadatos establecidos.

• Gestor Documental

Una de las principales necesidades derivadas de la administración electrónica es la gestión, almacenamiento y conservación de los documentos en formato electrónico que puedan generarse o recibirse por parte de la administración. Esta necesidad obliga a plantear soluciones sistematizadas y los más globales posibles, que permitan realizar de forma eficaz y eficiente las labores necesarias con esta documentación y con seguridad jurídica.

Por lo tanto, un documento electrónico tiene un conjunto de requisitos:

• Autenticidad: Acreditar que un documento es auténtico. Protección frente a adiciones, supresiones, modificaciones, utilizaciones u ocultaciones no autorizadas.

• Integridad: Asegurar que los documentos que se custodian permanecen completos e inalterados

• Confidencialidad: Impedir accesos no autorizados a los documentos custodiados

• Conservación: Velar por la permanencia de los documentos para garantizar su acceso a lo largo del tiempo.

• Disponibilidad: Facilitar que la información esté permanentemente a disposición de los legitimados para acceder a ella

• Trazabilidad: Generación de Auditorías y rastros de acceso.

• Fiabilidad: Representar de forma completa y precisa las actividades y procesos de la organización para Impedir que las modificaciones o transferencias que se produzcan en el sistema repercutan en las características de los documentos almacenados.

LANBIDE requiere, por tanto, un Sistema de Gestión Documental que sea garante y depositario de toda la documentación electrónica relativa a los expedientes de RGI/PCV. Necesitamos, por tanto, un Sistema de Gestión Documental que sea garante y depositario de toda la documentación electrónica, sistema que en adelante denominaremos Archivo Electrónico. El Archivo Electrónico se define como un sistema de gestión de documentos electrónicos y sus metadatos, guardados con criterios de archivo, y gestionables mediante servicios web. El Archivo Electrónico posibilitará el disponer de un archivo unificado y homogeneizado, desde el que los distintos subsistemas de la plataforma de Administración Electrónica puedan archivar y recuperar documentación electrónica.

• La construcción de un archivo de estas características exige identificar en primer lugar los principios que deben regir la Gestión Documental asociada a la RGI/PCV.

• Los principios generales de Gestión Documental que se establezcan servirán como marco de referencia que permita facilitar un modelo de gestión documental en el que el volumen de los documentos electrónicos aumente de forma considerable y los procesos de gestión documental estén normalizados conforme a la legislación y normativa de aplicación.

• Asimismo se deberá definir la estrategia para la construcción de dicho Archivo Electrónico y su integración con los distintos subsistemas de RGI. Puesto que la arquitectura propuesta para la plataforma de RGI estará orientada a servicios (WS), la estrategia contemplará la definición de servicios de acceso al archivo documental que faciliten la integración del Archivo Electrónico con los subsistemas y aplicaciones que requieren archivar y recuperar documentos.

• Para la implementación del archivo electrónico se propone utilizar las capacidades de gestión documental que ofrece el producto Alfresco.

El adjudicatario deberá tener en cuenta que aunque el objetivo es resolver la problemática documental de la RGI, a partir de este proyecto el Gestor Documental será el repositorio documental interno de LANBIDE, utilizado por los diferentes usuarios de LANBIDE en la tramitación de los expedientes, y recogerá los documentos proporcionados por los ciudadanos una vez digitalizados así como los documentos generados a lo largo de la vida del expediente en el proceso de tramitación.

Las principales características del Archivo Electrónico deben ser: Repositorio Común de documentos electrónicos, Servicios Documentales (almacenamiento, búsquedas, trasformación de formatos, …), Conservación y custodia de Documentos, Control de Acceso a Documentos, Cumplimiento de LOPD, Gestión de Registro de Accesos, Gestor Documental con potencialidades de un ECM (Enterprise Content Management), Arquitectura SOA., posibilidad de almacenamiento de documentos encriptados, Cumplimiento de los requisitos de Seguridad. Autenticidad, Integridad, Disponibilidad, Confidencialidad y Conservación.

• Plataforma de servicios de integración con sistemas externos (Gobierno Vasco, Seguridad Social, Haciendas Forales, Ayuntamientos, …)

Con los siguientes objetivos:

o Simplificar la documentación administrativa a presentar

o Recuperación automática de datos (padrón, datos económicos….=

o Verificación de la información presentada tanta en el momento del reconocimiento de la prestación como en procesos de control y seguimiento periódicos

En el ámbito de ejecución del proyecto se especificarán las necesidades, requisitos y funcionalidades derivadas de esta integración.

En este punto cabe destacar que será necesario establecer convenios de colaboración y desarrollos en dichos sistemas por lo que será un objetivo a cumplir a largo plazo. Se deberá establecer por lo tanto un plan de integración gradual.

La resolución definitiva de un expediente cerrará el ciclo de vida de la solicitud y se actualizará el subsistema de Gestión, Seguimiento y Control de las prestaciones de RGI y PCV con la información global del expediente (datos de la solicitud más datos de tramitación).

2.5. Descripción Funcional del Sistema

2.5.1. Subsistema de Gestión de Solicitudes

El objetivo de este subsistema es gestionar toda la información relativa a las solicitudes (reconocimiento y modificación de datos) de las prestaciones de RGI y PCV recibidas en LANBIDE.

Desde el punto de vista funcional, abarca el ámbito de gestión de la grabación de solicitudes y engloba las funcionalidades necesarias para el acceso y mantenimiento de los datos que conforman la entidad Solicitud:

• Alta solicitud (reconocimiento y modificación)

• Baja solicitud (será necesario determinar el tipo de baja a realizar: lógica, física o ambos)

• Modificación solicitud

• Consulta solicitud

• Búsqueda de solicitudes (dado el volumen de información que gestiona este subsistema será necesario establecer los criterios necesarios para no penalizar el rendimiento: limitar el número de registros a mostrar, establecer unos criterios de selección mínimos….)

• Consultas y Listados

Los datos de una solicitud se agrupan en:

• Datos solicitud: fecha, referencia, idioma, oficina donde se ha presentado

• Datos titular: datos identificativos, datos nacimiento, datos contacto

• Datos empadronamiento: domicilio, datos empadronamiento CAPV

• Datos UC: miembros, capacidad económica

• Datos notificación: datos representante, domicilio

• Datos PCV: importe gasto en vivienda, arrendador, indicadores cumplimiento requisitos

• Otros datos: indicador situación de maltrato doméstico, situación excepción cumplimiento edad mínima

• Observaciones

El documento de solicitud, así como el resto de documentos que la acompañan se digitalizarán y se almacenarán en el gestor documental.

Este subsistema está relacionado con el Gestor de Expedientes. La recepción de una solicitud da lugar al inicio de la tramitación de un expediente y la finalización de ciertas tareas/trámites deberá reflejarse en el estado de la solicitud. En lo que respecta a información, ambos sistemas comparten como mínimo los datos generales de cualquier solicitud: solicitante, interesados del expediente como puede ser el representante, datos notificación (idioma, domicilio)…

Como parte del ámbito del proyecto se determinará que funcionalidades quedan dentro del marco del sistema de negocio y cuales forma parte de la tramitación del expediente (y por lo tanto se desarrollarían como parte de la implementación de los procedimientos en RegexLan).

Deberá analizarse, además, el modelo de integración entre ambos sistemas en base al cual puedan compartir datos y notificar acciones en ambos sentidos, que puedan desencadenar actuaciones en uno y otro sistema.

En una primera fase dicho modelo puede ser tan básico como la generación de un procedimiento de avisos en el que cada sistema genere un aviso en determinados puntos de su proceso, de forma que dichos avisos puedan ser recogidos por el otro sistema y desencadenar (de forma manual y/o automática) las acciones que correspondan.

Como puntos de integración entre ambos sistemas se definen:

Sistema RGI Acción desencadenante

RegexLan Acción a realizar

Envío de la solicitud

(Estado solicitud = iniciada)

Inicio del procedimiento correspondiente (concesión en caso de solicitud de reconocimiento, modificación, suspensión,… en caso de solicitud de modificación)

RegexLan Acción desencadenante

Sistema RGI Acción a realizar

Inicio expediente Cambio estado de la solicitud: iniciada -> en proceso

Propuesta resolución Cambio estado de la solicitud: en proceso -> propuesta provisional (1)

Resolución Cambio estado de la solicitud: propuesta provisional -> resuelta (1)

Inicio proceso volcado información al sGP (datos de la solicitud más datos de tramitación).

Vueltas atrás Cambio estado de la solicitud: propuesta provisional -> en proceso

(1)El estado resuelta podría desglosarse en: resuelta concedida, resuelta denegada, resuelta modificada, resuelta suspendida, resuelta extinguida, resuelta renovada. Lo mismo podría decirse para el estado propuesta de resolución.

El estado de la solicitud ofrece una visión general de la situación del expediente correspondiente aunque el detalle del mismo deberá consultarse desde el sistema de gestión.

De cara al seguimiento de la prestación se considera importante asociar cada resolución con la solicitud que la ha generado, de este modo podremos, partiendo de la situación actual del expediente consultar todas las modificaciones sobre las condiciones de reconocimiento iniciales.

En el caso de las resoluciones de modificación, será condición indispensable que el solicitante sea titular de una prestación activa (no extinguida). Previo a la introducción de datos se recuperará la información correspondiente a la situación actual, sobre la cual se introducirán las modificaciones solicitadas. Si se considera necesario conocer las variaciones respecto a la situación anterior de un modo rápido (texto descriptivo) se estudiará la/s forma/s de su generación automática durante la grabación de la información.

Todos los beneficiarios de la RGI deberán estar registrados en el sistema de Persona Física de LANBIDE y en principio se establece que el alta y modificación de la información se realice en el aplicativo actual. Será necesario determinar el procedimiento a seguir cuando, derivado de la gestión de otros servicios, se modifiquen los datos de los beneficiarios de RGI ya que hay datos cuya modificación no tiene impacto en el negocio pero no ocurre lo mismo con otro tipo de información como puede ser un cambio de domicilio.

Todas las viviendas (domicilio de empadronamiento) se registrarán en el Maestro de Ubicaciones (que se describe en el apartado 2.5.2)

Determinadas solicitudes de modificación de datos no implican la tramitación de un expediente, por ejemplo un cambio de cuenta bancaria, por lo que será necesario determinar el procedimiento a seguir en esto casos. Puede que ni siquiera se considere necesario registrar la solicitud y se realice la modificación directamente en el SGP.

Como parte de este subsistema se han incluido funcionalidades propias de la tramitación de expedientes que, en función de la implementación de los procedimientos puede ser utilizadas únicamente como una simulación que facilite el trabajo de los usuarios (automatizando, en la medida de lo posible, las tareas a realizar)

• Verificar el cumplimiento de requisitos

Muestra los requisitos de acceso a la prestación de RGI o RGI y PCV (en función de las prestaciones solicitadas).

Por cada requisito se muestra:

o descripción

o propuesta: sólo tendrá contenido en aquellos requisitos que puedan ser verificados automáticamente, bien sea a partir de la información de la solicitud (por ejemplo edad) como a través de servicios de integración con otros sistemas

o revisado: indica que el requisito ha sido revisado por el usuario

o cumple: resultado del al verificación del requisito (cumple/no cumple)

o excepción: sólo tendrá contenido en aquellos requisitos para los que la normativa establece excepciones a su cumplimiento

Esta funcionalidad una tabla de parametrización, que se mantendrá desde el catálogo de maestros, donde se defina:

o descripción requisitos

o si es o no automático y en caso afirmativo podría especificarse el nombre del servicio que permite su verificación

o excepciones asociadas

y si fuera necesario se podría indicar el motivo/s de denegación asociados a su incumplimiento.

• Calcular el importe mensual de la prestación

Permite calcular el importe mensual de la prestación para un periodo determinado en base a la información de la solicitud. El cálculo del importe mensual se basará en:

o para el cálculo del importe de la RGI:

– número de miembros de la UC

– capacidad económica de la UC (teniendo en cuenta que el cómputo de los datos económicos variará en función de tipo de dato económico)

– máximos anuales establecidos en función del número de miembros de la UC en el

En el caso de familias monoparentales se añadirá además el importe anual establecido para dicho complemente

o para el cálculo del importe de la PCV:

– número de hijos de la UC

– modalidad de la RGI

– importe del gasto en vivienda

– importe de otras ayudas, prestaciones… de las que los beneficiarios fueran perceptores por ejemplo (renta básica de emancipación)

– máximos anuales establecidos en función del número de hijos de la UC (1, 2 ó más)

Hay que tener en cuenta que la RGI y PCV son prestaciones “diarias” lo que significa que si el periodo asociado al importe obtenido no corresponde a un mes completo el importe a pagar dicho mes se calculará en base a la siguiente fórmula:

(Importe mes calculado/30)xnºdías del periodo

Siempre habrá un importe mensual final que será el importe a pagar a partir de la fecha en la que se realiza el cálculo, pero dentro de un mismo mes.

En el caso de nuevas concesiones los atrasos vendrán determinados por la fecha de efectos de la prestación y la fecha en la que se realiza el primer pago (plazo de resolución). En el caso de modificaciones se tendrá en cuenta además los importes abonados desde la fecha de efectos de la modificación lo que puede dar lugar a un saldo positivo (atrasos) o negativo (cobros indebidos). En caso de que en un mismo periodo de cálculo se produzcan atrasos y cobros indebidos se realizará la compensación entre ellos hasta obtener un importe total que podrá generar un atraso o un cobro indebido,

• Realizar la propuesta de resolución

Gestiona los datos propios de la resolución que introducirá el usuario como parte de la tramitación del expediente y que se volcarán al sGP en la resolución definitiva: tipo de resolución, modalidad prestación, tipo de UC, indicador exenta de convenio y en caso afirmativo motivo de excepción, vigencia de la prestación (la fecha de inicio de vigencia en caso de concesión será al día siguiente de la fecha de entrada, la fecha de renovación será la fecha de inicio de efectos más dos años), importes pago, fecha pago…

Si la tramitación se realizara de forma telemática se pasará la información de la solicitud a este subsistema mediante un proceso de carga automática (dicho proceso dependerá del formato de generación del documento de solicitud telemática).

En lo que respecta a explotación de datos podría resultar de interés una consulta de totales importe por estado (salvo las resueltas) para poder hacer una previsión del importe de la nómina mensual, en cualquier caso las consultas y listados a realizar en este subsistema, así como el diseño de los mismos, se definirán en el ámbito de ejecución de proyecto.

2.5.2. Subsistema de Gestión de Prestaciones

Abarca el ámbito de gestión de los procesos de pago, seguimiento y control de la Prestación.

Las funcionalidades de este subsistema se han agrupado en diferentes módulos en base al proceso al que dan soporte:

2.5.2.1. Prestaciones

El objetivo de este subsistema es gestionar toda la información relativa a las prestaciones de RGI y PCV.

Se carga a partir de la información resultado de la tramitación de los procedimientos en RegexLan (sólo pasarán al sGP los expedientes resueltos). Dicha información se completará con la información del sGS.

Proporciona una visión de la situación actual de la prestación, facilitando además una perspectiva global sobre la misma y engloba las funcionalidades necesarias para el acceso y mantenimiento de los datos que conforman la entidad Prestación.

o Alta prestación

o Baja prestación

o Modificación prestación

o Consulta prestación

o Búsqueda de prestaciones

Dado el volumen de información que gestiona este módulo será necesario establecer los criterios necesarios para no penalizar el rendimiento: limitar el número de registros a mostrar, establecer unos criterios de selección mínimos….

Aunque se incluyen las funcionalidades que permiten el mantenimiento en principio la modificación de los datos de la Prestación debería hacerse únicamente desde la tramitación de expediente, salvo aquellos datos que no tengan impacto en el proceso de gestión como observaciones, cuenta bancaria….Deberán establecerse los mecanismos necesarios para mantener la integridad entre ambos sistemas, el modelo de integración será el mismo que el establecido para el sGS.

Dado el volumen de información a gestionar como parte de la entidad Prestación la información se muestra dividida en diferentes apartados:

o Datos generales. Ofrecen una visión básica del estado de la prestación: f. entrada solicitud, vigencia (f. efectos, f. renovación), fechas de control (próxima revisión, renovación), f. primer pago, datos situación (en caso de que estuviera suspendida o extinguida)

o Datos prestación. Ofrece información sobre los datos específicos de la prestación: titular, indicadores de excepción y datos del pago: importes mensuales y atrasos. El campo atrasos sólo estará informado si en la nómina actual se van a pagar atrasos por cualquier concepto. Se podrá además consultar los distintos importes mensuales de la prestación desde su concesión y el detalle de los atrasos abonados hasta la fecha.

Los indicadores que determinan si se trata de una UC pensionista o en situación de alta exclusión son importantes de cara a la gestión de la prestación puesto que no necesitan suscribir convenios de colaboración y por lo tanto

Las prestaciones con UC pensionistas o en situación de alta exclusión requieren de una gestión y seguimiento mucho más simplificada; no tiene que suscribir convenios, presentan menos documentación, las renovaciones son automáticas….

o Otros datos: incluye información de la cuenta bancaria en la que se abonará la prestación, así como datos de notificación. En principio se ha considerad el pago de la RGI y PCV en una única nómina por lo la prestación sólo tiene asociada una cuenta bancaria.

La información que se gestiona en este apartado no tiene impacto en el proceso de gestión por lo que se podría modificar sin necesidad de establecer ningún tipo de control.

o Datos UC: datos vivienda, fecha de constitución de la UC, tipo de UC, detalle miembros… Junto con la pestaña de datos económicos ofrecen la visión global de la situación de la UC y constituyen la información básica para calcular el importe mensual de la prestación.

Las modificaciones en la situación de la UC implicarán normalmente la modificación, suspensión o extinción de la prestación.

En caso de modificación de los datos de la UC que afectan al importe mensual de la prestación y que no se comunican en el plazo establecido por ley la fecha de efectos de la modificación sería, la del hecho causante en caso de que implique la reducción de importe mensual y la fecha comunicación en caso contrario. El efecto de una modificación de la situación de la UC comunicada en plaza será desde el primer día del mes siguiente al hecho causante.

Se establecen requisitos en cuanto al número máximo de UC que pueden ser perceptoras en una misma vivienda, tanto para la RGI como para la PCV.

Para establecer el tipo de UC es necesario incluir la información de todos los empadronados en la vivienda, posteriormente se determinará si forman o no parte de la UC.

El tipo de UC es un dato que deberá completarse como parte de la tramitación del expediente.

Se integrará con el maestro de ubicaciones.

o Datos económicos de la UC: capacidad económica de la UC.

Ofrece información de los ingresos y patrimonio de la UC. Al ser prestaciones que se otorgan a todos los miembros de la UC se deberán introducir los datos económicos a nivel de miembro pero sólo para los que forman parte de la UC

A la hora de conceder la prestación existen limitaciones en cuanto al importe máximo de ingreso de la UC, sólo se concederá la prestación si no se superan los importes máximos establecidos anualmente en función del número de miembros de la UC y modalidad de la prestación. Se establece también un patrimonio máximo para poder ser beneficiarios.

La información a registrar varía en función del tipo de dato económico y no todos computan de la misma forma, por lo que se necesitará una tabla de parametrización de datos económicos como parte del Catálogo del maestro.

o Datos PCV: importe gasto en vivienda, arrendador…

Ofrece una visión de la información relativa a la PCV, No todos los beneficiarios de la RGI serán beneficiarios de la PCV, pero es requisito indispensable que los beneficiarios de la PCV lo sean también de la RGI (en cualquiera de sus modalidades)

Hay circunstancias que pueden provocar la suspensión de la PCV y que no afecten al pago de la RGI pero no ocurre lo mismo con la RGI. Si se suspende la RGI se suspende la PCV y si se extingue la RGI se extingue la PCV. De cara al modelo de negocio a implantar se propone una gestión conjunta de ambas prestaciones que se permitirá agilizar y simplificar el procedimiento.

Por otro lado el pago de la PCV se deberá justificar semestralmente mediante la presentación de las facturas correspondientes y el titular de la prestación estará obligado a devolver las cantidades que se han abonado de forma indebida.

Por lo tanto desde la pestaña de la PCV podremos acceder a la información de las suspensiones, justificaciones y cobros indebidos asociados a una prestación.

Como en el cado se la RGI el abono de los cobros indebidos podrá ser compensado mensualmente mientras se mantenga la condición de beneficiario. En principio el cobro indebido se realizará también de forma conjunta con los cobros indebidos de la RGI.

o Suspensiones: periodos en los que la prestación ha estado suspendida

A lo largo del ciclo de vida de la prestación puede haber circunstancias que impliquen la suspensión del derecho durante un periodo, por ejemplo, en caso de trabajos temporales.

Existen dos tipos de suspensiones:

• Cautelares: cuando se tiene indicios de que una situación que puede provocar la pérdida de alguno de los requisitos exigidos para el reconocimiento y el mantenimiento de la prestación.

Una suspensión cautelar puede reanudarse con efecto desde el mismo día de la suspensión.

La suspensiones cautelares se podrán iniciar de oficio.

• Temporales: cuando se produce la pérdida temporal de alguno de los requisitos exigidos para su reconocimiento.

El periodo de suspensión de una prestación no podrá ser nunca superior a 18 meses consecutivos. Si previo a una suspensión temporal se hubiera realizado la suspensión cautelar del pago este periodo de tiempo también se tiene en cuenta a la hora de contabiliza dicho plazo..

o Renovaciones: relación de renovaciones de la prestación

La ley establece una renovación bienal de la prestación cada

o Pagos: relación de pagos mensuales de la prestación indicando por cada uno de ellos año, mes, perceptor, cuenta bancaria, importe, si ha sido devuelto pro el banco….

Esta información será únicamente de consulta, ya que se genera como parte del proceso de gestión de la prestación.

o Resoluciones: información de las resoluciones asociadas a la prestación, ofrece una visión completa de la prestación (negocio + tramitación). Desde cada resolución se podrá ver la información de la solicitud en base a la cual se hizo la resolución.

Esta información será únicamente de consulta, ya que se genera como parte del proceso de gestión de la prestación.

o Cobros Indebidos

Una de las obligaciones de los beneficiarios de la RGI es la devolución de las cantidades que han cobrado de forma indebida si, como consecuencia de un procedimiento de modificación, suspensión o extinción, o por cualquier otra circunstancia, se comprobara la percepción indebida de la prestación.

La normativa establece además la posibilidad de que el cobro indebido se compense con la nómina de la RGI (si se mantiene la condición de beneficiario) por lo que será necesario disponer de una funcionalidad que permita la gestión de estos cobros indebidos y los procesos derivados de la compensación, en los caso que sea necesario.

El proceso de nómina deberá tener en cuenta los cobros indebidos que serán descontados del importe a pagar

o Observaciones

Permite incluir información adicional sobre la prestación.

Se valorará la necesidad de generar observaciones automáticas ante determinados eventos, por ejemplo, un cambio de titular…

En el ámbito de ejecución del proyecto se deberá analizar además:

o El sistema de logs que se quiere establecer y el mecanismo de explotación del mismo.

Puede ser tan sencillo como mantener la fecha y nombre del usuario que ha realizado la última modificación y que dicha información se visualice en todas las páginas o una gestión mucho más compleja que almacene toda la información modificada y permita consultar los datos concretos objeto de modificación, usuario y fecha en la que se modificaron)

o Identificar necesidades de información histórica (por ejemplo puede ser interesante conocer los distintos titulares que ha tenido una prestación y su vigencia pero no las modificaciones de cuentas bancarias).

2.5.2.2. Nómina

En este módulo se incluyen las funcionalidades relacionadas con el pago de la prestación. En principio se plantea una única nómina en la que se pague de forma conjunta la prestación de RGI, más el complemento de familia monoparental si fuera e caso, y la PCV:

o Cierre de nómina

El objetivo de esta funcionalidad es el cierre de la nómina mensual previo a su lanzamiento. A partir del cierre de la nómina las nuevas resoluciones tendrán efectos de pago (nuevas concesiones, atrasos…) en la nómina del mes siguiente.

En el caso de la RGI y PCV al ser prestaciones de carácter subsidiario, no se considera una funcionalidad crítica puesto que el pago está asegurado y no hay limitaciones en la partida asignada.

o Inicio nómina

La información para generar el pago de la nómina se obtiene del sGP y aplica tanto a las prestaciones que no han sufrido variación en su situación (desde la nómina anterior), como a las nuevas concesiones y resoluciones provisionales derivadas de una solicitud de modificación (suspensiones, extinciones, modificaciones…)

Si se ha optado por un proceso de resolución mensual (decisión a tomar como parte del modelo de gestión a implantar) el sGP deberá notificar a RegexLan el inicio del proceso de nómina. Las resoluciones provisionales pasarán a definitivas y se volcará la información correspondiente a dichos expedientes en el sGP.

o Previo de nómina

El objetivo de esta funcionalidad es obtener información sobre el pago que se va a realizar, principalmente en lo que se refiere a importe y número de nuevas concesiones.

Como parte de la ejecución del proyecto se definirá la información que se quiere obtener en este ámbito, así como el medio (pantalla, listado) y formato de salida.

No realiza la integración con el Sistema de Pagos.

o Nómina

El objetivo de esta funcionalidad es realizar el pago mensual de las prestaciones, para lo cual deberá integrase con el Sistema de Pagos de LANBIDE.

El SGP deberá proporcional al sistema de Pagos toda la información necesaria para procesar el pago. Se generará un registro de pago por cada prestación activa (no extinguida, no suspendida) con la siguiente información: perceptor del pago,datos bancarios e importe. El desglose del importe a pagar vendrá determinado por los requerimientos del Sistema de Pagos (un único importe, desglose por prestación, desglose por prestación y atrasos…)

Puede ser que para la generación de la cinta al banco sea suficiente con un importe total pero se necesite mayor nivel de detalle de cara a su contabilización en el sistema económico financiero

El proceso de nómina deberá tener en cuenta, además, las posibles compensaciones de cobros indebidos que deberán ser descontadas del importe mensual

Como parte de la nomina se obtiene,además, la información del pago a realizar, que coincidirá con la explotación definida para el previo de la nómina.

En el ámbito de ejecución del proyecto se especificarán las necesidades, requisitos y funcionalidades derivadas de esta integración.

Dada la criticidad de este proceso será necesario definir también los mecanismos que permitan la anulación del pago (mientras se posible)

o Gestión de impagados

El objetivo de esta funcionalidad es registrar en el sistema las devoluciones enviadas por el banco derivadas de pagos que no se han podido realizar por no ser correcto el número de cuenta. Estas devoluciones se abonarán como atrasos en la nómina del mes siguiente.

Se marcará el pago como no realizado y se generará un atraso por impago.

En el ámbito de ejecución del proyecto se analizará el sistema de comicación con el banco y el tratamiento a realizar para procesar la información.

2.5.2.3. Procesos

En este módulos se incluyen los procesos de tratamiento masivo de información:

o Regularización económica anual. El proceso de regularización económica anual tendrá carácter retroactivo y en principio incluirá la notificación a los titulares de la prestación del nuevo importe mensual. Previo a la ejecución del proceso será necesario establecer los importes máximos anuales. Como parte del cálculo se volverá a calcular la capacidad económica de la UC en aquellos casos en que incluya datos económicos que se revalorizan anualmente (por ejemplo otras prestaciones que procedan de las administraciones como puede ser la PNC…) actualizándose los nuevos importes

o Procesos de renovación automática de la prestación en los supuestos que indica la Ley (titulares de la Renta Básica para la Inclusión y la Protección Social formadas exclusivamente por pensionistas que no se encuentren en edad de trabajar o que, estándolo, presenten una incapacidad permanente absoluta y personas en situación de alta exclusión que no se encuentren en situación de incorporarse al mercado laboral.

o Procesos para detectar extinciones automáticas en alguno de los supuestos establecidos en la ley (superar el periodo máximo de suspensión (18 meses), no presentar renovación, superar el periodo máximo para mantener la situación de matrimonio o relación permanente análoga, en caso de situaciones de violencia de género, ..)

En el ámbito de la ejecución del proyecto se especificarán los procesos a realizar y el método de integración con el Gestor de Expedientes, en caso de que impliquen inicio de tramitaciones de forma automática.

2.5.2.4. Seguimiento y Control

En este módulo se incluyen las funcionalidades necesarias para realizar el seguimiento y control de la prestación:

Una vez concedida, la información del expediente (tramitación + solicitud) se vuelca en el SGP y a partir de este momento se deberá establecer un plan de seguimiento y control que permita:

o Asegurar el cumplimiento de las obligaciones que establece la normativa y que pueden dan lugar a la suspensión e incluso extinción de la prestación en caso de incumplimiento.

o Analizar los resultados en lo que se refiere a la activación laboral de los beneficiarios de RGI.

Como parte del proceso de seguimiento y control de la prestación la Ley establece:

o Una revisión anual

La ley prevé una revisión anual que se iniciará de oficio con la comunicación al titular de la prestación del plazo en el que se efectuará la revisión.

o La renovación de la prestación con carácter bienal.

El proceso de renovación se iniciará con la comunicación al titular de la prestación, tres meses antes del vencimiento de plazo, la necesidad de iniciar la tramitación de su solicitud para su renovación.

o La obligación por parte de los titulares de comunicar cualquier modificación respecto a la situación de la UC que pudiera dar lugar a la modificación, suspensión o extinción del derecho a la prestación.

Para verificar el cumplimiento de requisitos y obligaciones de los beneficiarios de forma automática será necesario analizar las posibilidades de interrelación con los sistemas

propietarios de la información a validar como pueden ser: otros sistemas de LANBIDE, Seguridad Social, Ministerio de AAPP, Ayuntamientos, Gobierno Vasco, Diputaciones, dicha información hace referencia principalmente a datos de empadronamiento, capacidad económica de la UC, cumplimiento obligaciones derivadas del convenio de inclusión y plan personal de inserción, que en muchos caso pueden conllevar la necesidad de establecer un convenio de colaboración , desarrollo de nuevos servicios…

La integración con estos sistemas externos se realizará en dos puntos del proceso de gestión:

o como parte del proceso de registro e instrucción de la solicitud lo que permitirá: agilizar la introducción de datos de la solicitud, mediante la carga automática de información y simplificar la verificación de requisitos de concesión (la verificación es automática)

o como parte del módulo de seguimiento y control

La comprobación podrá realizarse en cualquier momento, de forma manual, pero deberá definirse un proceso planificado que se ejecute previo a la nómina que permita y evite en la medida de la posible la generación de cobros indebidos.

En el ámbito de ejecución del proyecto se analizarán las necesidades de integración con otros sistemas, así como los mecanismos para llevarlas a cabo.

2.5.2.5. Consultas y Listados

En este módulo se incluyen funcionalidades relativas a la explotación de los datos recogidos en el sistema, bien sea en pantalla o en formato impreso.

Las consultas, listados y diseño de los formatos correspondientes se definirán como parte del ámbito de ejecución del proyecto.

2.5.2.6. Catálogo de Maestros

Módulo específico de administración, que permitirá mantener toda la información del catálogo de maestros (entidades: código, descripción (castellano, euskera), y parametrización (tipos de datos económicos, requisitos…) necesaria para su funcionamiento.

Además como parte de este módulo se incluirá, el Maestro de Ubicaciones. Dada la relevancia que tiene la vivienda en el proceso de gestión de la RGI (se establecen limitaciones respecto al número máximo de prestaciones a conceder en una misma vivienda, tanto para la RGI como para la PCV), se considera necesario definir una entidad donde se registren todas las viviendas asociadas a una prestación de RGI con un identificativo único. La entidad ubicación además de los datos propios de la dirección deberá incluir, como mínimo, los siguientes datos:

o Indicador de vivienda colectiva

o Número de habitaciones (por lo menos en el caso de viviendas colectivas)

Aunque en la solución propuesta se incluye una relación de los maestros del sistema y necesidades de parametrización, en la fase de análisis se definirá la relación definitiva.

2.5.2.7. Atención usuarios

En este módulo se incluyen las funcionalidades necesarias para:

o Gestión de citas

Aunque uno de los principales objetivos del nuevo sistema es evitar la sobreprotección que existía en el sistema actual, en lo que respecta al registro de la solicitud, existen determinados colectivos que por su grado de analfabetismo o circunstancias

excepcionales de su situación requieren de ayuda personalizada para completar la solicitud

En cuanto al servicio de orientación: se establecen entrevistas personales con los beneficiarios de la prestación de cara a elaborar los convenios de inclusión y planes personales de inserción

Definir un sistema de gestión de citas permitirá conocer y balancear la carga de trabajo entre los distintos profesionales de LANBIDE.

o Gestión de sugerencias y quejas

El objetivo de esta funcionalidad será disponer de un mecanismo que permita evaluar la satisfacción de los solicitantes de RGI y PCV con el nuevo sistema.

No son funcionalidades que forman parte del proceso de gestión pero si pueden considerarse un complemento adicional que aporta valor añadido al sistema.

2.5.3. Subsistema BI del servicio de prestaciones de RGI y PCV

El objetivo de este subsistema es proporcionar una herramienta de gestión de la información y análisis de datos que agilice el estudio de la información relativa al servicio de RGI y PCV, facilitando y optimizando la toma de decisiones.

Aunque las necesidades y requisitos de este subsistema se analizarán en detalle en ámbito del proyecto como propuesta inicial de la arquitectura tecnológica en la que se basará el sistema se establece:

• El Sistema de Business Intelligence propuesto está alineado con la arquitectura técnica definida por LANBIDE y seguirá las pautas definidas para el BI desarrollado para el Sistema de Intermediación.

• Básicamente una arquitectura básica de BI comprende los siguientes elementos:

o Sistemas operativos en Servidores.

o Clientes de las Herramientas BI (diseño del repositorio de metadatos a explotar).

o Base de datos: Oracle (Gestor actual del Cliente)

o Herramientas BI de explotación del Data Warehouse y Cuadros de Mando. (Oracle Business Intelligence 11g)

o Herramienta ETL: Se Utilizará la herramienta de Oracle : Oracle Data Integration (ODI)

• Como plataforma del BI se propone la siguiente, similar a la implantada para el Sistema BI de Intermediación.

2.5.4. Subsistema Infraestructura de Soporte y Negocio de Procesos SOA para RGI y PCV

Se pretende que la arquitectura a construir para la gestión de servicios a proporcionar por LANBIDE proporcione servicios de infraestructura SOA independientes de los sistemas de información específicos, facilitando a los desarrolladores de sistemas la creación, publicación, acceso seguro y monitorizado de servicios, principalmente “servicios web”.

Se contemplan los siguientes tipos de interacciones principales entre aplicaciones:

• Síncronas: en las que la aplicación consumidora del servicio se bloquea hasta que la aplicación proveedora devuelve una respuesta. Este tipo de interacciones se implementa con “servicios web” conforme a los estándares reconocidos XML, SOAP y WSDL.

• Asíncronas: en las que las aplicaciones consumidoras y proveedoras de los servicios no se bloquean, basándose el intercambio de mensajes entre aplicaciones. Este tipo de interacciones se desarrolla mediante el uso de mensajería sobre el estándar JMS (Java Messaging System).

• Procesos: adicionalmente a la provisión de servicios para su consumo por parte de los sistemas clientes mediante el uso de estándares, será necesaria la provisión de servicios complejos compuestos de varios servicios simples con una lógica determinada entre ellos. Estos servicios complejos son los que implementarán la lógica de negocio de los procesos de integración existentes en la organización.

2.5.4.1. Desarrollo de nuevos “servicios web” mediante Oracle Service Bus

Se deberán realizar los desarrollos necesarios para la provisión de servicios, usando estándares de mercado, entre sistemas consumidores y sistemas proveedores de funcionalidad atómica. Como alcance de los desarrollos a realizar sobre Oracle Service Bus se deberá cubrir los procesos e integraciones planteadas en la funcionalidad descrita en el presente pliego técnico de condiciones.

Como sistemas a integrar se detallan los siguientes:

• Servicios Comunes:

o Plataforma de Firma Electrónica

o Pasarela de Pagos

o Plataforma de Notificaciones

o Plataforma de Digitalización

o Plataforma de Envío de SMS

o Sistema de Gestión de Persona Física

o Gestor Documental

o Generador de Documentos

o Sistema de Autenticación/Autorización

• Sistema Económico – Financiero

o Sistema de Gestión Presupuestaria

o Sistema de Gestión Económica de Subvenciones

o Tesorería

o Plataforma de Pagos

• Plataforma de Tramitación de Expedientes

o Portafirmas

o Registro Telemático

o Gestor de Expedientes (RegexLan)

• Sistema de Intermediación, Formación, Orientación

o Sistema de Gestión de la Oferta

o Servicios de Empleo actuales

• Sistema de Gestión, Seguimiento y Control de RGI y PCV

• Sistemas Externos: Será necesario identificar la conexión con entidades externas a LANBIDE como Gobierno Vasco, Seguridad Social, Ayuntamientos, Diputaciones con

el fin de establecer servicios de interoperabilidad que redunden en una simplificación de la documentación a portada por el ciudadano de acuerdo a la ley 11/2007 , así como un fortalecimiento de los sistemas de control.

En cuanto al alcance de integraciones habrá que ceñirse a lo especificado en la descripción técnica del presente pliego. En cualquier caso, deberá ser cubierta cualquier integración necesaria que sea detectada en el análisis funcional del proyecto.

Los desarrollos deberán habilitar los servicios proporcionados por los sistemas proveedores para que puedan ser accedidos por los sistemas consumidores teniendo en cuenta los criterios referentes a:

• Uso de mecanismos estándares

• Securización de los servicios mediante el uso de políticas WS-*. Aplicación de políticas de cifrado, firma digital, no repudio, control de acceso, autenticación y autorización cuando se considere oportuno. Hacer hincapié en este punto sobre todo en el caso de los servicios con sistemas externos.

• Composición de servicios simples en otros complejos pero que igualmente puedan ser accedidos por medios estándares.

• Registro y clasificación de los servicios para facilidad en su inventariado, localización y reaprovechamiento de los mismos, de cara a evitar la duplicidad de esfuerzos entre equipos de trabajo.

Hay que tener en cuenta que se considera alcance del presente pliego todas las fases del ciclo de vida software aplicables a un nuevo sistema:

• Toma de Requerimientos

• Análisis y Diseño

• Implementación

• Pruebas unitarias/integración/aceptación

• Despliegue

• Mantenimiento

2.5.4.2. Desarrollo y Adaptación de Servicios de Registro

Los Servicios de Registro deben permitir la publicación de “servicios web”, cumpliendo los requisitos siguientes:

• Diseño, adaptación e implantación de la infraestructura software del Registro de Servicios en conformidad con el estándar UDDI en sus últimas versiones.

• Desarrollo y adaptación de taxonomías que permitan la clasificación flexible de los servicios publicados.

• Desarrollo y establecimiento de políticas que permitan la publicación y modificación de servicios, cubriendo su ciclo de vida desde su concepción hasta la retirada.

• Desarrollo y adaptación de servicios de suscripción y notificación.

2.5.4.3. Desarrollo y Adaptación de Servicios de Seguridad y Monitorización de “Servicios Web”

Diseño, adaptación e implantación de la infraestructura software de Seguridad y Monitorización de “servicios web” en conformidad con los estándares del mercado en sus últimas versiones.

Desarrollo y adaptación de políticas de seguridad aplicables a los “servicios web” publicados, garantizando los siguientes aspectos:

• Autorización del consumo de un “servicio web” sólo por parte de las partes interesadas.

• Autenticación extremo a extremo del proveedor y consumidor del “servicio web”.

• Integridad y Confidencialidad extremo a extremo de la información transmitida durante la invocación de un “servicio web”.

• No repudio, cuando se solicite este servicio. Permiten a consumidor y proveedor del servicio tener garantía de que la invocación del servicio se ha producido.

Desarrollo y adaptación de Servicios de Monitorización de “servicios web” desplegados en la intranet, garantizando los siguientes aspectos:

• Contabilidad de la disponibilidad de los “servicios web” en explotación.

• Auditoría del consumo de “servicios web”, facilitando las consultas por diversos criterios como por ejemplo: sistema consumidor, tipo de servicios, sistema proveedor, dominio de red, etc.

• Intermediación de “servicios web” para garantizar parámetros de disponibilidad de servicio previamente establecidos (como por ejemplo número máximo de invocaciones por periodo, máximo de invocaciones simultáneas, etc.)

Las políticas de seguridad sobre servicios se deberán aplicar en función de las necesidades planteadas sobre los mismos por el área de seguridad. Hay que destacar que sobre todo se deberán aplicar políticas de cifrado sobre los servicios sobre entidades externas.

2.5.5. Subsistema de Explotación de la información del servicio de RGI y PCV para entidades externas

El objetivo de este subsistema es el intercambio de información relativa al servicio de RGI y PCV con Ayuntamientos, Diputaciones, Gobierno Vasco y otras entidades, organismos y Administraciones.

Las necesidades, requisitos y funcionalidades de este subsistema se analizarán en el ámbito de ejecución del proyecto

Esta funcionalidad podría limitarse al envío de una serie de listados (o publicación de los mismos en la web de LANBIDE) o considerar a estos terceros como usuarios del sistema, en cuyo caso habría que establecer diferentes perfiles, restricciones de acceso a funcionalidades y datos…

2.6. Modelo de seguridad

La seguridad de la información debe estar concebida como un servicio de soporte al negocio que tiene como fin la protección de la información y de los sistemas de la información del acceso, uso, divulgación, interrupción o destrucción no autorizada.

Como tal servicio la seguridad de la información debe ser objeto de la oportuna gestión que garantice, de forma continua, que se establezcan los controles y medidas para proteger los activos del proceso de Gestión de la RGI/PCV, y que se revisen y mejoren dichos controles y medidas, para dar respuesta oportuna y proactivamente a las amenazas que vayan surgiendo, a los cambios regulatorios, o a las modificaciones en los objetivos de seguridad. Por ello la seguridad debe contemplarse desde la implantación de diversos procesos de carácter estratégico, operativo y de control. Entre ellos los principales son:

• Políticas de Seguridad: Definición, Planificación y Desarrollo de las directrices de actuación necesarias para proporcionar un nivel de seguridad adecuado sobre los

servicios y procesos de la RGI/PCV que son soportados en el sistema de información definido en este pliego.

• Arquitectura de seguridad: Se constituye en el referente táctico que, tomando como base la evaluación de los riesgos del negocio, describe:

o La normativa de seguridad.

o La estructura organizativa de seguridad y los roles/ responsabilidades que las personas deben adoptar en el marco de los procesos de la seguridad de la información.

o La infraestructura tecnológica de seguridad requerida para controlar el registro, el tratamiento, el proceso de almacenamiento y el flujo de la información de forma segura.

o Planificación para la continuidad del negocio: Gestión de Continuidad de los servicios TI que dan soporte a las actividades de la RGI/PCV, asegurándose de que las facilidades técnicas y de servicio se pueden recuperar dentro de los márgenes de tiempo requeridos y acordados.

o Gestión de eventos: con el fin de gestionar el servicio de respuesta ante incidentes de seguridad.

o Securización de sistemas: con el fin de alcanzar el fortalecimiento técnico de los servicios para prevenir los incidentes relacionados con debilidades conocidas, y la ocurrencia de incidentes que exploten dichas debilidades.

o Análisis de Riesgos: identificar los riesgos de seguridad que podrían impedir área de RGI de LANBIDE lograr sus objetivos, determinando su magnitud e identificando las áreas que requieren medidas de salvaguarda o controles para minimizar dicho riesgo.

2.7. Descripción y condiciones de realización del servicio 2.7.1. Descripción de los trabajos a realizar: 1. - Octubre 2011- Nuevo Sistema de Información de Sistema Propio para LANBIDE.

En esta fecha el nuevo sistema debe estar preparado para comenzar a funcionar desde las oficinas como un Sistema Propio de LANBIDE. El objetivo es implantar en el 2011 una versión básica del sistema que permita su posterior escalabilidad aumentando paulatinamente las funcionalidades y módulos hasta lograr el sistema global descrito en el pliego en Diciembre del 2012. A continuación detallamos las tareas más importantes que habrá que llevar a cabo para alcanzar este hito:

1. Implantar en LANBIDE un sistema de información para la Gestión de la Renta de Garantía de Ingreso que incorpore las funcionalidades mínimas para su gestión y que pueda ser ampliado paulatinamente con el fin de lograr cubrir todos los requisitos indicados en el pliego. El nuevo sistema informático de RGI/PCV del País Vasco deberá incorporar los datos migrados de las diputaciones para que LANBIDE pueda asumir la gestión completa de todos los expedientes en curso, así como las nuevas funcionalidades definidas por LANBIDE. Se deberán desarrollar, así mismo, todos aquellos mecanismos necesarios para asegurar la sincronización de los datos entre la aplicación RGI y el resto de servicios de LANBIDE.

2. Desarrollar los servicios necesarios en el BUS para lograr integrar el nuevo sistema de gestión RGI/PCV de LANBIDE con aplicaciones externas e internas.

3. Definir e implantar un Generador de Documentos integrado con el Sistema de Gestión Documental garantizando la gestión, almacenamiento y conservación de los

documentos en formato electrónico que puedan generarse o recibirse por parte de la administración en relación con la RGI.

4. Definir e implantar una plataforma de firma y una plataforma de notificaciones corporativa. Utilizar la plataforma de mensajes SMSs.

5. Construir un Cuadro de Mando segmentando la información por distintos criterios (geográficos, funcionales, edad, sexo,…..), que recoja indicadores desde las distintas perspectivas lo que facilitará la mejora de la gestión y la toma de decisiones.

6. Definir e implantar un Modelo de Gestión de la Seguridad de la información, el alcance central son los procesos de seguridad aplicados a los procedimientos RGI/PCV.

7. Implantar una plataforma de interoperabilidad en LANBIDE con otras administraciones para facilitar el intercambio de datos.

8. Gestionar la gestión del cambio con el personal de las oficinas de LANBIDE acelerando la asimilación del sistema por parte del personal RGI.

9. Apoyar el despliegue de la solución en sus diferentes versiones incrementales con un equipo de cinco profesionales que apoyen el despliegue de la solución dando soporte a los usuarios durante los distintos pasos a producción de la solución.

2. - (Diciembre 2012)- Sistema de Información RGI/PCV de Sistema Propio para el Servicio Vasco de Empleo modernizado tanto funcional como tecnológicamente.

Durante los años 2011 y 2012 hasta la fecha de fin del proyecto, se llevarán a cabo tareas de mantenimiento correctivo, evolutivo y perfectivo de la nueva aplicación. El mantenimiento correctivo deberá entenderse como la aplicación de la garantía del sistema desarrollado e implantado, por lo que su costo deberá estar asumido en la parte correspondiente al punto anterior. El mantenimiento evolutivo se entenderá como la revisión continuada del nuevo sistema para identificar y mejorar sus funcionalidades. El mantenimiento perfectivo se entenderá como la revisión continuada de las distintas capas de la arquitectura del nuevo servicio para identificar e implantar mejoras en la misma. También entrará dentro de las tareas del proyecto los mantenimientos necesarios para adaptar la aplicación a nuevas versiones de los productos que se usen en la misma.

Al mismo tiempo se llevarán a cabo posibles trabajos pendientes que fuese necesario aplazar a lo largo del año 2012, debido a la incorporación de los acuerdos con otras entidades. Cada una de las nuevas funcionalidades que se incorporen deberá conllevar, de forma obligatoria, la actualización de la documentación de Análisis de Requisitos, Análisis Funcional, Diseño Técnico, Manual de Usuario y Manual de Explotación, así como otra documentación que LANBIDE estime necesaria. A continuación detallamos las tareas más importantes que se deberán llevar a cabo en este periodo:

1. Incorporación al sistema de nuevos requerimientos definidos por LANBIDE.

La empresa adjudicataria estará en la obligación de desarrollar y ejecutar las tareas encomendadas por LANBIDE.

Los plazos de entrega serán fijados por la adjudicataria según las previsiones de carga de trabajo encomendada por LANBIDE. La fecha de entrega será menor que el plazo máximo admisible.

Los plazos máximos serán fijados por LANBIDE dependiendo de la carga de trabajo encomendada, las previsiones estratégicas, la coordinación con otros desarrollos y la prioridad de desarrollo.

A lo largo de la ejecución de las tareas el tiempo de ejecución podrá alterarse por parte de LANBIDE, priorizando el desarrollo de algunas tareas frente a otras. En el caso de que el nuevo plazo no pudiese cumplirse por parte de la adjudicataria, esta informará de los motivos y causas, que serán analizadas en un Comité de Seguimiento.

2. Depuración de errores y mantenimiento correctivo

Será objeto de este proyecto la depuración y corrección de todos los errores que pudiese tener el sistema de gestión.

Así mismo la adjudicataria deberá indicar a la administración aquellos errores que se deban a un mal funcionamiento de la aplicación, para que se notifique el problema a los responsables del sistema, y para decidir las medidas provisionales necesarias a poner en marcha mientras la corrección del problema no se lleve a cabo.

3. Desarrollo de los cambios necesarios para adaptar la aplicación a nuevos

requerimientos de arquitectura

Entre las tareas a llevar a cabo en este proyecto estará la realización de las tareas pertinentes para la adecuación de las nuevas versiones de software base.

Dentro del proyecto también cabría la migración de la aplicación a una nueva arquitectura software, bien de todo el sistema o de parte de él, como puede ser la capa cliente, la de persistencia, etc., siempre que LANBIDE lo requiera, bien sea por motivos de rendimiento o por cualquier otro motivo.

4. Desarrollo de mejoras rendimiento en la aplicación en las tareas más críticas y

herramienta de monitorización.

Se deberá hacer una revisión continuada del sistema de gestión que permita identificar puntos de mejora de rendimiento en todas las capas de la arquitectura, priorizando siempre la incorporación de mejoras en aquellas funcionalidades más críticas, obedeciendo a criterios de uso y relevancia dentro del sistema.

5. Temas que quedasen pendientes del año 2012

Durante este periodo será necesario llevar a cabo todos los temas que pudiesen haber quedado pendientes del periodo que termina con el primer hito del proyecto como podría ocurrir con:

- Funcionalidades de integración a través de servicios del BUS que por su menor relevancia se hubiese decidido que no entrasen en funcionamiento en la fase inicial del sistema.

- Creación de procesos automáticos que no fuera imprescindible incorporarlos en la primera fase.

- Interfaces con otras aplicaciones de LANBIDE que pudiesen haber quedado sin migrar al nuevo módulo de Interfaces con Otras Aplicaciones de la aplicación.

Esta tarea implica que en la oferta deberá presentarse una priorización de los desarrollos a realizar en la primera parte del contrato, la que finaliza en Octubre del 2011, identificando cuáles de ellos sería posible retrasar sin que ello afecte a la operatividad del sistema de información.

2.7.2. Requisitos del equipo de trabajo El equipo de trabajo propuesto deberá estar compuesto por un director de proyecto y un equipo de técnicos que dispongan de los perfiles y conocimientos necesarios para desarrollar el conjunto de tareas descritas anteriormente.

Concretamente, deberán aportarse perfiles de Jefe de proyecto, Consultor tecnológico (Arquitecto J2EE), Consultores de negocio y de seguridad, Analistas funcionales y Analistas/Programadores con conocimientos y experiencia suficiente en desarrollo de aplicaciones java sobre arquitecturas J2EE. A continuación, se detallan los requisitos necesarios para los perfiles anteriormente solicitados:

Perfil Conocimientos Requeridos

Director de Proyecto

• Experiencia en la gestión de proyectos y en el ámbito de las Administraciones Públicas.

• Experiencia como responsable de proyectos en ámbitos relacionados con la gestión de expedientes y administración electrónica.

• Certificado de Gestor de Proyectos (PMP) por el Instituto PMI u otra entidad similar,

Jefe de Proyecto

• Experiencia en la realización de proyectos en el ámbito de las Administraciones Públicas.

• Experiencia como responsable de proyectos en ámbitos relacionados con la gestión de expedientes y administración electrónica.

• Certificado de Gestor de Proyectos (PMP) por el Instituto PMI u otra entidad similar

Consultor Experto en Prestaciones

• Experiencia en el ámbito de Acción Social • Conocimientos en automatización de expedientes administrativos • Experiencia en proyectos J2EE

Consultor tecnológico

• Experiencia como consultor tecnológico en proyectos SOA y arquitecturas J2EE.

• Conocimientos en diseño de arquitectura J2EE. • Conocimientos en programación J2EE, JSF, EJB3, Hibernate, JBOSS

Seam Framework y Spring Framework. • Conocimientos de modelado y administración avanzada de Base de

Datos Oracle y SQLServer. • Conocimientos en servidores de aplicaciones J2EE Weblogic 11G. • Experiencia en el uso y administración de herramientas de integración

continua y gestión de configuración: Maven, Hudson, CVS, Eclipse. • Conocimientos en metodologías ágiles: Scrum.

Consultor de negocio

• Experiencia como experto de negocio en ámbitos relacionados con la gestión de las administraciones públicas.

• Experiencia en proyectos de Administración electrónica • Conocimientos en metodología Métrica v3

Consultor de Seguridad

• Experiencia como experto de seguridad en proyectos de desarrollo para aplicaciones informáticas con datos de nivel alto a nivel de LOPD.

• Marcos organizativos y procesos de seguridad • Soporte técnico (experto externo) a comités de seguridad en diversas

organizaciones. • Experiencia en proyectos de implantación del ENS y planes de

aplicabilidad

Consultor BI

• Experiencia como experto de BI en proyectos de desarrollo para las administraciones públicas.

• Conocimientos de plataformas Gestión del Rendimiento (Reporting, Análisis, Planificación y Simulación y Estrategia mediante Cuadros de Mando y metodología Balanced Scorecard)

• Conocimientos específicos en ORACLE OBIEE 11G. • Participación en proyectos de políticas de empleo y servicio de

intermediación • Conocimientos en implantación de BI mediante metodología SCRUM

(agile BI)

Perfil Conocimientos Requeridos

Analista funcional

• Experiencia como analista funcional de aplicaciones Java sobre arquitecturas J2EE.

• Conocimientos en diseño UML y modelado de datos. • Conocimiento en modelado de procedimientos y migraciones de datos. • Conocimientos en análisis y desarrollo de procedimientos de extracción

y carga de datos en DWH. • Conocimientos en metodología Métrica v3

Analista/Programador

• Experiencia como analista/programador de aplicaciones java sobre arquitecturas J2EE.

• Conocimientos en programación J2EE, JSF, EJB, Web Services, Hibernate, XML, XSLT, XHTML y Javascript.

• Conocimientos de programación en PL/SQL • Conocimientos en servidores de aplicaciones J2EE. • Conocimientos y experiencia en uso de herramientas de desarrollo

Eclipse, CVS, Ant, Maven. • Conocimientos en servidores de aplicaciones J2EE. • Conocimientos en metodología Métrica v3.

2.7.3. Volumen mínimo de horas de dedicación dentro del pliego El volumen mínimo de recursos a contratar en función de los perfiles anteriormente descritos será de 90.300 horas repartidas según la tabla que se presenta a continuación:

Concepto Perfil Jornadas Horas

Servicios

Director 150,00 1.200,00

Jefe de Proyecto 275,00 2.200,00

Consultor 3.300,00 26.400,00

Analista Funcional 2.612,50 20.900,00

Analista Programador 4.950,00 39.600,00

Total jornadas 11.287,50 Total Horas 90.300,00

Si la empresa licitadora propone una solución basada total o parcialmente en un producto comercial tendrá que especificar en la oferta técnica cuál es el volumen de horas equivalente al montante de licencias de producto que aporta, de forma que el número de recursos mínimo solicitado en el párrafo anterior podría ser minorado en dicha cantidad sin perjuicio para el cumplimiento de los requisitos solicitados en este apartado. En este supuesto, será requisito obligatorio presentar una valoración económica del coste del mantenimiento de licencias del producto comercial sustitutivo de los recursos a contratar para los años 2013 y 2014. Dicha valoración de coste se incorporará como criterio evaluable dentro del apartado de Valor técnico y organizativo de la solución propuesta.