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

Las concentraciones de la población en núcleos urbanos han planteado en las últimas décadas la necesidad de reestructurar los servicios en todas las áreas de gobierno. Con el paso de los años, se ha aprendido a valorar la importancia, entre otras, de la calidad del agua que bebemos, del aire que respiramos, el tratamiento que hacemos de los residuos o las alternativas en la movilidad urbana. Sin embargo, esto en el siglo XXI ya no es suficiente por sí solo, es necesaria la introducción de la tecnología: gestionar la ciudad de la mano de los nuevos avances, permitiendo que el ciudadano pueda sacar el máximo provecho de los servicios 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 al escenario municipal para poner a disposición de todos los ayuntamientos aquellas actuaciones exitosas que se pueden implantar con el objetivo de mejorar y garantizar la calidad de vida de los ciudadanos. Dentro de este panorama son muchas las medidas innovadoras que contribuyen a construir una ciudad del futuro con actitud abierta a la participación ciudadana.

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

El Ayuntamiento xx Xxxxxxx, partícipe de dicho pacto desde el pasado 7 de septiembre de 2012, ya trabaja intensamente para tomar las medidas oportunas en beneficio de la calidad del aire que respiran sus habitantes, en la mejora de la movilidad a través de las actuaciones aprobadas en el Plan de Movilidad Urbana Sostenible (PMUS), en el buen uso de la energía con la reducción del presupuesto energético gracias a medidas de eficiencia en edificios públicos y a la optimización del alumbrado, en la mejora de las infraestructuras del ciclo del agua, en la teleoperación de los servicios públicos con el uso intensivo de las TIC'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 que recae la competencia. Es un modelo de funcionamiento en vertical que ha dado frutos positivos en un contexto 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ón socioeconómica actual, los grandes retos de sostenibilidad de la sociedad, las nuevas necesidades y demandas de los ciudadanos requieren transformar el modelo de gobernanza de las ciudades buscando una reordenación inteligente del espacio y de los servicios, un incremento en la eficacia y eficiencia de los mismos, la reducción de costes, la disminución del consumo energético y el reajuste de la oferta a las nuevas 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ón ciudadana, una mayor transparencia en la gestión municipal, una mejora de las capacidades de intervención social y facilitará el acceso a los datos en sistemas abiertos contribuyendo a crear entornos atractivos para la 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 de actuación:

1. Desarrollar estrategias de inclusión que propicien un cambio de modelo de gestión de los servicios públicos. Un modelo basado en una gestión integral de los servicios municipales en el que se pueda compartir la parte de los mismos que pueda ser compatible, sobre todo en recursos humanos, 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 de servicios públicos, la redefinición de los mismos o el replanteamiento de las relaciones con ciudadanos, turistas, empresas y proveedores.

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

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

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

2 Objeto y Alcance ‌

El objeto del contrato es la puesta en marcha de la Plataforma Smart Logroño que incluye el conjunto de infraestructuras, 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 y jerarquizada a otro basado en la gestión de la ciudad como un todo, optimizar los procesos de gestión de los servicios urbanos e implantar un portal con los contenidos de datos abiertos del catálogo Open Data municipal. Además, incluye la capacitación de la Plataforma como soporte a la prestación del servicio de Atenció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 la Plataforma 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 una teleoperación única de los servicios públicos, por medio de un Centro de Control Integral (CCI) que unifique 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 la integración posterior de servicios verticales.

❑ Mejora de los canales de comunicación, conocimiento transversal del estado de los servicios pú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 y del 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 la administración y el ciudadano.

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

❑ Integración futura de servicios públicos municipales como Regulación del Tráfico, Alumbrado Público, Medio Ambiente, Policía Local, Bomberos xx Xxxxxxx, Protección Civil, etc. basada en la concepción y desarrollo abierto y transparente de la Plataforma Smart Logroño. Esta integración no se refiere a la prestación propiamente dicha de los servicios, sino a la integración de datos y contenidos 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 y conlleva 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ón y 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 e interconecta los diferentes sistemas de manera más eficiente, mejorando la disponibilidad y tratamiento de 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 compartido de recursos entre los servicios de Regulación del Tráfico y de Alumbrado Exterior Público o el servicio de Información y Atención Ciudadana que se convierte en servicio horizontal, común al resto de

servicios, asumiendo la operativa del Centro de Control Integral de la Plataforma Smart Logroño y atendiendo, 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 en este contrato para completar la estrategia de despliegue para dar servicio a la Plataforma Smart Logroñ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 que incluye:

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

• Implantación de la funcionalidades y aplicativos comunes a los servicios verticales a integrar y a la prestación del servicio del Centro de Control Integral, incluyendo los sistemas de gestión de avisos e 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 de dispositivos, 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 para el gobierno de la ciudad.

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

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

• El desarrollo y ejecución de un “Proyecto-Piloto” de verificación de características, funcionalidades y 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ón integral de la ciudad, incluyendo la consultoría, desarrollo e implantación de proyectos de incorporación de contenidos de sistemas municipales y la colaboración y participación en proyectos de integración de servicios verticales.

2.1 Infraestructura y redes de comunicaciones

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

El Ayuntamiento xx Xxxxxxx ha diseñado una estrategia de despliegue de infraestructuras basada en el uso eficiente y evolutivo de los recursos para completar una red de comunicaciones capaz de vertebrar la ciudad e integrar las diferentes tecnologías que permiten la conexión de sensores, dispositivos y edificios que hace posible implementar el resto de los sistemas.

En paralelo con despliegues realizados en otros contratos municipales, este contrato incluye el suministro y despliegue de los elementos especificados en el Anexo A del presente Pliego que incluye detalle sobre el estado 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.

4. Completar el equipamiento necesario para establecer en el Centro de Control Integral (sito en la xxxxx Xxxxxx Xxxxxxxxxx xx 0) la futura teleoperación única para todos los servicios y para la atenció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 de módulos de gestión comunes a los servicios que se integran y un conjunto de soluciones, soportadas visual y funcionalmente en la cartografía, que facilitan una visión global y una gestión integral de la ciudad cuyos destinatarios 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 nuevos negocios.

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

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

3 Duración del contrato ‌

El contrato tendrá una duración de 4 años contados a partir de la firma del acta de inicio de la prestación de los servicios.

Todas las infraestructuras, suministros, equipamiento hardware, software y desarrollos a medida, creados e implementados durante la vigencia del mismo y sus correspondientes licencias pasarán a propiedad del Ayuntamiento xx Xxxxxxx desde su instalación, puesta en servicio o recepción, considerándose los mismos amortizados en valor en la vigencia del contrato.

4 Presupuesto de licitación ‌

El valor estimado del presente contrato asciende a la cantidad total de 2.392.056,20 € IVA incluido (base de 1.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 2017

4.1 Presupuesto global

Periodo de ejecución del

Contrato

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

4.2 Presupuesto por partidas

Concepto

Partida

Total

Contrato

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

G1 92020 21999

65.696,48

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

G1 92020 22799

1.360.000,00

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

G2 92020 63699

365.579,72

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

G2 92020 64199

600.780,00

2.392.056,20

5 Pago del Precio ‌

El pago del suministro y despliegue de infraestructuras y redes de comunicación y de la implantación de la Plataforma 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 hitos establecidos en el Anexo X xxx Xxxxxx de Prescripciones Técnicas. El pago se realizará tras la firma de las Actas de Recepción correspondientes:

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

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

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

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

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

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

2. PLATAFORMA DE GESTIÓN INTEGRAL:

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

El pago se realizará tras la firma del Acta de Recepción correspondiente según la planificació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ón especifica, 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 de tiempo transcurrido desde el inicio del contrato.

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

✓ La cantidad restante, restante en facturas mensuales conformadas por los servicios municipales 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 concepto cubriría los primeros 4 meses, la segunda los siguientes 4 meses y el resto en facturas mensuales.

6 Plazo de garantía ‌

A 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 se computará a partir de la fecha expresada en la correspondiente acta de recepción y será de un mínimo de DOS AÑOS si no tiene especificada otra mayor distinta.

7 Ampliaciones y Modificaciones del contrato ‌

No están previstas ampliaciones o modificaciones del contrato.

8 Responsable del contrato ‌

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

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 del proyecto 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 en todo momento a las necesidades concretas de las actuaciones a realizar. Así, para las decisiones y actuaciones 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 en función del ámbito y necesidades que surjan en los distintos planes de integración de los Servicios Verticales.

La Comisión de Desarrollo, si así lo estima conveniente, podrá disponer la colaboración del adjudicatario y su 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 siguientes competencias:

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

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

❑ Verificar el cumplimiento y calidad de los productos obtenidos.

❑ Verificar la planificación, disponibilidad de recursos, coordinación y seguimiento de las actividades a realizar durante la duración del contrato, con especial dedicación en la fase inicial de implantación de la Plataforma de Gestión y la elaboración, ejecución y seguimiento de un Plan Estratégico de Mejora e Integración para la transformación de los servicios municipales persiguiendo objetivos de eficiencia, sostenibilidad e innovación y de los distintos Planes para la integració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 los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizadas para resolverlos.

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

9 Obligaciones esenciales ‌

Tendrán la consideración de incumplimientos de obligaciones esenciales y podrán dar lugar a la “resolución del 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 servicios contratados sin causa justificada.

❑ La no aportación del personal mínimo exigido y necesario para la realización de los trabajos y prestaciones 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 al adjudicatario, 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, el incumplimiento de las especificaciones del proyecto o la imposibilidad cumplimiento del objetivo de verificar que la plataforma implantada responde a las especificaciones técnicas establecidas en el pliego, 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 informes que 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 o funcionarios municipales.

10 Criterios de selección ‌

Con el objeto de adjudicar el servicio a un Contratista con las garantías precisas para el adecuado cumplimiento de las obligaciones que se especifican en el presente pliego de condiciones, las condiciones mínimas de solvencia técnica que se exigen a los licitadores para optar a la adjudicación y que deberán acreditar suficientemente, son las siguientes:

❑ Haber realizado en los últimos cinco años al menos en 2 contratos relacionados con el objeto del presente contrato o prestar en la actualidad un servicio de soporte y consultoría de una plataforma de 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 de 3 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 marcha de la plataforma de gestión integral de:

• Al menos 6 personas con titulación universitaria superior en las áreas de informática y telecomunicaciones que tengan experiencia en contratos relacionados con la integración de 3 o 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 2 proyectos relacionados con el GIS Smallworld.

✓ Hardware y software de los equipos CE.

11 Criterios de adjudicación ‌

A 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 a la 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 de clá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 cada uno 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 propuesta técnica que permita, en el menor tiempo posible, conseguir con éxito los objetivos del contrato y disponer de una plataforma de gestión integral que ofrezca un repositorio de datos y de funcionalidades comunes que facilite un cambio en el modelo de gestión de los servicios municipales, incremente la capacidad de interoperar con organismos externos y permita un enfoque Big Data y Open Data para promover en la ciudadanía la participación, transparencia e innovación. Estos criterios se centran la valoración de la idoneidad y calidad técnica de las propuestas, en el cumplimiento de las características especificadas, en la definición, estructura y flexibilidad del equipo de soporte y consultoría, en la gestión de calidad y metodología para el desarrollo de los proyectos, en la propuesta de formación y transferencia tecnológica al personal municipal, en el aseguramiento de la evolución y continuidad de la plataforma y en las capacidades funcionales de los distintos módulos componentes y su grado de cohesión e integración.

Instrucciones sobre la documentación a presentar

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

2. Toda la documentación, incluidos índices, anexos, planos,... se debe presentar además en formato electrónico tipo PDF, o cualquier otro formato legible mediante software de libre distribución y deberá 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 a infraestructuras y redes de comunicación, se deberán incorporar como anexo, en formato electrónico tipo PDF, o cualquier otro formato legible mediante software de libre distribución, las hojas de especificaciones del fabricante de todos los elementos suministrados, tanto hardware como software, dentro del presente procedimiento.

Esta documentación anexa no se considerará a efectos del cálculo del número máximo de pá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 posibles ofertas, en la documentación referente a la plataforma de gestión integral, se podrá incluir como anexo, en formato electrónico tipo PDF, o cualquier otro formato legible mediante software de libre distribución, las especificaciones de productos, herramientas, metodologías, etc. que se correspondan 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 oferta en ese apartado incluirá consideraciones de la elección, ventajas que puede aportar, uso o adaptación de la misma, etc. y, si procede, se incluirá como anexo la documentación técnica oficial.

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

5. A efectos de verificar la existencia, apariencia y funcionamiento de interfaces, módulos o elementos software ya desarrollados, el adjudicatario podrá acompañar la descripción de características y especificaciones de la oferta con enlaces a versiones “demo” en sistemas web que permitan valorar estos aspectos. En estos casos, se incluirá en la oferta, indicando el usuario y contraseña o mecanismo habilitado, la url exacta de acceso y, además, se anexará documento que incluya la impresión de las distintas pantallas a valorar. Las versiones “demo” deben permitir interactuar 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 la fecha de adjudicación del contrato.

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

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 indicados anteriormente 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 dos bloques:

• un bloque principal que debe mantener la estructura y orden propuesto en el apartado de criterios 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 como características técnicas de equipamiento o productos, etc. según se ha indicado anteriormente.

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

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 de comunicación acorde a las especificaciones descritas en el PPT. La documentación mínima a presentar incluye:

❑ 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 fabricante del mismo para su correcta identificación

❑ Inventario detallado de elementos y licencias software a suministrar dentro del presente proyecto incluyendo para cada uno de ellos la cantidad a suministrar y el código de referencia del fabricante para 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ámaras de vigilancia de trafico

❑ Esquema físico y lógico del sistema de atención presencial, telefónico y vía chat y correo electrónico suministrado, incluyendo todos los componentes a suministrar y el papel que desempeñ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 de transferencia pico y media de los sistemas centrales suministrados requeridos para el correcto funcionamiento 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, la capacidad 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 los sistemas 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 la Versatilidad y funcionalidades del interfaz cliente del sistema.

11.2.2 Idoneidad y Planificación de la ejecución e implantación del contrato

En este apartado, la documentación debe incluir:

Máximo 7 puntos.

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

Se valorara la claridad y el rigor de la argumentación del planteamiento general y la coherencia del conjunto 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 diferentes tareas a desarrollar tomando como base las especificaciones realizadas en el apartado de Hitos y

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 marcha de los distintos elementos que la integran. La presentación de la planificación se llevará a cabo por medio 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, la existencia de mecanismos que faciliten el control y seguimiento de las tareas, así como la correcta identificación de los puntos más críticos del proyecto y la reducción del plazo previsto de implantación y puesta en marcha basada en la reutilización e incorporación de desarrollos ya existentes.

Puntuación máxima 3 puntos.

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

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

Puntuación máxima 1 puntos.

d) Metodología de Gestión de proyectos: la oferta debe justificar la propuesta de metodología de gestión de proyectos para las distintas actividades y fases, destacando los aspectos más relevantes 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 los requerimientos del presente pliego, las aportaciones metodológicas más allá de las descripciones generales, la implementación de esta metodología en la estructura y operativa del equipo y el uso de herramientas que contribuyan a la gestión del proyecto.

