Pliego de bases técnicas: sistema de RRHH del Gobierno ... · Por otra parte, la Viceconsejería de Función Pública se halla inmersa en un proceso de reorganización y renovación

SCR6150c Versión 2.0(12/01/05)

Pliego de bases técnicas:

Implantación, mantenimiento y evolución de algunos módulos sistema de RRHH del Gobierno Vasco sobre la plataforma SAP

Fecha: Septiembre de 2013 Referencia: 025/2013

EJIE S.A.

Mediterráneo, 14

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

http://www.ejie.es/

Pliego de Bases Técnicas

Contenido

Capítulo/sección Página

1 Introducción 5

2 Objeto del contrato 7

2.1 Objeto 7

2.2 Áreas Funcionales 7

2.2.1. Lote 1 8

2.2.2. Lote 2 10

2.2.3. Lote 3 12

2.3 Líneas de trabajo 18

2.4 Flujos de mantenimiento 20

2.4.1. Peticiones de servicio 21

2.4.2. Entregas 21

3 Configuración del Servicio 22

3.1 Organización del Equipo de Trabajo 22

3.2 Asignación de recursos 22

3.3 Equipo de Trabajo 22

3.3.1. Certificaciones en SAP y nivel de conocimientos 23

3.3.2. Veracidad de los datos 24

3.3.3. Condicionante del equipo de trabajo ofertado 24

3.3.4. Constitución inicial del equipo de trabajo 24

3.3.5. Modificaciones en la composición del equipo de trabajo 24


3.3.6. Jornada laboral y lugar de realización de los trabajos. 25

3.3.7. Currículo de los componentes del grupo de trabajo. 26

4 Especificaciones Técnicas 27

4.1 Metodología de desarrollo, normativa y Guía de Estilo 27

4.2 Entorno Tecnológico 27

4.3 Modelo de aseguramiento de la calidad 29

4.3.1. Construcción del sistema 29

4.3.2. Controles de calidad (SQA) 30

4.3.3. Tipologías de pruebas 30

4.3.4. Metodología de pruebas 31

4.3.5. Indicadores 31

4.3.6. Rendimiento 31

4.4 Herramientas del ciclo de vida de las aplicaciones 33

5 Control y Seguimiento 34

6 Condiciones particulares 35

6.1 Hitos y duración del servicio 35

6.2 Presupuesto y Modelo de facturación 35

6.3 Penalizaciones 36

6.4 Criterios de valoración 36

7 Garantía y Confidencialidad 38

7.1 Garantía 38

7.2 Confidencialidad 38

7.3 Derechos y propiedad de los desarrollos y datos 38

7.4 Protección de los datos 39


8 Estructura y Formato de la Propuesta 40

8.1 Estructura normalizada y contenido de las propuestas. 40

Pliego de Bases Técnicas 5/41

1 Introducción

EJIE, empresa pública del Gobierno Vasco contribuye, mediante la prestación de servicios informáticos, a conseguir una Administración Pública Vasca, moderna y eficiente. Así, construye y mantiene la infraestructura de los Sistemas de Información y Telecomunicaciones, posibilitando su continuidad y seguridad en base a un personal cualificado y a unos recursos y costes adecuados a la demanda. EJIE, tiene como meta final la consecución de la satisfacción de sus clientes. Para ello se ha impuesto como objetivos permanentes los siguientes:

Prestar servicios de manera eficiente y con calidad, asegurando el cumplimiento de los plazos de respuesta y un nivel "cero" de reclamaciones e incidencias.

Prestar servicios competitivos en relación al sector, en base a la permanente adecuación de los servicios internos al ámbito de actuación y asignando los recursos óptimos mediante la aplicación de los principios de racionalidad, especialidad y eficiencia.

Integrarse activamente con sus clientes en un entorno de transparencia, comunicación y con objetivos comunes: comprensión del problema, enfoque adecuado y resolución satisfactoria.

Obtener una imagen corporativa de servicio eficiente, de calidad y de empresa en punta tecnológica en el sector.

Podemos desglosar la actividad informática requerida por el Gobierno Vasco en tres ámbitos:

Infraestructura Operativa. Sistemas informáticos y de Telecomunicaciones.

Conocimiento funcional de la Administración Pública, y recursos técnicos para desarrollar el negocio.

Conocimiento tecnológico (TIC) que garantice la viabilidad de los proyectos abordados. EJIE se estructura en tres áreas de servicio, alineadas con las demandas del Gobierno Vasco:

Producción: Mantiene operativos los equipos informáticos, el software, las telecomunicaciones, los aplicativos, y los datos, con los niveles de seguridad requeridos.

Proyectos y Asistencia Técnica: Asesora y colabora con los departamentos en la definición, desarrollo, mantenimiento e implantación de sus sistemas de información, garantizando el cumplimiento de los estándares tecnológicos y la calidad del software. Asimismo se responsabiliza de la gestión integral de los proyectos comunes (proyectos de infraestructura y proyectos multidisciplinares). El área se compone de varios grupos asignados a los distintos departamentos del Gobierno Vasco, y compuestos por un responsable, técnicos de análisis y técnicos de desarrollo.

Sistemas y Telecomunicaciones: Estudia, desarrolla, mantiene, y soporta las infraestructuras tecnológicas existentes, y las de nueva implantación.

NOTA: Se puede obtener información más detallada y extensa en la dirección de Internet http://www.ejie.es/ Por otra parte, la Viceconsejería de Función Pública se halla inmersa en un proceso de reorganización y renovación íntegra de sus sistemas de gestión de RRHH para todos los empleados de la CAPV. Uno de los proyectos iniciados es la Implantación de las áreas SAP HCM, Portal y BW para la Administración de la CAPV. La implantación del nuevo sistema de RRHH está previsto que se realice para cuatro colectivos de personal pertenecientes a la CAPV: Administración General, Educación (pública y privada), Interior y Justicia. En la actualidad el proyecto está en curso y se encuentra en esta situación:

http://www.ejie.es/


Desde 1-12-2012, para Administración General, Justicia y Laborales de Interior, están en producción los módulos de PA (Registro de Personal), PD (Estructura Organizativa y RPT) y PE - Rol del empleado. Adicionalmente está operativa la infraestructura tecnológica de los entornos de desarrollo, pruebas y producción.

Desde 1-1-2013, para Administración General, Justicia y Laborales de Interior, se encuentran en producción los módulos de PT (Gestión de tiempos), BW (información para la dirección) y PE – Rol del responsable.

Para todos los módulos que actualmente se encuentran en producción hay que realizar adaptaciones específicas para la inclusión de los colectivos de Interior Ertzaintza y Educación (Pública y Privada). Estas evoluciones incluyen requisitos particulares, además de la necesidad de realizar la migración de datos y los interfaces para el intercambio de información entre los sistemas actuales y SAP. Por último, en estos momentos están pendientes de implementar, con porcentajes de avance diferentes, los módulos de: Nómina (PY), Pago Delegado (PG), Contabilidad Presupuestaria (CP), y Beneficios Sociales (BN).


2 Objeto del contrato

2.1 Objeto

Es objeto del presente pliego de bases técnicas la contratación del servicio de implantación, soporte a usuarios, mantenimiento y evolución de algunos módulos funcionales para el nuevo sistema de RRHH de la Comunidad Autónoma del País Vasco (en adelante CAPV), bajo plataforma SAP que se detallan en el apartado siguiente.

Según se ha indicado en el punto anterior, durante una etapa anterior se acometió por parte de EJGV parte del desarrollo del nuevo Sistema bajo las mismas especificaciones que se indican en el presente pliego. Los resultados parciales obtenidos deberán reaprovecharse al máximo posible. En caso de no reutilización, este hecho deberá justificarse por escrito (mediante un informe) y contar con aprobación por parte de la Dirección de Proyecto de EJIE.

El/los contratista/s del presente pliego deberá contemplar la coexistencia con el proyecto paralelo para la construcción y puesta en marcha del gestor de expedientes de RRHH (“Proyecto de implantación de un Gestor de Expedientes electrónico para el Sistema de Recursos Humanos de la Administración de la CAPV”), de forma que la solución completa deberá permitir el correcto funcionamiento del gestor. En caso de conflicto, ambos proyectos deberán llegar a un acuerdo equitativo que cubra las necesidades de EJIE/EJGV.

2.2 Áreas Funcionales

Los módulos/áreas funcionales de RRHH objeto del contrato se han dividido en los siguientes lotes:

LOTE 1

PD – Estructura organizativa y RPT

PA – Registro de personal

PT – Gestión de tiempos y planificación horaria

BW – Reporting de gestión e Información a la dirección. LOTE 2

CP – Contabilidad Presupuestaria

PY – Nómina

PG – Pago Delegado

BN – Beneficios Sociales

PE – Portal del empleado y responsable

AU – Gestión de usuarios y autorizaciones

LOPD – LOPD y auditoría de información LOTE 3

MI – Migración de datos

IF – Interfaces entre los sistemas actuales y SAP

AT – Arquitectura Tecnológica, TDMS y SOLMAN Asimismo, el número de empleados activos totales que finalmente tienen que gestionarse con este nuevo sistema son aproximadamente 50.000, repartidos por colectivos de la siguiente forma:

- Administración General (AG): 6.000 - Justicia (JU): 3.000 - Interior (IN): 7.000


- Educación Pública (ED - Publ): 22.000 - Educación Privada (ED - Priv): 12.000

Por otra parte cabe indicar que los desarrollos, parametrizaciones y documentación destinados al empleado deberán ser bilingües (euskara y castellano). La empresa contratista será responsable de habilitar la capacidad multi-idioma, introducir las traducciones en los sistemas (desarrollos, elementos SAP,….) y entregar los textos en castellano a traducir, cuya realización corresponderá a EJ-GV

