contratacion de servicios de soporte a suarios y … · 3.10.9 fichas de datos de los usuarios ......

Basauri. Diciembre – 2.015

ww

w.b

asa

uri

.ne

t

CONTRATACION DE SERVICIOS DE SOPORTE A USUARIOS Y SISTEMAS

Versión: 2.0

Creada por : viernes, 04 de diciembre de 2015

Revisada por :

INDICE

1 ANTECEDENTES .................................................................................................. 4

2 OBJETO ................................................................................................................... 6

2.1 SERVICIOS DE CENTRO DE ATENCIÓN A USUARIOS (CAU) .............................. 6 2.2 MANTENIMIENTO PREVENTIVO Y CORRECTIVO ............................................... 6

3 DESCRIPCION DE LOS SERVICIOS ................................................................ 8

3.1 ANTECEDENTES Y OBJETIVOS............................................................................ 8 3.2 PROCEDIMIENTO BÁSICO. .................................................................................. 8 3.3 OTRAS CONDICIONES. ...................................................................................... 11 3.4 DEFINICIÓN DEL ACTUAL SERVICIO DE CAU PRIMER NIVEL ........................... 11

3.4.1 Entorno tecnológico. .................................................................................. 11 3.4.2 Tipo de actividad. ....................................................................................... 12 3.4.3 Cobertura del servicio. ............................................................................... 12

3.5 UBICACIÓN Y EQUIPAMIENTO ESPECÍFICO. ..................................................... 12 3.6 USUARIOS ........................................................................................................ 13 3.7 TIPOS DE TICKETS GENERADOS POR EL CENTRO DE ATENCIÓN A USUARIOS . 13 3.8 CATEGORÍAS UTILIZADAS DE INCIDENTES Y SOLICITUDES ............................. 14 3.9 DIAGRAMA DE FLUJO DE LA GESTIÓN DE INCIDENTES Y SOLICITUDES .......... 15 3.10 DATOS DEL SISTEMA ....................................................................................... 16

3.10.1 Niveles de Resolución ............................................................................... 16 3.10.2 Urgencias, impactos y prioridades definidas ........................................... 16 3.10.3 Soluciones (BD de conocimiento) ............................................................ 17 3.10.4 Roles ......................................................................................................... 18 3.10.5 Notificaciones ........................................................................................... 18 3.10.6 Informes .................................................................................................... 19 3.10.7 Control remoto ......................................................................................... 20 3.10.8 Inventario de equipos de usuario ............................................................. 20 3.10.9 Fichas de datos de los usuarios corporativos .......................................... 21 3.10.10 Acceso a documentación del departamento TIC .................................... 21

4 METODOLOGIA Y ORGANIZACIÓN ............................................................ 22

4.1 DIRECCIÓN DEL CONTRATO ............................................................................ 22 4.2 OBLIGACIONES DEL ADJUDICATARIO ............................................................. 22 4.3 METODOLOGÍA Y DOCUMENTACIÓN ............................................................... 23

5 EQUIPO DE TRABAJO Y DEDICACIÓN ....................................................... 24

6 CONTROL Y SEGUIMIENTO ........................................................................... 25

7 TERMINOS Y CONDICIONES DEL PROCEDIMIENTO ............................ 26

7.1 GENERALES: ................................................................................................ 26 7.2 CONDICIONES PARTICULARES ............................................................... 26

7.2.1 Responsabilidades de dirección y gestión del servicio. ............................. 26 7.2.2 Control económico y facturación. .............................................................. 26 7.2.3 Propiedad intelectual, Seguridad y Confidencialidad. .............................. 26 7.2.4 Propiedad intelectual de los trabajos. ........................................................ 26 7.2.5 Seguridad y confidencialidad de la información. ....................................... 26

Basauriko Udala / Ayuntamiento de Basauri HHIB Saila/Departamento de TIC´S y OIAC

CSI01_PliegoCondicionesTecnicasSoporteCAU_v2.docx 04/12/2015 Página 3 de 26

CONFIDENCIALIDAD Restricciones de uso y revelación de los datos contenidos en este documento. La información y datos contenidos en este documento elaborado por

Ayuntamiento de Basauri para este proyecto es confidencial y privilegiada. Esta información se facilita a terceros bajo las más estrictas obligaciones de confidencialidad, en el bien entendido de que éste no revelará la misma a ningún tercero ni hará uso de ella, sin permiso expreso del Ayuntamiento, para propósito distinto del de generación.

Se prohíbe la reproducción total o parcial para otros fines que los anteriormente

indicados sin la autorización expresa de Ayuntamiento de Basauri. La información a tratar puede contener datos personales sometidos a las

disposiciones de la Ley Orgánica 1/1982, de 5 de mayo, de Protección Civil del Derecho al Honor, a la Intimidad Personal y Familiar y a la propia Imagen, de la Ley 12/1989, de 9 de mayo, de la Función Estadística Pública, del real decreto 994/1999 de 11 de junio de reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal, de la Ley Orgánica 15/1999 de 13 de Diciembre de protección de Datos de Carácter Personal, normas que el adjudicatario conoce y se obliga a respetar, en su propio nombre y en el de todo el personal que contrate o dependa de él para la ejecución de los trabajos objeto del contrato, suscribiéndose al efecto, y por lo que respecta a dicho personal, las oportunas cláusulas de confidencialidad en los correspondientes contratos.

El adjudicatario se compromete a no dar a la información y datos proporcionados

por la Administración, cualquier uso no previsto en el presente Pliego.



1 ANTECEDENTES El Centro de Atención a Usuarios (CAU) del Ayuntamiento de Basauri constituye la

interfaz entre la comunidad de usuarios y los diferentes servicios prestados por el departamento de TI

Los principios bajo los que opera el servicio de CAU son:

1. Mejora continua del servicio proporcionado. Este objetivo conlleva la necesidad de disponer de información sobre los niveles de servicio que se están ofreciendo, monitorizar el proceso y proponer acciones de mejora.

2. Proveer un único punto de contacto para el usuario final que realice las funciones de interfaz con otras áreas del departamento de TI (áreas funcionales, operación de los sistemas, etc.) y con los proveedores externos. En su implantación práctica, el servicio de CAU estará constituido por diferentes niveles de atención, pero cada usuario deberá tener un único punto de interlocución claramente identificado.