Puntuación máxima 2 puntos.

11.2.3 Arquitectura y características de la Plataforma

En este apartado, la documentación debe incluir:

Máximo 5 puntos.

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

El cumplimiento de las especificaciones del PPT en este apartado se ha identificado como requisito imprescindible en el Anexo E. Se valorarán aspectos y características adicionales que se incluyan 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ón como soporte de la captación, análisis e integración de datos para la gestión integral de los servicios urbanos, el observatorio y seguimiento de la ciudad, la integración con los servicios municipales y las relaciones con el ciudadano.

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

Puntuación máxima 2 puntos.

b) Características técnicas: la oferte debe argumentar el cumplimiento de las especificaciones del PPT 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ón integrada que redunden en una mejora técnica de la solución propuesta.

• 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 la misma.

• La facilidad de la plataforma para crecimiento horizontal en función de la evolución de las necesidades.

Puntuación máxima 3 puntos.

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 dar respuesta 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 la exposición, en especial la aportación de esquemas, imágenes y versiones "demo” que faciliten la comprensión de las funcionalidades, características y operativas descritas, la adecuación y contribución de los componentes de la propuesta a la consecución de los objetivos del contrato, el grado de desarrollo y las capacidades implementadas que faciliten y acorten su puesta en marcha, la integración e interconexión con funcionalidades y capacidades de la propia Plataforma, y el rigor y detalle de la solución propuesta en aspectos relacionados con:

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

• Servicios Administración y Gestión de la Plataforma: la oferta debe enumerar y describir la interfaz y los servicios básicos destacando las funcionalidades y características que redunden en 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 el desarrollo de funcionalidades de gestión de la Plataforma.

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

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

• IoT (Internet of Things: Internet de las cosas): Capacidad de Integración y gestión de sensores, actuadores y dispositivos. Descripción de los procesos de captación, normalización y 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 de funcionalidades de la plataforma.

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

• Servicio de Almacenamiento: la oferta debe enumerar y describir la arquitectura de solución para las distintas necesidades de almacenamiento de datos según su disponibilidad, volumen y tipo de contenido especificado en el PPT y debe justificar y optimizar los sistemas de almacenamiento 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.

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

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

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 mando ya elaborados que sean de interés para los objetivos del contrato.

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

✓ La capacidad de la Plataforma para implantar un enfoque de la gestión de la calidad de los 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ón georreferenciada de los contenidos y la integración con el GIS municipal según se especifica en el apartado correspondiente.

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

Puntuación máxima 3 puntos.

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

• Gestión de Servicios Verticales/Horizontales: capacidades propuestas para satisfacer las necesidades 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 y especificaciones indicadas en el PPT para los distintos sistemas de gestión.

✓ Las capacidades de integración de los sistemas entre si, con otros sistemas municipales y con los futuros servicios a integrar y la utilización de funcionalidades y contenidos comunes de la Plataforma.

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

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

✓ La incorporación xx xxxxxxx de información adicional de interés en la gestión de alertas e incidencias.

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

✓ El rigor y detalle de la propuesta para la gestión de la capa de negocio mediante procedimientos almacenados y la coherencia del modelo de datos planteado con las especificaciones 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 la capacidad 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 capacidad de interactuar con todos los elementos y contenidos de la Plataforma, el aprovechamiento de las últimas herramientas disponibles y el sistema GIS para el observatorio de la ciudad que incluye el control, inventario y motorización del estado de recursos, indicadores de calidad y cuadros de mando que proporcionan información para el seguimiento de los servicios y la toma 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, la capacidad y facilidad de interactuar con todos los contenidos de la Plataforma, el grado de avance en el desarrollo de la solución propuesta y las facilidades aportadas para su valoración.

• Integración con los Sistemas o Aplicativos Municipales y Sistemas Externos: la oferta debe enumerar 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 ambos sentidos 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 de interrelación con los ciudadanos.

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

Puntuación máxima 11 puntos.

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 de consultoría y soporte tecnológico, con detalle de la organización y disponibilidad de los recursos humanos del adjudicatario, incluyendo estructura, perfiles, cualificación, dedicación y disponibilidad del personal, metodología y herramientas utilizadas y nivel de servicio en las tareas de 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 el PPT, en especial:

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

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

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

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

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

Puntuación máxima 6 puntos.

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 de indicadores de servicio de la Plataforma y la planificación temporal para su implementación durante la vigencia del contrato.

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

• 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 la Plataforma 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 las necesidades 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 la plataforma por parte del personal municipal asignado. Se incluirán perfiles, contenidos, duración y temporalidad, etc. de los cursos y actividades a realizar.

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

Puntuación máxima 2 puntos.

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

Se valorará en especial:

• El grado de coherencia y rigor del Plan de Transferencia Tecnológica propuesto para conseguir la gestión autónoma de la Plataforma y el desarrollo de nuevas funcionalidades por parte del personal municipal.

• Las actuaciones propuestas y recursos comprometidos para el trasvase de conocimiento al personal municipal y la proximidad y disponibilidad de los canales de comunicación propuestos.

Puntuación máxima 2 puntos.

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 la plataforma, incluir las consideraciones y compromisos de la propuesta en materia protección de datos personales, seguridad y confidencialidad de la información y la propuesta soporte a la evolución de la Plataforma.

Se valorará el rigor, detalle y grado de cumplimiento y coherencia con las especificaciones del PPT, las medidas 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 y descripción de los compromisos y medidas a adoptar para garantizar la continuidad tecnológica de la plataforma.

Además de lo indicado, se valorarán especialmente los compromisos adquirido por el adjudicatario y la capacidad de cambio de modelo de la plataforma (evolución a modelo “in cloud”) sin coste ni pé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 los procedimientos y la integración y seguimiento de las actuaciones en el servicio de soporte de la Plataforma.

Puntuación máxima 0,5 puntos.

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

Además de lo indicado, se valorará en especial la capacidad de consultoría, medios empleados y colaboración para la planificación y desarrollo de los proyectos de integración, los puntos fuertes de la solución para garantizar la integración de nuevas funcionalidades y servicios, desarrollados por el Ayuntamiento xx Xxxxxxx o por terceros, así como la facilidad y capacidad de interoperación y reutilización de funcionalidades y la existencia de una API abierta y de un SDK (Software Development Kit).

Puntuación máxima 1 punto.

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

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

Puntuación máxima 1 punto.

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, la documentación debe incluir la visión y propuesta del adjudicatario para el desarrollo del proyecto piloto que permita 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 y coherencia con las especificaciones del PPT, las propuestas y aportaciones para la verificación de las funcionalidades de la Plataforma y la capacidad de innovación y evolución de la propuesta superada la fase de verificación del proyecto piloto.

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

Logroño, a 6 de septiembre de 2016

Xxxxxxx Xxxxxxx Xxxxxxx

Coordinador del Grupo de Trabajo Plataforma Smart Logroño

ANEXO A:

INFRAESTRUCTURAS Y REDES DE COMUNICACIONES

12 ANEXO A: Infraestructuras y Redes de Comunicaciones ‌

12.1 Dotación de equipos centrales