A continuación se indica de forma resumida el estado de cada una de los módulos/áreas de cada lote. Las empresas interesadas en la licitación podrán solicitar cuanta información adicional estimen necesaria para realizar una estimación más precisa de los trabajos a realizar.

2.2.1. Lote 1

PD – Estructura organizativa y RPT

Este módulo está en producción. Actualmente se encuentran en curso las adaptaciones específicas para los colectivos de Interior y Educación pública y privada. El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.

A continuación se indica el % de avance aproximado de los trabajos actualmente en curso:

Módulo Colectivo% Avance

Parametr.

% Avance

Construc.% DF %DT % UAT

ED Priv 100% 100% 59% 57% 0%

ED Publ 41% 67% 59% 57% 0%

IN 74% 57% 59% 57% 0%

PD

-% Avance Construc.: % avance en la construcción de los desarrollos de cliente.

- % DF: % avance en la realización de los diseños funcionales de los desarrollos a medida

- % DT: % avance en la realización de los diseños técnicos de los desarrollos a medida

- % UAT: % avance en la realización de las pruebas de usuario

PA – Registro de personal





Parametr.

% Avance


ED Priv 95% 100% 10% 100% 21%

ED Publ 64% 47% 24% 57% 0%

IN 76% 60% 24% 57% 0%

PA





PT – Gestión de tiempos y planificación horaria




Parametr.

% Avance


ED Priv 100% 100% 27% 19% 33%

ED Publ 95% 75% 27% 19% 0%

IN 64% 48% 27% 19% 0%

PT





BW – Reporting de gestión e Información a la dirección.

Este módulo está en producción. Actualmente se encuentran en curso las adaptaciones específicas para los colectivos de Común (son funcionalidades comunes a todos los colectivos), Interior y Educación pública y privada. El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.




Parametr.

% Avance


Comun 100% 64% 14% 63% 18%

ED Priv 80% 100% 14% 63% 0%

ED Publ 0% 0% 14% 63% 0%

IN 18% 0% 14% 63% 0%

BW





2.2.2. Lote 2

CP – Contabilidad Presupuestaria

Este módulo NO está en producción. Este módulo no es estándar SAP ya que se trata de la interface de comunicación entre SAP HCM y el sistema de contabilidad presupuestaria de EJGV (IKUS), que es un desarrollo a medida. Actualmente se encuentran en curso las adaptaciones específicas para los colectivos de Común (son funcionalidades comunes a todos los colectivos), y Educación privada. En este módulo no hay requisitos específicos para el resto de colectivos. El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.



Parametr.

% Avance


Comun 100% 100% 100% 29% 51%

ED Priv 100% 100% 100% 29% 43%CP





PY – Nómina

Este módulo NO está en producción. Actualmente se encuentran en curso las adaptaciones específicas para todos los colectivos, excepto para Educación Privada que cuenta con un módulo diferenciado para el cálculo de la nómina de este personal (PG-Pago Delegado). El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.




Parametr.

% Avance


AG 100% 100% 55% 49% 45%

Comun 100% 100% 55% 49% 0%

ED Publ 98% 17% 55% 49% 0%

JU 100% 100% 55% 49% 100%

IN 92% 11% 55% 49% 0%

PY





PG – Pago Delegado

Este módulo NO está en producción. Actualmente se encuentran en curso las adaptaciones necesarias para su cálculo. El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.



Parametr.

% Avance


ED Priv 100% 36% 70% 52% 7%PG





BN – Beneficios Sociales

Este módulo NO está en producción. Actualmente se encuentran en curso las adaptaciones específicas para todos los colectivos, excepto para Educación Privada que no tiene requisitos para este módulo. El adjudicatario deberá finalizar estas adaptaciones para las fechas indicadas en el apartado correspondiente.








Parametr.

% Avance


AG 100% 100% 73% 67% 100%

Comun 100% 100% 73% 67% 25%

ED Publ 98% 75% 73% 67% 0%

JU 100% 100% 73% 67% 100%

IN 95% 75% 73% 67% 0%

BN

PE – Portal del empleado y responsable




Parametr.

% Avance


ED Priv 100% 35% 40% 0% 0%

ED Publ 0% 50% 40% 0% 0%

IN 70% 100% 40% 0% 0%

PE





AU – Gestión de usuarios y autorizaciones

Este módulo está en producción. El desarrollo realizado es común para todos los colectivos.

LOPD – LOPD y auditoría de información

Este módulo está parcialmente en producción. La funcionalidad específica de LOPD está implantada quedando pendiente de construir íntegramente la correspondiente a auditoría de información.

2.2.3. Lote 3

MI – Migración de datos


Este área está parcialmente en producción. La migración de los módulos en productivo para los colectivos de AG, JU e IN-L está completamente realizada, quedando pendiente la correspondiente a los módulos y/o colectivos no arrancados.

Serán objeto de migración por parte del contratista todos los datos de los sistemas existentes, asegurando así un pleno y óptimo funcionamiento del sistema para la utilización por parte de sus usuarios, así como un adecuado soporte a los procesos de gestión de recursos humanos.

El contratista será responsable de la ejecución de cualquier tarea adicional que sea requerida para garantizar que el sistema esté operativo en el momento del arranque o arranques parciales que se establezcan. Esto implica que el contratista deberá:

Asumir en el alcance la migración de los todos los datos contenidos en las aplicaciones actuales y que pasarán a ser gestionados por el nuevo sistema.

Planificar adecuadamente las tareas, tanto desde el punto de vista conceptual como operativo.

El contratista deberá validar, depurar, convertir, consolidar la información proveniente de los distintos colectivos y, finalmente, cargar los datos en el nuevo sistema.

Controlar el resultado final del proceso, garantizando la consecución de los resultados que se hayan previsto.

En caso de que se establezca algún proceso continuo de migración, o descarga de datos desde los antiguos sistemas, éste tendrá consideración de interfaz.

Los procesos de migración deberán diseñarse teniendo en cuenta la reversibilidad del dato necesaria para el área de integración.

Se deberán aportar, asimismo, los procedimientos y herramientas que correspondan para la incorporación en el nuevo sistema de toda aquella información necesaria que no estuviera contemplada hasta la fecha en las estructuras de datos de las aplicaciones actuales.

Se deberá comprobar, en todo caso, la consistencia de los datos cargados (tanto los obtenidos a partir de otras aplicaciones, como los grabados de forma manual) mediante las correspondientes pruebas de integridad de datos.

Los aspectos principales en los que se centrará el proceso de migración son los siguientes:

Determinar una estrategia detallada para conseguir el alcance de migración (existe un documento propuesta, pero que no está totalmente cerrado para los módulos aún no productivos).

Estudio de los sistemas de información origen que permita identificar las fuentes de datos: tablas, entidades y relaciones existentes en los modelos actuales. Para esta tarea servirá de ayuda el mapa de aplicaciones generado dentro del área de Integración con otros sistemas

Análisis de los datos existentes en origen llevándose a cabo un estudio sobre la calidad de los datos extraídos de las fuentes de datos identificadas

Análisis de los requisitos del nuevo sistema que permitirán identificar los repositorios de datos que será necesario cargar

Elaboración de un catálogo de datos que identificará el mapeo de datos origen/destino identificando qué datos necesitan depuración previa, tablas de equivalencia, procesos de transformación, etc…

Esta tarea permitirá, también, identificar las carencias de información existentes en los sistemas origen


Una vez construidos los procesos de transformación, conversión y carga de datos, tras probarlos unitariamente, se llevarán a cabo pruebas integradas del ciclo completo de migración en el entorno de test que permitirán comprobar que los procesos funcionan correctamente y que los datos cargados cumplen los indicadores de calidad establecidos.

Una vez confirmados los resultados satisfactorios de las pruebas integradas se podrá abordar el siguiente estado de pruebas, el Paralelo. El objetivo de estas pruebas es comprobar el correcto funcionamiento del sistema, tomando como referencia los diferentes sistemas productivos actuales. Se establece un mínimo de 3 paralelos por colectivo de paralelos, sin que esto suponga realizar un mantenimiento duplicado de los sistemas a comparar.

Durante el período de Paralelos, el proceso de migración se ejecutará periódicamente, para mantener la consistencia de los datos de SAP, la comparación de resultados de nómina, la verificación de los interfaces, la realización de pruebas, configurar la carga de datos definitiva, etc...

Con cada una de las ejecuciones, se revisarán y chequearán los datos migrados, por comparación con los datos existentes en los sistemas actuales, analizando los indicadores de calidad. Todos estos trabajos deberán estar perfectamente documentados y deberán tener su correspondiente documentación de explotación.

EJIE determinará qué procesos serán necesarios realizar para la adecuada comparación de resultados, paralelos, etc…por parte de los usuarios funcionales. Se proporcionarán los informes necesarios para poder comprobar los datos y validar el resultado.

Antes de la migración final sobre la nueva solución SAP HCM se elaborará un Plan de Migración (Plan de Corte) que deberá incluir, como mínimo, la planificación para la ejecución de las distintas extracciones de datos, la secuencia de tareas y tiempos de todos de los procesos así como una definición detallada del plan de contingencia. IF – Interfaces entre los sistemas actuales y SAP

Este área está parcialmente en producción. Los interfaces de los módulos en productivo para los colectivos de AG, JU e IN-L está completamente realizada, quedando pendientes los correspondientes a los módulos y/o colectivos no arrancados.

El contratista realizará el diseño, desarrollo e implantación de todos los interfaces con otros sistemas y entidades externas que mantienen relación con el sistema de RRHH.

