EXPEDIENTE: 15G-2008/OT

TÍTULO: SUMINISTRO E INSTALACIÓN DE SISTEMAS DE CONTROL DE ACCESOS EN LOS EDIFICIOS DE GESTIÓN CENTRALIZADA DE EUSKO JAURLARITZA / GOBIERNO VASCO DURANTE LOS AÑOS 2008 Y 2009

ASUNTO: BASES TÉCNICAS

1. ANTECEDENTES

Eusko Jaurlaritza / Gobierno Vasco dispone de un sistema de gestión de accesos en los edificios de gestión centralizada de forma que mediante la utilización de tarjetas de proximidad las personas autorizadas acceden a los mismos quedando registro de todos los eventos de este tipo.

Asociadas a este sistema se tienen varias aplicaciones que permiten gestionar las visitas, el control horario del personal y funciones de seguridad, ya que se trabaja sobre cerraduras eléctricas, tornos, molinetes, barreras para vehículos interfonía etc.

En el corazón de este sistema se encuentra una base de datos y el aplicativo correspondiente de forma que se gestionan los grupos de usuarios, grupos de accesos, grupos de tarjetas, horarios y la propia gestión del conjunto.

Esta aplicación está relacionada con una base de datos del Gobierno, que se migra a otros sistemas y aplicativos SAP.

Entre las diferentes opciones HARDWARE / SOFTWARE se ha considerado conveniente la sustitución del actual sistema de terminales y lectores ya que se constata que las tarjetas actuales no cumplen los requerimientos de seguridad establecidos.

Hay que recordar que el actual es una extensión del antiguo sistema de control horario dirigido inicialmente a este fin en exclusiva. Más tarde se colocaron con los sistemas de control

Donostia - San Sebastian, 1 – 01010 VITORIA-GASTEIZTef. (945) 01 84 85 – Fax (945) 01 87 06

OGASUN ETA HERRI ADMINISTRAZIO SAILA

DEPARTAMENTO DE HACIENDA Y ADMINISTRACIÓN PÚBLICA

de acceso tales como tornos y puertas con cerraduras eléctricas siendo cada vez más una función de seguridad a nivel de accesos.

Esto hace que las tarjetas deban garantizar la validación del acceso de forma segura. En este caso se considera que las tarjetas actuales de 125 KHz. con chip marin no cumplen con los requisitos de seguridad ya que no se tiene la garantía de unicidad y son fácilmente copiables.

Por otro lado la tecnología actual en este campo ha evolucionado hacia las denominadas tarjetas MIFARE que se pretende utilizar lo que supondrá la sustitución de todas las tarjetas por otras nuevas de este tipo.

El suministro de estas tarjetas no será tenido en cuenta en la presente contratación.

2. OBJETO DEL SUMINISTRO

El objeto de la presente contratación es el suministro e instalación de equipos, sistemas de control de accesos para los edificios de gestión centralizada y aplicación para gestión de accesos y gestión de visitas.

3. REQUISITOS DE LA APLICACIÓN INFORMATICA PARA GESTION DE ACCESOS Y VISITAS

3.1. FUNCIONALIDAD DE LA APLICACIÓN

Acceso a aplicación con perfil de usuario

Traspaso de datos a aplicaciones del Eusko Jaurlaritza / Gobierno Vasco.

Mantenimiento de terminales, lectoras, calendarios, horarios, rutas de accesos, control de activación y desactivación de sistemas, etc.

Lector de tarjetas si son de acceso, la dirección de acceso será Entrada / Salida y si el lector es de presencia (reloj) la dirección de acceso es Interior. Este dato se exporta con los datos de la fichada para control horario.

Permita que el mismo lector en una ruta sea solo acceso para ciertas personas y control horario para otras y la persona pueda tener las 2 rutas de accesos asociadas a una tarjeta.

Permita asignar más de una tarjeta a cada persona.

Proceso para obtener las personas que se han integrado como alta y modificación automática y tiene pendiente de asignar txartela y/o rutas de acceso.

En cada persona, por cada ruta de acceso se tiene una fecha alta y una fecha de baja.

Considerar los accesos de visitas de una persona interna por olvido de tarjeta, como fichadas de control horario.