El Ayuntamiento xx Xxxxxxx pondrá a disposición del suministrador de la plataforma y las verticales a integrar 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 la plataforma. Como directiva general de utilización del entorno se deberán crear tantas máquinas virtuales como 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 para ejecutar 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, cuyas caracterí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. En caso de requerirse se podrán crear usuarios de acceso para la gestión/manejo de máquinas específicas del entorno por parte del personal de mantenimiento de la plataforma con objeto de mejorar la gestión del sistema. No obstante, el personal técnico del Ayuntamiento xx Xxxxxxx deberá disponer siempre de capacidad 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ía SAN (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 esta capacidad de almacenamiento mediante la creación de los correspondientes discos virtuales. Las directivas generales de utilización se establecerán una vez adjudicado el suministro. Como orientación respecto a la utilización del almacenamiento masivo:

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

• Los discos virtuales creados serán de aprovisionamiento Thin

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

12.1.3 Infraestructura de conectividad

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

El Ayuntamiento xx Xxxxxxx garantizará la conectividad a nivel IP de los servidores virtuales con el resto de infraestructura 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 xx Xxxxxxx. No obstante el adjudicatario deberá tender a 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 servidores virtuales tenderán a utilizar plataformas de 64 bits.

En caso de ser necesaria la utilización de plataforma Windows u otro sistema operativo propietario, las licencias del sistema operativo deberán adquirirse bajo el acuerdo Open que indicará el Ayuntamiento xx Xxxxxxx. Dichas licencias de sistema operativo incluirán el servicio de Microsoft Software Assurance durante la 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 tal manera que el Ayuntamiento xx Xxxxxxx disponga de libertad para el acceso al sistema sin restricciones de utilizació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 la plataforma Smart Logroño. Las licencias de uso pasarán a ser propiedad del Ayuntamiento xx Xxxxxxx una vez finalizado el presente contrato. Será responsabilidad del adjudicatario mantener los productos suministrados actualizados a las versiones adecuadas para el correcto funcionamiento de la plataforma Smart 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 las máquinas virtuales utilizadas en la infraestructura de la plataforma Smart Logroño. El proceso de instalación de todos los elementos deberá garantizar la transferencia de conocimiento hacia el personal municipal de acuerdo 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 que designe el Ayuntamiento xx Xxxxxxx para determinar las condiciones de configuración de todos los elementos y las modificaciones indicadas en al apartado anterior. A la finalización de dichas reuniones, el adjudicatario deberá entregar un planning de ejecución del despliegue inicial teniendo en cuenta las modificaciones que haya podido sufrir.

El Ayuntamiento xx Xxxxxxx se compromete a, de común acuerdo con el adjudicatario, a realizar la definició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 vez adjudicado el suministro. El adjudicatario se compromete a adaptar los datos de configuración incluidos en la oferta a las necesidades planteadas por el Ayuntamiento xx Xxxxxxx siempre que dicha adaptación no represente 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 xx Xxxxxxx.

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

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 los que 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 xx Xxxxxxx dispone de una red de radio DMR de acuerdo a la norma ETSI - TS 102 361 con multiplexación TDMA a 2 slots susceptible de ser utilizada para la transmisión de datos de futuros sensores o actuadores.

El nivel de cobertura del municipio xx Xxxxxxx es de un 85% incluyendo los polígonos industriales.

12.2.1.2 Tendidos de fibra óptica

Actualmente, el Ayuntamiento xx Xxxxxxx dispone de una red de fibra óptica propia dentro de la cual se encuentran 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 de fibra óptica se encuentra tendido a través de canalizaciones propiedad del Ayuntamiento xx Xxxxxxx y comparten dichas canalizaciones, en parte, con los tendidos propios que dan servicio al sistema de alumbrado 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 o recomendable conectarse mediante las redes anteriores deberán establecer su comunicación mediante redes 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ía redes 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 apartados anteriores. Adicionalmente y durante la duración del contrato, el adjudicatario podrá proponer nuevos

equipos o soluciones tecnológicas que considere mejoras para el sistema. Dichas mejoras o cambios en el equipamiento a suministrar deberán ser aprobadas por el Ayuntamiento xx Xxxxxxx.

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 y las ampliaciones que se irán realizando un sistema de transmisión basado en protocolo Carrier Ethernet 2.0 hasta los puntos primarios y secundarios de la red que permita definir mecanismos de comunicación independiente para los diferentes sistemas involucrados en el presente servicio y que sea susceptible de ampliació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 sistema se compondrá de un anillo que una todas las ubicaciones principales indicadas. No obstante, la arquitectura de la solución propuesta debe permitir la implementación de múltiples anillos con las ampliaciones necesarias.

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

❑ El punto de concentración estará ubicado en la Casa Consistorial. Éste se constituirá igualmente con partes críticas redundadas. La conexión del punto de concentración a la MAN corporativa se realizará mediante la utilización de interfaces CE a 10 GB (al menos 2 conexiones) contra los equipos corporativos (2 x Cisco Catalyst 6509 en VSS) que se encuentran en el CPD de la Casa Consistorial. El suministro deberá incluir los adaptadores ópticos necesarios para la interconexión de las redes en ambos extremos. El Ayuntamiento xx Xxxxxxx garantiza la disponibilidad de, al menos, 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 xx xxxxx total de 10Gbps en cada anillo configurado, ya sea este compartido por todo el anillo o mediante la utilización de agregación de enlaces 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.0 o 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 Ethernet que 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 cobre o 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 entre cualquiera de las ubicaciones secundarias y primarias, utilizando para ello los interfaces UNI suministrados por la electrónica de las ubicaciones primarias y/o las secundarias. Se deberán soportar 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 ubicaciones principales.

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

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

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

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

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

❑ Se deberá disponer de software de Gestión de Red con alarmas y vista gráfica de servicios extremo a extremo, licenciado con suficiente capacidad para no requerir ampliaciones de licencias en caso de incorporación de nuevos elementos a la red. El sistema de Gestión de Red deberá ser accesible 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 sistema instalado deberá enviar alertas SNMP y métricas SNMP de los diferentes circuitos físicos y virtuales definidos a los gestores centrales del Ayuntamiento xx Xxxxxxx para su monitorización.

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

Actualmente se encuentran instalados switches xxxxx Xxxxxxxxxx en diferentes ubicaciones de la red de tráfico que podrán ser reutilizados en los puntos de conexión principales o secundarios en caso de considerarse 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 la utilización de la red 3G/4G.

Para dicha conexión, en el caso de que los elementos dispongan de conectividad Ethernet, el adjudicatario deberá suministrar routers con tecnología 3G/4G para su instalación dentro de los cuadros de alumbrado o reguladores semafóricos. Las características de referencia que deberá cumplir el router 3G suministrado será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 router en 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 ser posible 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 del Ayuntamiento xx Xxxxxxx 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 los equipos de conectividad inalámbrica de acuerdo a las especificaciones de conectividad necesarias en función de los requerimientos de ancho xx xxxxx y nivel de transmisión de datos del sensor/actuador al que vaya a dar servicio.

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

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

El adjudicatario será responsable de suministrar o dar acceso al Ayuntamiento xx Xxxxxxx a un sistema de gestión M2M que permita monitorizar las tarjetas SIM suministradas y actuar sobre la gestión de las mismas por 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 equipos conectados mediante fibra óptica, estableciéndose el equipo de comunicación 3G como punto principal de conectividad y pudiendo desplegar desde este hacia puntos secundarios mediante fibra o cobre las conexiones necesarias. No obstante, el adjudicatario tendrá que tener en cuenta el ancho xx xxxxx disponible en la red 3G/4G en subida y en bajada y garantizar en cualquier caso la asignación a los puntos secundarios de suficiente ancho xx xxxxx para el correcto funcionamiento de los sensores/actuadores y su interacció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 y 3G de conectividad, se realizará de común acuerdo con el adjudicatario una vez adjudicado el presente suministro, prevaleciendo en caso de conflicto la decisión del Ayuntamiento xx Xxxxxxx. Dicho despliegue inicial 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 lo especificado 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 el Ayuntamiento xx Xxxxxxx.

El adjudicatario estará obligado a indicar los precios unitarios de cada uno de los elementos de comunicació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 el despliegue de red indicado en el presente pliego de prescripciones técnicas, siendo este como máximo de 6 meses desde la fecha de inicio del contrato.

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 una topología lógica xx xxxxxxxx y física de anillo.

Concretamente los equipos actuales se componen de los siguientes elementos:

❑ Cámaras analógicas XXXXX 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 monitores CRT existentes.

❑ Videograbador de 16 entradas ECV ECO-REC 16H.

12.3.2 Conectividad de las cámaras

La conectividad entregada deberá garantizar el ancho xx xxxxx requerido para el visionado de las cámaras a una velocidad de al menos 15 fps en cualquier punto de la red principal corporativa. Para ello, tal y como se ha indicado anteriormente se deberá utilizar un EVC con el ancho xx xxxxx garantizado entre la cámara y 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 la transmisión entre estas y el servidor de cámaras se realice mediante dicho protocolo. En caso de no poder adaptar 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 dichos requerimientos. Así mismo, también será requerimiento la adaptación de los sistemas de control y telemetría existentes en las cámaras actuales. La características ópticas de las cámaras suministradas deberán ser de iguales 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 las siguientes funcionalidades en:

❑ El suministro incluirá tanto el/los equipo/s servidor como un equipo cliente que se utilizará en el centro de control para su conexión al sistema de VideoWall instalado. Así mismo, se incluirán las licencias 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á estar preparado 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 no sea 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 mediante má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 una aplicación cliente/servidor sobre plataforma Windows 7 o superior con todas las funcionalidades del sistema disponibles. Adicionalmente se deberá disponer también de un cliente “ligero” vía web que permita, al menos, la consulta en tiempo real del sistema de cámaras. Este cliente ligero se

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

❑ Capacidad de configuración de los elementos visualizados dependiendo del cliente y/o el usuario que haga login al sistema. El sistema deberá permitir la configuración de esquemas dinámicos que sean 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 el Ayuntamiento xx Xxxxxxx pueda instalar tantos clientes como considere necesario, estando limitado únicamente por la degradación del rendimiento que surja de atender dichos clientes. El sistema deberá estar dimensionado para la instalación y ejecución simultánea de al menos 3 clientes 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 los clientes de visualización (al menos en los clientes “pesados”). Como mínimo deberá ser capaz de presentar en los clientes la visualización de la cámara o cámaras de origen de la alerta. Las alertas 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ámara definibles 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. Por ejemplo, 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ón con el objeto de optimizar los anchos xx xxxxx de la red.

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

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

❑ Acceso al sistema mediante usuario y contraseña y posibilidad de asignar a cada usuario diferentes roles en función de su responsabilidad. Al menos se deberá poder especificar por cada cá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 extracciones deberán poder realizarse en un formato de vídeo fácilmente visualizable. Se valorará la implementación de diferentes codecs.

• Capacidad de acceso a la telemetría de cada cámara. Se valorará la posibilidad de diferenciar entre movimiento libre o únicamente movimiento a puntos prefijados por el administrador del sistema.

12.3.3.1 Características del sistema existente

Actualmente el Ayuntamiento xx Xxxxxxx dispone de un sistema de cámaras de seguridad distribuido compuesto por:

• 6 servidores de grabación y control ubicados en diferentes dependencias municipales que ejecutan 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.

• 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 los anchos xx xxxxx 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 de cámaras anteriormente descrito, de tal manera que las cámaras de control de tráfico se traten como cualquier otra de las existentes.

Dentro del suministro se deberá incluir todo el hardware, software y licenciamiento necesario para la integración de las 15 cámaras existentes. No se deberá contar con recursos de los servidores existentes para 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 videowall existente, 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 garantizar la capacidad de visualización de, al menos, 16 cámaras del sistema. Dichos equipos se instalarán en las dependencias de la sala de control en un armario rack cercano a la ubicación del controlador del sistema de VideoWall existente.

El sistema se deberá integrar con la plataforma de Smart Logroño permitiendo la obtención de imágenes estáticas de las cámaras integradas en el sistema, de tal manera que la plataforma sea capaz 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 los sistemas necesarios para poder visualizar las cámaras de control de tráfico de acuerdo a lo indicado anteriormente 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 la red corporativa. Esto incluirá los equipos PC necesarios y paneles de visualización de tamaño suficiente para 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 su uso por parte de los operadores del Centro de Control Integral y del personal de atención presencial. El sistema de operación deberá integrarse con la plataforma suministrada y actuar como nexo entre el personal 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 por cualquiera de los medios indicados (ToIP, Chat o e-mail) desde el propio puesto de trabajo del operador. Las características que debe cumplir dicho interfaz son las siguientes:

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

• El sistema deberá incluir un sistema de atención vía chat escrito. El sistema permitirá el login de los agentes de atención al sistema de chat y el acceso de los ciudadanos desde Internet mediante 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 encuentre realizando una atención vía Chat deberá considerarse en estado ocupado y evitar que se le transfieran otro tipo de solicitudes de atención. Para la ejecución del sistema de chat por parte de 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 que quieran utilizar este servicio.

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

• El interfaz del operador deberá poder ser ejecutado utilizando un terminal basado en PC. En caso de ser necesaria la dotación de equipos adicionales para el correcto funcionamiento del sistema (terminales ToIP, etc) deberán incluirse dentro del suministro de la solución y responsabilizarse de su mantenimiento durante la duración del contrato. Así mismo, el sistema deberá ser susceptible de ser ejecutado en el entorno VDI indicado en el presente pliego 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 los siguientes apartados.

• El sistema deberá permitir establecer dinámicamente las funciones de cada uno de los agentes que se incorporen al sistema, de tal manera que se pueda establecer el tipo de solicitudes 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 realizar dinámicamente por parte del supervisor del sistema

• Distribución automática de las solicitudes hacia los agentes u otros recursos definidos (guías vocales, operadores automáticas, módulos de la plataforma, etc.) en función de diferentes pará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 la plataforma que permita la monitorización de las métricas de rendimiento y de los diferentes tiempos de las solicitudes de atención.

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

• El sistema deberá permitir la apertura xx xxxxxxx de chat al menos entre el supervisor del sistema 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 el agente, independientemente del origen de las mismas. Los datos obtenidos de las evaluaciones realizadas por los llamantes deberán ser capaces de ser exportados y/o interrogados por los niveles superiores de la plataforma Smart Logroño para su integración dentro de los módulos de análisis.

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

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

• Se valorará la posibilidad de integración del sistema con soluciones de reconocimiento vocal y conversió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 de interrogación por parte de los niveles superiores de la plataforma para la realización de su tratamiento 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 los niveles superiores de la plataforma para integrar la información obtenida de dicho sistema como datos de entrada para los cálculos estadísticos de atención al ciudadano.

Para este cometido, el Ayuntamiento xx Xxxxxxx se compromete a establecer los mecanismos necesarios para que los equipos que contengan los sistemas de la plataforma Smart City tengan acceso al servidor que controla los equipos de Qmatic. Dado el tipo y naturaleza de la información recabada por el sistema y que esta no es necesaria en tiempo real, se admitirá como solución la exportación periódica de ficheros desde el sistema 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 puedan evaluar la calidad de la atención recibida mediante un control de pulsadores que indiquen su grado de satisfacción. El sistema deberá asociar al nivel de satisfacción establecido al agente del que ha realizado la atención y la fecha y hora de la misma. La solución óptima pasaría por extender el sistema Qmatic con este tipo de mecanismo en caso de ser posible, en caso contrario, el sistema deberá ser capaz de enviar hacia la plataforma de Smart City la información obtenida o bien permitir la interrogación por parte de la plataforma de la información. Se valorará la capacidad de obtener del sistema información en tiempo real para su supervisió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ón presencial 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 xx Xxxxxxx se basa en una solución de la marca Cisco e incluye la infraestructura 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 del presente contrato en ningún caso se admitirá la instalación de nuevos elementos software o hardware sobre los equipos actuales que produzcan un detrimento en el rendimiento del sistema actual o que no cumplan con 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) diversificados en dos ubicaciones.

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

Plataforma software

El sistema se compone de los siguientes elementos software instalado sobre la arquitectura hardware anteriormente 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 equipos suministrados

El adjudicatario deberá incluir el servicio de mantenimiento correctivo de los elementos indicados en el presente 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 xx Xxxxxxx un número único de notificación de avisos para todos los elementos detallados en el apartado de infraestructuras del presente pliego. Dicho nú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 los siguientes 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ón o 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

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

A continuación se detallan cada uno de los elementos suministrados y los niveles de avería que se consideran 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 la plataforma Smart Logroño o el funcionamiento de cualquiera de las verticales incluidas en la plataforma o implique un nivel de incomunicación con los elementos desplegados que haga imposible el correcto funcionamiento 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 que surja en los sistemas de red que pueda ser subsanado mediante balanceo de carga de los elementos redundantes sin que se produzca una degradación de rendimiento que impida, en la práctica, la ejecución de 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 las tareas de atención al ciudadano. Se considerará crítica la caída del sistema de atención vía ToIP y grave la caí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 que dichos fallos no impidan el acceso a más del 20% de los operadores que hayan iniciado sesión en el sistema. 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, se realizará 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 e infraestructura central que atiendan la solución ofertada de integración de las cámaras de tráfico.

ANEXO B:

PLATAFORMA DE GESTIÓN INTEGRAL

13 ANEXO B: Plataforma de Gestión Integral ‌

La Plataforma de Gestión Integral de Servicios Públicos (en adelante Plataforma) es el conjunto de sistemas informáticos, técnicas y herramientas que tienen como objeto el aprovechamiento de información diversa obtenida 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 permitan la gestión eficiente, coordinada e integrada de la ciudad y de los servicios municipales, faciliten la toma de decisiones en base a la información que recibe y procesa, eleven la calidad de vida de los ciudadanos y aumenten 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 de especialización del componente o servicio vertical que requiera de otras tecnologías, manteniendo siempre el requisito de disponer de interfaces abiertas para asegurar la integrabilidad con el resto de la plataforma y sistemas municipales y externos.

El modelo arquitectónico debe ser abierto y multicapa basado en estándares que mantienen la independencia de la interfaz gráfica respecto al diseño de los procesos de negocio y éstos a su vez con la base de datos. Estos estándares serán, en la medida de lo posible, elementos xxx xxxxxxx de libre distribución que estén suficientemente probados y consolidados para su implementación en un entorno de estas características. La Plataforma debe estar soportada en una estructura física y lógica fundamentada en entorno Web y basada en un patrón que separe, al menos, las capas de presentación y control, de lógica de negocio y de acceso a datos para conseguir la independencia y robustez de cada una de ellas al estar centradas en sus objetivos específicos. La Plataforma debe estar construida sobre un conjunto limitado y optimizado 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 deben cumplir las especificaciones de referencia indicadas en PPT, resaltando que las licencias de uso, tanto de desarrollo como de producción, deben ser a perpetuidad y la titularidad debe ser del Ayuntamiento xx Xxxxxxx.

