PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES DEL...

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES DEL CONTRATO DE LA PLATAFORMA DE GESTIÓN DE SERVICIOS PÚBLICOS.

“SMART LOGROÑO”

Avenida de la Paz, 1126071 – Logroño (La Rioja)

Tfn: +034 941 277 000Fax: +034 941 277 079

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES DEL CONTRATO DE LA PLATAFORMADE GESTIÓN DE SERVICIOS PÚBLICOS. ”SMART LOGROÑO“

Contenido1 ANTECEDENTES ...........................................................................................................................3

2 OBJETO Y ALCANCE ....................................................................................................................4

3 DURACIÓN DEL CONTRATO ........................................................................................................6

4 PRESUPUESTO DE LICITACIÓN ..................................................................................................7

5 PAGO DEL PRECIO .......................................................................................................................8

6 PLAZO DE GARANTÍA ...................................................................................................................8

7 AMPLIACIONES Y MODIFICACIONES DEL CONTRATO ............................................................9

8 RESPONSABLE DEL CONTRATO ................................................................................................9

9 OBLIGACIONES ESENCIALES ...................................................................................................10

10 CRITERIOS DE SELECCIÓN .......................................................................................................10

11 CRITERIOS DE ADJUDICACIÓN .................................................................................................11

12 ANEXO A: INFRAESTRUCTURAS Y REDES DE COMUNICACIONES ....................................22

13 ANEXO B: PLATAFORMA DE GESTIÓN INTEGRAL .................................................................36

14 ANEXO C: SISTEMA DE GESTIÓN DE QUEJAS Y SUGERENCIAS ........................................66

15 ANEXO D: SISTEMA DE AFECCIONES EN LA VÍA PÚBLICA ................................................101

16 ANEXO E: REQUISITOS ............................................................................................................107

2


1 AntecedentesLas concentraciones de la población en núcleos urbanos han planteado en las últimas décadas la necesidadde reestructurar los servicios en todas las áreas de gobierno. Con el paso de los años, se ha aprendido avalorar la importancia, entre otras, de la calidad del agua que bebemos, del aire que respiramos, eltratamiento que hacemos de los residuos o las alternativas en la movilidad urbana. Sin embargo, esto en elsiglo XXI ya no es suficiente por sí solo, es necesaria la introducción de la tecnología: gestionar la ciudad dela mano de los nuevos avances, permitiendo que el ciudadano pueda sacar el máximo provecho de losservicios públicos, de la forma menos contaminante posible y con el máximo ahorro.

La Red Española de Ciudades Inteligentes (RECI), como asociación de ámbito nacional, enfoca su obra alescenario municipal para poner a disposición de todos los ayuntamientos aquellas actuaciones exitosas quese pueden implantar con el objetivo de mejorar y garantizar la calidad de vida de los ciudadanos. Dentro deeste panorama son muchas las medidas innovadoras que contribuyen a construir una ciudad del futuro conactitud abierta a la participación ciudadana.

Logroño es una ciudad plenamente convencida de esta necesidad de renovar y mejorar mediante losavances tecnológicos con proyectos ya ejecutados y otros que se irán llevando a cabo paulatinamente. Unejemplo claro de compromiso de futuro es el Pacto de Alcaldes, el cual es un movimiento europeo en el quese han unido diferentes entidades locales asumiendo el compromiso de mejorar la eficiencia energética yprogresar en materia de producción de energías renovables con el fin de reducir las emisiones de CO2 enun 20% para el año 2020.

El Ayuntamiento de Logroño, partícipe de dicho pacto desde el pasado 7 de septiembre de 2012, ya trabajaintensamente para tomar las medidas oportunas en beneficio de la calidad del aire que respiran sushabitantes, en la mejora de la movilidad a través de las actuaciones aprobadas en el Plan de MovilidadUrbana Sostenible (PMUS), en el buen uso de la energía con la reducción del presupuesto energéticogracias a medidas de eficiencia en edificios públicos y a la optimización del alumbrado, en la mejora de lasinfraestructuras del ciclo del agua, en la teleoperación de los servicios públicos con el uso intensivo de lasTIC's o en el aumento de la producción de energías renovables.

Hasta ahora todos los servicios se han gestionado individualmente desde la unidad administrativa en la querecae la competencia. Es un modelo de funcionamiento en vertical que ha dado frutos positivos en uncontexto económico en el que el presupuesto de ingresos lo ha permitido.

Todo ello, la concentración de población y de actividad económica en los núcleos urbanos, la situaciónsocioeconómica actual, los grandes retos de sostenibilidad de la sociedad, las nuevas necesidades ydemandas de los ciudadanos requieren transformar el modelo de gobernanza de las ciudades buscandouna reordenación inteligente del espacio y de los servicios, un incremento en la eficacia y eficiencia de losmismos, la reducción de costes, la disminución del consumo energético y el reajuste de la oferta a lasnuevas necesidades que plantean los agentes de la ciudad: ciudadanos, organizaciones, empresas,visitantes, etc.

Esta transformación redundará en una mejor calidad de vida, una mayor satisfacción y participaciónciudadana, una mayor transparencia en la gestión municipal, una mejora de las capacidades de intervenciónsocial y facilitará el acceso a los datos en sistemas abiertos contribuyendo a crear entornos atractivos parala inversión, crecimiento económico y generación de empleo.

Este cambio en el modelo de gobernanza de las ciudades se apoya en dos ejes fundamentales deactuación:

1. Desarrollar estrategias de inclusión que propicien un cambio de modelo de gestión de los serviciospúblicos. Un modelo basado en una gestión integral de los servicios municipales en el que sepueda compartir la parte de los mismos que pueda ser compatible, sobre todo en recursoshumanos, en el uso de la información y la teleoperación integrada.

2. Adoptar las nuevas tecnologías para realizar una gestión más eficiente en la prestación deservicios públicos, la redefinición de los mismos o el replanteamiento de las relaciones conciudadanos, turistas, empresas y proveedores.

El estado actual de la tecnología y la conectividad hace posible implementar modelos y solucionesinteligentes para desarrollar ciudades más sostenibles y con mayor calidad de vida. La plataforma de

3


gestión integral se constituye como un elemento fundamental de una Ciudad Inteligente ya que es la piezaque orquesta todas estas funcionalidades y objetivos.

El objetivo es convertir Logroño en una Ciudad Inteligente y, en este contexto, el Ayuntamiento de Logroñorealiza una apuesta integradora por el uso intensivo de las TIC en la gestión municipal, completando losproyectos realizados en la red de infraestructuras y comunicaciones y dotándose de una plataforma degestión integrada como instrumento de racionalización de las decisiones y acciones de gobierno quepermita la prestación eficaz, eficiente y sostenible de los servicios municipales, ofreciendo servicioscomunes y capacidad de integración y nuevos canales de comunicación más accesibles y ágiles a losciudadanos y agentes de la ciudad.

2 Objeto y AlcanceEl objeto del contrato es la puesta en marcha de la Plataforma Smart Logroño que incluye el conjunto deinfraestructuras, recursos materiales y humanos y servicios tecnológicos necesarios para la adquisición,transmisión y procesado de datos que permitan pasar de un modelo clásico de gestión independiente yjerarquizada a otro basado en la gestión de la ciudad como un todo, optimizar los procesos de gestión de losservicios urbanos e implantar un portal con los contenidos de datos abiertos del catálogo Open Datamunicipal. Además, incluye la capacitación de la Plataforma como soporte a la prestación del servicio deAtención Ciudadana y la integración posterior de servicios municipales.

Mediante la integración y puesta en marcha de la nueva gestión de los servicios municipales a través de laPlataforma Smart Logroño se pretende conseguir las siguientes mejoras y objetivos:

Dotación de equipamiento hardware y aplicaciones de gestión para la creación de unateleoperación única de los servicios públicos, por medio de un Centro de Control Integral (CCI) queunifique la atención telefónica de todos los servicios verticales que se integren.

Completar la dotación básica de infraestructuras de redes y comunicaciones soporte de laintegración posterior de servicios verticales.

Mejora de los canales de comunicación, conocimiento transversal del estado de los serviciospúblicos y mayor capacidad de respuesta e inmediatez en la intervención municipal.

Reducción y control del gasto público mediante la aplicación e implementación de la información ydel estado de los servicios integrados en la Plataforma Smart Logroño.

Fomento del uso de los avances tecnológicos mediante nuevos canales de comunicación entre laadministración y el ciudadano.

Mejora de la gestión de los servicios municipales por medio del conocimiento del estado de lossistemas en tiempo real y el análisis e integración de la información suministrada por la PlataformaSmart Logroño para cada servicio.

Integración futura de servicios públicos municipales como Regulación del Tráfico, AlumbradoPúblico, Medio Ambiente, Policía Local, Bomberos de Logroño, Protección Civil, etc. basada en laconcepción y desarrollo abierto y transparente de la Plataforma Smart Logroño. Esta integraciónno se refiere a la prestación propiamente dicha de los servicios, sino a la integración de datos ycontenidos para la visión global de la gestión de la ciudad.

El nuevo modelo de gestión se apoya en el uso de tecnologías y la participación activa de los ciudadanos yconlleva la necesidad de integración de servicios urbanos para optimizar el uso de recursos e instalaciones.

La integración de los servicios urbanos se sustenta en dos ejes: el uso de las tecnologías de la informacióny la comunicación (TIC's) y disponibilidad de medios materiales y humanos.

1. Las TIC's aportan los elementos que dotan a la ciudad de una nueva “inteligencia”, que coordina einterconecta los diferentes sistemas de manera más eficiente, mejorando la disponibilidad y tratamientode la información y permitiendo una gestión más racional de los recursos.

2. La integración de los servicios urbanos permite abordar las necesidades de recursos de forma global.En función de la naturaleza de los servicios, se producen sinergias como es el caso del uso compartidode recursos entre los servicios de Regulación del Tráfico y de Alumbrado Exterior Público o el serviciode Información y Atención Ciudadana que se convierte en servicio horizontal, común al resto de

4


servicios, asumiendo la operativa del Centro de Control Integral de la Plataforma Smart Logroño yatendiendo, tanto las demandas de los servicios municipales como la atención con los ciudadanos.

Por tanto, el presente contrato incluye:

1. Instalación de la infraestructura de las tecnologías de la información y las comunicaciones previstas eneste contrato para completar la estrategia de despliegue para dar servicio a la Plataforma SmartLogroño y al Centro de Control Integral (CCI).

2. Puesta en marcha y mantenimiento posterior de la Plataforma de gestión integral de la ciudad queincluye:

Despliegue y configuración de las funcionalidades y módulos básicos que se describen en estePliego.

Implantación de la funcionalidades y aplicativos comunes a los servicios verticales a integrar y a laprestación del servicio del Centro de Control Integral, incluyendo los sistemas de gestión de avisose incidencias, atenciones, de Quejas y Sugerencias y de afecciones en la vía pública.

Implantación de capacidades para la captación y normalización de la información, la gestión dedispositivos, la gestión analítica y georreferenciada de los datos y la elaboración de mapas,informes, indicadores y cuadros de mando ejecutivos para la gestión de los servicios y global parael gobierno de la ciudad.

Puesta en marcha de un Portal Smart Ciudad de relaciones con el ciudadano para el acceso acontenidos de la Plataforma Smart Logroño y un Portal Open Data con los contenidos de datosabiertos del catálogo Open Data que el Ayuntamiento de Logroño, a través de la Dirección Generalde Transparencia, está elaborando y que establezca un entorno que facilite la innovación ypotencie el emprendimiento.

Implantación de procedimientos y despliegue de la arquitectura y capacidades para la integraciónposterior de servicios verticales.

El desarrollo y ejecución de un “Proyecto-Piloto” de verificación de características, funcionalidadesy capacidades de la Plataforma de Gestión Integral.

3. Soporte a la operativa diaria, a la atención de incidencias y a la evolución de la Plataforma de gestiónintegral de la ciudad, incluyendo la consultoría, desarrollo e implantación de proyectos de incorporaciónde contenidos de sistemas municipales y la colaboración y participación en proyectos de integración deservicios verticales.

2.1 Infraestructura y redes de comunicaciones

La ciudad inteligente se sustenta en una completa red comunicaciones accesibles a todos los agentes quela constituyen que permita la captación y transmisión de grandes volúmenes de datos y la comunicación yconectividad de personas y sistemas.

El Ayuntamiento de Logroño ha diseñado una estrategia de despliegue de infraestructuras basada en el usoeficiente y evolutivo de los recursos para completar una red de comunicaciones capaz de vertebrar la ciudade integrar las diferentes tecnologías que permiten la conexión de sensores, dispositivos y edificios que haceposible implementar el resto de los sistemas.

En paralelo con despliegues realizados en otros contratos municipales, este contrato incluye el suministro ydespliegue de los elementos especificados en el Anexo A del presente Pliego que incluye detalle sobre elestado actual y las características y especificaciones de las infraestructuras y las redes de comunicación,que, de forma general, se encuadran en las siguientes áreas:

1. Completar el despliegue de fibra óptica municipal.

2. Renovación del sistema actual de cámaras de tráfico.

3. Equipamiento y soporte a la conectividad 3G/4G.

5


4. Completar el equipamiento necesario para establecer en el Centro de Control Integral (sito en lacalle Obispo Bustamante nº 3) la futura teleoperación única para todos los servicios y para laatención a la ciudadanía.

2.2 Plataforma de Gestión integral

La plataforma de gestión integral constituye la base tecnológica de la ciudad y ofrece un conjunto demódulos de gestión comunes a los servicios que se integran y un conjunto de soluciones, soportadas visualy funcionalmente en la cartografía, que facilitan una visión global y una gestión integral de la ciudad cuyosdestinatarios principales son:

La Administración, para el control de la gestión y la toma de decisiones.

El ciudadano, para la mejora de la calidad de los servicios urbanos que recibe.

Los prestadores de servicios urbanos, para la mejora de los propios servicios urbanos.

El sector local TIC's, para la promoción de la innovación, la cooperación y el desarrollo de nuevosnegocios.

Además, La Plataforma dará soporte tecnológico al Centro de Control Integral que se configura como unsistema que da respuesta a las averías, demandas, quejas, o servicios que requieren los ciudadanos deLogroño y apoya a los servicios municipales en el desarrollo de sus funciones, contando para ello con losrecursos existentes en la Plataforma Smart Logroño.

El Anexo B del presente Pliego incluye detalle sobre el características y capacidades de la Plataforma deGestión que deben cumplir las soluciones ofertadas.

3 Duración del contratoEl contrato tendrá una duración de 4 años contados a partir de la firma del acta de inicio de la prestación delos servicios.

Todas las infraestructuras, suministros, equipamiento hardware, software y desarrollos a medida, creados eimplementados durante la vigencia del mismo y sus correspondientes licencias pasarán a propiedad delAyuntamiento de Logroño desde su instalación, puesta en servicio o recepción, considerándose los mismosamortizados en valor en la vigencia del contrato.

6


4 Presupuesto de licitaciónEl valor estimado del presente contrato asciende a la cantidad total de 2.392.056,20 € IVA incluido (base de1.976.905,96 €; IVA 415.150,24 €), conforme al siguiente desglose por anualidades y prórrogas.

(*) Cálculos realizados para un inicio de contrato estimado para el 1 de febrero de 201 7

4.1 Presupuesto global

4.2 Presupuesto por partidas

7

Total

Concepto Partida Contrato

G1 92020 21999 65.696,48

G1 92020 22799 1.360.000,00

G2 92020 63699 365.579,72

G2 92020 64199 600.780,00

2.392.056,20

Servicios y mantenimiento de la Infraestructura Conectividad 3G/4G

Servicios asociados al Software de la Plataforma de Gestión: configuración, parametrización, puesta en marcha, evolución y mantenimiento.

Red de Fibra Óptica para sensórica Dotación Call Center y desarrollo del sistema 010 Dotación de una nueva infraestructura de servidores para las cámaras de vídeo Equipamiento de comunicaciones 3G/4G para la red de sensórica

Software principal de la plataforma de gestión (540000). Programa de quejas y sugerencias (60780)

Anualidad Base 21% IVA TOTAL

2016 763.644,40 160.365,32 924.009,72

2017 278.768,27 58.541,34 337.309,61

2018 303.315,39 63.696,23 367.011,62

2019 303.315,39 63.696,23 367.011,62

2020 303.315,39 63.696,23 367.011,62

2021 24.547,12 5.154,89 29.702,01

1.976.905,96 415.150,24 2.392.056,20

Periodo de ejecución del

Contrato


5 Pago del PrecioEl pago del suministro y despliegue de infraestructuras y redes de comunicación y de la implantación de laPlataforma de software se realizará en los siguientes términos:

1. INFRAESTRUCTURA Y REDES DE COMUNICACIÓN:

Se admitirá la realización de actas de recepción parciales tras el cumplimiento de los hitosestablecidos en el Anexo A del Pliego de Prescripciones Técnicas. El pago se realizará tras la firmade las Actas de Recepción correspondientes:

Hasta un máximo de 323.229,72 € de la 92020 63699 con cargo al ejercicio 2016 que incluyelos siguientes conceptos:

59,90 % a la recepción del Equipamiento de electrónica de Red CE primarios ysecundarios.

18,76 % a la recepción del Equipamiento e integración de las cámaras de control detráfico.

21,34 % a la recepción Equipamiento del sistema de atención telefónica (call center eintegración con sistema 010).

Hasta un máximo de 42.350,00 € de la 92020 63699 por cuartas e iguales partes en losejercicios 2017, 2018, 2019 y 2020 a la recepción del Equipamiento de comunicaciones3G/4G para la red de sensórica.

El mantenimiento de comunicaciones 3G/4G se realizará mediante facturas mensuales tras larealización de los servicios de conformidad para el Ayuntamiento, siendo su importe los reseñadosen la partida 92020 21999.

2. PLATAFORMA DE GESTIÓN INTEGRAL:

Implantación del conjunto de productos software que conforman la Plataforma de Gestiónintegral y el sistema de quejas y sugerencias. (92020 64199).

El pago se realizará tras la firma del Acta de Recepción correspondiente según laplanificación establecida.

40% a la recepción del proyecto piloto de verificación.

60% a la recepción definitiva de la Plataforma.

Las actividades de consultaría, soporte a la operativa gestión, configuración, programaciónespecifica, evolución y mantenimiento de la Plataforma de Gestión (92020 22799).

El pago se realizará:

A a la recepción del proyecto piloto de verificación se facturará la parte proporcional detiempo transcurrido desde el inicio del contrato.

A la recepción definitiva de la Plataforma se facturará la parte proporcional de tiempotranscurrido desde la recepción del proyecto piloto de verificación.

La cantidad restante, restante en facturas mensuales conformadas por los serviciosmunicipales competentes, tras la prestación de los servicios de conformidad.

Así, de acuerdo con los plazos indicados en el PPT, la primera factura por este conceptocubriría los primeros 4 meses, la segunda los siguientes 4 meses y el resto en facturasmensuales.

6 Plazo de garantíaA la finalización del contrato empezará a contar un plazo de garantía de UN AÑO.

En el caso de suministros, infraestructuras y comunicaciones la garantía de los elementos suministrados secomputará a partir de la fecha expresada en la correspondiente acta de recepción y será de un mínimo deDOS AÑOS si no tiene especificada otra mayor distinta.

8


7 Ampliaciones y Modificaciones del contratoNo están previstas ampliaciones o modificaciones del contrato.

8 Responsable del contratoPor parte del Ayuntamiento y conforme a lo estipulado en el artículo 52 del TRLCSP, se designará unResponsable del contrato al que corresponderá supervisar la ejecución del contrato, adoptar las decisionesy dictar las instrucciones necesarias con el fin de asegurar la correcta realización de las prestacionespactadas.

Este responsable contará con el apoyo de la Comisión de Desarrollo que se describe a continuación.

8.1 Comisión de Desarrollo de la Plataforma Smart Logroño

Al inicio del contrato se creará una Comisión de Desarrollo, como órgano de seguimiento y gestión delproyecto de Plataforma “Smart Logroño” y coordinación con los servicios de la Plataforma.

La Comisión de Desarrollo tendrá un carácter abierto para que su estructura y operativa pueda adaptarse entodo momento a las necesidades concretas de las actuaciones a realizar. Así, para las decisiones yactuaciones estratégicas, incorporará los responsables técnicos y políticos que se consideren oportunos.Del mismo modo, el número y composición de miembros que la integran se irá adaptando/ampliando enfunción del ámbito y necesidades que surjan en los distintos planes de integración de los ServiciosVerticales.

La Comisión de Desarrollo, si así lo estima conveniente, podrá disponer la colaboración del adjudicatario ysu equipo multidisciplinar de soporte tecnológico y consultoría para realizar las tareas encomendadas,estableciendo en cada caso los recursos, reuniones, metodología y temporalidad necesarias.

El adjudicatario deberá proponer un equipo de trabajo acorde con la oferta realizada designando, al menos,un director de proyecto y un director/responsable técnico de los trabajos de cada área de actuación.

La Comisión de Desarrollo será un órgano de apoyo al responsable del contrato en las siguientescompetencias:

Coordinar y realizar el seguimiento, control técnico y económico de los proyectos y actuaciones arealizar en el ámbito del presente contrato.

Evaluar la consecución de los distintos objetivos y el impacto socioeconómico de los proyectos yactuaciones realizadas.

Verificar el cumplimiento y calidad de los productos obtenidos.

Verificar la planificación, disponibilidad de recursos, coordinación y seguimiento de las actividadesa realizar durante la duración del contrato, con especial dedicación en la fase inicial deimplantación de la Plataforma de Gestión y la elaboración, ejecución y seguimiento de un PlanEstratégico de Mejora e Integración para la transformación de los servicios municipalespersiguiendo objetivos de eficiencia, sostenibilidad e innovación y de los distintos Planes para laintegración de servicios verticales.

Seguimiento y control técnico y económico de los proyectos y actuaciones a realizar.

Durante la ejecución de los trabajos objetos del contrato, el adjudicatario se compromete, en todo momento,a facilitar a las personas designadas por la Comisión de Desarrollo, la información y documentación queéstas soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan lostrabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos yherramientas utilizadas para resolverlos.

Para la prestación de los servicios incluidos en el contrato, el adjudicatario se compromete a formaradecuadamente al personal asignado y proporcionar el soporte técnico necesario para las tareas de soportey gestión y las necesidades de evolución de la Plataforma.

9


9 Obligaciones esencialesTendrán la consideración de incumplimientos de obligaciones esenciales y podrán dar lugar a la “resolucióndel contrato” las siguientes:

La obtención y uso de información para fines distintos de los expresados en el presente Pliego.

El abandono, incumplimiento o suspensión de cualquiera de las prestaciones o servicioscontratados sin causa justificada.

La no aportación del personal mínimo exigido y necesario para la realización de los trabajos yprestaciones objeto del contrato, así como el incumplimiento de sus horarios.

Pérdida o alteración sustancial durante la duración del contrato, por causas imputables aladjudicatario, de las especificaciones técnicas establecidas en el PPT sobre la arquitectura,características y capacidades técnicas de la Plataforma.

La finalización de la implantación del proyecto piloto en fecha posterior a la establecida, elincumplimiento de las especificaciones del proyecto o la imposibilidad cumplimiento del objetivo deverificar que la plataforma implantada responde a las especificaciones técnicas establecidas en elpliego, siempre que sea por causa imputable al adjudicatario.

La manipulación o falsedad de los datos del sistema de gestión de incidencias o de los informesque deban elaborarse.

La comisión de dos incumplimientos muy graves en un periodo de un año.

La comisión de agresiones o mobbing a ciudadanos, compañeros, subordinados, superiores ofuncionarios municipales.

10 Criterios de selecciónCon el objeto de adjudicar el servicio a un Contratista con las garantías precisas para el adecuadocumplimiento de las obligaciones que se especifican en el presente pliego de condiciones, las condicionesmínimas de solvencia técnica que se exigen a los licitadores para optar a la adjudicación y que deberánacreditar suficientemente, son las siguientes:

Haber realizado en los últimos cinco años al menos en 2 contratos relacionados con el objeto delpresente contrato o prestar en la actualidad un servicio de soporte y consultoría de una plataformade gestión integral con una antigüedad superior a dos años.

Haber realizado en los últimos cinco años al menos 2 contratos relacionados con la integración de3 o más de los siguientes aspectos en ciudades de más de 100.000 habitantes:

Sensorización.

Presentación visual de datos mediante mapas.

Semántica de la ciudad.

Seguridad y gestión de grandes volúmenes de datos.

Análisis de Datos.

Disponer dentro del equipo de trabajo propuesto para realizar la implantación y puesta en marchade la plataforma de gestión integral de:

Al menos 6 personas con titulación universitaria superior en las áreas de informática ytelecomunicaciones que tengan experiencia en contratos relacionados con la integración de 3o más de los aspectos detallados en el punto anterior.

Personal con certificación o experiencia demostrable de más de tres años en:

Tecnología GIS Smallworld con experiencia en los últimos tres años en al menos 2proyectos relacionados con el GIS Smallworld.

Hardware y software de los equipos CE.

10


11 Criterios de adjudicaciónA continuación se indican los criterios para la valoración y adjudicación de ofertas:

Criterios objetivos 51 Puntos

1. Oferta económica 51

Criterios subjetivos 49 Puntos

1. Infraestructuras y Redes de Comunicación 4

2. Planificación de la ejecución e implantación del contrato 7

3. Arquitectura y características de la Plataforma 5

4. Componentes de la Plataforma 14

5. Consultoría y Soporte Tecnológico 6

6. Acuerdos de Nivel de Servicio 3

7. Plan de Formación y Transferencia Tecnológica 4

8. Continuidad y Evolución de la Plataforma 4

9. Verificación de la Plataforma 2

11.1 Criterios objetivos

La adjudicación se realizará a la oferta que resulte más conveniente a los intereses municipales, conforme ala valoración de las ofertas económicas.

11.1.1 Oferta económica

La valoración de la oferta económica se efectuará de conformidad con la fórmula señalada en el pliego decláusulas administrativas particulares.

11.2 Criterios subjetivos

Para su valoración, la oferta debe contener la descripción de la solución propuesta por el licitador para cadauno de los criterios subjetivos no cuantificables mediante la aplicación de fórmula.

Los criterios subjetivos seleccionados se consideran los más adecuados para seleccionar la propuestatécnica que permita, en el menor tiempo posible, conseguir con éxito los objetivos del contrato y disponer deuna plataforma de gestión integral que ofrezca un repositorio de datos y de funcionalidades comunes quefacilite un cambio en el modelo de gestión de los servicios municipales, incremente la capacidad deinteroperar con organismos externos y permita un enfoque Big Data y Open Data para promover en laciudadanía la participación, transparencia e innovación. Estos criterios se centran la valoración de laidoneidad y calidad técnica de las propuestas, en el cumplimiento de las características especificadas, en ladefinición, estructura y flexibilidad del equipo de soporte y consultoría, en la gestión de calidad ymetodología para el desarrollo de los proyectos, en la propuesta de formación y transferencia tecnológica alpersonal municipal, en el aseguramiento de la evolución y continuidad de la plataforma y en las capacidadesfuncionales de los distintos módulos componentes y su grado de cohesión e integración.

11


Instrucciones sobre la documentación a presentar

1. La documentación debe ser clara y relevante, contener detalle suficiente y debe mantener elorden y la estructura de criterios subjetivos propuesta.

2. Toda la documentación, incluidos índices, anexos, planos,... se debe presentar además en formatoelectrónico tipo PDF, o cualquier otro formato legible mediante software de libre distribución ydeberá permitir realizar búsquedas exitosas por texto.

3. A efectos de facilitar la verificación de características técnicas, en la documentación referente ainfraestructuras y redes de comunicación, se deberán incorporar como anexo, en formatoelectrónico tipo PDF, o cualquier otro formato legible mediante software de libre distribución, lashojas de especificaciones del fabricante de todos los elementos suministrados, tanto hardwarecomo software, dentro del presente procedimiento.

Esta documentación anexa no se considerará a efectos del cálculo del número máximo depáginas, si hubiera un límite establecido en este apartado.

4. A efectos de proporcionar información relevante que aporte valor añadido sobre otras posiblesofertas, en la documentación referente a la plataforma de gestión integral, se podrá incluir comoanexo, en formato electrónico tipo PDF, o cualquier otro formato legible mediante software de libredistribución, las especificaciones de productos, herramientas, metodologías, etc. que secorrespondan con la documentación oficial del fabricante o suministrador.

A modo de ejemplo, si la metodología de desarrollo propuesta es Métrica v3, el detalle de la ofertaen ese apartado incluirá consideraciones de la elección, ventajas que puede aportar, uso oadaptación de la misma, etc. y, si procede, se incluirá como anexo la documentación técnicaoficial.


5. A efectos de verificar la existencia, apariencia y funcionamiento de interfaces, módulos oelementos software ya desarrollados, el adjudicatario podrá acompañar la descripción decaracterísticas y especificaciones de la oferta con enlaces a versiones “demo” en sistemas webque permitan valorar estos aspectos. En estos casos, se incluirá en la oferta, indicando el usuarioy contraseña o mecanismo habilitado, la url exacta de acceso y, además, se anexará documentoque incluya la impresión de las distintas pantallas a valorar. Las versiones “demo” deben permitirinteractuar y no se tendrán en cuenta presentaciones tipo "PowerPoint". Las versiones “demo”deberán estar operativas desde la fecha de finalización de la presentación de ofertas hasta lafecha de adjudicación del contrato.


6. La documentación utilizará un tipo de letra Arial 12 o similar.

7. No se establece un número máximo de páginas. Se deberán seguir los criterios indicadosanteriormente sobre la documentación principal y relevante y los anexos.

8. Atendiendo a las consideraciones anteriores, la documentación de las ofertas se estructura en dosbloques:

un bloque principal que debe mantener la estructura y orden propuesto en el apartado decriterios subjetivos y que contendrá la información relevante y significativa de la propuesta.

un bloque de anexos que contendrá información complementaria a la anterior comocaracterísticas técnicas de equipamiento o productos, etc. según se ha indicadoanteriormente.

Se indica a continuación detalle de la documentación a presentar y los aspectos a valorar para cada uno delos criterios subjetivos propuestos.

12


11.2.1 Infraestructuras y Redes de Comunicación

Máximo 4 puntos.

En este apartado, la documentación debe incluir el Plan de despliegue de infraestructuras y redes decomunicación acorde a las especificaciones descritas en el PPT. La documentación mínima a presentarincluye:

Inventario detallado de los equipos hardware a suministrar dentro del presente proyecto,incluyendo para cada uno de ellos la cantidad a suministrar y el código de referencia del fabricantedel mismo para su correcta identificación

Inventario detallado de elementos y licencias software a suministrar dentro del presente proyectoincluyendo para cada uno de ellos la cantidad a suministrar y el código de referencia del fabricantepara su correcta identificación

Esquema lógico de la ampliación de red de fibra óptica a suministrar

Esquema de arquitectura física y lógica del suministro realizado para la integración de las cámarasde vigilancia de trafico

Esquema físico y lógico del sistema de atención presencial, telefónico y vía chat y correoelectrónico suministrado, incluyendo todos los componentes a suministrar y el papel quedesempeñe cada uno de ellos en la solución aportada.

Cálculos estimados de consumo de entrada/salida de disco indicando, al menos, IOPS y tasas detransferencia pico y media de los sistemas centrales suministrados requeridos para el correctofuncionamiento de la solución y su relación con los sistemas actuales sobre los que se apoya.

Para realizar la valoración de este apartado, se tendrá en cuenta lo siguiente:

a) Red de comunicaciones del sistema .......................................................... hasta 2 puntos.

Se valorará la solución propuesta, la flexibilidad de la red para transportar diferentes servicios, lacapacidad de ampliación de la solución propuesta y la facilidad en la gestión y configuración.

b) Integración de cámaras de tráfico............................................................... hasta 0,5 puntos.

Se valorará la solución propuesta, la integración con el sistema actual y la flexibilidad de lossistemas de visualización.

c) Servicio central de atención........................................................................ hasta 1,5 puntos.

Se valorará el nivel de integración con la plataforma y con el sistema ToIP existente y laVersatilidad y funcionalidades del interfaz cliente del sistema.

11.2.2 Idoneidad y Planificación de la ejecución e implantación delcontrato

Máximo 7 puntos.

En este apartado, la documentación debe incluir:

a) Justificación de la idoneidad de la solución propuesta para el cumplimiento de los objetivos yrequisitos exigidos en el PPT.

Se valorara la claridad y el rigor de la argumentación del planteamiento general y la coherencia delconjunto de las propuestas que forman parte de la oferta presentada.

Puntuación máxima 1 puntos.

b) Plan de Implantación: El licitador deberá presentar una planificación temporal de las diferentestareas a desarrollar tomando como base las especificaciones realizadas en el apartado de Hitos y

13


Planificación del PPT. El Plan de Implantación debe establecer claramente las fases, actuaciones,requerimientos y plazos para disponer de la misma y los planes específicos de puesta en marchade los distintos elementos que la integran. La presentación de la planificación se llevará a cabo pormedio de la metodología PMP de PMBOK® del PMI®, o similar.

En especial, se valorará el detalle, rigor y coherencia en la planificación de las actividades, laexistencia de mecanismos que faciliten el control y seguimiento de las tareas, así como la correctaidentificación de los puntos más críticos del proyecto y la reducción del plazo previsto deimplantación y puesta en marcha basada en la reutilización e incorporación de desarrollos yaexistentes.