Deberán mantenerse las integraciones existentes, minimizando el impacto de la puesta en marcha del nuevo sistema, mediante la propagación de la información desde el nuevo Sistema hacia los modelos de datos actuales.

De igual manera deberán abordarse las necesidades adicionales de intercambio de información derivados de la implantación de un nuevo modelo de gestión de recursos humanos: certificación electrónica, gestión documental, Portal del Empleado, etc...

Al gestionarse con el nuevo Sistema la información integrada de distintos colectivos, existe la necesidad de distribución de la información a los antiguos sistemas y por tanto deberá considerar la existencia de filtrado de datos a la hora de revertir la información a cada uno de ellos.

El hecho de que el presente pliego no contemple la puesta en marcha de todas las funcionalidades de RRHH, provocará la coexistencia entre módulos funcionales del nuevo sistema y de los sistemas actuales de los 4 colectivos. Esto supone que será necesario disponer de interfaces hasta que las funcionalidades afectadas no sean absorbidas por el nuevo sistema.


Las aplicaciones actuales que sean parcialmente sustituidas por el nuevo sistema, sufrirán un proceso de desintegración, es decir, deberán adaptarse según el grado de integración de su funcionalidad y convivirán con la solución SAP HCM. El desarrollo de los mecanismos de intercambio de información deberá abordarse minimizando las adaptaciones necesarias en las aplicaciones actuales, y teniendo en cuenta las limitaciones tecnológicas existentes en los entornos actuales. La responsabilidad de la adaptación del software de las aplicaciones actuales recaerá sobre EJ-GV.

Las estrategias de integración podrán ser distintas según el colectivo y/o el entorno afectado.

Como línea de trabajo a seguir, se generará un mapa de aplicaciones que permita el análisis de todas las aplicaciones/sistemas/entidades afectadas así como, de los flujos de Información existentes o derivados de los nuevos requisitos, entre ellas.

Se analizarán e inventariarán todos los bloques de información que fluyen entre las diferentes aplicaciones o entidades de cada colectivo y el sistema SAP de RRHH. Para cada flujo se determinaran sus características principales: aplicaciones implicadas, sentido (entrada/ salida), colectivo, periodicidad, etc…

Tomando como base los planteamientos iniciales y las soluciones tecnológicas de EJ-GV, deberán determinarse en detalle los escenarios tecnológicos de integración necesarios por cada colectivo. Los posibles escenarios identificados hasta el momento son: distribución ALE/IDOC del dato maestro, consumo y exposición de web services, integraciones asíncronas según modelo publicador/suscriptor (eventos), intercambio de ficheros (por NFS y otros medios) y uso de conectores basados en interfaces SAP estándar (Dorlet DASS, EMC Documentum, etc…).

A partir de los flujos identificados y los escenarios de integración propuestos se identificarán las interfaces que serán necesarias construir. Por cada interfaz deberá entregarse una documentación que describa su funcionalidad, todas sus características (aspectos de seguridad, volumen de información, periodicidad de ejecución, etc.) y el escenario en el que se encajará.

Teniendo en cuenta que cada uno de estos los interfaces constituirá una unidad de desarrollo, se elaborará su correspondiente documentación técnica (diseño funcional, diseño técnico y plan de pruebas).

Las pruebas de funcionamiento de la integración desarrollada deberán abarcar el ciclo completo de intercambio de datos, desde la extracción de los datos en origen hasta la consolidación de dichos datos en destino, siendo responsabilidad del contratista la planificación y coordinación de todos los recursos necesarios: software afectado (procesos estándar de la solución SAP HCM, nuevos desarrollos, adaptaciones sobre aplicaciones antiguas, aplicaciones intermedias, herramientas de envío…) y personal de todas las partes implicadas.

Durante la fase de pruebas se irán elaborando tanto el plan de implantación como los manuales de operación/explotación de interfaces.

AT – Arquitectura Tecnológica, TDMS y SOLMAN.

Aunque los 4 sistemas SAP (HCM, Portal, Bw y SOLMAN) están actualmente en productivo, este área tiene pendientes una serie de tareas adicionales a las habituales de mantenimiento de sistemas preventivo y reactivo:

Portal: Puesta en marcha de TREX: herramienta de indexación del Portal

Webdispatcher: la alta disponibilidad de la capa frontal de SAP en la actualidad es activo-pasivo. El objetivo del es que funcione en cluster.


BBDD: homogenizar las versiones de Oracle entre desarrollo, pruebas y producción

Mantenimiento de Logística de Software: En la actualidad existen muchas órdenes de transporte que no se pueden transportar a producción, lo que está provocando que exista una cola de import muy extensa y no permite realizar un Import All. Está pendiente definir e implementar alguna solución.

Monitorización: Integración de la monitorización de SAP (SOLMAN) con la Solución de Monitorización BEM/Patrol estándar de EJIE.

Backup/restore: Prueba de restore de Solution Manager. Solución Backups Instancias Java.

Seguridad: Implementar la solución de autenticación.

TDMS: El alcance de este apartado comprende tanto la instalación como la parametrización y puesta en marcha del producto según los requisitos/escenarios (copia y anonimización de datos, comparación de nómina y tiempos…) identificados por EJIE/EJGV.

SOLMAN: Durante la etapa anterior del proyecto se han utilizado varios escenarios previstos por el producto, además de los obligatorios para el soporte por parte del fabricante, SAP, y los propios de administración de sistemas (EWA, SRL, CCMS...). El contratista deberá realizar el mantenimiento íntegro (incluidos los desarrollos y parametrizaciones) de todos ellos. Los principales escenarios no técnicos utilizados son:

o Gestión documentación del proyecto.

o Gestión de tareas.

o Gestión de pruebas de integración y aceptación de usuario.

Asimismo, es objeto del contrato mejorar los escenarios técnicos como la explotación de la solución “Technical Operations” de Solution Manager (Monitorización Centralizada, herramientas centrales de administración, Root Cause Analisys, Explotación de Informes)

Gestión IT, adaptación los procedimientos de gestión de SAP a los estándares ITIL utilizados en EJIE (Gestión de cambios, Gestión de despliegues, Gestión de la capacidad, Continuidad de Negocio….)

Tareas de Fin proyecto:

o Reorganización y limpieza de mandantes

o Replicar Producción en Pruebas, para asegurar la coherencia de los sistemas.

o Entrega de Repositorio de Software instalado.

Por otra parte, existe una serie de entregables que están pendientes o desactualizados, siendo responsabilidad del contratista su completa elaboración:

Arquitectura

1. Solución de Albergue (Entregado. Mantenimiento Continuo)

2. Plan de Contingencia y Alta Disponibilidad. (No entregado)

3. Inventario Actualizado de Comunicaciones (Entregado. Pendiente Actualización)

Rendimiento

1. Plan de Pruebas de Rendimiento – Revisión (Willy) (Entregado. Mantenimiento Continuo)


Pruebas de rendimiento por Volumen/Aplicación (No entregado)

2. Informe de niveles de Servicio y herramientas para medirlos por parte de EJGV (No entregado)

3. Análisis del Ancho de Banda (No Entregado)

4. Plan de Pruebas de Contingencia y Continuidad (Entregado. Pendiente Actualización).

5. Solución de Archivo: propuesta de plan de descargas de datos y documentos (No Entregado)

Seguridad:

1. Definición Técnica de tipos de usuarios (No entregado)

2. Solución Autenticación (Entregado. Pendiente aprobación Ejie e Implementación por parte Proyecto).

3. Seguridad Lógica/física (No entregado)

Logística del Software:

1. Solución de Logística del Software (Entregado. Mantenimiento Continuo)

Solución al Import ALL (No entregado)

Monitorización: La versión actual no se ajusta a las necesidades de Ejie (Entregado. Pendiente Actualización)

Backup/Restore: La versión actual no se ajusta a las necesidades de Ejie y está incompleto (Entregado. Pendiente Actualización)

Jobs:

1. Plan de Pruebas Técnicas Jobs (Entregado. Mantenimiento Continuo)

2. Manual de Operación y Explotación de Jobs (Entregado. Mantenimiento Continuo)

3. Documentar Cadenas de BW (No entregado)

Administración de Sistemas:

1. Manual de Explotación y Administración de HCM. (Entregado. Mantenimiento Continuo)

2. Manual de Explotación y Administración de SOLMAN. (No entregado)

3. TREX: Manual de Instalación, Manual de Explotación y Administración de Trex. (No entregado)

4. Interfaces: Manual de operación/explotación de interfaces (No entregado)


2.3 Líneas de trabajo

Con objeto de definir más detalladamente el alcance y condiciones del contrato, se han establecido varias líneas de trabajo, caracterizadas principalmente por agrupaciones lógicas de actividades que deberán desarrollarse dentro de cada uno de los lotes, en función de estado de cada módulo/área. Las actividades englobadas en el servicio son:

Implantación de nuevos módulos funcionales Esta actividad comprende el análisis y diseño, el desarrollo y parametrización, las pruebas, la implementación y la gestión del cambio, de aquellos módulos/áreas que aún no están en productivo, según el estado indicado en el apartado 2.2.

El desarrollo del nuevo sistema ha de contemplar e integrar las acciones necesarias para satisfacer, además de los requisitos identificados en la documentación funcional del proyecto (BBPs, Diseños Funcionales, Actas de Reunión…) la normativa vigente aplicable en materia de RRHH, la organización de EJGV y la situación actual de los sistemas, así como las relaciones entre sí de los distintos subsistemas expuestos o con otros sistemas o entidades externos. En particular, es responsabilidad del adjudicatario adaptar las funcionalidades que no están en productivo a la normativa vigente en el momento de puesta en producción.

Atención a Consultas y Soporte Técnico de Aplicaciones

Definido como el conjunto de actividades de soporte y atención a consultas e incidencias técnicas, entre EJIE/EJGV y el personal técnico del proveedor. Estas actividades deberán ser realizadas preferentemente mediante la herramienta de gestión de peticiones de servicio (Mantis), frente al canal telefónico. En este último caso, una vez atendida la llamada, ésta también deberá darse de alta como petición de servicio en la herramienta de gestión.

Mantenimiento Correctivo:

Se define como aquel proceso orientado a la reparación de defectos existentes en un sistema software. Estos defectos pueden manifestarse de distintas formas:

o Cuando el programa falla o termina inesperadamente. o Un programa produce un resultado que no es acorde con los requisitos.

Se contemplan dos tipos básicos de mantenimiento correctivo:

o Reparaciones de emergencia: ejecutadas en cortos periodos de tiempo y generalmente sobre un único programa.

o Reparaciones planificadas: arreglan defectos que no requieren una atención inmediata y re-examinan todas las reparaciones de emergencia.

El mantenimiento correctivo incluye actividades que comprenden desde la colaboración activa con EJIE en el diagnóstico de los defectos detectados y su propuesta de solución, hasta el seguimiento y resolución de los mismos. También se incluyen como responsabilidad del adjudicatario los desarrollos necesarios para corregir los datos erróneos por el mal funcionamiento de la aplicación.

Toda actuación sobre el software motivado por un fallo o error de la aplicación será considerada siempre como actividad correctiva y en ningún caso actividad de tipo evolutivo.


Mantenimiento Evolutivo (incluye las evoluciones de los módulos/áreas necesarias para los colectivos de personal no en producción): Son las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la evolución o cambio de las necesidades del usuario, es decir, la incorporación de nuevas funcionalidades a la cobertura actual del software. Incluye, entre otros:

o Cambios en los requisitos de la aplicación

o Modificaciones derivadas de cambios en la normativa

o Modificaciones de alcance limitado que supongan mejoras del aplicativo y por tanto incorporables a la versión base

En base al esfuerzo requerido para su resolución, esta tipología de actividad se ha dividido en dos niveles: o Mantenimiento Evolutivo a pequeña escala

Son actividades relacionadas con el desarrollo evolutivo, cuyo tamaño y complejidad no son excesivos. Se estima un esfuerzo menor a 100 horas-persona.

o Mantenimiento Evolutivo a gran escala

Corresponderán a actuaciones de tamaño y complejidad más significativas, en concreto, aquellas cuyo esfuerzo sobrepase el límite establecido para el mantenimiento evolutivo a pequeña escala.

Mantenimiento Adaptativo: Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc. Incluye, entre otros:

o Cambios en el entorno de los datos o su procesamiento

o Cambios en la plataforma o arquitectura tecnológica

o Modificación de procedimientos existentes que no implican nuevas funcionalidades

o Exportaciones e importaciones de datos dedicados a la integración con otras aplicaciones del entorno, para mantenimiento de integridad de la información

o Integración con otros aplicativos a nivel de plataforma tecnológica

Este tipo de mantenimiento se regirá por los mismos criterios descritos en el mantenimiento evolutivo.

En función del estado de cada uno de los módulos/áreas las actividades a realizar son:

- Módulos/áreas en producción: Atención a Consultas y Soporte Técnico de Aplicaciones; mantenimiento correctivo, mantenimiento evolutivo y mantenimiento adaptativo.

- Módulos/áreas pendientes de implantación: se incluyen todas las actividades de las áreas en producción más la implantación de nuevos módulos funcionales.

GESTIÓN DE LA DOCUMENTACIÓN

EJIE cuenta actualmente con un repositorio documental de toda la información relacionada con el mantenimiento de estos módulos/áreas. Es responsabilidad del contratista su mantenimiento al día. El repositorio está contenido en el sistema SAP Solution Manager.


Asociado al ciclo de vida del desarrollo software, nuestra metodología de desarrollo ARINBIDE y la metodología propia de SAP ASAP ya marcan el conjunto de entregables que deben obtenerse en cada una de las fases que la componen. También en este aspecto, es fundamental disponer de toda la documentación perfectamente actualizada.

El contratista se compromete a actualizar de forma continua y sistemática toda la documentación técnica y funcional del proyecto, por lo que cada vez que se entregue una nueva versión de un producto, se deberá entregar, de forma simultánea, la versión actualizada de la documentación cuyo contenido haya cambiado como consecuencia de la actualización de funcionalidad o corrección de fallos del sistema.

La documentación será clara, concisa, precisa y mantenible de forma que permita cumplir, dependiendo del tipo de documento, las funciones para las que haya sido diseñada. Todos los documentos del mismo tipo estarán estructurados de la misma forma.

Se subraya también la necesidad de generar la documentación y elementos adicionales fijados por el servicio de gestión de cambios de EJIE para cada implantación:

Instrucciones implantación

Manual de explotación

Otros documentos según la tipología y características de la aplicación (seguridad LOPD, plan de continuidad de negocio, configuración de recursos en XLNetS, etc.)

El incumplimiento sobre la obligación del mantenimiento y actualización del repositorio y de la documentación generará la no aceptación del trabajo.

GESTIÓN Y ADMINISTRACIÓN DEL SERVICIO

Se incluyen en esta línea de trabajo las actividades relativas a la gestión y seguimiento del propio servicio, cuyos indicadores e informes deben ser reportados al comité de seguimiento para su aprobación y control. Se incluyen por lo tanto los informes detallados en el apartado de “Control y seguimiento” del presente pliego de bases técnicas.

2.4 Flujos de mantenimiento


2.4.1. Peticiones de servicio

GRUPO GESTIÓN

ANS

GRUPO

ASISTENCIA

TÉCNICACAUGESTIÓN CAMBIO

DEPARTAMENTO

PROVEEDOR

EJIE

Flujo de peticiones de servicio

Tomando como referencia el proceso de mantenimiento (MSI) definido por ARINBIDE, el licitador podrá incluir en su oferta una propuesta de flujo de peticiones de trabajo a aplicar durante la prestación del servicio. En última instancia, el modelo final a utilizar deberá ser aprobado por EJIE.

Será responsabilidad del adjudicatario establecer su protocolo de actuación interno para las peticiones que les sean requeridas.

2.4.2. Entregas

El modelo de referencia para realizar las entregas del código actualizado tras una solicitud de trabajo seguirá las directrices marcadas por el documento de Estándares de desarrollo de sistemas software, de obligado cumplimiento en el entorno de GV-EJIE.

El licitador deberá incluir en su oferta una propuesta de flujo de entregas a aplicar durante la prestación del servicio. En última instancia, el modelo final a utilizar deberá ser aprobado por EJIE.

Este flujo de entregas deberá incluir, en función de la tipología de la solicitud de trabajo resuelta: o El inventario de desarrollos o Documentación. Todos aquellos documentos que hayan sido modificados (BBPs, Diseños,

manuales de usuario, de explotación, etc.) o de nueva creación. o Documentación adicional necesaria para la logística de software.

El adjudicatario será el responsable de la implantación del cambio en todos los entornos, desarrollo, pruebas y producción.

La petición de trabajo se cerrará en el momento en que los cambios realizados hayan sido instalados satisfactoriamente en el entorno de producción.

http://www.ejie.net/documentacion.htm

http://www.ejie.net/anexos_PBT.htm


3 Configuración del Servicio

3.1 Organización del Equipo de Trabajo

El licitador deberá describir en su Documento de Propuesta Técnica:

La organización (perfiles) del equipo de proyecto asignado a la realización de las actividades resultantes del presente pliego, así como

Las funciones de los mismos

La relación nominal de los participantes, junto su correspondiente documento de currículo.

3.2 Asignación de recursos

El licitador deberá incluir en su Documento de Propuesta Técnica, un desglose de horas y % de dedicación total por módulo/área y perfil. Además se diferenciará el equipo destinado a:

- Implantación de los módulos no arrancados

- Mantenimiento de los módulos/áreas en producción

- Evoluciones necesarias de los módulos/áreas para los colectivos de personal no en producción

El equipo mínimo para la prestación del servicio de mantenimiento integral de los módulos/áreas en producción es de 1 FTE (Full-time equivalent), excepto para las áreas de Migración, LOPD, y Gestión de usuarios y autorizaciones.

El desglose de horas se considerará como orientativo y será tenido en consideración en el momento de valorar la proporcionalidad entre las diferentes módulos/áreas según la estimación del licitador, permitiendo, de esta forma, valorar la idoneidad del dimensionamiento del equipo de trabajo propuesto y su adecuación a la consecución de los objetivos.

Para poder conseguir la trazabilidad de las diferentes ofertas recibidas, todos los perfiles que se oferten deberán de pertenecer a alguna de las categorías indicadas a continuación y no a otras:

Jefe de Proyecto

Consultor Funcional

Consultor Técnico

Analista Programador

Programador

Programador Junior

Técnico de Sistemas

3.3 Equipo de Trabajo

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando.


El licitador debe comprometerse, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en el Documento de Propuesta Técnica, y durante el periodo fijado en cada actividad específica.

3.3.1. Certificaciones en SAP y nivel de conocimientos

El equipo propuesto por el licitador deberá tener el nivel mínimo de experiencia en función de su perfil que se detalla a continuación:

Jefe proyecto

Experiencia mínima de 5 años en Proyectos de gran volumen de Implantación/mantenimiento SAP HCM y de RRHH.

Conocimientos de Metodologías, Gestión del Cambio, Gestión de Riesgos y Gestión de aseguramiento de Calidad.

