Source: http://docplayer.es/486885-Propuesta-del-grupo-a-para-la-implantacion-de-itil-en-la-empresa-gxi-s-a.html
Timestamp: 2018-04-22 05:33:34+00:00

Document:
Propuesta del Grupo A para la implantación de ITIL en la empresa GXI S.A. - PDF
Propuesta del Grupo A para la implantación de ITIL en la empresa GXI S.A.
Download "Propuesta del Grupo A para la implantación de ITIL en la empresa GXI S.A."
Luis Miguel Montero Zúñiga
1 Propuesta del Grupo A para la implantación de ITIL en la empresa GXI S.A. Marc Aguilar Eduardo García Javier Navarro Joel Sàmper Director: Jorge Infante Mòdul de gestió de xarxes i serveis 3r trimestre, 1r curs de 2n cicle Any 2005
2 Resumen: Implantamos un sistema de gestión de redes y servicios de una empresa de seguros. Tras analizar la situación de la empresa, nuestro departamento especifica un servicio de help desk, gestión de incidencias estructurada en 4 niveles con servicio 24/7, gestión de problemas y gestión de cambios; todo ello basado en ITIL. Hemos implantado en laboratorio soluciones concretas: monitorización de dispositivos con NetMRG y SNMP para la gestión proactiva y reactiva; monitorización del servidor web Apache basado en Wbem, con la creación de un cliente Java, un provider en C y la definición de una clase MOF; y definición de procesos con Keops workflow. Hemos redactado acuerdos de nivel de servicio para los servicios de correo electrónico y de help desk. Hemos resumido alternativas de outsourcing disponibles en el mercado. El diagrama de Gantt muestra el plan de implantación, que consta de 3 fases con una duración total de 14 meses. Palabras clave: redes, servicios, gestión, help desk, service desk, incidencias, ITIL, NetMRG, SNMP, Apache, Wbem, CIM, MOF, Keops, workflow, outsourcing, CMDB, inventario, SLA, OpenWbem, Conzentra, Indra, snmpwalk. Abstract: A network and service management system for an insurance firm is implemented. After analyzing the situation of the firm our department specifies a help desk service, incident management structured in 4 stages with 24/7 service, problem management and change management; all based on ITIL. We have implemented concrete solutions in laboratory: device monitoring with NetMRG and SNMP for proactive and reactive management; Apache web server monitoring based on Wbem, with the creation of a Java client, a C provider and with the definition of a MOF class; and process definition with Keops workflow. We have composed service level agreements for and help desk services. We have summarized outsourcing alternatives available in open market. A Gantt diagram shows the implementation plan, which consists of 3 stages with a total time span of 14 months. Keywords: network, service, management, help desk, service desk, incident, ITIL, NetMRG, SNMP, Apache, Wbem, CIM, MOF, Keops, workflow, outsourcing, CMDB, inventory, SLA, OpenWbem, Conzentra, Indra, snmpwalk. A Team 2/133
3 Tabla de contenidos 0. Introducción Objetivos Contenidos Audiencia del estudio Resumen ejecutivo Plan de implantación de procesos ITIL Estudio de la situación actual Estado actual de la empresa Problemas internos detectados Conclusiones Objetivos tácticos Introducción Objetivos propuestos de gestión Plan de trabajo Introducción ª fase del plan ª fase del plan ª fase del plan Diagrama temporal Mejora continua y evaluación Procesos de gestión de servicios Servicio de Service Desk Introducción: Objetivos de nuestro Service Desk Análisis características diferentes sedes Diferentes estructuras posibles Service Desk Propuesta estructura Service Desk Aplicación utilizada Service Desk Gestión de incidencias Introducción Descripción del sistema de gestión Gestión de problemas Introducción Descripción del sistema de gestión Organización del personal Gestión de cambios Introducción Proceso de cambios Conclusiones Diseño inicial de la CMDB Definición Ubicación y mantenimiento Acuerdos de nivel de servicio Herramientas de monitorización NetMrg Introducción Instalación y configuración de NetMRG Manual de uso Diagrama de la red Dispositivos a gestionar Perfiles de usuario Creación de monitores Uso de scripts para los monitores Creación de monitores/gráficos A Team 3/133
4 4.2. Wbem Introducción Análisis de requisitos Casos de uso de la aplicación Diagramas de secuencia Resumen aplicación desarrollada Implementación del proveedor Herramientas de gestión: Keops Workflow Diseño Flujo Explotación Inicio, desarrollo y cierre de incidencias Otras funcionalidades Outsourcing Introducción Conzentra Indra Conclusiones sobre el outsourcing Referencias Miembros del equipo de trabajo ANEXO 1: Enunciado del proyecto ANEXO 2: Diagrama de Gantt del proyecto ANEXO 3: Manual de instalación del Keops ANEXO 4: Scripts para el NetMRG ANEXO 5: SLA para el servicio de correo electrónico ANEXO 6: SLA para el servicio de help desk externo A Team 4/133
5 Tabla de figuras Tabla 3.a. Distribución del personal por turnos y sedes Tabla 3.b. Distribución de turnos y horarios en las diferentes sedes Figura 3.c. Diferencia horaria entre sedes Figura 3.d.. Esquema de captación de incidencias y primer nivel de resolución Figura 3.e. Formato del formulario de captación de incidencias Tabla 3.k. Distribución del personal por sedes Tabla 3.l. Distribución de turnos y horarios en las diferentes sedes Tabla 3.m. Distribución del personal por turnos, sedes y niveles Figura 3.n. Modelo conceptual de la CMDB Figura 4.a. Diagrama de dispositivos y equipos en la red GXI Tabla 4.b. IPs de los dispositivos a gestionar Figura 4.c. Vista Administrador de la página principal de NetMrg Figura 4.d. Vista cliente del árbol de dispositivos Figura 4.e. Monitores creados Figura 4.f. Añadir un script a NetMrg Figura 4.g. Visualización de los scripts declarados Figura 4.h. Añadir los scripts a una carpeta creada Figura 4.i. Crear un nuevo monitor Figura 4.j. Añadir al sub-dispositivo un monitor Figura 4.k. Añadir a otro sub-dispositivo un monitor Figuras 4.l. Aplicar plantillas de gráficos a monitores. Visualización de gráficos Figura 4.m. Caso de uso #M Figura 4.n. Caso de uso #C Figura 4.o. Caso de uso #E Figura 4.p. Caso de uso #F Figura 4.q. Diagrama de secuencia de acceso a todos los logs registrados Figura 4.r. Diagrama de secuencia de iniciar y parar el servicio Apache Figura 4.s. Diagrama de secuencia de filtrar los logs por fecha Figura 4.t. Diagrama de secuencia de visualización de estadísticas Figura 4.u. Esquema de bloques de los elementos de la plataforma Wbem Figura 4.v. Diagrama UML de las clases del cliente Wbem Figura 4.x. Ejecutar EnumInstances con cliente Wbem Pegasus Figura 4.z. Diagrama de secuencia del funcionamiento general del cliente Wbem Java Figura 4.aa. Ventana principal de interacción con usuario Figura 4.ab. Menú Servidores Figura 4.ac. Menú Accesos Figura 4.ad. Menú Estadísticas Figura 4.ae. Interfaz gráfica para escoger una fecha Figuras 4.af. Parámetros de filtrado Figura 4.ag. Resultado del filtrado Figura 4.ah. Especificación de parámetros para las estadísticas según IP o recurso Figura 4.ai. Estadísticas por fecha Figura 4.aj. Resultado de las estadísticas generales Figura 5.a. Diseño de un flujo en la aplicación de workflow Keops Figura 5.b. Definición de un diccionario de datos Figura 5.c. Presentación de un diccionario de datos Figura 5.d. Pantalla de login una vez desarrollado el workflow Figura 5.e. Pantalla de alta de incidencia Figura 5.f. Pantalla de cierre de incidencia Figura 5.e. Historial de incidencias Figura 5.f. Relación de incidencias aplicando un filtro Figura 6.a. Diagrama de los niveles de incidencias en outsourcing A Team 5/133
6 0. Introducción 0.1. Objetivos En este documento, el grupo A3-Team presenta su propuesta de implantación de procesos para la gestión de las infraestructuras y servicios TIC, de acuerdo con el enunciado del proyecto detallado en el anexo 1. Primero se realiza un análisis de las necesidades de GXI en cuanto a la gestión de sus sistemas TIC se refiere, para más tarde proponer cómo se abordarán las problemáticas encontradas, especificando los procesos de gestión de servicios que se piensan llevar a cabo, e incluyendo una planificación para la implantación de la solución propuesta Contenidos En el apartado 1 se suministra un resumen ejecutivo de la propuesta de implantación. Este resumen ejecutivo está orientado a proporcionar una visión general de la solución estudiada, así como las diferentes partes que la componen: análisis de la empresa, planificación del plan de implantación y los procesos de gestión que se llevarán a cabo. También acuerdos de calidad de servicio y la descripción de las herramientas que se emplearán. En el apartado 2 se describe el plan de implantación, comenzando por el análisis actual de la empresa, pasando por la identificación de problemas que hacen que GXI no pueda disfrutar de unas infraestructuras de soporte de TIC que le permitan utilizarlas de forma eficiente y cuyos problemas no impacten de forma definitiva en su negocio, y finalizando con una planificación sobre la implantación de diferentes procesos basados en la metodología ITIL que permitan solucionar los problemas identificados. En el apartado 3 se definen en detalle los procesos de gestión de los servicios TIC de GXI, realizando una descripción de todas las partes que se contemplan tener en cuenta en el apartado 2. Concretamente se detallan los escalones de resolución de incidencias, se definen los procesos de Service Desk y la gestión de incidencias, problemas y cambios. Se realiza diseño inicial de la CMDB y de una propuesta de organización del personal, así como la redacción del SLA de uno de los servicios que soportan las infraestructuras de telecomunicación (concretamente el servicio de correo electrónico). En el apartado 4 se ponen en relieve dos herramientas propuestas para la monitorización de dispositivos, aplicaciones y servicios, ambas de libre distribución, como son Netmrg y una aplicación propia basada en el estándar WBEM. De la misma manera, en el apartado 5 se muestra la aplicación KEOPS, que en su caso proporciona la capacidad de gestionar el flujo de trabajo, muy útil en el seguimiento y registro de resolución de incidencias, problemas y cambios. En el apartado 6 se realiza un estudio de una alternativa, que consistiría en la posibilidad de subcontratar los diferentes procesos descritos en el apartado 3, dejando de la mano de una empresa especializada en gestión de redes la gestión de las infraestructuras TIC de GXI, de forma parcial o total, pero siempre que dicha empresa ofrezca una solución que afronte todos los requisitos que desde este documento consideramos necesarios. Como ejemplo se incluye un SLA sobre el servicio de Service Desk que GXI firmaría con la empresa subcontratada, en caso de escoger esta posibilidad. Finalmente, en el apartado 7 indicamos las referencias bibliográficas y electrónicas usadas para la elaboración de este documento. A Team 6/133
7 0.3. Audiencia del estudio Este documento está dirigido a la dirección y el departamento de Sistemas de Información y Comunicaciones de GXI, para que estudie nuestra propuesta de implantación de procesos para la gestión de las infraestructuras TIC. A Team 7/133
8 1. Resumen ejecutivo El presente documento especifica la propuesta de implantación de procesos basados en ITIL para la gestión de las infraestructuras TIC de GXI, S.A. Concretamente se realiza una propuesta de implantación de estos procesos de acuerdo a unos objetivos claramente definidos, a raíz de un estudio de la situación actual de la empresa. Se contempla la implantación de un Service Desk, centralizado desde el punto de vista de sistemas, pero distribuido por lo que a contacto con el cliente se refiere, garantizando un servicio de 24x7 y de forma global para todas las sedes de la empresa, y con personal de atención en aquellas sedes- donde el idioma preferente no es el castellano. Este Service Desk compondrá el primer escalón definido para la resolución de incidencias, que está formado por un total de tres (más un cuarto que correspondería a los proveedores). Para que GXI S.A. pueda ejercer una gestión inteligente y eficiente sobre la infraestructura TIC, y por lo tanto sobre los servicios que ésta soporta, se debe definir una metodología que aparte de permitir una reacción concreta y predefinida ante los problemas, sea capaz de detectarlos antes de recibir notificación de los usuarios, dotando nuestro sistema de desencadenar procesos de incidencias de forma proactiva. De esta manera, y para una reacción ante problemas o incidencias del departamento de forma reactiva, se dispondrá de un Service Desk, el cual tendrá definidos unos parámetros de actuación. Para una reacción proactiva, en cambio, se dispondrá básicamente de dos herramientas de monitorización de libre elección, como lo son Netmrg y una aplicación propia basada en el estándar WBEM. De esta forma el departamento de sistemas tendrá la capacidad de detectar la mayoría de posibles problemas que puedan ocurrir, estando además preparados para resolverlos. De la misma manera, el sistema de gestión contemplará acciones para detectar problemas de fondo y, además, permitir gestionar procesos de cambio que se puedan desencadenar a raíz de incidencias, problemas u otros (como ampliaciones de la infraestructura a la hora de abrir futuras nuevas sedes, entre otros). El segundo nivel del escalado de gestión se encargará de resolver todas aquellas incidencias que no estén contempladas en el primer (con lo que conseguimos agilidad en el Service Desk), y tendrá también la competencia de sugerir posibles problemas de fondo. Al igual que en el primer escalón, el personal de este nivel tendrá todos los marcos de actuación definidos y acotados, y conocerá sus competencias dentro del proceso de gestión. Dispondrán de información sobre cómo resolver las incidencias que se puedan dar en la red. En el caso de enfrentarse a una incidencia cuyo origen y solución no está definido o no se conoce, el flujo llegará al tercer nivel del escalón, formado por especialistas. Estos se encargarán de añadir incidencias no contempladas a las listas de responsabilidades de los dos primeros niveles, definiendo los parámetros de actuación y los tiempos e actuación. También se encargarán de detectar problemas de fondo, a partir de un seguimiento periódico del historial de incidencias ocurridas. Todas estas actividades y coordinaciones entre escalones estarán supervisadas por un responsable, el gestor de incidencias, y en cualquier caso tendrá la potestad para alterar el flujo natural de las incidencias, de facilitar el contacto entre expertos y proveedores cuando sea necesario, y en general de supervisar los procesos de gestión de incidencias, problemas y cambios, tomando parte de forma directa en todas las decisiones más allá de lo establecido. Todo el sistema de información, que contendrá los inventarios, manuales de instalación y configuración, datos sobre usuarios, historial de incidencias, problemas y cambios, known errors, y los parámetros de actuación (en dos idiomas cuando se estime necesario), estará centralizado en la sede de Barcelona, y duplicado en la sede de Madrid, desde donde se realizarán backups periódicamente. A Team 8/133
9 Para la consecución de la implantación de estos procesos, que permitan reducir el alto coste del mantenimiento de las infraestructuras TIC y que, a su vez, la doten de la capacidad de reaccionar ante problemas unos tiempos determinados, el grupo A3-Team propone un plan de implantación, que consta de tres fases y contempla una duración total de 14 meses. De esta forma, El departamento de Sistemas y Comunicación podrá garantizar el nivel de calidad que se debe ofrecer para responder a las necesidades del negocio. A Team 9/133
10 2. Plan de implantación de procesos ITIL 2.1. Estudio de la situación actual Estado actual de la empresa En una visión general de la empresa, vemos que: Hay un creciente número de clientes, a los cuales se les ha vendido la operativa a través de Internet como un valor añadido. Hay clientes empresariales potenciales pero que acuerdos de nivel calidad. Se está viviendo un proceso de expansión geográfica, con apertura de nuevas sedes en nuevos mercados. El 70% del personal está en oficina (40% trabajando en PC de sobremesa y 30% con portátil; estos últimos en aumento). Está prevista una experiencia piloto en que el 15% trabajaran desde casa con portátil y conexión ADSL. El 30% del personal trabajan mayoritariamente fuera de oficina, con portátil con Wi-Fi (los peritos, además con PDA). Se dispone de una plantilla de 500 personas. Su distribución es: Por sedes: Barcelona 300, Madrid 100, A Coruña 50, Lisboa 50, Buenos Aires 50 (previsto), Hong-Kong 50 (previsto). Por departamentos: Dirección 20, Recursos 100, Marketing 20, Comercial 100, Gestión de pólizas 200, Atención al cliente 50, TIC 60. Esta descripción muestra que el personal que se ocupa de la gestión de la infraestructura que soporta los servicios se encuentra considerablemente repartido entre las diferentes sedes de GXI Problemas internos detectados A raíz de los estudios realizados sobre el funcionamiento interno actual dentro de la empresa, se han detectado diversos problemas: Poca disponibilidad de los sistemas informáticos, con la consecuente pérdida de clientes. Averías en el sistema de gestión de pólizas, lo que ocasiona una pérdida de días u horas de trabajo laboral. Al atender una avería a veces el interlocutor no es el adecuado, haciendo repetir al cliente. El director de Sistemas dice que es por rotación de personal y se pierde experiencia. Y que están desbordados como para hacer informes detallados. La no disponibilidad de los sistemas y los cortes durante la tragedia del maremoto originaron pérdidas. El operador de telecomunicaciones dice que no hubieron cortes. Lentitud en el acceso a las máquinas que albergan BBDD por el alto crecimiento experimentado en los últimos meses. La expansión geográfica hace que se instalen nuevas versiones de los productos de software, con riesgos de falta de interoperatividad y fallos inesperados A Team 10/133
11 La inundación en Barcelona produjo la no disponibilidad de los sistemas durante días. El SLA no ha sido respetado por operador de telecomunicaciones pero éste lo desmiente. Discrepancias en el número de licencias de software con Microsoft. Incapacidad de decir a qué servicios afectarán las paradas de mantenimiento Los comerciales que tienen disco duro lleno ven tardar días a que se les restablezca uno nuevo. Los SLAs de la competencia garantizan tiempos de tramitación y establecen penalizaciones en caso de incumplimiento; esto en el sector empresarial. Sin embargo en GXI no hay compromisos internos entre departamentos, con lo cual de momento es imposible igualar la oferta Conclusiones Una vez conocidos los problemas internos concretos que han surgido y la situación de la empresa en cuanto a recursos humanos y materiales y modo de funcionamiento, se procede a realizar un análisis de la problemática de fondo que origina los problemas y amenazas detectados. Todos ellos, aunque relacionados, se han clasificado en tres niveles (de mayor, 1, a menor, 3), según el impacto que tienen sobre el negocio de GXI. En resumen, los problemas detectados se podrían sintetizar en los siguientes puntos: El sistema de infraestructura de tecnologías de la información y comunicación de GXI sigue un patrón de comportamiento reactivo ante los problemas que va surgiendo. (1) Los mecanismos de funcionamiento de GXI no están bien organizados y esto provoca que los mismos problemas o incidencias se repitan, no haya un tiempo estándar establecido para resolver los mencionados problemas, etc. (2) Las diferentes personas que trabajan con los sistemas TIC no tienen bien delimitadas sus funciones, y esto provoca problemas a la hora de resolver problemas en el sistema y a la hora de atender las incidencias que los clientes nos hagan llegar. De esta forma, cualquier circunstancia ante la cual haya que actuar difícilmente será cubierta por la persona más indicada para ello. (3) Al no ser capaces de detectar de forma eficiente los problemas en nuestro sistema, ni tampoco de registrarlos de forma ordenada y consciente, no se tienen bases para medir los niveles de calidad que nuestros proveedores nos dan, y por lo tanto de poder reclamar justificadamente el nivel de calidad de servicio contratado, defendernos de posibles engaños, etc. (1) GXI no es capaz de establecer un nivel de calidad de servicio y cumplirlo de forma garantizada. (1) El hecho de que la gestión de todos los sistemas no esté centralizada sólo hace que la capacidad de crecimiento y expansión de la empresa resulte más compleja, y por lo tanto queda limitada. (3) Al haber tanta heterogeneidad de recursos (plataformas y sistemas operativos diferentes, móviles y PDAs con conexión a Internet, variedad de aplicaciones dedicadas y otras genéricas, telefonía sobre IP prevista para un futuro, acceso cableado e inalámbrico a la red, oficinas distribuidas, etc.), se hace muy compleja la gestión del sistema por el hecho de no disponer de un sistema de gestión totalmente integrado. (1) Se observa, además, la falta de un sistema de inventariado. (1) A Team 11/133
12 2.2. Objetivos tácticos Introducción Una vez detectados los problemas de GXI asociados a las TIC, a continuación se procede a especificar objetivos y metas que nos permitan superarlos, y a su vez nos faciliten un crecimiento lo menos complejo posible en caso de ampliaciones del negocio Objetivos propuestos de gestión A partir de lo que hemos observado hasta ahora, creemos necesario establecer los siguientes procesos de gestión: Establecimiento de procesos de soporte de servicio, donde: Se establezca un punto de atención a los clientes y usuarios de los sistemas TIC de GXI, donde el sistema sea capaz de reaccionar de forma reactiva, pero ordenada. Se definirá el tipo de punto de atención al cliente resulta más adecuado (el hecho de tener oficinas repartidas en todo el planeta hace que se deba estudiar las interacciones horarias, idiomas, etc.), se establecerán las funciones del Service Desk, y se implantarán parámetros de actuación de las personas que se encarguen de ello, para conseguir una incorporación eficiente de problemas a nuestro sistema de incidencias. Se definan procesos de gestión de las incidencias, definiendo y formalizando el proceso que éstas deberán seguir, de forma que sea posible cumplir los SLAs acordados. De esta forma, se definirán flujos, donde cada uno se encargará de la resolución de un tipo de problemas. Será necesario establecer una lista donde se clasifiquen los diferentes tipos de incidencias, y al flujo al que corresponderán. Un repositorio de información se encargará de registrar las incidencias detectadas de forma reactiva (a través del Service Desk), o de forma preactiva (a través las herramientas de gestión y monitorización del sistema). Los diferentes flujos se establecerán en función de tipo de problemática y de la gravedad de la incidencia, y cada uno tendrá definidos los parámetros de actuación, donde se contemplará que cuando un grupo no sea capaz de lidiar con un problema, éste podrá transmitir la incidencia a otro grupo. Así se podrá conseguir un escalado en la resolución de incidencias, estableciendo fases, responsables en curso. El repositorio de información guardará registro sobre el ciclo de vida de cada incidencia, de forma que GXI sea capaz de saber con certeza el tiempo de actuación, y actuar en consecuencia de forma que pueda alcanzar el nivel de calidad de servicio acordado con sus clientes, y detecte si el proveedor le está cumpliendo el que acordaron. Se implanten procesos de gestión de problemas, que permitan analizar y definir problemas concurrentes a partir de una serie de repetición de incidencias relacionadas o referentes al mismo problema. De esta forma GXI será capaz de avanzarse en tiempo a algunos problemas que puedan acontecerle, y esto le permitirá en numerosas ocasiones evitar la no-disponibilidad de algún servicio. Se habiliten procesos de gestión de configuración, que permitan tener de forma accesible los elementos que forman nuestra infraestructura. De la misma forma que el resto, el repositorio de información deberá guardar constancia de todos los elementos hardware y software del sistema (elementos de red, PCs, servidores, etc. Así como el software instalado en cada uno de ellos). Con esta medida se tendrá de forma muy precisa el número de licencias usadas, así como una fuente fiable valiosa, muy útil a la hora de realizar la sustitución de equipos o programas (las configuraciones están registradas). Estas medidas resultarán muy útiles teniendo sucursales en diferentes continentes. A Team 12/133
13 Se faciliten procesos de gestión de cambios, donde se registren las adaptaciones, mejoras, ampliaciones, etc. sobre los elementos hardware y software que componen nuestro sistema. En la práctica equivaldrá a guardar información histórica sobre la información de configuración (donde, además de la actual, se puedan observar las diferencias respecto anteriores versiones de los sistemas). Establecimiento de procesos de entrega de servicios, que incluirá la gestión de: Niveles de servicio (SLAs). Para ello será necesario conocer los tiempos de actuación a los que puede responder GXI. Los SLAs de GXI contemplarán compromisos con respecto a la entrega de servicio (aspectos sobre el tiempo entre el que un cliente contrata un nuevo servicio y cuándo dispone de él, así como medidas de contingencia, punto de contacto, etc.), sobre el mantenimiento del servicio (disponibilidad de la que disfrutará de forma garantizada, tiempo de resolución de averías/problemas, parámetros de calidad de servicio garantizados como anchos de banda a ofrecer, u otros-, y contingencias asociadas), y sobre los precios que se cobrarán por el servicio y la variación temporal de los precios sobre el mismo. Disponibilidad de los servicios que se ofrecen, que se conseguirá regulando y estabilizando el tiempo de resolución de averías y problemas, así como el de nuestros proveedores. Continuidad de servicio, que nos permita su suministro ante eventualidades. Esto es, conocer la infraestructura hasta el punto de conocer sus puntos débiles, y nos permita establecer medidas de contingencia para cuando se crea necesario (son permisibles fallos del suministro eléctrico o de otro tipo, cómo afecta a nuestra disponibilidad, y medidas a tomar al respecto, por ejemplo). Por último, establecimiento de procesos para: Gestionar la infraestructura de información y comunicaciones (equipos y servicios de telecomunicaciones que soportan los servicios a los clientes), y la de las aplicaciones que permiten ofrecer los diferentes servicios, mediante las herramientas NETMRG y una aplicación basándose en el estándar WBEM. Estas herramientas nos permitirán reaccionar de forma proactiva, y generarán automáticamente incidencias a partir de la detección de problemas en dispositivos o aplicaciones. Gestionar la seguridad de los sistemas y la confidencialidad de los datos de los clientes Plan de trabajo Introducción En este apartado se procede a describir el plan de actividades a realizar para poder alcanzar los objetivos descritos con anterioridad, así como las fases del proceso de implantación, lo que contempla cada una y sus metas. En la primera fase, se especificarán las tareas que sirvan como medida temporal para el funcionamiento del departamento de TIC, resolviendo, de forma parcial y provisional, los problemas que afectan directamente a la interacción con el cliente y la gestión de los problemas más inmediatos, especialmente relacionados con la gestión de incidencias. La segunda fase será la principal, y contempla la cobertura de la mayoría de los objetivos descritos con anterioridad. Se hará del sistema de gestión de GXI un sistema estable y eficiente, que permita abordar gran parte de las problemáticas detectadas. Se establecerán los procedimientos que permitirán detectar y gestionar de forma proactiva las incidencias, así como la solución de problemas que vayan repitiéndose, distribución de personal, etc. A Team 13/133
14 En la tercera fase, finalmente, se contempla la cobertura total de objetivos, cerrando los que se cubrieron parcialmente en la segunda y abordando los últimos. Por ejemplo, se acabarán de redondear algunos aspectos de mejora continua, así como posibles mejoras en la seguridad. En resumen, en la primera fase se establecerán medidas de funcionamiento temporal, durante la implantación del proyecto, mientras que la segunda fase abarcará la consecución de los principales objetivos de gestión. En una tercera fase se acabarán de abordar otros aspectos de gestión aislados y menos urgentes. Es oportuno añadir que para las diferentes tareas descritas a lo largo de las tres fases propuestas se cuenta con la participación del personal del departamento de sistemas de información y comunicaciones de GXI incluidas en los recursos de cada tarea-, con el fin de poder conseguir de la mejor forma posible el análisis, y el posterior despliegue de los sistemas propuestos, con el valor de que se sientan partícipes e integrados en el proceso de cambio, y lleguen a la fase de formación con nociones sobre el futuro plan de gestión ª fase del plan En esta fase se tiene previsto realizar un sistema provisional de resolución de incidencias, donde, una vez se hayan definido los flujos de trabajo y la clasificación que seguirán las incidencias, permitan vía la resolución de las mismas, incluyendo cada paso que se realice. De esta forma, seremos capaces de organizar la resolución de incidencias al mismo tiempo que conocemos de primera mano los tiempos de resolución, necesarios para la definición de los SLAs, en la segunda fase. La medida del seguimiento de incidencias por se aplicará de forma temporal, hasta que se establezca una herramienta adecuada para su seguimiento, y una persona se encargará de realizar una supervisión sobre los procesos, de tal forma que sea posible especificar un listado de incidencias, y cuánto tiempo se emplea en resolverlas (aproximadamente). De la misma manera, se establecerán responsables para la resolución de cada clase de incidencias, quién abrirá incidencias a partir de las llamadas de los clientes, y las reenvíe a quien corresponda, y otro (u otros) responsables que se encarguen de la apertura de incidencias a partir de los sistemas de monitorización disponibles. Otra/s personas se encargarán de registrar el tiempo de resolución manteniendo contacto con cada uno de los grupos así como su supervisión general, mientras otras personas se encargan de notificar a los usuarios del servicio (clientes o empleados) que la incidencia ha sido resuelta. Tareas: Identificador: 1.1 Duración: 8 días Recursos: 8 personas Actividad: Clasificación de incidencias Descripción: - Estudio de los servicios que el sistema TIC soporta y ofrece. - Listado de problemas comunes asociados a los diferentes servicios. - Clasificación de incidencias según gravedad y servicio. Requiere: - Hitos: Reunión con representantes de los diferentes colectivos representativos que usan los servicios TIC (peritos, atención al cliente, sistemas, etc.). Salidas: Pauta de clasificación de las incidencias a contemplar por el sistema de gestión. Lista y caracterización de servicios. A Team 14/133
15 Identificador: 1.2 Duración: 55 días Recursos: 10 personas Actividad: Inventario provisional Descripción: - Realización de un inventario de equipos y software disponibles en la actualidad. - Recopilación de los manuales de los que se dispongan. Requiere: - Hitos: - Salidas: Inventario general Identificador: 1.3 Duración: 15 días Recursos: 5 personas Actividad: Adecuación de la plantilla disponible Descripción: Estudio sobre la capacidad, experiencia y función actual de cada una de las personas que trabajan sobre el sistema, a fin de encontrar el puesto de trabajo óptimo para cada uno de ellos en el funcionamiento del departamento, una vez implantados los procesos de gestión. Se contemplan estudios de expedientes y entrevistas personales. Requiere: - Hitos: - Reuniones individuales con el personal de TIC - Una vez completadas todas las tareas anteriores, se alcanza el hito de recopilación de datos. Salidas: Listado donde se refleje lo que aporta cada trabajador a la empresa. Identificador: 1.4 Duración: 5 días Recursos: 8 personas Actividad: Flujos de resolución de incidencias Descripción: Descripción sobre los diferentes caminos que puede seguir una incidencia desde que se detecta hasta que se resuelve. Se contempla la definición de los parámetros que deberán incluir las fichas sobre incidencias de tal forma que quede constancia del tiempo que ha dedicado cada persona a la incidencia, problemas detectados, por qué ha traspasado la responsabilidad a otra persona si la pasa-, etc. Estas fichas consistirán en un o un fichero adjunto que se pasará vía de responsable en responsable (esta medida es temporal, hasta que se implante una herramienta de workflow). Requiere: 1.1, 1.2, 1.3 Hitos: - Salidas: - Documento que detalle los diferentes flujos de resolución de incidencias. - Patrón de ficha asociada a las incidencias. A Team 15/133
16 Identificador: 1.5 Duración: 10 días Recursos: 8 personas Actividad: Asignación de responsabilidades Descripción: - Descripción de quién se encarga de qué durante el despliegue posterior del proyecto, de acuerdo con el estudio sobre el equipamiento disponible, los problemas que se pueden encontrar y el perfil de cada trabajador. - Persona/s que se encargarán del contacto con los usuarios y clientes, quién/es se encargarán de generar incidencias a partir de la monitorización del sistema, responsable/s de cada área de actuación sobre las incidencias, quién/es informarán al usuario sobre el éxito en la resolución, y quién/es realizarán el seguimiento de estos pasos y el estudio estadístico asociado. La misma persona que atienda las incidencias asignará éstas a los diferentes ingenieros y técnicos según un patrón fijo y éstas recibirán la supervisión general de un responsable máximo del departamento. Requiere: 1.4 Hitos: Reuniones individuales con el personal, donde se le informe de sus nuevas funciones y responsabilidades (detallado también por escrito). Salidas: - Identificador: 1.6 Duración: 15 días Recursos: 6 personas Actividad: Toma de medidas en la situación actual Descripción: Recopilación sobre la cantidad y el tipo de incidencias que se producen, el tiempo de resolución de incidencias, el tiempo de realización de cambios requeridos por un cliente sobre un servicio, tiempo de alta de un servicio a un cliente. Requiere: 1.5 Hitos: Fin de la fase 1 Salidas: Informe donde se reflejen datos estadísticos y conclusiones extraídas sobre la gestión de las TIC. A Team 16/133
17 ª fase del plan En esta segunda fase vamos a establecer todos aquellos procedimientos que nos van a permitir alcanzar el grueso de los objetivos que nos hemos propuesto. En primer lugar vamos a intentar concretar al máximo los objetivos y ver si nuestro plan es coherente con los datos obtenidos hasta ahora. Acto seguido se van a recopilar más datos, que nos permitirán desarrollar el resto de actividades con coherencia. Como actividades primordiales tenemos, en un primer grupo, el estudio del Service Desk y la descripción de procesos que harán posible el soporte de los servicios, teniendo como figura principal la gestión de incidencias, problemas y cambios (y por tanto también el modelo de almacenamiento de datos). Para poder establecer estos procesos habremos definidos previamente unos roles, que representarán las personas que van a llevar a cabo estos procesos, de qué manera, con qué responsabilidades y manejando qué datos. Como segundo grupo se pueden distinguir aquellas actividades que tienen como objetivo la implantación de los diferentes componentes de software (Keops, Netmrg, Wbem) que se han visto adecuados para poder mejorar el actual sistema de gestión de la empresa, con sus correspondientes planes de pruebas. Habrá planes de pruebas para cada paquete software individual, en modo caja blanca (pruebas realizadas por los instaladores), y un plan de pruebas integral más amplio, realizado por becarios. Finalmente cabe destacar que, finalmente, se desarrollarán tareas para la documentación de procesos y software, formación de personal y elaboración de estadísticas. Tareas: Identificador: 2.1a Duración: 15 días Recursos: 8 personas Actividad: Estudio de las aplicaciones actuales Descripción: - Se recopilará toda la información sobre las aplicaciones: qué personas las dominan como usuario o como desarrollador, manuales de uso, instalación u otros, garantías, servicio técnico, etc. - Se estudiará la idoneidad de las aplicaciones que soportan los servicios ofrecidos a nuestros clientes y usuarios, con especial énfasis en la aplicación a medida que soporta altas y bajas de usuarios, modificación de las condiciones de servicio, etc. Se estudiará la posibilidad de herramientas más estandarizadas o continuar con la actual si hay garantías. Requiere: 1.6 Hitos: - Reuniones con responsables y desarrolladores de software. Salidas: - A Team 17/133
18 Identificador: 2.1b Duración: 15 días Recursos: 8 personas Actividad: Estudio de los equipamientos actuales Descripción: - Se recopilará toda la información sobre los equipamientos: qué personas los dominan, manuales, garantías, servicio técnico, etc. - Se estudiará la idoneidad de los dispositivos que soportan los servicios ofrecidos a nuestros clientes y usuarios. Se harán RFPs para proponer la adquisición de nuevos equipos y de qué características para el soporte de las nuevas aplicaciones y para soportar mejor las actuales. Requiere: - Hitos: - Salidas: RFPs Identificador: 2.1c Duración: 15 días Recursos: 12 personas Actividad: Repositorio de manuales Descripción: - Se establecerán unos requisitos que deben cumplir estos manuales (ej. el manual de usuario debe incluir un apartado de FAQs). Si los manuales no son suficientemente explícitos o no cumplen con los requisitos, el departamento elaborará manuales a partir de la información que se obtenga de esta y otras fuentes, para que estén a disposición del resto del departamento. - Para los elementos hardware, se requerirán manuales de configuración y mantenimiento - Para los elementos software, se requerirán manuales de despliegue (incluyendo instalación y configuración), de mantenimiento y de usuario. Requiere: 2.1a, 2.1b Hitos: Estudios preliminares realizados Salidas: Documentos de usuario y de desarrollador, en formato digital y disponibles en un servidor. Identificador: 2.2 Duración: 12 días Recursos: 12 personas Actividad: Inventario definitivo Descripción: Elaboración de un inventario a partir del inventario hecho en la primera fase, que no sólo incluirá los equipos (PCs, portátiles, PDAs...) sino sus componentes internos y dispositivos, así como los diferentes sistemas operativos y aplicaciones, ya sean de carácter genérico o específicas, su configuración, y las garantías, las licencias u otros. En caso que un manual encontrado no cumpla con los requisitos especificados anteriormente se complementará o se editará un nuevo manual. Requiere: 2.1c Hitos: - Salidas: Documento con un inventario detallado de equipamiento, dispositivos y software en formato digital. A Team 18/133
19 Identificador: 2.3 Duración: 7 días Recursos: 5 personas Actividad: Elementos a monitorizar Descripción: Se van a determinar razonadamente qué elementos de nuestro sistema (dispositivos, equipos, sub-dispositivos, aplicaciones, servicios...) se van a monitorizar. Se va a determinar en qué circunstancias se van a generar alarmas y por qué. Requiere: 2.2 Hitos: - Salidas: Lista de elementos y eventos a monitorizar. Identificador: 2.4 Duración: 10 días Recursos: 12 personas Actividad: Estudio del Service Desk Descripción: - Estudio de diferentes opciones para establecer Service Desk: centralizado o distribuido, 24h u horario reducido, interacciones entre ellos si hay más de uno, si usarán la misma aplicación de gestión, estudio de una posible subcontratación. Se prevé un diseño centralizado, pues esto asegura una mayor capacidad de crecimiento e integración de sistemas y estándares de procedimientos. - Estudio de las medidas de contingencia en caso de establecerse un sistema centralizado ante la no disponibilidad del Service Desk. Preferencia frente a otros sistemas de backup. Requiere: 2.3 Hitos: - Salidas: - A Team 19/133
20 Identificador: 2.5 Duración: 30 días Recursos: 10 personas Actividad: Gestión de incidencias Descripción: - Definición del escalado en la actuación ante incidencias. Por ejemplo: primer nivel: Service Desk; segundo nivel: personal de mantenimiento; tercer nivel: grupo de expertos; cuarto nivel: actuación de los proveedores de acuerdo con SLAs. - Caracterización de los distintos roles. Qué funciones tendrá cada rol. Caracterización de las habilidades necesarias. - Definición de los procesos que permitirán detectar, registrar, procesar y concluir las incidencias que ocurran en nuestro sistema, proveyéndonos tanto de medidas reactivas como proactivas, usando las bases de datos y aplicaciones específicas. Abarca tanto la detección proactiva como la reactiva. Esta definición incluirá los parámetros de actuación en cada etapa del proceso, p.e. listado de preguntas previsibles acciones y respuestas a dar en la primera etapa del proceso recepción de notificación de incidencia ; uso de los SLAs con nuestros proveedores; acciones a realizar al haber solucionado una incidencia, etc. - Qué perfiles de personas se encargarán de qué procesos y con qué responsabilidades. Se definirá cómo y por qué se podrán transferir las incidencias a otros trabajadores. Se establecerá también una jerarquía de responsables. - Definición de los formularios a usar, qué datos se van a registrar y cómo se van a comunicar entre el personal, qué preguntas se van a hacer a los clientes. Requiere: 2.4 Hitos: - Salidas: Informe sobre estos dos tipos de flujos. Identificador: 2.6 Duración: 18 días Recursos: 10 personas Actividad: Gestión de problemas graves o de fondo Descripción: Ídem del anterior pero definiendo los procesos que van a permitir: - Detección y registro de incidencias repetitivas, es decir, a las debidas a un problema de fondo. Quién se encarga de ellas y cómo se detectan. - Plan de actuación ante desastres y problemas urgentes, es decir, medidas de contingencia: duplicidad de sistemas. Transmisión del mando y control de un CAC a otros CAC en caso de caída de éste. Conmutación a sistemas de backup y SAI. Requiere: 2.4 Hitos: - Salidas: Informe sobre estos tipos de flujos A Team 20/133
09/2005 Certificado ASP eps Network Services Certificado ASP Especificación de prestaciones y servicios Válidas para Software Versión de software eps Network Services 4.1 eps Network Services, Especificación
e Proyecto Gestión de Redes y Servicios PRÁCTICA ARIS Hugo Casadevall Bausela Laura Denia Samper Jara Pascual Soldevilla Jordi Recio Prieto Marc Serravinyals Castellà Control de cambios Versión Autor Fecha

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución