SCR6150c Versión 2.0(12/01/05) : Implantación, mantenimiento y evolución del sistema de RRHH del Gobierno Vasco sobre la plataforma SAP Fecha: Julio de 2014 Referencia: 036/2014 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 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.
Contenido Capítulo/sección Página 1 Introducción 4 1.1 Necesidad de contratación 5 2 Objeto del contrato 6 2.1 Objeto y Alcance del Servicio 6 2.2 Descripción del Servicio 6 3 Requisitos del servicio 13 3.1 Descripción 13 3.2 Flujos de mantenimiento 15 3.2.1. Peticiones de servicio 15 3.2.2. Entregas 16 3.3 Organización del Equipo de Trabajo 16 3.4 Asignación de recursos 16 3.5 Equipo de Trabajo 17 3.5.1. Certificaciones en SAP y nivel de conocimientos 17 3.5.2. Constitución inicial del equipo de trabajo 17 3.5.3. Modificaciones en la composición del equipo de trabajo 18 3.5.4. Horario y lugar de realización de los trabajos.(de prestación de los servicios)18 4 Especificaciones Técnicas 20 4.1 Metodología de desarrollo, normativa y Guía de Estilo 20 Pliego de Condiciones Técnicas
4.2 Entorno Tecnológico 20 4.3 Modelo de aseguramiento de la calidad 22 4.3.1. Controles de calidad (SQA) 22 4.3.2. Tipologías de pruebas 22 4.3.3. Metodología de pruebas 22 4.3.4. Indicadores 23 4.3.5. Rendimiento 23 4.4 Herramientas del ciclo de vida de las aplicaciones 24 5 Planificación y Organización 25 5.1 Transferencia Tecnológica. 25 6 Presupuesto y oferta económica. 26 6.1 Penalizaciones 26 7 Mecanismos de Seguimiento, Control y Supervisión 28 8 Criterios de Valoración. 29 9 Estructura y Formato de la Propuesta Técnica 32 9.1 Estructura normalizada y contenido de las propuestas. 32 Pliego de Condiciones Técnicas
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. 4/32
NOTA: Se puede obtener información más detallada y extensa en la dirección de Internet http://www.ejie.es/ 1.1 Necesidad de contratación 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 (en adelante proyecto EIZU). 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), Seguridad y Justicia. En la actualidad el proyecto está en curso y se encuentra en esta situación: Para Administración General, Justicia, Laborales de Seguridad, y Educación Privada, en producción los módulos de PA (Registro de Personal), PD (Estructura Organizativa y RPT), PE - Rol del empleado, responsable y web de centros de educación privada, PT (Gestión de tiempos), BW (información para la dirección), PY (Gestión de nómina), BN (Beneficios sociales), CP (Contabilidad Presupuestaria), y PG (Gestión del pago delegado). Adicionalmente, para el 30-09-2014, para el colectivo de Seguridad-Ertzaintza está prevista la implantación de los módulos de PA (Registro de Personal), PD (Estructura Organizativa y RPT), PT (Gestión de tiempos, sólo parcialmente), BW (información para la dirección), PE Roles de empleado y responsable, PY (Gestión de nómina), y BN (Beneficios sociales). Para todos los módulos que actualmente se encuentran en producción hay que realizar adaptaciones específicas para la incorporación del colectivo de Educación Pública y para el colectivo de Seguridad- Ertzaintza es necesario implantar completamente el módulo de planificación horaria y gestión de tiempos (PT). 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. 5/32
2 Objeto del contrato 2.1 Objeto y Alcance del Servicio Es objeto del presente pliego de condiciones técnicas la contratación del servicio de implantación, atención a consultas, mantenimiento y evolución del 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 previa etapa se acometió por parte de EJGV/EJIE 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 contratista 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 Descripción del Servicio La presente contratación comprende tres líneas de trabajo diferenciadas que cuentan con unos plazos y unos presupuestos diferenciados: 1. Evolución de los módulos/áreas necesarias para incorporar el colectivo de Educación Pública. 2. Evolución de los módulos/áreas necesarias para incorporar la gestión de tiempos y planificación horaria del colectivo de Seguridad. 3. Atención a consultas y mantenimiento de los módulos/áreas/colectivos que estén implantados al inicio o que entren en producción en cualquier momento hasta final del contrato. Los módulos/áreas funcionales de RRHH objeto del contrato son los siguientes: PD Estructura organizativa y RPT PA Registro de personal PT Gestión de tiempos y planificación horaria 6/32
BW Reporting de gestión e Información a la dirección. 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 MI Migración de datos IF Interfaces entre los sistemas actuales y SAP 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 - Seguridad (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 que aplican para los colectivos con implementaciones pendientes. 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: Educación Pública Módulo % Avance Parametr. % Avance Construc. % DF %DT % UAT BN 98% 75% 73% 67% 0% BW 0% 0% 14% 63% 0% PA 64% 47% 24% 57% 0% 7/32
PD 41% 67% 59% 57% 0% PT 95% 75% 27% 19% 0% PY 98% 17% 55% 49% 0% PE 0% 50% 40% 0% 0% Seguridad (Módulo de Gestión de Tiempos y Planificación Horaria) Módulo % Avance Parametr. % Avance Construc. % DF %DT % UAT PT 64% 48% 27% 19% 0% -% 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 Adicionalmente existen dos áreas horizontales que se encuentran en curso y cuyo alcance, para los módulos-colectivos no arrancados, se describe a continuación MI Migración de datos Esta área está parcialmente en producción. La migración de los módulos en productivo para los colectivos de AG, JU, IN y ED-Privada está completamente realizada, quedando pendiente la correspondiente a los módulos-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. 8/32
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 9/32
establece un mínimo de 2 paralelos por colectivo de empleados, 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 Esta área está parcialmente en producción. Los interfaces de los módulos en productivo para los colectivos de AG, JU, IN y ED-Privada está completamente realizada, quedando pendientes los correspondientes a los módulos-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 10/32
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. 11/32
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. 12/32
3 Requisitos del servicio 3.1 Descripción Con objeto de definir más detalladamente el alcance y condiciones del contrato, se han establecido varias actividades, caracterizadas principalmente por agrupaciones lógicas de tareas que deberán desarrollarse, en función de estado de cada módulo/área. Las actividades englobadas en el servicio son: 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 o Cuando el programa falla o termina inesperadamente. Un programa produce un resultado que no es acorde con los requisitos. Se contemplan dos tipos básicos de mantenimiento correctivo: o o Reparaciones de emergencia: ejecutadas en cortos periodos de tiempo y generalmente sobre un único programa. Reparaciones planificadas: arreglan defectos que no requieren una atención inmediata y reexaminan 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 total o parcialmente): 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 o o Cambios en los requisitos de la aplicación Modificaciones derivadas de cambios en la normativa Modificaciones de alcance limitado que supongan mejoras del aplicativo y por tanto incorporables a la versión base 13/32
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 o Son actividades relacionadas con el desarrollo evolutivo, cuyo tamaño y complejidad no son excesivos. Se estima un esfuerzo menor a 100 horas-persona. 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. Por su especial relevancia, las evoluciones de los módulos/áreas necesarias para los colectivos de personal no en producción total o parcialmente tendrán un tratamiento diferenciado dentro del contrato, que incluirá las siguientes actividades: 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 para todos los colectivos (total o parcialmente). 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. 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 o o o o Cambios en el entorno de los datos o su procesamiento Cambios en la plataforma o arquitectura tecnológica Modificación de procedimientos existentes que no implican nuevas funcionalidades Exportaciones e importaciones de datos dedicados a la integración con otras aplicaciones del entorno, para mantenimiento de integridad de la información 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. 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á 14/32
entregar, de forma simultánea, la versión actualizada o la nueva documentación cuyo contenido haya cambiado/surgido 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 condiciones técnicas. 3.2 Flujos de mantenimiento 3.2.1. Peticiones de servicio DEPARTAMENTO EJIE GESTIÓN CAMBIO GRUPO ASISTENCIA TÉCNICA CAU GRUPO GESTIÓN ANS PROVEEDOR Flujo de peticiones de servicio 15/32
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. 3.2.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. 3.3 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.4 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: 1. Evolución de los módulos/áreas necesarias para incorporar el colectivo de Educación Pública. 2. Evolución de los módulos/áreas necesarias para incorporar la gestión de tiempos y planificación horaria del colectivo de Seguridad. 3. Atención a consultas y mantenimiento de los módulos/áreas/colectivos que estén implantados al inicio o que entren en producción en cualquier momento hasta final del contrato. 16/32
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 Programador Programador Junior 3.5 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. El licitador debe comprometerse, en caso de ser adjudicatario, a mantener los recursos ofertados, según lo establecido en el Documento de Propuesta Técnica, y durante el periodo fijado en cada actividad específica. La empresa licitadora propondrá los recursos con la experiencia laboral acorde con el perfil asignado en la oferta. En la propuesta se deberán incluir referencias, desempeñando la categoría asignada en la oferta, sobre: Colaboraciones realizadas en proyectos grandes de implantación de SAP RRHH Colaboraciones realizadas en proyectos de grandes dimensiones de RRHH, no necesariamente en proyectos SAP Colaboraciones realizadas en proyectos pertenecientes a la Administración Pública Colaboraciones realizadas en proyectos de RRHH para la Administración Pública Colaboraciones realizadas en proyectos para el Gobierno Vasco y/o EJIE Años de experiencia desempeñando labores similares al rol a cubrir El licitador identificará la empresa a la que pertenece cada uno de los recursos y deberá incluir en la propuesta los certificados de la Seguridad Social de forma que se pueda comprobar la pertenencia del recurso presentado a la empresa correspondiente en el momento de presentación de la oferta. 3.5.1. Certificaciones en SAP y nivel de conocimientos Las establecidas como requisito de solvencia. 3.5.2. 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. 17/32
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 sustito con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir. Aceptación de los sustitutos 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.5.3. Modificaciones en la composición del equipo de trabajo La valoración final de la calidad de 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 sustituto/s con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir. Aceptación de sustituto/s 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.5.4. Horario y lugar de realización de los trabajos.(de prestación de los servicios) 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: 18/32
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 condiciones 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. 19/32
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 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. 20/32