Pliego técnico Contratación de una herramienta de gestión de CAU y CMDB

Transcripción

1 Pliego técnico Contratación de una herramienta de gestión de CAU y CMDB SOCIEDAD FORAL DE SERVICIOS INFORMÁTICOS Fecha de realización: 7 de octubre de 2013

2 1. Introducción Objeto del contrato Alcance del proyecto Planteamiento técnico... 4 Requerimientos funcionales... 4 Requerimientos Generales... 5 CMDB... 6 Service Desk... 7 Control Remoto... 9 Knowledge base Requerimientos técnicos Presentación Arquitectura de la solución Integración con otras herramientas Carga inicial de información Soporte y nivel de servicio mínimo Plan de proyecto Plan de entrega Plazo de ejecución Elementos a indicar en la oferta Pag.2

3 1. Introducción La Sociedad Foral de Servicios Informáticos (IZFE) presta servicios TI a las administraciones públicas de Gipuzkoa: Diputación Foral, Juntas Generales, Ayuntamientos y entidades locales y otras empresas y organismos públicos. Estos servicios incluyen tareas de soporte y asistencia que se apoyan en un software de Service Desk, que en la actualidad ha quedado obsoleto y que debe ser renovado. Asimismo, se pretende en esta renovación del sistema de Service Desk orientar tanto los procesos como las herramientas disponibles hacia una gestión más avanzada de los servicios TI atendiendo a las mejores prácticas en esta materia. Se pretende implantar una solución que permita gestionar una CMDB y los procesos de gestión IT habituales. 2. Objeto del contrato El objeto del contrato es la adquisición, implementación, soporte y garantía de un año, de una suite de productos que permitan gestionar con éxito los diferentes servicios TI así como los principales procesos para su gestión, atendiendo a las mejores prácticas IT. En ese sentido, IZFE toma como referencia el modelo de gestión IT de ITIL y el estándar ISO El sistema debe ser una herramienta capaz de gestionar, de modo general La definición de los servicios y sus componentes, recogiendo sus relaciones y el significado de las mismas, de modo que sea posible registrar y posteriormente, generar informes relativos a las diferentes peticiones, cambios, incidencias, etc. en los distintos elementos y sus afecciones a los servicios o a otros elementos. Recoger los distintos roles asociados a los servicios y sus componentes: responsables, técnicos al cargo del mantenimiento, etc. de modo que sea posible automatizar asignaciones de ciertos tipos de tareas a los roles designados. Gestionar los niveles de servicio requeridos para los distintos elementos y conectar la herramienta con sistemas que permitan su seguimiento. Gestionar las peticiones, cambios, incidencias, problemas, etc. relativos a los servicios o sus componentes. Generar informes sobre todos estos aspectos. Pag.3

4 3. Alcance del proyecto La propuesta debe incluir licencias de uso para los siguientes colectivos Grupo de soporte de primera línea: se trata de un grupo que hace uso intensivo de la herramienta. 15 técnicos de soporte en diferentes horarios de servicio, estando activos simultáneamente 10. Grupos de soporte de segunda línea: grupos que atienden tickets escalados desde el primer nivel, tickets internos de incidencias o peticiones o grupos de tercer nivel (empresas subcontratadas para mantenimiento de sistemas concretos). 120 técnicos de uso esporádico, calculándose una concurrencia media de 12 personas conectadas simultáneamente. Usuarios: grupo de aproximadamente 4000 usuarios que crean y consultan el estado de sus tickets, sin capacidad de gestión de los mismos, más allá de abrir, dar visto bueno a los cierres propuestos e incluir los comentarios oportunos. La herramienta debe soportar una media de entradas anuales. 4. Planteamiento técnico Requerimientos funcionales Se distinguen los siguientes módulos o grupos de funcionalidades principales: Service Desk: funciones para soportar la operativa de apertura de tickets (incidencias, peticiones, cambios, ) entre usuarios y soporte. CMDB: funciones de gestión del inventario de servicios TI y sus componentes, relaciones, atributos, etc. Funciones necesarias para soportar los principales procesos de gestión TI sobre los servicios IT definidos y sus componentes, según describen los estándares/modelos de referencia indicados. Funciones de gestión del conocimiento relativo a la resolución de problemas más típicos que ofrezcan posteriormente un sistema de autoayuda al usuario. Control remoto: funciones para que el soporte tome control del equipo de usuario para solucionar los problemas que pueda haber. Existen además otros requisitos de tipo técnico, integración con otras plataformas, etc. Pag.4