La solución propuesta para la Plataforma debe ser en modo “on-premise” o “in-house”, es decir, la infraestructura hardware y el software deberán ser implantados en el Ayuntamiento xx Xxxxxxx. Para lo cual el adjudicatario debe suministrar dos entornos, uno de Producción y otro de Desarrollo. Ambos entornos deben ser tecnológicamente iguales, con las diferencias propias de la finalidad de este último de permitir el desarrollo y prueba de funcionalidades antes de su despliegue en Producción y el adjudicatario debe proporcionar 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 una forma horizontal como vertical.

b) Debe disponer de capacidad para integrar una gran cantidad de datos generados desde múltiples fuentes 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 la toma de decisiones y el aprendizaje del comportamiento de la ciudad.

d) Xxxx dotar a los gestores públicos, proveedores de servicios y a la ciudadanía de las herramientas 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 un enfoque Open Data para incrementar la participación ciudadana y la transparencia y establecer un entorno 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 de programación abierta (API) y estándares que permitan que tanto el Ayuntamiento como terceros (fabricantes o desarrolladores) puedan desarrollar otros módulos o aplicaciones para incorporar nuevas funcionalidades

o integrar nuevos servicios.

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

Modularidad, adaptabilidad y evolución.

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

Debe permitir la integración de la información desde diferentes soluciones/sistemas y dispositivos, disponer de capacidad de integración con los servicios/plataformas de gestión de la ciudad y debe permitir el desarrollo y la integración de servicios y aplicaciones proporcionados por entidades externas de forma sencilla 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 de datos, velocidad de proceso y capacidad de respuesta en tiempo real.

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

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 los procesos 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 debe ser personalizable y ampliable.

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

Resiliencia.

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

Accesibilidad y usabilidad.

La Plataforma debe respetar los protocolos internacionales de accesibilidad (W3C y las Web Content Accessibility Guidelines 1.0, elevando al máximo la accesibilidad del sistema y, para las funcionalidades orientadas 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ándose principalmente 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 visualizarse correctamente en los navegadores estándar imperantes en el mercado, en sus últimas versiones y con diferentes resoluciones de pantalla.

La Plataforma debe ofrecer facilidad de operación, configuración y mantenimiento en todos los niveles de servicio: gestores, administradores, desarrolladores, etc. La interfaz debe ser homogénea, intuitiva y fácil de usar 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 de tratamiento de la información en una ciudad inteligente para proporcionar una visión integrada de la misma y consolidarse como columna vertebral que facilite la integración de los sistemas verticales existentes y futuros 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 la transmisió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 de datos 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 de alertas/actuaciones y el seguimiento de la ciudad.

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

• Integración con sistemas municipales.

• Portales de acceso para ciudadanos, organizamos y empresas externas.

• Enfoque Open Data para la externalización de los datos y posibilitar el desarrollo de aplicaciones de 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 su capacidad 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 soporte global o específico a las verticales integradas, al gobierno y gestión de la ciudad, a los sistemas municipales 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 la plataforma: gestión de usuarios, acceso, auditoría, seguridad, supervisión y monitorización, ayuda, etc. y debe ofrecer a los gestores un portal de “acceso unificado” a las distintas funcionalidades autorizadas según los 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. La interfaz debe ser personalizable, intuitiva y de fácil uso, y permitir a los gestores, de forma autónoma y sin necesidad de mayores conocimientos, gestionar los dispositivos y orígenes de datos integrados en la plataforma, 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 los servicios avanzados. La interfaz debe integrar el acceso a funcionalidades incluidas en los servicios básicos y avanzados de la Plataforma y debe permitir una evolución fácil y sencilla para adaptar o incorporar nuevas funcionalidades.

La Plataforma debe disponer de mecanismos que garanticen la confidencialidad, integridad, disponibilidad y trazabilidad 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 consumo de 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 a elementos de la Plataforma (indicadores, informes, memorias y estadísticas, cuadros de mando, etc.) y ejecución de funcionalidades y servicios de la misma.

b) Debe considerar diferentes tipos de acceso según sean individuos, dispositivos o aplicaciones los que consuman servicios o información de la misma, según sean usuarios internos o externos, etc. Para ello, debe contemplar la identificación contra un directorio de LDAP (Active Directory 2003 o superior y OpenLDAP al menos) valorándose la opción de múltiples repositorios LDAP y posibilidades de identificación a través de otros mecanismos como usuario/contraseña, tokens, OAuth, certificados electrónicos etc. y disponer de capacidad para extenderse y adaptarse con facilidad a otro tipo de soluciones avanzadas basadas, por ejemplo en técnicas biométricas.

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

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

La oferta debe enumerar y describir la interfaz y los servicios básicos destacando las funcionalidades y caracterí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 en la Plataforma tanto para su integración y puesta a disposición de los distintos servicios autorizados como su interoperabilidad con otras plataformas. Debe estar preparado para recibir grandes volúmenes de datos heterogéneos, tanto estructurados como no estructurados, y establecer las reglas de tratamiento y almacenamiento que posibiliten su puesta a disposición del resto de componentes de la Plataforma para una gestión integral de los mismos.

Es el responsable de estandarizar y normalizar los distintos contenidos y fuentes de datos, tanto internas como 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 casos que se establezca, a los ciudadanos, en los formatos habituales a través del Portal Open Data ciudadano y del Portal Smart Ciudad. Del mismo modo, dispondrá de capacidades de integración con las aplicaciones municipales.

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

La Plataforma debe facilitar el desarrollo o integración de aplicaciones en todos los niveles (servicios verticales actuales o futuros, Sistemas Municipales, desarrolladores externos, …). Todo ello, acorde a los mecanismos y procedimientos indicados para definir las autorizaciones de acceso a los contenidos de la Plataforma. Para ello, dispondrá de integradores o conectores que suministren, de forma fácil y sencilla, los distintos 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 estas aplicaciones 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/actuadores con el objeto de tener independencia en la inclusión de nuevos sistemas de gestión y/o equipos de sensorizació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 se compromete a mantener actualizada la publicación de todas las funcionalidades de integración existentes en la Plataforma, así como mantener una documentación exhaustiva de la API, servicios web u otros mecanismos 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 de comunicaciones.

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

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

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

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