3. Capturar información sobre la comunidad de usuarios a fin de detectar necesidades que deberían ser cubiertas (formación, infraestructura, deficiencias en las aplicaciones, etc.).

4. Evolucionar desde un soporte reactivo a un soporte proactivo. El CAU deberá tener la capacidad de anticiparse e informar a los usuarios de los problemas detectados que puedan afectar a su trabajo.

5. Actuar como fuente de conocimientos del Ayuntamiento en materia de incidencias de TI, gracias a la documentación de soluciones a los problemas más frecuentes.

6. Satisfacer a los usuarios y cubrir sus expectativas. La clave para el éxito del CAU será su habilidad para cubrir e incluso superar las expectativas de los usuarios con respecto al conjunto de servicios ofrecidos por la Unidad.

Actualmente el Ayuntamiento de Basauri dispone de un Centro de Atención al

Usuario para la atención telefónica y resolución/gestión de incidencias y de peticiones de servicios que, bajo los principios indicados, ha supuesto la normalización y el avance en la calidad del servicio ofrecido desde el departamento de TI hacia los usuarios del ayuntamiento y sus organismos autónomos dependientes.

El servicio se encuentra implantado desde el año 2006. La implantación de este sistema ha supuesto para el departamento de TI, la

tipificación y estructuración de las incidencias, la disposición de procedimientos y protocolos de común actuación de atención y soporte y la definición de flujos de trabajo que han provocado la mejora en la organización municipal y la de sus organismos y empresas dependientes.

Por otro lado es competencia de la subarea de modernización es diseñar,

implementar y mantener la infraestructura informática y de telecomunicaciones requerida para el desarrollo de la actividad municipal.

La infraestructura tecnológica del ayuntamiento se organiza de la siguiente manera

1. CPD:



El ayuntamiento posee un Centro de Proceso de Datos situado en la Casa Consistorial. El CPD se compone de servidores físicos y virtuales (VMWARE) en los que se almacenan y ejecutan las diferentes aplicaciones que sirven de herramientas en la prestación de los servicios municipales.

Dentro del CPD existen configuraciones heterogéneas con diferentes sistemas operativos (Windows Server, Linux, etc.), servidores de aplicaciones (Tomcat, Etc.) y de base de datos (Oracle, SQL-Server, My SQL, Etc.)

Existen diferentes clases de servidores: De ficheros, Bases de Datos, Servidores Web (Gestores de contenido: Joomla, Druppal, Wordpress), servidores de aplicaciones, servidores de antivirus, etc.

2. Redes de Comunicaciones, Datos, Voz y Video El ayuntamiento tiene conectados todos los edificios municipales a través de redes

virtuales. Por otro lado presta servicios de correo, web e interoperabilidad a través de redes públicas y privadas.

También dispone de una red CCTV, que agrupa de forma centralizada las cámaras de video vigilancia y gestión de las rampas mecánicas.

3. Redes de Locales En cada uno de los edificios municipales se dispone de redes locales conectadas a la

red principal que integran tanto servicios de voz como de datos. 4. Sistemas de Backup y NAS

El ayuntamiento cuenta con sistemas de almacenamiento (CELERRA) y sistemas de backup centralizados

5. Sistemas de Seguridad Perimetral. Existen dispositivos hardware y software que forman parte del sistema de

seguridad perimetral del ayuntamiento. Los firewall son de Palo Alto, el gestor de navegación es Iron-Port, el sistema

antivirus Trend Micro. 6. Red de Voz.

El ayuntamiento cuenta con centrales telefónicas en todos sus edificios unidas por tecnología IP.

La central en casa consistorial es una BP-250 y en el resto de edificios son BP50.



2 OBJETO

El objeto de este pliego es establecer las condiciones técnicas para la prestación de servicios de CAU y de mantenimiento preventivo y correctivo de los sistemas de información y comunicaciones del Ayuntamiento de Basauri y de sus organismos autónomos:

1. La contratación del servicio de primer nivel de CAU de forma eficaz y con unas cotas altas de calidad de atención a los usuarios, atendiendo a las mejores prácticas conocidas como ITIL.

2. El mantenimiento preventivo y correctivo de los diferentes subsistemas que componen la infraestructura municipal.

2.1 Servicios de Centro de Atención a Usuarios (CAU) El suministro de los servicios de CAU supone de manera general para el

adjudicatario:

1. La atención telefónica al usuario bilingüe (euskera y castellano) y el registro de la incidencia o peticiones de servicios en la aplicación de helpdesk implementada al efecto (FCT_CAU) desarrollada por el departamento de desarrollo del Ayuntamiento

2. La resolución de las incidencias de los usuarios de manera telefónica o bien por medios telemáticos de asistencia remota a través de la red de datos y todo ello por un tiempo limitado de resolución a establecer.

3. La apertura y cierre de las incidencias y peticiones de servicio. 4. Un nivel de supervisión y control de los técnicos resolutores del primer

nivel de CAU y de las incidencias registradas. 5. La utilización de la herramienta de helpdesk dispuesta por el Ayuntamiento

sobre la red de datos corporativa (acceso a la intranet). El ámbito de actuación del CAU será:

1. Todos los usuarios del Ayuntamiento y Organismos Autónomos que acceden a la red de datos y los servicios y aplicativos dispuestos sobre la misma

2. Personal invitado, personal en tránsito y personal subcontratado, pudiendo acceder desde la intranet o desde internet.

3. Todos los equipos propiedad del ayuntamiento que se encuentren en la intranet o internet. Masivamente el ámbito de actuación será sobre equipos dispuestos en la intranet y puntualmente sobre equipos móviles en acceso desde internet.

2.2 Mantenimiento Preventivo y Correctivo Los trabajos de mantenimiento y configuración del sistema informático municipal

en los siguientes ámbitos:



1. Administración de herramientas de seguridad. o Firewall. o Software antivirus.

2. Soporte a Microinformática. o Hardware. Servidores, PCs, periféricos. o Redes locales. o Sistemas operativos de red y sobremesa. o Ofimática, entornos de desarrollo, etc.

3. Administración de red. 4. Administración de base de datos. 5. Administración de buzones de correo corporativo. 6. Administración de seguridad de aplicaciones. 7. Administración de servidores virtualizados. 8. Soporte CAU.

El personal técnico asignado que presten estos servicios deberá tener