5 Requerimientos Generales La solución propuesta deberá estar alineada con las mejores prácticas ITIL. Para ello se valorarán acreditaciones reconocidas en este ámbito que se aporten PinkVERIFY (2011) y/o ITIL Software Scheme ISS- (Gold level). La plataforma deberá Ser multilenguaje, soportando simultáneamente al menos euskera y castellano, permitiendo que cada usuario configure el idioma en el que prefiere acceder a la plataforma. Esto debe incluir tanto los textos propios de la herramienta como los que se incluyan en la configuración particular de IZFE. Contar con ayuda integrada, en formato electrónico, sensible al contexto. El sistema deberá contar con un sistema para ofrecer en tiempo real un dashboard o cuadro de mando con los gráficos o indicadores más comunes. Deberá permitir generar nuevos sin necesidad de programación, en función de los datos que maneja la herramienta. Se valorará la variedad en los formatos de representación (numérico, gráficas de barras, sectores, gauges, tablas de datos,...) así como formatos -fuentes, colores,.- en función de umbrales. El dashboard será configurable por los usuarios para filtrar sus elementos de interés (tipos de tickets, elementos afectados, categorías, prioridades,...). Se valorará que pueda hacerlo separadamente para incidencias/problemas/cambios de forma genérica o configurable para los tipos que se definan. En cualquiera de los ámbitos de la solución podrán definirse campos adicionales, que serán dinámicos en función del registro (ítem CMDB, registro de Service Desk o inventario). La configuración de estos campos deberá poder realizarse desde el interface web, sin necesidad de programación. Podrá adjuntarse cualquier fichero de información adicional. El sistema contará con métodos de generación de métricas o indicadores configurables, que permita realizar un análisis de situación actual y pasada, así como análisis de tendencias. Las métricas deberán ser parametrizables, y accesibles desde el interface web. El sistema contará con un conjunto de reportes por defecto, ofreciendo facilidades para adaptar dichos reportes, modificándolos según las necesidades corporativas, y añadiendo nuevos reportes específicos. Los reportes deberán admitir visualización on-line, así como exportación al menos a formatos abiertos, PDF, texto u hojas de cálculo que permitan su tratamiento externo. Las diferentes pantallas (listados, informes,..) admitirán exportación a formatos abiertos (csv, pdf, imágenes, ) para su posterior utilización. En su generación admitirán filtrado por los campos comunes (fechas, categoría del registro, tipo del registro, cliente, prioridad, ). Pag.5

6 El sistema dispondrá de distintos niveles de acceso configurables por perfiles, permitiendo controlar qué perfiles de usuarios o técnicos pueden visualizar los diferentes ítems de información o realizar ciertas acciones. Se valorará que el sistema cuente con la opción de registrar la actividad de accesos (quién y cuándo se accede a cada registro) así como cambios en los campos de los registros. CMDB El módulo de gestión de configuración (CMDB) deberá estar integrado con el módulo de inventario permitiendo el alta automática de CIs tecnológicos detectados por el inventario y con los módulos de gestión de incidencias, problemas, peticiones, cambios El nivel de automatización para la gestión de CIs a partir del inventario, deberá ser configurable, permitiendo indicar qué tipos de activos deben ser automáticamente catalogados como CIs vinculados y dispondrá de opción de bloquear la modificación de CIs si no existen RFCs vinculadas. Se deberán poder definir reglas para configurar qué tipos de CIs se pueden dar de alta, tipos de relaciones entre tipos de CIs. Las relaciones entre CIs asociados a activos del inventario podrán gestionarse de manera automática. Se admitirá la creación de relaciones manuales. Se valorará que contemplen un valor que refleje el peso, importancia o impacto de la relación. Se deberá poder definir el ciclo de vida para cada tipo de CI y los estados compatibles con cada tipo. Se deberán poder configurar distintos niveles de profundidad (detalle de información) en función del tipo de CI, y campos de información diferenciados en función del tipo de CI seleccionado. El conjunto de tipos de datos para los campos de información deberá ser amplio para permitir los usos más comunes (textos, listas desplegables, opciones,...). Las relaciones, bien sean automáticas o manuales, deberán visualizarse en modo de listados y en representación gráfica. El modo gráfico de relaciones permitirá moverse entre los distintos CIs, mostrando el grado de importancia o impacto de cada una de las relaciones y su tipo y soportará búsquedas filtradas por tipos de CIs, de relaciones, profundidad a partir de un CI inicial. El modo gráfico deberá visualizar de manera rápida aquellos CIs en los que existan cambios sobre la situación monitorizada, en situación de fallo, con incidencias,.. El sistema admitirá modificar el estado (disponible/no disponible) de elementos de la CMDB desde herramientas externas que miden la disponibilidad de la infraestructura. Se valorará la capacidad de gestionar SLAs por defecto basados en la disponibilidad de los CIs, la calidad de parámetros TI medidos automáticamente, la capacidad disponible, el volumen de incidencias, o los tiempos y costes registrados. Pag.6

7 El sistema incluirá métodos de notificación a contactos configurados ante eventos en los diferentes CIs: planificaciones de paradas de servicios, cambios en servicios, incidencias en curso,... Estos métodos deberán tener en cuenta la publicación de avisos en el portal web o el envío de correos. Se valorará que la herramienta incorpore herramientas para la gestión de la seguridad de la información o los servicios alineada con los requisitos del Esquema Nacional de Seguridad: Gestión del valor de los ítems de información y servicios. Propagación de valores hacia elementos inferiores a través de las relaciones entre CIs. Análisis de riesgos de los sistemas de información definidos o enlace a herramientas que lo permitan Service Desk El software de Service Desk gestionará las incidencias, peticiones, problemas, cambios y entregas relativas a elementos de inventario y/o CMDB de forma totalmente integrada. Deberá contar con un flujo para la gestión del ciclo de vida totalmente alineado con las mejores prácticas ITIL, así como con la norma ISO El flujo deberá poder parametrizarse para adaptarse a las necesidades concretas de la organización, y deberá cubrir todo el ciclo de vida, desde el registro inicial, hasta el cierre final. Las incidencias o peticiones podrán relacionarse con otras incidencias, peticiones, problemas, RFCs o tópicos de conocimiento. Cualquiera de los módulos de gestión de incidencias, peticiones, problemas, cambios o entregas deberá estar integrado y tener acceso directo a cualquiera de los CIs almacenados en el módulo de gestión de la configuración (CMDB). Las relaciones deberán ser bidireccionales. Además, la aplicación gestionará las comunicaciones con el usuario a través de un portal web para que cualquier usuario de la organización pueda conocer el estado de sus incidencias dadas de alta. El portal de los usuarios contará con opciones de autoayuda, permitiendo a los usuarios la consulta de FAQs o tópicos de conocimiento previamente publicados por el personal de soporte, y que permita la resolución rápida de incidencias o peticiones sin necesidad de contactar con el personal de soporte. Contará con opciones de integración de chat para que los usuarios contacten con los técnicos de soporte. El portal podrá ser configurable, permitiendo ordenar, acumular, filtrar las pantallas de datos en función de los campos de los registros (categorías, tipos, prioridades, o bien los campos personalizados definidos) sin necesidad de programación. El sistema permitirá configurar plantillas. Debe poder definirse que perfil de usuarios pueden utilizar ciertas plantillas o haber modelos diferentes para usuarios o técnicos. Pag.7