❑ Normalizar la información recibida de los sensores y sistemas de gestión verticales de tal manera que 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 y a los sistemas de gestión verticales actuales para la interactuación de los niveles superiores hacia dichos 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 la obtenció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 (Kit de 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 de aplicaciones 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 la informació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 optimizado de sistemas de almacenamiento de datos para favorecer su mantenimiento y evolución y la transferencia de conocimiento.

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 xxxxxxx e incidencias y la visión global de la ciudad.

❑ Información integrada de actuaciones, avisos, afecciones e incidencias y eventos de todo tipo del sistema 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 de indicadores y cuadros de mando de los sistemas de gestión de verticales y de la gestión de la propia plataforma.

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

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

Para realizar la valoración, la oferta debe justificar y optimizar las soluciones y sistemas de almacenamiento propuestos en cada caso y contener una tabla que indique como mínimo, para los distintos tipos de informació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 sencillas para manejar grandes conjuntos de datos xx xxxxxxx diversas, con un gran número de variables y en condiciones de tiempo real, obteniendo indicadores de servicio de alto valor añadido. Un sistema que de respuesta a las necesidades de obtención de información y facilite el conocimiento, medida y optimización de 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, la existencia 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, de predicción y simulación de estrategias, de implementación de reglas y políticas de gestión que permitan poner a disposición de los servicios avanzados de la Plataforma los recursos y estructuras que faciliten la gestión, seguimiento, control y soporte a la toma de decisiones sobre los Servicios Verticales, la gestión global de la ciudad y los Servicios Municipales. Además, debe proporcionar un repositorio estructurado que almacene los objetos generados (plantillas, consultas, informes, memorias y estadísticas, cuadros de mando, etc.).

Para obtener la información y presentar los resultados, la Plataforma proveerá de una interface, acorde a lo descrito en las características generales, intuitiva y gráfica, apoyada en un sistema de visualización de datos geográficos con altas capacidades de interacción que facilite la toma de decisiones estratégicas y operativas de 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 uso de este u otro sistema GIS como una herramienta básica de apoyo para la gestión de los distintos servicios de la Plataforma y servicios verticales, de manera que se puedan georreferenciar no sólo los inventarios de elementos y recursos gestionados, sino las actuaciones, avisos, incidencias y eventos de todo tipo que se consideren necesarios para disponer de una visión integral del estado de la ciudad. Si se opta por otro sistema, el adjudicatario deberá implementar los mecanismos y estrategias para mantener sincronizados ambos 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 una infraestructura de datos espaciales que garantice plenamente la continuidad de los servicios y aplicaciones actuales en el entorno Smallworld y, en línea con la orientación de la plataforma, facilite la explotación de información geográfica de forma abierta tanto a la plataforma como a los servicios actuales o futuros que puedan conectarse. Por ello, la solución propuesta debe estar alineada con las normas, estándares y especificaciones que regulan y garantizan la interoperabilidad de la información geográfica (la directiva 2007/2/CE INSPIRE, transpuesta en España por la Ley 14/2010, de 5 de julio, sobre las infraestructuras y los servicios de información geográfica en España (LISIGE), la serie de normas ISO 19100 y los estándares establecidos 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

❑ una solución que permita dotar a la Plataforma de capacidad de georreferenciación de contenidos y 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 del presente contrato y debe incluir detalle suficiente de los requerimientos y necesidades derivadas de esta implantació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 de procesos de actualización/adecuación de aplicaciones y desarrollos existentes y de posibles extracciones de datos a realizar.

El sistema GIS implementado deberá garantizar la disponibilidad de suficientes licencias de acceso para la gestión de la plataforma y para el acceso de los ciudadanos y gestores municipales a la información georreferenciada, al menos, mediante cliente ligero (web o similar). Se valorará especialmente la no existencia 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 Ayuntamiento xx Xxxxxxx 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 servicios avanzados o conjunto de sistemas que interactúan con la Plataforma y que se agrupan en cinco ejes bá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 contrato busca instalar en el Ayuntamiento una plataforma con un alto grado de evolución y desarrollo de componentes para que, tras una fase inicial de implantación y un breve periodo de adaptación a las especificaciones del Ayuntamiento, se disponga de plena capacidad operativa para iniciar la integración de servicios 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 la Plataforma y a medida que se lo vayan permitiendo los actuales contratos, la integración de servicios municipales 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 de la misma y que incluyen funcionalidades, ya existentes o a desarrollar, que permitan integrar la gestión de varios de los servicios verticales.

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

1. Concepción abierta para dar soporte a la variedad de servicios verticales posibles y debidamente documentados 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., proporcionando un tiempo de respuesta aceptable según la actividad a realizar con el apoyo del sistema GIS o un sistema de mapas.

4. Disponer de estructuras de datos y capacidades para integrar e interactuar de forma autorizada con los sistemas verticales y los sistemas de gestión municipales, incluyendo el registro manual de contenidos 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 servicios verticales. Los servicios horizontales tienen dos objetivos claros:

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

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 plataforma y 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 servicios verticales y que pudieran ampliar la oferta de servicios comunes de la Plataforma, como son la gestió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 los servicios 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, integrando información del seguimiento de los avisos/averías de los servicios verticales, información del resto de componentes de la Plataforma (quejas y sugerencias, afecciones en la vía pública, atenciones, mapas de recursos, datos del sistema GIS, …) y otros contenidos de interés (datos de meteorología, …) permitiendo gestionar 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 el registro tanto de forma manual como integrada desde distintos orígenes.

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

El sistema facilitará la toma de decisiones y la valoración y optimización de recursos facilitando el cálculo de rutas, tiempo estimado de atención, posibles afecciones en el tráfico por accidentes, cortes x xxxxxxx ocupada, 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 y gestión de recursos según prioridad y tipo de emergencia, agrupación de alertas relacionadas, aviso y atenció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 sistema debe permitir personalización para adaptarse a las particularidades de cada servicio: como los flujos de avisos, 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 consultas y gestiones de los ciudadanos. Se desea dotar al CCI de un sistema de gestión que mejore y agilice la atención que realizan, permita registrar actividad y grado de satisfacción en el servicio que presta y facilite el acceso 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 presente contrato).

❑ Inscripciones en Actividades xx Xxxxxxx 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 forma temporal en las campañas de solicitud.

❑ Gestión de datos xxx xxxx 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 la pró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 el equipamiento y capacidades indicadas en el apartado de infraestructuras y contenidos de la Plataforma para disponer 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ón en actividades deportivas, nieve, fuertes lluvias o viento que incrementen las llamadas de los ciudadanos 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 servicios horizontales, mapas y recursos, etc. y otros contenidos configurables, como por ejemplo representaciones 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 los ciudadanos.

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

• El sistema debe integrarse con el sistema telefónico de manera que recoja del mismo la información de la llamada, recopile del sistema la información disponible para ese número proporcionando al operador información adicional como número de llamadas recibidas, temáticas, última llamadas, observaciones sobre el ciudadano, enlace a trámites, etc. que agilicen 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 e información de interés para dar respuesta a las peticiones de información de los ciudadanos. El catálogo debe incluir opciones para ampliar información o iniciar actuaciones y facilidades para indicar 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 proporcionando información y facilitando el acceso a los mismos. Por ejemplo, pasar el identificador de llamada y nú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 llamadas parametrizadas 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 la lista de números y contenidos a trasladar. El sistema debe permitir automatizar la gestión y distribución de estas listas facilitando crear bloques o grupos de llamadas asociados a los agentes de 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 Municipal demandante.

7. Incluir un sistema de atención vía chat escrito según especificaciones del Sistema integral de atenció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 las atenciones realizadas y de las encuestas de satisfacción (postllamadas automatizadas del call center 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 capacidades para importar actuaciones de forma masiva y automatizada tanto de sistemas verticales como de otros 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 72 horas, solicitudes de información, diversas suscripciones y visitas a instalaciones) comunicadas por los ciudadanos desde distintos medios. Las averías son incidencias detectadas en base a un catálogo con el compromiso de resolución en 72 horas. Estas peticiones se trasladan a las unidades municipales correspondientes 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 la misma 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 tipos de peticiones y la visualización como contenido adicional en la gestión de alertas e incidencias según configuración (por ejemplo, las averias72 horas y las quejas y sugerencias).

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

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. La Plataforma debe proporcionar un registro en tiempo real de estas afecciones y gestionar su visualización sobre el mapa de la ciudad y su visualización como contenido adicional en la gestión de alertas e incidencias, 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 carga automatizada de aquellas unidades que disponen de gestión de afecciones en MS Access.

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

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 que facilite el seguimiento global de los servicios, la gestión de dispositivos y eventos, la gestión estratégica y la toma de decisiones.

Con este objetivo, la interfaz de la Plataforma debe permitir a los gestores, de forma centralizada, segura y multiusuario, explotar la capacidad de análisis y simulación de la misma e interactuar con los distintos contenidos (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 habituales en el manejo de mapas, capacidad multicapa (añadir/quitar capas), agrupar y/o filtrar por múltiples criterios temáticos como distritos, zonas de gestión, etc., por intervalos de tiempo, por gestores responsables, por dispositivo, etc., obtener resúmenes, ampliar información, incorporar datos multimedia y, si el sistema de gestió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 las especificaciones del Ayuntamiento si estuviera desarrollado, un cuadro de mando integral que permita la coordinación, control y seguimiento de las actuaciones que se establezcan bajo el contexto de ciudades inteligentes incluyendo contenidos propios de la Plataforma y evolucionando con la incorporación de nuevas funcionalidades 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 y contenidos 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 en marcha debe permitir también mejorar los propios servicios municipales. Por ello, se considera fundamental que la Plataforma disponga de capacidades de integración, entendida en ambos sentidos, con los Sistemas Municipales de Gestión permitiendo el intercambio de información e integración de funcionalidades con los sistemas municipales de gestión.

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

❑ Disponibilidad de grandes volúmenes de información de orígenes diversos, tanto e tiempo real como 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ácilmente contenidos y funcionalidades de la misma. Esta integración debe ser autorizada y sin que requiera por ello identificación adicional. Se indican algunos ejemplos a implementar de utilización de recursos de la Plataforma de forma directa desde los propios sistemas municipales.

❑ Desde un sistema de gestión municipal, habilitar una opción para mostrar cuadros de mando o informes de indicadores de gestión. Por ejemplo, un informe por distrito con contenidos sobre las quejas 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 global del gestor. Por ejemplo las averías e incidencias ocurridas en un periodo de tiempo por zonas de gestió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 ciudadanos en 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ón del ciudadano información integrada o generada en la misma que se determine publicar en determinados formatos 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 de ciudadanos: 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 de la ciudad.

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

En el marco del Plan de Innovación xx Xxxxxxx 2020, el Ayuntamiento xx Xxxxxxx, a través de la Dirección General de Transparencia, trabaja en la elaboración de un catálogo Open Data con contenidos de las unidades 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 la implementació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 xx Xxxxxxx considere de interés para su publicación.

Este Catálogo debe estar diseñado para facilitar la incorporación de los contenidos actuales y futuros a medida 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ón de 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 y adaptable a estilos y contenidos propios del Ayuntamiento xx Xxxxxxx.

Además del acceso vía portal, la solución debe incluir capacidades para exportar datos de forma flexible y compatible, al menos, con formatos de proyectos de reutilización de la información de ámbito nacional o europeo: formato Open Data compatible con xxxx://xxxxx.xxx.xx y formato compatible CKAN (estándar FI- WARE). Se valorará la existencia de capacidades de exportación basadas en una API abierta sobre estándares tipo REST, ficheros JSON o ficheros HDFS, así como al existencia de servicios web y/o portlets desarrollados 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 y descarga/suscripción de contenidos. Además, debe ir acompañada de opciones y funcionalidades relacionadas 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ón basadas en el uso de los datos publicados en el catálogo Open Data. Para ello, debo incluir además una secció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 indicadas en el PPT.

13.6 Capacidad y calidad tecnológica

Entre sus competencias, el Responsable del contrato, deberá supervisar la capacidad y calidad de los servicios prestados por la Plataforma, con especial atención a los aspectos tecnológicos de la misma, la transferencia tecnológica, la evolución de la Plataforma, la integración de servicios verticales y la implantación de infraestructura, redes y comunicaciones. Para ello contará con el apoyo de la Comisión de Desarrollo, del personal municipal que se estime oportuno en cada momento y del servicio de consultoría prestado 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 proyectos de integración de servicios verticales.

• Asesoramiento para la definición de procedimientos, mapas, indicadores, informes, memorias y 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 los recursos necesarios para la integración de servicios verticales.

• Definición y elaboración de mapas, indicadores, memorias y estadísticas, informes y cuadros de 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 de la 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 servicios verticales.

• 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 e incidencias de funcionamiento.

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

• Identificación y anticipación de posibles incidencias y desviaciones en la ejecución de proyectos 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 la Plataforma y de la prestación del servicio.

• Actividades de reporte y resolución de incidencias, mantenimiento/actualización, adaptación o mejora 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 tareas encomendadas.

• Elaboración de documentación, estudios e informes que el Ayuntamiento considere oportunos sobre la gestión y seguimiento del servicio, la operativa y procedimientos de actuación, el mantenimiento 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 los acuerdos 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 de consultoría y soporte tecnológico del adjudicatario.

Las necesidades de recursos son diferentes en función de las fases del proyecto, diferenciando como mínimo, las fases iniciales de desarrollo e implantación de la Plataforma y las fases posteriores de consultorí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ísticas y necesidades. El equipo de primera atención será estable, con plena disponibilidad y dedicación a las labores indicadas anteriormente y el equipo de segunda atención, tendrá una dedicación variable según las necesidades 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 estas actividades.

13.6.1.2 Lugar de prestación del servicio

El equipamiento, locales, suministros, licencias y, en general, las necesidades requeridas para la realización de los trabajos de consultoría y soporte tecnológico serán a cargo del adjudicatario, salvo que el Ayuntamiento, 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.

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

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

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

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

Se deberá establecer un procedimiento de gestión que permita el control de incidencias, averías, mejoras o aclaraciones de forma que se agilice y facilite la gestión del conocimiento y la relación entre el adjudicatario y el Ayuntamiento, automatizando en la propia Plataforma la obtención de informes, memorias y estadí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 de incidencias y consultas operacionales sobre la Plataforma, se establecerá un servicio 8x5 (8 horas al día, de lunes a viernes, laborales según calendario de apertura del Ayuntamiento xx Xxxxxxx) para el soporte presencial en las instalaciones municipales en horario de 8:00 a 14:00 y de 17:00 a 19:00. y un servicio 24x7 (24 horas al día todos los días del año) para el soporte telefónico, cuya implantación será progresiva y a demanda del Ayuntamiento en función de las necesidades horarias de atención del CCI y de los servicios verticales a integrar.

Para el resto de actividades de consultoría y soporte a desarrollo y evolución de la Plataforma se establecerá de forma coordinada con los responsables municipales, un servicio de soporte que debe cubrir como 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 y un equipo de trabajo formado por técnicos para cubrir los distintos “perfiles” necesarios según el ámbito y la actividad 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 de horarios 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 la atención presencial a la operativa diaria de la Plataforma y, en la instalaciones del adjudicatario, las tareas de coordinación con el Ayuntamiento y la gestión y coordinación con el resto de recursos dedicados al proyecto 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 de personas, participación y dedicación que considere idóneo para el desempeño de las actividades encomendadas y se compromete a mantener el equipo y dedicación propuesta. Cualquier alteración de las condiciones de la propuesta deberá ser comunicada y autorizada por parte del Ayuntamiento xx Xxxxxxx. Cualquier coste derivado de sustituciones o suplencias o incrementos de personal para cumplir los compromisos adquiridos para la prestación del servicio será por cuenta del adjudicatario.

Igualmente, el adjudicatario debe incluir en la oferta la descripción de la operativa del servicio y la metodologí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 y tecnologí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 horario municipal, 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 el Ayuntamiento xx Xxxxxxx y orientada a la incorporación de contenidos y capacidades de la plataforma e integración con sistemas municipales de menor entidad o no vinculados con proyectos de integración de servicios verticales.

En el apartado siguiente, se definen los acuerdos de nivel de servicio para la gestión de incidencias para la consultoría y soporte tecnológico, así como las penalizaciones pertinentes si alguno de estos acuerdos no es 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 y control de la gestión de los servicios que ofrece y facilitar la toma de decisiones sobre la gestión de la ciudad. En esa misma línea, dentro de las actividades del servicio de consultoría y soporte tecnológico a prestar por el adjudicatario, se incluyen el desarrollo, la gestión y administración de los indicadores, informes y cuadros de mando para supervisar tanto el funcionamiento global de la Plataforma, con independencia que la responsabilidad recaiga o no en el adjudicatario del servicio, como las diversas actuaciones realizadas 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 la prestación y seguimiento del servicio y permitan la recogida, registro, administración, escalado y gestión de la solución de incidencias de funcionamiento y de las consultas recibidas tanto operacionales como de evolución de la Plataforma.

❑ Elaborar y mantener un cuadro de mando del cumplimiento de los ANS, automatizando la obtenció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 prestaciones del servicio y las fases para su implantación, y se detallarán los acuerdos de nivel de servicio iniciales que será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 iniciales entrará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ún evolucione 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úmero de dispositivos gestionados y de orígenes de datos externas.

• Gestión de Aplicaciones/Funcionalidades como el número de aplicaciones/servicios comunes disponibles 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 y documentos, 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 Plataforma realizadas 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 tiempo medio, máximo y mínimo de atención x tipología.

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

• Actividades de Soporte al Responsable del contrato o a la Comisión de Desarrollo: como el tiempo 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, el número de consultas/preguntas o incidencias no registradas y el de procedimientos o documentació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 la Plataforma. Dentro de estas actuaciones, los acuerdos de nivel de servicio se centran en la gestión global de incidencias de la Plataforma, con independencia de que la solución de las mismas sea o no responsabilidad del adjudicatario.

13.7.2.1 Definiciones

❑ Incidencia: suceso o comportamiento de un equipo o funcionalidad informática que impide el normal desarrollo de las labores del usuario. Se atenderán incidencias de servicio o aplicación en el á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 y clasifican las incidencias reportadas, las tareas realizadas y la solución y conclusiones de las mismas.

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

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

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

• Tiempo respuesta: El tiempo transcurrido desde la fecha y hora de apertura hasta la fecha y hora 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 como críticos. A definir según sea ventanilla, acceso ciudadano, periodo especial, gestión en tiempo real, etc.

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

⮚ la incidencia constituye una violación de seguridad o puede provocar incumplimientos legales.

✓ Media: la incidencia afecta a un proceso que no está catalogado como crítico y el número de 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 la solución es temporal, la incidencia quedará en estado resuelto hasta la solución definitiva y cierre de la incidencia.

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

• Validación: En caso de no conformidad por parte del usuario o responsable técnico, se registrarán las oportunas “no conformidades” sobre la solución propuesta. En caso de conformidad, 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 definitiva finalizando 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 acumuladas en 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 €
Entre 94% y 80%	Hasta 200 €
Entre 79% y 70%	Hasta 350 €
Menos de 70%	Hasta 500 €

Forma de medición: Calcula en porcentaje un índice cuyo numerador es el número de incidencias que cumplen el objetivo 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
Entre 89% y 80%	Hasta 200 €
Entre 79% y 70%	Hasta 350 €
Menos de 70%	Hasta 500 €
Forma de medición: Calcula en porcentaje un índice cuyo numerador es el número de incidencias que cumplen el objetivo señalado para el indicador según la modalidad y prioridad de la incidencia y su denominador es el nº total de incidencias 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 el procedimiento, operativa, indicadores y la herramienta de gestión a utilizar. Al inicio del proyecto, la propuesta debe ser acordada y aprobada definitivamente por el Ayuntamiento.

La propuesta del adjudicatario, como mínimo, debe ajustarse a las consideraciones indicadas anteriormente sobre 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.

13.8 Incumplimientos específicos

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

13.8.1 Incumplimientos Leves

De forma general, serán consideradas como incumplimientos leves todas aquellas infracciones del PPT no tipificadas 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 o personal asignado al seguimiento técnico de la Plataforma.

❑ Retraso en la disponibilidad establecida para los indicadores, informes y cuadros de mando gestionados en la Plataforma.

❑ El trato incorrecto de los empleados de la empresa adjudicataria a los gestores y usuarios de la Plataforma, 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 no justificadas 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 no sustitución de los mismos con personal de similar cualificación.

❑ El uso descuidado o incorrecto de los recursos, instalaciones o materiales del Ayuntamiento xx Xxxxxxx.

❑ La utilización de la Plataforma y de los medios municipales para fines distintos a los que están destinados por la Administración municipal o de los que se desprenden de las funciones establecidas en el pliego de prescripciones técnicas para los servicios contratados sin la autorizació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 tres incumplimientos leves en el periodo de un año.

Y en particular:

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

❑ La incorrecta ejecución, retraso, negligencia o descuido en el cumplimiento de las funciones y tareas 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 la empresa contratada.

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

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

13.8.3 Incumplimientos muy graves

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

Y en particular:

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

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

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

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

❑ El incumplimiento de las obligaciones que en materia de protección de datos, seguridad y confidencialidad 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 por dañ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 habilidades necesarias para abordar con éxito el cambio hacia modelos de gestión de los servicios basados en la integración de recursos y el uso intensivo de tecnologías. El adjudicatario se compromete a mantener una colaboración ágil y constante con el personal municipal y realizar una correcta formación y transferencia tecnológica que garantice el conocimiento y manejo de la Plataforma por parte del personal técnico y de gestión designado por el Ayuntamiento y a mantener en todo momento formado e informado al personal de sistemas en relación a las infraestructuras y software utilizado en la Plataforma (instalación de equipos centrales, 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 el desarrollo de su atención. (La planificación de esta formación debe contemplar la implantación de las funcionalidades de gestión descrita en el PPT y el momento de la integració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 y actividades a realizar.

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

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

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

13.10 Continuidad de la Plataforma, protección de datos personales, 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 presente contrato. Por ello, es objetivo del Ayuntamiento garantizar y salvaguardar la Plataforma y prevenir situaciones que dificulten o impidan su plena utilización o desarrollo de funcionalidades, como puedan ser la falta 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/o industrial de los desarrollos de programas realizados para el presente contrato, así como de la documentació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 que el adjudicatario pueda conservarla o facilitarla a terceros sin la expresa autorización de éste, que en su caso, 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 los desarrollos de los programas realizados en el marco del presente contrato y garantizar que el código fuente cubra la funcionalidad completa de la plataforma de Gestión Integral objeto del contrato. Además, el adjudicatario se compromete a proporcionar una solución de continuidad, en caso de cese en su actividad a través del correspondiente contrato de depósito de los códigos fuentes debidamente actualizados a la versión implantada en producción durante la vigencia del contrato, asociados a los derechos de propiedad intelectual, propiedad del adjudicatario habitualmente conocido como “Escrow Agreement” o bajo cualquier otra circunstancia imputable a dicha empresa, previa audiencia de la misma, siempre y cuando se acredite la imposibilidad del correcto mantenimiento de los programas.

El adjudicatario no tendrá la obligación de entregar los códigos fuentes de los programas existentes antes de 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 las medias y disposiciones que en materia de Protección de Datos de Carácter Personal se encuentren en vigor a 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á formalizar el correspondiente contrato de acceso a datos con las instrucciones del responsable del tratamiento del fichero afectado.

13.10.3 Seguridad

El acceso y utilización por parte del adjudicatario de los recursos y sistemas informáticos municipales se ajustará a las especificaciones, procedimientos y requisitos que establezca el Ayuntamiento (medidas de seguridad, acceso y conexión, VPN, certificados, etc.), debiendo comprometerse al uso adecuado de los mismos y a tratar únicamente la información autorizada a la que tenga acceso para la prestación del servicio, a no utilizar la información para otros fines que los recogidos en el presente Pliego, así como a no extraerla, 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 de información facilitados por el Ayuntamiento y a la descarga o eliminación segura de la misma en los equipos informá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 aquellos hechos, informaciones, conocimientos, documentos y otros elementos a los que tenga acceso con motivo de la prestación del servicio, autorizando el acceso, exclusivamente, a aquellas personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a este contrato. Todas ellas serán advertidas del carácter confidencial y reservado de la información. En ningún caso deberán emplearse documentos o datos con 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, la documentación y los códigos fuentes entregados por el adjudicatario sólo beneficien a esta entidad local y no a eventuales futuros adjudicatarios para actividades ajenas a las adjudicadas por el Ayuntamiento de Logroño.

El adjudicatario deberá informar a sus empleados y colaboradores de las obligaciones y compromisos en esta materia y establecer las medidas de seguridad necesarias para protegerla, como restringir el acceso a la informació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 de confidencialidad y secreto en los términos descritos (art. 10 LOPD) en los contratos laborales que suscriban los 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 la Plataforma y el desarrollo de los servicios comunes especificados. Una vez probada y testada y, en paralelo con el desarrollo y adaptación de las funcionalidades indicadas de gestión y gobierno de la ciudad y relaciones con los ciudadanos, la Plataforma estará operativa para la evolución continua de funcionalidades y 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 forma activa en el estudio, valoración y desarrollos necesarios para la mejora o ampliación de servicios verticales o funcionalidades 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 coste adicional, las versiones y evolución de los aplicativos y funcionalidades incluidas en la oferta y desarrollados con anterioridad a la adjudicación del contrato.

Las versiones y evolución de funcionalidades de los desarrollos realizados para el Ayuntamiento de Logroño en el ámbito del presente contrato y las necesidades de ampliación de servicios en la Plataforma por incorporación de nuevos desarrollo comunes propios, de terceros o por interoperabilidad con otras plataformas serán objeto de estudio por parte del Ayuntamiento para ser incluidas como parte de la actividad de consultoría y soporte técnico del presente contrato, en función del alcance, impacto en las aplicaciones y disponibilidad 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 de servicios verticales que detalle con claridad las fases y tareas de interconexión e integración en la Plataforma 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 de servicios verticales en función de su ámbito, interés y capacidad: desde una integración mínima en la que el servicio aporta solo los datos a la Plataforma hasta una integración plena en la que el servicio comparte los datos 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” con detalle de los objetivos, alcance, necesidades, responsabilidades y plazos para la integración y especificaciones particulares. A través de las actuaciones de consultoría de este contrato, el adjudicatario se compromete 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 el Responsable del contrato a través de la Comisión de Desarrollo, adaptando su composición y funcionamiento a las necesidades de cada caso y estableciendo actuaciones y recursos destinados a garantizar 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 de integració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 equipo multidisciplinar creado para su ejecución.

4. Evolución y ampliación de mapas indicadores, informes y cuadros de mando de los servicios municipales 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 de nuevos 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 contenidos de 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.

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ón del contrato, el Ayuntamiento de Logroño podrá suscribir alguna de las modalidades ofrecidas en los té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 componentes incluidos en la oferta y la plena capacidad operativa de la Plataforma para iniciar los proyectos de integració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 la capacidad 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 de mando 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 y simulació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 su funcionamiento hasta la puesta en marcha definitiva.

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

6. La publicación automatizada en el Catálogo Open Data o, al menos, simulación de funcionalidades hasta 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 de una Estación de Tratamiento de Agua Potable (ETAP) cuyas las instalaciones están ubicadas en el municipio de Lardero. La ETAP cuenta con un moderno sistema de gestión que incluye la lectura on/line de tres contadores de caudal a la salida de la ETAP y otros 6 más repartidos en puntos estratégicos de la red de distribución, aunque solo el de Valdegastea está conectado. Dada la diferencia de altitud entre Logroño y la ETAP, el sistema dispone de unas válvulas reguladoras de la presión del agua que permiten mantener la misma 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í establecer una 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 de agua. 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 realizan semestralmente obteniendo la información desde distintas fuentes: lectores, tarjeta de lectura o lectura en la web aportada por los interesados.

El piloto debe incluir:

1. Captación de datos de sensores.

• Las lecturas on/line de los contadores de caudal indicados anteriormente y registrar datos histó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 las instalaciones de la ETAP y el sistema de comunicaciones actual permite procesos puntuales de 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 de gestió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 de zonas/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 ciclo de 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 (identificadas por 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, al menos:

⮚ 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 o sectores seleccionados y con capacidad para interactuar comparando zonas seleccionadas,

…

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

6. Integración con el Gobierno de la Ciudad: Dada la diferencia en los plazos de implantación, el piloto debe incluir, al menos, los mecanismos y capacidades de integración de los contenidos en la gestió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 los indicadores que se establezcan.

• Portal Open Data.

✓ Consumos medios de agua por habitante y año.

✓ Indicadores establecidos.

✓ 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 se accederá a contenidos desarrollados en el proyecto piloto. Esta integración en la parte del sistema municipal 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ños para 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á tener en cuenta una serie de hitos y fases generales que el Ayuntamiento determina para disponer de la Plataforma 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 las actuaciones de “inicio del proyecto” y la disponibilidad de las infraestructuras a aportar por parte del Ayuntamiento.

La planificación incluye:

❑ El despliegue operativo de elementos básicos de la Plataforma en las 5 primeras semanas (Fase 2)

❑ Un periodo adicional hasta los 4 meses (Fase 3) para los desarrollos y actuaciones que permitan verificar 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 de funcionalidades 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 e interoperabilidad 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 tipo REST, web service, etc.) y de ejecución: Motor de Reglas, Gestor de Eventos, Gestor de Dispositivos, 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 GIS Municipal.
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 incluyendo indicadores de negocio y calidad.
Despliegue del cuadro de mando Operacional de Servicio del CCI a plataforma

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ásico de inventario para averías, actuaciones ,... ) •Gestión Económica con funcionalidades para el seguimiento y control de la propia plataforma 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ón y 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 se compromete 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 de sistemas 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 y resolución de problemas.

❑ Documentación de Usuario: manual de gestión, manejo de la interfaz, interfaces de análisis y explotación de datos.

La documentación incluye las diferentes versiones que se generen y se realizará tanto en papel como en soporte electrónico editable.

ANEXO C:

SISTEMA DE QUEJAS Y SUGERENCIAS

14 ANEXO C: Sistema de Gestión de Quejas y Sugerencias ‌

El sistema de quejas y sugerencias es un componente fundamental en la atención ciudadana. El Ayuntamiento de Logroño tiene avanzado el proyecto de renovación del actual sistema de quejas cuya implantación se incorpora en la fase inicial del este proyecto para mejorar su integración con la Plataforma y la 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ño de las nuevas funcionalidades orientadas a conseguir una gestión más rápida y eficaz, adaptada a la organización municipal y a los canales de comunicación existentes en la actualidad y que facilite el cumplimiento 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 y procesos que recoja las funcionalidades descritas más adelante adaptadas al entorno tecnológico del proyecto: se diseñarán las estructuras de datos, los estilos de las pantallas, el acceso y seguridad, las opciones de configuración, la presentación y navegación, la nomenclatura a utilizar, la arquitectura del código, las plantillas tipo de las pantallas y formularios de gestión, los módulos y funcionalidades comunes al 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 de petición descritos anteriormente en cuanto al registro y tramitación o ciclo de vida y compartir el resto de funcionalidades de selección y filtrado, explotación, configuración, seguridad y perfiles, procesos y avisos e integración con otras aplicaciones.

Se aprovecharán al máximo las opciones y posibilidades de la base de datos indicada en el apartado de entorno tecnológico del presente pliego, desarrollando en procedimientos almacenados las funcionalidades de la capa de negocio.

En la elaboración de este modelo participarán personal municipal y de la empresa adjudicataria, siendo finalmente 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 de búsqueda y consulta de peticiones.

Una vez establecido este modelo se realizará el diseño técnico necesario para el desarrollo de los distintos componentes y, una vez aprobado por el Ayuntamiento de Logroño, se continuará siguientes fases del desarrollo 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 principal del aplicativo de gestión, el sistema debe gestionar diversos tipos de información (peticiones) adaptando su funcionalidad a las necesidades de cada uno y disponer de una arquitectura que facilite la incorporación de nuevos 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 distintos medios que se registran de forma manual o automática según su procedencia. En función del contenido, la Unidad de Participación Ciudadana (en adelante UPC), decreta a la correspondiente unidad 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 la web en las secciones habilitadas en cada servicio municipal. Se tramitan con el mismo procedimiento que las quejas y sugerencias.

❑ Indicación de Averías en la ciudad: de reciente implantación. Gestiona indicaciones de los ciudadanos de situaciones de peligro en la ciudad que se corresponden con un catálogo de averías cuyo compromiso de subsanación es de 72 horas, Se tramitan de forma similar a las quejas y sugerencias aunque se decretan de forma automática según el catálogo y añaden un componente de ubicación o geoposicionamiento en el mapa, cálculo de los plazos comprometidos y avisos específicos.

❑ Solicitudes de visita a la Alcaldesa: peticiones de cita con la Alcaldesa que se canalizan a la unidad correspondiente.

❑ Solicitudes de visita al Teatro Bretón: peticiones de visita al Teatro que se canalizan a la unidad correspondiente.

❑ Solicitudes de visita a Centros Municipales: peticiones de visita a otras instalaciones que se canalizan a la unidad correspondiente.

❑ Suscripción al De Buena Fuente: suscripciones a la publicación municipal semanal que se canalizan a la unidad correspondiente.

❑ Suscripción a la publicación del Teatro Bretón: suscripciones a la publicación con la programación del Teatro Bretón que se canalizan a la unidad correspondiente.

Visitas Centros

Visitas Alcaldesa

Suscripción a Publicaciones

Averías

Solicitudes de Información

Quejas y Sugerencias

Peticiones

A continuación se indican las características generales del sistema con un nivel de detalle suficiente para valorar las funcionalidades requeridas y el alcance del proyecto. En la fase inicial del mismo se identificarán con mayor precisión y detalle los requisitos del sistema sin que esto pueda suponer un cambio significativo en 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 o electró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 o desde 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 las diferentes Tablas Auxiliares que corresponda a cada caso y la existencia de información obligatoria según los distintos tipos de petición.

De forma general, salvo decretación automática, es la UPC la encargada de distribuir las peticiones entre la unidad o unidades implicadas y, una vez contestadas por éstas, la responsable de comunicar al ciudadano solicitante 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 apartado correspondiente 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 tabla auxiliar de Tipos de Información. En algunos casos se establece un subtipo de petición a determinar entre los 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 tabla auxiliar 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 y no 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.

Estado: Las peticiones se grabarán con un estado inicial que refleja la situación y permite gestionar la acciones a realizar.

Observaciones: De forma opcional, se permitirá a los gestores indicar observaciones públicas (visibles por gestores 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 el resto de tipos. En los casos de no identificación del solicitante se considera que éste renuncia al seguimiento 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 de edad (según la tabla auxiliar correspondiente) del solicitante y el sexo del solicitante. El gestor también podrá 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 se entiende 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 la localizació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 datos aportados (por ejemplo: para una prioridad: correo electrónico, teléfono, correo postal, si se dispone del correo 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 se incorpora 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. Se obtendrá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 con sistema 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. Se aplicará 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 y solicitudes de información y automática en el resto de tipos de petición, seleccionando un valor de entre los existentes 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.

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 de 72 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, contenido y obligatoriedad de la información.

En los casos en que exista una unidad asignada por defecto (averías, suscripciones, visitas, OMIC, ...) y esté completa la información requerida, además del registro se realiza, sin intervención de la UPC, la actuación de “Decretar“, asignado como destino la unidad municipal establecida, calculando los plazos de gestió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 el seguimiento de la petición: referencia identificativa PET AAAA/NNNNNN, texto indicativo y plazo estimado de resolución si se verifican los datos. Estos datos se presentan al ciudadano al finalizar el registro de la petició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 un valor 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 forma similar 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 peticiones con 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 estado activo, los datos de nombre y apellidos, año de nacimiento para el tramo de edad, sexo, contacto (dirección postal, 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.

❑ Datos de Seguimiento

Una vez realizada la grabación de la petición se devuelve un mensaje informativo para que el operador indique 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.

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 el sistema 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ón o, se tomará de forma automática en el caso de dispositivos móviles.

❑ Datos de Seguimiento

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 del servicio web (1) que da soporte al registro y seguimiento de peticiones desde la web municipal o dispositivos móviles. Será responsabilidad del Ayuntamiento de Logroño la adecuación de formularios de la web y de la

aplicación para móviles.

(1) En la fase inicial del proyecto se decidirá la construcción de un nuevo servicio web o adaptación del existente.

14.2 Tramitación

Con carácter general, una vez registradas las peticiones, el sistema implementa las siguientes funcionalidades 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 en niveles 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 dar solución a la misma.

❑ Contestar: introducir en el sistema el contenido de la respuesta a transmitir al ciudadano solicitante.

❑ Comunicar: la UPC comunica al ciudadano el resultado de la petición o posibles actuaciones relacionadas 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 significativa para el gestor.

❑ Anular: de forma motivada en los casos que proceda.

❑ Cerrar la petición cuando ya no existan más actuaciones a realizar.

❑ 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ón de 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 en su 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 se establecen 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 o incorporados 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 la tramitació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 la tramitació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 debe poder 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 en relació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 gestores correspondientes que realizan las gestiones oportunas para elaborar la respuesta que será comunicada al ciudadano.

En algunas casos puede haber un registro posterior que indica la ejecución o realización de la tarea comprometida. Esta ejecución también será comunicada al ciudadano.

14.3.1 Registro Automático

Formulario en la web municipal que utilizará el servicio web de alta de peticiones para incorporar el sistema los 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 las indicaciones existentes para cumplimentación.

❑ 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).

• Correo electrónico.

• 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 del ciudadano.

• Referencia: ( ej. PET 2013 / 25 ).

• Texto informativo.

• Posibles plazos o compromiso de realización.

14.3.2 Registro Manual

Existirá una funcionalidad similar a la descrita para el registro automático que permita registrar las quejas y sugerencias presentadas de forma telefónica o presencial o detectadas en buzones, medios de prensa o redes 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 el texto de la LOPD.

❑ En la utilización del servicio web de peticiones se incluirán los valores internos de:

• 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 a una cuenta configurada.

14.3.3 Tramitación

Una vez registradas en el sistema, el tratamiento de las quejas y sugerencias incluye las actuaciones siguientes:

❑ 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 si procede, ...

❑ Agregar: asociar la gestión de una queja a otra ya registrada por tratarse de lo mismo con el objeto de 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 su contestación.

❑ Volver a decretar: En el caso de unidades con dos niveles de estructura como Logroño Deporte para 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 la misma.

❑ 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 por la 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ón necesaria 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 y zona 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 de correos 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 de la petición:

❑ Tipo de Petición si lo considera.

❑ Categoría (*):

• Seleccionar tema/materia/objeto del catálogo de peticiones mostrando las indicaciones existentes 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 de sujeto 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 ampliar información se incluiría como observaciones y el gestor puede incorporar nuevos anexos si procede.

Al aceptar la petición se validan los datos introducidos y se actualizará la información de la petición en el sistema:

❑ Se registrará la información de la misma asociada a la petición.

❑ Si se ha catalogado la materia, se produce y registra un comunicado de aviso al Concejal de la Materia correspondiente.

❑ Si se ha catalogado el distrito, se produce y registra un comunicado de aviso al Concejal del Distrito correspondiente.

14.3.3.2 Agregar

En ocasiones, desde formularios de la web, se reciben quejas y sugerencias repetidas porque se solicitan varias 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 contenido siendo 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” se reflejen en las “vinculadas” y la única particularidad se establecerá en el momento de comunicar al ciudadano 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 no estén agregadas ni en estado final y mostrando las que tengan quejas agregadas ordenadas por fecha 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 registra un 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 la queja 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 varias unidades 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 destinataria identifique su ámbito de actuación en la petición.

(*) destinos activos, autorizados, por tipo de petición.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la 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 al ciudadano solicitante.

❑ Se calcula y registra el plazo de Contestación.

Esta actuación permite a los gestores autorizados trasladar las peticiones recibidas al destino indicado según el catálogo de averías. Se establecerá una unidad municipal responsable y según los casos, un responsable 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 de dos niveles de gestión de las peticiones de modo que dentro de su ámbito de actuación de unidades, un gestor 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 tenga asociados destinos de nivel 2.

Se selecciona la actuación de decreto inicial y mostrará una pantalla para:

❑ Seleccionar el destino mostrando los posibles (*) de la tabla auxiliar de destinos. (*) activos, autorizados, por tipo de petición y nivel.

❑ Introducir las indicaciones oportunas, mostrando inicialmente el texto con instrucciones específicas de la actuación decreto inicial.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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 error de 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. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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 correo electró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 destinatarios habituales (técnicos o empresas).

Se mostrará una pantalla que permita:

❑ 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 carga previamente la información básica de la avería.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

• 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 a las 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 general para facilitar la explotación posterior.

Se validará que la petición esté en estado “decretada” o “contestada” (para poder cambiar la misma). Se mostrará una pantalla que permita:

❑ 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 la contestación, existirá la opción de guardar los datos sin confirmar la actuación, es decir, sin cambiar su estado de tramitación.

Al confirmar la actuación, el sistema determina en función de la configuración por distrito y del número de decretos 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 grabado su contestación).

❑ Se registrará la información de la misma asociada a la petició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 hay un flujo de dos personas para elaborar la contestación). Desde la primera contestación, la comunicación al ciudadano 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 24 horas y se emite un aviso o alerta a la siguiente persona en el flujo que recibirá en su cuenta de correo el

mensaje con la información básica de la queja o sugerencia y dos enlaces para la ejecución de dos opciones 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 de aprobación calculado.

• En la segunda opción, además se realizará la actuación de Comunicar registrando el gestor correspondiente.

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 al interesado 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ías que 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 en el sistema de modo que por ejemplo, en el caso de comunicaciones telefónicas, debe preverse la posibilidad de 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 unidades implicadas y que se haya superado el plazo de aprobación si existiera - O sea una “agregada” que requiere comunicació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 contenido comunicado: la contestación de las unidades implicadas o la ejecución de alguna acción comprometida y que la segunda no afecta a los plazos de cierre.

Se mostrará una pantalla que permita:

❑ 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. Al confirmar la actuación:

• 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 caso contrario 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 registrará la información de la misma asociada a la petición.

• 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.

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 UPC proceda a comunicárselo al ciudadano.

Se validará que la petición esté en estado “contestada” o “comunicada”. Se mostrará una pantalla que permita:

❑ Introducir texto indicativo.

❑ Incorporar posibles observaciones internas del gestor.

❑ Adjuntar archivos como fotografías o informes. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

14.3.3.11 Comunicar Ejecuciones

Desde la UPC, de forma similar a la comunicación de contestaciones, se trasladan al ciudadano las indicaciones sobre la realización de la actuación comprometida.

Se validará que la petición tenga registrada la ejecución sin comunicar. Se mostrará una pantalla que permita:

❑ Introducir texto en el que se carga el texto de la ejecución.

❑ Incorporar posibles observaciones internas del gestor. Al confirmar la actuación:

❑ 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 caso contrario 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 registrará la información de la misma asociada a la petición.

• Se marcan como comunicadas las ejecuciones enviadas.

❑ Si la actuación es INTENTO.

• Se registrará la información a título informativo.

14.3.3.12 Anular

Esta actuación permite a los gestores autorizados anular de forma motivada las peticiones: error en la gestión, error en los datos, repetición, ...

Se validará que la petición no esté en un estado de tramitación final. Se mostrará una pantalla que permita:

❑ seleccionar el motivo de la anulación (* obligatorio).

❑ introducir texto de observaciones del gestor. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ Se produce y registra un cambio de estado en la petición a “anulada”.

❑ Se produce y registra un comunicado de aviso al ciudadano solicitante (s/configuración).

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 las mismas una vez realizadas las actuaciones establecidas para su tramitación. Esta actuación tiene la finalidad de establecer un punto común a todas las peticiones que identifique la finalización de actividades en la tramitación de peticiones.

El sistema permitirá a los gestores autorizados seleccionar las peticiones que cumplan las condiciones y proceder, 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. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petició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 de gestiones realizadas de una petición.

Se validará que la petición no esté en un estado de tramitación final. Se mostrará una pantalla que permita:

❑ Introducir texto breve e indicativo del comentario (*).

❑ Introducir texto de observaciones del gestor. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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 o presencial) de las comunicaciones realizadas por los ciudadanos en relación con averías, incidencias y desperfectos 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 gestores correspondientes que realizan las verificaciones oportunas y trasladan la misma según el caso a los té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 y particularidades en que se establece un compromiso de 72 horas para los que se cuenta con las unidades municipales y convenios con empresas externas. Algunas averías no son competencia del Ayuntamiento por la tipología o por los requisitos necesarios. En estos casos, el compromiso de 72 horas se limita a la contestación.

Cuando la resolución sea competencia del Ayuntamiento, la unidad responsable valorará la actuación a realizar y puede optar por contestar al ciudadano o esperar a resolución de la avería para registrar la actuación de ejecutar que le será comunicada al ciudadano. Cualquiera de las dos acciones da por finalizado el compromiso de 72 h.

En la contestación de la unidad se determina si la petición cumple los criterios establecidos y el plazo comprometido 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 ser comunicada 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 se tengan en cuenta los festivos y que en las peticiones fuera de horario el plazo se comience en la mañana del primer día hábil posible. De forma similar a lo que sucede en el actualidad fuera del horario municipal y de forma telefónica, se establece, de forma adicional a la decretación de averías, la opción de “aviso de urgencias” cuyo destinatario será la Policía Local de guardia que determinarán si es necesario realizar alguna intervención.

Las comunicaciones de averías deben contener la información necesaria para su resolución, quedando en suspenso 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ía con otros sistemas como por ejemplo: la Orden de Trabajo generada.

14.4.1 Registro Automático

Formulario en la web municipal que utilizará el servicio web de alta de peticiones para incorporar al sistema los 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 indicaciones existentes 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.

• Correo electrónico.

• 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.

En la utilización del servicio web de peticiones se incluirán los valores internos de:

❑ 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 del ciudadano

• Referencia: ( ej. PET 2013 / 25 ).

• Texto informativo.

• Posibles plazos o compromiso de realización.

14.4.2 Registro Manual

Existirá una funcionalidad similar a la descrita para el registro automático que permita registrar las averías de forma telefónica o presencial 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 el texto de la LOPD.

❑ En la utilización del servicio web de peticiones se incluirán los valores internos de:

• 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 a realizar. (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

Se validará que la petición esté en estado “registrada” o “decretada”. Se mostrará una pantalla que permita:

❑ Seleccionar el destino mostrando los posibles (*) de la tabla auxiliar de destinos.

❑ Introducir texto con instrucciones o indicaciones específicas para que la unidad destinataria identifique su ámbito de actuación en la petición

(*) destinos activos, autorizados, por tipo de petición.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la 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 del Destino correspondiente y al responsable 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 de 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. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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).

❑ Se produce y registra un comunicado de aviso al ciudadano solicitante (s/configuración).

14.4.4.2 Trasladar

En función de las particularidades de las averías, el sistema permitirá trasladar las mismas a los responsables 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 destinatarios habituales (técnicos o empresas).

Se mostrará una pantalla que permita:

❑ Introducir o seleccionar un destinatario de la información.

❑ Introducir un texto con instrucciones o indicaciones específicas para el responsable de solucionar la avería, en el que se carga previamente la información básica de la avería.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

• 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ón oportuna según la valoración realizada. Las posibles necesidades de remitir la información a terceros se realizan con la actuación anterior de trasladar.

Se validará que la petición esté en estado “decretada”.

Se mostrará una pantalla que permita:

❑ Introducir texto con la contestación por parte de la unidad.

❑ Incorporar posibles observaciones del gestor.

❑ Adjuntar archivos.

Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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). Se mostrará una pantalla que permita:

❑ introducir el texto a comunicar, en el que se carga previamente la contestación de la unidad o el texto de ejecución, indicando la inclusión de adjuntos si los hubiera.

❑ Incorporar posibles observaciones internas del gestor. Al confirmar la actuación:

❑ 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 caso contrario 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 registrará la información de la misma asociada a la petición.

• 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.

❑ Si la actuación es INTENTO.

• Se registrará la información a título informativo.

14.4.4.5 Ejecutar

Cuando el responsable de solucionar la avería comunica a la unidad que ésta está solucionada, se registra en 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”. Se mostrará una pantalla que permita:

❑ introducir texto indicativo.

❑ Incorporar posibles observaciones internas del gestor.

❑ Adjuntar archivos como fotografías o informes. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

14.4.4.6 Comunicar Ejecuciones

Desde la UPC, de forma similar a la comunicación de contestaciones, se trasladan al ciudadano las indicaciones sobre la solución a la avería, etc.

Se validará que la petición tenga registrada la ejecución sin comunicar. Se mostrará una pantalla que permita:

❑ Introducir texto en el que se carga el texto de la ejecución.

❑ Incorporar posibles observaciones internas del gestor. Al confirmar la actuación:

❑ 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 caso contrario 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 registrará la información de la misma asociada a la petición.

• Se marcan como comunicadas las ejecuciones enviadas.

❑ Si la actuación es INTENTO.

• Se registrará la información a título informativo.

14.4.4.7 Anular

Esta actuación permite a los gestores autorizados anular de forma motivada las peticiones: error en la gestión, error en los datos, repetición, ...

Se validará que la petición no esté en un estado de tramitación final. Se mostrará una pantalla que permita:

❑ Seleccionar el motivo de la anulación (* obligatorio).

❑ Introducir texto de observaciones del gestor. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ Se produce y registra un cambio de estado en la petición a “anulada”.

❑ Se produce y registra un comunicado de aviso al ciudadano solicitante (s/configuración).

14.4.4.8 Cerrar

El sistema permitirá a los gestores autorizados seleccionar las peticiones que cumplan las condiciones y proceder, 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. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ Se produce y registra un cambio de estado en la petición a “cerrada”.

14.4.4.9 Comentar

Está actuación permite a los gestores incluir una acción o actividad significativa en la tramitación de gestiones realizadas de una petición.

Se validará que la petición no esté en un estado de tramitación final. Se mostrará una pantalla que permita:

❑ Introducir texto breve e indicativo del comentario (*).

❑ Introducir texto de observaciones del gestor. Al confirmar la actuación:

❑ Se registrará la información de la misma asociada a la petición.

❑ 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 peticiones para consultar o realizar las gestiones oportunas según su perfil. En función de los perfiles varían las necesidades de acceso inicial por lo que debe contemplarse que cada gestor pueda identificar el filtro inicial de 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, …), es decir, por texto libre. Del mismo modo, se podrá realizar la búsqueda seleccionando entre tipos de petición existentes. 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, de comunicar, etc.).