c) Plan de Calidad: la oferta debe describir el plan de calidad propuesto por el adjudicatario y lasmedidas a adoptar para asegurar la calidad en el presente proyecto.

En especial, se valorará la experiencia y conocimiento del adjudicatario en las actuacionespropuestas y la adecuación, detalle y rigor de la propuesta para la consecución de los objetivos delproyecto.


d) Metodología de Gestión de proyectos: la oferta debe justificar la propuesta de metodología degestión de proyectos para las distintas actividades y fases, destacando los aspectos másrelevantes y significativos y su contribución al éxito del proyecto.

En especial, se valorará la adecuación, detalle y rigor de la propuesta para finalizar con éxito losrequerimientos del presente pliego, las aportaciones metodológicas más allá de las descripcionesgenerales, la implementación de esta metodología en la estructura y operativa del equipo y el usode herramientas que contribuyan a la gestión del proyecto.


11.2.3 Arquitectura y características de la Plataforma

Máximo 5 puntos.

En este apartado, la documentación debe incluir:

a) Descripción general, justificación y coherencia tecnológica de la arquitectura ofertada respecto alas necesidades expuestas para la Plataforma de Gestión Integral.

El cumplimiento de las especificaciones del PPT en este apartado se ha identificado comorequisito imprescindible en el Anexo E. Se valorarán aspectos y características adicionales que seincluyan y que redunden en una mejora técnica de la solución propuesta, en especial:

La claridad y el rigor de la argumentación y la adecuación de la arquitectura de la solucióncomo soporte de la captación, análisis e integración de datos para la gestión integral de losservicios urbanos, el observatorio y seguimiento de la ciudad, la integración con los serviciosmunicipales y las relaciones con el ciudadano.

La construcción de la plataforma propuesta sobre un conjunto limitado y optimizado detecnologías para favorecer su mantenimiento y evolución y la transferencia de conocimiento.


b) Características técnicas: la oferte debe argumentar el cumplimiento de las especificaciones delPPT en este apartado.

Además del cumplimiento de las características indicadas, se valorarán:

La adecuación de las características y capacidades adicionales de la plataforma de gestiónintegrada que redunden en una mejora técnica de la solución propuesta.

14


La capacidad de plataforma para trabajar con contenidos de las principales redes sociales,como, por ejemplo, Twitter y proporcionar acceso vía dispositivos móviles a contenidos de lamisma.

La facilidad de la plataforma para crecimiento horizontal en función de la evolución de lasnecesidades.


11.2.4 Componentes de la Plataforma

Máximo 14 puntos.

En este apartado, la documentación debe incluir la descripción de características, especificaciones,capacidades de integración, desarrollo y justificación de los componentes de la solución propuesta para darrespuesta a las especificaciones indicadas en los apartados de servicios básicos y servicios avanzados.

Se valorará el grado de cumplimiento y coherencia con las especificaciones del PPT, la claridad de laexposición, en especial la aportación de esquemas, imágenes y versiones "demo” que faciliten lacomprensión de las funcionalidades, características y operativas descritas, la adecuación y contribución delos componentes de la propuesta a la consecución de los objetivos del contrato, el grado de desarrollo y lascapacidades implementadas que faciliten y acorten su puesta en marcha, la integración e interconexión confuncionalidades y capacidades de la propia Plataforma, y el rigor y detalle de la solución propuesta enaspectos relacionados con:

a) Servicios Básicos: El cumplimiento de las especificaciones del PPT en este apartado se haidentificado como requisito imprescindible en el Anexo E. Se valorarán aspectos y característicasadicionales de los servicios básicos que se incluyan y que redunden en una mejora técnica de lasolución propuesta.

Servicios Administración y Gestión de la Plataforma: la oferta debe enumerar y describir lainterfaz y los servicios básicos destacando las funcionalidades y características que redundenen minimizar el tiempo de implantación y un mejor funcionamiento de la Plataforma.

Además de lo indicado, se valorará la existencia de una API abierta tipo REST para eldesarrollo de funcionalidades de gestión de la Plataforma.

Servicio de Integración e Interoperabilidad: la oferta debe enumerar y describir lasfuncionalidades y características de la propuesta que redunden en una mayor integración eInteroperabilidad.

Además de lo indicado, se valorarán las capacidades y características que faciliten laintegración e interoperabilidad entre los componentes de la propia plataforma y con otrasplataformas.

IoT (Internet of Things: Internet de las cosas): Capacidad de Integración y gestión desensores, actuadores y dispositivos. Descripción de los procesos de captación, normalizacióny almacenamiento de grandes volúmenes de datos heterogéneos: sensores y dispositivos,indicadores, inventarios, sistemas municipales, etc. y su puesta a disposición para el resto defuncionalidades de la plataforma.

Además de lo indicado, se valorará especialmente la capacidad y sencillez de la soluciónpropuesta para la integración y gestión de sensores, actuadores, dispositivos del ámbito de laciudad, indicadores de gestión y otras fuentes de datos identificadas y la capacidad deconocimiento en tiempo real de los sistemas integrados.

Servicio de Almacenamiento: la oferta debe enumerar y describir la arquitectura de soluciónpara las distintas necesidades de almacenamiento de datos según su disponibilidad, volumeny tipo de contenido especificado en el PPT y debe justificar y optimizar los sistemas dealmacenamiento propuestos en cada caso y contener una tabla que indique como mínimo,para los distintos tipos de información, su correspondiente sistema de almacenamiento.

15


Además de lo indicado, se valorará adecuación y optimización de los recursos propuestos y lapropuesta sobre un conjunto limitado y optimizado de sistemas de almacenamiento parafavorecer su mantenimiento y evolución y la transferencia de conocimiento.

Servicio de Analytics Data (AD) y Business Intelligence (BI): la oferta debe enumerar ydescribir las funcionalidades y características de la propuesta para dar respuesta a lasespecificaciones indicadas sobre el análisis de información, integración e interpretación dedatos que generen valor añadido a la información y su puesta a disposición para los serviciosavanzados.

Además de lo indicado, se valorará especialmente:

La capacidad de análisis y facilidad para generar información de valor añadida:indicadores, cuadros de mando, etc.

El incremento de funcionalidades y capacidades de análisis y predicción.

La inclusión adicional en la oferta de reglas, informes, indicadores y cuadros de mandoya elaborados que sean de interés para los objetivos del contrato.

La capacidad de la Plataforma para incluir procesos ETL existentes en el Ayuntamientobasados en PDI Pentaho 4.3.

La capacidad de la Plataforma para implantar un enfoque de la gestión de la calidad delos servicios a través del seguimiento de indicadores, con una visión global y transversal.

Servicio de Georreferenciación: la oferta debe describir la solución propuesta para la gestióngeorreferenciada de los contenidos y la integración con el GIS municipal según se especificaen el apartado correspondiente.

Además de lo indicado, se valorará especialmente la capacidad de la propuesta paragestionar información geoposicionada agrupada en áreas, distritos y zonas de gestión, lavisión y enfoque abierto de la solución y la integración en ambos sentidos con el sistema GISmunicipal.


b) Servicios Avanzados: la oferta debe incluir detalle de la propuesta, características, interfaces paradar respuesta a las necesidades identificadas en los distintos ejes en los que se agrupan losservicios avanzados

Gestión de Servicios Verticales/Horizontales: capacidades propuestas para satisfacer lasnecesidades comunes de los futuros servicios verticales a integrar y las necesidades del CCI.

Además de lo indicado, se valorará especialmente:

El rigor, detalle y adecuación de la solución propuesta a las características yespecificaciones indicadas en el PPT para los distintos sistemas de gestión.

Las capacidades de integración de los sistemas entre si, con otros sistemas municipalesy con los futuros servicios a integrar y la utilización de funcionalidades y contenidoscomunes de la Plataforma.

El alcance de la información de gestión aportada a la plataforma, las capacidades para lavisión georreferenciada de la misma y la elaboración de informes, indicadores de gestióny calidad, cuadros de mando y su integración en la gestión de la ciudad y en el catálogoOpen Data.

La ampliación de desarrollos comunes que faciliten y agilicen y simplifiquen la integraciónde futuros servicios verticales.

La incorporación de fuentes de información adicional de interés en la gestión de alertas eincidencias.

La integración de la gestión de atenciones con el equipamiento y dispositivos del CCIpara la teleoperación única y la atención a ciudadanos.

16


El rigor y detalle de la propuesta para la gestión de la capa de negocio medianteprocedimientos almacenados y la coherencia del modelo de datos planteado con lasespecificaciones indicadas en la gestión de quejas y sugerencias.

La simplicidad de la operativa en la gestión de afecciones en la vía pública y lacapacidad de integración no intrusiva con los sistemas de gestión actual.

El alcance de los contenidos existentes a incorporar a la Plataforma.

Gobierno y Gestión de la Ciudad: la oferta debe incluir detalle de la interfaz y de la capacidadde interactuar con todos los elementos y contenidos de la Plataforma, el aprovechamiento delas últimas herramientas disponibles y el sistema GIS para el observatorio de la ciudad queincluye el control, inventario y motorización del estado de recursos, indicadores de calidad ycuadros de mando que proporcionan información para el seguimiento de los servicios y latoma de decisiones en base a múltiple información recogida y elaborada en la plataforma.

Además de lo indicado, se valorará especialmente la facilidad de manejo de la interfaz, lacapacidad y facilidad de interactuar con todos los contenidos de la Plataforma, el grado deavance en el desarrollo de la solución propuesta y las facilidades aportadas para suvaloración.

Integración con los Sistemas o Aplicativos Municipales y Sistemas Externos: la oferta debeenumerar y detallar las capacidades y las integraciones incluidas en la propuesta.

Además de lo indicado, se valorará la facilidad y el alcance de la integración en ambossentidos de información y funcionalidades entre la Plataforma y los Sistemas Municipales.

Relación con el ciudadano: la oferta debe describir las características, funcionalidades,interfaces, integraciones del Portal Smart Ciudad y el Portal Open Data.

Las capacidades de gestión del Catálogo Open Data y funcionalidades de búsqueda,visualización, suscripción y promoción de LAB's del Portal Open Data y la capacidad deinterrelación con los ciudadanos.

Además de lo indicado, se valorará especialmente la solución y las funcionalidadespropuestas para el Portal Smart Ciudad, la facilidad de gestión del Catálogo Open Data, lasfuncionalidades de búsqueda, visualización y suscripción del Portal Open Data, la facilidad ycapacidad de adaptación a los formatos de exportación indicados, el alcance de loscontenidos del Catálogo, la capacidad de interrelación con los ciudadanos y la facilidad paraproporcionarles mapas y contenidos de la Plataforma. También se valorarán las facilidades yutilidades de la solución para la promoción de la innovación y el emprendimiento.


11.2.5 Consultoría y Soporte Tecnológico

Máximo 6 puntos.

a) En este apartado, la documentación debe incluir la descripción general de la propuesta deconsultoría y soporte tecnológico, con detalle de la organización y disponibilidad de los recursoshumanos del adjudicatario, incluyendo estructura, perfiles, cualificación, dedicación ydisponibilidad del personal, metodología y herramientas utilizadas y nivel de servicio en las tareasde soporte tecnológico de la Plataforma de Gestión Integrada y de los servicios integrados.

Se valorará el detalle, rigor y adecuación de la propuesta a las especificaciones indicadas en elPPT, en especial:

La organización de los recursos humanos y desarrollo de tareas operativas y evolución de laplataforma, el nivel de servicio, la flexibilidad, cercanía y disponibilidad de recursoscomprometidos para las labores de consultoría y asistencia en la resolución de las cuestionesque se plateen.

17


El uso de metodología ágiles de gestión de los proyectos, que garanticen una integraciónrápida y exitosa, la implementación de esta metodología en la estructura y operativa delequipo.

La existencia de procedimientos adecuados y el uso de herramientas y funcionalidades de lapropia plataforma que incrementen el grado de automatización de las actuaciones y facilitenla prestación y seguimiento del servicio prestado.

Incremento en la composición del equipo de soporte estable sobre el equipo mínimo indicadoen el pliego que aporte valor significativo al servicio o mejora en la prestación de los horariosestablecidos en el pliego.

La flexibilidad del servicio y la disponibilidad para ajustar los recursos a lo largo del proyectoen base a las necesidades de los proyectos.


11.2.6 Acuerdos de Nivel de Servicio (ANS)

Máximo 3 puntos.

En este apartado, la documentación debe incluir la propuesta de estructura y contenido del catálogo deindicadores de servicio de la Plataforma y la planificación temporal para su implementación durante lavigencia del contrato.

Se valorará el detalle, rigor y adecuación de la propuesta a las especificaciones indicadas en el PPT, enespecial:

El incremento en el número de indicadores de servicio propuesto para la Plataforma.

El adelanto en los plazos de implantación del catálogo de indicadores.

La organización y mejoras técnicas del ANS de Gestión de Incidencias y la integración en laPlataforma de los mecanismos de control y seguimiento.

La mejora en los objetivos y número de Indicadores del ANS.

11.2.7 Plan de Formación y Transferencia Tecnológica

Máximo 4 puntos.

En este apartado, la documentación debe incluir la propuesta del adjudicatario para dar respuesta a lasnecesidades especificadas en materia de formación y transferencia de la Plataforma Smart Logroño:

a) Plan de Formación: propuesta del adjudicatario para garantizar el conocimiento y manejo de laplataforma por parte del personal municipal asignado. Se incluirán perfiles, contenidos, duración ytemporalidad, etc. de los cursos y actividades a realizar.

Se valorará el rigor, detalle, alcance y adecuación del plan de formación para garantizar elconocimiento de los gestores y técnicos municipales designados.


b) Plan de Transferencia Tecnológica: propuesta del adjudicatario para conseguir la gestiónautónoma de la Plataforma de Gestión Integrada y el desarrollo de nuevas funcionalidades porparte del personal municipal

Se valorará en especial:

El grado de coherencia y rigor del Plan de Transferencia Tecnológica propuesto paraconseguir la gestión autónoma de la Plataforma y el desarrollo de nuevas funcionalidades porparte del personal municipal.

18


Las actuaciones propuestas y recursos comprometidos para el trasvase de conocimiento alpersonal municipal y la proximidad y disponibilidad de los canales de comunicaciónpropuestos.


11.2.8 Continuidad y Evolución de la Plataforma

Máximo 4 puntos.

En este apartado, la documentación debe detallar las medidas para garantizar la continuidad de laplataforma, incluir las consideraciones y compromisos de la propuesta en materia protección de datospersonales, seguridad y confidencialidad de la información y la propuesta soporte a la evolución de laPlataforma.

Se valorará el rigor, detalle y grado de cumplimiento y coherencia con las especificaciones del PPT, lasmedidas aportadas para garantizar la continuidad y evolución de la Plataforma, en especial.

a) Continuidad de la Plataforma: puntos fuertes de la solución propuesta, identificación de riesgos ydescripción de los compromisos y medidas a adoptar para garantizar la continuidad tecnológica dela plataforma.

Además de lo indicado, se valorarán especialmente los compromisos adquirido por el adjudicatarioy la capacidad de cambio de modelo de la plataforma (evolución a modelo “in cloud”) sin coste nipérdida de funcionalidad.

Puntuación máxima 1,5 puntos.

b) Actualización del software de la Plataforma: especificación de procedimientos, estrategias,mecanismos y frecuencia de actualización del software de la plataforma suministrada.

Además de lo indicado, se valorará especialmente la existencia y coherencia de losprocedimientos y la integración y seguimiento de las actuaciones en el servicio de soporte de laPlataforma.

Puntuación máxima 0,5 puntos.

c) Integración de servicios verticales: propuesta de organización, operativa y capacidad deladjudicatario para las tareas de consultoría y ejecución de proyectos de integración de futurasverticales.

Además de lo indicado, se valorará en especial la capacidad de consultoría, medios empleados ycolaboración para la planificación y desarrollo de los proyectos de integración, los puntos fuertesde la solución para garantizar la integración de nuevas funcionalidades y servicios, desarrolladospor el Ayuntamiento de Logroño o por terceros, así como la facilidad y capacidad de interoperacióny reutilización de funcionalidades y la existencia de una API abierta y de un SDK (SoftwareDevelopment Kit).

Puntuación máxima 1 punto.

d) Evolución de contenidos: propuesta de captación inicial y ampliación futura de contenidos de laPlataforma.

Además de lo indicado, se valorará el alcance inicial de los contenidos con relación directa en laconsecución de los objetivos del proyecto y la propuesta y planificación de incorporación decontenidos durante la vigencia del contrato.

Puntuación máxima 1 punto.

19


11.2.9 Verificación de la Plataforma

Máximo 2 puntos.

En este apartado, teniendo en cuenta las especificaciones indicadas en el apartado 13.12 del PPT, ladocumentación debe incluir la visión y propuesta del adjudicatario para el desarrollo del proyecto piloto quepermita verificar el correcto funcionamiento de las capacidades de la plataforma.

Se valorará la adecuación de la propuesta a los plazos y finalidad indicada, el grado de cumplimiento ycoherencia con las especificaciones del PPT, las propuestas y aportaciones para la verificación de lasfuncionalidades de la Plataforma y la capacidad de innovación y evolución de la propuesta superada la fasede verificación del proyecto piloto.

Todos aquellos proyectos técnicos que no superen los 27 puntos de los 49 posibles, no serántenidos en cuenta en la valoración oferta económica.

Logroño, a 6 de septiembre de 2016

Eduardo Modrego PascualCoordinador del Grupo de Trabajo Plataforma Smart Logroño

20


ANEXO A:

INFRAESTRUCTURAS Y REDES DECOMUNICACIONES

21


12 ANEXO A: Infraestructuras y Redes de Comunicaciones

12.1 Dotación de equipos centrales

El Ayuntamiento de Logroño pondrá a disposición del suministrador de la plataforma y las verticales aintegrar los recursos que se detallan en los siguientes apartados del presente punto.

El adjudicatario deberá utilizar dichos recursos para la instalación de los sistemas (Bases de datos,servidores de aplicaciones, servidores de control, etc) que den soporte a las distintas funcionalidades de laplataforma. Como directiva general de utilización del entorno se deberán crear tantas máquinas virtualescomo sean necesarias para el correcto funcionamiento del sistema suministrado.

12.1.1 Servidores de virtualización

El sistema dispondrá de dos servidores físicos para la virtualización de las máquinas necesarias paraejecutar el entorno de plataforma y verticales.

Cada uno de estos servidores tendrá las siguientes características:

Blade Hewlett Packard BL460c Gen9 con 2 procesadores Intel Xeon E5-2630v3 (2.4GHz)

256 GB de RAM DDR4 a 2133 MHz

Adaptador HP FlexFabric 20Gb 2-port 650FLB FIO Adapter

Estos servidores dispondrán cada uno de ellos de una licencia del hipervisor de virtualización, cuyascaracterísticas serán las siguientes:

Vmware vSphere versión 5.5 o superiores

Los servidores vShpere se integrarán dentro de la infraestructura existente de vCenter para su gestión. Encaso de requerirse se podrán crear usuarios de acceso para la gestión/manejo de máquinas específicas delentorno por parte del personal de mantenimiento de la plataforma con objeto de mejorar la gestión delsistema. No obstante, el personal técnico del Ayuntamiento de Logroño deberá disponer siempre decapacidad de acceso y gestión de las máquinas creadas en este entorno.

12.1.2 Infraestructura de almacenamiento

Los servidores de virtualización indicados en el apartado anterior estará conectados mediante tecnologíaSAN (FCP o FcoE) con caminos redundantes a través de switches empresariales convergentes.

Dentro de la cabina se pondrá a disposición del entorno una capacidad de almacenamiento de:

12TB brutos en tecnología SAS 6G de 10Krpm

16TB brutos en tecnología NL-SAS 6G de 7.2Krpm

Las máquinas virtuales que se crearán para el soporte de la plataforma y verticales deberán utilizar estacapacidad de almacenamiento mediante la creación de los correspondientes discos virtuales. Las directivasgenerales de utilización se establecerán una vez adjudicado el suministro. Como orientación respecto a lautilización del almacenamiento masivo:

Se tenderá a la utilización de discos virtuales en vez de asignación física de volúmenes de lacabina

Los discos virtuales creados serán de aprovisionamiento Thin

Se tenderá a estructurar las necesidades de almacenamiento en dos niveles en función desus necesidades de IOPS y rendimiento para poder distribuir adecuadamente losrequerimientos en los dos Tier de almacenamiento disponibles

22


12.1.3 Infraestructura de conectividad

Los equipos de virtualización se encuentran conectados a la infraestructura LAN municipal mediante lastarjetas FcoE a conmutadores convergentes.

El Ayuntamiento de Logroño garantizará la conectividad a nivel IP de los servidores virtuales con el resto deinfraestructura de LAN corporativa, así como con la infraestructura de red incluida en el presente suministro.

12.1.4 Software de las máquinas virtuales

El adjudicatario deberá incluir las licencias de sistema operativo de todas las máquinas virtuales instaladas.Dichas licencias serán propiedad del Ayuntamiento de Logroño. No obstante el adjudicatario deberá tendera la utilización de licencias de software libre en los sistemas operativos de las máquinas virtuales,preferiblemente Linux en su distribución CentOS. Todas las versiones de software base de los servidoresvirtuales tenderán a utilizar plataformas de 64 bits.

En caso de ser necesaria la utilización de plataforma Windows u otro sistema operativo propietario, laslicencias del sistema operativo deberán adquirirse bajo el acuerdo Open que indicará el Ayuntamiento deLogroño. Dichas licencias de sistema operativo incluirán el servicio de Microsoft Software Assurance durantela duración del presente contrato garantizando el correspondiente soporte y actualización de versiones.

Se valorará especialmente la utilización de productos de software libre en los productos base y frameworks(desarrollo, integración, etc.) sobre los que se apoyen los sistemas que componen el presente suministro,evitando en lo posible productos que impliquen un licenciamiento por puesto, cliente o de tipo flotante, de talmanera que el Ayuntamiento de Logroño disponga de libertad para el acceso al sistema sin restricciones deutilización.

No obstante, en caso de ser necesario incluir elementos sujetos a licenciamiento, el adjudicatario deberáaportar las licencias de uso necesarias para la correcta ejecución de los servidores y clientes de laplataforma Smart Logroño. Las licencias de uso pasarán a ser propiedad del Ayuntamiento de Logroño unavez finalizado el presente contrato. Será responsabilidad del adjudicatario mantener los productossuministrados actualizados a las versiones adecuadas para el correcto funcionamiento de la plataformaSmart Logroño y los sistemas verticales.

12.1.5 Servicios de instalación

El adjudicatario será responsable de la instalación y configuración para su correcto funcionamiento de lasmáquinas virtuales utilizadas en la infraestructura de la plataforma Smart Logroño. El proceso de instalaciónde todos los elementos deberá garantizar la transferencia de conocimiento hacia el personal municipal deacuerdo a lo especificado en el correspondiente apartado del presente PPT.

Se deberá planificar antes del despliegue inicial un calendario de reuniones con el personal técnico quedesigne el Ayuntamiento de Logroño para determinar las condiciones de configuración de todos loselementos y las modificaciones indicadas en al apartado anterior. A la finalización de dichas reuniones, eladjudicatario deberá entregar un planning de ejecución del despliegue inicial teniendo en cuenta lasmodificaciones que haya podido sufrir.

El Ayuntamiento de Logroño se compromete a, de común acuerdo con el adjudicatario, a realizar ladefinición y creación de las máquinas virtuales en el entorno de virtualización descrito.

El adjudicatario estará obligado a realizar la configuración establecida por el Ayuntamiento una vezadjudicado el suministro. El adjudicatario se compromete a adaptar los datos de configuración incluidos enla oferta a las necesidades planteadas por el Ayuntamiento de Logroño siempre que dicha adaptación norepresente un incremento en el precio de los elementos suministrados. No obstante, en caso de conflicto,prevalecerá la opinión de los técnicos del Ayuntamiento de Logroño.

Se considerará que los elementos han quedado totalmente instalados y configurados en el momento en quelos mismos estén en condiciones de cumplir los requerimientos planteados en el presente pliego y se hayanadaptado adecuadamente para el servicio bajo la plataforma Smart Logroño.

23


12.2 Red de comunicaciones del sistema

El sistema global se apoyará horizontalmente sobre una red de comunicaciones multiservicio que integrarálos actuales recursos de conectividad municipales existentes, así como los ofertados por el licitador y losque puedan surgir durante la ejecución del presente contrato.

Actualmente, la red municipal se basa en los siguiente mecanismos de comunicación:

Red DMR.

Fibra óptica de propiedad municipal.

Red alquilada sobre operador de telecomunicaciones basada en tecnologías móviles y fijas (3G,4G, xDSL, FTTH, etc.).

12.2.1 Redes existentes

A continuación se detallan las infraestructuras de red multiservicio existentes.

12.2.1.1 Red DMR

El Ayuntamiento de Logroño dispone de una red de radio DMR de acuerdo a la norma ETSI - TS 102 361con multiplexación TDMA a 2 slots susceptible de ser utilizada para la transmisión de datos de futurossensores o actuadores.

El nivel de cobertura del municipio de Logroño es de un 85% incluyendo los polígonos industriales.

12.2.1.2 Tendidos de fibra óptica

Actualmente, el Ayuntamiento de Logroño dispone de una red de fibra óptica propia dentro de la cual seencuentran interconectados centros municipales y otros elementos, algunos de ellos en dominio público(cuadros de alumbrado, cámaras de control de tráfico, cuadros de señalización semafórica, etc.). El cable defibra óptica se encuentra tendido a través de canalizaciones propiedad del Ayuntamiento de Logroño ycomparten dichas canalizaciones, en parte, con los tendidos propios que dan servicio al sistema dealumbrado público y de control de movilidad.

Existen diferentes tipos de F.O. desplegada:

Fibra óptica monomodo con salto de índice de 9/125

Multimodo 50/125 y 62.5/125

Para el presente proyecto únicamente se utilizará la fibra óptica monomodo

12.2.1.3 Conectividad inalámbrica de equipos

Aquellos equipos de control o sensores que deban conectarse a la infraestructura y no sean susceptibles orecomendable conectarse mediante las redes anteriores deberán establecer su comunicación medianteredes de operadores móviles. El adjudicatario, de acuerdo a lo especificado más adelante en este pliego,deberá indicar diferentes equipos de conectividad soportados por el sistema que permita la conexión víaredes móviles de operadores.

12.2.2 Ampliaciones a la red de comunicaciones

A continuación se detallará las ampliaciones necesarias sobre la red existente descrita en los apartadosanteriores. Adicionalmente y durante la duración del contrato, el adjudicatario podrá proponer nuevos

24


equipos o soluciones tecnológicas que considere mejoras para el sistema. Dichas mejoras o cambios en elequipamiento a suministrar deberán ser aprobadas por el Ayuntamiento de Logroño.

12.2.2.1 Ampliación de la red multiservicio

El adjudicatario deberá suministrar la electrónica necesaria para implementar sobre la red de F.O. actual ylas ampliaciones que se irán realizando un sistema de transmisión basado en protocolo Carrier Ethernet 2.0hasta los puntos primarios y secundarios de la red que permita definir mecanismos de comunicaciónindependiente para los diferentes sistemas involucrados en el presente servicio y que sea susceptible deampliación a nuevas verticales o servicios.

El sistema suministrado para esta implementación deberá garantizar:

Topología de anillo de fibra óptica formado entre las ubicaciones principales de la red. El sistemase compondrá de un anillo que una todas las ubicaciones principales indicadas. No obstante, laarquitectura de la solución propuesta debe permitir la implementación de múltiples anillos con lasampliaciones necesarias.

El anillo deberá disponer de capacidades de backup ante cortes de fibra o caídas de los equiposde las ubicaciones principales. El tiempo de conmutación del anillo en caso de fallo deberá serigual o inferior a 50 ms

El punto de concentración estará ubicado en la Casa Consistorial. Éste se constituirá igualmentecon partes críticas redundadas. La conexión del punto de concentración a la MAN corporativa serealizará mediante la utilización de interfaces CE a 10 GB (al menos 2 conexiones) contra losequipos corporativos (2 x Cisco Catalyst 6509 en VSS) que se encuentran en el CPD de la CasaConsistorial. El suministro deberá incluir los adaptadores ópticos necesarios para la interconexiónde las redes en ambos extremos. El Ayuntamiento de Logroño garantiza la disponibilidad de, almenos, un interface X2 en cada uno de los 6509 para su utilización para este propósito.

El sistema deberá permitir disponer de un ancho de banda total de 10Gbps en cada anilloconfigurado, ya sea este compartido por todo el anillo o mediante la utilización de agregación deenlaces punto a punto a nivel óptico sobre el mismo.

Todo el equipamiento electrónico CE deberá disponer de la certificación MEF Carrier Ethernet 2.0o MEF Carrier Ethernet 1.0

Soporte de 802.3ah, 802.1ag, Y.1713 en los equipos de CE incluidos en el suministro.

Soporte de Ethernet Fast Ring Protection con G.8032 o EAPS v1 o v2

Cada una de las ubicaciones principales dispondrá de un equipo de demarcación Carrier Ethernetque permita definir múltiples interfaces de tipo UNI. Dichos interfaces permitirán la conexión,utilizando sistemas modulares (tipo SFP o similar), de las ubicaciones secundarias mediante cobreo diferentes tipos de F.O. (sobre uno o dos hilos en este último caso).

El sistema deberá permitir la creación de circuitos C.E. EVC de tipo P2P o MP2MP y RMP entrecualquiera de las ubicaciones secundarias y primarias, utilizando para ello los interfaces UNIsuministrados por la electrónica de las ubicaciones primarias y/o las secundarias. Se deberánsoportar los tipos de servicio E-Line y E-Access, valorándose la opción de servicios E-LAN y E-Tree basados tanto en puerto como en VLAN.

El sistema deberá permitir la utilización de múltiples EVC por UNI, al menos, en las ubicacionesprincipales.

El equipo suministrado en las ubicaciones secundarias deberá permitir la extensión de los EVCcreados desde las ubicaciones principales, extendiendo para ello la demarcación C.E. o bienrealizando conexiones que permitan traspasar los EVC definidos en el interface UNI principal através enlaces con múltiples VLAN.

Se deberá poder especificar perfiles de ancho de banda de tipo ingress y egress a nivel de UNI,EVC y CoS ID dentro de los EVC. Dichos perfiles de ancho de banda deberán tener unagranularidad mínimo de 1 Mbps.

Preferiblemente, los equipos suministrados serán modulares, permitiendo múltiplesconfiguraciones en función de los módulos instalados en dichos equipos.

25


El equipo suministrado para las ubicaciones principales deberá permitir la conexión de al menos 8ubicaciones secundarias. Los puertos de conexión deberán ser de tipo modular, basados en SFP osimilar y permitir la utilización de diferentes tipos de medios para su conexión. Al menos deberándisponer de capacidades para conectar equipos mediante cable UTP y F.O. monomodo ymultimodo.

Todos los nodos instalados deberán gestionarse en banda sin necesidad de disponer deconectividad adicional para la supervisión.

Se deberá disponer de software de Gestión de Red con alarmas y vista gráfica de serviciosextremo a extremo, licenciado con suficiente capacidad para no requerir ampliaciones de licenciasen caso de incorporación de nuevos elementos a la red. El sistema de Gestión de Red deberá seraccesible por parte del personal municipal y permitir la configuración de los equipos suminitrados.

Adicionalmente, desde el sistema de gestión o utilizando cualquier otro mecanismo, el sistemainstalado deberá enviar alertas SNMP y métricas SNMP de los diferentes circuitos físicos yvirtuales definidos a los gestores centrales del Ayuntamiento de Logroño para su monitorización.

Las alertas y datos de rendimiento se deberán integrar dentro de la plataforma suministrada de talmanera que se tenga acceso al estado del sistema de una manera integrada.

Actualmente se encuentran instalados switches marca Hirschmann en diferentes ubicaciones de la red detráfico que podrán ser reutilizados en los puntos de conexión principales o secundarios en caso deconsiderarse adecuado.

12.2.2.2 Ampliación de la red móvil de dispositivos

Aquellos elementos que no puedan ser conectado con los sistemas centrales mediante la utilización de fibraóptica y/o cableado de cobre de acuerdo a lo indicado en el apartado anterior deberán conectar mediante lautilización de la red 3G/4G.

Para dicha conexión, en el caso de que los elementos dispongan de conectividad Ethernet, el adjudicatariodeberá suministrar routers con tecnología 3G/4G para su instalación dentro de los cuadros de alumbrado oreguladores semafóricos. Las características de referencia que deberá cumplir el router 3G suministradoserán:

Capacidad de comunicación 2G/3G

Un puerto Ethernet de 100 Mbps RJ45.

Puerto RS232 y RS485, permitiendo la simulación de un puerto COM remoto utilizando el routeren modo transparente a través de IP.

Soporte de protocolos PPP, PPPoE, TCP, UDP, DHCP, ICMP, RIP, etc.

Capacidad de establecimiento de VPNs mediante IPSec, PPTP, L2TP, GRE y en caso de serposible implementar el protocolo abierto de OpenVPN.

Gestionable mediante CLI, SNMP e interface Web.

Capacidad de actualización del firmware en remoto.

Montaje en carril DIN.

El router deberá ser capaz de ser configurado para la utilización de un APN específico delAyuntamiento de Logroño para permitir la utilización dentro de una red privada.

Compatible con las tarjetas M2M suministradas por el adjudicatario.