8 Se podrán configurar distintos grupos de soporte que funcionen únicamente como línea de soporte superior de otros grupos sin admitir asignación directa de los usuarios. La herramienta incorporará métodos para clasificar las incidencias en distintos tipos y categorías. Se podrán configurar las categorías de incidencias necesarias, enlazarlas jerárquicamente en los niveles necesarios y asociar categorías o tipos a tipos de CIs. En función de la clasificación de la incidencia o petición, el sistema será capaz de gestionar un flujo de autorizaciones previo a la atención del registro. Los perfiles autorizadores no serán necesariamente personal técnico de soporte. Las incidencias y peticiones podrán priorizarse en base al impacto y urgencia de las mismas. Se valorará la existencia de algún mecanismo que permita establecer las reglas de prioridad lo más amplio posible utilizando los campos disponibles (tipos, categorías, elementos afectados, intervalos de tiempo transcurridos, campos propios que indiquen prioridades o impactos,..). El sistema permitirá configurar escalados en función de la clasificación. Contará con algún sistema automático que permita el escalado automático de incidencias o peticiones en función de los valores introducidos por los usuarios en el formulario de soporte disponible en el portal de usuarios. Cualquier incidencia o petición podrá asociarse con elementos del inventario y/o CMDB. La vinculación entre los elementos del inventario o CMDB y la incidencia o petición deberá ser bidireccional. El sistema admitirá el alta de nuevas incidencias o peticiones realizadas directamente por los técnicos de soporte en su nombre de los usuarios. Debe poder configurarse qué perfiles de técnicos pueden dar de alta dichos registros. El sistema admitirá el alta de nuevas incidencias o peticiones mediante el envío de correos electrónicos a cuentas de (POP3, IMAP). Deberán poderse configurar distintas cuentas asociadas a la creación de distintos tipos o categorías o reglas para la creación en función de los campos que incluya el mensaje. También admitirá el alta de nuevas incidencias o peticiones directamente a partir de cambios detectados en la infraestructura. El sistema registrará el origen de la notificación de la incidencia o petición, admitiendo distinguir al menos la recepción de incidencias desde el portal web de usuarios (registro de origen automático), origen en correos electrónicos, origen mediante llamada telefónica o cualquier otro origen configurable. Los cambios de estado en la incidencia o petición podrán ser notificados de manera automática por la herramienta vía correo electrónico, dirigido tanto a los usuarios finales como a los técnicos de soporte. Deben poder manejarse distintos mensajes para los usuarios o internos entre los técnicos de soporte. El sistema deberá contabilizar de manera automática el tiempo invertido en cada etapa del ciclo de vida, así como guardar el histórico de dicho ciclo de vida. Pag.8