conocimientos demostrables en los siguientes entornos:

1. S.O. Microsoft. Servidores (W2003, W2008 y W2012) y PCs (WXP y W7). 2. S.O Linux. 3. Virtualización (Vmware). 4. Administración de Oracle, SQL Server y My-SQL. 5. Seguridad perimetral e interna. 6. Administración de red y correo corporativo. 7. Interoperabilidad Administrativa. Librerías del MAP. 8. Configuración y acceso a redes BizkaiSarea, EuskalSarea y Sara.



3 DESCRIPCION DE LOS SERVICIOS A continuación se describen los parámetros del servicio actual del CAU y de

mantenimiento y las nuevas necesidades que se derivan de la nueva relación contractual a establecer con el adjudicatario.

3.1 Antecedentes y objetivos Esta área de actividad atiende en primera instancia de forma telefónica las

incidencias y solicitudes de los usuarios finales y proporciona o canaliza una solución en el plazo más breve posible:

De forma directa, telefónicamente y con herramientas de asistencia remota (1er.nivel)

En diferido, sin desplazamiento (1er Nivel) En diferido, con personal con capacidad de actuación in-situ (2º Nivel). En diferido, a través de otros servicios, como mantenimiento, soporte

aplicaciones, etc. Puede recibir incidencias y peticiones de servicio a través de correo

electrónico a traves de la dirección [email protected]

Las actividades que se realizan es este área se pueden tipificar en estos grupos:

Atención de llamadas, apertura de incidencias y tickets, calificación y resolución telefónica y seguimiento de incidentes.

Resolución en diferido, generalmente por control remoto de determinadas incidencias de puesto-usuario.

Desvío a segundos niveles de resolución Seguimiento de incidencias y cierre.

El Ayuntamiento pondrá a disposición del adjudicatario la aplicación de helpdesk

implementada al efecto (FCT_CAU) desarrollada por el departamento de TI. Este servicio es el responsable de facilitar a los usuarios municipales un punto de

contacto único para comunicar cualquier tipo de incidencia con los Sistemas de Información (tanto hardware como software).

3.2 Procedimiento básico.

Los procesos del Servicio, que se encuentran especificados en el correspondiente Procedimiento de calidad, a modo de resumen son:

a. Solicitud de Incidencia El usuario solicita un servicio del la sección, a través de los dos canales

disponibles, el registro telemático a través de la aplicación CAU, o el teléfono (944666318).

Si el usuario solicita el servicio de manera telemática describe lo más detalladamente posible la incidencia y la cataloga de una manera general.

En el caso de hacerlo vía teléfono el usuario describe al agente telefónico el tipo de incidencia, el agente graba los datos de: Usuario, Descripción del problema y Categoría.

mailto:[email protected]



Después de solicitar la incidencia la sección de TI asigna un identificador único a esa incidencia, de manera que el usuario disponga de una referencia única para consultar su estado. Este identificador es comunicado al usuario de forma telemática a través correo electrónico.

b. Asignación de Incidencia Una vez registrada la incidencia, esta es asignada de manera automática a un

agente del departamento en función de la categoría inicial. El agente recibe un aviso de manera telemática, indicándole que le ha sido asignado

un trabajo. En el caso de que el agente pertenezca al grupo de Atención Usuarios, este abrirá la

incidencia en el mismo instante de su notificación en el sistema de gestión y estudiará si la incidencia es de su competencia, si es así procederá a su clasificación.

En el caso de que por error la incidencia no es de su competencia, la reasignará en el sistema, documentando en el apartado de notas el motivo de la reasignación.

En el caso de que el agente no pertenezca al grupo de Atención de Usuarios, se consultarán las incidencias asignadas como mínimo una vez por día, preferiblemente a primera hora de la mañana.

c. Clasificación de Incidencia Una vez aceptada la incidencia, el agente responsable procede a su clasificación,

reasignándole categoría en caso de ser necesario, asignándole Subcategoría, asignando el proyecto en caso de que la incidencia sea relativa a un proyecto abierto o en fase de mantenimiento y la prioridad del trabajo en relación con la importancia de esta dentro del conjunto de trabajos pendientes.

Una vez clasificada la incidencia, se cambia el estado de estado de NUEVA a ABIERTA.

d. Análisis de Incidencia Antes de iniciar el estudio de la petición, se verifica que la información registrada es

correcta. Para determinar su validez: Si se trata de un mantenimiento correctivo o incidencia de hardware, se debe

reproducir el problema. En el caso de un mantenimiento evolutivo (Nuevos Desarrollos), Compras, Internet

hay que comprobar que la petición es razonable o factible. Se verifica que la información acerca de la incidencia sea suficiente, si no es así se

deberá de solicitar más información al peticionario a través de la aplicación, dejando de esta manera registro de dicha petición.

Una vez examinada la petición comienza su Análisis, que será diferente en función del tipo de mantenimiento establecido.

Si se trata de una petición de mantenimiento correctivo, incidencia de hardware o Tratamiento de Datos, y según el acuerdo de nivel de servicio establecido para los sistemas de información afectados, se evalúa hasta qué punto es crítico el problema.

Así es posible determinar si la solución es a corto plazo, es decir, la prioridad es del tipo MUY ALTA o ALTA, o si es a medio o a largo plazo:

1. Si el problema es crítico, su análisis y solución comienza

inmediatamente con el fin de reanudar rápidamente el nivel de



servicio. Sin embargo, este modo de actuación no elimina la necesidad de una revisión posterior del problema para valorar los posibles efectos secundarios, establecer una solución definitiva y actualizar todos los productos implicados.

2. Si no es crítico, la petición se clasifica para proceder en la tarea siguiente a determinar cuál es la solución más adecuada.

En el resto de los casos:

1. Si se trata de una petición de desarrollo se delimita su alcance

determinando si se trata de una modificación a los sistemas de información inicialmente afectados o de una incorporación para cubrir nuevas funcionalidades no contempladas hasta el momento en dichos sistemas de información, en el caso de ser nuevos desarrollos o modificaciones evolutivas a los ya existentes.

2. Si se trata de una compra se procede a su análisis, identificando como mínimo:

Si tiene implicación con el resto de los SI Si es necesario un Pliego de Condiciones Técnicas Si es una petición de un software sectorial, sin implicación con