El adjudicatario se compromete a suministrar las tarjetas SIM necesarias para la comunicación de losequipos de conectividad inalámbrica de acuerdo a las especificaciones de conectividad necesarias enfunción de los requerimientos de ancho de banda y nivel de transmisión de datos del sensor/actuador al quevaya a dar servicio.

26


El coste correspondiente al suministro de las tarjetas, los procesos de alta y las cuotas de transmisión seránpor cuenta del adjudicatario.

Las tarjetas suministradas deberán operar bajo un APN que establezca una red privada virtual decomunicación entre las tarjetas móviles y la sede central en la Casa Consistorial del Ayuntamiento deLogroño. El adjudicatario será responsable de suministrar un canal de comunicación de la sede central conla red privada virtual de móviles con el suficiente ancho de banda que garantice la correcta conectividad delos equipos 3G a través de dicha red. No se permitirá la utilización de Internet o cualquier otra red decarácter público como mecanismo de transporte de la red privada anteriormente indicada.

El adjudicatario será responsable de suministrar o dar acceso al Ayuntamiento de Logroño a un sistema degestión M2M que permita monitorizar las tarjetas SIM suministradas y actuar sobre la gestión de las mismaspor parte del personal adscrito al proyecto, tanto sea este municipal como del contrato.

El despliegue de los dispositivos 3G se realizará de acuerdo a la misma filosofía que los equiposconectados mediante fibra óptica, estableciéndose el equipo de comunicación 3G como punto principal deconectividad y pudiendo desplegar desde este hacia puntos secundarios mediante fibra o cobre lasconexiones necesarias. No obstante, el adjudicatario tendrá que tener en cuenta el ancho de bandadisponible en la red 3G/4G en subida y en bajada y garantizar en cualquier caso la asignación a los puntossecundarios de suficiente ancho de banda para el correcto funcionamiento de los sensores/actuadores y suinteracción con niveles superiores de la plataforma.

12.2.2.3 Despliegue de red

La realización del plan de despliegue de red, que incluirá la elección de los puntos primarios, secundarios y3G de conectividad, se realizará de común acuerdo con el adjudicatario una vez adjudicado el presentesuministro, prevaleciendo en caso de conflicto la decisión del Ayuntamiento de Logroño. Dicho despliegueinicial incluirá, al menos, las siguientes cantidades de nodos:

RED INICIAL DE FIBRA

Tipo de nodo Cantidad

Nodo principal de comunicaciones 15

Nodo secundario de comunicaciones 47

RED 3G

Tipo de nodo Cantidad

Nodos 3G 109

Se admitirá un aumento en la cantidad de nodos principales y secundarios suministrados de acuerdo a loespecificado en el apartado correspondiente a la valoración de criterios objetivos del presente PPT.

El despliegue de la red de nodos 3G se realizará durante la duración del contrato de común acuerdo con elAyuntamiento de Logroño.

El adjudicatario estará obligado a indicar los precios unitarios de cada uno de los elementos decomunicación incluidos en la oferta, así como a su suministro para futuras ampliaciones del sistema.

Dentro de la oferta se deberá incluir un cronograma que indique los plazos estimados para completar eldespliegue de red indicado en el presente pliego de prescripciones técnicas, siendo este como máximo de 6meses desde la fecha de inicio del contrato.

27


12.3 Integración de las cámaras de vigilancia de tráfico

12.3.1 Características de las cámaras existentes

Actualmente el sistema dispone de 15 cámaras de control de tráfico analógicas conectadas mediante unatopología lógica de estrella y física de anillo.

Concretamente los equipos actuales se componen de los siguientes elementos:

Cámaras analógicas BOSCH modelo LTC-0455.

Sistema de control de posicionamiento y óptica zoom ECV modelo TCB-R.

Matriz de vídeo ALLEGIANT LTC-8300 para la conmutación de las cámaras hacia los monitoresCRT existentes.

Videograbador de 16 entradas ECV ECO-REC 16H.

12.3.2 Conectividad de las cámaras

La conectividad entregada deberá garantizar el ancho de banda requerido para el visionado de las cámarasa una velocidad de al menos 15 fps en cualquier punto de la red principal corporativa. Para ello, tal y comose ha indicado anteriormente se deberá utilizar un EVC con el ancho de banda garantizado entre la cámaray el servidor central a través de la red CE, teniendo en cuenta que el servidor de cámaras se encontraráconectado a la MAN corporativa.

Así mismo, se deberá incluir la adaptación de las cámaras existentes a tecnología IP, de tal manera que latransmisión entre estas y el servidor de cámaras se realice mediante dicho protocolo. En caso de no poderadaptar o incluir interfaces de comunicación que permitan su adaptación a dicho protocolo seráresponsabilidad del adjudicatario la sustitución de las cámaras por unas nuevas que se adapten a dichosrequerimientos. Así mismo, también será requerimiento la adaptación de los sistemas de control y telemetríaexistentes en las cámaras actuales. La características ópticas de las cámaras suministradas deberán ser deiguales o superiores características a las existentes.

12.3.3 Servidor de cámaras

Dentro del presente suministro se deberá incorporar el hardware y software necesario para garantizar lassiguientes funcionalidades en:

El suministro incluirá tanto el/los equipo/s servidor como un equipo cliente que se utilizará en elcentro de control para su conexión al sistema de VideoWall instalado. Así mismo, se incluirán laslicencias cliente y servidor necesarias para soportar el sistema.

Grabación de las cámaras de control de tráfico a una velocidad de al menos 15 fps.

Capacidad para contener la grabación durante, al menos, 30 días. El sistema deberá estarpreparado para limitar la grabación a 30 días máximo para garantizar el cumplimiento de la LOPD.

Ser un sistema distribuido, modular y fácilmente ampliable.

Sistema de visualización que permita trabajar de forma distribuida por red de tal manera que nosea necesario acceder al servidor para ver las cámaras o consultar grabaciones.

Se deberá permitir la configuración de áreas de exclusión de grabación y/o visualización mediantemáscaras y/o difuminados para garantizar la intimidad de los elementos grabados.

Se deberá disponer de un cliente de visualización “pesado” mediante la ejecución de unaaplicación cliente/servidor sobre plataforma Windows 7 o superior con todas las funcionalidadesdel sistema disponibles. Adicionalmente se deberá disponer también de un cliente “ligero” vía webque permita, al menos, la consulta en tiempo real del sistema de cámaras. Este cliente ligero se

28


basará en la conexión al servidor de cámaras y nunca será accediendo directamente a losinterfaces web de que dispongan las cámaras IP incluidas.

Capacidad de configuración de los elementos visualizados dependiendo del cliente y/o el usuarioque haga login al sistema. El sistema deberá permitir la configuración de esquemas dinámicos quesean capaz de elegir la cámara visualizada en función de alertas, valores de umbral u horarios.

Los clientes de acceso no deberán estar limitados por licenciamiento, de tal manera, que elAyuntamiento de Logroño pueda instalar tantos clientes como considere necesario, estandolimitado únicamente por la degradación del rendimiento que surja de atender dichos clientes. Elsistema deberá estar dimensionado para la instalación y ejecución simultánea de al menos 3clientes pesados y 2 clientes Web.

Gestión de alarmas en las diferentes cámaras que deberán quedar registradas en el sistema.Estas alarmas deberán ser capaces de desencadenar modificaciones en los interfaces de losclientes de visualización (al menos en los clientes “pesados”). Como mínimo deberá ser capaz depresentar en los clientes la visualización de la cámara o cámaras de origen de la alerta. Lasalertas deberán poder ser originadas por, al menos:

Umbrales de detección de movimiento en las cámaras o en áreas especificas de cada cámaradefinibles por el administrador del sistema.

Detección de objetos abandonados.

Señales analógicas/digitales de equipos conectados a los sistemas de las cámaras. Porejemplo, detectores de apertura de puertas, sensores de temperatura, etc.

El sistema deberá permitir especificar diferentes niveles de fps para la visualización y la grabacióncon el objeto de optimizar los anchos de banda de la red.

Control de los valores de telemetría y zoom en cada una de las cámaras. En caso de que latelemetría existente no sea compatible con el sistema propuesto, será responsabilidad deladjudicatario la sustitución de la telemetría por una compatible que permita el mismo nivel demovimiento y funcionalidad que la existente.

Deberá ser posible la desactivación de la grabación de las cámaras cuando se realicenmovimientos de las mismas de una manera automática configurable por cada cámara o, comomínimo, disponer de la capacidad de desactivar la grabación manualmente por parte de losoperadores del sistema, previo a al realización de dichos movimientos.

Acceso al sistema mediante usuario y contraseña y posibilidad de asignar a cada usuariodiferentes roles en función de su responsabilidad. Al menos se deberá poder especificar por cadacámara lo siguiente:

Capacidad de acceso a la visualización en tiempo real de las cámaras.

Capacidad de acceso a la consulta de las grabaciones realizadas en cada cámara.

Capacidad de extracción de las grabaciones realizadas en cada cámara. Dichas extraccionesdeberán poder realizarse en un formato de vídeo fácilmente visualizable. Se valorará laimplementación de diferentes codecs.

Capacidad de acceso a la telemetría de cada cámara. Se valorará la posibilidad de diferenciarentre movimiento libre o únicamente movimiento a puntos prefijados por el administrador delsistema.

12.3.3.1 Características del sistema existente

Actualmente el Ayuntamiento de Logroño dispone de un sistema de cámaras de seguridad distribuidocompuesto por:

6 servidores de grabación y control ubicados en diferentes dependencias municipales queejecutan el software WAF versión 4.8.7.1624.

52 cámaras de diferentes tipos y tecnologías, incluyendo cámaras IP y analógicas.

4 puestos de vigilancia distribuidos mediante cliente dedicado.

2 puestos de extracción de grabaciones.

29


Varios clientes web de acceso a las cámaras en tiempo real.

Todos los equipos se encuentran conectados a través de la red corporativa municipal, garantizando losanchos de banda necesarios.

12.3.3.2 Integración

El adjudicatario deberá integrar las cámaras de control de tráfico del nuevo sistema dentro del sistema decámaras anteriormente descrito, de tal manera que las cámaras de control de tráfico se traten comocualquier otra de las existentes.

Dentro del suministro se deberá incluir todo el hardware, software y licenciamiento necesario para laintegración de las 15 cámaras existentes. No se deberá contar con recursos de los servidores existentespara la ampliación del sistema necesaria para el presente suministro.

El sistema suministrado deberá permitir la visualización de las cámaras de tráfico a través del videowallexistente, descrito en el apartado correspondiente del presente pliego de prescripciones técnicas. Para ello,se deberán incluir los equipos PC necesarios para instalar los clientes pesados necesarios para garantizarla capacidad de visualización de, al menos, 16 cámaras del sistema. Dichos equipos se instalarán en lasdependencias de la sala de control en un armario rack cercano a la ubicación del controlador del sistema deVideoWall existente.

El sistema se deberá integrar con la plataforma de Smart Logroño permitiendo la obtención deimágenes estáticas de las cámaras integradas en el sistema, de tal manera que la plataforma seacapaz de correlacionar eventos u otros datos de la misma con las imágenes obtenidas del sistema.

En caso de resultar imposible la integración con el sistema existente el adjudicatario deberá incorporar lossistemas necesarios para poder visualizar las cámaras de control de tráfico de acuerdo a lo indicadoanteriormente y además suministrar todos los elementos necesarios (hardware, software y licenciamiento)para la visualización de las cámaras de tráfico en, al menos, dos ubicaciones municipales conectadas a lared corporativa. Esto incluirá los equipos PC necesarios y paneles de visualización de tamaño suficientepara poder ver, al menos, 16 cámaras en tiempo real.

12.4 Servicio central de atención

12.4.1 Operación del Centro de Control Integral

Dentro del suministro actual deberá incluirse un sistema de operación sobre la plataforma destinado a suuso por parte de los operadores del Centro de Control Integral y del personal de atención presencial. Elsistema de operación deberá integrarse con la plataforma suministrada y actuar como nexo entre elpersonal de operación del Centro de Control y la plataforma.

Deberá apoyar al personal de operación en las siguientes áreas:

Atención presencial.

Atención telefónica.

Servicio de Chat escrito.

Correo electrónico.

Se valorará la inclusión de mecanismos de atención vía vídeo

El sistema de operación dispondrá de una interfaz que permita recoger las solicitudes de atención porcualquiera de los medios indicados (ToIP, Chat o e-mail) desde el propio puesto de trabajo del operador. Lascaracterísticas que debe cumplir dicho interfaz son las siguientes:

30


Para la atención de solicitudes telefónicas se deberá conectar con el sistema ToIP corporativoactual. Se deberá tener en cuenta que exista la posibilidad de traspasar llamadas de unamanera fácil y natural hacia las demás dependencias municipales. La responsabilidad de laconectividad con la red pública recaerá sobre los sistemas telefónicos actuales, debiendopermitir el enlace SIP el establecimiento de los suficientes canales de comunicación para elcorrecto desarrollo del servicio de atención telefónica. El adjudicatario será responsable deincluir todo el hardware, software y licencias necesarias para la interconexión, tanto en sussistemas como en los sistemas municipales existentes.

El sistema deberá incluir un sistema de atención vía chat escrito. El sistema permitirá el loginde los agentes de atención al sistema de chat y el acceso de los ciudadanos desde Internetmediante la utilización de cualquiera de los navegadores estándar imperantes en el mercado(Internet Explorer, Chrome, Mozilla Firefox, Safari, etc.). Cuando un agente se encuentrerealizando una atención vía Chat deberá considerarse en estado ocupado y evitar que se letransfieran otro tipo de solicitudes de atención. Para la ejecución del sistema de chat por partede los ciudadanos se tenderá a que no sea necesaria la descarga de clientes o plugins Java,ActiveX o similares para evitar incompatibilidades o procesos tediosos en los ciudadanos quequieran utilizar este servicio.

El servicio permitirá la monitorización de una cuenta de correo electrónico del sistema decorreo corporativo y permitirá gestionar las atenciones solicitadas desde dicha cuentaintegrando la información de las atenciones y sus estadísticas con los niveles superiores de laplataforma para su posterior análisis. El sistema deberá permitir la integración con servidoresde correo electrónico IBM Domino, Microsoft Exchange e integración vía POP3/IMAP4 ySMTP.

El interfaz del operador deberá poder ser ejecutado utilizando un terminal basado en PC. Encaso de ser necesaria la dotación de equipos adicionales para el correcto funcionamiento delsistema (terminales ToIP, etc) deberán incluirse dentro del suministro de la solución yresponsabilizarse de su mantenimiento durante la duración del contrato. Así mismo, elsistema deberá ser susceptible de ser ejecutado en el entorno VDI indicado en el presentepliego de prescripciones técnicas

El sistema contará con un interfaz específico para la figura del supervisor que permitirácontrolar el nivel de servicio en tiempo real y realizar las interacciones que se detallan en lossiguientes apartados.

El sistema deberá permitir establecer dinámicamente las funciones de cada uno de losagentes que se incorporen al sistema, de tal manera que se pueda establecer el tipo desolicitudes de atención que cada agente va a realizar en función de diferentes parámetros(origen de la solicitud, tipo de solicitud, etc). Esta asignación deberá poderse realizardinámicamente por parte del supervisor del sistema

Distribución automática de las solicitudes hacia los agentes u otros recursos definidos (guíasvocales, operadores automáticas, módulos de la plataforma, etc.) en función de diferentesparámetros (número telefónico llamante, tiempos de espera, tipo de solicitud, etc.).

Supervisión en tiempo real del estado del servicio desde el propio entorno de gestión de laplataforma que permita la monitorización de las métricas de rendimiento y de los diferentestiempos de las solicitudes de atención.

En el caso de solicitudes vocales el sistema deberá permitir la utilización de mecanismos IVRprevios a la asignación al agente, una vez finalizada la solicitud o durante el periodo deespera del llamante.

El sistema deberá permitir la apertura de canales de chat al menos entre el supervisor delsistema y los agentes y opcionalmente entre los propios agentes y chats en grupo

Capacidad de realizar encuestas de satisfacción posteriores a la atención recibida por elagente, independientemente del origen de las mismas. Los datos obtenidos de lasevaluaciones realizadas por los llamantes deberán ser capaces de ser exportados y/ointerrogados por los niveles superiores de la plataforma Smart Logroño para su integracióndentro de los módulos de análisis.

Capacidad de registro de las atenciones realizadas. En caso de atenciones telefónicas sedeberá poder grabar la conversación. En el resto de tipos de atención se guardará un

31


histórico del flujo y contenido de las interacciones entre los agentes y el solicitante de laatención. El registro deberá poder realizarse automáticamente, a petición del agente o apetición del supersivor del sistema.

Se valorará la posibilidad de integración del sistema con soluciones de reconocimiento vocal yconversión de texto a voz de terceros o su disponibilidad dentro del propio sistema.

Recogida de estadísticas de las atenciones realizadas y su exportación o capacidad deinterrogación por parte de los niveles superiores de la plataforma para la realización de sutratamiento y unificación con el resto de sistemas.

12.4.2 Servicio de atención presencial

El sistema deberá integrar los datos obtenidos desde el sistema Qmatic de atención presencial con losniveles superiores de la plataforma para integrar la información obtenida de dicho sistema como datos deentrada para los cálculos estadísticos de atención al ciudadano.

Para este cometido, el Ayuntamiento de Logroño se compromete a establecer los mecanismos necesariospara que los equipos que contengan los sistemas de la plataforma Smart City tengan acceso al servidor quecontrola los equipos de Qmatic. Dado el tipo y naturaleza de la información recabada por el sistema y queesta no es necesaria en tiempo real, se admitirá como solución la exportación periódica de ficheros desde elsistema Qmatic y su importación en bloque al sistema de análisis de la plataforma Smart City.

Adicionalmente, el adjudicatario deberá incorporar un mecanismo físico para que los ciudadanos puedanevaluar la calidad de la atención recibida mediante un control de pulsadores que indiquen su grado desatisfacción. El sistema deberá asociar al nivel de satisfacción establecido al agente del que ha realizado laatención y la fecha y hora de la misma. La solución óptima pasaría por extender el sistema Qmatic con estetipo de mecanismo en caso de ser posible, en caso contrario, el sistema deberá ser capaz de enviar hacia laplataforma de Smart City la información obtenida o bien permitir la interrogación por parte de la plataformade la información. Se valorará la capacidad de obtener del sistema información en tiempo real para susupervisión durante las atenciones presenciales.

12.4.3 Sistemas actuales

12.4.3.1 Sistema de control de atención presencial

Actualmente el departamento de atención ciudadana dispone de un sistema de gestión de la atenciónpresencial que se encarga de la gestionar las colas de espera. Dicho software es de la marca Qmatic,concretamente Qwin 2000Q SP 11 en su versión 55.01.1711.

12.4.3.2 Sistema ToIP corporativo

El sistema ToIP actual del Ayuntamiento de Logroño se basa en una solución de la marca Cisco e incluye lainfraestructura hardware y software que se detalla a continuación.

Hay que tener en cuenta, que, si bien, la infraestructura aquí detallada se utilizará dentro del desarrollo delpresente contrato en ningún caso se admitirá la instalación de nuevos elementos software o hardware sobrelos equipos actuales que produzcan un detrimento en el rendimiento del sistema actual o que no cumplancon las especificaciones funcionales y/o de capacidad establecidas y/o recomendadas por el fabricante.

Plataforma hardware

El sistema se compone de dos equipos Cisco Business Edition 6000 9.x (BE6K-ST-BDL-K9) diversificadosen dos ubicaciones.

32


Adicionalmente se dispone de un tercer equipo (Cisco UCSC-C220 M3S) para funciones de copia deseguridad única y exclusivamente.

Plataforma software

El sistema se compone de los siguientes elementos software instalado sobre la arquitectura hardwareanteriormente descrita con la asignación de recursos indicada para cada uno de ellos:

Elemento vCPUs RAM HDD

Cisco Unified Call Manager v9.1 – Server 1 2 4 GB 80 GB

Cisco Unified Call Manager v9.1 – Server 2 2 4 GB 80 GB

Cisco Unified CM IM and Presence v9.1 – Server 1 1 2 GB 80 GB

Cisco Unified CM IM and Presence v9.1 – Server 2 1 2 GB 80 GB

Cisco Unity Connection v9.1 1 4 GB 160 GB

Cisco Unified Attendant Console Advanced v10 1 4 GB 80 GB

Cisco ExpressWay C 2 6 GB 132 GB

Cisco ExpressWay E 2 6 GB 132 GB

12.5 Servicio de mantenimiento correctivo de los equipossuministrados

El adjudicatario deberá incluir el servicio de mantenimiento correctivo de los elementos indicados en elpresente apartado de infraestructuras de acuerdo a las siguientes especificaciones.

12.5.1 Recepción de avisos

El adjudicatario deberá poner a disposición del Ayuntamiento de Logroño un número único de notificación deavisos para todos los elementos detallados en el apartado de infraestructuras del presente pliego. Dichonúmero único deberá estar disponible en formato 24x7.

12.5.2 Tipos de avería

Se definirán los siguientes tipos de avería dentro de los elementos de infraestructura del contrato, con lossiguientes niveles de atención y acuerdos de nivel de servicio de solución:

Tipo de avería

Horario de atención

Plazo de primera atención

Plazo de resolucióno sustitución de pieza

Esfuerzo continuado

Crítica 24x7 1 hora 4 horas Sí

Grave 24x7 4 horas 12 horas Sí

Leve 8x5 8 horas 24 horas No

33


Como norma general se entenderá como avería crítica cualquier tipo de avería que produzca unadegradación sustancial del funcionamiento de la plataforma o cualquiera de las verticales y especialmenteaquella que afecte a los servicios públicos hasta tal punto que ponga en riesgo la seguridad de las personaso instalaciones.

A continuación se detallan cada uno de los elementos suministrados y los niveles de avería que seconsideran para cada uno de ellos.

12.5.3 Sistemas de red

En el caso de sistemas de red se considerarán averías críticas aquellas que impidan la ejecución de laplataforma Smart Logroño o el funcionamiento de cualquiera de las verticales incluidas en la plataforma oimplique un nivel de incomunicación con los elementos desplegados que haga imposible el correctofuncionamiento de la plataforma o alguna de las verticales dependientes.

Dado el nivel de redundancia existente en los sistemas, se considerará avería leve cualquier problema quesurja en los sistemas de red que pueda ser subsanado mediante balanceo de carga de los elementosredundantes sin que se produzca una degradación de rendimiento que impida, en la práctica, la ejecuciónde cualquiera de las funciones que soporte dicho sistema.

12.5.4 Servicio central de atención

En el caso del servicio central de atención se considerarán averías críticas aquellas que impidan realizar lastareas de atención al ciudadano. Se considerará crítica la caída del sistema de atención vía ToIP y grave lacaída de alguno de los sistemas alternativos (chat, correo, etc).

Se considerarán leves los errores de funcionamientos en los clientes de acceso al sistema siempre quedichos fallos no impidan el acceso a más del 20% de los operadores que hayan iniciado sesión en elsistema. En cuyo caso se considerarán averías graves o críticas.

12.5.5 Cámaras de tráfico

Con carácter general, el mantenimiento de las cámaras de tráfico, tanto preventivo como correctivo, serealizará desde el contrato de gestión de la vertical de tráfico.

Dentro del presente contrato estará incluido el mantenimiento de los equipos servidores/clientes einfraestructura central que atiendan la solución ofertada de integración de las cámaras de tráfico.

34

ANEXO B:

PLATAFORMA DE GESTIÓN INTEGRAL


13 ANEXO B: Plataforma de Gestión IntegralLa Plataforma de Gestión Integral de Servicios Públicos (en adelante Plataforma) es el conjunto de sistemasinformáticos, técnicas y herramientas que tienen como objeto el aprovechamiento de información diversaobtenida desde distintos orígenes del ámbito de la ciudad que, mediante tecnologías de Análisis de datos(DA) y Business Intelligence (BI) y un uso inteligente de la misma, ofrezca servicios avanzados que permitanla gestión eficiente, coordinada e integrada de la ciudad y de los servicios municipales, faciliten la toma dedecisiones en base a la información que recibe y procesa, eleven la calidad de vida de los ciudadanos yaumenten la cooperación, promoción y desarrollo de oportunidades de negocio.

13.1 Arquitectura

El modelo de arquitectura software de la propuesta debe estar basada en tecnologías y soluciones abiertas,preferiblemente en la Plataforma Java Enterprice Edition (Java EE), salvo casos puntuales deespecialización del componente o servicio vertical que requiera de otras tecnologías, manteniendo siempreel requisito de disponer de interfaces abiertas para asegurar la integrabilidad con el resto de la plataforma ysistemas municipales y externos.

El modelo arquitectónico debe ser abierto y multicapa basado en estándares que mantienen laindependencia de la interfaz gráfica respecto al diseño de los procesos de negocio y éstos a su vez con labase de datos. Estos estándares serán, en la medida de lo posible, elementos del mercado de libredistribución que estén suficientemente probados y consolidados para su implementación en un entorno deestas características. La Plataforma debe estar soportada en una estructura física y lógica fundamentada enentorno Web y basada en un patrón que separe, al menos, las capas de presentación y control, de lógica denegocio y de acceso a datos para conseguir la independencia y robustez de cada una de ellas al estarcentradas en sus objetivos específicos. La Plataforma debe estar construida sobre un conjunto limitado yoptimizado de tecnologías para favorecer su mantenimiento y evolución y la transferencia de conocimiento.

La oferta debe detallar los componentes y herramientas utilizadas en cada capa y su licenciamiento y debencumplir las especificaciones de referencia indicadas en PPT, resaltando que las licencias de uso, tanto dedesarrollo como de producción, deben ser a perpetuidad y la titularidad debe ser del Ayuntamiento deLogroño.

La solución propuesta para la Plataforma debe ser en modo “on-premise” o “in-house”, es decir, lainfraestructura hardware y el software deberán ser implantados en el Ayuntamiento de Logroño. Para lo cualel adjudicatario debe suministrar dos entornos, uno de Producción y otro de Desarrollo. Ambos entornosdeben ser tecnológicamente iguales, con las diferencias propias de la finalidad de este último de permitir eldesarrollo y prueba de funcionalidades antes de su despliegue en Producción y el adjudicatario debeproporcionar procedimientos documentados y utilidades para el paso de un entorno a otro.

13.2 Características de la Plataforma

13.2.1 Características generales

Se indican a continuación las características generales exigibles en la Plataforma.

a) Debe permitir la gestión del conocimiento de los diferentes servicios de la ciudad tanto de unaforma horizontal como vertical.

b) Debe disponer de capacidad para integrar una gran cantidad de datos generados desde múltiplesfuentes y con diferentes estructuras a través de un enfoque Big Data.

c) Debe permitir el análisis eficiente de los datos y eventos gestionados por la plataforma para latoma de decisiones y el aprendizaje del comportamiento de la ciudad.

36


d) Debe dotar a los gestores públicos, proveedores de servicios y a la ciudadanía de lasherramientas para incrementar la eficiencia, la sostenibilidad y la calidad de los servicios.

e) Debe facilitar la información a ciudadanos y agentes económicos y sociales a través de unenfoque Open Data para incrementar la participación ciudadana y la transparencia y establecer unentorno que fomente la innovación y el emprendimiento.

13.2.2 Características técnicas

Las características técnicas requeridas por la Plataforma son:

Solución abierta.

La Plataforma debe estar basada en tecnologías y soluciones abiertas y disponer de una interface deprogramación abierta (API) y estándares que permitan que tanto el Ayuntamiento como terceros (fabricanteso desarrolladores) puedan desarrollar otros módulos o aplicaciones para incorporar nuevas funcionalidadeso integrar nuevos servicios.

El adjudicatario será responsable de realizar la documentación suficiente para que el Ayuntamiento deLogroño o terceros sean capaces de utilizar los recursos de la plataforma sin requerir la asistencia directapor parte del adjudicatario.

Modularidad, adaptabilidad y evolución.

La Plataforma debe de ser modular facilitando la reutilización de funciones y debe disponer de capacidadesque garanticen, de forma fácil y escalable, la adaptación o incorporación de nuevos servicios verticales odesarrollos de funcionalidades.

Debe permitir la integración de la información desde diferentes soluciones/sistemas y dispositivos, disponerde capacidad de integración con los servicios/plataformas de gestión de la ciudad y debe permitir eldesarrollo y la integración de servicios y aplicaciones proporcionados por entidades externas de formasencilla ofreciendo una API abierta basada en estándares para interactuar con la Plataforma.

Robustez y escalabilidad horizontal.

La Plataforma debe ser robusta y escalable garantizando volumen de almacenamiento y procesado dedatos, velocidad de proceso y capacidad de respuesta en tiempo real.

La Plataforma debe estar soportada en una arquitectura que permita escalar, ampliar y personalizar suestructura y comportamiento conforme a la evolución de la misma y a las necesidades cambiantes delAyuntamiento.

Seguridad y privacidad.

La Plataforma debe disponer de las técnicas necesarias para asegurar la privacidad, confidencialidad,acceso autorizado y seguridad de los datos almacenados o gestionados por la solución, tanto en losprocesos de envío y recepción como en la manipulación de los mismos, autenticando los elementos(dispositivos, aplicativos y gestores) que originan, manipulan o reciben dichos datos. Esta seguridad debeser personalizable y ampliable.

La Plataforma debe garantizar la integridad y seguridad tanto de los datos que gestiona como de la propiaplataforma.

Resiliencia.

La Plataforma debe estar construida sobre arquitecturas y protocolos de actuación que garanticen la gestióneficiente de fallos que puedan afectar a la disponibilidad de la Plataforma, de tal forma que se garantice unalto nivel de operatividad de la misma en cualquier circunstancia.

37


Accesibilidad y usabilidad.

La Plataforma debe respetar los protocolos internacionales de accesibilidad (W3C y las Web ContentAccessibility Guidelines 1.0, elevando al máximo la accesibilidad del sistema y, para las funcionalidadesorientadas al ciudadano, se deben cumplir los requisitos de accesibilidad de Nivel AA.

La Plataforma debe mantener en la aplicación unos criterios mínimos de usabilidad, centrándoseprincipalmente en:

Facilidad del aprendizaje.

Velocidad por parte del usuario final del desempeño de las tareas asociadas.

Baja tasa de incidencias.

Bajos niveles de frustración.

Satisfacción subjetiva.

Universalidad.

Facilidad para ser recordado.

Multidispositivo e Interfaz de Usuario.

Atendiendo a los principios básicos de accesibilidad web, la información contenida en la Plataforma tendráque ser accedida en igualdad de condiciones, independientemente de la tecnología que el usuario emplee.La Plataforma debe estar disponible para el acceso mediante múltiples dispositivos (ordenador, smartphone,tableta táctil, etc.) y para los sistemas operativos soportados por dichos dispositivos: plataformas Windows(Windows 98 en adelante, Windows Mobile, etc.), Android, iPhone OS, etc.

El adjudicatario garantizará que las páginas resultantes del presente contrato podrán visualizarsecorrectamente en los navegadores estándar imperantes en el mercado, en sus últimas versiones y condiferentes resoluciones de pantalla.

La Plataforma debe ofrecer facilidad de operación, configuración y mantenimiento en todos los niveles deservicio: gestores, administradores, desarrolladores, etc. La interfaz debe ser homogénea, intuitiva y fácil deusar y de aprender, sencilla, segura y personalizable.

13.3 Componentes de la Plataforma

La Plataforma debe estar dotada de capacidades que permitan completar la lógica de procesos detratamiento de la información en una ciudad inteligente para proporcionar una visión integrada de la misma yconsolidarse como columna vertebral que facilite la integración de los sistemas verticales existentes yfuturos en un sistema único transversal de ciudad que funcione como un todo.

De forma general, la lógica de procesos incluye:

1. Recolección de datos de la ciudad a través de sensores, dispositivos, aparatos, redes sociales,atención ciudadana, infraestructura físicas y otros repositorios de información existentes y latransmisión de estos datos a través de las redes de comunicación.

2. Enfoque BIG DATA para la normalización y almacenamiento de los datos recibidos en un repositorio dedatos de la ciudad.

3. Procesado posterior mediante georreferenciación, sistemas analíticos y predictivos.

4. Puesta a disposición de esta información para lo distintos servicios de la plataforma que incluyen:

Monitorización en tiempo real (o casi real según las capacidades de captación) para la emisión dealertas/actuaciones y el seguimiento de la ciudad.

Confección de informes, memorias y estadísticas, indicadores y cuadros de mando que faciliten lagestión de los distintos servicios y la toma decisiones.

Integración con sistemas municipales.

38


Portales de acceso para ciudadanos, organizamos y empresas externas.

Enfoque Open Data para la externalización de los datos y posibilitar el desarrollo de aplicacionesde terceros.

Interoperabilidad con otras plataformas.

Para ello, la Plataforma debe constar al menos de las siguientes funcionalidades:

Servicios Básicos relacionados con la administración y gestión de la propia Plataforma y sucapacidad para dar respuesta óptima las necesidades de almacenamiento, análisis,georreferenciación, integración e interoperabilidad.

Servicios Avanzados relacionados con sistemas que interactúan con la Plataforma como soporteglobal o específico a las verticales integradas, al gobierno y gestión de la ciudad, a los sistemasmunicipales y a las relaciones con los ciudadanos y sistemas externos.

13.4 Servicios Básicos

13.4.1 Servicios Administración y Gestión de la Plataforma

La Plataforma proporcionará servicios básicos propios de la operativa, control, configuración y gestión de laplataforma: gestión de usuarios, acceso, auditoría, seguridad, supervisión y monitorización, ayuda, etc. ydebe ofrecer a los gestores un portal de “acceso unificado” a las distintas funcionalidades autorizadas segúnlos roles asignados en cada caso.

La Plataforma debe poder administrarse y gestionarse desde una consola web centralizada. Para ello,dispondrá de una interfaz multidispositivo, en entorno web, sin requerimientos adicionales de instalación. Lainterfaz debe ser personalizable, intuitiva y de fácil uso, y permitir a los gestores, de forma autónoma y sinnecesidad de mayores conocimientos, gestionar los dispositivos y orígenes de datos integrados en laplataforma, generar información tabulada, gráficas, mapas y visualizaciones (indicadores, informes,memorias y estadísticas, cuadros de mando, etc.) y ponerla a disposición de otros gestores o de losservicios avanzados. La interfaz debe integrar el acceso a funcionalidades incluidas en los servicios básicosy avanzados de la Plataforma y debe permitir una evolución fácil y sencilla para adaptar o incorporar nuevasfuncionalidades.

La Plataforma debe disponer de mecanismos que garanticen la confidencialidad, integridad, disponibilidad ytrazabilidad de la información gestionada por la misma. Para ello, debe:

1. Permitir definir y gestionar políticas de seguridad de acceso/aportación de contenidos y consumode servicios de la Plataforma.

a) Debe proveer de un módulo centralizado que integre la gestión y administración de usuarios,roles y permisos, garantizando la privacidad y seguridad a nivel de acceso a datos, acceso aelementos de la Plataforma (indicadores, informes, memorias y estadísticas, cuadros demando, etc.) y ejecución de funcionalidades y servicios de la misma.