Consultor Funcional/Responsable de Módulo

Experiencia mínima de 5 años en Proyectos de Implantación/mantenimiento SAP HCM; preferiblemente en administración pública, en el módulo/área a la que esté asignado.

Conocimientos medios de Gestión de Equipos; Metodologías, Gestión de Riesgos y Gestión de aseguramiento de Calidad;

Conocimientos profundos y experiencia, tanto funcional como técnica, en Procesos y Procedimientos asociados a la gestión de RRHH de la Administración Pública; la globalidad del paquete estándar de SAP para HCM; gestión de pruebas tanto integradas como de usuario.

Consultor Técnico/Consultor de Módulo

Experiencia mínima de 1,5 años en Proyectos de Implantación/mantenimiento SAP HCM; preferiblemente en administración pública, en el módulo/área a la que esté asignado.

Conocimientos profundos, tanto funcional como técnica, en Metodologías; Procesos y Procedimientos asociados a la gestión de RRHH de la Administración Pública; módulos funcionales estándar de SAP para HCM; análisis, supervisión de la programación; gestión y ejecución de pruebas tanto integradas como de usuario.

Programadores

Experiencia mínima de 3 años en labores de programación y prueba en entornos ABAP, Java (SAP Portal, Oracle weblogic, SAP Netweaver Developer Studio, SAP NWDI), SOA,…

Programador Junior

Experiencia mínima de 1 años en labores de programación y prueba en entornos ABAP, Java (SAP Portal, Oracle weblogic, SAP Netweaver Developer Studio, SAP NWDI), SOA,…

Técnicos de sistemas

conocimientos y experiencia mínima de 4 años en proyectos de implantación/mantenimiento de plataforma y arquitectura SAP, proyectos Portal Web y SAP ERP, proyectos de gestión autenticación…


3.3.2. Veracidad de los datos

EJIE se reserva la facultad de solicitar, en cualquier momento, antes o después de la adjudicación y durante el curso de los trabajos, de cualquier otro tipo de documento complementario, en orden a la comprobación de cuantos datos haya ofrecido la empresa adjudicataria, tanto respecto a la misma, como a los recursos de que disponga.

La falsedad en los mismos podrá implicar asumir penalizaciones, y en último término, podrá provocar la resolución del contrato.

3.3.3. Condicionante del equipo de trabajo ofertado

La falsedad en el nivel de conocimientos técnicos del personal ofertado, deducida del contraste entre lo reflejado en el currículo y los conocimientos reales demostrados en la ejecución de los trabajos, podría en último término, provocar la revisión de la adjudicación y en su caso la rescisión del pedido/contrato.

3.3.4. Constitución inicial del equipo de trabajo

El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes relacionados en la oferta adjudicataria y consecuentemente valorados.

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el Documento de Propuesta Técnica objeto de la misma y:

Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo

que suscita el cambio, se procederá a:

La presentación por el adjudicatario de posibles candidatos con un perfil de cualificación

técnica igual o superior al de la persona que se pretende sustituir.

Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de EJIE

Caso de que se demostrase que el cambio no se corresponde con causa justificada, de fuerza

mayor y no imputable al adjudicatario, EJIE se reserva el derecho no solo a la aprobación de la

persona o personas sustitutivas, sino incluso a la revisión de la adjudicación y en su caso la

rescisión del pedido/contrato, si este hecho fuera elemento determinante en la mencionada

adjudicación.

3.3.5. Modificaciones en la composición del equipo de trabajo

La valoración final de la productividad y calidad de los trabajos de las personas que realizan los trabajos objeto del presente pliego corresponde a la Dirección del Proyecto de EJIE, siendo potestad suya solicitar el cambio de cualquiera de los componentes del equipo de trabajo, con un preaviso de quince días, por otro de igual categoría, si existen razones justificadas que lo aconsejen.

Si el adjudicatario propusiera el cambio de una de las personas del equipo de trabajo, se deberá solicitar por escrito con quince días de antelación, y requerirá de las siguientes condiciones:

Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.


Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al de la

persona que se pretende sustituir.

Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de EJIE

Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las sustituciones de personal, deberán subsanarse mediante periodos de solapamiento sin coste adicional, durante el tiempo necesario. Si a criterio de la Dirección del Proyecto de EJIE, esto no fuera posible, las dos primeras semanas de trabajo del sustituto no serán facturables corriendo a cargo del adjudicatario.

3.3.6. Jornada laboral y lugar de realización de los trabajos.

El adjudicatario deberá tener al menos un recurso por módulo/área con la ubicación física en EJIE/EJGV. La propuesta recogerá el detalle de los recursos que están en presencial y en remoto. Una vez iniciado el servicio, estos cambios de ubicación deberán ser expresamente aprobados por el Director de proyecto de EJIE.

Para el personal que realice los trabajos de desarrollo en las dependencias del adjudicatario:

La jornada de trabajo estará de acuerdo a la establecida por el adjudicatario,

Los componentes del grupo de trabajo deberán estar en una única ubicación y desarrollarán su

labor con hardware y software propiedad del adjudicatario. Dicha ubicación deberá ser lo

suficientemente cercana a EJIE como para garantizar una presencia rápida en sus dependencias

ante cualquier eventualidad que pudiera surgir.

Para el personal que realice los trabajos de desarrollo en las dependencias de EJIE/EJGV, estos se realizarán en las siguientes condiciones:

La jornada de trabajo estará de acuerdo a la establecida por EJIE,

Con carácter general los componentes del grupo de trabajo deberán desarrollar su labor con

hardware propiedad del adjudicatario. El equipo será plataformado con la imagen corporativa de

EJIE/EJGV para su conexión a la Red Corporativa.

Si por circunstancias excepcionales y cuando la realización efectiva de los trabajos no se ajuste a

la planificación o así se requiera por las necesidades del servicio, el adjudicatario deberá

comprometerse a una plena disponibilidad incluso fuera del horario habitual (salvo acuerdo previo

por la Dirección del Proyecto de EJIE), sin que la realización del trabajo tenga una consideración

especial a efectos de cómputo de horas o tarifa aplicable a las mismas

El horario de atención telefónica, así como la atención a peticiones de mantenimiento correctivo se ajustará a la jornada de trabajo establecida por EJIE.

Con objeto de garantizar la continuidad de los servicios críticos proporcionados por las aplicaciones incluidas en el presente pliego de bases técnicas, el adjudicatario deberá facilitar un teléfono de contacto 24x7 que permita activar, en caso necesario, el servicio de mantenimiento correctivo para peticiones de prioridad muy urgente o urgente objeto del contrato.

Las necesidades excepcionales de ampliación del horario de disponibilidad de los entornos de EJIE, o de sus servicios de soporte u operación, deberán ser acordados con antelación suficiente con el Director de Proyecto de EJIE. En cualquier caso solo se contemplarán las necesidades recogidas en el catálogo de servicios de EJIE.


3.3.7. Currículo de los componentes del grupo de trabajo.

Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de contratación, junto con el papel/perfil (conforme a los indicados anteriormente en este PBT) que asumen en la realización descrita.

La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una adecuada evaluación del apartado de “Organización del Proyecto”, pudiendo el licitador no ser puntuado por este concepto.

Datos del currículo:

Apellidos y Nombre,

Edad,

N.I.F., N.S.S. y justificación/certificación de alta en la empresa (certificado de la S. Social)

Conocimientos metodológicos y tecnológicos principales.

Formación Reglada: Centro, Titulación y Fechas (desde-hasta).

Formación no Reglada: Centro, Curso y Fecha (desde-hasta).

Certificaciones SAP: Descripción y Fecha.

Experiencia Acumulada: Total Años.

Experiencia profesional: Empresa, Puesto / Responsabilidades, Meses o Años, Fecha (desde-

hasta).

Conocimientos y Experiencia obtenida Proyectos: Proyecto, Puesto / Responsabilidades, Meses,

Fecha (desde-hasta), y principales tecnologías utilizadas, para al menos los principales o

correspondientes a experiencias similares.


4 Especificaciones Técnicas

4.1 Metodología de desarrollo, normativa y Guía de Estilo

La organización del trabajo y ejecución del proyecto estará basada en la Metodología de planificación y desarrollo de sistemas de información ARINBIDE.

ARINBIDE se concibe como una metodología práctica para el ciclo de vida completo del software, basada en Métrica 3, y adaptada a las necesidades y directrices de EJ-GV/EJIE, Además consta de un apartado para establecimiento de una metodología de Gestión de Proyectos. Como Plan de Calidad la propia metodología, en sus apartados de trabajo habitual, genera los registros de calidad necesarios para el sistema de calidad de EJ-GV/Ejie. Por las características del Proyecto las tareas y entregables podrán ser complementados con las recomendaciones o definiciones contenidas en la metodología Accelerated SAP (ASAP).

Para todo el ciclo de vida del proyecto, ARINBIDE define las siguientes fases metodológicas:

Gestión del proyecto (GPR)

Análisis del Sistema de Información (ASI)

Diseño del Sistema de Información (DSI)

Construcción del Sistema de Información (CSI)

Implantación y Aceptación del Sistema (IAS)

Mantenimiento del Sistema de Información (MSI)

Gestión de la configuración (GCO)