el reto de los SI 3. Si se trata de una petición de publicación de Web, se identifican los

contenidos y método de actualización de estos, analizando la periodicidad.

4. Si se trata de una solicitud de tratamiento de la información. Se valora su criticidad y si existe una fecha de entrega.

5. Si se trata de una compra se analiza la petición y se mira si esta ha sido presupuestada con anterioridad. En el caso de que sea una petición no presupuestada y la compra sea de carácter urgente es necesario buscar la financiación oportuna.

Una vez analizadas las incidencias si no se va a trabajar en su resolución el agente

cambia el estado ABIERTA a PENDIENTE.

e. Reasignación En el caso de que la incidencia no sea competencia del servicio de CAU, este

reasigna la incidencia en función de su naturaleza a cualquiera de los integrantes de la sección.

Una vez realizado esta asignación al nuevo agente es comunicada a este de forma telemática.

f. Resolución, Documentación e Imputación Una vez analizada la incidencia el agente comienza su resolución, puede darse el

caso de que al agente la resuelva de inmediato o no. Si la resolución es inmediata, el agente resuelve la incidencia y en el apartado

solución documenta la forma de solución de una manera descriptiva indicando los pasos y documentos de apoyo (si los hubiera) donde está la forma de resolver la incidencia.

Esta descripción es lo más detallada posible con el objetivo de que sea lo suficientemente explicativa para permitir a otro agente resolver la misma incidencia reportada por otro usuario.



Una vez documentada la solución, el agente imputa el tiempo que ha tardado el resolver la incidencia, en el caso de que la incidencia haya sido clasificada con un proyecto, a la hora de imputar el tiempo, el agente indicará la fase y subfase del proyecto.

Si la incidencia no pertenece a ningún proyecto entonces la fase y subfase son las propias del Mantenimiento Correctivo.

Si la resolución se hace en varias etapas bien por que se hace en diferentes momentos o por diferentes agentes, entonces por cada trabajo que se haga para resolver la incidencia, se ha de documentar en notas adicionales cada trabajo realizado así como imputar el tiempo dedicado.

Una vez solucionado se documenta la solución definitiva. Una vez imputado el tiempo entonces el agente cambia de estado a la incidencia,

pasando el estado de ABIERTA a PENDIENTE DE VERIFICAR. El sistema envía una notificación al usuario, para que verifique el cierre de la

incidencia. En el caso de que una incidencia sea devuelta después de una verificación de un

usuario, el proceso es el mismo que el de Resolución.

g. Verificación El usuario verifica que la incidencia ha sido resuelta correctamente. En el caso de

que así sea, envía una nota adicional, validando su cierre. Sino el usuario indica al agente encargado de los motivos que argumenta para no cerrar la incidencia. En este caso el agente cambia de estado la incidencia de PENDIENTE DE VERIFICAR a PENDIENTE

h. Cierre Si la nota del usuario es positiva el agente cambia el estado de la incidencia de

PENDIENTE DE VERIFICAR a CERRADA. En el caso de que el usuario no conteste en 24 horas, el agente cierra la incidencia

sin confirmación por parte del usuario.

3.3 Otras condiciones.

El servicio debe ser bilingüe, euskera, castellano y a valorar el idioma inglés. El servicio se ejecutará desde las instalaciones del proveedor siempre y

cuando se cumplan los criterios técnicos, en caso contrario el Ayuntamiento habilitará un espacio dedicado a este tipo de servicio.

3.4 Definición del actual servicio de CAU primer nivel Los datos relevantes del servicio ofrecido en el último año son los siguientes:

3.4.1 Entorno tecnológico.

El entorno tecnológico que se debe atender es el siguiente: Puesto cliente Microsoft Conexión a red datos Ethernet/IP Servicios dispuestos sobre la red de datos. Ver portal web Seguridad

- OIAM, OAM y eSSO de Oracle, LDAP, Certificados (Izenpe). - Sistema IDS y Firewall. - VPN.



- WI-FI.

3.4.2 Tipo de actividad.

Los problemas, averías o peticiones que no pueden ser resueltos en el CAU (1er Nivel) se asignan a otras áreas para su resolución (técnicos especializados del departamento de TI), siendo responsabilidad del CAU (1er Nivel) el seguimiento, control y reporte de todo el proceso.

El Centro de Atención a Usuarios desarrolla su actividad a dos niveles de actuación y especialización:

1. Un primer nivel de atención telefónica en el que se resuelven on-line las consultas e incidencias reportadas por los usuarios finales y

2. Un segundo nivel de soporte especializado que atiende las incidencias no resueltas en primera instancia.

3.4.3 Cobertura del servicio.

La cobertura del servicio CAU es:

Lunes – Viernes 08:00 – 20:00

Durante el periodo de jornada continua (Junio a Septiembre) el horario del servicio

es el mismo con independencia del horario del usuario. Asimismo en Agosto, Diciembre y Semana Santa hay una clara disminución de la

actividad: Turno de Tarde (16:00 – 20:00): Disminuye en un 90% de actividad Agosto: Disminuye en un 50% de actividad Diciembre: Disminuye en un 10% de actividad Semana Santa: Disminuye en un 10% de actividad

3.5 Ubicación y equipamiento específico. Tanto la ubicación como el equipamiento necesario para la realización de las tareas

relacionadas con la herramienta de helpdesk debe proporcionarlos el adjudicatario e incluir en los mismos (PCs) la aplicación de FCT_CAU proporcionado por el departamento de TIC del ayuntamiento de Basauri a través de su intranet municipal.

En cuanto a comunicaciones, el adjudicatario debe disponer lo siguiente: 1. Telefonía y Datos:

Los aparatos telefónicos necesarios para que el personal adscrito al proyecto este localizado.

En caso de ser necesario: la electrónica de red de datos necesaria a instalar en la ubicación del adjudicatario o proveedor. A estos efectos, el adjudicatario o proveedor facilitará un armario rack para albergar la electrónica de red y las comunicaciones con las debidas garantías de control de acceso, así como el cableado de datos UTP categoría 6 hasta dicho rack, destinado a los puestos de atención del CAU.



Equipos: los puestos de trabajo necesarios para que los resolutores de primer nivel puedan acceder a la herramienta dispuesta sobre la red corporativa del ayuntamiento. Será necesario disponer los navegadores web indicados.