9 El sistema permitirá notificar a los técnicos cuando existan registros en su bandeja de entrada que hayan excedido un umbral de tiempo (configurable) sin haber sido atendidos. Permitirá configurar reglas para el escalado jerárquico de incidencias / peticiones que superen un umbral configurable del SLA asignado así como enviar notificaciones automáticas como aviso. En función de la clasificación de la incidencia o petición, el sistema será capaz de calcular automáticamente SLAs basados en tiempos de atención, escalados o resolución. Deberán tenerse en cuenta diferentes calendarios y horarios de servicio en estos cálculos. Cualquiera de las acciones documentadas por los técnicos de soporte podrá ser marcada para ser visible al usuario final o privada, para uso interno de los técnicos de soporte. El cierre podrá realizarse por el propio usuario una vez validado. En el momento del cierre de las incidencias o peticiones, el usuario podrá contestar una encuesta de valoración (global y/o vinculada a tipos concretos de incidencias/peticiones) totalmente configurable por parte de los técnicos de soporte. Los registros podrán ser confirmados y cerrados por el usuario directamente desde el interface web, momento en el que el sistema podrá ser configurado para realizar una encuesta de satisfacción. Ante la circunstancia de que el usuario final no cierre la incidencia o petición en un tiempo razonable, el sistema deberá ofrecer mecanismos configurables para su cierre automático. En el momento del cierre de la incidencia o petición, el sistema deberá calcular de manera automática al menos: tiempo real de resolución tiempo real de cierre horas invertidas en las acciones realizadas grado de cumplimiento del SLA establecido Control Remoto Deberá ser posible tomar el control remoto a sistemas multiplataforma, admitiendo al menos los basados en SO Windows (32/64 bits, clientes o servidores, físicos o virtuales), SO MacOS (mínimo 10) y Linux. Se valorará la capacidad de capturar dispositivos móviles como teléfonos y tabletas bajo Android, IOS,.. El control remoto deberá ser capaz de tomar el control sobre el equipos remotos teniendo en cuenta que tanto los usuarios como los técnicos pueden encontrarse en redes privadas (intranet) o públicas (internet). Se valorará que disponga de medios para minimizar el ancho de banda disponible y para evitar configuraciones específicas de red (uso de protocolos y puertos habituales). Deberá ser posible cifrar las comunicaciones entre técnicos y usuarios con sistemas actuales y reconocidos por su robustez. Pag.9

10 Los mecanismos de control remoto atendido deben poder ser parametrizables, pudiendo configurar si se inicia bajo autorización o no del usuario y mostrando o no al usuario la actividad de control remoto del técnico. En el caso de autorización con el usuario presente se valorará que ésta se haga mediante su contraseña de Directorio para verificar la identidad del autorizador. Tanto en modo atendido como desatendido, el sistema dispondrá de la capacidad de poder cambiar la sesión y activar el modo administrador, suponiendo que la cuenta en sesión no tenga de tales privilegios. También deberá ser capaz de realizar reinicios de la máquina con reconexión automática una vez el equipo vuelva a estar accesible, tanto en modo de control remoto desatendido como en modo atendido y sin haber instalado previamente ningún servicio que posibilite el control remoto desatendido. El sistema dispondrá de chat escrito (directamente sobre la herramienta) para la comunicación entre el técnico de soporte y el usuario final que está recibiendo la atención remota. Se valorará la existencia de voz (directamente sobre la herramienta) o videoconferencia. El sistema dispondrá de un mecanismo de uso fácil para la transmisión de ficheros bidireccional entre el técnico de soporte y el usuario, de manera segura. El sistema dispondrá de copia de portapapeles desde/hacia el cliente. Se valorará que desde el chat haya sistemas para abrir fácilmente una incidencia o petición usando la información del usuario de chat y el texto introducido como descripción. El sistema dispondrá de la opción de grabar las sesiones remotas, incluyendo la información contenida en el chat, para su posterior documentación. Estas grabaciones deberán ser exportables a formatos de video estándar fuera de la herramienta. El sistema dispondrá de un mecanismo para la gestión de múltiples sesiones simultáneamente por parte de los técnicos de soporte. El establecimiento de la sesión y control remoto deberá ser en un lapso de tiempo corto. El sistema dispondrá de envío de combinaciones o teclas especiales (CTRL+ALT+SUPR, Windows+X, comando en Mac,...). El control remoto deberá ser capaz de tomar el control sobre el equipos remotos teniendo en cuenta que los usuarios pueden disponer de más de un monitor o de resoluciones mayores que las del técnico. Se valorará que los técnicos dispongan de una lista personalizada de equipos a controlar remotamente de uso frecuente. Se valorará que las sesiones de control remoto sean transferibles entre los técnicos. Knowledge base La solución propuesta deberá implementar un ciclo de vida de los tópicos de conocimiento registrados, totalmente alineado conforme a las mejores prácticas ITIL. Pag.10

11 Deben poder establecerse roles para revisar y autorizar la publicación y revisión de los tópicos de conocimiento, permitiendo que sólo los tópicos previamente autorizados estén disponibles para su consulta. Deberá permitir la publicación de tópicos a los usuarios finales, no sólo a los técnicos de soporte, permitiendo configurar el nivel de visibilidad de los tópicos. La plataforma deberá registrar automáticamente los cambios que ha sufrido el tópico de conocimiento a lo largo de su ciclo de vida La plataforma deberá ofrecer un sistema de autoayuda al usuario en función de los elementos afectados, tipos de incidencias o peticiones similares, etc. La plataforma deberá contar con sistemas para revisar y generar informes asociados al uso de los tópicos de conocimiento. El contenido generado deberá ser exportable a formatos abiertos. Requerimientos técnicos Presentación La plataforma contará con un interface 100% web, tanto para la administración del sistema como para su uso, sin necesidad de instalar software adicional en los equipos. El portal web de los usuarios deberá ser compatible con los principales navegadores web (IE, Firefox, Chrome,..). El interfaz web ofrecerá: Portal de usuarios. Portal de técnicos encargados de la resolución de las peticiones o incidencias. Portal de gestores con cuadro de mando y funciones de generación de informes relativos al servicio, elementos o procesos de los que sean responsables. Portal de administradores de la herramienta. El portal de usuarios podrá ser totalmente configurable, con la opción de añadir los logotipos corporativos, mensajes de bienvenida y alertas/avisos. Desde el portal de usuario podrán publicarse distintos links configurables, para acceder a otros sistemas web corporativos, o incluso a enlaces externos. Arquitectura de la solución Se valorará que la propuesta sea una suite completa y totalmente integrada de un mismo fabricante Pag.11

12 La plataforma tendrá la posibilidad de ser instalada en servidores físicos o virtuales, sin que haya diferencias en las funcionalidades. Debe ser compatible con la infraestructura disponible, VMware vsphere 5.1 La plataforma debe permitir la instalación en un único servidor o bien distribuir al menos la capa de aplicación y base de datos en diferentes servidores. Los motores de bases de datos incluirán entre los compatibles, al menos, Microsoft SQL Server y Oracle. Deben admitirse en ambos casos las ediciones gratuitas. La base de datos deberá entregarse totalmente documentada, incluyendo al menos el Diagrama Entidad-Relación y el Documento de Diseño Técnico, ambos totalmente actualizados y disponibles para su ayuda en línea. La base de datos deberá disponer de métodos para su consulta desde sistemas externos sin necesidad de contar con el apoyo del fabricante, ni contratar servicios extra adicionales. Integración con otras herramientas La solución propuesta se integrará con otras herramientas que ya existen en IZFE y que gestionan aspectos relacionados con ésta. Se detallan las herramientas con las que deberá integrarse la solución propuesta y al final un resumen a los métodos de integración propuestos. Inventario IZFE dispone actualmente de la herramienta ProactivaNet Inventario, en la que gestiona el parque de equipos (principalmente, microinformática, pero también servidores y otros elementos). La solución propuesta deberá integrarse con el Inventario y mantener esta integración en el futuro. Esta compatibilidad no puede limitarse a una carga puntual o planificada (batch) sino que debe estar directamente integrada con él. Las funciones de integración requeridas incluyen la creación de CIs en la CMDB a partir de elementos del inventario de modo automático para ciertos tipos de CIs o manual, el acceso a campos de información sobre un CI contenidos en el inventario,.. Directorios de Usuarios Los grupos de usuarios de la herramienta están definidos en diferentes Directorios. La herramienta deberá poder recoger de esos Directorios la definición de los usuarios, los grupos en los que están integrados y otros parámetros. Estos Directorios son o o Directorio Activo de Microsoft (versión 2008 R2) y Novel Identity Manager Aplicación propia: los usuarios de ayuntamientos y entidades locales residen en una aplicación propia de IZFE que los alberga en una base de datos propia. Pag.12