Se mostrará una opción de búsqueda rápida o habitual que presente los primeros resultados acompañados de 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 de calidad y las necesidades planteadas por los Gestores de Unidades y los responsables de Distritos. Para dar respuesta a las necesidades que se indican en el apartado de explotación, se desarrollarán las opciones de imprimir o exportar las peticiones filtradas. Del mismo modo, este filtrado puede utilizarse para realizar acciones 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 gestores responsables de la tramitación de las peticiones. Además de las opciones de búsqueda, en la pantalla de acceso se tendrá en cuenta la presentación de datos agregados que aporten al gestor una visión global del estado de las peticiones autorizadas y accesos rápidos a las “bandejas” de peticiones según su estado o a las ú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:

• 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 el sistema identificarse y acceder a las peticiones autorizadas según la unidad administrativa, tema/materia o distrito.

El sistema dispondrá de:

❑ “Visualización inicial”: orientada a facilitar el acceso de gestores de unidades y concejales implicados y que incluya los datos básicos, el resumen de la tramitación y las posibles acciones a realizar y al seguimiento de ciudadanos solicitantes.

❑ “Visualización detallada”: orientada a administradores y gestores de UPC que permita el acceso en detalle 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.

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 la petició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 registros anulados.

❑ Anexos: imágenes, archivos, ... anexos asociados a la petición con opción acceder al detalle y visualización de los mismos.