Información detallada sobre las fases y entregables de la metodología ARINBIDE, se encuentra en la página web (http://www.ejie.net/documentacion.htm), así como información sobre estándares tecnológicos, de desarrollo, de calidad

Igualmente será de referencia el Documento de Estándares Tecnológicos de Gobierno Vasco, publicado en: www.euskadi.net/informatika

La aplicación de la metodología propuesta estará apoyada en el uso de las herramientas informáticas necesarias. A tal efecto la oferta incluirá todas las licencias de uso necesarias.

El modelo de ciclo de vida del software seleccionado deberá contemplar la realización de prototipos de diseño del sistema de cara a facilitar las labores de definición y validación de las especificaciones por parte de los usuarios.

4.2 Entorno Tecnológico

El sistema se desarrollará principalmente sobre los productos SAP ERP (ABAP), SAP Netweaver Portal (JAVA) y SAP BI (ABAP+JAVA). No se excluye la posibilidad de que algunas funcionalidades, se desarrollen en las plataformas J2EE estándar de EJIE. En todo momento deberán respetarse todas las convenciones


establecidas por la Dirección de Informática y Telecomunicaciones y EJIE para el desarrollo, explotación y albergue de aplicaciones (www.euskadi.net/informatika)

Si bien las licencias de SAP y del gestor de base de datos, las aportará el Gobierno Vasco, queda comprendido en el objeto de este contrato el servicio de instalación del software en los servidores que la Administración de la Comunidad Autónoma del País Vasco determine. Quedan comprendidas además la integración en la arquitectura tecnológica actual, con los ajustes que se precisen y la definición de los ajustes en la infraestructura que se necesiten. En la realización y codificación de las unidades de tratamiento de las aplicaciones se utilizará una metodología estructurada y homogénea de diseño y programación, no debiendo existir procesos diferentes para la solución de funcionalidades idénticas.

Las herramientas para el desarrollo deberán adecuarse a los estándares tecnológicos establecidos por EJ-GV (www.euskadi.net/informatika).

Deberán respetarse las normativas establecidas por Ejie para explotación y albergue de sistemas. En el caso que se plantee, dentro de este ámbito, la utilización de herramientas no recogidas en dicha normativa, ésta deberá actualizarse y completarse por parte de la empresa contratista, previa autorización para su uso por parte de Ejie.

Así mismo, en lo que respecta a la implantación de sistemas en explotación y su posterior operación, se estará a tenor de lo dispuesto en el documento Normativa de Explotación de Ejie. Si durante el desarrollo de los trabajos sufrieran algún cambio, estos deberán ser asumidos por la empresa contratista de los mismos.

Para aquellas funcionalidades a publicar en Internet deberá tenerse en cuenta la normativa de la presencia de Euskadi en Internet (euskadi.net).

La empresa contratista deberá mantener los Libros de Estilo para los portales de empleado de intranet de todos los colectivos. Dichos libros contienen los principios o bases comunes y ciertas especificidades para cada uno de los colectivos.

La solución completa de RRHH del proyecto está construida sobre la base de SAP ERP, que se complementa con otros productos y sistemas para conformar la solución completa, entre los que podemos destacar:

El portal de RRHH como punto de acceso a los contenidos de empleado y responsable (basado en SAP Netweaver Portal)

SAP BW para la explotación de la información y la toma de decisiones

SAP Solution Manager como herramienta de gestión centralizada de sistemas SAP

SAP NWDI y Netweaver Developer Studio para el desarrollo Java

Desarrollo J2EE en la infraestructura estándar de EJIE/EJGV

Sistemas de control de presencia y acceso Dorlet DASS

Platea (Plataforma Tecnológica para la e-Administración) como proveedor de servicios horizontales de ayuda a la gestión electrónica

Dokusi para la gestión documental (basado en EMC Documentum)

En el documento PBT-PLATEA-Anexos se anexa explicación detallada de los sistemas corporativos involucrados en PLATEA.



4.3 Modelo de aseguramiento de la calidad

EJIE contempla la calidad en distintos ámbitos de aplicación, tanto calidad en los procesos como calidad en los productos.

Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el adjudicatario deberá contemplar y proveer la documentación que sea requerida en cumplimiento de la metodología ARINBIDE.

Por otro lado, con el objetivo de asegurar además la calidad de los productos software obtenidos, será de referencia obligatoria el modelo estándar de aseguramiento de la calidad definido para el contexto de GV-EJIE, que a grandes rasgos consta de:

Asignación del valor NAC (nivel de aseguramiento de la calidad) asociado al proyecto.

Controles de calidad (SQA) a realizar durante el ciclo de vida de desarrollo del software.

Tipologías de pruebas a ejecutar.

La metodología de pruebas que permita certificar de manera más exhaustiva el cumplimiento de los estándares de calidad definidos.

Los indicadores estándar, las métricas y sus umbrales permitidos.

El conjunto de herramientas que facilitan la aplicación de la metodología y la obtención de indicadores.

En este ámbito de definición de la calidad, será de referencia el documento de Estándares de calidad de producto Software, así como la Metodología de Pruebas.

4.3.1. Construcción del sistema

Los desarrollos y parametrizaciones se ajustarán siempre a los requisitos funcionales, así como a los diseños conceptuales, funcionales y técnicos correspondientes, asegurando la trazabilidad de los requisitos de principio a fin.

Se maximizará la compartición y reutilización de funcionalidades entre los desarrollos, evitando duplicados de código.

Deberá garantizarse el acceso a la información, implementando los mecanismos de seguridad y confidencialidad correspondientes, así como de auditoría.

Deberán contemplarse posibles funcionamientos anómalos de los componentes, implementando gestión de excepciones y control de errores.

Se realizarán los desarrollos teniendo en cuenta que deberá construirse un sistema multi idioma.

Se deberá maximizar el uso de parámetros de configuración en detrimento de la codificación de constantes en el código fuente.

El contratista se comprometerá a realizar análisis estático de código sobre los desarrollos antes de su transporte a pruebas, y así depurar en primera instancia el código que se promociona.

Los desarrollos proporcionarán un rendimiento adecuado al uso previsible del sistema, que se determinará durante la fase de consultoría, y asegurarán la escalabilidad, garantizando así la estabilidad y las condiciones de crecimiento del sistema.

Para el aseguramiento de la calidad de los entregables del proyecto, la empresa contratista deberá establecer el procedimiento de Gestión de Calidad dónde estén descritas todas las medidas dispuestas por la empresa para asegurar la calidad de los trabajos. Dicho procedimiento deberá abarcar las tareas

http://www.ejie.net/documentacion.htm






de: definición del Plan de Calidad; establecimiento de metodologías, estándares, herramientas, métricas; planificación de revisiones, de las posibles acciones correctoras; diseño de los distintos informes de calidad,…). Dicho procedimiento será de obligado cumplimiento (en el apartado Modelo de aseguramiento de la calidad del presente pliego se describe en más detalle la gestión requerida).

Deberá realizarse un análisis de usabilidad y navegabilidad de las interfaces de usuario desarrolladas.

Las aplicaciones creadas por el contratista deberán ser fácilmente mantenibles, a través de módulos y herramientas de administración.

La separación de la lógica de Presentación y lógica de Negocio deberá estar clara en el código, así como el acceso a los datos.

Un aspecto importante a la hora de realizar un desarrollo, y de obligado cumplimiento por los desarrolladores, será dejar una traza o log, un rastro de las acciones que se van realizando a lo largo de su ejecución.

Se establecerán por tanto las pautas para llevar a cabo el seguimiento en tiempo de ejecución de todos los desarrollos a realizar y así:

Rastrear de manera más rápida y cómoda la ejecución de un programa.

Encontrar y depurar errores más rápidamente.

Extraer estadísticas y conclusiones sobre los programas.

Facilitar la tarea de las personas encargadas del mantenimiento de los desarrollos.

Realizar un mantenimiento más eficiente de las aplicaciones.

La metodología de trazas y logs será de lectura y cumplimiento obligatorio para todos los desarrolladores, de manera que conozcan:

Las herramientas necesarias para la creación de logs.

Cómo utilizar el log de manera rápida y sencilla en cada una de las tecnologías que intervienen en los desarrollos.

En qué casos deben de aplicar la creación de un log.

4.3.2. Controles de calidad (SQA)

En función del NAC asignado, se han definido una serie de controles de calidad, cuya ejecución es obligatoria o recomendada, tal y como se define en el documento de Estándares de calidad de producto Software.

El adjudicatario deberá contemplar la ejecución de estos controles de calidad dentro del alcance del proyecto objeto de contratación.

4.3.3. Tipologías de pruebas


El modelo de aseguramiento de calidad establece que el cumplimiento del estándar está además condicionado por el conjunto mínimo de tipologías de pruebas que se deberán realizar. El alcance de éstas viene ya determinado por la propia metodología de desarrollo ARINBIDE. O si es de aplicación, de manera complementaria, por la metodología de pruebas.

A la hora de realizar las pruebas, la estrategia a seguir deberá incluir obligatoriamente la realización de pruebas unitarias, de integración, y de sistema, más la de aceptación si los cambios realizados deben ser validados por el usuario. Estos cuatro tipos de pruebas deben realizarse independientemente del NAC obtenido. Las de sistema, divididas en funcionales, y no funcionales (que incluyen las de rendimiento) se deberán ejecutar según el nivel NAC asignado al proyecto.

4.3.4. Metodología de pruebas

Dada la no existencia de un proyecto de Oficina Técnica de Calidad, paralelo al presente pliego de contratación, el adjudicatario, además del cumplimiento de la metodología de desarrollo ARINBIDE, deberá contemplar la ejecución de las tareas propias de la Metodología de Pruebas que se consideren oportunas, como son:

o Checklist de verificación de ARINBIDE (CVA) o Definición y gestión del plan de pruebas mediante la herramienta homologada a tal efecto (Ver

Anexo de herramientas) o Realización del Informe Final de Pruebas (IFPB) o Seguimiento y gestión de incidencias mediante la herramienta homologada a tal efecto (Ver

Anexo de herramientas) o Realización del informe final de incidencias (IIPB) o …