13 Gestión de Proyectos de desarrollo IZFE gestiona proyectos de desarrollo de aplicaciones en la herramienta de HP Project and Portfolio Management Center PPM- (Versión ). Se plantea una interrelación de los dos sistemas en varios aspectos como pueden ser o o o Relación de solicitudes de asistencia técnica, averías, etc. del Service Desk con los proyectos de desarrollo o mantenimiento en PPM. Lanzamiento de peticiones de cambio en el Service Desk a partir de cambios validados en los proyectos PPM. Monitorización de activos IZFE dispone de varias herramientas que monitorizan el estado de elementos de infraestructura (CIs o elementos de inventario) capaces de registrar su estado (correcto o fallo) o diferentes niveles (por ejemplo, % de ocupación de discos, líneas de comunicaciones, memoria, ). Estas herramientas normalmente están preparadas para ejecutar acciones (envío de correo, ejecución de un comando local o remoto, petición web, ). La solución propuesta debería disponer de métodos para aceptar peticiones por estas vías y así actualizar el estado de los activos afectados. Estos son varios tipos de integraciones planteada pero se pueden plantear otros en el futuro por lo que son deseables métodos de integración lo más abiertos posibles. Para ello se valorará la capacidad de incorporar diferentes métodos de integración entre la solución propuesta y otras, entre los que se proponen: Webservices: Capacidad de la herramienta de ofrecer un juego de servicios web documentados con capacidad para que sistemas externos ejecuten operaciones sobre la información contenida de modo asíncrono. Correo: Capacidad de la herramienta de recibir mensajes de correo electrónico formateados que realicen operaciones sobre elementos, tickets. Ficheros de intercambio (csv, xml, ): Capacidad de sincronizar datos de la herramienta con ficheros de intercambio en el formato indicado en intervalos de tiempo planificados. Conexión directa de bases de datos: Información completa del modelo de datos de cara a que aplicaciones externas inserten o lean directamente la información. En todo caso se valorará la capacidad de la herramienta para su apertura futura a otros tipos de herramientas (sistemas de reporting, ) no definidos actualmente. Carga inicial de información Como parte de la migración de la herramienta actual (CA Service Desk versión 11.2) deberá realizarse una carga inicial de datos. Pag.13

14 Elementos de CMDB o Inventario o Información relativa a servicios, ítems de información, responsables, valor (en el ámbito del Esquema Nacional de Seguridad) en formato Excel. o Información relativa a aplicaciones, entornos que soportan aplicaciones y servidores que soportan entornos (relacionados entre los 3 elementos), así como de contactos, responsables, etc. Albergada en base de datos SQL server exportable a Access, documentada la estructura. o Listados de elementos de red y equipos en formatos Excel. Información de usuarios: o grupos a los que pertenecen: información que no concuerda con el Directorio, ya que una misma persona puede pertenecer a diferentes grupos de escalado. o ubicación física de los usuarios, teléfono, Soporte y nivel de servicio mínimo Servicio comercial El adjudicatario dispondrá de servicio técnico-comercial para atender las necesidades del servicio, tales como estudio de necesidades, presentación de nuevos productos y servicios, facturación o cualquier otra atención comercial. El licitador designará un gestor comercial para la coordinación de todas las cuestiones relacionadas con la gestión del contrato, indicándolo en la propuesta. Servicio técnico El licitador designará un experto técnico certificado para la transmisión y coordinación de las incidencias que pudieran surgir durante la duración del contrato. Además deberá indicar el número de empleados certificados dedicado al objeto de contratación en su empresa. Este servicio, podrá ser dado por el licitador o por el fabricante. En cualquiera de los casos, deberá indicarse en la oferta los protocolos de tramitación de incidencias. El nivel de servicio se medirá desde el momento en que IZFE comunique la incidencia. Esta comunicación se realizará mediante el protocolo propuesto por el licitador para la gestión de incidencias y que deberá ser aceptado por Izfe. Se requerirá un nivel de servicio preferente por parte del licitador que deberá incluir: Experto técnico asignado Asistencia Remota, Web, Mail y Telefónica Tiempo máximo de respuesta indicado por el licitador Soporte proactivo Intervención de emergencia In-Situ Pag.14