Mantenimiento de visitas concertadas

Entrada de nueva visita, que por defecto se cargan los datos del visitado de su última visita.

Permita que la persona que está en recepción (puesto de visitas) quede identificada.

Para una nueva entrada de visita, por defecto se cargan los datos del visitado en su última visita realizada.

En el registro de entrada de visitas, guardar en la visita el nro. de tarjeta que se entrega a través de un lector de tarjetas.

Control de un máximo nro. de accesos presentes en un lector o ruta de acceso. Limitar aforo.

Consulta de personas presentes en una estructura orgánica, estructura física, sala, persona visitada según tipo de persona Interna, Externa o Visita.

Consulta de datos por días, horas, matricula, tarjeta, DNI, tipo de persona (Interna, Externa, Visita), lector, ruta de acceso, estructura orgánica, estructura física, sala y persona visitada.

Consulta de tarjetas de visitas no devueltas.

Consulta de nro. visitas que realiza una persona en un periodo de tiempo y en un edificio.

Todas las consultas y listados que se generen en la aplicación se podrán exportar a Excel, PDF u otros formatos.

Exportación de datos de fichadas que intervienen en control horario, para otros sistemas.

Anexo “formatos de ficheros para exportar fichadas”.

Borrado o descarga de datos según LOPD.

Política de seguridad XLNET.

3.2. INTEGRACION DE LA NUEVA APLICACIÓN

El sistema incorporará automáticamente todas las altas, bajas y modificaciones del personal interno y externo, así como visitas que el aplicativo de Eusko Jaurlaritza / Gobierno Vasco genere en una base de datos o fichero.

La aplicación estará adaptada al sistema de seguridad de XL NET.

Se exportarán on-line a fichero o base de datos los movimientos de control de presencia o accesos.

3.3. MIGRACION DE DATOS HISTORICOS

Migración de los datos históricos de visitas actuales:

Los datos identificativos de la persona visitante o de matriculas visitantes.

El último visitado de la persona visitante

Estructura orgánica

Estructura física

Salas

Migración de datos históricos de accesos y presencia.

3.4. FUNCIONALIDAD DE DATOS HISTORICOS

De Visitas:

Consultas, listados para estadísticas anuales. Filtro por días, horas, matricula, tarjeta, DNI, tipo de persona Visita, persona interna, externa como visita por olvido de tarjeta, lector, ruta de acceso, estructura orgánica, estructura física, sala y persona visitada.

De Accesos:

Consulta de datos por días, horas, matricula, tarjeta, DNI, tipo de persona (Interna, Externa, Visita), lector, ruta de acceso, estructura orgánica, estructura física, sala.

Todas las consultas y listados que se generen se dejarán en Excel, PDF, u otros formatos.

3.5. IMPLANTACION DEL SISTEMA

3.5.1.Metodología aplicable

La metodología aplicable al proyecto se deberá basar en estándares homologados en el EJGV:

Los desarrollos deberán realizarse siguiendo la metodología de ciclo de vida de desarrollo de software estándar en el EJ-GV, Metodología Arin Bide (basada en métrica 3).

Herramientas de cumplimentación de requisitos y de cliclo de vida de proyectos de desarrollo.

Los definidos por la Organización Internacional para la Estandarización (ISO). En especial cabe mencionar la norma ISO 9001:2000 que especifica los requisitos para un sistema de gestión de la calidad (de aplicación en EJIE)

La metodología y herramientas de aseguramiento de la calidad de los desarrollos de EJIE basada en estándares internacionales.

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.

Se deberán respetarse las convenciones adoptadas para desarrollo, funcionamiento y albergue de aplicaciones Web (Intranet / Internet) recogidas en la normativa y estándares del Gobierno Vasco.

Deberá tenerse en cuenta la normativa de la presencia de Euskadi en Internet (euskadi.net).

La seguridad y control de acceso a las aplicaciones deberán utilizar el sistema de seguridad establecido como Administración de Usuarios y Seguridad para EJ-GV.

En el caso de que la realización del proyecto la metodología a actualizar estuviera apoyada en el uso de las herramientas informáticas. El adjudicatario incluirá todas.

Quedan excluidas las licencias del software de gestión de accesos y visitas.

La aplicación requiere la carga inicial de datos para el correcto funcionamiento del sistema.

3.5.2.Arquitectura, albergue e implantación

Estas tareas se realizarán conjuntamente entre el adjudicatario y el equipo de sistemas de EJIE. Asimismo, el adjudicatario además de incorporar los perfiles técnicos necesarios para estas tareas, será responsable único de realizar su planificación y seguimiento, identificando las desviaciones que se produzcan y definiendo y ejecutando acciones correctoras que corrijan o mitiguen las mismas.

Arquitectura de integración

Diseño y documentación de los distintos servicios de la solución en base a los distintos requisitos planteados; dentro del alcance de este aparatado se definirán la forma de exposición de los servicios, su tecnología y relación con otras iniciativas de integración existentes en EJIE de ámbito corporativo.

Solución de Albergue y Arquitectura de Sistemas

Diseño y documentación de los distintos componentes hardware y software de la solución en base a los distintos requisitos planteados; dentro del alcance de este aparatado se definirán entornos de trabajo, los componentes, su exposición y los distintos actores que harán uso de estos componentes.

Definición y documentación de las infraestructuras hardware y software reflejando las siguientes soluciones de:

Definicón de entornos de trabajo

Conectividad y exposición

Seguridad física y lógica

Componentes de la solución

Solución de almacenamiento

Solución de recuperación y backup

Solución de monitorización

Solución de alta disponibilidad y contingencias

Normativa de Albergue e Implantación

Normativa de albergue, documentación de las normas y buenas prácticas de cara al desarrollo de nuevas iniciativas que hagan uso de la plataforma eFactura.

Normativa de implantación, documentación de los procedimientos y tareas a realizar para la implantación en los distintos entornos y traspaso entre entornos de eFactura.

Implantación de las infraestructuras

Se trata de la parte del proyecto que implanta o ejecuta la instalación y albergue:

Instalación del hardware y software de la solución

Configuración de la solución

Pruebas de la plataforma

Manuales de Soporte y Explotación

Entornos de trabajo

Al menos deben existir tres entornos bién diferenciados:

Desarrollo, utilizado para el desarrollo y parametrización del sistema.

Pruebas, utilizado para realizar pruebas, cursos de formación, comunicación del proyecto y carga de datos de los sistemas antiguos.

Producción, utilizado para la explotación de la aplicación por parte de los usuarios finales y realización de carga de datos final.

Se gestionará de forma que se puedan contemplar los siguientes aspectos:

Versiones en los entornos de pruebas y producción

Se podrá obtener la funcionalidad diferencial entre versiones de objetos

Permitirá conocer las incidencias corregidas o modificaciones funcionales implantadas en una determinada versión

Posible Reconstrucción de cualquier versión de un objeto de los entornos de pruebas y producción.

Se dará soporte mecanizado al traspaso entre los tres entornos: desarrollo, pruebas y producción.

Asimismo el adjudicatario deberá definir y establecer, previo acuerdo con EJIE, las políticas y normativas de implantación, albergue y operación para el nuevo sistema. Para ello se tendrán en cuenta como punto de partida las políticas generales actuales de explotación de EJIE.

Por último, el adjudicatario tendrá que definir, teniendo en cuenta la normativa general establecida por EJIE, e implementar el plan de contingencias del nuevo sistema.

3.5.3.Documentación Entregable.

3.5.3.1. En la oferta

Se debe aportar la documentación sobre:

Requisitos técnicos del producto (arquitectura, plataformas, comunicaciones, back-up, almacenamiento, gestión de logs…),

Arquitectura del sistema y software a utilizar.

Donde existan diferentes perfiles de usuarios:

Usuario administrador

Usuario para gestión de accesos

Usuario para gestión de terminales, lectoras, rutas de acceso, calendarios, horarios, etc.

Usuario para gestión de visitas

Usuario para gestión de consultas

Usuario para gestión de otras operaciones.

Estos usuarios de diferentes perfiles sean por cada edificio o un conjunto de edificios, donde se instalan los sistemas de accesos y /o visitas.

Comunicación entre el aplicativo y los dispositivos (lectores y / o dispositivos de alarmas) y aplicaciones del Gobierno Vasco.

Base de datos.

Gestión de log.

Política de licencias. Mantenimiento, soporte, tarifas, servicios ofrecidos y niveles de servicio.

Mecanismos de disponibilidad y continuidad del producto (contingencia).

3.5.3.2. Para la implantación del sistema

Manual de usuario administrador y por cada tipo de perfil de usuario existente.

Manual de instalación cliente y servidor.

Manual de Implantación / Solución de Albergue.

Manual de administración del producto.

Plan de pruebas.

Manual de Explotación.

Plan de continuidad y continuidad del producto (Contingencia).

4. SUMINISTRO E INSTALACIÓN DE EQUIPOS Y SISTEMAS DE CONTROL DE ACCESOS

El sistema de control de accesos deberá tener una arquitectura distribuida en base a CPU´s para controles de acceso con capacidad de controlar lectoras así como entradas y salidas digitales para elementos auxiliares.

La alimentación será a 220 V. en corriente alterna y serán conectables en LAN 10/100 base T RJ45 con protocolo TCP/IP.

Las lectoras serán de proximidad con tecnología EAN-MIFARE con rango de lectura mínimo de hasta 7 cm.

Según se ha argumentado el sistema debe garantizar su convivencia al máximo nivel de integración con SAP. De ahí que se establezca como condición indispensable que los sistemas ofertados certifiquen su condición como partner homologados de SAP.

Existen varias configuraciones posibles ya que se tienen las siguientes situaciones y funcionalidades.

1. Terminal con teclado, lectora y display para control horario, unidad instalada, cableada y puesta en servicio.

2. Terminal con teclado, lectora y display para control horario con apertura de puerta con cerradura eléctrica, unidad instalada, cableada y puesta en servicio.

3. Terminal con teclado, lectora y display para control horario con apertura de puerta con cerradura eléctrica e interfono, unidad instalada, cableada y puesta en servicio.

4. Terminal con lectora para control de accesos con cerradura eléctrica, pulsador de salida, unidad instalada, cableada y puesta en servicio.

5. Terminal con lectora para control de accesos con cerradura eléctrica, pulsador de salida e interfono, unidad instalada, cableada y puesta en servicio.

6. Terminal con lectora para control de accesos con cerradura eléctrica, con una segunda lectora de salida (y sin pulsador), unidad instalada, cableada y puesta en servicio.

7. Terminal con lectora para control de accesos con cerradura eléctrica, con una segunda lectora de salida (y sin pulsador) e interfono, unidad instalada, cableada y puesta en servicio.

8. Terminal con lectora y display para control de acceso tipo barrera vehículos, lazo de empotrar en pavimento e interfono, unidad instalada, cableada y puesta en servicio.

9. Terminal con lectora y display para control de acceso tipo torno personas, unidad instalada, cableada y puesta en servicio.

10. Terminal con lectora y display para control de acceso tipo torno personas, con teclado, unidad instalada, cableada y puesta en servicio.

11.Terminal con lectora y display para control de acceso tipo torno personas, con una segunda lectora para salida de visitas y recogida en buzón mediante ranura en chasis, unidad instalada, cableada y puesta en servicio.

12.Reconocedor de tarjetas para registrar la entrada de visitas.

13.Lector de DNI, para incluir los datos personales en la aplicación (OCR,..)

14.Aplicación informática para gestión de terminales, tarjetas, horarios, lectoras, control de accesos, control de visitas, etc. y del sistema en general según requerimientos de usuarios y perfiles de usuarios. Configuración y programación del sistema.

La puesta en servicio de los suministros descritos en los puntos anteriores requiere una doble consideración dada la situación inicial de la aplicación actual en la que debe ser capaz de integrarse y la gestión integrada SAP a la que finalmente tenderá.

Ambos puntos de vista tendrán que ser considerados tanto técnicamente como desde el punto de vista económico. Es decir el concepto “puesta en servicio”

incluirá ambas fases inicial y final, de la configuración y gestión en la red de los terminales y serán realizados coordinadamente con la planificación que para la migración de ambas aplicaciones y bases de datos determine EJ/GV.

Se considerará la puesta en servicio de las unidades descritas incluyendo la configuración y programación a nivel gráfico en la aplicación solicitada en el punto 14.

A nivel de la partida 14 se preverán tres puestos de gestión para monitorización de eventos y trabajos relacionados a nivel de control de seguridad:

1 Edificio Lakua en Vitoria-Gasteiz con acceso a la totalidad de terminales de la red.

2 Edificio Andía en Donostia con acceso a la totalidad de terminales en Donostia.

3 Edificio Gran Vía 85 con acceso a la totalidad de terminales en Bilbo.

Además se tendrán dos licencias para acceso a la totalidad del sistema a nivel de administrador del mismo. La aplicación será multitarea y multiusuario.

Se desea un sistema integrado de Control de Acceso para lo que será preciso un nivel alto de interrelación entre los diversos sistemas de seguridad para lo que tendrá las capacidades de comunicación necesarias.

5. ALCANCE DEL SUMINISTRO

La instalación de control de accesos está configurada en cada edificio según las necesidades del Servicio de Seguridad que se mantendrá en su estado actual. Únicamente se prevén algunas ampliaciones que están reflejadas en las mediciones. Se tienen las siguientes unidades de acuerdo a las configuraciones 1 a 14 descritas en el apartado 4.

TIPO DE SUMINISTRO

NUMERO DE UNIDADES

VITORIA-GASTEIZ DONOSTIA BILBO TOTAL

1 25 3 4 322 1 1 1 33 2 3 3 84 20 1 1 22

5 20 2 2 246 2 2 2 67 1 1 1 38 10 - 2 129 25 - 8 3310 1 - 1 211 1 - 1 212 2 2 413 2 2 414 1

Este número de unidades para los diversos suministros se considerará de forma orientativa, ya que debe entenderse como un objetivo de migración del sistema que debe ser planificado y considerado con los diversos participantes en el presente proyecto incluidos los usuarios de los edificios.

Constituye por lo tanto un objetivo para el plazo establecido en la vigencia del presente contrato, es decir hasta el 31/12/09.

La concreción última de los suministros se hará mediante pedido específico una vez adjudicado el contrato de acuerdo a las condiciones del mismo. El plazo de cada uno de los pedidos se contabilizará a partir de la fecha del mismo y no podrá exceder del plazo hipotético ofertado en el apartado 6.

6. PRESUPUESTO, OFERTA ECONÓMICA Y DOCUMENTACIÓN

Se presentarán precios unitarios para cada uno de los suministros 1 a 14 descritos de acuerdo al modelo de proposición económica y anexo al mismo.

Así mismo en sobre C entregarán cuanta información consideren oportuno para la comprensión de la propuesta técnica. En particular lo especificado en el punto 3.5.3.1. de este pliego.

El presupuesto máximo establecido en la presente contratación es de 250.000 euros IVA incluido, distribuidos en las siguientes anualidades:

Año 2.008 125.000 €

Año 2.009 125.000 €

Así mismo se ofertará el plazo de entrega y planificación para un hipotético pedido de 20 terminales del tipo descrito en 4.9 instalados en funcionamiento con el software de gestión descrito en 4.14

7. CRITERIOS DE ADJUDICACIÓN

Se establecen los siguientes criterios de adjudicación:

1 Oferta económica 25 puntos

2 Valor técnico

- Calidad de los equipos. Prestaciones técnicas y capacidad de integración 15 puntos

- Calidad del aplicativo desde el punto de vista de usuarios (Servicio de Seguridad, visitas y administrador del sistema) 15 puntos

- Calidad del aplicativo desde el punto de vista de seguridad informática, redundancias, fiabilidad, estabilidad etc. 20 puntos

- Calidad del aplicativo desde el punto de vista de integración y comunicación con otros sistemas. 15 puntos

3 Plazo de entrega y planificación 10 puntos

- Según se solicita en apartado 6.

Vitoria-Gasteiz 4 de agosto de 2008

Fdo: Jesús Valcarlos

JEFE DE OFICINA TÉCNICA Y MANTENIMIENTO

Vº.Bº. Angel Albinarrate Eguia

DIRECTOR DE RECURSOS GENERALES