❑ Comunicaciones asociadas a la petición: correos de aviso a gestores o concejales, correos a té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, el sistema permitirá que el gestor determine los parámetros para delimitar el ámbito de las peticiones sobre las que realizar proceso de recuento. Los resultados obtenidos se podrán exportar para su inclusión en informes o memorias.

Se establecerá un sistema lo más generalista posible que permita cubrir estas necesidades e incorporar con facilidad 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.

❑ 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 datos referidos 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 de selección y un número de encuestas deseadas que el sistema seleccionará de forma aleatoria entre las peticiones que cumplan las condiciones establecidas. Una vez seleccionadas, enviará un correo electrónico a los solicitantes que dispongan del mismo con un enlace para la cumplimentación de las preguntas y permitirá, 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 datos significativos 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 detectados inicialmente e incorporar con facilidad necesidades futuras.

Modelo	Destinatario
Modelo	Gestor Unidad	D.G. Unidad	Concejal Unidad	Concejal Materia	Concejal Distrito
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

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

Ha sido decretada una nueva petición desde el sistema de Quejas y Sugerencias del Ayuntamiento de Logroño hacia su 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 recibir

mensajes.

Cuando en una petición se actualice la materia o el distrito, se emitirá un aviso al Concejal asignado al

Distrito / 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 > 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 recibir mensajes.

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 Unidad y a los Concejales de Distrito y Materia (cuentas de correo asociadas) de forma similar al del ejemplo expuesto.

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 > 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 recibir mensajes.

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, Distrito y 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 > 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 recibir mensajes.

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 > a resolver el <fecha hora compromiso de resolución>

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 > 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 recibir mensajes.

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 la necesidad de una posible intervención al Policía de Guardia de forma similar al del ejemplo expuesto.