15 Izfe calificará las incidencias como: Incidencias no críticas: Serán las incidencias que los técnicos de Izfe remitan vía web, mail o telefónica al adjudicatario y que no sean por paradas de servicio. Incidencias críticas: Serán las incidencias que se generen debidas a una parada de servicio o infección de elementos del parque. Izfe será el que defina el nivel de servicio de la incidencia y la de por resuelta. Los plazos máximos de resolución serán: Incidencias no críticas: los plazos máximos definidos por el adjudicatario en su oferta. Incidencias críticas: deberán ser atendidas en menos de 24 horas y el plazo de resolución será de 48 horas. Izfe podrá escalar la definición de las incidencias de no críticas a críticas cuando las causas lo justifiquen. 5. Plan de proyecto La contratación del servicio llevará asociadas una serie de tareas que garanticen el seguimiento y la calidad del mismo. Por tanto, la oferta deberá contener información sobre: Proyecto de implantación Organización: Implantación de procedimientos y herramientas y diagramas de comunicación Seguimiento e Informes: Seguimiento continuo del proceso de implementación y posterior evolución del sistema y elaboración de informes. Documentación: A la entrega del proyecto, se proveerá a IZFE de la documentación técnica necesaria, describiendo la instalación y el mantenimiento. Concretamente la oferta describirá el proceso que propone para garantizar el control del seguimiento de los trabajos, con una calidad óptima. Se incluirá como mínimo: Procedimientos a utilizar Roles y responsabilidades Pag.15

16 6. Plan de entrega Los suministros objeto de este pliego deberán realizarse en los plazos que se indican a continuación: Se deberá proveer antes del 31 de diciembre del 2013 de los siguientes elementos: Proyecto de instalación Licencias de Service Desk Licencias de control remoto La implantación de la CMDB se realizará antes del 28 de febrero de Las garantías, comenzarán a computar tras la aceptación por IZFE del proyecto de implantación de la suite de productos objeto del contrato. 7. Plazo de ejecución La oferta deberá detallar el plan de implementación de la herramienta así como los hitos y plazos para la ejecución de cada uno de ellos. En el momento de la adjudicación, el licitador designará a un coordinador técnico que junto con las personas designadas por IZFE definirán y ejecutarán el plan de implementación del objeto contratado. El licitador pondrá a disposición de IZFE tantos recursos humanos y técnicos como sean necesarios para la implantación del proyecto en el plazo indicado. En el precio de licitación estarán incluidos todos los gastos que estas asistencias puedan conllevar, tales como desplazamientos, hoteles, etc 8. Elementos a indicar en la oferta El licitador, de forma clara, deberá indicar ineludiblemente en la oferta: En caso de que el licitador no sea el propietario de la solución a implementar, deberá acreditar certificación del fabricante de la herramienta. Plazos y procedimientos de implementación de la solución. Configuración detallada del equipo de trabajo. Descripción y detalle de los procedimientos de control y seguridad de los trabajos. Detalle del nivel de servicio en el caso de que implique mejoría sobre los mínimos solicitados por Izfe. Pag.16

17 9. Mejoras Se valorarán las mejoras relacionadas con el objeto del expediente, que cumplan con el precio de licitación, en especial las relativas a: Mejoras en las características y funcionalidades de las licencias suministradas Mejoras en el número de licencias suministradas Mejoras en el tipo de soporte Mejoras en el periodo de soporte Bolsa de horas de servicio técnico especializado Auditoría de implantación CMDB Otras mejoras Pag.17