4.3.5. Indicadores

Aunque la propia Metodología de Pruebas ya define un conjunto completo de indicadores y sus umbrales asociados, existe un conjunto básico de indicadores que toda aplicación a implantar en el entorno de GV-EJIE deberá satisfacer.

En el entorno de desarrollo, para obtener los resultados de los indicadores para el proyecto se deberán seguir las instrucciones marcadas en el documento Indicadores_NAC.Desarrollo, en el que se especifican detalladamente los pasos a realizar y las herramientas a utilizar en cada momento.

El adjudicatario del presente contrato deberá contemplar la ejecución de las tareas necesarias para la obtención de los indicadores que apliquen dentro del alcance del proyecto objeto de contratación.

Igualmente, como parte del aseguramiento de la calidad, se ha definido para el entorno de pruebas (pre-producción) el documento Indicadores_NAC.Pruebas. El adjudicatario del presente contrato deberá suministrar toda la información y entregables que sean requeridos en este ámbito para la realización de las pruebas.

4.3.6. Rendimiento

Debido al elevado número de usuarios del nuevo sistema y a la necesidad de completar determinados procesos en paralelo por parte de todos los usuarios en unos plazos muy reducidos, así como de ofrecer información en tiempo y forma a cualquier nivel de gestión desde el que ésta sea solicitada, será requisito imprescindible para la aceptación del sistema que éste cumpla unas óptimas condiciones




técnicas y operativas en cuanto a tiempo de respuesta, rendimiento, optimización del ancho de banda utilizado, escalabilidad, agilidad de la interfaz disponibilidad, trazabilidad, etc.

Los tiempos de respuesta del sistema tendrán en cuenta la dispersión geográfica de los distintos ámbitos de gestión de la Administración de la CAPV.

Se deberá estudiar el tráfico de comunicaciones generado por los sistemas y las necesidades de conexión y ancho de banda de la infraestructura de comunicaciones para soportar las transacciones y operaciones generadas por el sistema, teniendo en consideración las situaciones de pico.

Se revisará el dimensionamiento realizado por el equipo de proyecto anterior y en caso de que sea necesario deberán definirse los ajustes en la infraestructura que se necesiten para el correcto funcionamiento del sistema (hardware, sistemas de almacenamiento, comunicaciones, puestos cliente, etc.)

Se definirán indicadores de rendimiento (KPIs) de los procesos de negocio principales y/o significativos de cada área y se realizarán pruebas de carga y estrés que certifiquen el correcto funcionamiento del sistema de acuerdo a los indicadores establecidos, verificando los niveles de respuesta de la aplicación ante las previsiones de carga del sistema. Así mismo se verificará el comportamiento global del sistema en cuanto a consumo de memoria y CPU de sus componentes.En caso de necesidad, se realizará el proceso de optimización de rendimiento (tunning) de los sistemas y componentes afectados.

El contratista pondrá a disposición del Gobierno Vasco las herramientas que permitan medir de manera sencilla los niveles de cumplimiento de los indicadores de seguimiento del servicio que se determinen y compararlos con los objetivos que se establezcan.

Se establecerán estrategias de descarga de datos y documentos antiguos que garanticen en todo momento un rendimiento óptimo del sistema. Si procede, el contratista deberá definir y poner en práctica una estrategia para el diseño y la instrumentación del archivado de información histórica de RRHH, con arreglo a las directrices de arquitectura y sistemas de EJ-GV.

Tiempos de Respuesta

Para todos los sistemas y módulos, sin excepción, se determinara el tiempo de respuesta objetivo de las pantallas del usuario final, que servirán como referencia para identificar posibles problemas de rendimiento y usabilidad:

Para una transacción de consulta ligera (recuperación de un conjunto limitado de datos de un solo item).

Para una transacción de consulta pesada (recuperación de un importante conjunto de datos de un solo item, o pocos datos pero de un número elevado de items).

Para una transacción de actualización media (ni especialmente pesada ni especialmente ligera).

Otros casos se analizarán en base a los ejemplos anteriores.

Será responsabilidad del contratista conseguir que la mayor parte de las funcionalidades respondan de acuerdo a lo establecido. En cualquier caso, se deberá garantizar que los usuarios puedan sostener un ritmo de trabajo sin esperas ilógicas.

Otro tipo de operaciones y opciones que no puedan encajarse en los supuestos anteriores recurrirán al criterio general de sostenimiento del ritmo de trabajo (tanto si hablamos de usuarios como si hablamos de programas) sin esperas ilógicas.


Para aquellas operaciones y opciones que no puedan medirse en términos de pantalla de usuario final (procesos batch, servicios, etc.):

Debe ser capaz de procesar con buen rendimiento evaluación de tiempos, nómina, seguros sociales, y todos los trabajos adicionales ligados al proceso de Nómina, en horario de tarde/noche; y extracciones sistemáticas de información como el fichero de Plantilla u otros semejantes;

Debe ser capaz de procesar con buen rendimiento, y cumpliendo ventanas horarias, los procesos anuales de cambio de partidas presupuestarias, recálculo de IRPF, cálculos asociados a determinación de importes anuales para Hacienda, y otros similares. Así como también retroactividades incluso masivas.

Debe ser capaz de procesar trabajos en diferido que no supongan desatar procesos masivos ni generalizados, en horario de mañana, sin afectar sensiblemente al on-line.

Los procesos batch no deberán disminuir la disponibilidad y respuesta de los sistemas, en el horario de 7:00h a 22:00h.

Las duraciones anormalmente largas de procesos batch se analizarán todo lo necesario hasta encontrar alternativas que las reduzcan a extremos manejables.

Los servicios (componentes de todo tipo que sean llamados on-line por otros programas) tendrán un tiempo de respuesta tal que el elemento llamante no incurra en esperas.

4.4 Herramientas del ciclo de vida de las aplicaciones

Como soporte e instrumento necesario en la ejecución de todas las fases del proyecto, existe un conjunto de Herramientas homologadas por EJIE, que abarcan todo el ciclo de vida de las aplicaciones, y que facilitan la realización de distintas tareas y normalizan la obtención de entregables.

Estas herramientas homologadas son las que se utilizan en el entorno de trabajo de EJIE, no pudiendo utilizarse en el mismo otras herramientas similares o equivalentes.

Para los trabajos a realizar en las dependencias del proveedor, su uso es recomendado frente a otros productos o herramientas del mercado, para dar cobertura a los cometidos para los que están destinadas. No obstante, en los casos en los que el resultado de uso de las herramientas sea un entregable con un formato específico y normado, su uso será obligatorio frente a otras herramientas de mercado, o bien en cualquier caso deberá proporcionarse un formato compatible.

En el documento PBT-Anexo Herramientas se detallan las herramientas homologadas.

http://www.ejie.net/herramientas.htm



5 Control y Seguimiento

El propósito de las tareas de control y seguimiento es el de proveer una visión objetiva del estado actual de la prestación del servicio y determinar las posibles desviaciones a fin de aplicar las acciones correctoras que sean necesarias.

Los productos mínimos de esta práctica son los informes de seguimiento, un documento o artefacto, donde anotamos los resultados de la evaluación de una iteración de control; de momento sin decir las correcciones a tomar.

Una vez identificadas las desviaciones/riesgos, es necesario decidir oportunamente las correcciones requeridas, llevándolas a cabo en el momento en que sea necesario. Finalmente es importante que la corrección planteada sea a su vez, objeto de seguimiento, lo que implica que la planificación debe ser actualizada para que refleje las acciones que se han determinado necesarias para corregir la desviación.

A la hora de realizar las reuniones de seguimiento es conveniente calcular previamente las medidas o métricas que aplicadas al servicio objeto de la contratación sirvan de indicador sobre el estado del mismo. Esto con el objeto de obtener una evaluación lo más completa y objetiva posible de la prestación del servicio.

Así, bajo esta perspectiva, el licitador deberá describir en su Documento de Propuesta Técnica:

El modelo de control y seguimiento a aplicar durante la prestación del servicio, incluyendo las reuniones de seguimiento a celebrar, su objetivo, su periodicidad, los asistentes necesarios, los controles que deben ser ejecutados, etc.

Los informes de seguimiento.

Los indicadores de calidad del servicio a medir, y su criticidad asociada.


6 Condiciones particulares

6.1 Hitos y duración del servicio

La duración del contrato para todos los lotes es de 11 meses.

Adicionalmente los contratistas, en función de cada lote, deberán cumplir los siguientes hitos/plazos parciales:

- 31/12/2013: Implantación de los módulos PY, CP y BN para los colectivos de AG, JU e IN-Lab.

- 31/12/2013: Paso a producción de las evoluciones de los módulos de PA, PD, PT, PE y BW para el colectivo de IN-Func (Ertzaintza).

- 31/12/2013: Implantación de todos los módulos de ED privada (PA; PD, PT, PE, BW, PG y CP).

- 31/03/2014: Paso a producción de las evoluciones de los módulos de PY, CP y BN para el colectivo de IN-Func. (Ertzaintza).

- 31/05/2014: Implantación de todos los módulos de ED pública (PA; PD, PT, PE, BW, BN, PG y CP).

Las áreas transversales a todos los módulos (MI, IF; LOPD, y AU) deberán cumplir con las fechas de cada uno de los módulos/colectivos, con la parte de la funcionalidad que requiera cada uno de ellos.

6.2 Presupuesto y Modelo de facturación

Se establece un presupuesto máximo por lote:

Lote 1: 1.178.688,35 € (IVA NO incluido).

Lote 2: 1.454.621,00 € (IVA NO incluido)