b) Debe considerar diferentes tipos de acceso según sean individuos, dispositivos o aplicacioneslos que consuman servicios o información de la misma, según sean usuarios internos oexternos, etc. Para ello, debe contemplar la identificación contra un directorio de LDAP (ActiveDirectory 2003 o superior y OpenLDAP al menos) valorándose la opción de múltiplesrepositorios LDAP y posibilidades de identificación a través de otros mecanismos comousuario/contraseña, tokens, OAuth, certificados electrónicos etc. y disponer de capacidadpara extenderse y adaptarse con facilidad a otro tipo de soluciones avanzadas basadas, porejemplo en técnicas biométricas.

2. Gestionar la autenticación y autorización, controlando el acceso autorizado a la Plataforma y atodos los elementos a los que se acceda a través de esta.

39


3. Garantizar confidencialidad en la comunicación con la Plataforma, en el acceso a los datos y elconsumo de servicios, de modo que cada rol sólo pueda ver los datos a los que tiene acceso yrealizar actuaciones debidamente autorizadas.

La oferta debe enumerar y describir la interfaz y los servicios básicos destacando las funcionalidades ycaracterísticas que redunden en un mejor funcionamiento de la Plataforma.

13.4.2 Servicio de Integración e Interoperabilidad

Este servicio da cobertura a las necesidades de captación y normalización de la información gestionada enla Plataforma tanto para su integración y puesta a disposición de los distintos servicios autorizados como suinteroperabilidad con otras plataformas. Debe estar preparado para recibir grandes volúmenes de datosheterogéneos, tanto estructurados como no estructurados, y establecer las reglas de tratamiento yalmacenamiento que posibiliten su puesta a disposición del resto de componentes de la Plataforma parauna gestión integral de los mismos.

Es el responsable de estandarizar y normalizar los distintos contenidos y fuentes de datos, tanto internascomo externas, que alimentan la Plataforma, canalizando la captura de la información y la emisión deórdenes hacia los actuadores o dispositivos:

Internet de las Cosas (IoT): red de sensores, actuadores y dispositivos del ámbito de la ciudad.

Indicadores de Gestión y otras fuentes de datos (Servicios Municipales, Redes Sociales, etc.).

También se encarga de suministrar los datos al resto de elementos de la Plataforma y, en aquellos casosque se establezca, a los ciudadanos, en los formatos habituales a través del Portal Open Data ciudadano ydel Portal Smart Ciudad. Del mismo modo, dispondrá de capacidades de integración con las aplicacionesmunicipales.

La Plataforma debe disponer de capacidad para la Gestión de los dispositivos del IoT conectados, actualesy futuros, de forma individual y masiva y debe permitir el tratamiento y explotación de datos tanto en tiemporeal como por lotes o batch optimizando en cada caso las necesidades de cálculo, almacenamiento ymemoria.

La Plataforma debe facilitar el desarrollo o integración de aplicaciones en todos los niveles (serviciosverticales actuales o futuros, Sistemas Municipales, desarrolladores externos, …). Todo ello, acorde a losmecanismos y procedimientos indicados para definir las autorizaciones de acceso a los contenidos de laPlataforma. Para ello, dispondrá de integradores o conectores que suministren, de forma fácil y sencilla, losdistintos contenidos normalizados a través del Open Data (en los distintos formatos) y una API pública,implementada sobre estándares de comunicación (Web Service, REST, etc.) que permita que estasaplicaciones utilicen y se integren con funcionalidades de la Plataforma.

Así mismo, se deberá disponer de la especificación completa de comunicación con los sensores/actuadorescon el objeto de tener independencia en la inclusión de nuevos sistemas de gestión y/o equipos desensorización y control. Los procesos de integración pueden ser estándares (de sensores, de dispositivos,de aplicaciones,...) o específicos si deben ser desarrollados de forma particular. El adjudicatario secompromete a mantener actualizada la publicación de todas las funcionalidades de integración existentes enla Plataforma, así como mantener una documentación exhaustiva de la API, servicios web u otrosmecanismos de comunicación existentes con la misma.

La normalización de datos debe permitir realizar las siguientes tareas:

Recoger la información proveniente de los sensores/actuadores a través de la red decomunicaciones.

Recoger información de los sistemas de gestión de las verticales que se integren mediante losinterfaces que expongan dichos sistemas.

Recoger información de otros sistemas que aporten valor añadido a la gestión integrada deservicios.

Proporcionar información a otros sistemas municipales para la mejora de la experiencia degestión.

40


Enviar comandos de actuación sobre aquellos dispositivos susceptibles de realizar accionesdentro de la red de sensores/actuadores.

Normalizar la información recibida de los sensores y sistemas de gestión verticales de tal maneraque se unifiquen los datos enviados hacia los niveles superiores de la Plataforma Smart Logroño.

Normalizar la interfaz de envío de mensajes de actuación hacia los equipos actuadores de la red ya los sistemas de gestión verticales actuales para la interactuación de los niveles superiores haciadichos elementos.

La Plataforma debe disponer de capacidad de interoperabilidad con otras plataformas en base a:

La integración y normalización de datos que aporta la independencia que se requiere sobre laobtención/captación de información.

La publicación de datos abiertos a través de un Catálogo y un Portal Open Data.

La posibilidad de interconexión entre aplicaciones y entre plataformas mediante el uso de SDK (Kitde desarrollo) y una API abierta, soportando distintos modos de acceso a los datos:suscripción/notificación y petición/respuesta y consultas georreferenciadas.

Políticas de seguridad integrada en el acceso a través de la API, SDK, Open Data, etc.

Desarrollos basados en estándares y soluciones abiertas que permitan la portabilidad deaplicaciones entre distintas plataformas.

13.4.3 Servicio de Almacenamiento

En cuanto a los datos, la Plataforma debe tener una filosofía Open Data en la puesta a disposición de lainformación entre los distintos elementos y un enfoque Big Data contemplando el almacenamiento,tratamiento y explotación de grandes volúmenes de información en tiempo real y de información histórica,de información estructurada y no estructurada, de información transaccional y analítica.

Los requerimientos de almacenamiento de la Plataforma varían según necesidades de disponibilidad,volumen y tipo de contenido. La Plataforma debe estar construida sobre un conjunto limitado y optimizadode sistemas de almacenamiento de datos para favorecer su mantenimiento y evolución y la transferencia deconocimiento.

Así, inicialmente, entre los contenidos de información manejados en la Plataforma, se identifican:

Información propia de la operativa, gestión y control de la Plataforma de gestión integrada.

Información de inventarios de recursos y de otros sistemas para facilitar la gestión de averías eincidencias y la visión global de la ciudad.

Información integrada de actuaciones, avisos, afecciones e incidencias y eventos de todo tipo delsistema de averías e incidencias.

Información de otros servicios horizontales de la Plataforma y sistemas municipales:

“Atenciones”, “Quejas y Sugerencias” y “Afecciones en la vía pública” en tiempo real.

“Población” e “Instalaciones Municipales” con una periodicidad a determinar.

Información georreferenciada de la solución GIS.

Información analítica resultante de los procesos de BI (Business Intelligence) para la obtención deindicadores y cuadros de mando de los sistemas de gestión de verticales y de la gestión de lapropia plataforma.

Información del servicio a Ciudadanos incluyendo el catálogo y datos del módulo Open Data y loscontenidos del módulo de Acceso del Ciudadano.

La solución debe proporcionar mecanismos de backup, redundancia y seguridad de acceso autorizado paragarantizar el almacenamiento, disponibilidad, trazabilidad y seguridad de los datos.

41


Para realizar la valoración, la oferta debe justificar y optimizar las soluciones y sistemas de almacenamientopropuestos en cada caso y contener una tabla que indique como mínimo, para los distintos tipos deinformación indicados anteriormente, su correspondiente solución de gestión de base de datos.

13.4.4 Servicio de Análisis

La Plataforma debe proporcionar un sistema integral de gestión de información con herramientas sencillaspara manejar grandes conjuntos de datos de fuentes diversas, con un gran número de variables y encondiciones de tiempo real, obteniendo indicadores de servicio de alto valor añadido. Un sistema que derespuesta a las necesidades de obtención de información y facilite el conocimiento, medida y optimizaciónde los procesos en un marco de gestión integrada de la ciudad que permita:

1. La gestión del conocimiento de los diferentes servicios verticales integrados, nivel horizontal, laexistencia de un cuadro global de gestión de la ciudad, nivel vertical.

2. Realizar análisis de datos y predicciones según los datos almacenados.

3. Encontrar patrones de comportamiento en los sucesos de la ciudad.

4. Realizar simulaciones de situaciones que puedan darse en la ciudad.

Para ello, debe incluir mecanismos y técnicas de análisis de información, de integración e interpretación, depredicción y simulación de estrategias, de implementación de reglas y políticas de gestión que permitanponer a disposición de los servicios avanzados de la Plataforma los recursos y estructuras que faciliten lagestión, seguimiento, control y soporte a la toma de decisiones sobre los Servicios Verticales, la gestiónglobal de la ciudad y los Servicios Municipales. Además, debe proporcionar un repositorio estructurado quealmacene los objetos generados (plantillas, consultas, informes, memorias y estadísticas, cuadros demando, etc.).

Para obtener la información y presentar los resultados, la Plataforma proveerá de una interface, acorde a lodescrito en las características generales, intuitiva y gráfica, apoyada en un sistema de visualización de datosgeográficos con altas capacidades de interacción que facilite la toma de decisiones estratégicas y operativasde los diferentes ámbitos de gestión.

Además, esta capacidad de análisis debe ser fácilmente escalable y adaptable a las necesidades futuras.

13.4.5 Servicio de Georreferenciación

El Ayuntamiento dispone de un sistema GIS Smallworld (1). La solución propuesta debe contemplar el usode este u otro sistema GIS como una herramienta básica de apoyo para la gestión de los distintos serviciosde la Plataforma y servicios verticales, de manera que se puedan georreferenciar no sólo los inventarios deelementos y recursos gestionados, sino las actuaciones, avisos, incidencias y eventos de todo tipo que seconsideren necesarios para disponer de una visión integral del estado de la ciudad. Si se opta por otrosistema, el adjudicatario deberá implementar los mecanismos y estrategias para mantener sincronizadosambos sistemas en función de las necesidades de información.

La gestión y el análisis de la información geográfica de la Plataforma Smart City debe entenderse como unainfraestructura de datos espaciales que garantice plenamente la continuidad de los servicios y aplicacionesactuales en el entorno Smallworld y, en línea con la orientación de la plataforma, facilite la explotación deinformación geográfica de forma abierta tanto a la plataforma como a los servicios actuales o futuros quepuedan conectarse. Por ello, la solución propuesta debe estar alineada con las normas, estándares yespecificaciones que regulan y garantizan la interoperabilidad de la información geográfica (la directiva2007/2/CE INSPIRE, transpuesta en España por la Ley 14/2010, de 5 de julio, sobre las infraestructuras ylos servicios de información geográfica en España (LISIGE), la serie de normas ISO 19100 y los estándaresestablecidos por el Open Geoespatial Consortium (OGC).

Para realizar la valoración, la oferta debe incluir descripción de:

los distintos casos de uso en la Plataforma de la información georreferenciada y

42


una solución que permita dotar a la Plataforma de capacidad de georreferenciación de contenidosy garantizar la continuidad y calidad del actual servicio GIS Municipal.

La propuesta debe ser viable y factible. Su implantación será a cargo del Adjudicatario en el ámbito delpresente contrato y debe incluir detalle suficiente de los requerimientos y necesidades derivadas de estaimplantación (mecanismos y estrategias de sincronización y publicación de contenidos, formatos utilizados,implantación de herramientas y/o versiones diferentes de productos, etc.) y de la planificación y ejecución deprocesos de actualización/adecuación de aplicaciones y desarrollos existentes y de posibles extracciones dedatos a realizar.

El sistema GIS implementado deberá garantizar la disponibilidad de suficientes licencias de acceso para lagestión de la plataforma y para el acceso de los ciudadanos y gestores municipales a la informacióngeorreferenciada, al menos, mediante cliente ligero (web o similar). Se valorará especialmente la noexistencia de limitaciones de acceso concurrente al sistema GIS.

(1) GE Smallworld Core Spatial Technology (CST) 4.1.0.

GE Smallworld Internet Application Server (IAS) 4.1.0.A la fecha de inicio del contrato está previsto disponer del Dataset GIS Smallworld del Ayuntamientode Logroño en formato Shapefile y un Sistema de Información Geográfica de código libre (QGIS)para la visualización de los mismos.

13.5 Servicios Avanzados

Además de los componentes indicados anteriormente, la Plataforma debe proporcionar los serviciosavanzados o conjunto de sistemas que interactúan con la Plataforma y que se agrupan en cinco ejesbásicos:

Gestión de Servicios Verticales.

Gestión de Servicios Horizontales.

Gobierno y Gestión de la Ciudad.

Sistemas Municipales.

Relación con el Ciudadano.

13.5.1 Gestión de Servicios Verticales

Esta denominación abarca los servicios municipales que se integren en la Plataforma. El presente contratobusca instalar en el Ayuntamiento una plataforma con un alto grado de evolución y desarrollo decomponentes para que, tras una fase inicial de implantación y un breve periodo de adaptación a lasespecificaciones del Ayuntamiento, se disponga de plena capacidad operativa para iniciar la integración deservicios verticales.

Dando continuidad a la presente licitación, está prevista la licitación de los servicios de Atención Ciudadana,Regulación de Tráfico y Alumbrado Exterior Público, que incluirán de forma obligada su integración en laPlataforma y a medida que se lo vayan permitiendo los actuales contratos, la integración de serviciosmunicipales de áreas como movilidad y medio ambiente y otros posibles proyectos.

13.5.2 Gestión de Servicios Horizontales

Esta denominación abarca los servicios proporcionados por la Plataforma comunes al resto de servicios dela misma y que incluyen funcionalidades, ya existentes o a desarrollar, que permitan integrar la gestión devarios de los servicios verticales.

Deben de mantener las características indicadas para la Plataforma con especial énfasis en:

43


1. Concepción abierta para dar soporte a la variedad de servicios verticales posibles y debidamentedocumentados para facilitar los procesos de integración.

2. Integración con el resto de componentes de la Plataforma.

3. Explotación georreferenciada de la información por calles, zonas de gestión, etc., proporcionandoun tiempo de respuesta aceptable según la actividad a realizar con el apoyo del sistema GIS o unsistema de mapas.

4. Disponer de estructuras de datos y capacidades para integrar e interactuar de forma autorizadacon los sistemas verticales y los sistemas de gestión municipales, incluyendo el registro manual decontenidos y mecanismos y facilidades para importar estos contenidos de forma automatizada,individual o masiva.

La Sala de Centro de Control Integral (CCI) es el espacio físico que simboliza la integración de los serviciosverticales. Los servicios horizontales tienen dos objetivos claros:

1. Dar respuesta a las necesidades comunes de los servicios verticales que se integren en laPlataforma.

La solución propuesta debe incluir como mínimo capacidades para:

Gestión del Catálogo de Recursos Materiales incorporados en la Plataforma.

Gestión de Recursos Humanos del personal relacionado con la Plataforma.

Gestión Económica con funcionalidades para el seguimiento y control de la propia plataformay los servicios verticales integrados.

Gestión de Dispositivos conectados a la Plataforma.

Gestión de Eventos con capacidad para configurar reglas y actuaciones.

Además, se identifican, otros módulos susceptibles de ser compartidos por varios serviciosverticales y que pudieran ampliar la oferta de servicios comunes de la Plataforma, como son lagestión de mantenimiento, de órdenes de trabajo, de vehículos, de stocks, de instalaciones, etc.

2. Dar repuesta las necesidades de gestión del CCI que da soporte global de atención a todos losservicios que se integren en la Plataforma Smart Logroño.

Gestión de Alertas e Incidencias única para todos los servicios verticales.

Gestión Integral de Atenciones.

Gestión de Quejas y Sugerencias.

Gestión de Afecciones en la vía pública.

13.5.2.1 Gestión de Alertas e Incidencias

Comprende la gestión unificada de las alertas e incidencias que se producen en la ciudad, integrandoinformación del seguimiento de los avisos/averías de los servicios verticales, información del resto decomponentes de la Plataforma (quejas y sugerencias, afecciones en la vía pública, atenciones, mapas derecursos, datos del sistema GIS, …) y otros contenidos de interés (datos de meteorología, …) permitiendogestionar la situación, optimizar tiempos y recursos empleados y faciliten la toma de decisión.

El sistema debe detectar en tiempo real las averías e incidencias de los sistemas conectados y permitir elregistro tanto de forma manual como integrada desde distintos orígenes.

El sistema debe proporcionar facilidades para describir las distintas situaciones de alertas que seproduzcan, incorporando información adicional de interés como la localización de la misma, recursosmateriales y personales próximos a la zona, información de edificios, población o actividades económicasque pudieran estar afectadas, historial de incidencias en la zona y avisos de ciudadanos que se produzcan.

44


El sistema facilitará la toma de decisiones y la valoración y optimización de recursos facilitando el cálculo derutas, tiempo estimado de atención, posibles afecciones en el tráfico por accidentes, cortes o calzadaocupada, accesibilidad de la zona, etc.

Además, incluirá capacidades para manejar la alerta facilitando procedimientos y protocolos de actuación,gestión de avisos, comunicaciones y traslado o escalado de las actuaciones a realizar, movilización ygestión de recursos según prioridad y tipo de emergencia, agrupación de alertas relacionadas, aviso yatención al ciudadano y cierre de incidencias.

La gestión de las situaciones de averías e incidencias será integrada para todos los tipos, pero el sistemadebe permitir personalización para adaptarse a las particularidades de cada servicio: como los flujos deavisos, movilización de recursos, etc.

13.5.2.2 Gestión Integral de Atenciones

El Centro de Control Integral (CCI) es el responsable de la atención telefónica y presencial de las consultasy gestiones de los ciudadanos. Se desea dotar al CCI de un sistema de gestión que mejore y agilice laatención que realizan, permita registrar actividad y grado de satisfacción en el servicio que presta y facilite elacceso a los aplicativos de gestión en los trámites en que sea posible.

Las actuaciones o trámites principales en la actualidad son:

Registro de Quejas y Sugerencias y Averías 72 horas. (sistema a renovar en el marco del presentecontrato).

Inscripciones en Actividades de Logroño Deporte.

Inscripciones en Ludotecas y Campamentos.

Emisión de Volantes padronales.

Información general a través de la página web.

Registro de sujetos en la Base de datos corporativa. Grabación de becas y chiquibecas, de formatemporal en las campañas de solicitud.

Gestión de datos del bono de transporte “bonobús”.

Altas en la wifi municipal.

Altas en el sistema de bicicletas “Logrobici”.

El sistema proporcionará datos e indicadores que se integrarán con las especificaciones que resulten de lapróxima licitación del contrato para establecer los procesos de seguimiento y control del servicio.

El sistema de gestión debe facilitar la los operadores del CCI un entorno de trabajo que integre elequipamiento y capacidades indicadas en el apartado de infraestructuras y contenidos de la Plataforma paradisponer al menos de las funcionalidades siguientes:

1. Disponer de un “escritorio” o menú de opciones fácilmente identificables que faciliten el acceso a:

Datos básicos de identificación, información horaria, climatología, ...

Previsiones para el día: eventos y acontecimientos previstos, afecciones en la vía (obras,actuaciones....), etc.

Predicciones de posibles cargas o picos de actividad. Por ejemplo: campaña por inscripciónen actividades deportivas, nieve, fuertes lluvias o viento que incrementen las llamadas de losciudadanos o intervenciones de los servicios municipales, un evento (concierto, marcha,actividad deportiva,... ) que origine movimiento masivo de personas, etc.

Resto de componentes y contenidos de la Plataforma autorizados como servicioshorizontales, mapas y recursos, etc. y otros contenidos configurables, como por ejemplorepresentaciones en el mapa de la ubicación de las zonas wifi, o instalaciones municipales,etc. que puedan facilitar su gestión de resolver las necesidades de información de losciudadanos.

45


Aplicativos de gestión actuales y futuros que soportan la actividad de atención y tramitaciónde gestiones.

El sistema debe integrarse con el sistema telefónico de manera que recoja del mismo lainformación de la llamada, recopile del sistema la información disponible para ese númeroproporcionando al operador información adicional como número de llamadas recibidas,temáticas, última llamadas, observaciones sobre el ciudadano, enlace a trámites, etc. queagilicen y mejoren la atención.

2. Incluir mecanismos ágiles de gestión de mensajes y avisos entre los operadores y turnos.

3. Facilitar la gestión de un catálogo de contenidos, actuaciones, eventos y actividades, trámites einformación de interés para dar respuesta a las peticiones de información de los ciudadanos. Elcatálogo debe incluir opciones para ampliar información o iniciar actuaciones y facilidades paraindicar a los operadores los procedimientos y protocolos de actuación en cada intervención.

4. Integración con los sistemas de gestión de trámites que permitan esta integración proporcionandoinformación y facilitando el acceso a los mismos. Por ejemplo, pasar el identificador de llamada ynúmero de teléfono llamante al aplicativo de quejas o sugerencias.

5. Permitir realizar y registrar preguntas al finalizar la llamada con información como código postal,distrito, rango de edad, temática y calle y número. El sistema debe permitir llamadasparametrizadas desde los sistemas de gestión municipal para que puedan utilizar este módulo.

6. Para facilitar el interoperabilidad con los Servicios Municipales que demandan “Campañas” al CCI,el sistema debe disponer de un mecanismo para importar archivos (en formato txt, csv, ...) con lalista de números y contenidos a trasladar. El sistema debe permitir automatizar la gestión ydistribución de estas listas facilitando crear bloques o grupos de llamadas asociados a los agentesde operación o turnos y permitir que éstas registren el resultado de la llamada y de los intentos.Finalmente, debe permitir exportar esta información para devolvérsela al Servicio Municipaldemandante.

7. Incluir un sistema de atención vía chat escrito según especificaciones del Sistema integral deatención del apartado de infraestructuras, registrando la actividad realizada.

8. El sistema debe utilizarse e integrarse con el resto de componentes de la Plataforma,implementando en la misma la elaboración de informes, la generación de indicadores de lasatenciones realizadas y de las encuestas de satisfacción (postllamadas automatizadas del callcenter en la atención telefónica y del Qmatic en la atención presencial), cuadros de mando, etc.para la gestión, evaluación y seguimiento del sistema.

9. Registrar de forma automática y manual las atenciones realizadas.

10. Diseño adaptado para permitir gestionar atenciones de otros servicios, incluyendo capacidadespara importar actuaciones de forma masiva y automatizada tanto de sistemas verticales como deotros sistemas de gestión municipales.

13.5.2.3 Gestión de Quejas y Sugerencias

El sistema de quejas y sugerencias gestiona diversos tipos de peticiones (quejas y sugerencias, averías 72horas, solicitudes de información, diversas suscripciones y visitas a instalaciones) comunicadas por losciudadanos desde distintos medios. Las averías son incidencias detectadas en base a un catálogo con elcompromiso de resolución en 72 horas. Estas peticiones se trasladan a las unidades municipalescorrespondientes para su contestación y posterior traslado a los ciudadanos.

El sistema debe utilizarse e integrarse con el resto de componentes de la Plataforma, implementando en lamisma la elaboración de informes, la generación de indicadores, cuadros de mando, etc. para la gestión,evaluación y seguimiento del sistema.

La Plataforma debe permitir la visualización personalizada sobre el mapa de la ciudad de los distintos tiposde peticiones y la visualización como contenido adicional en la gestión de alertas e incidencias segúnconfiguración (por ejemplo, las averias72 horas y las quejas y sugerencias).

46


El sistema se debe desarrollar de acuerdo con las especificaciones descritas en el Anexo C de estedocumento.

13.5.2.4 Gestión de Afecciones en la vía pública

El sistema gestiona la información sobre las posibles afecciones (obras, actuaciones en la vía,accidentes,...) de distintos tipos en la vía pública que pueden afectar a la movilidad en la ciudad. LaPlataforma debe proporcionar un registro en tiempo real de estas afecciones y gestionar su visualizaciónsobre el mapa de la ciudad y su visualización como contenido adicional en la gestión de alertas eincidencias, personalizando la misma en función de los diferentes tipos, orígenes y estados.

La incorporación de afecciones se realizará de forma manual y se implementará la opción de cargaautomatizada de aquellas unidades que disponen de gestión de afecciones en MS Access.

El sistema debe utilizarse e integrarse con el resto de componentes de la Plataforma, implementando en lamisma la elaboración de informes, la generación de indicadores, cuadros de mando, etc. para la gestión,evaluación y seguimiento del sistema.

El sistema se debe desarrollar de acuerdo con las especificaciones descritas en el Anexo D de estedocumento.

13.5.3 Gobierno y Gestión de la Ciudad

La Plataforma debe permitir una visión holística, única e integrada de toda la información de la ciudad quefacilite el seguimiento global de los servicios, la gestión de dispositivos y eventos, la gestión estratégica y latoma de decisiones.

Con este objetivo, la interfaz de la Plataforma debe permitir a los gestores, de forma centralizada, segura ymultiusuario, explotar la capacidad de análisis y simulación de la misma e interactuar con los distintoscontenidos (cuadros de mando, informes, memorias y estadísticas, indicadores, alertas e incidencias,inventario geolocalizado de distintos y diversos elementos e infraestructuras físicas de la ciudad, etc.),proporcionando capacidades de control y visualización geográfica que incluyan funcionalidades habitualesen el manejo de mapas, capacidad multicapa (añadir/quitar capas), agrupar y/o filtrar por múltiples criteriostemáticos como distritos, zonas de gestión, etc., por intervalos de tiempo, por gestores responsables, pordispositivo, etc., obtener resúmenes, ampliar información, incorporar datos multimedia y, si el sistema degestión lo permite y el gestor está autorizado, enlazar con la gestión específica del elemento seleccionado.

Dentro de los objetivos del apartado de soporte a la Plataforma, se desarrollará o adaptará a lasespecificaciones del Ayuntamiento si estuviera desarrollado, un cuadro de mando integral que permita lacoordinación, control y seguimiento de las actuaciones que se establezcan bajo el contexto de ciudadesinteligentes incluyendo contenidos propios de la Plataforma y evolucionando con la incorporación de nuevasfuncionalidades y la integración de servicios verticales y proyectos estratégicos de la ciudad.

La oferta debe incluir detalle de la interfaz y de la capacidad de interactuar con todos los elementos ycontenidos de la Plataforma.

13.5.4 Sistemas Municipales

La Plataforma es uno de los componentes principales para la gestión y gobierno de la ciudad y su puesta enmarcha debe permitir también mejorar los propios servicios municipales. Por ello, se considera fundamentalque la Plataforma disponga de capacidades de integración, entendida en ambos sentidos, con los SistemasMunicipales de Gestión permitiendo el intercambio de información e integración de funcionalidades con lossistemas municipales de gestión.

Esta integración debe proporcionar mejoras en la gestión de los servicios municipales basadas en lainformación y servicios que ofrece la Plataforma:

47


Disponibilidad de grandes volúmenes de información de orígenes diversos, tanto e tiempo realcomo históricos.

Disponibilidad de módulos y funcionalidades comunes e integradas.

Capacidad visualización georreferenciada sobre la solución GIS de la Plataforma.

Capacidad analítica para confeccionar informes, indicadores, cuadros de mando y memorias.

Disponibilidad de combinar información diversa para la toma de decisiones.

Capacidad de trasladar contenidos al ciudadano y publicar datos en el Open Data Municipal.

De este modo, la Plataforma debe permitir que los sistemas de gestión municipal integren fácilmentecontenidos y funcionalidades de la misma. Esta integración debe ser autorizada y sin que requiera por elloidentificación adicional. Se indican algunos ejemplos a implementar de utilización de recursos de laPlataforma de forma directa desde los propios sistemas municipales.

Desde un sistema de gestión municipal, habilitar una opción para mostrar cuadros de mando oinformes de indicadores de gestión. Por ejemplo, un informe por distrito con contenidos sobre lasquejas y sugerencias, averías en un determinado estado y periodo de tiempo, datos económicos,de población, sociales, etc..

Del mismo modo, mostrar elementos georreferenciados en el mapa que faciliten la visión globaldel gestor. Por ejemplo las averías e incidencias ocurridas en un periodo de tiempo por zonas degestión.

13.5.5 Relación con el Ciudadano

Uno de los objetivos principales del proyecto es promover la colaboración y participación de los ciudadanosen mejorar la gestión de los servicios de la ciudad y elevar así la calidad de vida de los mismos.

Por este motivo, la Plataforma debe incluir mecanismos y herramientas que posibiliten poner a disposicióndel ciudadano información integrada o generada en la misma que se determine publicar en determinadosformatos y periodicidad.

Inicialmente se identifican los ejes de actuación:

Acceso de los ciudadanos a contenidos de la plataforma que se ponen a disposición deciudadanos: inventarios de información georreferenciada, cuadros de mando o indicadores, etc.que se muestran al ciudadano de forma similar a lo especificado anteriormente para el gobierno dela ciudad.

Acceso de los ciudadanos a contenidos del Open Data municipal: La Plataforma debeproporcionar las capacidades para gestionar obtención, censado y categorización de contenidosen un Catálogo Open Data y su publicación en el Portal Open Data.

En el marco del Plan de Innovación de Logroño 2020, el Ayuntamiento de Logroño, a través de la DirecciónGeneral de Transparencia, trabaja en la elaboración de un catálogo Open Data con contenidos de lasunidades municipales y un plan para su despliegue en la Plataforma Smart Logroño.

Para la fase de implantación se establece un catálogo inicial con contenidos mínimos a implementar y,dentro de las actividades de soporte y evolución de la Plataforma, el adjudicatario se compromete a laimplementación y evolución del catálogo Open Data resultante de los trabajos indicados.

El catálogo inicial incluye:

Datos de población por edad, sexo, nacionalidad.

Datos de las averías e incidencias del sistema.

Datos externos proporcionados por otras entidades.

Y en general, todos los datos incorporados en la Plataforma que el Ayuntamiento de Logroñoconsidere de interés para su publicación.

48


Este Catálogo debe estar diseñado para facilitar la incorporación de los contenidos actuales y futuros amedida que aumente la integración de información en la Plataforma.

El Catálogo debe gestionar los contenidos por tipo, origen, fecha de inicio y fin, fechas de disponibilidad,frecuencia de actualización, histórico de contenidos, licencia y formatos disponibles, procesos de obtenciónde la información y ubicación del archivo a descargar.

Para el Acceso del Ciudadano, la plataforma deberá disponer de un Portal Open Data personalizable yadaptable a estilos y contenidos propios del Ayuntamiento de Logroño.

Además del acceso vía portal, la solución debe incluir capacidades para exportar datos de forma flexible ycompatible, al menos, con formatos de proyectos de reutilización de la información de ámbito nacional oeuropeo: formato Open Data compatible con http://datos.gob.es y formato compatible CKAN (estándar FI-WARE). Se valorará la existencia de capacidades de exportación basadas en una API abierta sobreestándares tipo REST, ficheros JSON o ficheros HDFS, así como al existencia de servicios web y/o portletsdesarrollados en JSR-286 que permitan incluir datos del catálogo en otros sistemas.

La visualización de la oferta del catálogo debe incluir facilidades de búsqueda por distintos criterios:materias, temas, formatos, últimos datos actualizados, … y debe permitir previsualización ydescarga/suscripción de contenidos. Además, debe ir acompañada de opciones y funcionalidadesrelacionadas como Qué es Open Data, Términos de uso, Ideas y colaboraciones, etc.

La solución propuesta debe promover la colaboración de los ciudadanos e impulsar ideas de innovaciónbasadas en el uso de los datos publicados en el catálogo Open Data. Para ello, debo incluir además unasección que permita recibir sugerencias, publicar noticias relacionadas y casos de uso.

La solución debe cumplir con especial rigor las especificaciones de accesibilidad de entornos web indicadasen el PPT.

13.6 Capacidad y calidad tecnológica

Entre sus competencias, el Responsable del contrato, deberá supervisar la capacidad y calidad de losservicios prestados por la Plataforma, con especial atención a los aspectos tecnológicos de la misma, latransferencia tecnológica, la evolución de la Plataforma, la integración de servicios verticales y laimplantación de infraestructura, redes y comunicaciones. Para ello contará con el apoyo de la Comisión deDesarrollo, del personal municipal que se estime oportuno en cada momento y del servicio de consultoríaprestado por el Adjudicatario del contrato.

Con carácter general, las actuaciones principales en esta materia se describen en tres niveles:

A nivel estratégico:

Proporcionar soporte en materia de TIC's, en especial para planificar y gestionar los proyectosde integración de servicios verticales.

Asesoramiento para la definición de procedimientos, mapas, indicadores, informes, memoriasy estadísticas y cuadros de mando para la mejora de los servicios municipales.

A nivel técnico:

Ejecución, seguimiento y control de la planificación para la implantación de la Plataforma.

Planificación, coordinación, gestión, seguimiento y control de los proyectos y gestión de losrecursos necesarios para la integración de servicios verticales.

Definición y elaboración de mapas, indicadores, memorias y estadísticas, informes y cuadrosde mando para alimentar el cuadro de mando integral para el gobierno de la ciudad.

Consultoría, planificación, coordinación, ejecución y seguimiento y control de la integración dela Plataforma con los sistemas municipales.

Gestión de los dispositivos, medios y recursos asignados a la Plataforma.

Actividades de consultoría sobre la Plataforma, las Smart Cities y la integración de serviciosverticales.

49

http://datos.gob.es/


Actividades formativas relacionadas con el uso, gestión y mejora de la Plataforma.Generación y mantenimiento de procedimientos y documentación relacionada.

Soporte a gestores en la recepción, atención y resolución de consultas operativas eincidencias de funcionamiento.

Soporte y mantenimiento de las aplicaciones y funcionalidades desarrolladas en al marco dela Plataforma, incluyendo modificación y tareas de configuración de la solución ofertada paralas funcionalidades comunes de la Plataforma que resulten necesarias por cambios en lareglamentación u operatividad de la gestión durante la vigencia o prórrogas del presentecontrato.

Identificación y anticipación de posibles incidencias y desviaciones en la ejecución deproyectos dentro del marco de la Plataforma y sugerencia de correcciones y actuaciones.

A nivel operativo:

Actividades de gestión, supervisión, monitorización y control del funcionamiento de laPlataforma y de la prestación del servicio.

Actividades de reporte y resolución de incidencias, mantenimiento/actualización, adaptación omejora de la Plataforma.

Actividades horizontales de asistencia técnica al resto de componentes de la Plataforma.

Actividades de coordinación Ayuntamiento-Adjudicatario para la realización de las tareasencomendadas.

Elaboración de documentación, estudios e informes que el Ayuntamiento considere oportunossobre la gestión y seguimiento del servicio, la operativa y procedimientos de actuación, elmantenimiento o mejora de la Plataforma y la integración de servicios verticales.

Elaboración, gestión y actualización de la documentación técnica relacionada con el proyecto.

Realización de tareas de mantenimiento del conocimiento para el seguimiento de losacuerdos de nivel de servicio durante la vigencia del contrato.

13.6.1 Consultoría y Soporte tecnológico

13.6.1.1 Organización

Para realizar estas tareas, el Responsable del contrato, podrá contar con la colaboración del equipo deconsultoría y soporte tecnológico del adjudicatario.

Las necesidades de recursos son diferentes en función de las fases del proyecto, diferenciando comomínimo, las fases iniciales de desarrollo e implantación de la Plataforma y las fases posteriores deconsultoría y soporte tecnológico desde la puesta en marcha de la misma hasta la finalización del contrato.En estas últimas, se establecen, al menos dos niveles de atención con sus correspondientes característicasy necesidades. El equipo de primera atención será estable, con plena disponibilidad y dedicación a laslabores indicadas anteriormente y el equipo de segunda atención, tendrá una dedicación variable según lasnecesidades de consultoría, desarrollo o intervención de cada actuación.

El Responsable del contrato, en última instancia, será el encargado del seguimiento y control de estasactividades.

13.6.1.2 Lugar de prestación del servicio

El equipamiento, locales, suministros, licencias y, en general, las necesidades requeridas para la realizaciónde los trabajos de consultoría y soporte tecnológico serán a cargo del adjudicatario, salvo que elAyuntamiento, de forma temporal o permanente, en función de las fases y necesidades de cada actividad,adopte medidas para la utilización de medios, equipamiento o locales municipales.

50


La atención más cercana será prestada desde las dependencias del adjudicatario en el término municipal deLogroño (en adelante “instalaciones del adjudicatario”). La atención presencial 8x5 a la operativa diaria de laPlataforma se realizará desde dependencias municipales. Durante la vigencia del contrato, esta decisiónpodrá cambiar y seguirá el criterio de costes indicado anteriormente.

Las comunicaciones entre las instalaciones del adjudicatario y del Ayuntamiento se ajustarán a lasespecificaciones y requisitos que establezca el Ayuntamiento (VPN, certificados, etc.) y las especificacionesdel pliego en materia de seguridad y confidencialidad.

La empresa utilizará su propia conexión a Internet para comunicarse con el Ayuntamiento, con unacapacidad tal que ofrezca una velocidad de transferencia equivalente a la de los equipos conectados en lared local.

El adjudicatario debe disponer de personal de soporte especializado, propio o de terceros y sin ningún costepara el Ayuntamiento, para la resolución de cuestiones técnicas relacionadas con la Plataforma SmartLogroño que, por su dificultad, requieren la realización de consultas, estudios o actuaciones para suresolución.

Se deberá establecer un procedimiento de gestión que permita el control de incidencias, averías, mejoras oaclaraciones de forma que se agilice y facilite la gestión del conocimiento y la relación entre el adjudicatarioy el Ayuntamiento, automatizando en la propia Plataforma la obtención de informes, memorias yestadísticas, indicadores y cuadros de mando para la gestión y seguimiento del servicio prestado.

13.6.1.3 Prestación del servicio

Como mínimo, para la operativa diaria de la Plataforma, atención, registro, escalado y resolución deincidencias y consultas operacionales sobre la Plataforma, se establecerá un servicio 8x5 (8 horas al día, delunes a viernes, laborales según calendario de apertura del Ayuntamiento de Logroño) para el soportepresencial en las instalaciones municipales en horario de 8:00 a 14:00 y de 17:00 a 19:00. y un servicio24x7 (24 horas al día todos los días del año) para el soporte telefónico, cuya implantación será progresiva ya demanda del Ayuntamiento en función de las necesidades horarias de atención del CCI y de los serviciosverticales a integrar.

Para el resto de actividades de consultoría y soporte a desarrollo y evolución de la Plataforma seestablecerá de forma coordinada con los responsables municipales, un servicio de soporte que debe cubrircomo mínimo el calendario y horario municipal, tanto en primera atención como en otras necesidades.

13.6.1.4 Equipo de Trabajo

Por parte del Adjudicatario, existirán al menos responsables de proyecto equivalentes al equipo municipal yun equipo de trabajo formado por técnicos para cubrir los distintos “perfiles” necesarios según el ámbito y laactividad a prestar: jefe de proyecto, consultor de sistemas, analista funcional, desarrollador, formador,consultor, administrativo, experto, etc.

El equipo de trabajo de primera atención propuesto debe garantizar el cumplimiento y disponibilidad dehorarios en los servicios indicados para la tareas de atención y consultoría, tanto presencial como telefónica,tareas administrativas, tareas soporte a desarrollo y evolución de la Plataforma, etc. Como mínimo, deberácontar con personal cualificado para cubrir, en las instalaciones municipales, el servicio 8x5 que garantice laatención presencial a la operativa diaria de la Plataforma y, en la instalaciones del adjudicatario, las tareasde coordinación con el Ayuntamiento y la gestión y coordinación con el resto de recursos dedicados alproyecto por el adjudicatario.

Ajustándose a lo anterior, el adjudicatario debe indicar en la oferta la propuesta de estructura,funcionalidades y equipo humano soporte, según las fases y evolución del contrato, indicando el número depersonas, participación y dedicación que considere idóneo para el desempeño de las actividadesencomendadas y se compromete a mantener el equipo y dedicación propuesta. Cualquier alteración de lascondiciones de la propuesta deberá ser comunicada y autorizada por parte del Ayuntamiento de Logroño.Cualquier coste derivado de sustituciones o suplencias o incrementos de personal para cumplir loscompromisos adquiridos para la prestación del servicio será por cuenta del adjudicatario.

51


Igualmente, el adjudicatario debe incluir en la oferta la descripción de la operativa del servicio y lametodología de trabajo a utilizar para la gestión de los proyectos.

El equipo humano deberá contar con la capacitación y experiencia suficiente en los distintos módulos ytecnologías que conforman la Plataforma y en la metodología de trabajo a emplear.

Además de lo anterior, el equipo de trabajo se incrementará en una persona en dependencias y horariomunicipal, gran conocedor de la Plataforma y con capacidad polivalente para el análisis y desarrollo.Mantendrá la coordinación con el resto del equipo, aunque su actividad será directamente gestionada por elAyuntamiento de Logroño y orientada a la incorporación de contenidos y capacidades de la plataforma eintegración con sistemas municipales de menor entidad o no vinculados con proyectos de integración deservicios verticales.

En el apartado siguiente, se definen los acuerdos de nivel de servicio para la gestión de incidencias para laconsultoría y soporte tecnológico, así como las penalizaciones pertinentes si alguno de estos acuerdos noes cumplido por causas imputables al adjudicatario.

13.7 Acuerdos de Nivel de Servicio

La Plataforma tiene como objetivo proporcionar herramientas e información para realizar el seguimiento ycontrol de la gestión de los servicios que ofrece y facilitar la toma de decisiones sobre la gestión de laciudad. En esa misma línea, dentro de las actividades del servicio de consultoría y soporte tecnológico aprestar por el adjudicatario, se incluyen el desarrollo, la gestión y administración de los indicadores, informesy cuadros de mando para supervisar tanto el funcionamiento global de la Plataforma, con independenciaque la responsabilidad recaiga o no en el adjudicatario del servicio, como las diversas actuacionesrealizadas por el equipo de consultoría y soporte tecnológico.

Para ello, el adjudicatario debe:

Proporcionar procedimientos y herramientas integradas en la Plataforma que automaticen laprestación y seguimiento del servicio y permitan la recogida, registro, administración, escalado ygestión de la solución de incidencias de funcionamiento y de las consultas recibidas tantooperacionales como de evolución de la Plataforma.

Elaborar y mantener un cuadro de mando del cumplimiento de los ANS, automatizando laobtención de gráficas de evolución, informes y estadísticas, etc.

Realizar encuestas de satisfacción entre los usuarios de la Plataforma.

Al inicio del contrato se establecerá un catálogo inicial de indicadores para valorar la calidad y prestacionesdel servicio y las fases para su implantación, y se detallarán los acuerdos de nivel de servicio iniciales queserán incorporados al cuadro de mando de seguimiento del servicio de Plataforma.

Los indicadores iniciales, el cuadro de mando de seguimiento y los acuerdos de nivel de servicio inicialesentrarán en vigor un vez finalizada la fase de implantación de la Plataforma.

El catálogo y el cuadro de mando se irán ampliando y revisando durante la vigencia del contrato segúnevolucione la propia Plataforma hasta incluir, al menos, los indicadores que se proponen a continuación.

13.7.1 Indicadores de servicio de la Plataforma

Con carácter general, se proponen las categorías e indicadores objeto de incorporación al catálogo inicial:

Capacidades de la Plataforma: indicadores diversos relacionados con:

Gestión de Infraestructuras, sensores, dispositivos y otras fuentes de datos como el númerode dispositivos gestionados y de orígenes de datos externas.

52


Gestión de Aplicaciones/Funcionalidades como el número de aplicaciones/servicios comunesdisponibles y de servicios verticales integrados.

Gestión de Recursos Disponibles como el número de indicadores de gestión y monitorización,de informes, cuadros de mando y mapas de recursos, de procedimientos, guías ydocumentos, de recursos de información del Open Data.

Gestión de Usuarios: como el número de gestores internos, externos y sistemas conectados.

Procesos Tácticos y Operacionales indicadores diversos relacionados con:

Actividad de la Plataforma: como el número de sesiones abiertas, duración y tiempo medio,de gestores no conectados en el periodo, de informes emitidos y consultas realizadas porámbito.

Gestión de Portal Smart Logroño: como el número de accesos, duración y tiempo medio.

Gestión de Open Data: como el número de consultas realizadas, de descargas/suscripciones.

Gestión de Configuración: como el número de actualizaciones de versión de la Plataformarealizadas y de cambios/actualizaciones según distintos los tipos y componentes.

Actividades de Soporte a Usuarios:

El grado de satisfacción de la atención a usuarios.

Gestión de consultas/preguntas: como el número de consultas atendidas y el tiempomedio, máximo y mínimo de atención x tipología.

Gestión de incidencias: como el número de incidencias registradas, el tiempo derespuesta, resolución y cierre de incidencias, tiempo medio, máximo y mínimo, númerode “no conformidades”.

Actividades de Soporte al Responsable del contrato o a la Comisión de Desarrollo: como eltiempo dedicado según tipo de actividad (operativa, consultoría, análisis, desarrollo,formación, coordinación, etc.) por ámbito y persona.

Procesos Estratégicos

Gestión de ANS: como el número de incumplimientos de ANS, acumulado en un periodo, elnúmero de consultas/preguntas o incidencias no registradas y el de procedimientos odocumentación técnica que no están actualizados.

13.7.2 ANS de Gestión de Incidencias

Como se ha indicado anteriormente, el servicio incluye el soporte para los servicios prestados por laPlataforma. Dentro de estas actuaciones, los acuerdos de nivel de servicio se centran en la gestión globalde incidencias de la Plataforma, con independencia de que la solución de las mismas sea o noresponsabilidad del adjudicatario.

13.7.2.1 Definiciones

Incidencia: suceso o comportamiento de un equipo o funcionalidad informática que impide elnormal desarrollo de las labores del usuario. Se atenderán incidencias de servicio o aplicación enel ámbito de la Plataforma, generalmente detectadas por los usuarios finales de las aplicaciones,gestores o los equipos de soporte.

Herramienta de gestión de incidencias: aplicativo informático mediante el cual se registran yclasifican las incidencias reportadas, las tareas realizadas y la solución y conclusiones de lasmismas.

Canal: procedimientos y vías habilitadas para la comunicación de incidencias, como la herramientade gestión, teléfono de soporte, correo electrónico, etc.

Apertura de incidencia: comunicación de la incidencia al equipo de soporte por el canalcorrespondiente en el horario de servicio habilitado, generando incidencias en estado abierto.

53


Respuesta: primer diagnóstico o respuesta realizada por el equipo soporte y registrada en laherramienta de gestión.

Tiempo respuesta: El tiempo transcurrido desde la fecha y hora de apertura hasta la fecha yhora de respuesta a la incidencia.

Prioridad: valoración del alcance o severidad de la incidencia.

Alta: en alguno de los siguientes casos:

la incidencia afecta a la operativa general o disponibilidad del sistema.

la incidencia afecta a cualquiera de los procesos que están catalogados comocríticos. A definir según sea ventanilla, acceso ciudadano, periodo especial, gestiónen tiempo real, etc.

la incidencia afecta a un proceso con impacto económico.

la incidencia constituye una violación de seguridad o puede provocarincumplimientos legales.

Media: la incidencia afecta a un proceso que no está catalogado como crítico y el númerode usuarios o dispositivos afectados es significativo.

Baja: las no incluidas en las categorías anteriores.

Responsable Resolución: asignación del equipo responsable de la resolución de la incidencia.Puede ser el propio adjudicatario u otros.

Incidencias propias: son aquellas cuya solución corresponde al adjudicatario.

Resolución: subsanación o contestación de la incidencia por parte del responsable asignado. Si lasolución es temporal, la incidencia quedará en estado resuelto hasta la solución definitiva y cierrede la incidencia.

Tiempo de resolución: El tiempo transcurrido desde la fecha y hora de apertura hasta la fechay hora de respuesta.

Validación: En caso de no conformidad por parte del usuario o responsable técnico, seregistrarán las oportunas “no conformidades” sobre la solución propuesta. En caso deconformidad, se registrará la aceptación por parte del usuario o responsable técnico.

Cierre: una vez resuelta y, después de ser aceptada, la incidencia se cierra de forma definitivafinalizando su ciclo de vida.

Número de incidencias: Número de incidencias acumuladas en un período de tiempo.

Número de incidencias propias: Número de incidencias competencia del adjudicatario acumuladasen un período de tiempo.

13.7.2.2 Indicadores

Se establecen dos indicadores sobre el tiempo de respuesta y el tiempo de resolución de incidencias.

Indicador 01. Tiempo de respuesta (TRP) a incidencias

Objetivo: < 45 min. en el 98 % de los casos.

Descripción: Medición del % de cumplimiento del objetivo establecido de tiempo de respuesta a incidencias.

Periodo de aplicación: mensual Importancia: alta

Dimensiones:

Valor Rebaja en la factura

Entre 97% y 95% Hasta 100 €



Menos de 70% Hasta 500 €

54


Forma de medición: Calcula en porcentaje un índice cuyo numerador es el número de incidencias que cumplen elobjetivo señalado para el indicador y su denominador es el nº total de incidencias del periodo.

Nº de incidencias del periodo TRP<45 min % cumplimiento de TRP = ---------------------------------------------------------------- * 100

Nº total de incidencias del periodo

Origen: Herramienta de gestión de incidencias

Indicador 02. Tiempo de resolución (TRS) a incidencias propias

Objetivo: inferior a los tiempos máximos acordados según modalidad de servicio y prioridad de la incidencia.

Tiempos máximos Baja Media Alta

Servicio 8x5: < 3 días 90 % casos < 1 día 90 %casos < 4 horas 90 %casos

Servicio 24x7: < 10 días 90 % casos < 4 días 90 %casos < 1 día 90 %casos

Descripción: Medición del tiempo de resolución de incidencias según soporte y prioridad

Periodo de aplicación: mensual Importancia: alta

Dimensiones:

Valor Rebaja en la factura



Menos de 70% Hasta 500 €

Forma de medición: Calcula en porcentaje un índice cuyo numerador es el número de incidencias que cumplen elobjetivo señalado para el indicador según la modalidad y prioridad de la incidencia y su denominador es el nº total deincidencias de esa modalidad y prioridad en el periodo.

Nº de incidencias del periodo TRS < [tiempo máximo]% cumplimiento de TRP = ------------------------------------------------------------------------------ * 100

Nº total de incidencias del periodo

Origen: Herramienta de gestión de incidencias

El adjudicatario debe incluir en la oferta una propuesta de acuerdos de nivel de servicio que incluya elprocedimiento, operativa, indicadores y la herramienta de gestión a utilizar. Al inicio del proyecto, lapropuesta debe ser acordada y aprobada definitivamente por el Ayuntamiento.

La propuesta del adjudicatario, como mínimo, debe ajustarse a las consideraciones indicadas anteriormentesobre el horario, disponibilidad, personal asignado al servicio, indicadores y actuaciones para:

1. Recibir, registrar, catalogar y evaluar las incidencias y consultas recibidas.

2. Trasladar las mismas al equipo responsable.

3. Dentro de las que sean del ámbito de actuación del adjudicatario

Resolver en un primer nivel de atención o escalar al siguiente nivel.

Resolver en un segundo nivel de atención o requerir intervención adicional.

55


13.8 Incumplimientos específicos

Se considerará falta sancionable toda acción u omisión del adjudicatario que suponga un quebranto de lasexigencias especificadas en el PPT y constituyen incumplimientos de esta prestaciones contratadas, cuandomenos, los siguientes:

13.8.1 Incumplimientos Leves

De forma general, serán consideradas como incumplimientos leves todas aquellas infracciones del PPT notipificadas como graves o muy graves y siempre que no se aprecie la circunstancia de reiteración.

Y en particular:

No cumplir las instrucciones comunicadas de forma oral por el Responsable del contrato opersonal asignado al seguimiento técnico de la Plataforma.

Retraso en la disponibilidad establecida para los indicadores, informes y cuadros de mandogestionados en la Plataforma.

El trato incorrecto de los empleados de la empresa adjudicataria a los gestores y usuarios de laPlataforma, a los compañeros, a superiores o subordinados o a los funcionarios municipales.

El incumplimiento de los horarios establecidos para el servicio, retraso en el inicio, ausencia nojustificadas o la finalización anticipada durante la prestación del mismo.

La no suplencia, en casos de ausencia o enfermedad de los trabajadores habituales o la nosustitución de los mismos con personal de similar cualificación.

El uso descuidado o incorrecto de los recursos, instalaciones o materiales del Ayuntamiento deLogroño.

La utilización de la Plataforma y de los medios municipales para fines distintos a los que estándestinados por la Administración municipal o de los que se desprenden de las funcionesestablecidas en el pliego de prescripciones técnicas para los servicios contratados sin laautorización de los funcionarios municipales o en casos de razonable necesidad.

13.8.2 Incumplimientos graves

De forma general, serán consideradas como incumplimiento grave haber sido sancionado con tresincumplimientos leves en el periodo de un año.

Y en particular:

El incumplimiento de las características y especificaciones de los elementos software y hardwareincluidos en el presente contrato.

La incorrecta ejecución, retraso, negligencia o descuido en el cumplimiento de las funciones ytareas establecidas en el PPT.

El maltrato de las instalaciones, mobiliario o enseres por parte del personal del adjudicatario.

La sustracción de materiales.

La simulación, engaño u ocultación de información o incidencias durante la prestación del servicio.

La falta de respeto y consideración para con los gestores y usuarios de la Plataforma,compañeros, subordinados, superiores o funcionarios municipales por parte del personal de laempresa contratada.

La pérdida de materiales o de información, cuya propiedad corresponda al Ayuntamiento deLogroño, durante la prestación de los servicios contratados.

El incumplimiento de las obligaciones que en materia de protección de datos, seguridad yconfidencialidad se fijan el PPT que no tengan la consideración de muy grave o sean causa deresolución de contrato.

56


13.8.3 Incumplimientos muy graves

De forma general, serán consideradas como incumplimiento muy grave haber sido sancionado con dosincumplimientos graves en el periodo de un año.

Y en particular:

Los insultos graves o amenazas a ciudadanos, compañeros, subordinados, superiores ofuncionarios municipales.

No cumplir las instrucciones comunicadas por escrito por el Responsable del contrato o personalasignado al seguimiento técnico de la Plataforma.

El maltrato o pérdida intencionada de los recursos, instalaciones, o materiales del Ayuntamiento deLogroño.

El uso de recursos o información municipal para actividades no relacionadas con el propósito delcontrato, o bien, la extralimitación en su uso.

El incumplimiento de las obligaciones que en materia de protección de datos, seguridad yconfidencialidad se fijan el PPT.

13.8.4 Penalidades especiales

El régimen de penalidades para los incumplimientos específicos indicados, será el siguiente:

Incumplimientos leves Hasta 300,00 €

Incumplimientos graves De 301,00 a 600,00 €

Incumplimientos muy graves De 601,00 a 1.000,00 €

La penalidad es compatible y por lo tanto podrá añadirse si concurren la oportunas indemnizaciones pordaños o perjuicios causados a la administración municipal.

13.9 Formación y Transferencia Tecnológica

La formación es un elemento fundamental para dotar a las personas de los conocimientos y las habilidadesnecesarias para abordar con éxito el cambio hacia modelos de gestión de los servicios basados en laintegración de recursos y el uso intensivo de tecnologías. El adjudicatario se compromete a mantener unacolaboración ágil y constante con el personal municipal y realizar una correcta formación y transferenciatecnológica que garantice el conocimiento y manejo de la Plataforma por parte del personal técnico y degestión designado por el Ayuntamiento y a mantener en todo momento formado e informado al personal desistemas en relación a las infraestructuras y software utilizado en la Plataforma (instalación de equiposcentrales, puestos de trabajo, software base y específico relacionado con el proyecto, etc.).

El adjudicatario debe incluir en la oferta para su valoración:

1. Plan de Formación que incluya acciones formativas orientadas a distintos colectivos:

Gestores y Técnicos en aspectos relacionados con Redes de Comunicaciones y Plataforma.

Decisores responsables del gobierno de la ciudad y gestión de servicios integrados.

Personal del CCI en los sistemas y funcionalidades incluidas en la Plataforma para eldesarrollo de su atención. (La planificación de esta formación debe contemplar laimplantación de las funcionalidades de gestión descrita en el PPT y el momento de laintegración del servicio de Atención Ciudadana en el CCI).

Se deberán detallar los perfiles, contenidos, duración y temporalidad, etc. de los cursos yactividades a realizar.

57


2. Plan de Transferencia Tecnológica con detalle del alcance, medios, recursos, temporalidad yactuaciones a realizar.

La transferencia del conocimiento debe extenderse en un sentido amplio y debe permitir alpersonal municipal avanzar de forma autónoma en la mejora y ampliación de funcionalidades ycontenidos de los distintos servicios municipales. Ente las medidas incluidas, la oferta debecontemplar propuestas orientadas a la adquisición por parte del personal municipal de desarrollosde referencia o guía para la incorporación de contenidos de distintos tipos y orígenes deinformación, la obtención de informes y cuadros de mando y la integración con sistemasmunicipales.

Se valorarán las actuaciones propuestas y recursos comprometidos para el trasvase de conocimiento alpersonal municipal y la proximidad y disponibilidad del canal de comunicación propuesto.

13.10 Continuidad de la Plataforma, protección de datospersonales, seguridad y confidencialidad de la información

13.10.1 Continuidad

La Plataforma constituye una apuesta por un modelo de gestión que supera la duración del presentecontrato. Por ello, es objetivo del Ayuntamiento garantizar y salvaguardar la Plataforma y prevenirsituaciones que dificulten o impidan su plena utilización o desarrollo de funcionalidades, como puedan ser lafalta de asistencia/soporte por parte del adjudicatario o la obsolescencia de la tecnología empleada.

El adjudicatario acepta expresamente que la titularidad de los derechos de propiedad intelectual y/oindustrial de los desarrollos de programas realizados para el presente contrato, así como de ladocumentación generada al amparo del mismo pertenecerán en exclusiva al Ayuntamiento de Logroño.

Toda la documentación específica del contrato quedará en propiedad del Ayuntamiento de Logroño sin queel adjudicatario pueda conservarla o facilitarla a terceros sin la expresa autorización de éste, que en sucaso, podría concederse previa petición formal con expresión del fin.

El adjudicatario deberá entregar obligatoriamente al Ayuntamiento de Logroño el código fuente de losdesarrollos de los programas realizados en el marco del presente contrato y garantizar que el código fuentecubra la funcionalidad completa de la plataforma de Gestión Integral objeto del contrato. Además, eladjudicatario se compromete a proporcionar una solución de continuidad, en caso de cese en su actividad através del correspondiente contrato de depósito de los códigos fuentes debidamente actualizados a laversión implantada en producción durante la vigencia del contrato, asociados a los derechos de propiedadintelectual, propiedad del adjudicatario habitualmente conocido como “Escrow Agreement” o bajo cualquierotra circunstancia imputable a dicha empresa, previa audiencia de la misma, siempre y cuando se acreditela imposibilidad del correcto mantenimiento de los programas.

El adjudicatario no tendrá la obligación de entregar los códigos fuentes de los programas existentes antesde la adjudicación del contrato.

13.10.2 Protección de datos personales

El adjudicatario y el personal a su servicio en la prestación del contrato están obligados a cumplir todas lasmedias y disposiciones que en materia de Protección de Datos de Carácter Personal se encuentren en vigora la adjudicación del contrato o que puedan estarlo durante su vigencia.

Para los casos en los que la prestación del servicio incluye acceso a datos personales, se deberá formalizarel correspondiente contrato de acceso a datos con las instrucciones del responsable del tratamiento delfichero afectado.

58


13.10.3 Seguridad

El acceso y utilización por parte del adjudicatario de los recursos y sistemas informáticos municipales seajustará a las especificaciones, procedimientos y requisitos que establezca el Ayuntamiento (medidas deseguridad, acceso y conexión, VPN, certificados, etc.), debiendo comprometerse al uso adecuado de losmismos y a tratar únicamente la información autorizada a la que tenga acceso para la prestación delservicio, a no utilizar la información para otros fines que los recogidos en el presente Pliego, así como a noextraerla, copiarla, cederla, publicarla o venderla total o parcialmente, ni en soporte informático ni en papel.

A la finalización del contrato, el adjudicatario procederá a la devolución, si existieran, de los soportes deinformación facilitados por el Ayuntamiento y a la descarga o eliminación segura de la misma en los equiposinformáticos utilizados para la prestación del servicio.

13.10.4 Confidencialidad

El adjudicatario estará obligado a mantener la más absoluta confidencialidad y reserva de todos aquelloshechos, informaciones, conocimientos, documentos y otros elementos a los que tenga acceso con motivo dela prestación del servicio, autorizando el acceso, exclusivamente, a aquellas personas estrictamenteimprescindibles para el desarrollo de las tareas inherentes a este contrato. Todas ellas serán advertidas delcarácter confidencial y reservado de la información. En ningún caso deberán emplearse documentos o datoscon finalidad distinta de la prevista, ni comunicarse o transferirse a terceros.

Por su parte, el Ayuntamiento de Logroño adoptará las medidas suficientes para que los derechos, ladocumentación y los códigos fuentes entregados por el adjudicatario sólo beneficien a esta entidad local yno a eventuales futuros adjudicatarios para actividades ajenas a las adjudicadas por el Ayuntamiento deLogroño.

El adjudicatario deberá informar a sus empleados y colaboradores de las obligaciones y compromisos enesta materia y establecer las medidas de seguridad necesarias para protegerla, como restringir el acceso a lainformación exclusivamente a los empleados involucrados, implantar medidas técnicas frente a potenciales atacantes,seguir las pautas legales obligatorias, etc. Del mismo modo, el adjudicatario deberá incluir una cláusula deconfidencialidad y secreto en los términos descritos (art. 10 LOPD) en los contratos laborales que suscribanlos trabajadores destinados a la prestación del servicio objeto del presente pliego.

13.11 Evolución de la Plataforma

Al inicio de proyecto, se realizará la implantación y adaptación de las funcionalidades básicas de laPlataforma y el desarrollo de los servicios comunes especificados. Una vez probada y testada y, en paralelocon el desarrollo y adaptación de las funcionalidades indicadas de gestión y gobierno de la ciudad yrelaciones con los ciudadanos, la Plataforma estará operativa para la evolución continua de funcionalidadesy contenidos por la incorporación de nuevas verticales o integración con los sistemas municipales

13.11.1 Evolución Funcional

La actividad de consultoría y soporte técnico compromete al adjudicatario a colaborar y participar de formaactiva en el estudio, valoración y desarrollos necesarios para la mejora o ampliación de servicios verticales ofuncionalidades de la Plataforma.

13.11.1.1 Actualización del software de la Plataforma

Durante la duración del contrato, el adjudicatario se compromete a proporcionar e instalar sin costeadicional, las versiones y evolución de los aplicativos y funcionalidades incluidas en la oferta y desarrolladoscon anterioridad a la adjudicación del contrato.

59


Las versiones y evolución de funcionalidades de los desarrollos realizados para el Ayuntamiento de Logroñoen el ámbito del presente contrato y las necesidades de ampliación de servicios en la Plataforma porincorporación de nuevos desarrollo comunes propios, de terceros o por interoperabilidad con otrasplataformas serán objeto de estudio por parte del Ayuntamiento para ser incluidas como parte de la actividadde consultoría y soporte técnico del presente contrato, en función del alcance, impacto en las aplicaciones ydisponibilidad de recursos.

13.11.1.2 Integración/Ampliación de servicios verticales

Entre las actividades a realizar, se elaborará y mantendrá un procedimiento general para la integración deservicios verticales que detalle con claridad las fases y tareas de interconexión e integración en laPlataforma e incluya la documentación técnica necesaria.

La Plataforma debe estar diseñada para permitir y facilitar distintos grados o niveles de integración deservicios verticales en función de su ámbito, interés y capacidad: desde una integración mínima en la que elservicio aporta solo los datos a la Plataforma hasta una integración plena en la que el servicio comparte losdatos y utiliza para su gestión componentes y funcionalidades proporcionados por la misma.

Cada nueva incorporación o mejora de servicios verticales dará lugar a un “Proyecto de integración” condetalle de los objetivos, alcance, necesidades, responsabilidades y plazos para la integración yespecificaciones particulares. A través de las actuaciones de consultoría de este contrato, el adjudicatario secompromete a participar de forma activa en la consecución de los objetivos del proyecto

El proyecto, en cuanto a la integración del servicio en la Plataforma, será supervisado y controlado por elResponsable del contrato a través de la Comisión de Desarrollo, adaptando su composición yfuncionamiento a las necesidades de cada caso y estableciendo actuaciones y recursos destinados agarantizar el soporte tecnológico necesario para la ejecución del mismo.

Para ello, el servicio de soporte tecnológico y consultoría de la Plataforma, será responsable al menos de:

1. Mantener y aportar la Documentación Técnica de las capacidades y especificaciones deintegración en la Plataforma de gestión.

2. Participar en el comité de seguimiento y control de los proyectos de integración.

3. Tareas de consultoría y soporte técnico a los proyectos de integración como miembro del equipomultidisciplinar creado para su ejecución.

4. Evolución y ampliación de mapas indicadores, informes y cuadros de mando de los serviciosmunicipales con la incorporación de nuevas funcionalidades o contenidos.

13.11.2 Evolución de Contenidos

La ampliación de los contenidos de la base de información de la Plataforma:

1. Incorporación de nuevos datos a la red sensórica provenientes de:

La ampliación de la red de sensores conectados físicamente a la Plataforma o inclusión denuevos sensores de los servicios verticales.

Otros sistemas externos, a través de conexiones de Open Data, API's abiertas, etc.

2. Incorporación de nuevos contenidos georreferenciados en el Sistema Gis Municipal y contenidosde los sistemas municipales.

3. La integración de nuevos servicios verticales o proyectos estratégicos municipales.

4. La generación de datos de valor añadido a partir de datos contenidos en la Plataforma.

5. Datos provenientes de redes sociales.

6. La información proveniente de sistemas externos conectados a la Plataforma.

60


13.11.3 Contrato de Mantenimiento

Además, la oferta debe incluir un Contrato de Mantenimiento de la Plataforma con detalle de opciones,niveles de servicio y su correspondiente valoración económica.

La adjudicación de este contrato no vincula la aceptación del Contrato de Mantenimiento. A la finalizacióndel contrato, el Ayuntamiento de Logroño podrá suscribir alguna de las modalidades ofrecidas en lostérminos indicados en la oferta que resulte adjudicataria.

13.12 Verificación de la Plataforma

Al objeto de verificar la correcta instalación y funcionamiento de la Plataforma, al inicio del contrato darácomienzo un “Proyecto Piloto” a realizar por el Adjudicatario con la colaboración del personal municipal.

El proyecto será el propuesto por el Ayuntamiento, acordando con el adjudicatario detalles sobre el alcance,especificaciones y plazos y debe ser de una dimensión adecuada para ejecutarse en el menor plazo posible,a la vez, suficiente para permitir al Ayuntamiento verificar el grado de desarrollo de los componentesincluidos en la oferta y la plena capacidad operativa de la Plataforma para iniciar los proyectos deintegración de los servicios verticales.

El proyecto incluirá al menos:

1. La conexión de al menos dos fuentes de datos diversos de sistemas disponibles para verificar lacapacidad de incorporación de datos a la Plataforma.

2. La visualización de datos en mapas y la elaboración de informes, indicadores y un cuadro demando que permita verificar las capacidades analíticas y de gestión de la Plataforma.

3. La integración con los servicios horizontales de forma completa o, al menos, registro de datos ysimulación de funcionalidades.

4. La puesta a disposición de los contenidos para el gobierno de la ciudad y el portal Smart Ciudad o,como mínimo, demostración y simulación de mecanismos y procesos necesarios para verificar sufuncionamiento hasta la puesta en marcha definitiva.

5. La integración de estos contenido en un sistema municipal en colaboración con el personalmunicipal.

6. La publicación automatizada en el Catálogo Open Data o, al menos, simulación de funcionalidadeshasta que el Catálogo esté operativo.

13.12.1 Propuesta Proyecto Piloto

El Ayuntamiento de Logroño para la gestión del ciclo del agua de abastecimiento de la ciudad dispone deuna Estación de Tratamiento de Agua Potable (ETAP) cuyas las instalaciones están ubicadas en elmunicipio de Lardero. La ETAP cuenta con un moderno sistema de gestión que incluye la lectura on/line detres contadores de caudal a la salida de la ETAP y otros 6 más repartidos en puntos estratégicos de la redde distribución, aunque solo el de Valdegastea está conectado. Dada la diferencia de altitud entre Logroño yla ETAP, el sistema dispone de unas válvulas reguladoras de la presión del agua que permiten mantener lamisma en los valores establecidos.

Además, es posible disponer de información de sondas que aportan valores de pluviometría, temperatura,humedad, etc. tanto de la Comunidad Autónoma de La Rioja como del propio Ayuntamiento y así estableceruna valoración sobre la incidencia de las distintas situaciones en las variaciones del caudal.

La Unidad Municipal de Aguas cuenta con una base de datos MS Access 97 para gestionar el consumo deagua. Esta base de datos gestiona alrededor de 61.000 contratos, de consumo doméstico y no doméstico,distinguiendo los contratos según las distintas tipologías. Las lecturas de los contadores se realizansemestralmente obteniendo la información desde distintas fuentes: lectores, tarjeta de lectura o lectura en laweb aportada por los interesados.

61


El piloto debe incluir:

1. Captación de datos de sensores.

Las lecturas on/line de los contadores de caudal indicados anteriormente y registrar datoshistóricos para análisis y evaluación de los mismos.

Datos de las válvulas reguladoras de la presión del agua. Estos datos se encuentran en lasinstalaciones de la ETAP y el sistema de comunicaciones actual permite procesos puntualesde captación de datos y generación de avisos.

Datos atmosféricos: (temperatura, pluviometría, ...)

2. Integración de datos de sistemas municipales. El piloto debe integrar los datos del sistema degestión:

de habitantes para realizar el cálculo de indicadores (sistema IBM AS/400).

de consumos de contadores.

Sistema georreferenciado de la Plataforma para la confección de mapas y selección dezonas/territorio por parte de los gestores municipales.

3. Alertas e incidencias: el piloto integrará en el sistema de incidencias de la Plataforma una “alerta”cuando las válvulas de regulación de presión alcancen un valor establecido.

4. Capacidad Análisis. El piloto debe incluir:

Confección de cuadros de control específico: Confección de un cuadro de control con el ciclode caudal, caudal máximo, mínimo, según selección temporal.

Confección de indicadores: consumos agua por habitante y año.

Incidencia de las temperaturas, pluviometría, ... en el caudal de agua.

Información detallada y agrupada de consumos en Instalaciones Municipales (identificadaspor un tipo de contrato).

Implementar Informes gráficos sobre los objetivos de:

Minimizar el consumo de agua por hogar.

Consumo doméstico < nn (por ejemplo 100) litros por persona y día que muestren, almenos:

La evolución del consumo x tipo, habitante y día.

Tendencia decreciente = valoración positiva o la contraria.

5. Visualización georreferenciada:

Visualización del mapa de consumo medio x habitante y año por zonas establecidas osectores seleccionados y con capacidad para interactuar comparando zonas seleccionadas,…

Visualización del mapa de consumo no doméstico x categorías de contratos (edificios einstalaciones municipales, fuentes, …).

6. Integración con el Gobierno de la Ciudad: Dada la diferencia en los plazos de implantación, elpiloto debe incluir, al menos, los mecanismos y capacidades de integración de los contenidos en lagestión global de la ciudad.

7. Integración con las relaciones con el Ciudadano.

Portal Smart Logroño: mecanismo para visualizar el mapa consumo medio x habitante y losindicadores que se establezcan.

Portal Open Data.

Consumos medios de agua por habitante y año.

Indicadores establecidos.

62


Publicaciones de datos de calidad del agua (cloro, turbidez, etc): Boletines analíticos

8. Integración, al menos, en un sistema municipal a establecer por el Ayuntamiento y desde el que seaccederá a contenidos desarrollados en el proyecto piloto. Esta integración en la parte del sistemamunicipal se realizará en colaboración con el personal municipal.

El proyecto incluye la carga de datos históricos de caudales y de consumos, al menos de los últimos 5 añospara permitir comparaciones entre indicadores.

13.13 Hitos y Planificación

El adjudicatario debe incluir en la oferta la planificación completa y detallada del proyecto que deberá teneren cuenta una serie de hitos y fases generales que el Ayuntamiento determina para disponer de laPlataforma con capacidad operativa e iniciar los procesos de integración de servicios verticales.

Se establece como punto de partida (Fase 1) y referencia para el cómputo de tiempo la realización de lasactuaciones de “inicio del proyecto” y la disponibilidad de las infraestructuras a aportar por parte delAyuntamiento.

La planificación incluye:

El despliegue operativo de elementos básicos de la Plataforma en las 5 primeras semanas (Fase2)

Un periodo adicional hasta los 4 meses (Fase 3) para los desarrollos y actuaciones que permitanverificar la operatividad de la Plataforma.

La implantación y despliegue completo de la Plataforma no superará los 8 meses (Fase 4).

Con carácter general, a continuación se establecen los hitos y el plazo máximo de realización defuncionalidades y actuaciones identificadas en la Plataforma.

ACTUACIONES F1 F2 F3 F4

Actuaciones de inicio del proyecto y disponibilidad de las infraestructuras.

Instalación del software base de la plataforma para el acceso, auditoría, monitorización,seguridad, etc.

Despliegue de los repositorios de datos.

Despliegue de las capacidades de captación, normalización, integración einteroperabilidad de la plataforma con el IoT, servicios municipales y otras plataformas,incluyendo Conectores (con diversos protocolos) y API de integración e interoperabilidad.

Despliegue de las capacidades de gestión (Interfaz de usuario web, API abierta tipoREST, web service, etc.) y de ejecución: Motor de Reglas, Gestor de Eventos, Gestor deDispositivos, funcionalidades para de extracción transformación y carga de información.

Despliegue de la capacidad Analítica.

Despliegue de la capacidad georreferenciación e Integración con el Sistema GISMunicipal.

Desarrollo de Integraciones de IoT y Servicios Municipales para Proyecto Piloto.

Puesta en marcha del sistema de Averías e integración de datos de valor añadido.

Puesta en marcha del sistema de Atenciones.

Puesta en marcha del sistema de Quejas y Sugerencias (fase I).

Puesta en marcha del sistema de Afecciones (fase I).

Despliegue del cuadro de mando Operacional de Servicio de la Plataforma incluyendoindicadores de negocio y calidad.

Despliegue del cuadro de mando Operacional de Servicio del CCI a plataforma

63


incluyendo indicadores de negocio, calidad y seguimiento de la actividad y prestaciones.

Despliegue del cuadro de mando Operacional de Soporte Tecnológico.

Despliegue de la capacidades de los servicios comunes requeridos en la Plataforma:•Gestión del Catálogo de Recursos Materiales incorporados en la Plataforma.•Gestión de Recursos Humanos del personal relacionado con la Plataforma (nivel básicode inventario para averías, actuaciones ,... )•Gestión Económica con funcionalidades para el seguimiento y control de la propiaplataforma y los servicios verticales integrados.

Desarrollo e implantación del Proyecto. Piloto

Despliegue Cuadro mando Ejecutivo o Global de Gestión de la Ciudad

Completar la integración de datos del Sistema GIS Municipal

Implantación de Portal Open Data.

Implantación de Portal Smart Ciudad.

Publicación de la API abierta, Kit de Desarrollo, etc. para la promoción de la participacióny la innovación.

Finalización del sistema de Quejas y Sugerencias (fase II).

Finalización del sistema de Afecciones (fase II).

Despliegue de la capacidades de los otros servicios comunes opcionales.

13.14 Documentación Técnica

La traspaso tecnológico se completa con los entregables de documentación a generar. El adjudicatario secompromete a generar y proporcionar, como mínimo, la documentación siguiente:

Arquitectura de la Solución: Redes y comunicaciones, Plataforma e Integración con el resto desistemas de la solución.

Bases de datos: modelos de datos, estructura y localización de datos.

Documentación de Administración, Gestión y Configuración de la Plataforma.

Descripción de las interfaces y operativa de cada componente e interoperabilidad entre ellos.

Descripción de las interfaces para la integración de funcionalidades.

Documentación de Operación: Manuales de instalación, paso entre entornos y detección yresolución de problemas.

Documentación de Usuario: manual de gestión, manejo de la interfaz, interfaces de análisis yexplotación de datos.

La documentación incluye las diferentes versiones que se generen y se realizará tanto en papel como ensoporte electrónico editable.

64

ANEXO C:

SISTEMA DE QUEJAS Y SUGERENCIAS


14 ANEXO C: Sistema de Gestión de Quejas y SugerenciasEl sistema de quejas y sugerencias es un componente fundamental en la atención ciudadana. ElAyuntamiento de Logroño tiene avanzado el proyecto de renovación del actual sistema de quejas cuyaimplantación se incorpora en la fase inicial del este proyecto para mejorar su integración con la Plataforma yla interoperabilidad con los sistemas utilizados por el servicios de información y atención ciudadana.

El proyecto nace de la experiencia del sistema actual y del estudio realizado por Ayuntamiento de Logroñode las nuevas funcionalidades orientadas a conseguir una gestión más rápida y eficaz, adaptada a laorganización municipal y a los canales de comunicación existentes en la actualidad y que facilite elcumplimiento de los compromisos adquiridos con la ciudadanía en la respuesta a sus peticiones.

El proyecto se inicia con el diseño y las especificaciones técnicas de un modelo de datos, gestión yprocesos que recoja las funcionalidades descritas más adelante adaptadas al entorno tecnológico delproyecto: se diseñarán las estructuras de datos, los estilos de las pantallas, el acceso y seguridad, lasopciones de configuración, la presentación y navegación, la nomenclatura a utilizar, la arquitectura delcódigo, las plantillas tipo de las pantallas y formularios de gestión, los módulos y funcionalidades comunesal proyecto, los procesos a realizar y las llamadas entre los mismos.

La arquitectura del sistema permitirá especificar y modelar las particularidades de los distintos tipos depetición descritos anteriormente en cuanto al registro y tramitación o ciclo de vida y compartir el resto defuncionalidades de selección y filtrado, explotación, configuración, seguridad y perfiles, procesos y avisos eintegración con otras aplicaciones.

Se aprovecharán al máximo las opciones y posibilidades de la base de datos indicada en el apartado deentorno tecnológico del presente pliego, desarrollando en procedimientos almacenados las funcionalidadesde la capa de negocio.

En la elaboración de este modelo participarán personal municipal y de la empresa adjudicataria, siendofinalmente aprobado por el Ayuntamiento de Logroño.

En la oferta se deberá incluir una propuesta no vinculante de diseño y navegación de la operativa debúsqueda y consulta de peticiones.

Una vez establecido este modelo se realizará el diseño técnico necesario para el desarrollo de los distintoscomponentes y, una vez aprobado por el Ayuntamiento de Logroño, se continuará siguientes fases deldesarrollo de proyectos: pruebas, formación e implantación del sistema.

Del mismo modo que sucede en el sistema actual, aunque las quejas y sugerencias son el objeto principaldel aplicativo de gestión, el sistema debe gestionar diversos tipos de información (peticiones) adaptando sufuncionalidad a las necesidades de cada uno y disponer de una arquitectura que facilite la incorporación denuevos tipos de petición. Así, el sistema incluye inicialmente la gestión de:

Quejas y Sugerencias: comunicación de quejas o sugerencias realizadas ciudadanos en distintosmedios que se registran de forma manual o automática según su procedencia. En función delcontenido, la Unidad de Participación Ciudadana (en adelante UPC), decreta a la correspondienteunidad municipal donde se elabora la contestación que es remitida al ciudadano por la UPC.

Solicitudes de información: consultas o peticiones diversas realizadas por los ciudadanos en laweb en las secciones habilitadas en cada servicio municipal. Se tramitan con el mismoprocedimiento que las quejas y sugerencias.

Indicación de Averías en la ciudad: de reciente implantación. Gestiona indicaciones de losciudadanos de situaciones de peligro en la ciudad que se corresponden con un catálogo deaverías cuyo compromiso de subsanación es de 72 horas, Se tramitan de forma similar a lasquejas y sugerencias aunque se decretan de forma automática según el catálogo y añaden uncomponente de ubicación o geoposicionamiento en el mapa, cálculo de los plazos comprometidosy avisos específicos.

Solicitudes de visita a la Alcaldesa: peticiones de cita con la Alcaldesa que se canalizan a launidad correspondiente.

Solicitudes de visita al Teatro Bretón: peticiones de visita al Teatro que se canalizan a la unidadcorrespondiente.

66


Solicitudes de visita a Centros Municipales: peticiones de visita a otras instalaciones que secanalizan a la unidad correspondiente.

Suscripción al De Buena Fuente: suscripciones a la publicación municipal semanal que secanalizan a la unidad correspondiente.

Suscripción a la publicación del Teatro Bretón: suscripciones a la publicación con laprogramación del Teatro Bretón que se canalizan a la unidad correspondiente.

A continuación se indican las características generales del sistema con un nivel de detalle suficiente paravalorar las funcionalidades requeridas y el alcance del proyecto. En la fase inicial del mismo se identificaráncon mayor precisión y detalle los requisitos del sistema sin que esto pueda suponer un cambio significativoen las funcionalidades indicadas.

14.1 Registro de Peticiones

La grabación en el sistema de esta información se realiza de dos formas:

Manual: desde la atención telefónica o presencial, desde la inspección de buzones físicos oelectrónicos o desde apartados específicos en medios de comunicación.

Automática: (vía servicio web) desde los distintos formularios existentes en la web municipal odesde la aplicación para móviles "logroño.es".

En la grabación se procederá a verificar y registrar la información recogida validando la misma contra lasdiferentes Tablas Auxiliares que corresponda a cada caso y la existencia de información obligatoria segúnlos distintos tipos de petición.

De forma general, salvo decretación automática, es la UPC la encargada de distribuir las peticiones entre launidad o unidades implicadas y, una vez contestadas por éstas, la responsable de comunicar al ciudadanosolicitante el resultado de las mismas.

14.1.1 Información manejada

Con carácter general, se indica la información a manejar en el registro de peticiones, si bien en el apartadocorrespondiente se especifica con mayor detalle:

Datos Generales

Tipo de Petición se registra de forma obligatoria seleccionando un valor de entre los existentes en la tablaauxiliar de Tipos de Información. En algunos casos se establece un subtipo de petición a determinar entrelos existentes en la tabla auxiliar de subtipos de Información.

Lugar de Entrada se registra de forma obligatoria seleccionando un valor de entre los existentes en la tablaauxiliar de Origen.

Fecha y Hora de Registro: Se creará de forma automática la fecha y la hora en que se registra la petición yno podrá ser modificada por el gestor.

Número: Se asignará a cada petición un número único obtenido de la secuencia: PET_NUM_QYS.

67

Peticiones

Quejas y Sugerencias

Solicitudes de Información

AveríasSuscripción a Publicaciones

Visitas Alcaldesa

Visitas Centros


Estado: Las peticiones se grabarán con un estado inicial que refleja la situación y permite gestionar laacciones a realizar.

Observaciones: De forma opcional, se permitirá a los gestores indicar observaciones públicas (visibles porgestores y solicitantes) y privadas (no visibles por solicitantes).

Datos del Solicitante

La identificación del solicitante será obligatoria en las solicitudes de visita y suscripción y opcional para elresto de tipos. En los casos de no identificación del solicitante se considera que éste renuncia alseguimiento de las actuaciones que se realizan.

CIF/NIF: Identificación de solicitante.

Nombre y Apellidos: Nombre y Apellidos o Razón Social del solicitante.

Representatividad: campo auxiliar opcional para indicar el colectivo al que representa el solicitante.

Para la elaboración de estadísticas, si se dispone de la información dato, el sistema obtendrá el tramo deedad (según la tabla auxiliar correspondiente) del solicitante y el sexo del solicitante. El gestor tambiénpodrá introducir estos valores.

Datos de Contacto

En las solicitudes de visita y solicitudes de información será obligatorio el teléfono o el correo electrónico.

En las suscripciones será obligatoria la dirección y el teléfono o el correo electrónico.

En las quejas y sugerencias y averías cabe plantearse la opción de solicitante sin contacto, por lo que seentiende que renuncia a la comunicación y al seguimiento.

Dirección: del solicitante calle, portal, letra, escalera, piso, puerta, código postal y población.

Correo Electrónico: del solicitante.

Teléfono: del solicitante. (*)

(*) Se establecerá un formato de teléfono para el registro de peticiones único para permitir lalocalización posterior de peticiones por número de teléfono.

Medio de Contestación preferente: vendrá marcado por la prioridad establecida en función de los datosaportados (por ejemplo: para una prioridad: correo electrónico, teléfono, correo postal, si se dispone delcorreo electrónico éste será el medio preferente aunque se indiquen otros datos de contacto.

Datos de la Petición

Texto: Contenido de la queja o sugerencia o petición. Será obligatorio en todos los tipos petición

Anexos: Información opcional y adicional en distintos formatos (audio, vídeo, imagen o pdf) que seincorpora a las tablas de anexos asociados a la petición.

Datos Ubicación Será obligatorio en las peticiones de Averías. El sistema mostrará el mapa de Logroño,permitiendo indicar una ubicación en la que se posicionará o pinchar directamente en un punto del mapa. Seobtendrán y guardarán las coordenadas XY de la posición y la descripción de la dirección correspondiente.Con estas coordenadas se obtendrán los datos de distrito y zona de gestión (ver apartado conexión consistema de Territorio municipal). El gestor también podrá introducir estos datos de forma manual.

Datos de Categorización

Indicador de fallo de comunicación: marca a introducir por el gestor para indicar esta situación. Seaplicará a quejas y sugerencias y se podrá filtrar por esta marca en el buscador.

Palabras Clave: se asociarán a las peticiones seleccionando de la tabla auxiliar de palabras clave.

Tema: será obligatorio en las peticiones de Averías y según configuración en quejas y sugerencias ysolicitudes de información y automática en el resto de tipos de petición, seleccionando un valor de entre losexistentes en la tabla auxiliares. Existirán varios niveles según el catálogo: tema, subtema, materia y objeto.

Datos de Seguimiento

Referencia: Tipo, año y número como por ejemplo: PET 2013 / 125.

68


Texto: indicativo del modo de realizar el seguimiento (si hay identificación del ciudadano).

Plazo Previsto previa verificación de la información según calendario/horario municipal.

Datos de Gestión

Tiempo de Realización calculado entre el momento de registro o referencia y la contestación.

Resultado para las peticiones de averías se determinará si el tiempo de realización supera o no el plazo de72 horas previsto.

Coste para las peticiones de averías se registrará el coste estimado de la subsanación de la misma.

14.1.2 Proceso General

La actuación de “Registrar” realiza la incorporación de los datos al sistema validando el formato, contenidoy obligatoriedad de la información.

En los casos en que exista una unidad asignada por defecto (averías, suscripciones, visitas, OMIC, ...) yesté completa la información requerida, además del registro se realiza, sin intervención de la UPC, laactuación de “Decretar“, asignado como destino la unidad municipal establecida, calculando los plazos degestión y realizando los avisos oportunos a los gestores destinatarios.

Si el solicitante tiene identificación de contacto, el registro de peticiones determina los datos para elseguimiento de la petición: referencia identificativa PET AAAA/NNNNNN, texto indicativo y plazo estimadode resolución si se verifican los datos. Estos datos se presentan al ciudadano al finalizar el registro de lapetición y, si existe correo electrónico se le envía un recibo de la petición realizada.

El cálculo del plazo estimado de resolución deberá poder configurarse por tipo de petición y podrá ser unvalor en horas, días y estar referenciado a distintos calendarios y horarios municipales según las UUMM.

Para determinados tipos de petición, cuando el registro se produzca fuera del horario de atención al público,se enviará un correo electrónico de aviso a Policía para que valoren la necesidad de intervención, de formasimilar a la recepción actual de llamadas telefónicas.

14.1.3 Registro Manual

Existirá un formulario o pantalla que seguirá los pasos indicados anteriormente para el registro de peticionescon las matizaciones siguientes respecto a lo señalado anteriormente:

Datos del Solicitante

Si se introduce el nif/cif se accederá a la Base de Datos de Terceros para completar, si existe en estadoactivo, los datos de nombre y apellidos, año de nacimiento para el tramo de edad, sexo, contacto (direcciónpostal, correo electrónico y número de teléfono) y el código de sujeto correspondiente.

Datos de Ubicación

Se realizará directamente sobre el callejero municipal completando el campo de dirección proporcionada,dirección normalizada y distrito y zona de gestión asociada.

Se permitirá al gestor el posicionamiento en el mapa de las coordenadas de latitud y longitud.


Una vez realizada la grabación de la petición se devuelve un mensaje informativo para que el operadorindique al ciudadano.

Que se ha realizado correctamente la grabación en el sistema.

El modo y referencia para el seguimiento (si hay identificación).

El plazo previsto previa verificación de la información según calendario/horario municipal.

En el registro de la petición, se buscarán posibles peticiones similares en la misma ubicación y tema,avisando al gestor por si procede realizar una agregación de las mismas.

69


14.1.4 Registro Automático

Según el tipo de petición existirán varios formularios para la recogida y grabación de peticiones en elsistema con las matizaciones siguientes respecto a lo señalado anteriormente:

Datos de Ubicación

Se permitirá al ciudadano indicar calle número o pinchar en un punto del mapa para obtener la geoposicióno, se tomará de forma automática en el caso de dispositivos móviles.


Una vez realizada la grabación de la petición, se devuelve al ciudadano un mensaje informativo indicando

Que se ha realizado correctamente la grabación en el sistema.

El modo y referencia para el seguimiento (si hay identificación válida del solicitante).

El plazo previsto previa verificación de la información según calendario/horario municipal.

Además

Se establece un sistema de verificación de solicitante humano.

Se mostrarán los datos correspondientes a la Ley de Protección de Datos.

14.1.4.1 Formularios web y aplicación para móviles

La empresa adjudicataria será responsable del desarrollo de la lógica de la actuación de “registro” y delservicio web (1) que da soporte al registro y seguimiento de peticiones desde la web municipal o dispositivosmóviles. Será responsabilidad del Ayuntamiento de Logroño la adecuación de formularios de la web y de laaplicación para móviles.

(1) En la fase inicial del proyecto se decidirá la construcción de un nuevo servicio web o adaptación delexistente.

14.2 Tramitación

Con carácter general, una vez registradas las peticiones, el sistema implementa las siguientesfuncionalidades que se adecuarán a cada tipo de petición manejada:

Validar/Completar la información registrada.

Decretar o trasladar a la unidad de gestión correspondiente y al responsable de la reparación.

Volver a decretar: en los casos en que la unidad municipal destino disponga de estructura enniveles para la gestión de las peticiones.

Rechazar: En el caso de error devolviendo el control a la UPC.

Trasladar: Enviar la información de la petición a los técnicos o a la empresa responsable de darsolución a la misma.

Contestar: introducir en el sistema el contenido de la respuesta a transmitir al ciudadanosolicitante.

Comunicar: la UPC comunica al ciudadano el resultado de la petición o posibles actuacionesrelacionadas con la misma.

Ejecutar: indicar que se ha reparado al avería o realizada la tarea o sugerencia propuesta.

Comentar: es registrar dentro de la tramitación de la petición una acción informativa significativapara el gestor.

Anular: de forma motivada en los casos que proceda.

Cerrar la petición cuando ya no existan más actuaciones a realizar.

70


Agregar: incorporar la tramitación de la petición a otra de similar contenido.

14.2.1 Información manejada

Con carácter general, la información a manejar en el tramitación de peticiones incluye datos de:

Actuaciones: que incluye información para cada una de las acciones que se realizan en la gestiónde peticiones: tipo, fecha y hora, referencias y datos adicionales.

Estados: que incluye información de los distintos estados en los que se encuentra una petición ensu tramitación: tipo, fecha de cambio y actuación que genera el cambio de estado.

Plazos o Vencimientos: que incluye información de los distintos periodos y controles que seestablecen para una petición en su tramitación: fecha y hora de inicio y fin del periodo.

Anexos: que incluye información de los distintos archivos presentados por el solicitante oincorporados por los gestores en la tramitación de una petición: fecha, tipo y descripción.

Comunicaciones: que incluye información trasladada entre los diferentes intervinientes en latramitación de una petición: fecha y hora de la comunicación, medio de comunicación, destinatario,resultado y contenido de la misma.

Información adicional: que incluye comentarios y observaciones que se incorporan en latramitación de una petición. Las observaciones podrán ser públicas o propias del gestor.

Encuestas: que incluye las respuestas a la encuesta de satisfacción ciudadana.

A continuación se detallan los dos tipos de peticiones más significativos, si bien cada tipo de petición debepoder mantener sus características específicas:

Quejas y Sugerencias.

Averías 72 horas.

14.3 Petición de Quejas y Sugerencias

Las gestión de quejas y sugerencias incluye el registro automático (web municipal o aplicación para móviles)manual (telefónico o presencial) de las sugerencias, reclamaciones y opiniones de los ciudadanos enrelación con el funcionamiento de los servicios públicos municipales.

El sistema registra las peticiones y, vía correo electrónico al decretarse, se trasladan a los gestorescorrespondientes que realizan las gestiones oportunas para elaborar la respuesta que será comunicada alciudadano.

En algunas casos puede haber un registro posterior que indica la ejecución o realización de la tareacomprometida. Esta ejecución también será comunicada al ciudadano.


Formulario en la web municipal que utilizará el servicio web de alta de peticiones para incorporar el sistemalos datos introducidos por los ciudadanos.

Leyenda: (*) obligatorio () opcional

Se solicitarán:

Tipo de Petición (*): QYS (valor fijo).

Categoría (*): seleccionar tema/materia/objeto del catálogo de peticiones mostrando lasindicaciones existentes para cumplimentación.

71


Datos del solicitante (* s/configuración de solicitante anónimo).

Nombre, Apellido1 y Apellido2.

Nif.

Datos de contacto (* s/configuración de obligatoriedad de introducir contacto).


Teléfono.

Modo de contestación preferente (s/contacto introducido o no procede).

Datos de la queja o sugerencia.

Descripción (): es opcional si tiene anexo.

Ubicación ().

Dirección de la queja: Calle, núm + indicaciones.

Geoposicionamiento.

Anexos () como por ejemplo un archivo de imagen.

Sistema de verificación de solicitante humano + LOPD.

Al aceptar la petición se validan los datos introducidos.

Categoría.

Anexo (caso de envía solo foto) y/o Descripción

Validación del sistema de verificación solicitante humano.

En la utilización del servicio web de peticiones se incluirán los valores internos de:

Origen: web.

Si el registro es correcto se devuelven los datos suministrados por el servicio web para el seguimiento delciudadano.

Referencia: ( ej. PET 2013 / 25 ).

Texto informativo.

Posibles plazos o compromiso de realización.


Existirá una funcionalidad similar a la descrita para el registro automático que permita registrar las quejas ysugerencias presentadas de forma telefónica o presencial o detectadas en buzones, medios de prensa oredes sociales, de una forma ágil a los gestores autorizados, con las particularidades siguientes:

Eliminación de la presentación y validación del sistema de verificación de solicitante humano y eltexto de la LOPD.


Origen: Telefónico o Presencial según selección.

Se incluirá una opción para marcar la petición como emergencia, enviando un correo electrónico auna cuenta configurada.

14.3.3 Tramitación

Una vez registradas en el sistema, el tratamiento de las quejas y sugerencias incluye las actuacionessiguientes:

72


Completar/Validar: incorporar al registro de la queja la información necesaria para la tramitación:catalogar el tema, materia objeto de la queja, posibles indicadores, asignar dirección y distrito siprocede, ...

Agregar: asociar la gestión de una queja a otra ya registrada por tratarse de lo mismo con el objetode unificar las actuaciones a realizar sobre las distintas quejas agrupadas.

Decretar a la(s) unidad(es) de gestión correspondiente con las indicaciones oportunas para sucontestación.

Volver a decretar: En el caso de unidades con dos niveles de estructura como Logroño Deportepara dirigir la petición al gestor correspondiente.

Rechazar: En el caso de error de competencia devolviendo el control a la UPC.

Trasladar la petición al técnico encargado de contestar.

Contestar: la unidad de gestión indica la respuesta a la queja y anexa la información oportuna.

Aprobar: acción de confirmación de la contestación cuando intervienen varias personas en lamisma.

Comunicar: la UPC comunica al ciudadano la contestación de la unidad.

Ejecutar: indicación de que se ha realizado la tarea abierta con la contestación a la queja.

Comunicar Ejecuciones: la UPC comunica al ciudadano que se ha realizado la tarea generada porla queja o sugerencia.

Cerrar: la petición cuando ya no existan actuaciones a realizar.

Anular: de forma motivada en los casos que proceda.

Comentar: incluir actuaciones o hitos informativos en la tramitación de la queja o sugerencia.

14.3.3.1 Completar/Validar

El gestor de UPC accede a las peticiones recibidas en el sistema para revisar y completar la informaciónnecesaria y decretar las mismas a los destinos oportunos (unidades municipales) para su contestación.

La tarea de completar el registro de información incluye la catalogación de materia, ... dirección, distrito yzona de gestión y palabras clave, etc.

En función de la configuración establecida la catalogación de materias y distritos realizará el envío decorreos avisando de la recepción de quejas a los concejales asignados de materia y distrito.

Se mostrará una pantalla similar a la del alta donde el gestor pueda modificar e incorporar la información dela petición:

Tipo de Petición si lo considera.

Categoría (*):

Seleccionar tema/materia/objeto del catálogo de peticiones mostrando las indicacionesexistentes para cumplimentación.

Dirección normalizada, distrito y zona de gestión.

Podrá completar datos del solicitante y contacto con las facilidades de acceso a los datos desujeto y territorio si se dispone del NIF del solicitante.

Modo de contestación preferente.

Los datos específicos de la queja o sugerencia no podrán alterarse, si fuera necesario ampliarinformación se incluiría como observaciones y el gestor puede incorporar nuevos anexos siprocede.

Al aceptar la petición se validan los datos introducidos y se actualizará la información de la petición en elsistema:

Se registrará la información de la misma asociada a la petición.

73


Si se ha catalogado la materia, se produce y registra un comunicado de aviso al Concejal de laMateria correspondiente.

Si se ha catalogado el distrito, se produce y registra un comunicado de aviso al Concejal delDistrito correspondiente.

14.3.3.2 Agregar

En ocasiones, desde formularios de la web, se reciben quejas y sugerencias repetidas porque se solicitanvarias veces de forma consecutiva. En este caso el gestor procederá a anular las repetidas.

En otras ocasiones, se reciben quejas y sugerencias distintas, pero con la misma temática y contenidosiendo idéntica la tramitación de las mismas. Para estos casos, el nuevo sistema debe permitir “agregar”quejas y sugerencias de modo que las actuaciones realizadas por los gestores sobre la “principal” sereflejen en las “vinculadas” y la única particularidad se establecerá en el momento de comunicar alciudadano la contestación/resolución de la misma que dependerá del modo particular de cada petición.

Se validará que la petición esté en estado “registrada”, “decretada” o “contestada”.

Se mostrará una pantalla para:

Seleccionar la queja o sugerencia principal permitiendo una búsqueda rápida sobre quejas que noestén agregadas ni en estado final y mostrando las que tengan quejas agregadas ordenadas porfecha reciente.

Al confirmar la actuación:

Se registrará la información de la actuación asociando la queja a la queja principal.

Se produce y registra un cambio de estado en la petición a “agregada”.

Si el número de peticiones agregadas supera el establecido para los avisos se produce y registraun comunicado de aviso al Concejal de Distrito y al Concejal de Materia.

Se determinará si procede realizar otras actuaciones en función del estado de tramitación de laqueja principal. Si estuviera “comunicada” habría que comunicar al solicitante la queja agregada.Al gestionar el resto de estados se tendrá en cuenta la queja agregada.

14.3.3.3 Decretar

Esta actuación permite a los gestores autorizados trasladar las peticiones recibidas a la(s) unidad(es)gestoras correspondientes.

Debe tenerse en cuenta que una misma petición, por tener contenidos diversos, puede decretarse a variasunidades y que deben quedar reflejadas las distintas respuestas de cada paso.

Se validará que la petición esté en estado “registrada” o “decretada”.

Se mostrará una pantalla para:

Seleccionar el destino mostrando los posibles (*) de la tabla auxiliar de destinos.

Introducir texto con instrucciones o indicaciones específicas para que la unidad destinatariaidentifique su ámbito de actuación en la petición.

(*) destinos activos, autorizados, por tipo de petición.



Se produce y registra un cambio de estado en la petición a “decretada”.

Se produce y registra un comunicado de aviso al gestor de la Unidad correspondiente y alciudadano solicitante.

Se calcula y registra el plazo de Contestación.

74


Esta actuación permite a los gestores autorizados trasladar las peticiones recibidas al destino indicadosegún el catálogo de averías. Se establecerá una unidad municipal responsable y según los casos, unresponsable de la reparación (técnico municipal o empresa externa).

14.3.3.4 Volver a Decretar

Para permitir la gestión de unidades como Deportes con un nivel adicional de gestión, el sistema dispone dedos niveles de gestión de las peticiones de modo que dentro de su ámbito de actuación de unidades, ungestor puede remitir una petición decretada a otro nivel de gestión.

Se validará que la petición esté en estado “decretada”, que no esté contestada y que el gestor tengaasociados destinos de nivel 2.

Se selecciona la actuación de decreto inicial y mostrará una pantalla para:


(*) activos, autorizados, por tipo de petición y nivel.

Introducir las indicaciones oportunas, mostrando inicialmente el texto con instrucciones específicasde la actuación decreto inicial.



Se envía y registra un comunicado de aviso al gestor de la Unidad correspondiente.

No se alterará el plazo de contestación calculado.

14.3.3.5 Rechazar

Los gestores autorizados acceden a las quejas y sugerencias que les son decretadas y si hubiera un errorde competencias en la misma, pueden rechazarla.

Se validará que la petición esté en estado “decretada”.

Se mostrará una pantalla que permita:

Seleccionar el motivo del rechazo.

Introducir texto de observaciones del gestor.



Se produce y registra un cambio de estado en la petición a “registrada”.

Se anula el plazo de contestación calculado.

Se produce y registra un comunicado de aviso al ciudadano solicitante (s/configuración).

14.3.3.6 Trasladar

Para facilitar el acceso de las personas finales que elaboran la contestación, es posible trasladar por correoelectrónico una queja o sugerencia dentro de la propia unidad destinataria.

El sistema pondrá a disposición de los gestores un mecanismo para mantener los contactos o destinatarioshabituales (técnicos o empresas).


Introducir o seleccionar un destinatario de la información.

Introducir un texto con instrucciones o indicaciones específicas para el técnico, en el que se cargapreviamente la información básica de la avería.

75




Se envía y registra un correo electrónico al destinatario seleccionado.

14.3.3.7 Contestar

Los gestores autorizados acceden a las quejas y sugerencias que les son decretadas para dar solución alas mismas.

Los gestores podrán incorporar observaciones y archivos a la contestación y la grabación de la contestación“devuelve” la gestión a la UPC que es la encargada de comunicar el resultado al ciudadano.

La contestación de quejas y sugerencias activará el sistema de avisos y alertas.

También pueden incluir etiquetas propias de la unidad independientes de las establecidas a nivel generalpara facilitar la explotación posterior.

Se validará que la petición esté en estado “decretada” o “contestada” (para poder cambiar la misma).


Introducir el texto de la contestación (*).

Adjuntar archivos con información adicional que se enviarán al ciudadano.

Introducir texto de Observaciones del gestor ().

Introducir Plazo de Ejecución si procede.

Agregar etiquetas ().

Para permitir que el gestor introduzca los datos en distinto momentos en función de la complejidad de lacontestación, existirá la opción de guardar los datos sin confirmar la actuación, es decir, sin cambiar suestado de tramitación.

Al confirmar la actuación, el sistema determina en función de la configuración por distrito y del número dedecretos a unidades existentes en la petición:

Si se requiere aprobación o no y

Si se da por contestada o no (se requiere que todas las unidades implicadas hayan grabadosu contestación).


Calcular/Recalcular Plazo de Ejecución si procede.

Si dispone de todas las contestaciones de las unidades.

Se produce y registra un cambio de estado en la petición a “contestada”.

Si “no procede comunicación” se ejecuta la actuación de Comunicar.

Si requiere Aprobación y “requiere comunicación”.

Calcular Plazo de Aprobación (24 h. de margen para el Concejal).

Se envía y registra un correo electrónico al Concejal de Distrito.

14.3.3.8 Aprobar

El nuevo sistema debe incluir la actuación de “aprobación” en los casos en que así configure (cuando hayun flujo de dos personas para elaborar la contestación). Desde la primera contestación, la comunicación alciudadano quedará en suspenso un periodo a establecer de 24 horas.

Cuando se realiza la contestación, la comunicación al ciudadano queda en suspenso un periodo de 24horas y se emite un aviso o alerta a la siguiente persona en el flujo que recibirá en su cuenta de correo el

76


mensaje con la información básica de la queja o sugerencia y dos enlaces para la ejecución de dosopciones posibles:

Aprobar: al pulsarlo, se da por enterado de la contestación.

Comunicar: al pulsarlo, la persona se hace responsable de la comunicación al solicitante.

En el sistema:

Se realizará la actuación de Aprobar registrando la opción pulsada y anulando el plazo deaprobación calculado.

En la segunda opción, además se realizará la actuación de Comunicar registrando el gestorcorrespondiente.

Si no hay selección de opción, superadas las 24 h la petición se libera para ser comunicada por la UPC.

14.3.3.9 Comunicar

Una vez contestados todos los aspectos relatados en la queja o sugerencia, el SAC procede a comunicar alinteresado al resolución de la misma por el medio de contestación elegido en la petición.

El nuevo sistema deberá contemplar medios de contestación acordes con el uso de las nuevas tecnologíasque se desea para el aplicativo, Así, además de las actuales (carta, teléfono, fax y correo electrónico),deberá existir la posibilidad de contestar a los ciudadanos a través de sms, redes sociales, etc.

El sistema debe permitir que la contestación incorpore archivos de fotos, vídeos, pdf, etc.

El sistema debe mantener un registro de los distintos intentos y medios utilizados quedando constancia enel sistema de modo que por ejemplo, en el caso de comunicaciones telefónicas, debe preverse la posibilidadde anotar la persona y el teléfono con los que se ha contactado.

Se validará que la petición tenga actuaciones de “contestar” (sin comunicar) de todas las unidadesimplicadas y que se haya superado el plazo de aprobación si existiera - O sea una “agregada” que requierecomunicación (agregada a un petición principal que ya estaba comunicada) -.

La actuación tiene mucha similitud con la de comunicación de ejecución. Sólo difieren en el contenidocomunicado: la contestación de las unidades implicadas o la ejecución de alguna acción comprometida yque la segunda no afecta a los plazos de cierre.


introducir el texto a comunicar, en el que se carga previamente la contestación de la(s) unidad(s),indicando la inclusión de adjuntos y la fecha de ejecución si hubiera.

Incorporar posibles observaciones internas del gestor.


Según el modo de contestación seleccionado (por defecto el preferente).

Correo electrónico: Se envía y registra un correo electrónico y actuación completada.

Telefónico: Si la llamada tiene éxito, se registra la llamada y actuación completada. En casocontrario actuación es INTENTO.

Impreso: Se genera y registra un informe modelo carta impresa y actuación completada.

Si la actuación está COMPLETADA.


Se produce y registra un cambio de estado en la petición a “comunicada”.

Se calcula y registra el plazo de fin de gestión estimado.

Se marcan como comunicadas las actuaciones de contestar existentes.

Si la actuación es INTENTO.

Se registrará la información a título informativo.

77


14.3.3.10 Ejecutar

Determinadas quejas y sugerencias pueden requerir de intervención adicional por parte del Ayuntamiento.En estos casos, cuando se produce la ejecución comprometida, se registra en el sistema para que la UPCproceda a comunicárselo al ciudadano.

Se validará que la petición esté en estado “contestada” o “comunicada”.


Introducir texto indicativo.


Adjuntar archivos como fotografías o informes.



14.3.3.11 Comunicar Ejecuciones

Desde la UPC, de forma similar a la comunicación de contestaciones, se trasladan al ciudadano lasindicaciones sobre la realización de la actuación comprometida.

Se validará que la petición tenga registrada la ejecución sin comunicar.


Introducir texto en el que se carga el texto de la ejecución.









Se marcan como comunicadas las ejecuciones enviadas.



14.3.3.12 Anular

Esta actuación permite a los gestores autorizados anular de forma motivada las peticiones: error en lagestión, error en los datos, repetición, ...

Se validará que la petición no esté en un estado de tramitación final.


seleccionar el motivo de la anulación (* obligatorio).

introducir texto de observaciones del gestor.



78


Se produce y registra un cambio de estado en la petición a “anulada”.


14.3.3.13 Cerrar

El circuito de gestión de las quejas y sugerencias que se registran en el sistema finaliza con el cierre de lasmismas una vez realizadas las actuaciones establecidas para su tramitación. Esta actuación tiene lafinalidad de establecer un punto común a todas las peticiones que identifique la finalización de actividadesen la tramitación de peticiones.

El sistema permitirá a los gestores autorizados seleccionar las peticiones que cumplan las condiciones yproceder, de forma masiva, a su cierre dando por terminada la gestión de las mismas.

Se validará que la petición esté en un estado “comunicada” y que esté vencido el plazo de fin de gestión.



Se produce y registra un cambio de estado en la petición a “cerrada”.

14.3.3.14 Comentar

Está actuación permite a los gestores incluir una acción o actividad significativa en la tramitación degestiones realizadas de una petición.



Introducir texto breve e indicativo del comentario (*).




No se alteran estados ni plazos previos.

14.4 Petición de Averías 72 horas

Las gestión de avisos de averías incluye el registro automático (web municipal) o manual (telefónico opresencial) de las comunicaciones realizadas por los ciudadanos en relación con averías, incidencias ydesperfectos que se produzcan en la ciudad (en adelante averías).

El sistema registra las peticiones y, vía correo electrónico al decretarse, se trasladan a los gestorescorrespondientes que realizan las verificaciones oportunas y trasladan la misma según el caso a lostécnicos municipales o a empresas colaboradoras para su resolución.

Se dispone de un catálogo elaborado específico de averías por Ayuntamiento que determina los supuestos yparticularidades en que se establece un compromiso de 72 horas para los que se cuenta con las unidadesmunicipales y convenios con empresas externas. Algunas averías no son competencia del Ayuntamiento porla tipología o por los requisitos necesarios. En estos casos, el compromiso de 72 horas se limita a lacontestación.

Cuando la resolución sea competencia del Ayuntamiento, la unidad responsable valorará la actuación arealizar y puede optar por contestar al ciudadano o esperar a resolución de la avería para registrar laactuación de ejecutar que le será comunicada al ciudadano. Cualquiera de las dos acciones da porfinalizado el compromiso de 72 h.

79


En la contestación de la unidad se determina si la petición cumple los criterios establecidos y el plazocomprometido para su resolución. La contestación se comunica al ciudadano.

Cuando se recibe comunicación de la resolución de la avería, se registra como ejecutada para sercomunicada también al ciudadano.

Para el cálculo de las 72 horas se tendrá en cuenta el calendario y horario municipal de modo que no setengan en cuenta los festivos y que en las peticiones fuera de horario el plazo se comience en la mañanadel primer día hábil posible. De forma similar a lo que sucede en el actualidad fuera del horario municipal yde forma telefónica, se establece, de forma adicional a la decretación de averías, la opción de “aviso deurgencias” cuyo destinatario será la Policía Local de guardia que determinarán si es necesario realizaralguna intervención.

Las comunicaciones de averías deben contener la información necesaria para su resolución, quedando ensuspenso el compromiso de 72h hasta recabar la información necesaria.

La unidad gestora podrá disponer de un campo adicional para incorporar posibles “referencias” de la averíacon otros sistemas como por ejemplo: la Orden de Trabajo generada.


Formulario en la web municipal que utilizará el servicio web de alta de peticiones para incorporar al sistemalos datos introducidos por los ciudadanos.

Leyenda: (*) obligatorio () opcional

Se solicitarán:

Tipo de Petición (*):

AVE (valor fijo).

Categoría (*): seleccionar tema/materia en el catálogo de averías mostrando las indicacionesexistentes para cumplimentación.

Datos del solicitante ().

Nombre, Apellido1 y Apellido2.

Nif.

Datos de contacto ().

Dirección postal: Calle núm esc piso puerta + CP+ Localidad + Provincia.


Teléfono.

Modo de contestación preferente (s/contacto introducido o no procede)

Datos de la avería (se mostrará indicación de que deben introducir el tema de la visita)

Descripción (): es opcional si tiene anexo.

Ubicación (*) de cualquiera de las formas siguientes:

Dirección de la avería: Calle núm + indicaciones.

Geoposicionamiento.

Anexos () como por ejemplo un archivo de imagen.

Sistema de verificación de solicitante humano + LOPD

Al aceptar la petición se validan los datos introducidos

Categoría.

Anexo (caso de envía solo foto) y/o Descripción.

Ubicación de la avería de alguna de las opciones disponibles.

Validación del sistema de verificación solicitante humano.

80



Origen: web.

Decretar Automático Unidad según catálogo.

Si el registro es correcto se devuelven los datos suministrados por el servicio web para el seguimiento delciudadano

Referencia: ( ej. PET 2013 / 25 ).

Texto informativo.

Posibles plazos o compromiso de realización.


Existirá una funcionalidad similar a la descrita para el registro automático que permita registrar las averíasde forma telefónica o presencial de una forma ágil a los gestores autorizados, con las particularidadessiguientes.

Eliminación de la presentación y validación del sistema de verificación de solicitante humano y eltexto de la LOPD.


Origen: Telefónico o Presencial según selección.

14.4.3 Tramitación

Una vez registradas en el sistema, el tratamiento de las averías incluye las actuaciones siguientes:

Decretar a la unidad de gestión correspondiente y al responsable de la reparación.

Rechazar: En el caso de error devolviendo el control a la UPC.

Trasladar la comunicación a la empresa o técnicos responsables de su solución.

Contestar: la unidad de gestión indica la valoración de la avería comunicada y las acciones arealizar. (subsanación o traslado a la empresa correspondiente).

Ejecutar: indicar que se ha reparado la avería.

Comunicar: la UPC comunica al ciudadano el resultado de la petición (contestación y/o ejecución).

Anular de forma motivada en los casos que proceda.

Cerrar la petición cuando ya no existan actuaciones a realizar.

14.4.4 Decretar

Esta actuación permite a los gestores autorizados trasladar las peticiones recibidas al destino indicadosegún el catálogo de averías. Se establecerá una unidad municipal responsable y según los casos, unresponsable de la reparación (técnico municipal o empresa externa).

Se validará que la petición esté en estado “registrada” o “decretada”.



Introducir texto con instrucciones o indicaciones específicas para que la unidad destinatariaidentifique su ámbito de actuación en la petición

(*) destinos activos, autorizados, por tipo de petición.


81



Se produce y registra un cambio de estado en la petición a “decretada”.

Se produce y registra un comunicado de aviso al gestor del Destino correspondiente y alresponsable de la reparación si procede.

Se calculan y registran:

El plazo de Contestación. 72 h,

El plazo de Ejecución. 72 h.

14.4.4.1 Rechazar

Los gestores autorizados acceden a las averías que les son decretadas y si hubiera un error decompetencias en la misma, pueden rechazarla.



Seleccionar el motivo del rechazo.




Se produce y registra un cambio de estado en la petición a “registrada”.

Se anulan los plazos calculados al decretar (contestación y ejecución).


14.4.4.2 Trasladar

En función de las particularidades de las averías, el sistema permitirá trasladar las mismas a losresponsables de su resolución de dos formas:

1.Automática al decretar la avería y si se establece en el catálogo de averías,

2.Manual mediante la actuación de trasladar que permite al gestor, de forma manual, indicar el destinatario.

El sistema pondrá a disposición de los gestores un mecanismo para mantener los contactos o destinatarioshabituales (técnicos o empresas).


Introducir o seleccionar un destinatario de la información.

Introducir un texto con instrucciones o indicaciones específicas para el responsable de solucionarla avería, en el que se carga previamente la información básica de la avería.



Se envía y registra un correo electrónico al destinatario.

14.4.4.3 Contestar

Los gestores autorizados acceden a las peticiones de avería decretadas para introducir la contestaciónoportuna según la valoración realizada. Las posibles necesidades de remitir la información a terceros serealizan con la actuación anterior de trasladar.


82



Introducir texto con la contestación por parte de la unidad.

Incorporar posibles observaciones del gestor.

Adjuntar archivos.



Se produce y registra un cambio de estado en la petición a “contestada”.

Si “no procede comunicación”, se ejecuta la actuación de Comunicar.

14.4.4.4 Comunicar

Desde la UPC se traslada al ciudadano el resultado de su petición de aviso de avería.

Se validará que la petición esté en estado “contestada” o “cerrada” (si se permite comunicar a futuro).


introducir el texto a comunicar, en el que se carga previamente la contestación de la unidad o eltexto de ejecución, indicando la inclusión de adjuntos si los hubiera.









Se produce y registra un cambio de estado en la petición a “comunicada”.

Se calcula y registra el plazo de fin de gestión estimado.

Se marcan como comunicadas las actuaciones de contestar y ejecutar existentes.



14.4.4.5 Ejecutar

Cuando el responsable de solucionar la avería comunica a la unidad que ésta está solucionada, se registraen el sistema para que la UPC proceda a comunicárselo al ciudadano.

Se validará que la petición esté en estado “decretada”, “contestada” o “comunicada”.


introducir texto indicativo.


Adjuntar archivos como fotografías o informes.



83


14.4.4.6 Comunicar Ejecuciones

Desde la UPC, de forma similar a la comunicación de contestaciones, se trasladan al ciudadano lasindicaciones sobre la solución a la avería, etc.

Se validará que la petición tenga registrada la ejecución sin comunicar.


Introducir texto en el que se carga el texto de la ejecución.









Se marcan como comunicadas las ejecuciones enviadas.



14.4.4.7 Anular

Esta actuación permite a los gestores autorizados anular de forma motivada las peticiones: error en lagestión, error en los datos, repetición, ...



Seleccionar el motivo de la anulación (* obligatorio).




Se produce y registra un cambio de estado en la petición a “anulada”.


14.4.4.8 Cerrar

El sistema permitirá a los gestores autorizados seleccionar las peticiones que cumplan las condiciones yproceder, de forma masiva, a su cierre dando por terminada la gestión de las mismas.

Se validará que la petición esté en un estado “comunicada” y que esté vencido el plazo de fin de gestión.



Se produce y registra un cambio de estado en la petición a “cerrada”.

84


14.4.4.9 Comentar

Está actuación permite a los gestores incluir una acción o actividad significativa en la tramitación degestiones realizadas de una petición.



Introducir texto breve e indicativo del comentario (*).




No se alteran estados ni plazos previos.

14.5 Acceso, selección y filtrado

Los gestores debidamente acreditados podrán establecer criterios de búsqueda/selección de peticionespara consultar o realizar las gestiones oportunas según su perfil. En función de los perfiles varían lasnecesidades de acceso inicial por lo que debe contemplarse que cada gestor pueda identificar el filtro inicialde acceso a la pantalla de selección.

En el sistema a desarrollar es necesario que se pueda buscar, indistintamente de cómo se haga la consulta(mayúsculas, minúsculas, acentos, …) por todos los campos (nombre, apellidos, dirección, distrito, …), esdecir, por texto libre. Del mismo modo, se podrá realizar la búsqueda seleccionando entre tipos de peticiónexistentes. Las búsquedas, por defecto, deben filtrar peticiones en estado de tramitación en curso o activas,pudiendo establecer otros valores en demandas específicas según el estado (pendientes de contestar, decomunicar, etc.).

Se mostrará una opción de búsqueda rápida o habitual que presente los primeros resultados acompañadosde contadores por distintos criterios de modo que el gestor pueda seguir refinando los criterios de selección.

Existirá otra búsqueda avanzada para dar respuesta a la demandas más complejas como los indicadores decalidad y las necesidades planteadas por los Gestores de Unidades y los responsables de Distritos. Paradar respuesta a las necesidades que se indican en el apartado de explotación, se desarrollarán las opcionesde imprimir o exportar las peticiones filtradas. Del mismo modo, este filtrado puede utilizarse para realizaracciones o actuaciones sobre un grupo de peticiones.

Los gestores podrán gestionar (crear, guardar, eliminar) sus propias búsquedas.

En la fase de diseño se establecerán las características para un acceso ágil y cómodo de los gestoresresponsables de la tramitación de las peticiones. Además de las opciones de búsqueda, en la pantalla deacceso se tendrá en cuenta la presentación de datos agregados que aporten al gestor una visión global delestado de las peticiones autorizadas y accesos rápidos a las “bandejas” de peticiones según su estado o alas últimas recibidas.

Se establecen los criterios de búsqueda siguientes:

Sobre las Peticiones. Peticiones por:

Identificación de Peticiones: único o rango de valores.

Tipo de petición QYS, AVE, ...

Lugar de entrada (Origen)

Texto sobre contenido y otros campos.

Sobre la Estructura y Territorio. Peticiones por:

Unidad Destino, Agrupaciones de Unidad, Distrito, Calle, CP.

Sobre las Categorías. Peticiones por:

85


Tema, subtema, materia y objeto.

Palabras clave.

Sobre la Temporalidad. Peticiones de:

Hoy, Ayer, Último semana, Último mes, En año (ej: 2013), Entre fechas.

Sobre el Solicitante. Peticiones por:

NIF Apellidos, nombre, Tramos de Edad, Sexo, Contacto (e-mail, teléfono).

Sobre la Gestión. Peticiones por:

Estado, Actuaciones – Fechas.

Otros datos. Peticiones por:

Indicador de “fallo comunicación”.

Etiquetas propias de las unidades.

Criterios especiales o “bandejas” para gestores y concejales:

Peticiones sin decretar con plazo vencido.

Peticiones sin contestar con plazo vencido.

Peticiones sin comunicar con plazo vencido.

Peticiones sin ejecutar con plazo vencido.

Peticiones por materia.

Peticiones por distrito.

14.6 Consulta y modificación

La gestión de perfiles y ámbitos de acceso permitirá a los gestores, concejales y personal implicado en elsistema identificarse y acceder a las peticiones autorizadas según la unidad administrativa, tema/materia odistrito.

El sistema dispondrá de:

“Visualización inicial”: orientada a facilitar el acceso de gestores de unidades y concejalesimplicados y que incluya los datos básicos, el resumen de la tramitación y las posibles acciones arealizar y al seguimiento de ciudadanos solicitantes.

“Visualización detallada”: orientada a administradores y gestores de UPC que permita el acceso endetalle a la información y tramitación de la petición.

14.6.1 Visualización de Peticiones

Se mostrarán los datos básicos de la petición:

Datos de la Petición: tipo, identificación, origen, fecha, ...

Datos de Situación: último estado, actuación y plazo vigente y posible Aviso de plazo superado.

Datos del Solicitante, contacto y modo de contestación.

Datos de Ubicación y existencia de anexos.

Datos de Catalogación: tema, subtema, materia, objeto, distrito, indicadores y etiquetas.

Datos para el seguimiento.

Observaciones públicas y privadas.

86


14.6.2 Datos de Tramitación

Además de los datos básicos se podrá acceder a la información registrada durante la tramitación de lapetición. Se presentará la relación de

Actuaciones realizadas sobre la petición con la opción de acceso al detalle de la mismas: registrar,decretar, ...

Estados por los que ha pasado la petición en su tramitación: registrada, decretada, contestada,comunicada, ...

Plazos calculados que influyen en la tramitación de la petición con opción de ver o no los registrosanulados.

Anexos: imágenes, archivos, ... anexos asociados a la petición con opción acceder al detalle yvisualización de los mismos.

Comunicaciones asociadas a la petición: correos de aviso a gestores o concejales, correos atécnicos o empresas colaboradoras y comunicaciones con los ciudadanos.

14.6.3 Peticiones Agregadas

Al visualizar una petición se podrá acceder a la relación de peticiones agregadas a la misma.

14.6.4 Acciones posibles

Se visualizarán las opciones de ejecución de actuaciones sobre la petición mostrada.

14.7 Explotación

Para cubrir las necesidades de obtención de los indicadores y estadísticas detectadas inicialmente, elsistema permitirá que el gestor determine los parámetros para delimitar el ámbito de las peticiones sobre lasque realizar proceso de recuento. Los resultados obtenidos se podrán exportar para su inclusión eninformes o memorias.

Se establecerá un sistema lo más generalista posible que permita cubrir estas necesidades e incorporar confacilidad necesidades futuras.

14.7.1 Indicadores y Estadísticas detectadas

Nº total de quejas.

Nº total de quejas por día de semana

Nº total de quejas por mes.

Nº total de quejas por hora de entrada.

Nº total de quejas por tipo de petición.

Nº total de quejas por lugar de entrada.

Nº total de quejas por estado.

Nº total de quejas pendientes de contestar

Nº total de quejas por modo de contestación.

Nº total de quejas x sexo.

Nº total de quejas x tramo de edad.

87


Nº total de quejas x materias.

Nº total de quejas por calles.

Nº total de quejas por distritos.

Nº total de quejas por CP.

Nº total de quejas x unidad. En este caso deben poderse individualizar o acumular los datosreferidos a las distintas unidades.

Tiempo medio de resolución y coste medio de las actuaciones en el caso de Averías.

Asimismo, debe facilitar datos respecto a:

Fecha de entrada y decretación.

Fecha de entrada y contestación/es

Fecha de entrada y comunicación

Fecha de decretación y contestación.

Fecha de decretación y comunicación.

Fecha de contestación y comunicación.

14.7.2 Encuestas

El nuevo sistema incorpora un módulo de encuestas que permita al gestor establecer parámetros deselección y un número de encuestas deseadas que el sistema seleccionará de forma aleatoria entre laspeticiones que cumplan las condiciones establecidas. Una vez seleccionadas, enviará un correo electrónicoa los solicitantes que dispongan del mismo con un enlace para la cumplimentación de las preguntas ypermitirá, de forma manual que el gestor registre las respuestas en el caso de contacto telefónico.

Además de las cuestiones que se planteen en la encuesta se incluirá la opción de añadir o completar datossignificativos como el sexo, tramo de edad y distrito del solicitante.

A modo de ejemplo se describe una encuesta básica:

Distrito XXXXXXXXXXXXXX Tramo Edad XXXXXXXXXXXXXX Sexo XXXXXXXXXXXXXX Valore de 1 a 5 su satisfacción respecto a tiempo de respuesta. Valore de 1 a 5 su satisfacción respecto a la calidad de la respuesta. Valore de 1 a 5 su satisfacción respecto a la información recibida. Valore de 1 a 5 su satisfacción respecto a la calidad del servicio en general.

14.7.3 Avisos y Alertas

Se establecerá un sistema lo más generalista posible que permita realizar los avisos y alertas detectadosinicialmente e incorporar con facilidad necesidades futuras.

ModeloDestinatario

GestorUnidad

D.G.Unidad

ConcejalUnidad

ConcejalMateria

ConcejalDistrito

1. Aviso de Decreto X

2. Aviso de Catalogación X X

3. Agregación>nn X X X

4. FecDecreto+7d X X

4. FecDecreto+14d X X X

88


6. Avería > 72 horas X

7. Urgencias fuera de horario

14.7.3.1 Modelo Aviso 1. Aviso de Decreto

Cuando en una petición se realice la actuación de Decretar, se emitirá un aviso al Gestor de la Unidad(cuentas de correo asociadas) de forma similar al del ejemplo expuesto.

Ejemplo

<Nombre de la Aplicación>

Ha sido decretada una nueva petición desde el sistema de Quejas y Sugerencias del Ayuntamiento de Logroño haciasu Unidad.

Puede contestarla haciendo click en el siguiente enlace: < enlace al detalle de la petición >

Gracias por su colaboración.

Este mensaje es solo informativo. Por favor no conteste a este mensaje. La cuenta de correo utilizada no está preparada para recibirmensajes.

Cuando en una petición se actualice la materia o el distrito, se emitirá un aviso al Concejal asignado alDistrito / Materia (cuentas de correo asociadas) de forma similar al del ejemplo expuesto.

Ejemplo


Ha sido decretada una nueva petición desde el sistema de Quejas y Sugerencias del Ayuntamiento de Logroño relacionada con su < Distrito / Materia >.

Puede ampliar información haciendo click en el siguiente enlace: < enlace al detalle de la petición >



14.7.3.2 Modelo Aviso 3. Aviso de Vinculación

Cuando se agregue una petición y existan más de un nº establecido se emitirá un aviso al Gestor de Unidady a los Concejales de Distrito y Materia (cuentas de correo asociadas) de forma similar al del ejemploexpuesto.

Ejemplo


Ha sido agregada una nueva petición en relación < texto de la petición original > que se encuentra < estado de la petición original >. Hay < nº peticiones agregadas > peticiones agregadas.

Puede ampliar información haciendo click en el siguiente enlace: < enlace al detalle de la petición >



89


14.7.3.3 Modelo Aviso 4. Contestación Demorada

Los procesos de Pendientes de Contestar 7d y 14d emiten un aviso a los responsables de la Unidad, Distritoy Materia (cuentas de correo asociadas) de forma similar al del ejemplo expuesto.

Ejemplo


Relación de peticiones que incumplen el plan de calidad de este Ayuntamiento por haberse demorado su contestación más de < 7 días (naturales) > a fecha < 07/08/2012 5:00:05 >

TIPO NÚMERO FECHA NOMBRE PETICIÓN------------------------------------------------------------------------------------------QUE 128130 presentada el <fecha y hora petición> por < nombre solicitante > agregadas [< nº agregadas>]

< texto de la petición xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>AVE 128130 presentada el <fecha y hora petición> por < nombre solicitante > agregadas [< nº agregadas>] < texto de la petición xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Total de solicitudes: <nº peticiones en enviadas>

Puede ampliar información haciendo click en el siguiente enlace: < enlace al aplicativo >



14.7.3.4 Modelo Aviso 6. Ejecución Demorada

El proceso de Ejecución Demorada 72h emite un aviso a los responsables de la Unidad, Distrito y Materia(cuentas de correo asociadas) de forma similar al del ejemplo expuesto.

Ejemplo


Relación de averías que incumplen el plan de calidad de este Ayuntamiento por haberse superado el plazo de comprometido para su resolución a fecha < 07/08/2012 5:00:05 >

AVE 128130 presentada el <fecha petición> por < nombre solicitante > agregadas [< nº agregadas>] a resolver el <fecha hora compromiso de resolución>

< texto de la petición xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Total de solicitudes: <nº peticiones en enviadas>

Puede ampliar información haciendo click en el siguiente enlace: < enlace al aplicativo >



14.7.3.5 Modelo Aviso 7. Urgencias

Cuando se registre una petición fuera del horario municipal, se emitirá un aviso informativo para valorar lanecesidad de una posible intervención al Policía de Guardia de forma similar al del ejemplo expuesto.

Ejemplo


90


Ha sido recibida una nueva petición en el sistema de Quejas y Sugerencias del Ayuntamiento de Logroño, que se leremite al estar cerrada la atención al público en este horario.

AVE 128130 presentada el <fecha y hora petición> por < nombre solicitante > < texto de la petición xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>



14.7.4 Informes y Memoria

En este apartado se indican las necesidades de salida impresa a incluir en el sistema y se establecen lassiguientes tipologías de resultados a obtener:

Informe individual.

Lista de peticiones.

Memoria de las Unidades.

El sistema a desarrollar deberá apoyarse sobre un servidor de gestión de informes Actuate iServer versión 9SP1 para la generación y gestión de cualquier informe de la aplicación, aprovechando al máximo lasopciones y posibilidades que ofrece.

14.7.4.1 Informe individual

A modo de ficha resumen y similar a lo descrito en el apartado de visualización rápida, el sistema permitiráemitirá un informe individual, tipo oficio con los datos resumidos de la petición.

14.7.4.2 Lista de peticiones

De forma similar a lo indicado en el apartado de explotación e indicadores, el sistema permitirá que el gestordetermine los parámetros para delimitar el ámbito de las peticiones a incluir en el proceso de impresión.

Se permitirá obtener dos informes, uno simple que incluya información mínima de las peticionesseleccionadas con indicación de los criterios y peticiones seleccionadas y otro que contenga mayor detallede las peticiones.

14.7.4.3 Memorias de las Unidades

Para facilitar la elaboración de las distintas memorias de las unidades, el sistema permitirá el acceso almódulo de explotación e indicadores. Dado que el acceso a las peticiones se limita a las autorizadas, losgestores disponen de medios para obtener los distintos indicadores cuyo resultado podrán exportar paraelaborar la documentación que consideren oportuna.

14.8 Seguimiento de ciudadanos

Los ciudadanos que realicen peticiones acordes con los criterios de identificación y contacto recibirán unareferencia (PET AAAA/NNNNNN) del registro de la petición realizada. Es responsabilidad del Ayuntamientode Logroño incluir en la web municipal el acceso a la información del estado de tramitación de la petición,previa identificación. Es responsabilidad de la empresa adjudicataria la funcionalidad del servicio web quede soporte a las necesidades de información de este seguimiento.

91


Al registrar determinados tipos de petición, si existe dirección de correo electrónico, se remitirá un acuse derecibo con la petición realizada.

14.9 Configuración, seguridad y perfiles

14.9.1 Configuración básica

En este apartado se indica la información básica a gestionar relativa a la estructura y configuración depeticiones.

Tipos de peticiones: incluye el mantenimiento y configuración de los distintos tipos de peticionesmanejado en el sistema.

QYS Quejas y sugerencias.

SOL Solicitud de información.

AVE Comunicación de avería 72 horas.

STB Suscripción publicación del Teatro Bretón.

SBF Suscripción publicación de De Buena Fuente.

VST Solicitud de visita personal.

VCM Solicitud de visita a centro o dependencia.

Subtipos de información: incluye el mantenimiento y configuración de los subtipos asociados a lainformación anterior.

DBF/PAP Edición papel.

DBF/DIG Edición digital.

VCM/TBR Visita Teatro Bretón.

VCM/CCS Visita Casa Consistorial.

VCM/BMB Visita Bomberos.

VCM/SCC Visita Sala Centro de Control.

VST/SVA Visita Alcaldesa.

Origen: incluye el mantenimiento y configuración del lugar de entrada. Contendrá de formaimplícita el modo de grabación.

Web, 010, ...

Estados: incluye el mantenimiento y configuración de estados en los que se puede encontrar unapetición a lo largo de su tramitación.

Registrada Grabación.

Agrupada Su gestión se realiza con otra Petición principal.

Decretada Envío a Destino(s).

Contestada Contestada por TODOS los Destinos.

Comunicada Comunicada al solicitante.

Cerrada Finalizada.

Anulada Anulada.

Catalogación: incluye el mantenimiento y configuración de las distintas opciones de catalogaciónde las peticiones. Se incluye la gestión de:

Palabras clave.

Tema/Subtema/Materias/Objeto.

92


Indicador de Fallo en la Comunicación.

Dirección Normalizada.

Distrito.

Etiqueta: categorías a introducir de forma particular por la distintas unidades municipales.

14.9.2 Estructura organizativa

En este apartado se incluye de forma general la información a gestionar relativa a la estructura organizativade unidades y destinos que intervienen en la gestión de peticiones.

Los destinos posibles se estructuran en dos niveles para permitir la gestión de unidades como LogroñoDeporte.

Existirá una Agrupación de Unidades que permite obtener estadísticas por agrupación de destinos

14.9.3 Actuaciones y plazos

En este apartado se incluye de forma general la información a gestionar relativa a las distintas actuaciones yplazos que intervienen en la gestión de peticiones en el sistema:

Actuaciones identificadas: Registrar, Completar, Agregar, Decretar, Volver a decretar, Rechazar,Trasladar, Contestar, Comunicar, Ejecutar, Comentar, Anular, Cerrar.

Plazos identificados: Contestación, Ejecución, Aprobación o Fin de gestión.

Se asociarán las actuaciones permitidas a los distintos tipos de petición.

Los plazos tendrán asociada la forma de calcular la fecha de inicio y fin de los mismos, incluyendo en elcaso de averías el cálculo por horas.

14.9.4 Otros contenidos

Se incluye de forma general la información a configurar relativa a otros contenidos relacionados la gestiónde peticiones.

Anexos:

El sistema dispondrá de capacidad de configuración de los tipos de archivos anexo, su tamaño y suasociación a los distintos tipos de peticiones del sistema.

Tipos de comunicaciones:

El sistema dispondrá de capacidad de configuración de los tipos de comunicaciones y su asociación a losdistintos tipos de peticiones y orígenes del sistema. Se gestionará la utilización de salidas impresas,servidores, números de teléfono y cuentas de correo, etc.

Encuestas:

El sistema dispondrá de capacidad de configuración y gestión de encuestas básicas que se podrán asociaral proceso de selección de encuestados.

El registro de las encuestas será efectuado por los propios ciudadanos o por el 010 y existirá unaexplotación básica del resultado de las mismas.

93


14.9.5 Acceso y seguridad

En este apartado se incluye de forma general la información relativa al acceso, seguridad y auditoría delsistema.

14.9.5.1 Perfiles

Se identifican los siguientes perfiles para la configuración de autorizaciones a los distintos intervinientespara realizar actuaciones sobre las peticiones gestionadas en el sistema.

Perfil externo para ciudadanos solicitantes.

El sistema dispondrá de capacidad de configuración para establecer un perfil y ámbito de informaciónasociados a los ciudadanos que presenten peticiones a través del sistema web.

No está previsto el acceso al sistema de empresas externas colaboradoras.

Perfil Interno para los administradores, gestores y concejales.

El sistema dispondrá de capacidad de configuración para establecer perfiles y ámbitos de informaciónasociados a los distintos usuarios que permita discriminar:

Los tipos Información a maneja: quejas y sugerencias, solicitudes, averías, ...

El origen o lugar de entrada de las mismas

Los destinos posibles: Unidades municipales y empresas colaboradoras

Los temas y materias de catalogación: temas, materias, ...

El distrito asignado.

La acciones o funciones permitidas: Registrar, Consultar, Actualizar, Agregar, Decretar,Rechazar, Contestar, Comunicar, Anular, Cerrar, ...

Inicialmente se identifican lo perfiles siguientes:

Administrador Control Total del Aplicativo, Configuración, Perfiles.

Adm UPC Control Total sobre Aplicativo, Configuración, Explotación del sistema.

Gestor UPC Control Total sobre tipos de petición y origen autorizados

Gestor 010Registrar, Consultar peticiones y Encuestar.

Gestor Unidad Control Básico (*) sobre tipos de petición autorizadas y decretadas a suunidad.

NO PUEDE SI PUEDE

Registrar Actualizar la petición Aprobar Comunicar Agregar, Anular, Cerrar Encuestar

Decretar si nivel 2 (casode LDP)

Contestar Rechazar Ejecutar

Concejal Unidad Consulta sobre tipos de petición autorizadas y decretadas a su unidad. Notendrá capacidad de actuación.

Concejal Materia Consulta sobre tipos de petición autorizadas y catalogadas en su materia.No tendrá capacidad de actuación.

Concejal Distrito Control Externo (*) sobre tipos de petición autorizadas y catalogadas en sudistrito

94


NO PUEDE SI PUEDE

Registrar Actualizar la petición Rechazar Ejecutar Agregar, Anular, Cerrar Encuestar

Contestar Aprobar Comunicar

Todos los gestores podrán realizar actuaciones informativas como Comentar.

Gestión de Perfiles

El sistema dispondrá de una gestión de contraseñas y permitirá que los gestores mantengan sus propiasPreferencias.

14.9.5.2 Autenticación

Externa

Referida a los ciudadanos que formulen sus peticiones cumpliendo los requisitos establecidos deidentificación/contacto para el seguimiento de peticiones recibirán la información necesaria para poderacceder al seguimiento de cada petición.

Para ello, se habilitará en la web municipal un formulario acceso por identificador/referencia que presente lainformación de forma individual y estado de la misma y permita al ciudadano realizar posibles actuaciones.

Esta Autenticación puede evolucionar en el marco de otros proyectos de administración electrónica parapermitir un seguimiento masivo a un ciudadano identificado.

La identificación externa es responsabilidad del Ayuntamiento de Logroño.

Interna

Referida al acceso del resto de perfiles identificados anteriormente según los perfiles anteriores que no secorresponden con el ciudadano.

El sistema a desarrollar debe contemplar la identificación contra un directorio de LDAP (Active Directory2003 o superior y OpenLDAP al menos) valorándose la opción de múltiples repositorios LDAP.

14.9.5.3 Auditoría

Las tablas principales del sistema contendrán datos básicos de creación y actualización que, junto a laconsulta de actuaciones, permitirán el seguimiento de qué, quién y cuándo se ha realizado una acción en latramitación de las peticiones gestionadas en el sistema.

14.10 Procesos

14.10.1 Selección de Encuestados

El sistema permite al gestor establecer parámetros de selección y un número de encuestas que el sistemaseleccionará de forma aleatoria entre las peticiones que cumplan las condiciones establecidas. Una vez

95


seleccionadas, enviará un correo electrónico a los solicitantes que dispongan del mismo con un enlace parala cumplimentación de las preguntas y permitirá, de forma manual que el gestor registre las respuestas en elcaso de contacto telefónico.

14.10.2 Ejecución de Avisos

El sistema dispondrá de un mecanismo para establecer la periodicidad de ejecución de los distintosprocesos de aviso por correo electrónico del exceso de plazos establecidos en la tramitación de peticiones.

Inicialmente se identifican los procesos siguientes:

Contestaciones demoradas 7días y 14 días.

Ejecución demorada en avería 72 horas.

14.10.2.1 Contestaciones Demoradas 7d

Proceso diario que envía correos a las peticiones no contestadas con FecDecreto+7d

Proceso: Diario 02:00

Tipo: Quejas y Sugerencias, Solicitudes de Información, Averías,

Destino: Responsables de Gestores de Unidades (DG)+Concejales de Distrito

Casos: Peticiones de los tipos indicados, decretadas y no contestadas, con el plazo de contestaciónvencido + 7d. (y <14)

Modelo: Mod.Aviso 4

14.10.2.2 Contestaciones Demoradas 14D

Proceso: Diario 02:00

Tipo: Quejas y Sugerencias, Solicitudes de Información, Averías,

Destino: Responsables de Gestores de Unidades (DG)+Concejales de Distrito+Concejales de Materia

Casos: Peticiones activas de los tipos indicados, decretadas y no contestadas, con el plazo decontestación vencido + 14d.

Modelo: Mod.Aviso 4

14.10.2.3 Ejecución Demorada 72h

Proceso: Diario 07:00 09:30 12:00 14:00

Tipo: Averías

Destino: Responsables de Gestores de Unidades (DG)+Concejales de Distrito

Casos: Averías no ejecutadas y con el plazo de ejecución vencido (+72h o 7d desde la aceptación) enfunción del compromiso existente.

Modelo: Mod.Aviso 6

96


14.11 Integración con otras aplicaciones y sistemas

14.11.1 Web y Aplicación para móviles

Será responsabilidad de la empresa adjudicataria el desarrollo o actualización de los distintos métodos delservicio web necesarios para dar soporte al registro y seguimiento de peticiones desde la web municipal o elaplicativo para móviles.

14.11.2 Sujetos

El Ayuntamiento de Logroño será responsable de proporcionar un servicio web para recuperar los datos deun sujeto conocido su nif. En todo caso, el sistema deberá permitir al gestor la introducción manual de estainformación.

14.11.3 Territorio

El Ayuntamiento de Logroño será responsable de proporcionar un servicio web para recuperar el callejeromunicipal. El GIS proporciona la funcionalidad para obtener las coordenadas del mapa conocidas lacalle/número. El adjudicatario debe implementar una funcionalidad de la Plataforma o del GIS que permiteobtener el distrito y zona de gestión al que pertenecen las coordenadas de la petición. En todo caso, elsistema deberá permitir al gestor la introducción manual de esta información.

14.11.4 Plataforma de envío/recepción de SMS

Con objeto de reducir el coste y el tiempo requerido tanto en factor humano como el número de intentos arealizar en la “comunicación” entre los intervinientes en el sistema (ciudadanos, gestores, …), el nuevosistema debe contemplar en su arquitectura, procesos y configuración, la posibilidad de integración futuracon una plataforma de envío/recepción de SMS.

14.11.5 Servicio de Atención 010

Un elevado número de registros de peticiones se realiza dentro de la actividad asignada al Servicio del 010.Con objeto de facilitar la integración del nuevo sistema con la operativa del 010, éste deberá estarpreparado de forma que el proceso de registro de peticiones pueda enlazarse individualmente desde otrosaplicativos y al finalizar la grabación pueda enlazarse con otros aplicativos, recibiendo y enviado los datos eidentificación necesaria en cada caso para que la operativa de atender una llamada que requiera iniciar elproceso de registro de una petición, enlace con el aplicativo y, una vez atendida, conectar con la “encuestade atención” sea continua para el operador del servicio.

El Servicio de Atención 010 enviaría la identificando de la llamada y el número de teléfono llamante y elsistema de peticiones envía información de la petición a la “encuesta de atención” del Servicio de Atención010.

Además, el sistema dispondrá de una búsqueda por teléfono de contacto, nombre, contenido y fechas quefacilite la localización de peticiones en una atención telefónica o presencial o para ser utilizadas desdeaplicaciones externas.

97


14.11.6 Acciones automatizadas después del registro

El sistema debe contemplar la posibilidad de asociar al registro de una petición la opción de ejecutar unaactuación (abrir una página, llamar a un servicio web o procedimiento almacenado).

Por ejemplo, el registro de la suscripción al De Buena Fuente Digital ejecuta un servicio web que graba deforma automática la información de la petición en el sistema de gestión correspondiente. Del mismo modo,la grabación manual de un petición por parte del 010 lanzaría la llamada para registrar en su sistema laencuesta atención a realizar al final de cada llamada.

El nuevo sistema debe contemplar la ejecución de este tipo de llamadas y el Ayuntamiento de Logroño seráel responsable de desarrollar el “código llamado”.

14.11.7 Plataforma Smart Logroño

El nuevo sistema debe potenciar su integración la Plataforma Smart Logroño. Para ello, debe disponer defacilidades para la integración de la información de peticiones en sistemas como el de avisos e incidencias,en el observatorio de la ciudad, etc. y utilizar en la gestión las capacidades que ofrece la Plataforma.

a) la visualización georreferenciada sobre GIS o sobre mapa (open street map -OSM- en local) de laspeticiones registradas y su estado, pudiendo seleccionar por tipo de petición, temática, estados yfechas. La integración debe ser capaz de permitir acceso autorizado desde la Plataforma al detallede tramitación de las peticiones utilizando una url de enlace.

b) La capacidad analítica para confeccionar informes, indicadores y memorias.

c) La capacidad Open Data.

14.12 Incorporación de datos del sistema actual

Como mínimo, el adjudicatario debe incorporar al nuevo sistema la información existente de peticionesregistradas desde enero del año 2016.

14.13 Consideraciones adicionales

14.13.1 Plazos de Ejecución

Se establecen dos fases para la implantación del sistema de quejas y sugerencias. Una primera que incluyela recepción y gestión básica de las peticiones y que debe estar operativa en 4 meses desde el inicio delcontrato y otra que incluye la totalidad del sistema que deberá completarse a los 8 meses desde el inicio delcontrato.

14.13.2 Entorno tecnológico

El desarrollo del sistema de quejas y sugerencias debe seguir las pautas tecnológicas indicadas para laPlataforma Smart Logroño, por tanto, debe estar basado en tecnología Java (JEE) con una arquitecturaabierta y multicapa basada en estándares, que mantienen la independencia de la interfaz gráfica respecto aldiseño de los procesos de negocio y éstos a su vez con la base de datos. Estos estándares serán, en lamedida de lo posible, elementos del mercado de libre distribución que estén suficientemente probados yconsolidados para su implementación en un entorno de estas características.

98


La oferta debe indicar los componentes a utilizar y su nivel de licenciamiento, no suponiendo en ningún casoun coste adicional para el Ayuntamiento de Logroño.

El desarrollo debe estar soportado en una estructura física y lógica fundamentada en entorno Web y basadoen el patrón Modelo-Vista-Controlador (MVC) y debe mantener características compatibles al resto de lossistemas municipales gestionados por el servicio de Nuevas Tecnologías, por lo que se incluyen algunasparticularidades sobre el entorno tecnológico exigido para el desarrollo del nuevo sistema.

Arquitectura de desarrollo:

JSF para la capa de presentación.

Spring para el nivel de servicios de aplicación e integración.

Hibernate para persistencia y acceso datos.

Arquitectura de ejecución:

El Servidor de aplicaciones será preferiblemente el de la Plataforma de gestión Integrada, obien, Tomcat o similar.

El sistema de Gestión de Bases de Datos debe ser Oracle 11.2.04.

La capa de negocio se implementará preferiblemente en procedimientos almacenados deOracle.

Se priorizará la utilización de Actuate iServer versión 9 para la obtención de salidas impresas.

El adjudicatario será responsable del correcto funcionamiento del sistema y de la calidad de los datosmanejado y debe incluir en la oferta una garantía mínima de 12 meses a contar desde la fecha de recepcióndel producto. Dicha garantía incluye la subsanación de errores o fallos ocultos que se pongan de manifiestocon el funcionamiento de la aplicación o que se descubran mediante prueba o cualquiera otro medio, asícomo la inclusión de documentación incompleta y subsanación de la que contenga deficiencias.

La oferta debe incluir un modelo de datos relacional con detalle y explicación suficiente que permita valorarla solución propuesta. Este modelo no será vinculante dado que será objeto de análisis durante la fase dedesarrollo.

Además, el adjudicatario se compromete a realizar la transferencia de conocimiento al personal municipalpara que pueda asumir de manera autónoma la administración, gestión y mantenimiento del sistema. Paraello, la oferta debe incluir un plan de formación para gestores según los perfiles identificados y un plan deformación y transferencia de conocimiento específicos para el personal de sistemas y desarrollo delAyuntamiento.

99

ANEXO D:

SISTEMA DE AFECCIONES EN LA VIA PÚBLICA


15 ANEXO D: Sistema de Afecciones en la Vía PúblicaEl propio dinamismo de las ciudades requiere una ordenación de las actividades en las vías y espacioslibres públicos que implica a diferentes servicios municipales que desarrollan, tramitan o resuelvenactuaciones, a demanda de terceros o por iniciativa propia, y cuya ejecución tiene una repercusión sobre lamovilidad de los ciudadanos de Logroño y que en algunos casos puede provocar interferencias entre dichasactuaciones.

Esta actividades pueden tener carácter temporal o permanente y requerir, según los casos, actuaciones desolicitud previa (con tramitación ordinaria o comunicada) y autorización por parte del servicio responsable.

En la actualidad, los servicios municipales regulan y gestionan de diferentes formas estas actuaciones y condistinta información en función de los diferentes tipos de afecciones. Se hace necesario que todo el personalimplicado conozca a un tiempo y de una sola vez dónde y qué tipo de afecciones acontecen en Logroño.Para realizar esta gestión eficiente y eficaz y minimizar los efectos de las distintas afecciones en la víapública es imprescindible disponer y compartir la información y gestionar las relaciones entre los distintosservicios afectados.

Para ello, la Plataforma debe incluir un sistema de gestión que proporcione capacidades comunes a todoslos servicios teniendo en cuenta sus particularidades y necesidades, aportando tanto una visión parcial parala gestión como global para determinar el alcance de la afección y ampliando la información con contenidosy con la capacidad de georreferenciación de la Plataforma. La información de afecciones en la vía públicaserá de especial utilidad en la gestión de incidencias en la ciudad.

Los objetivos principales son:

1. Integrar todas la fuentes de información en un repositorio de datos común, accesible a todos losservicios afectados, para la gestión y el conocimiento de las autorizaciones para la ocupación outilización de los espacios de dominio y uso público viario

2. Dotar a los distintos servicios municipales de capacidades para gestionar la actualización, consultay seguimiento de las mismas.

3. Ampliar y complementar la información con contenidos de la Plataforma, en especial contenidosgeorreferenciados como mobiliario urbano, alumbrado público, señalización, hidrantes, etc.

Incorporar la información que resulte de interés para el seguimiento control de incidencias y para la gestiónde la ciudad.

Este sistema no será intrusivo con la forma de gestionar de los servicios municipales. Debe proporcionarcapacidades de gestión para facilitar y mejorar las actuaciones en los servicios que gestionan las afeccionesde forma manual e integrará los datos de aquellos servicios que dispones de sistemas particulares (MSAccess).

Con carácter general se describen las funcionalidades y capacidades mínimas del sistema, que serándesarrolladas en un proyecto posterior una vez adjudicado el contrato con la participación de personalmunicipal y de la empresa adjudicataria, siendo finalmente aprobado por el Ayuntamiento de Logroño:

a) Debe permitir registrar la información relacionada con las distintas afecciones, manteniendo unaparte común y otra específica para cada tipo de afección. El registro será tanto de forma manualcomo por importación o integración de datos de los sistemas de gestión particulares de losservicios municipales.

b) Utilizará la capacidad de georreferenciación de la Plataforma para ubicar la afección y permitir suposicionamiento en el mapa. Además permitirá la presentación de afecciones por zonas o áreasdel mapa seleccionadas.

c) Debe gestionar los estados, temporalidad y ámbito de las afecciones permitiendo visualizar elmapa de afecciones en distintas fechas o periodos.

d) Debe permitir visualizar de las afecciones en función del tipo, estado y ámbito de afección e incluirla posibilidad de datos adicionales o relevantes de la afección y enlaces a otros contenidos como

101


actas o acuerdos de aprobación u otros documentos como por ejemplo modificaciones y ajustesen el transporte urbano.

e) La arquitectura y configuración del sistema debe permitir especificar los distintos tipos deafecciones, establecer varios niveles de categorización y modelar las particularidades enconformen el acceso, registro y tramitación de las afecciones.

f) Configurar avisos a los gestores implicados, a otras unidades afectadas y recordatorios al catálogode contenidos descrito en el sistema de gestión de atenciones.

g) Debe establecer la configuración y mecanismos de control para el uso y acceso autorizado de loscontenidos.

De forma general, el sistema incluye la gestión de todas las afecciones por ocupación o utilización de losespacios de dominio público y uso público viario que, con carácter informativo, se pueden agrupar enocupación por:

1. Obras en aceras, calles peatonales o calzada, incluyendo vallado, casetas, andamios, maquinaelevadora, grúas, vehículos para obras, apertura de zanjas y acometidas (gas, electricidad,telecomunicaciones, ...), canalizaciones, contenedores, etc.

2. Obras realizadas por empresas externas en el marco de contratos con el Ayuntamiento.

3. Actividad: mercantil, vehículos para transporte, ventas ambulantes, puestos (helados, castañas,churros, ...), etc.

4. Reservas de estacionamiento temporales para mudanzas, autobuses publicitarios, etc.

5. Publicidad, reparto, quiosco (prensa,once),

6. Celebraciones o fiestas de la ciudad, barrios, zonas, etc.

7. Mobiliario de restauración y hostelería como: mesas, sillas, sombrillas, toldos, terrazas de veladores,etc.

8. Eventos y espectáculos o actuaciones: eventos deportivos, circos y atracciones feriales, músicacallejera y otras actuaciones artísticas.

9. Campañas y actos promocionales.

Las unidades municipales detectadas inicialmente son Dominio Público, Urbanismo, Movilidad, ParticipaciónCiudadana y Policía Local.

En la oferta se deberá incluir una propuesta no vinculante de diseño y navegación de la operativa debúsqueda y consulta de afecciones.

15.1 Información manejada

Se incluyen los contenidos de información identificados inicialmente para facilitar la compresión y ámbito delsistema.

Identificación.

id propio.

id externo Expte. AAAA/nnnnn

Fecha de Solicitud.

Lugar de la solicitud.

Solicitante-Promotor y Representante en su caso

id Tercero Municipal.

NIF.

102


Nombre o Razón social.

Contacto.

Dirección postal.

Teléfonos.


Asunto/Contenido.

Descripción.

Ampliación de descripción.

Ampliar información: texto y enlace externo.

Ubicación

Codificación

códigos de identificación de Territorio.

Coordenadas en el plano.

Descripción y ampliación de la ubicación.

ej: Avda de la Paz 11 (en la plaza en la zona de reloj)

Observaciones de ubicación.

Tipo de Ocupación: calzada, banda de aparcamiento, acera,...

Temporalidad.

Fecha hora desde y hasta.

Temporal / permanente.

Tramitación.

Estado Activa / no Activa.

Tipo Ordinaria / Comunicada.

Fase Pendiente de Tramitación / Aprobada /...

Catalogación.

Servicio que gestiona.

Unidad.

Subunidad.

Otros servicios implicados

Tipología: tipos de solicitudes según configuración de servicio municipal y gestor.

Tipo.

Subtipo.

Clasificación: obras, actividades, hostelería, transporte, fiestas...

Palabras clave / etiquetas de búsqueda.

Alcance.

Indicador de afección: tráfico, aparcamiento, peatones,...

Otros datos

Requiere Fianza

Requiere Seguro

Comentarios Adicionales.

103


15.2 Operativa

15.2.1 Acceso, selección y filtrado

Los gestores debidamente acreditados podrán establecer criterios de búsqueda/selección de afeccionespara consultar o realizar las gestiones oportunas según su perfil.

La consulta debe permitir realizar búsquedas por un o varios criterios como tipo, periodo de fechas, estado,solicitante, ubicación, ..., siendo indistinto el uso de mayúsculas, minúsculas, acentos, …

Según el usuario, se mostrará una opción de búsqueda rápida o habitual que presente los primerosresultados acompañados de contadores por distintos criterios de modo que el gestor pueda seguir refinandolos criterios de selección.

Existirá otra búsqueda avanzada para dar respuesta a la demandas más complejas

En la fase de diseño se establecerán las características para un acceso ágil y cómodo de los gestores delas afecciones.

15.2.2 Consulta y modificación

La gestión de perfiles y ámbitos de acceso permitirá a los gestores y personal implicado en el sistemaidentificarse y acceder a las afecciones autorizadas según la catalogación anteriormente indicada. Enfunción de esta autorización, el gestor podrá gestionar y modificar los datos de la afección. El sistema debeguardar información de auditoría sobre los cambios producidos en los datos.

15.2.3 Avisos y alertas

Se establecerá un sistema lo más generalista posible que permita a los gestores establecer alertas anteeventos (por ejemplo, si se registra un determinado tipo de afecciones en un radio nn de un punto del mapa)y avisos o traslados a otras unidades o servicios (por ejemplo, el registro de una afección, envíe un correo aParticipación Ciudadana y a Policía.

15.2.4 Explotación

El sistema debe integrarse con la capacidades y funcionalidades de la Plataforma para permitir la obtenciónde estadísticas e indicadores de gestión del sistema.

15.3 Integración con otras aplicaciones y sistemas

15.3.1 Sujetos

El Ayuntamiento de Logroño será responsable de proporcionar un servicio web para recuperar los datos desolicitante conocido su nif. En todo caso, el sistema deberá permitir al gestor la introducción manual de estainformación.

104


15.3.2 Plataforma Smart Logroño

El nuevo sistema debe potenciar su integración la Plataforma Smart Logroño. Para ello, debe disponer defacilidades para la integración de la información de peticiones en sistemas como el de avisos e incidencias,en el observatorio de la ciudad, etc. y utilizar en la gestión las capacidades que ofrece la Plataforma.

Entre otras, el sistema debe utilizar la capacidad de georreferenciación de la Plataforma para ubicar lasafecciones y su área de afección en el mapa de la ciudad.

15.3.3 Gestión de Afecciones de Dominio Público

La unidad de Dominio Público dispone de un sistema MS Access 97 donde registran y tramitan lassolicitudes de afecciones de su competencia.

Se mantendrá la operativa actual de gestión de las afecciones de dominio público integrando la informaciónde interés en el sistema de afecciones de la Plataforma y ampliando sus prestaciones con las capacidades yfuncionalidades que proporciona la Plataforma.

15.4 Incorporación de datos del sistema actual

Como mínimo, con la puesta en marcha del sistema, el adjudicatario se compromete a incorporar al mismola información existente de afecciones desde la fecha de adjudicación del contrato.

15.5 Indicadores

Como mínimo, el sistema debe proporcionar los indicadores siguientes:

Número de afecciones tramitadas por tipo, fechas, unidad, estados, solicitante y territorioseleccionado.

Tiempo acumulado de afección por tipo, fechas, unidad y territorio seleccionado.

105

ANEXO E:

REQUISITOS


16 ANEXO E: RequisitosLos requisitos a continuación señalados son requisitos mínimos obligatorios de inexcusable cumplimientopor los licitadores, de forma que su incumplimiento dará lugar al rechazo automático de la proposición. Ensu caso, según lo previsto en el apartado 11 de este Pliego “Criterios de adjudicación”, se valoraránpropuestas de características adicionales al cumplimiento de los requisitos básicos que redunden en unamejora técnica de la solución. En este sentido, la posesión del requisito básico es una especificación técnicadel Pliego obligatoria y no valorable, y sólo cuando éste se mejora, de acuerdo con los citados criterios,pasaría a ser objeto de valoración, exclusivamente por las características adicionales.

16.1 Generales

N. Requisito

1 Cumplir las Instrucciones indicadas en el PPT sobre la documentación a presentar.

16.2 Infraestructuras y Redes de Comunicación

N. Requisito

1 Electrónica de red tipo CE para un mínimo de 15 nodos principales.

2 Electrónica de red para un mínimo de 47 nodos secundarios.

3 Equipos de comunicaciones 3G/4G para al menos 109 nodos de red.

4 15 cámaras de tráfico IP para sustituir las actuales existentes.

5 Adaptación o sustitución de los sistemas de telemetría de las cámaras existentes.

6 Servidor para integrar las cámaras suministradas.

7 Integración de las cámaras IP de tráfico sustituidas.

8 Ampliación del sistema de atención presencial QMATIC existente.

9 Sistema de Call Center telefónica, vía Chat y correo electrónico para el centro de control.

10 Mantenimiento de las licencias de software base suministradas durante la duración del contrato.

16.3 Plataforma de Gestión Integrada

N. Requisito

1 ¿La oferta incluye un Plan de Implantación acorde a los requisitos indicados en el PPT (apartado 11.2)?

Arquitectura y características: ¿La solución propuesta en la oferta cumple los requisitos de arquitectura ycaracterísticas generales especificadas en los apartados correspondientes del PPT para la Plataforma deGestión Integrada (apartados 13.1 y 13.2)?

2 Arquitectura.

3 Solución abierta.

107


4 Modularidad y adaptabilidad.

4 Robustez y escalabilidad.

5 Seguridad y privacidad

6 Resiliencia.

7 Accesibilidad y usabilidad.

8 Multidispositivo e Interfaz de Usuario.

Servicios Básicos ¿La solución propuesta en la oferta cumple los requisitos, características, funcionalidades yoperativa especificada en el PPT para los servicios básicos (apartado 13.4) ?

9 Servicios básicos de administración y gestión.

10 Servicio de Almacenamiento.

11 Servicio de Integración.

13 Servicio de Análisis.

14 Servicio de Georreferenciación.

Servicios Avanzados ¿La solución propuesta en la oferta cumple los requisitos, características,funcionalidades y operativa especificada en el PPT para los servicios avanzados (apartado 13.5) ?

15 Gestión de Incidencias

16 Gestión de Quejas y Sugerencias.

17 Gobierno y Gestión de la Ciudad

18 Sistemas Municipales

19 Relación con el Ciudadano

Otros módulos ¿La solución propuesta en la oferta cumple los requisitos, características, funcionalidades yoperativa especificada en el PPT para ...?

20 Actividades de Consultoría y Soporte.

21 Acuerdos de Nivel de Servicio

22 Formación y Transferencia Tecnológica.

23 ¿La oferta incluye una propuesta de Contrato de Mantenimiento?

24 Proyecto piloto de verificación de funcionalidades de la Plataforma.

108

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES DEL...

Documents

Transcript of PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES DEL...