Ejemplo

Ha sido recibida una nueva petición en el sistema de Quejas y Sugerencias del Ayuntamiento de Logroño, que se le remite 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> 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 recibir

mensajes.

14.7.4 Informes y Memoria

En este apartado se indican las necesidades de salida impresa a incluir en el sistema y se establecen las siguientes 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 9 SP1 para la generación y gestión de cualquier informe de la aplicación, aprovechando al máximo las opciones 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 gestor determine 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 peticiones seleccionadas con indicación de los criterios y peticiones seleccionadas y otro que contenga mayor detalle de 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 al módulo de explotación e indicadores. Dado que el acceso a las peticiones se limita a las autorizadas, los gestores disponen de medios para obtener los distintos indicadores cuyo resultado podrán exportar para elaborar 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 una referencia (PET AAAA/NNNNNN) del registro de la petición realizada. Es responsabilidad del Ayuntamiento de 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 que de soporte a las necesidades de información de este seguimiento.

Al registrar determinados tipos de petición, si existe dirección de correo electrónico, se remitirá un acuse de recibo 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 de peticiones.

❑ Tipos de peticiones: incluye el mantenimiento y configuración de los distintos tipos de peticiones manejado 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 la informació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 forma implícita el modo de grabación.

• Web, 010, ...

❑ Estados: incluye el mantenimiento y configuración de estados en los que se puede encontrar una petició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ón de las peticiones. Se incluye la gestión de:

• Palabras clave.

• Tema/Subtema/Materias/Objeto.

• 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 organizativa de 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ño Deporte.

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 y plazos 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 el caso 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ón de peticiones.

❑ Anexos:

El sistema dispondrá de capacidad de configuración de los tipos de archivos anexo, su tamaño y su asociació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 los distintos 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 asociar al proceso de selección de encuestados.

El registro de las encuestas será efectuado por los propios ciudadanos o por el 010 y existirá una explotación básica del resultado de las mismas.

14.9.5 Acceso y seguridad

En este apartado se incluye de forma general la información relativa al acceso, seguridad y auditoría del sistema.

14.9.5.1 Perfiles

Se identifican los siguientes perfiles para la configuración de autorizaciones a los distintos intervinientes para 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ón asociados 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ón asociados 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 su unidad.

NO PUEDE

SI PUEDE

• Registrar

• Actualizar la petición

• Aprobar

• Comunicar

• Agregar, Anular, Cerrar

• Encuestar

• Decretar si nivel 2 (caso de LDP)

• Contestar

• Rechazar

• Ejecutar

• Concejal Unidad Consulta sobre tipos de petición autorizadas y decretadas a su unidad. No tendrá 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 su distrito

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 propias Preferencias.

14.9.5.2 Autenticación

❑ Externa

Referida a los ciudadanos que formulen sus peticiones cumpliendo los requisitos establecidos de identificación/contacto para el seguimiento de peticiones recibirán la información necesaria para poder acceder al seguimiento de cada petición.

Para ello, se habilitará en la web municipal un formulario acceso por identificador/referencia que presente la informació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 para permitir 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 se corresponden con el ciudadano.

El sistema a desarrollar debe contemplar la identificación contra un directorio de LDAP (Active Directory 2003 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 la consulta de actuaciones, permitirán el seguimiento de qué, quién y cuándo se ha realizado una acción en la tramitació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 sistema seleccionará de forma aleatoria entre las peticiones que cumplan las condiciones establecidas. Una vez

seleccionadas, enviará un correo electrónico a los solicitantes que dispongan del mismo con un enlace para la cumplimentación de las preguntas y permitirá, de forma manual que el gestor registre las respuestas en el caso 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 distintos procesos 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ón vencido + 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 de contestació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) en función del compromiso existente.

Modelo: Mod.Aviso 6

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 del servicio web necesarios para dar soporte al registro y seguimiento de peticiones desde la web municipal o el aplicativo para móviles.

14.11.2 Sujetos

El Ayuntamiento de Logroño será responsable de proporcionar un servicio web para recuperar los datos de un sujeto conocido su nif. En todo caso, el sistema deberá permitir al gestor la introducción manual de esta información.

14.11.3 Territorio

El Ayuntamiento de Logroño será responsable de proporcionar un servicio web para recuperar el callejero municipal. El GIS proporciona la funcionalidad para obtener las coordenadas del mapa conocidas la calle/número. El adjudicatario debe implementar una funcionalidad de la Plataforma o del GIS que permite obtener el distrito y zona de gestión al que pertenecen las coordenadas de la petición. En todo caso, el sistema 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 a realizar en la “comunicación” entre los intervinientes en el sistema (ciudadanos, gestores, …), el nuevo sistema debe contemplar en su arquitectura, procesos y configuración, la posibilidad de integración futura con 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á estar preparado de forma que el proceso de registro de peticiones pueda enlazarse individualmente desde otros aplicativos y al finalizar la grabación pueda enlazarse con otros aplicativos, recibiendo y enviado los datos e identificación necesaria en cada caso para que la operativa de atender una llamada que requiera iniciar el proceso de registro de una petición, enlace con el aplicativo y, una vez atendida, conectar con la “encuesta de 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 el sistema de peticiones envía información de la petición a la “encuesta de atención” del Servicio de Atención 010.

Además, el sistema dispondrá de una búsqueda por teléfono de contacto, nombre, contenido y fechas que facilite la localización de peticiones en una atención telefónica o presencial o para ser utilizadas desde aplicaciones externas.

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 una actuació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 de forma 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 la encuesta 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 de facilidades 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 las peticiones registradas y su estado, pudiendo seleccionar por tipo de petición, temática, estados y fechas. La integración debe ser capaz de permitir acceso autorizado desde la Plataforma al detalle de 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 peticiones registradas 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 incluye la recepción y gestión básica de las peticiones y que debe estar operativa en 4 meses desde el inicio del contrato y otra que incluye la totalidad del sistema que deberá completarse a los 8 meses desde el inicio del contrato.

14.13.2 Entorno tecnológico

El desarrollo del sistema de quejas y sugerencias debe seguir las pautas tecnológicas indicadas para la Plataforma Smart Logroño, por tanto, debe estar basado en tecnología Java (JEE) con una arquitectura abierta y multicapa basada en estándares, que mantienen la independencia de la interfaz gráfica respecto al diseño de los procesos de negocio y éstos a su vez con la base de datos. Estos estándares serán, en la medida de lo posible, elementos del mercado de libre distribución que estén suficientemente probados y consolidados para su implementación en un entorno de estas características.

La oferta debe indicar los componentes a utilizar y su nivel de licenciamiento, no suponiendo en ningún caso un 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 basado en el patrón Modelo-Vista-Controlador (MVC) y debe mantener características compatibles al resto de los sistemas municipales gestionados por el servicio de Nuevas Tecnologías, por lo que se incluyen algunas particularidades 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, o bien, 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 de Oracle.

• 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 datos manejado y debe incluir en la oferta una garantía mínima de 12 meses a contar desde la fecha de recepción del producto. Dicha garantía incluye la subsanación de errores o fallos ocultos que se pongan de manifiesto con 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 valorar la solución propuesta. Este modelo no será vinculante dado que será objeto de análisis durante la fase de desarrollo.

Además, el adjudicatario se compromete a realizar la transferencia de conocimiento al personal municipal para que pueda asumir de manera autónoma la administración, gestión y mantenimiento del sistema. Para ello, la oferta debe incluir un plan de formación para gestores según los perfiles identificados y un plan de formación y transferencia de conocimiento específicos para el personal de sistemas y desarrollo del Ayuntamiento.

Document Metadata

Table of Contents

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

Document Metadata