Lote 3: 889.418,25 € (IVA NO incluido)

En documento separado y siguiendo lo establecido en el modelo de Pliego/Hoja de Cláusulas Administrativas se deberá incluir el importe Total de la Oferta Económica, con y sin I.V.A, para cada uno de los lotes a los que opte. Adicionalmente, el contratista deberá desglosar el importe correspondiente cada uno de los módulos/áreas, por colectivo, integrantes de cada uno de los lotes a los que opte, indicando para aquellos que aún no están en productivo la parte destinada a la implantación y la correspondiente al mantenimiento integral. Para el caso de los módulos en productivo deberá indicar la parte destinada a las evoluciones para la inclusión de los nuevos colectivos y la correspondiente al resto de mantenimiento integral. Asimismo, opcionalmente, se podrá incluir cualquier otro desglose de estimación de esfuerzos que se considere relevante para la correcta evaluación del apartado “Proposición económica” contemplado en la sección de Criterios de Valoración.

En el precio ofertado se entenderán ya incluidos: las dietas, gastos de desplazamiento y/o cualquier otro gasto necesario para la realización del servicio. Con independencia de lo aquí indicado será necesario incluir el desglose de cualquier gasto o aspecto objeto del presente pliego si así fuera requerido de forma expresa en el Pliego/Hoja de Cláusulas Administrativas.

Por último, el contratista deberá incluir una propuesta de facturación no vinculante, que deberá ser aprobada en el Comité de Dirección del proyecto, una vez iniciado el mismo.


6.3 Penalizaciones

En las reuniones de Comité de Dirección, y en base a los informes de Nivel de Servicio, se comprobarán

las desviaciones resultantes, siendo objeto de penalizaciones en los términos que a continuación se establecen.

1.- El incumplimiento de los plazos parciales/hitos previstos en el apartado “6.1. Hitos y duración del servicio” del Pliego de Bases Técnicas se penalizará con arreglo a las siguientes estipulaciones:

- cada mes de retraso se penalizará con un 2 % del importe correspondiente a la implantación del

módulo/área o del importe de las evoluciones para la inclusión de los nuevos colectivos, según

corresponda.

2.- Para el servicio de mantenimiento integral, el incumplimiento de los niveles de servicio propuestos por el contratista, según el siguiente cuadro

Rango de desviación Penalización sobre

importe mensual

De 1 al 5 % 1%

Del 6 al 10 % 2%

Superior al 10% 3%

En el caso de incumplimiento de los plazos parciales/hitos previstos en el apartado “6.1. Hitos y duración del servicio” del Pliego de Bases Técnicas, en un plazo superior a 3 meses, EJIE podrá resolver el

contrato unilateralmente.

6.4 Criterios de valoración

Los criterios de adjudicación que servirán de base para la valoración de las propuestas presentadas a cada uno de lotes, así como sus pesos de ponderación se recogen a continuación. Para la evaluación de las propuestas, que se realizará de forma independiente para cada uno de los lotes, se establecen unos criterios de ponderación con una puntuación máxima de 100 puntos.

A continuación se detalla la puntuación y aspectos que se tendrán en cuenta para la adjudicación de cada uno de los lotes:


Característica Objeto de valoración Puntos

Proposición Económica 50

Entendimiento y planteamiento solución 25

Equipo de Trabajo propuesto 20

Planificación y Organización del proyecto 5

La Proposición económica se valorará al 50% en 2 subcriterios. Precio total de la propuesta (25 puntos), para los importes correspondientes a las evoluciones

para la inclusión de los nuevos colectivos de los módulos en productivo, y para la implantación de módulos no en productivo:

Total puntos (precio total) x Precio Total más ventajoso (el de precio más bajo) Tarifa media oferta evaluada

Valor medio ponderado de las tarifas (25 puntos) para los importes correspondientes a los mantenimientos de la parte de los módulos/áreas en producción. Se calculará sobre el valor medio de las tarifas de los distintos perfiles solicitados ponderadas por el nº de horas de dedicación prevista, y utilizando la fórmula:

Total puntos (valor medio ponderado tarifas) x Tarifa media más ventajosa (la de precio más bajo) Tarifa media oferta evaluada


7 Garantía y Confidencialidad

Las cláusulas relativas a la propiedad intelectual, garantía y confidencialidad de la información, así como el resto de condiciones generales de contratación se encuentran disponibles en la web de EJIE (www.ejie.net) en el apartado perfil de contratante.

7.1 Garantía

El período de garantía será como mínimo el tiempo que dure el contrato. No obstante los licitadores especificarán, en su caso, el tiempo de garantía ofrecido superior al mínimo, así como el alcance de la misma.

El adjudicatario se compromete a resolver las desviaciones causadas por errores propios y no inducidas por otras aplicaciones o intervenciones externas sin cargo alguno para EJIE, sin embargo, cualquier producto que entregado por el adjudicatario, sea modificado por un tercero, perderá de inmediato su garantía.

7.2 Confidencialidad

El proveedor se compromete a:

Tratar con absoluta confidencialidad todo el material y la información que reciba como

consecuencia de los trabajos realizados objeto de la adjudicación, durante el periodo de tiempo de

duración de la misma,

No utilizar la misma para otros fines que los recogidos en el presente Pliego de Condiciones

Técnicas.

No duplicar, copiar, revelar, ceder o vender total o parcialmente la información obtenida, en todo o

en parte, a terceros sin autorización escrita de EJIE,

Advertir a sus empleados de sus obligaciones respecto a la confidencialidad de la información,

velando por el cumplimiento de la misma,

Restringir la utilización de la información obtenida como consecuencia de los trabajos realizados

objeto del presente pliego de bases técnicas, exclusivamente para aquellos empleados que

tengan necesidad de conocerla y con la finalidad de realizar los trabajos expuestos.

Poner todos los medios a su alcance para conservar el carácter confidencial y reservado tanto de

la información y documentación recibida de EJIE, como de los resultados obtenidos del trabajo

realizado.

La devolución de toda la información, material y/ soportes informáticos obtenidos, así como a la

descarga de la misma de sus equipos informáticos o (si existieran), una vez finalizado el periodo

de contratación correspondiente.

Cualquier infracción en este sentido será calificada como grave y será causa de resolución del contrato, sin perjuicio de las responsabilidades penales, o de otro tipo, en que se puedan incurrir.

7.3 Derechos y propiedad de los desarrollos y datos

Todos los derechos de propiedad intelectual y de ‘Copyright’ de cualquier producto o subproducto derivados de los trabajos realizados bajo la correspondiente adjudicación serán propiedad exclusiva de EJIE, obligándose


las partes a otorgar el documento oportuno cuando éste sea necesario, para la debida constancia pública de este hecho ante cualquier Organismo o Registro, tanto de la Comunidad Autónoma como de la Administración Central del Estado Español.

Así mismo todo producto o subproducto derivada de la correspondiente contratación no podrá ser utilizado para otros fines fuera del ámbito de la misma, sin el permiso expreso y por escrito de EJIE.

La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.

7.4 Protección de los datos

El proveedor quedará obligado al cumplimiento de lo dispuesto en la Ley Orgánica de Protección de Datos, sobre protección de datos de carácter personal. En este sentido, deberá sujetarse a los preceptos de la Ley Orgánica 15/1999, de 13 de diciembre, LOPD, y su Reglamento de Desarrollo, RD 1720/2007, de 21 de diciembre.


8 Estructura y Formato de la Propuesta

El licitador sólo podrá presentar su propuesta contemplando una única alternativa.

8.1 Estructura normalizada y contenido de las propuestas.

La propuesta que se presente por el licitador deberá aportar la información que se requiere en todos sus apartados y estar obligatoriamente estructurada de la siguiente forma:

Documento de Propuesta Técnica, incluyendo

Índice.

Presentación y Características Generales:

Identificación del pliego al que responde la propuesta.

Acatamiento con carácter general a las condiciones del pliego.

A partir de este punto, los siguientes apartados se particularizarán para cada una de las soluciones que se oferten.

Descripción de la Solución Técnica/Servicio.

Se incorporará al inicio de este apartado el resumen de los aspectos más significativos y

relevantes de la solución propuesta. Se deberá incluir información detallada de la propuesta en

relación con los requisitos de este pliego. Se trata, en definitiva, de una memoria descriptiva del

servicio ofertado.

Descripción del Entorno Tecnológico.

Organización del equipo de proyecto, junto con perfiles, funciones y responsabilidades.

Datos relativos de todos los componentes del equipo de trabajo, incluyendo el cuadro de

asignación de recursos a los módulos/áreas incluidos en el servicio.

Composición del equipo de trabajo propuesto, ordenado por categorías profesionales.

Currículo de cada uno de los componentes, de acuerdo a lo indicado en el apartado Equipo

de Trabajo y recogido en Anexo al Documento de Propuesta Técnica.

Planificación y Organización.

Se indicarán las principales fases/tareas del servicio y el cronograma de trabajos.

Procedimientos de Gestión, Control y Calidad del servicio

Metodologías

Garantía, Confidencialidad y Propiedad Intelectual.

(*) En ningún caso se deberá incluir información Económica en el Documento de Propuesta Técnica.

Documento de Propuesta/Oferta Económica, incluyendo:

Importe Total de la oferta Económica: sin I.V.A.

Número de horas por persona y categoría/perfil.


Coste hora por categoría/perfil.

Siguiendo el modelo establecido.

Cualquier otro requisito establecido en el Pliego de Cláusulas Administrativas.

Documents

Pliego de bases técnicas: sistema de RRHH del Gobierno ... · Por otra parte, la Viceconsejería de Función Pública se halla inmersa en un proceso de reorganización y renovación