3.6 Usuarios Los usuarios que, de un modo u otro, tienen capacidad para acceder a los servicios

ofrecidos por el CAU del ayuntamiento se dividen en función de la ubicación:

EDIFICIO/ENTIDAD USUARIOS

AYUNTAMIENTO 112

BIDEARTE 31

BIDEBI 2

BRIGADA 9

CC BASOZELAI 23

CC IBAIGANE 13

CC POZOKOETXE 2

CC SAN MIGUEL 3

EISE 7

EMAKUMEEN ETXEA 13

ETXE MAITIA 8

EUSKALTEGI 2

HILERRIA 1

IMD ARTUNDUAGA 15

IMD URBI 1

LOCAL SINDICAL 1

OIAC SAN MIGUEL 2

POLICIA LOCAL 17

SOCIAL ANTZOKIA 8

TABERNA NAGUSIA 2

TS ARIZGOITI 1

TS KALERO 1

Total general 274

3.7 Tipos de tickets generados por el Centro de Atención a Usuarios

El CAU del Ayuntamiento se entiende como el punto de contacto único entre el

área de informática y los usuarios a los que la unidad ofrece servicio. Al tratarse de un punto de contacto único, los usuarios no discriminan el tipo de servicio que necesitan, simplemente transmiten la necesidad al CAU. Es éste el que recibe la comunicación del usuario y lo transforman en un ticket, que siguiendo las buenas prácticas ITIL, puede ser de 5 tipos:

Incidente: cualquier evento que no forma parte de la operación de un servicio y que provoca, o puede provocar, su interrupción o una bajada en



la calidad del servicio. (Ejemplo: no arranca un PC, no se puede acceder a la web corporativa, excesiva lentitud en el acceso a internet, etc.)

Problema: es la causa desconocida que provoca uno o más incidentes. (Ejemplo: se reitera la incidencia de un usuario que cada mañana comunica que no puede acceder a internet, los eventos diarios son “incidencias” y para investigar qué es lo que provoca esas incidencias diarias se abrirá un “problema”)

Solicitud: es una petición de servicio o consulta de información proveniente de un usuario final. (Ejemplo: instalación de un nuevo software, actualización del antivirus, mover una impresora de lugar, aumentar los privilegios de una cuenta de usuario, etc.)

Orden de Cambio: es una petición que requiere una aprobación por parte de los responsables del servicio, las órdenes de cambio pueden venir derivadas de un incidente, una solicitud o un problema. (Ejemplo: instalación masiva de software en un aula, instalación masiva de PC’s, cambio de los discos de un servidor de ficheros que está en producción, actualización del software del servidor de correo, etc.

Reclamaciones: constancias declaradas de los usuarios por las que no se encuentran conformes con el trato dado, resolución de la incidencia o servicio ofrecido.

3.8 Categorías utilizadas de incidentes y solicitudes Se detallan las categorías de incidentes (I) y solicitudes (R) utilizadas , así como el

número de cada una de ellas. Estas categorías dan una idea del catálogo de servicios del que debe dar soporte el CAU.

CATEGORÍA TOTAL

Desarrollo y mantenimiento de aplicaciones. 371

Datos geográficos - Cartografía 119

CPD Centro de Proceso de Datos 179

Mant. Puestos informáticos. Mant. soft. cliente. Copias seguridad 679

Comunicaciones voz y Datos 191

Consultoría y Organización 28

Total general 1567

La relación anterior de categorías debe considerarse como un punto de partida para

la prestación del servicio del CAU, pudiendo extenderse en la medida que crezca el ámbito de actuación del mismo o bien en caso de que se detecten líneas de servicio no incorporadas previamente.

La tipificación de las incidencias creadas en el sistema según una serie de categorías predefinidas tiene por objeto:

Facilitar el análisis y tratamiento inicial (búsqueda de soluciones, asignación, etc.).

Realizar un seguimiento posterior analizando las causas y las tendencias de los problemas registrados en el sistema.

Asignar una serie de valores por defecto al nuevo problema. Por ejemplo, al seleccionar una categoría para un problema se obtiene automáticamente la persona asignada para su resolución.



Adicionalmente, cada categoría de problema puede tener soluciones tipo asociadas, que podrán ser visualizadas siempre que se hayan registrado previamente. La tipificación se realizará basándose en tres o cuatro niveles, separados por “.”. Cada nivel implica un grado mayor de detalle en una tipificación jerárquica. Ejemplo de una tipificación/categoría de varios niveles:

3.9 Diagrama de flujo de la Gestión de Incidentes y Solicitudes A continuación se muestra el diagrama que define el flujo completo de estados por

los que puede pasar un incidente y una solicitud, así como una descripción de los estados:



3.10 Datos del Sistema Los datos del sistema son aquellos que, cargados en la herramienta de Gestión de

Incidencias, proporcionan un conjunto de valores predefinidos en determinados campos, facilitando el registro y tratamiento de las incidencias.

Los datos de referencia del sistema pueden clasificarse en:

1. Niveles de Resolución 2. Urgencias, impactos y prioridades definidas 3. Soluciones 4. Roles 5. Notificaciones 6. Informes 7. Indicadores

En las siguientes secciones se detalla el conjunto de datos del sistema identificados.

3.10.1 Niveles de Resolución

A continuación se detalla el conjunto de Niveles de Resolución existentes en el Sistema, y su descripción.

Nivel Descripción Nivel 1 Primera línea de atención telefónica- Técnico de Atención

Nivel 2. Técnicos que atienden desde el servicio de CAU in-situ o por control remoto

Nivel 3. Técnicos del departamento de TI responsables de servicios o especialistas

Nivel 4 Empresas proveedoras del Ayuntamiento de mantenimiento de hardware o software.

3.10.2 Urgencias, impactos y prioridades definidas

Han sido definidos por el ayuntamiento y configurados en FCT_CAU (sólo para incidentes) tiempos máximos de resolución (SLA´s) que permitirán, de manera orientativa, obtener al ayuntamiento una estimación de la capacidad resolutiva de los equipos TI. Estos tiempos son calculados de manera semi-automática por la aplicación en función de los valores de urgencia e impacto que son introducidos por los técnicos en base a unos criterios objetivos, son estos:

URGENCIA DESCRIPCIÓN 1 El incidente debe ser resulto de inmediato. Normalmente, implica usuario(s) parado(s) o impide

la realización de alguna acción que no puede esperar (p.e. cierre financiero)

2 Existe una solución provisional o alternativa que no deja parado al usuario y le permite seguir trabajando.

3 Poco urgente, la solución puede esperar.

IMPACTO DESCRIPCIÓN

1 Proceso o aplicación totalmente necesaria para el trabajo en un servicio crítico de cara al público. (p.e.: no funciona TAO en un puesto de ventanilla de la OIAC Proceso o aplicación cuyo fallo afecte a la ventanilla y por tanto, a un conjunto considerable de ciudadanía (p.e.: no puede emitirse un certificado de empadronamiento por qué no funciona la máquina expendedora de certificados

2 Operaciones importantes, pero sobre puestos de trabajo que no se utilizan para dar servicio a un colectivo que pueda generar colas. Cualquier aplicación crítica, para la que exista una solución



alternativa provisional. El problema afecta a una Unidad Orgánica completa (Servicio o Departamento).

3 Operaciones que no impiden el funcionamiento correcto de un servicio al público Operaciones sólo parcialmente afectadas Usuarios afectados <3

Con los valores obtenidos de la urgencia y el impacto se hará el cálculo de la

prioridad:

Urgencia Impacto

1 2 3

1 2 3 4

2 3 4 5

3 4 5 6

Las prioridades son definidas en función de la siguiente tabla

IMPACTO VALOR DESCRIPCIÓN TIEMPO DE

RESOLUCIÓN

Alta 2 o 3 Afecta a muchos usuarios y/o sistemas, que además quedan parados. También puede asignarse a otros escenarios cuando afecte a usuarios VIP o sistemas altamente críticos

4 horas de resolución

Media 4

Afecta a muchos usuarios y/o sistemas, que además quedan parados. También puede asignarse a otros escenarios cuando afecte a usuarios VIP o sistemas altamente críticos Afecta a un número reducido de usuarios. No quedan parados, aunque sí con operatividad limitada


Baja 5 o 6

Típicamente un único usuario o, en caso de ser varios, con un impacto inexistente en su operativa diaria. El incidente no será atendido mientras haya otros más prioritarios en espera.


3.10.3 Soluciones (BD de conocimiento)

El sistema permite utilizar mecanismos de ayuda para la resolución de problemas

abiertos. Principalmente se contemplan dos posibilidades:

- Dado un determinado problema, es posible buscar en el sistema problemas anteriores ya resueltos que sean similares al actual. Para ello existen ventanas de búsqueda que permitan obtener una lista de problemas que cumplan con el criterio de selección deseado.



- Por otra parte, es posible crear Soluciones Tipo que puedan aplicarse a determinadas incidencias. En este caso, deberán registrarse previamente dichas Soluciones.

3.10.4 Roles

Cada posible resolutor tiene disponible varios roles. Un rol define una serie de permisos sobre los objetos de SD, así como una vista predeterminada de la aplicación (pestañas, opciones, etc.). Se establece el rol en la esquina superior derecha de SD (“Establecer rol”).

A continuación se ven los 5 roles disponibles y el uso que cada uno de ellos debe hacer de los diferentes objetos de SD:

Además, utilizaremos otros dos los roles “Castellano” o “Euskara” sólo cuando

queramos actuar como Usuarios Finales. A continuación adjuntamos una breve definición de cada uno de los roles:

1. Primer nivel: rol propio del/ los técnicos del CAU (primera línea de soporte).

2. Técnicos In Situ: rol que identifica a los técnicos del CAU/ departamento de TI del ayuntamiento que resuelven incidentes y solicitudes presencialmente.

3. Resolutores de Servicio: rol asociado a los responsables de los servicios TI que presta el departamento de TI.

4. Proveedores: rol propio de los proveedores con los que mantiene relación con el Ayuntamiento.

5. Gestores de área: identifica a los gestores de equipo o grupo que tienen una visión estratégica y de supervisión de los servicios TI.

3.10.5 Notificaciones

La aplicación FCT_CAU enviará puntualmente notificaciones mediante correo

electrónico a los involucrados en el tratamiento de un ticket, son las siguientes:

1 Solo en casos excepcionales

ROL INCIDENCIAS PROBLEMAS SOLICITUDES CAMBIOS

Primer Nivel Crean/Resuelven Crean1 Crean/Resuelven Crean

Técnicos In Situ Crean(*)/Resuelven

Crean(*) Crean(*)/Resuelven Resuelven

Resolutores de Servicio

Resuelven Crean/Resuelven Resuelven Crean/Resuelven

Proveedores Resuelven Resuelven - -

Gestores de área - - - -



3.10.6 Informes

Los informes de Gestión de Incidencias permiten realizar un seguimiento del

funcionamiento del Centro de Atención a Usuarios. Mediante la obtención de estos informes se pueden:

- Detectar problemas que no están siendo resueltos según los niveles de

servicio definidos. - Detectar incidencias y problemas repetitivos. - Obtener indicadores y estadísticas sobre el funcionamiento del Help Desk.

Podemos agrupar los informes de gestión en cuatro grupos:

1. Estadísticas semanales

- Tickets (incidentes y solicitudes) nuevos y resueltos a lo largo de la semana anterior por grupo y ubicación.

2. Estadísticas mensuales

En el mes anterior:

- Tickets en cada organismo por colectivo de usuarios y tiempo medio de servicio.

- Tickets por categorías y tiempo medio de servicio. - Tickets resueltos y tiempo medio de servicio, para cada unidad, centro y

colectivo de usuario. - Tickets resuelto por método de resolución (In situ, Control remoto,

Teléfono, etc.)

- Tickets resueltos por ubicación y grupo resolutor

- Tickets resueltos por ubicación, grupo resolutor y nivel de resolución - Tickets resueltos por ubicación y colectivo de usuario.

3. Estadísticas mensuales acumuladas

- Tickets pendientes pro grupo y ubicación, y su reparto en 6 rangos de

antigüedad (<2dias, <4dias, <8dias, <30dias, >30dias)



- Estado actual de todos los tickets generados en los últimos 12 meses (abiertos, en proceso, resueltos, cerrados, etc.)

- Tipos de tickets en los últimos 12 meses (incidentes, solicitudes, problemas, etc.)

- Tiempo medio de servicio en los tickets de los últimos 12 meses, agrupado por nivel y grupo.

4. Cuadros de mando

- Tickets nuevos y resueltos en el día de hoy, ayer, en los últimos 7 días, 30

días y 365 días ordenados por: Entidad y ubicación. Entidad, ubicación y grupo. Entidad y resolutorio.

Indicadores

Con el fin de alcanzar los objetivos de calidad y mejora continua del proceso, se

medirán y monitorizarán diferentes parámetros de control que permitan establecer el nivel del servicio.

Para ello se utilizarán, al menos, los indicadores que se describen en la siguiente tabla. En ella se especifica el tipo de indicador, su descripción, el valor que tiene que cumplir en el periodo inicial de implantación y el valor objetivo una vez finalizado el periodo de implantación. Estos valores son los establecidos como objetivo y sólo vinculan al CAU de primer nivel, objeto de licitación para este pliego, en aquellos indicadores en los que se cita expresamente.

Tipo de Indicador Descripción del Indicador Valor Inicial Valor Objetivo

Capacidad de resolución Porcentaje de incidencias resueltas en primer nivel

>= 40% >= 45%

Como complemento a los Indicadores de Nivel de Servicio se realizan encuestas

periódicas de satisfacción entre los usuarios del CAU para captar el grado de aceptación e implantación del servicio.

3.10.7 Control remoto

Actualmente el CAU utiliza herramientas de acceso y control remoto de los puestos de trabajo de los usuarios.

3.10.8 Inventario de equipos de usuario

El departamento de TIC dispone de un inventario de los equipos de usuarios conectados a la red de datos utilizando la herramienta “ocs-iventory”

- El inventario corporativo de equipos se encuentra implementado mediante la solución. “ocs-iventory” Este inventario es parcial y recoge



exclusivamente aquellos equipos considerados o catalogados como corporativos

- Este inventario se está integrando actualmente en la herramienta de helpdesk mediante el establecimiento de procedimientos que realizan una exportación e importación de datos entre el aplicativo de inventario y la herramienta de Helpdesk.

- Está en proceso de integración la herramienta de CAU con los datos provenientes de la aplicación de inventario

3.10.9 Fichas de datos de los usuarios corporativos

Todos los usuarios de los colectivos indicados se encuentran localizados en un

directorio LDAP cuyo objetivo es facilitar la autenticación de los usuarios para el acceso a los diversos servicios y aplicativos proporcionados en la red de datos corporativa. Sin embargo, los datos disponibles en Ldap no son suficientes para las necesidades del CAU y deben complementarse con los datos que provienen directamente de las fuentes de autorización descritas. Así mismo, existe un directorio secundario Active Directory que contiene una réplica sincronizada de manera constante de los usuarios dispuestos sobre Ldap.

3.10.10 Acceso a documentación del departamento TIC

El CAU de primer nivel a contratar, a través del coordinador del servicio tendrá visibilidad y deberá consultar el Centro de Documentación de Servicios del departamento de TIC.

En el mismo se encontrarán el detalle técnico, funcional y operacional de los diferentes servicios y los protocolos de actuación ante incidencias en los mismos.



4 METODOLOGIA Y ORGANIZACIÓN En lo que se refiere a este contrato, el Ayuntamiento de Basauri ejercerá sus

competencias a través de un Comité Técnico. Corresponde a éste la supervisión de los trabajos para lograr los objetivos, sobre la base de las especificaciones del presente Pliego, proponer las modificaciones que convenga introducir o, en su caso, la suspensión de los trabajos si existiese causa suficiente motivada.

El Ayuntamiento de Basauri designará un Director del Contrato, con capacidad

adecuada y suficiente para las labores propias de este cargo, el cual podrá incorporar al proyecto, durante su realización, a las personas que estime necesarias para verificar y evaluar todas las actuaciones. El seguimiento y control se efectuará sobre las siguientes bases:

Seguimiento continuo de la evaluación del proyecto entre el responsable

del equipo de trabajo por parte del adjudicatario y el Director del Contrato. Reuniones de seguimiento y revisiones técnicas, con periodicidad mensual,

del responsable del equipo de trabajo, por parte del adjudicatario, y el Director del Contrato o persona en quien delegue, al objeto de revisar el grado de cumplimiento de los objetivos, los efectivos de personal dedicados al proyecto y la validación de las actividades realizadas.

Tras las revisiones técnicas, de las que se levantará acta, el Director del Contrato

podrá rechazar en todo o en parte los trabajos realizados, en la medida que no respondan a lo especificado o no superen los controles de calidad acordados.

4.1 Dirección del Contrato El director del Contrato desempeñará las funciones de dirección, inspección y

coordinación, estableciendo los criterios y líneas generales de la actuación del adjudicatario. Asimismo, tendrá las siguientes funciones:

Aprobar el plan de trabajo propuesto por el adjudicatario. Facilitar credenciales y contactos al equipo de trabajo del

adjudicatario. Validar las certificaciones para el abono de los trabajos y preparar los

controles para su recepción y liquidación. Rechazar cualquier trabajo, elemento o equipo que considere

inadecuado con el objeto del Pliego.

4.2 Obligaciones del Adjudicatario Serán las que tengan por objeto desarrollar las prescripciones del presente pliego,

que se concretan en el análisis, simplificación y rediseño de procedimientos administrativos del Ayuntamiento de Basauri y en la selección de la herramienta informática a implantar para la automatización de estos procedimientos.

Para el ejercicio y desarrollo de sus funciones, el adjudicatario deberá:



Informar al Ayuntamiento de la marcha de los trabajos encomendados. Proponer un plan de trabajo (según aplicación MS-PROJECT o

compatible) Establecer servicios de inventario y archivo que contendrán la

documentación de todas las tareas realizadas. Estos archivos estarán permanentemente a disposición del Ayuntamiento.

Aportar, para la realización del objeto del contrato, los medios propios de toda índole necesarios de cara al soporte técnico que puedan necesitar para llevar a efecto con éxito los trabajos de consultoría objeto del presente concurso. Contarán para ello con el (los) necesario(s) centro(s) de soporte y los medios de formación adecuados.

Corregir y modificar los distintos trabajos realizados si no fueran de conformidad del Director del Contrato.

El adjudicatario será responsable, enteramente, de la exactitud de los trabajos y en

general, de los resultados que proporcione a la Administración.

4.3 Metodología y Documentación

La metodología a seguir para la organización y ejecución del trabajo estará basada en la Metodología de Planificación y Desarrollo de Sistemas de Informática, promovida por el Consejo Superior de Informática (Métrica 3).

La documentación requerida de entregarse en soporte electrónico, y en papel en caso de que así fuera solicitada por el ayuntamiento, haciendo uso de las herramientas más adecuadas en cada caso. Con carácter preferente se utilizarán las siguientes herramientas de documentación:

Textos e Imágenes: MS-Office Planificación : Microsoft Project Diagramación: Microsoft Visio



5 EQUIPO DE TRABAJO Y DEDICACIÓN El adjudicatario aportará el personal necesario para la óptima realización de los

trabajos objeto del contrato, incluyendo como mínimo los siguientes perfiles, repartidos a lo largo de las distintas fases de los trabajos:

Director de Proyecto, que coordinará todas las actividades entre la

empresa adjudicataria y el Ayuntamiento. Estará en contacto con el Director del Contrato asignado por el Ayuntamiento de Basauri.

Se hace mención especial a las siguientes funciones: Seguimiento del Plan de Trabajo propuesto en la oferta y

aprobado por Ayuntamiento de Basauri, con estricto cumplimiento de plazos y calidad en las entregas de documentos previstos en dicho Plan.

Comunicación inmediata a la Dirección del proyecto de cualquier previsible alteración de las condiciones contractuales en cualquiera de sus aspectos (personal, técnico, económico, etc.), originado por causas ajenas al propio adjudicatario.

Comunicación inmediata a la Dirección del proyecto de las repercusiones y/o problemas que puedan plantearse en el desarrollo.

Técnico o técnicos encargados de realizar las labores especificadas en este Pliego de Prescripciones Técnicas.

El adjudicatario dispondrá de todos aquellos medios materiales que sean

necesarios para la correcta ejecución de los trabajos, que deberán estar detallados en las ofertas.

Para la correcta ejecución del proyecto el Ayuntamiento de Basauri aportará:

Aclaraciones y precisiones a los objetivos del proyecto. Aprobación de la documentación realizada. Interlocución necesaria con los usuarios y responsables del

Ayuntamiento. Cumplimiento de las acciones de implantación según los planes

previstos. Participación en las pruebas de integración y su visto bueno. Aprobación de la calidad de los servicios.



6 CONTROL Y SEGUIMIENTO

Se establecerá un equipo multidisciplinar para llevar a cabo el control y seguimiento

del proyecto. El Equipo de Proyecto estará formado por representantes del Ayuntamiento de

Basauri (Contratación y Tecnologías de la Información) y la empresa adjudicataria. La empresa adjudicataria deberá presentar un Plan de Trabajo con la planificación

de las tareas y la dedicación, indicando la posible necesidad de participación de técnicos del Ayuntamiento de Basauri en el caso de que se requiriese su colaboración o aportación de información específica, y que deberá ser aprobado por la Dirección del Proyecto.

Si durante la ejecución del Plan de Trabajo sobreviniesen desviaciones necesarias

respecto al programa inicialmente establecido la empresa adjudicataria presentará una modificación del mismo y un presupuesto corregido o complementario que deberá ser, a su vez, aprobado y aceptado por la Dirección del Proyecto antes de iniciar dichas desviaciones o trabajos complementarios.

La Dirección del Proyecto podrá solicitar de la empresa adjudicataria en cualquier

momento informes sobre el estado y grado de cumplimiento del programa comprometido. Conforme se vayan realizando las fases completas previstas en el Plan de Trabajo, la

empresa adjudicataria presentará a la Dirección del Proyecto los productos de la actividad realizada junto con un informe de situación y dedicación del trabajo encargado.

El adjudicatario se responsabilizará del levantamiento de las actas de todas las reuniones que se lleven a cabo y que deberán ser remitidas al día siguiente de su celebración para su aprobación por la Dirección del Proyecto.

Junto con las convocatorias de reunión se acompañará el Orden del Día de la misma

que será remitido con antelación suficiente para su estudio previo y aprobación por parte de la Dirección del Proyecto.



7 TERMINOS Y CONDICIONES DEL PROCEDIMIENTO

7.1 GENERALES:

El Ayuntamiento se reserva el derecho de realizar entrevistas, comprobar las referencias a la empresa licitadora.

El Ayuntamiento se reserva el derecho de declarar el concurso desierto. El Ayuntamiento no es responsable del coste en que incurra el licitador en la

preparación de la oferta.

7.2 CONDICIONES PARTICULARES

7.2.1 Responsabilidades de dirección y gestión del servicio.

La empresa adjudicataria deberá comunicar por escrito la designación de una persona de su organización (Delegado del Contratista) encargada de ejercer las facultades de dirección y organización en lo referente a prestación de los servicios contratados.

7.2.2 Control económico y facturación.

Los trabajos realizados se facturarán según el número de horas efectivamente dedicadas, al precio hora ofertada por la empresa adjudicataria y hasta el presupuesto máximo especificado en el pliego de condiciones administrativas.

La empresa adjudicataria emitirá una factura al final de cada mes por este número de horas junto a un informe con el desglose de las horas realizadas en cada jornada.

7.2.3 Propiedad intelectual, Seguridad y Confidencialidad.

7.2.4 Propiedad intelectual de los trabajos.

Sin perjuicio de lo dispuesto por la legislación vigente en materia de propiedad intelectual y de protección jurídica de todos trabajos desarrollados al amparo del presente contrato, los derechos corresponden únicamente al Ayuntamiento de Basauri, con exclusividad y a todos los efectos, incluyendo los programas en código fuente y toda la documentación técnica y de usuario que se genere.

7.2.5 Seguridad y confidencialidad de la información.

El adjudicatario queda expresamente obligado a mantener absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer con ocasión del cumplimiento del contrato, especialmente los de carácter personal, que no podrá copiar o utilizar con fin distinto al necesario para realizar la labor encomendada, ni tampoco ceder a otros ni siquiera a efectos de conservación.

Basauri, a 4 Diciembre de 2015

Enrique Pascual

Jefe Departamento de TIC´s

contratacion de servicios de soporte a suarios y … · 3.10.9 fichas de datos de los usuarios ......

Documents