SinCity 2º Borrador Grupo E Jurgi Barreña Patricia Durán Ignasi Pujals Roger Rossell Alberto Vílchez 1 INDICE 1. ESTUDIO DEL PLAN DE IMPLANTACIÓN .................................................. 5 1.1. Objetivos estratégicos ......................................................................... 5 1.1.1. Actores ............................................................................................ 5 1.1.2. Objetivos ......................................................................................... 6 1.2. Situación actual ................................................................................... 8 1.2.1. Debilidades y problemas ................................................................... 8 1.2.2. Fortalezas y oportunidades ............................................................. 10 1.3. Objetivos tácticos .............................................................................. 13 1.4. Plan de trabajo.................................................................................. 14 1.4.1. Implantación ITIL en Excalibur ........................................................ 14 1.4.1.1. Implantación Gestión de Incidencias ............................................. 17 1.4.1.2. Implantación Gestión de Problemas .............................................. 18 1.4.1.3. Implantación Service Desk ........................................................... 18 1.4.1.4. Implantación Gestión de Configuración ......................................... 20 1.4.1.5. Implantación Gestión de Seguridad ............................................... 20 1.4.1.6. Periodos de prueba y correcciones ................................................ 21 1.4.2. Implantación ITIL en el resto de casinos .......................................... 22 1.4.3. Recursos ........................................................................................ 25 1.5. Evaluación ........................................................................................ 26 2. SERVICE DESK ..................................................................................... 30 2.1. Objetivos Service Desk ...................................................................... 30 2.2. Métricas Service Desk ........................................................................ 30 2.3. Tipo Service Desk .............................................................................. 31 2.4. Tecnologías Service Desk ................................................................... 31 2.5. Funciones y responsabilidades Service Desk ........................................ 32 2.5.1. Funciones del Service Desk ............................................................. 32 2.5.2. Gestión de escalabilidad .................................................................. 32 2.6. Perfil del personal.............................................................................. 33 2.7. Procesos del Service Desk .................................................................. 33 2.7.1. Técnica estructurada de interrogación ............................................. 33 2.7.2. Identificación y detalles del cliente .................................................. 34 2.7.3. Análisis de la carga de trabajo ......................................................... 34 2.7.4. Registro de incidencias ................................................................... 35 2 3. GESTIÓN DE INCIDENCIAS................................................................... 36 3.1. Introducción ..................................................................................... 36 3.2. Niveles de soporte ............................................................................. 36 3.3. Incidencias reactivas ......................................................................... 38 3.3.1. Primer nivel.................................................................................... 38 3.3.2. Segundo nivel ................................................................................ 41 3.3.3. Tercer nivel .................................................................................... 41 3.4. Incidencias proactivas ....................................................................... 42 3.4.1. Primer nivel.................................................................................... 42 3.4.2. Segundo y tercer nivel .................................................................... 43 3.5 Ciclo de vida de las incidencias ............................................................ 43 3.6. Estado de las incidencias ................................................................... 44 3.7. Roles en la gestión de incidencias ...................................................... 44 3.7.2. Personal de la gestión de incidencias ............................................... 45 3.8. Actividades de la gestión de incidencias .............................................. 45 3.8.1. Identificación y registro de la incidencia ........................................... 45 3.9. Tipo de incidencias ............................................................................ 47 3.10. Gestión de problemas ...................................................................... 53 3.10.1. Diferenciación entre problema e incidencia ..................................... 53 3.10.2. Actividades control reactivo de problemas ...................................... 53 3.10.3. Identificación y registro del problema ............................................ 54 3.10.6. Control de errors .......................................................................... 57 3.10.7. Gestión de Problemas Proactivos ................................................... 60 3.10.8. Informes de históricos .................................................................. 62 3.10.10. Lista de posibles problemas ......................................................... 63 4. GESTIÓN DE LA CONFIGURACIÓN ........................................................ 66 4.1. Objetivos .......................................................................................... 66 4.2. Implementación de la gestión de configuración ................................... 66 4.2.1. Análisis de los sistemas existentes ................................................... 66 4.2.2. Elección de las herramientas a utilizar.............................................. 66 4.2.3. Diseño de la CMDB ......................................................................... 69 4.2.4. Implementación de la CMDB ........................................................... 70 4.3. Roles, funciones y responsabilidades .................................................. 70 5. GESTIÓN DE SEGURIDAD ..................................................................... 72 3 5.1. Introducción ..................................................................................... 72 5.1.1. Requisitos de Seguridad .................................................................. 73 5.2. Medidas de la gestión de seguridad .................................................... 73 5.2.1. Control .......................................................................................... 73 5.2.2. Planificación ................................................................................... 74 5.2.3. Implementación ............................................................................. 75 5.2.4. Evaluación ..................................................................................... 76 5.2.5. Mantenimiento ............................................................................... 77 5.3. Factores en la gestión de seguridad.................................................... 78 6. HERRAMIENTAS UTILIZADAS ............................................................... 80 6.1. Help Desk, HP Openview Service Desk................................................ 80 6.1.1. GESTIÓN DE INCIDENCIAS ............................................................. 80 6.1.2. GESTIÓN DE PROBLEMAS ............................................................... 80 6.1.3. GESTIÓN DE CONFIGURACIONES ................................................... 80 6.2. Monitorización, NETMRG .................................................................... 81 6.3. Gestión del nivel de servicio, NimBus .................................................. 82 ANNEX 1 SLA’S ........................................................................................ 87 4 1. ESTUDIO DEL PLAN DE IMPLANTACIÓN 1.1. Objetivos estratégicos En primer lugar, para realizar correctamente el plan de implantación se deben definir los objetivos de negocio a alto nivel, de forma que todo el mundo sea capaz de entenderlos. En este caso nos servirá para comunicar a todo el personal implicado en la implantación de ITIL en los casinos MGM qué es lo que se debe conseguir con ello y de esta forma saber en todo caso la dirección que lleva el trabajo común de MGM y SinCity. Para que la comunicación de los objetivos estratégicos tenga éxito y éstos sean asimilados por todo el personal de MGM, se deberán transmitir los objetivos de forma personalizada a cada departamento de la empresa. El claro motivo es la función específica que cada departamento desempeña y, por tanto, el objetivo de cada uno. Así pues, en un primer lugar se definen los actores que participaran en el proceso de implantación. 1.1.1. Actores Los principales actores implicados en la actividad empresarial de cada uno de los casinos MGM son los mencionados a continuación: Dirección Operaciones Recursos humanos Marketing Finanzas Sistemas de información y comunicaciones La relación entre departamentos es la típica de toda empresa, con la peculiaridad de que la mayoría no están en contacto directo. Es decir, el personal de los departamentos de RRHH, marketing y finanzas pueden compartir lugar de trabajo pero con toda seguridad no lo harán con el personal de operaciones o de sistemas. No obstante, su situación física no dista más de un número pequeño de plantas, cosa que puede permitir una relación entre departa La relación entre departamentos es la típica de la mayoría de empresas. Todos los departamentos están en el mismo edificio (casino) pero a su vez separados por plantas, a excepción de la dirección, que es un poco anárquica en este aspecto. Además, todos los casinos se encuentran en la misma calle a pocas manzanas de distancia, factor también a tener en cuenta en el momento de implantar los procesos de ITIL. Así pues, la situación que nos ocupa se puede ver en la siguiente figura: 5 LUXOR EXCALIBUR Dirección Dirección GRAND LAS VEGAS RRHH Marketing Finanzas Operaciones Sistemas Sistemas RRHH Marketing Finanzas Operaciones Dirección Dirección ISLA DEL TESORO Dirección RRHH Marketing Finanzas Operaciones Sistemas Sistemas RRHH Marketing Finanzas Operaciones Sistemas RRHH Marketing Finanzas Operaciones BELLAGIO La figura anterior que muestra la relación entre departamentos y sedes tanto física como virtual servirá como posible modelo de comunicación así como de flujo de información a tener en cuenta para diseñar los procesos que se crean convenientes. La situación física de cada actor tiene especial importancia para el departamento de sistemas de información y comunicaciones, ya que mantiene relación con el resto de departamentos y debido a las tareas que desempeña puede requerir el desplazamiento para solucionar problemas del resto de departamentos. Por otro lado, para el conseguir el buen funcionamiento de los casinos también intervienen un conjunto de actores externos que son los encargados de proporcionar las comunicaciones tanto internas de cada casino como externas. En este caso particular, será necesario negociar niveles de servicio para asegurar el cumplimiento de los objetivos que se definan. 1.1.2. Objetivos La definición de objetivos estratégicos tiene como finalidad la justificación (a todos los actores mencionados en el punto anterior) de el plan de implantación de ITIL que se va a llevar a cabo. De esta forma, se le deberá dar sentido al plan para cada uno de los actores implicados demostrando que las mejoras que se introducirán van a beneficiarles. Así se consigue añadir interés y motivación en los participantes del proceso de cambios que se va a iniciar. 6 En la siguiente tabla se indican los objetivos y beneficios que se desean obtener con la implantación de los procesos ITIL: Actores Dirección Objetivos / Beneficios - Incremento de ingresos al incrementar la disponibilidad de los servicios. - Fidelización de clientes mediante un trato personalizado derivado de un sistema de seguimiento de clientes más fiable. - Fortalecimiento del servicio y diferenciación del resto de casinos. - Formación de personal más profesional. Operaciones - Soporte informático de mayor calidad. RRHH - Aumento de productividad gracias al aumento de Marketing disponibilidad de los servicios informáticos. Finanzas - Incremento de satisfacción con el servicio informático. - Menor tiempo de resolución de incidencias. Sistemas - Aumento de la productividad, descenso de papeleo burocrático. - Mayor efectividad en el trabajo realizado, aprovechamiento del tiempo. - Acotación de responsabilidades y funciones. 7 1.2. Situación actual A partir del análisis DAFO, se pueden identificar una serie de debilidades que puedan darse debido a posibles problemas en la organización o en el sistema. Asimismo, se ven reflejadas también las fortalezas y las oportunidades que permiten reforzar el negocio frente a las amenazas y los problemas. 1.2.1. Debilidades y problemas A continuación, se da una relación de las debilidades extraídas a partir del análisis mencionado, indicando detalles sobre los problemas que las causan y las consecuencias que pueden acarrear en el caso de que se produzcan, así como una pequeña descripción. ID debilidad Descripción Detección de problemas Consecuencias D1 Pérdidas de ingresos Alguna máquina recreativa averiada. Fallos en los cajeros ATM. Servicio poco satisfactorio. Pérdidas en las ganancias obtenidas apuestas realizadas en el casino. de las ID debilidad Descripción D2 Retraso del servicio técnico para resolver incidencias en las máquinas recreativas o los cajeros. Detección de problemas Si se da un cierto número de averías al mismo tiempo es posible que sobrepase la capacidad de atención a estas por parte del servicio técnico. Molestias para los jugadores, que no pueden jugar o realizar apuestas, de lo cual se deriva una pérdida de ingresos. Consecuencias ID debilidad Descripción Detección de problemas D3 Caída de la red VPN. Fallos al intentar contactar con los demás casinos de la red. Consecuencias Pérdida de conexión entre los casinos, que no podrían intercambiar datos entre ellos de forma segura. ID debilidad Descripción D4 Pérdida de conectividad dentro del casino. 8 Detección de problemas Se pierde la conexión a Internet y el acceso a aplicaciones web. Consecuencias Molestias a los empleados del casino que necesiten de conexión a la red para desarrollar su labor, la cual podrían ver impedida en algún momento. ID debilidad Descripción Detección de problemas Consecuencias D5 Caída del servicio de telefonía. El servicio DECT utilizado entre los empleados quedaría inutilizado. De la misma manera no se podrían realizar llamadas al exterior. Incomunicación del personal del casino. ID debilidad Descripción Detección de problemas D6 Pérdida de clientes. Puede deberse a averías recurrentes de algunas máquinas. Consecuencias ID debilidad Descripción Detección de problemas Consecuencias ID debilidad Descripción Detección de problemas Consecuencias ID debilidad Descripción Detección de problemas Consecuencias Pérdida de ingresos. D7 Descontento entre clientes. Puede deberse a averías recurrentes de algunas máquinas o a servicios no del todo eficientes: falta de cajeros o averías de estos, por ejemplo. Puede conllevar a la pérdida de clientes, y por lo tanto a la de ingresos. D8 Bajas prestaciones de equipamiento informático. Los empleados del casino pueden encontrar que sus equipos no cubren las necesidades que se les presentan al realizar su trabajo. Entorpecimiento de la labor del personal del casino. D9 Servicio ineficiente. Los clientes no reciben el trato que deberían o encuentran dificultades para jugar. Descontento y pérdida de clientes. Tras desglosar las posibles debilidades detectadas, se puede realizar una relación de los problemas que las causan, de manera que analizando la 9 prioridad de cada uno de ellos y su complejidad, se puede hallar algún tipo de solución a cada uno de ellos para poder evitar o resolver las debilidades mencionadas. Así, primero se resolverán los problemas con la prioridad más alta que sean más sencillos, pues los que sean más complejos requerirán más tiempo, que podría haberse ganado en solventar otros de igual prioridad pero más rápidos de solucionar. ID Descripción Prioridad Complejidad Orden Debilidades solución producidas P1 Exceso de tiempo de resolución de una avería. 1 Media 2 D1, D2, D7 P2 Averías de la red del operador de telecomunicaciones contratado 2 Alta 1 D3, D4, D5 P3 Averías recurrentes P4 P5 Personal del casino poco eficiente Equipamiento poco adecuado 3 Alta 3 D1, D2, D3, D4, D5, D7, D8, D9 4 Baja 5 D1, D7, D9 5 Media 4 D8 Gracias al estudio que se ha realizado de los problemas que provocan las debilidades que pueden afectar a la buena marcha del negocio, se ve como algunos de los mencionados están interrelacionados, lo cual hace que unos deriven de otros y que al aplicar una solución al problema raíz los demás se resuelvan automáticamente, o que se facilite su erradicación. Tenemos que por ejemplo, las averías recurrentes pueden derivar en la saturación del servicio técnico para solventarlas y en un servicio poco satisfactorio de cara a los clientes. Así, el equipamiento poco adecuado también puede derivar en que el personal no sea eficiente en su trabajo. 1.2.2. Fortalezas y oportunidades Una vez que hemos visto las posibles debilidades de la empresa, pasamos a contrastarlas con los puntos fuertes que posee. El análisis de los puntos fuertes de SinCity permite ver si éstos pueden contrarrestar algunas de las debilidades detalladas con anterioridad. Las que queden pendientes, se analizará con más detenimiento el problema que las causa, para hallar la solución más adecuada y aplicarla. 10 ID fortaleza Descripción F1 Las apuestas, los juegos de mesa y los juegos de azar se han convertido en parte de ocio de las personas. Cada vez más personas acuden a este tipo de establecimientos para su diversión. Ventajas Aumento de los clientes y por lo tanto de los ingresos. ID fortaleza Descripción F2 Existe mucha gente que ha convertido este tipo de juegos en su forma de ganar cantidades pequeñas y medianas de dinero y que acuden habitualmente a este tipo de establecimientos a probar suerte. Ventajas ID fortaleza Descripción Ventajas ID fortaleza Descripción Ventajas Fidelización de clientes, al haber convertido la visita al casino en un hábito. F3 Se apuesta por la incorporación de novedosos juegos de diversos tipos en los locales para que los usuarios tengan dónde elegir, lo cual hace que resulte atractivo acudir a estos lugares en los que puede encontrar un amplio abanico de ofertas lúdicas Fidelización de clientela al ofrecer servicios y juegos que no se encuentran en otros casinos. F4 La empresa sitúa sus establecimientos en lugares con un nivel de riqueza y un índice de turismo considerablemente altos. Mayor afluencia de clientes con posibilidades de hacer apuestas más grandes. Entre las fortalezas descritas se puede ver que casi todas hacen frente a la debilidad D1, ya que casi todas ellas permiten asegurar o incrementar los ingresos. Además también permiten poner solución, al menos en parte al descontento y la pérdida de clientes (D6 y D7). Además de las fortalezas, hay que tener en cuenta también las oportunidades que encuentra SinCity, que ayudan a reforzar y orientar la estrategia del negocio. Tales oportunidades se describen a continuación: La composición de los locales hace que la idea sea rápidamente exportable a otros emplazamientos sin que conlleve nuevos y grandes diseños. Dicho de otro modo, las máquinas y demás elementos son fácilmente exportables a otros lugares. Por otro lado, la fácil convergencia de las máquinas usadas nos permite incorporar nuevos juegos o diferentes tipos de apuesta de 11 una forma rápida y sencilla, y que no conlleva cambios en hardware. La afición al juego y las apuestas presente en todo el país y especialmente arraigada en la zona de Las Vegas ofrece la posibilidad de abrir o adquirir nuevos casinos con la seguridad de que van a resultar rentables. La variedad de juegos existentes da la posibilidad de ofrecer diferentes productos muy diversos y sin que hayan sido explotados mucho por otras empresas. 12 1.3. Objetivos tácticos El fin de este análisis es encontrar soluciones a los problemas que hemos visto con anterioridad para evitar que interfieran en la buena marcha de la empresa. ID del Soluciones propuestas problema Técnicas de workaround para poder mantener el aparato averiado en funcionamiento hasta poder aplicar una solución definitiva, en el caso de que el equipo técnico se encuentre saturado por las incidencias. P1 P2 P3 P4 P5 Si el retraso se produce por otros motivos, con un nivel normal de incidencias, haría falta un replanteamiento de la estrategia a seguir en caso de averías para tratar de minimizar lo más posible el tiempo de resolución del problema. Tratar de ser proactivos, de manera que cuando se produzca la incidencia ya se sepa cuál es y cómo resolverla. Procurar tener un buen SLA con la compañía que nos asegure en caso de averías su rápida reparación. Tratar de ser proactivos, de manera que cuando se produzca la incidencia ya se sepa cuál es y cómo resolverla. Replantearse la estrategia de atención al cliente. Formar adecuadamente al personal en el uso de todos los dispositivos del casino que necesiten para desarrollar su trabajo. Renovación del equipamiento o actualización de las herramientas. 13 1.4. Plan de trabajo El plan de trabajo que se propone consiste en la planificación de las tareas y actividades que se realizarán para llevar a cabo la implantación de ITIL en los cinco casinos de MGM Mirage. Debido al tipo de negocio que nos ocupa, no se puede interrumpir la actividad de los casinos para realizar toda la implantación completa a la vez. Así pues, se ha decidido hacer una primera implantación en el casino Excalibur y posteriormente hacer la implantación en el resto de casinos. Se ha elegido a Excalibur porqué es el casino más pequeño y con menor número de empleados, por lo que si la actividad de negocio se ve afectada durante el periodo de implantación, los daños serán reducidos al mínimo. Además, en esta primera implantación se realizarán todo un conjunto de tareas que no será necesario volver a realizar en las posteriores, como la elección de tecnologías y modelos, definición de incidencias y problemas, o análisis de riesgos. Por otro lado, los periodos de pruebas y correcciones también se reducirán puesto que no se repetirán los fallos cometidos en la primera implantación. También se debe mencionar que la implantación que se realizará no ocupará todos los módulos y procesos de ITIL; se han seleccionado aquellos procesos que aportarán más beneficio a la empresa. Por este motivo, se ha decidido implantar los procesos de gestión de incidencias y problemas junto al service desk y la gestión de configuración, todos ellos del módulo de Service Support. Además, también se implantará el módulo de Security Management. En los siguientes apartados se detallará la planificación del plan de trabajo, así como las tareas que lo ocupan. 1.4.1. Implantación ITIL en Excalibur Como se ha comentado anteriormente, no se puede hacer la implantación completa a la vez, se deben definir e implementar los procesos gradualmente para minimizar el impacto en la actividad empresarial. En este caso, se ha decidido implantar en primer lugar la gestión de incidencias prácticamente en paralelo con la gestión de problemas, para posteriormente añadir el service desk como marco en el Service Support. Se debe decir que para la elección de la herramienta a utilizar se ha tenido que diseñar la CMDB (tarea de gestión de configuración) para verificar la compatibilidad. La implantación de la gestión de configuración y gestión de seguridad también se ha realizado en paralelo, y a la vez que la formación de personal en incidencias y problemas y el 1er periodo de pruebas para optimizar recursos y ganar tiempo. 14 En cuanto a las pruebas y correcciones, se incluirán dos etapas para realizarlas. Estas coincidirán con la finalización de las implantaciones de incidencias y problemas, y configuración y seguridad respectivamente. En la siguiente figura se pueden observar de forma más clara las tareas de las que constará esta primera implantación, así como sus fechas de inicio/final y su duración. 15 16 1.4.1.1. Implantación Gestión de Incidencias En la figura de la página anterior se puede observar la temporización de las tareas de esta parte, así como su relación entre ellas y con las tareas de otros procesos. Además, en las siguientes tablas se presenta una breve descripción. Tarea Definición y clasificación de incidencias Duración 10 días Recursos A-1;A-2 Predecesoras Ninguna, primera tarea a realizar en la gestión de incidencias. Descripción Definición de las posibles incidencias y realización de una clasificación en función de diferentes parámetros. Tarea Confección de formularios Duración 5 días Recursos AP-1;AP-2 Predecesoras Definición y clasificación de incidencias Descripción Diseño de formularios como soporte y documentación a los procesos a los que se somete una incidencia y el tratamiento que se le da. Tarea Estructuración de niveles (Workflow de las incidencias) Duración 10 días Recursos A-3;AP-3;A-4 Predecesoras Definición y clasificación de incidencias Descripción Definición y estructuración de los diferentes niveles que habrán en la gestión de una incidencia y primera aproximación de la organización y estructuración de cada uno de los niveles. Tarea Definición de funciones, responsabilidades y procesos Duración 15 días Recursos A-1;A-2;AP-3;AP-4 Predecesoras Estructuración de niveles (Workflow de as incidencias) Descripción Delegación de responsabilidades y funciones a realizar en los puestos de trabajos encargados de la gestión de incidencias, así como los procesos que se deberán seguir en cada situación. Tarea Formación de personal: Gestión de Incidencias Duración 15 días Recursos A-4;AP-3;AP-4 Predecesoras Configuración/adaptación de la herramienta elegida Descripción Formación específica del personal que se va a encargar de gestionar las incidencias según la nueva organización, los procesos y funciones establecidas y la herramienta para la gestión. La formación se realizará a turnos con duración de media jornada. 17 1.4.1.2. Implantación Gestión de Problemas En la figura X también se pueden encontrar todas las tareas y actividades a realizar en relación a la gestión de problemas. Tareas de las que se hace una explicación en las tablas que se pueden encontrar a continuación. Tarea Definición y clasificación de problemas Duración 10 días Recursos A-1;A-2 Predecesoras Definición y clasificación de incidencias Descripción Definición de los posibles problemas teniendo en cuenta las incidencias definidas y realización de una clasificación en función de diferentes parámetros. Tarea Confección de formularios Duración 5 días Recursos AP-1;AP-2 Predecesoras Definición y clasificación de problemas Descripción Diseño de formularios como soporte y documentación a los procesos a los que se somete un problema y el tratamiento que se le da. Tarea Definición de funciones, responsabilidades y procesos. Duración 15 días Recursos A-3;A-4;AP-2 Predecesoras Confección de formularios Descripción Delegación de responsabilidades y funciones a realizar en los puestos de trabajos encargados de la gestión de problemas, así como los procesos que se deberán seguir en cada situación. Tarea Formación de personal: Gestión de Problemas Duración 5 días Recursos A-2 Predecesoras Configuración/adaptación de la herramienta elegida Descripción Formación específica del personal que se va a encargar de gestionar los problemas con la nueva organización, procesos establecidos y la herramienta para la gestión. La formación se realizará a turnos con duración de media jornada. 1.4.1.3. Implantación Service Desk De la misma forma que los apartados anteriores, en la figura X también se pueden contemplar las tareas a realizar para la implantación del service desk. Seguidamente se describe brevemente cada tarea. Tarea Duración Predecesora s Definición de objetivos y métricas 10 días Recursos A-1;A-2;AP-3;AP-4 Definición funciones, responsabilidades y procesos de gestión de incidencias 18 Descripción Definición de los objetivos específicos del service desk y las métricas necesarias para medir su grado de cumplimiento. Tarea Elección del modelo Duración 5 días Recursos A-1;A-2 Predecesora s Definición de objetivos y métricas Descripción Análisis de los modelos de service desk aplicables y elección del que más se ajuste a la estructura de la empresa. Tarea Definición de funciones, responsabilidades y procesos. Duración 15 días Recursos A-1;A-2;AP-1;AP-2 Predecesoras Elección del modelo Descripción Delegación de responsabilidades y funciones a realizar en los puestos de trabajos encargados del service desk, así como los procesos que se deberán seguir en cada situación. Tarea Duración Elección de la herramienta a usar 5 días Recursos A-4;A-3 Elección del modelo y Diseño del nuevo modelo de inventario Predecesoras (G. Configuración) Descripción Elección de la tecnología (herramienta informática) adecuada para soportar los procesos definidos y que se ajuste completamente con el modelo de CMDB definido previamente para evitar incompatibilidades. Tarea Configuración/adaptación de la herramienta elegida A-3;AP-1;P-1;PDuración 20 días Recursos 2;P-3 Predecesoras Elección de la herramienta a usar Descripción Configuración de la herramienta y adaptación según todos los aspectos definidos anteriormente en la gestión de incidencias y problemas y en el propio service desk. Tarea Diseño del modelo de BD para almacenar incidencias Duración 5 días Recursos A-2;AP-2 Predecesora s Elección de la herramienta a usar Descripción Diseño de la BD que almacenará las incidencias teniendo en cuenta la herramienta elegida y todos los parámetros definidos anteriormente en la gestión de incidencias. 19 1.4.1.4. Implantación Gestión de Configuración A continuación se muestran de forma detallada las tareas a realizar con toda su información relevante: Tarea Duración Análisis de sistemas de configuración existentes 5 días Recursos AP-4;A-4 Ninguna, realización con antelación para proporcionar info de la Predecesoras CMDB al Service Desk Descripción Análisis de los diferentes procesos, funciones, responsabilidades ...etc que se utilizan actualmente en el casino para hacer una agrupación consistente y especifica para reorganizar la gestión de la configuración y establecer las necesidades de cara al nuevo modelo de inventario. Tarea Diseño del nuevo modelo de inventario Duración 10 días Recursos A-3;A-4;AP-3;AP-4 Predecesoras Análisis de sistemas de configuración existentes Descripción Diseño de un modelo de inventario (CMDB) a partir de la reorganización de la gestión de configuración, acorde con las necesidades específicas del casino. Tarea Implementación del nuevo modelo de inventario A-3;AP-1;P-2;PDuración 15 días Recursos 3;P-1 Predecesoras Diseño del nuevo modelo de inventario Descripción Implementación del modelo diseñado con todos los equipos y elementos de red que se ha decidido incluir en el inventario. Tarea Formación de personal: Gestión de Configuración Duración 10 días Recursos A-4;AP-2;A-1 Predecesoras Implementación del nuevo modelo de inventario Descripción Formación específica del personal que se va a encargar de gestionar la configuración según la nueva organización y procesos establecidos. La formación se realizará a turnos con duración de media jornada. 1.4.1.5. Implantación Gestión de Seguridad En cuanto a la gestión de seguridad, en la misma figura que los procesos anteriores se muestra el diagrama gantt de las tareas a realizar, mientras que las tablas sucesivas describen con más detalle cada una de las tareas. Tarea Análisis de amenazas Duración 5 días Recursos AS-1;AS-2 Predecesoras Puesta en marcha del Service Desk. Descripción 20 Análisis de posibles amenazas tanto internas como externas que pueden comprometer la integridad, confidencialidad... etc de los datos, así como la disponibilidad de los servicios. Tarea Elección de los recursos a proteger Duración 5 días Recursos AS-3;A-1 Predecesoras Análisis de amenazas Descripción Elección de qué recursos se protegerán teniendo en cuenta las amenazas y su probabilidad de éxito, así como el coste de la protección del recurso en relación a esta probabilidad. Definición de procesos (plan, implantación, evaluación, control Tarea mantenimiento y documentación) Duración 10 días Recursos AS-1;AS-2;AS-3 Predecesoras Elección de los recursos a proteger Descripción Definición de los procesos de planificación, implantación, evaluación, control, mantenimiento y documentación en concordancia con las necesidades específicas del casino y en relación a los recursos que se ha decidido proteger. Tarea Definición de funciones y responsabilidades Duración 5 días Recursos AS-1;A-2 Predecesoras Definición de procesos Descripción Delegación de responsabilidades y funciones a realizar en los puestos de trabajos encargados de la gestión de la seguridad. Tarea Formación de personal: Gestión de seguridad Duración 10 días Recursos AS-2;AS-3 Predecesoras Definición de procesos Descripción Formación específica del personal que se va a encargar de gestionar la seguridad según los procesos y funciones establecidas. La formación se realizará a turnos con duración de media jornada. 1.4.1.6. Periodos de prueba y correcciones Se ha decidido establecer dos periodos de pruebas a realizar para cada una de las dos grandes partes de la implantación; por un lado incidencias, problemas y service desk y por el otro configuración y seguridad. De esta forma, se pretenden consolidar las partes ya implantadas con los nuevos procesos, verificando su correcto funcionamiento e integración. Además, se ha considerado interesante repetir las pruebas en la implantación del resto de casinos para hacer una depuración más profunda y comprobar el buen funcionamiento de todos los procesos en todos los casinos a la vez. Así que aunque los periodos de prueba 3º y 4º estén dentro de la implantación en el resto de casinos, también se describirán en este apartado. 21 En cuanto la duración y recursos destinados a cada periodo de pruebas, la siguiente tabla muestra los detalles: Tarea 1º Periodo de pruebas y realización de correcciones Duración 20 días Recursos T-1;T-2;P-1;P-2;P-3 Predecesoras Puesta en marcha: Gestión de incidencias y problemas Descripción Testeo conjunto de los procesos de gestión de incidencias y problemas bajo el marco del service desk. Valoración de impresiones del personal. Corrección de fallos o puntos débiles detectados en el testeo o en la valoración del personal. Tarea 2º Periodo de pruebas y realización de correcciones Duración 20 días Recursos T-1;T-2;P-1;P-2;P-3 Predecesoras Puesta en marcha: Gestión de configuración y seguridad Descripción Testeo del la gestión de configuración y la gestión de seguridad por separado y conjuntamente con los procesos de gestión de incidencias y problemas. Valoración de impresiones del personal. Corrección de fallos o puntos débiles detectados en el testeo o en la valoración del personal. Tarea Duración 3º Periodo de pruebas y realización de correcciones 10 días Recursos T-1;P-1;P-2;A-1 Puesta en marcha: Gestión de incidencias y problemas (resto Predecesoras de casinos) Descripción Testeo conjunto de los procesos de gestión de incidencias y problemas de todos los casinos. Valoración de impresiones del personal. Corrección de fallos o puntos débiles detectados en el nuevo testeo o en la valoración del personal del resto de casinos. Tarea Duración 4º Periodo de pruebas y realización de correcciones 10 días Recursos T-2;P-1;P-2;P-3;A-3 Puesta en marcha: Gestión de configuración y seguridad (resto Predecesoras de casinos) Descripción Testeo conjunto de los procesos de gestión de configuración y seguridad de todos los casinos junto con todos los procesos. Valoración de impresiones del personal. Corrección de fallos o puntos débiles detectados en el nuevo testeo o en la valoración del personal del resto de casinos. 1.4.2. Implantación ITIL en el resto de casinos Una vez se han implantado los procesos mencionados con éxito en el casino EXCALIBUR, la parte más complicada del proyecto ya está realizada. Ya solo queda trasladar los procesos, funciones y nuevas responsabilidades definidas al resto de los casinos e implantarlos. 22 Como se ha mencionado en la primera parte de la sección Plan de implantación, en esta segunda parte se ahorrará la realización de muchas tareas y se reducirá la duración de las restantes, como resultado al trabajo realizado durante la definición de procesos y los periodos de prueba en la primera implantación. Principalmente se revisarán las funciones, responsabilidades y procesos y se formará al nuevo personal. En la figura de la página siguiente se pueden observar estas tareas en todas las fases de la segunda implantación, con sus nuevas duraciones. 23 24 1.4.3. Recursos En cuanto al personal que se estima que será necesario para realizar el plan de implantación, se han concretado 6 perfiles profesionales bien diferenciados. Además, no habrá el mismo número de personas de cada perfil y predominarán los perfiles con mayor experiencia laboral. En la siguiente tabla se puede observar este aspecto: Perfil profesional Jefe de proyecto Analista Analista programador Programador Testeador senior Analista seguridad Cantidad 1 4 4 Abreviación 3 2 3 P-[1...3] T-[1...2] AS-[1...3] A-[1...4] AP-[1...4] Por otro lado, debido a la importancia del trabajo de cada tipo de perfil y el factor de que la mayoría de tareas son de análisis, no todos los perfiles trabajaran el mismo número de horas. En la siguiente tabla se muestra la dedicación de cada empleado y se observan las diferencias entre perfiles: Personal Dedicación Jefe proyecto 1.544 horas A-1 760 horas A-2 752 horas A-3 752 horas A-4 760 horas AP-1 640 horas AP-2 640 horas AP-3 640 horas AP-4 624 horas T-1 400 horas T-2 400 horas P-1 760 horas P-2 760 horas P-3 800 horas AS-1 240 horas AS-2 240 horas AS-3 240 horas 25 1.5. Evaluación En este apartado se proponen un conjunto de medidas y procedimientos de evaluación para determinar el nivel de éxito que ha tenido el plan de implantación de ITIL. Para ellos se identificarán los factores críticos de éxito (CSFs) y los indicadores de prestaciones clave (KPIs) relevantes en cada proceso implantado. De esta forma, se podrá saber dentro de cada proceso, el nivel de éxito de cada aspecto evaluado según los indicadores establecidos. Normalmente se compararán valores actuales con valores obtenidos en un periodo anterior, observando el porcentaje de aumento o reducción de cada indicador. Los CSFs y los KPIs se separan por procesos en las siguientes tablas para presentarlos de forma más clara y ordenada: Gestión de incidencias Factores criticos de éxito (CSFs) Resolución rápida de incidencias Indicadores de prestaciones clave (KPIs) Incremento de incidencias resueltas por el primer nivel Reducción de incidencias clasificadas incorrectamente Aumento del número de incidencias tratadas por cada Mejora de la productividad operador de primer nivel Reducción del coste de tratamiento de incidencias Mejora de la calidad del Reducción de la no-disponibilidad del servicio causado por servicio incidencias Incremento de incidencias resueltas antes de la notificación del usuario Reducción de incidencias re-abiertas Reducción del tiempo medio de resolución de incidencias Incremento de incidencias resueltas según su clasificación (prioridad, categoría) Mejora en encuestas de satisfacción del usuario en resolución Satisfacción del usuario de incidencias Reducción del tiempo de espera para el Service Desk Reducción del llamadas perdidas en el SD Gestión de problemas Factores criticos de éxito (CSFs) Mejora de la calidad de servicio Minimizar impacto de problemas Indicadores de prestaciones clave (KPIs) Reducción de incidencias/problemas repetidas Reducción de incidencias/problemas que afectan a los clientes Reducción de la aparición de incidencias/problemas conocidas Reducción del tiempo medio de resolución de problemas Reducción del tiempo para identificar problemas Reducción del número de problemas sin identificar 26 Reducción del coste para los usuarios Gestión de la configuración Factor de éxito (CSFs) Control de equipamiento tecnológico Soporte a otros procesos Mejora de la calidad de servicio Gestión de seguridad Factor de éxito (CSFs) Protección ante individuos Protección ante software malicioso Protección ante urtos Reducción del tiempo de realización de reparaciones para errores conocidos Reducción de la interrupción de servicios para usuarios de la empresa Incremento de cambios realizados proactivamente Prestaciones clave (KPIs) Reducción de equipos mal configurados en la CMDB Incremento del registro de equipos en CMDB Incremento de la velocidad de registro de equipos Reducción de incidencias por mala configuración de equipos Reducción del tiempo de resolución de incidencias por la disponibilidad de los datos y velocidad de acceso y recuperación Aumento de la velocidad de substitución y reparación de equipos Aumento de la satisfacción de los usuarios con los equipos Reducción de errores en el servicio atribuibles a información de configuración errónea Prestaciones clave (KPIs) Reducción del tiempo medio de detección de intrusiones Reducción del tiempo medio de detección de mal uso de privilegios Reducción del tiempo medio de detección de suplantaciones Reducción de recursos dañados por individuos Aumento de la identificación de autoría de intrusiones/suplantaciones Reducción del tiempo medio de detección de malware Reducción del numero de malware que irrumpe dentro de la red privada Aumento de la identificación del origen del malware Reducción de recursos dañados por malware Aumento de la identificación de autoría de hurtos Reducción del tiempo medio de detección de hurtos Para la obtención de toda la información necesaria para realizar una correcta evaluación, será necesaria una recogida exhaustiva de estadísticas y opiniones de los usuarios. Las estadísticas se pueden recoger mediante informes mensuales donde se muestren los parámetros de interés obtenidos de la propia documentación producida por la actividad habitual del departamento. Las opiniones de los usuarios se 27 pueden obtener a partir de encuestas obligatorias de satisfacción de personal y encuestas voluntarias realizadas a los propios clientes. La síntesis de estadísticas y opiniones se puede realizar de forma anual para evaluar los resultados y presentarlos a la directiva a final de año como muestra de la mejora obtenida con la implantación de los procesos ITIL. 28 1.6. Mejora continua Una vez finalizada la implantación del plan en su totalidad, no se debe creer que la nueva organización va a durar para toda la vida. La actividad económica y empresarial evoluciona, de la misma forma que lo hacen la tecnología y las comunicaciones. Además, los gustos y las costumbres de las personas también cambian, y todo ello en conjunto da lugar a un mercado dinámico que está en constante movimiento. Por este motivo, en cada momento se debe encontrar el equilibro entre el propio negocio y la tecnología utilizada para no quedar descolgado en el mercado por culpa de tener aplicaciones o infraestructuras obsoletas que no cumplen con los requisitos de los clientes. Así pues, para conseguir que MGM tenga una fuerte presencia en el mercado con el paso del tiempo, se hace una propuesta de actividades para actualizar y mejorar la gestión de sus redes y servicios, una vez realizado el plan de implantación. El objetivo de estas actividades y tareas es conformar un plan de mejora continua que sirva para realimentar todo el procedimiento que se ha seguido en la implantación de ITIL de forma que se vuelvan a seguir los mismos pasos para su actualización. Tarea Soporte post-implantación Duración 3 meses Recursos 2 Analistas programadores Descripción Después de la implantación se quedarán trabajando dos analistas programadores que hayan participado en el plan para ofrecer soporte de primera mano y ayudar a consolidar todo lo Implantado. Tarea Análisis de resultados Frecuencia Anual Recursos Datos obtenidos a partir de la evaluación Descripción Realizar el proceso de evaluación de forma anual, con la recogida de estadísticas y encuestas y su trascripción a los parámetros definidos. Analizar los resultados y tomar medidas si es necesario. Tarea Análisis de informes Frecuencia Semestral Recursos Informes mensuales de las Descripción A partir de los informes mensuales producidos según los procesos ITIL implantados, realizar un seguimiento semestral para la detección de puntos débiles en los procesos y su posterior mejora. 29 2. SERVICE DESK 2.1. Objetivos Service Desk El objetivo del Service Desk es de actuar como punto central de contacto entre el usuario y la gestión de servicios IT. Se gestionan las incidencias y peticiones, proporcionando un punto de interconexión con otras actividades como la gestión de cambios, problemas y configuración. Para poder seleccionar un Service Desk que se adecue a las características del servicio, se tiene que tener en cuenta elementos como la disponibilidad en la atención telefónica a los usuarios y que se puedan comunicar en cualquier hora del día todos los días de la semana (24x7). Cuando un usuario tenga un problema, queja o cuestión, con la implementación del Service Desk, recibirá respuestas y soluciones de manera rápida y eficiente. 2.2. Métricas Service Desk Para saber si el funcionamiento del Service Desk que se implementa funciona de forma correcta, se definirán unas métricas que permitirán evaluar la efectividad del servicio. Si la valoración de los parámetros está por debajo de los considerados adecuados, sabremos que no se está dando un buen servicio y se tendrá que solucionar de cualquier forma. La parte más importante es conocer los niveles de servicio que el cliente pide, entonces tendremos un punto de referencia por tal de decidir si hay un buen nivel de servicio. Para mesurar la efectividad, los elementos que se tendrán en cuenta serán: - Diario: - Estado de las incidencias y problemas frente a los niveles de servicio concertados. - Semanal: - Disponibilidad de los servicios - Frecuencia y duración de las incidencias (tiempo medio de respuesta) - Alteraciones del Servicio - Mensual: - Rendimiento general, logros y análisis de tendencias. - Nivel de satisfacción de los usuarios 30 2.3. Tipo Service Desk El Centro de Atención a los Usuarios (CAU) es el único punto de contacto y debe dar soporte de alta calidad, identificando y reduciendo los costes del servicio. Hay tres tipos de CAU: el local, el virtual y el centralizado. Antes de elegir la solución final se ha estudiado las ventajas y inconvenientes de cada tipo. El local se adapta a los problemas que se tengan en la misma sede pero tiene la contrariedad de que se necesita un gran nombre de personal que eleva los costes económicos y además no se tiene una visión de la problemática en el conjunto de la empresa. El virtual puede situarse y ser accedido desde cualquier lugar del mundo, hay un coste reducido de operaciones y se hace un buen uso de los recursos. Las desventajas es que no se adapta con el servicio que se tiene que ofrecer ya que una parte importante es la solución de las incidencias y problemas que muchas veces se tienen que hacer in-situ. El centralizado ha sido la elección final por varios motivos. Hay una gestión más consolidada ya que todo se gestiona desde una misma sede, hay una visión de la problemática en conjunto, se aprovechan mejor los recursos lo que hace que se reduzcan los costes. Como se muestra en la siguiente figura, el Service Desk estará situado en el MGM Grand Las Vegas para poder gestionar los 5 casinos. 2.4. Tecnologías Service Desk Para proporcionar un servicio que se adecue a las necesidades de los 31 clientes, las tecnologías que se utilizaran serán: - HP Openview Service Desk (definido en el capitulo de herramientas utilizadas) - Internet - VoIP - Correo electrónico 2.5. Funciones y responsabilidades Service Desk Los objetivos principales del Service Desk es proporcionar un único punto de contacto con el cliente y facilitar la restauración del servicio de operación con el mínimo impacto en el negocio, proporcionando los niveles de servicio acordados y las prioridades del negocio. Si las incidencias que no se pueden resolver de forma rápida por el Service Desk se redirigirán a un personal más especializado que realizará un diagnostico y buscará una solución. Si las incidencias no se resuelven o están por debajo de los SLAs marcados, se tendrán que ser considerados como problemas que se gestionarán siguiendo el proceso marcado por la gestión de problemas. 2.5.1. Funciones del Service Desk Las funciones serán las siguientes: - Recibir llamadas i atenderlas en primera instancia - Mantener a los usuarios informados acerca del estado y progreso de la incidencia - Realizar una primera clasificación de la incidencia, intentar resolverla y redirigirla a la persona adecuada si no se ha podido solucionar - Seguimiento de la monitorización - Almacenar incidentes y quejas - Gestión de las peticiones incluyendo su finalización y verificación - Elaboración de informes a dirección - Comunicar los cambios a corto plazo sobre los niveles de servicio al cliente - Conocer dónde se tiene que redirigir las incidencias que no se sepan solucionar - Identificación de problemas - Detectar necesidades de formación del cliente - Contribución a la identificación de problemas 2.5.2. Gestión de escalabilidad Tiempo para coger el teléfono En la mayoría de los casos, el nombre de tonos que se tendrá que esperar un usuario que llame al Service Desk, será entre 2 i 6 tonos. Tiempo de conversación telefónica Para poder resolver todas las incidencias se dispondrá de un sistema de 32 encolamiento de las llamadas que notificará al personal de Service Desk siempre que hayan llamadas en espera. Así atender a las llamadas de la manera más rápida i no dejen usuarios sin respuestas. El tiempo máximo para atender una llamada será de 3 a 5 minutos. Tiempo medio de resolución de incidencias Aproximadamente el 80% de las incidencias se resolverán en menos de dos horas. Carga de trabajo Se tendrá que mesurar el nombre de personas que forman parte del Service Desk es el adecuado y si es necesario ampliar o reducir el personal por tal de no desaprovechar recursos. Para mesurar la carga de trabajo se definirán una serie de parámetros que ayudarán a tomar decisiones: - Nombre de peticiones recibidas - Nombre de peticiones atendidas - Nombre de peticiones recibidas y no atendidas - Tiempo medio de resolución de incidencias - Tipo de peticiones que se reciban (si el tipo de peticiones coincide con el tipo de incidencias que se definirá en la gestión de incidencias y problemas) - Tipo de peticiones que más tarden en solucionarse (soporte de primer nivel, segundo, tercero o intervención de los proveedores) 2.6. Perfil del personal El Service Desk estará formado por un personal capaz de trabajar en equipo, con experiencia técnica, que conozcan las herramientas de gestión y con facilidad por la comunicación con los clientes. El perfil pedido será el siguiente: - Conocimiento técnico de las herramientas de gestión - Habilidades interpersonales - Nivel alto de la lengua inglesa - Nivel medio de la lengua española - Capacidad para entender los objetivos del negocio - Motivación para dar un buen servicio - Capacidad de explicación de conceptos a nivel de usuario - Activo a la hora de escuchar - Capacidad de aprendizaje 2.7. Procesos del Service Desk Se definirán una serie de procesos a seguir por parte del personal del Service Desk que tendrán de ser revisados de forma regular y actualizados en caso que se detecte cualquier carencia o mejora. 2.7.1. Técnica estructurada de interrogación 33 Se definirá una estructura de dialogo para atender las peticiones de los usuarios, de esta forma, el personal no se olvida de ningún aspecto. El proceso de atención al usuario será el siguiente: - Salutación inicial - Petición de los datos personales del usuario que realiza la incidencia - Petición de los datos de la incidencia - Intentar resolver la incidencia si es de primer nivel, sino pasarle con el departamento encargado de esa incidencia del nivel dos. - Sino se ha solucionado notificar que estamos trabajando en ello y dar información del tiempo que se tardará en solucionar la incidencia. - Una vez solucionada la incidencia, dar las gracias por la llamada i despedirse 2.7.2. Identificación y detalles del cliente - Nombre del usuario Id del usuario Numero de teléfono Casino Zona del Casino Los datos del cliente se podrán obtener a partir de un número identificativo (ID) que se ha asignado al usuario y que notificará en la llamada. 2.7.3. Análisis de la carga de trabajo La optimización de la utilización del personal es de gran importancia y es necesario saber si este numero de trabajadores es adecuado y si el personal del Service Desk sabe solucionar la mayoría de incidencias. Para poder saberlo, es necesario que cada vez que una incidencia, se redireccione o se finalice, se añada al registro de la incidencia esta información. Los elementos a añadir serán: - Día y hora de la notificación de la incidencia - Día y hora solución de la incidencia - Persona que ha recibido la incidencia y el tiempo que ha estado trabajando en ella - Persona que ha resuelto la incidencia y el tiempo que ha estado trabajando en ello - Intermediario que le han pasado la incidencia y la ha pasado a otro nivel y el tiempo que ha estado trabajando en ella Cada mes se realizarán estadísticas de forma automatizada y los resultados se analizarán por un equipo que decidirá si es necesario hacer cambios. Las estadísticas tendrán la siguiente información: - Disponibilidad del servicio - Mayores áreas de incidencias o Las que sucedan mas a menudo 34 - o Las que requieren más personal o Las que llevan más tiempo para ser resueltas Incidencias que necesitan abrir un problema Errores conocidos y cambios requeridos Satisfacción de los usuarios Carga de trabajo de los trabajadores Participación del personal de segundo nivel 2.7.4. Registro de incidencias Todas las incidencias se almacenarán a la base de datos. La información que se registrará está definido en el apartado de gestión de incidencias y problemas. 35 3. GESTIÓN DE INCIDENCIAS 3.1. Introducción En este apartado se explica como se tratarán las incidencias que lleguen al sistema. Del mismo modo, el objetivo principal de este apartado es posibilitar la recuperación más rápida posible de los apartados afectados por incidencias a la operación normal de estos. De este modo se pretende minimizar el impacto negativo que puedan tener las posibles incidencias en el negocio. Las prioridades de las incidencias y los procesos de escalabilidad deben ser especificados en el Service Level Management y documentados en los SLAs. También cabe destacar la estrecha relación que mantiene la gestión de incidencias con la gestión de problemas y con el mismo Help Desk que se desarrollan mediante las interfaces definidas en este documento. Antes de continuar con las incidencias, conviene diferenciar los dos tipos que existen. Por una parte están las incidencias reactivas y por otra las proactivas. Las reactivas son aquellas que no se detectan y son comunicadas por el cliente. Por otro lado, las proactivas son las que se detectan con las herramientas de monitorización de dispositivos y son tratadas antes de que el usuario se de cuenta, pudiéndolas solucionar, algunas veces, antes de que provoquen un mal funcionamiento grave. 3.2. Niveles de soporte En SinCity aplicaremos los tres niveles de soporte que ITIL especifica: Primer nivel: El primer nivel, o Service Desk, será el punto único de contacto con el usuario que llame para notificar una incidencia o problema. Efectuará también de filtro para los casos que no necesiten de una gestion ya que la incidencia tiene una resolución sencilla y no compleja. Este primer nivel va estar formado por gente con un nivel técnico no muy alto, pero con don de gentes y comunicativos. Va aser necesaria una formación previa de las aplicacions y procedimentos que vamos a tratar. Se detallará más este nivel en el apartado del Seviche Desk. Segundo nivel: El segundo nivel será el que tratará de buscar soluciones a las incidencias que se abren del primer nivel, actualizando el historial y en contacto con el Servicio de Help Desk para comunicar el estado de la incidencia. También tratará los problemas con el procedimiento que explicaremos en el siguiente nivel. Estará formado por el equipo de gestión de incidencias y de problemas. 36 Tercer nivel: Se trata del último nivel del escalado de la solución de problemas. Lo componen expertos en diferentes áreas específicas y a ellos les llegan los problemas que no se han podido resolver en ningún nivel anterior. Los componentes de este nivel deben tener perfil de Ingenieros Superiores en telecomunicaciones, en informática o en industrial y han de haber pasado por lo menos un año en el nivel dos. Con esta última exigencia se espera dotar a los trabajadores del tercer nivel con la experiencia y visión necesaria para trabajar en este último nivel. Como se ha comentado previamente, los integrantes del citado nivel serán especialista en un área muy específico. Por ejemplo, habrá experto en la base de datos, experto en red, experto en seguridad de red, experto en seguridad, experto en el sistema operativo, experto en software, experto en software de las máquinas recreativas, experto en el hardware de las máquinas recreativas, expertos en comunicaciones internas, experto en máquinas cashless y expertos por el estilo. 37 3.3. Incidencias reactivas El soporte de las incidencias se diferencia en diferentes niveles para poder tratarlas mejor. De este modo, a medida que se sube de nivel, se dispone de mayor especialidad, tiempo y recursos para solventarlos. 3.3.1. Primer nivel El proceso comienza cuando un usuario da parte de una incidencia mediante los procedimientos preestablecidos. El primer nivel es el encargado de recoger la petición del usuario independientemente del procedimiento en que se ha hecho llegar. Acto seguido, se le hace saber al usuario que se ha iniciado el proceso de resolución de la incidencia junto al número de su incidencia y se le indica una persona de contacto para poder resolver sus dudas. Mencionar que 38 esta persona será la encargada de avisar al usuario de la resolución de la incidencia. Profundizando más en el tema, cuando se abra una nueva incidencia se le asigna automáticamente un ticket, es decir un número único que se le asigna a cada incidencia y se utiliza para identificarlo. Además, habrá que rellenar diferentes campos de un formulario para tener unos datos iniciales sobre el tema. Los campos del formulario serán los siguientes, pero al abrir una nueva incidencia no habrá que rellenarlos todos, sólo los más importantes y algunos se tendrán que ir completando mientras se intenta solucionar. Datos o o o de la incidencia Número de incidencia (Predetermianda) Localizador Identificador de dispositivo (este campo autocompleta las dos posteriores) o Nombre del casino o Zona del casino o Clasificación de la incidencia. o Estado: Abierta, cerrada y en resolución o Descripción o Criticidad o Hora y fecha de inicio o Hora y fecha de notificación (autocompletada) o ID del trabajador que la ha recibido (autocompletada) o Hora de previsión de resolución: tiempo estimado de la resolución o Pasos de la solución: Que niveles y personas han intentado solucionarlo. Esta parte se irá rellenando mientras se intenta solucionar. o ID del trabajador que la ha solucionado o Descripción de la solución o Hora y fecha de la resolución (autocompletada al cerrarse la incidencia) o Observaciones Identificador de usuario/trabajador (este campo autocompleta las cuatro posteriores) o Nombre o Apellidos o Teléfono de contacto o E-mail de contacto o Datos del usuario/trabajador que ha dado parte o Identificador del trabajador encargado de comunicar al usuario/trabajador la resolución de la incidencia Cave recordar que no todos los campos del formulario son obligatorios y se habrán de rellenar según los datos que se tienen 39 de él. Por otra parte, los campos como fecha de resolución, ID de la persona que ha solucionado la avería, etc. han de ser insertadas más tarde. Por otro lado, para facilitar la inserción de datos, se han añadido campos que autocompletan otros campos. Por ejemplo, al insertar la ID de usuario el sistema busca y completa automáticamente los datos relativos a ese cliente que ya son conocidos por él. Después de haber recibido una incidencia y haber rellenado el formulario pertinente, el Help Desk ha de comenzar a trabajar. El primer paso que ha de realizar es contrastar con los errores y problemas ya conocidos e identificar si la incidencia entrante corresponde a una ya solucionada y tipificada. Para ello, se provee este primer nivel de una tabla con la información necesaria para la identificación de incidencias conocidas y los pasos que han de seguir para solucionarla junto con los programas apropiados. Con todo esto se consiguen dos cosas. La primera disponer de procedimientos para indicar al usuario como solucionarla a base de pasos que ha de seguir. Por otro lado, se generan recursos para que el propio trabajador disponga de recursos para resolver los errores mediante programas de conexiones remotas y aplicaciones parecidas construidas por el equipo técnico que con indicaciones paso a paso consiguen resolver los errores. De esta manera, se consiguen solucionar los típicos errores que ocurren y que de antemano se conoce su solución. Con esto se consigue que no se saturen los niveles posteriores con errores fácilmente solucionables por el primer nivel y así, se reduce el tiempo de resolución, aumentando, de esta forma, la satisfacción del usuario. Siguiendo este procedimiento queda claro que si el operador del Help Desk puede arreglar una incidencia lo hará. Una vez arreglado, modificará el estado de esta y cumplimentará los datos necesarios. Acto seguido, el sistema avisará al encargado de contactar con el cliente indicándole que lo haga. Una vez comunicado al cliente o pasados 2 días desde que se intenta comunicarse con él para indicarle este hecho se archivará la incidencia. Existen dos posibilidades de que una incidencia pase del primer nivel al segundo. El primero es que los miembros del primero no puedan solucionar el problema y pasen al segundo para que estos trabajen en ello. La segunda posibilidad es que después de haber pasado una hora desde que se abrió la incidencia, el primer nivel no ha sido capaz de solucionarlo, el sistema lo transfiera automáticamente al segundo. De todas formas se ha contemplado un tercer caso excepcional. Se trata de cuando el primer nivel observa que el dispositivo en cuestión no se puede arreglar. Por ejemplo, cuando un teléfono DECT haya caído al suelo y se haya roto en mil pedazos. En este caso, el primer 40 nivel puede pasar el ticket con la calificación de sustitución directamente al departamento pertinente . De esta forma se gana en eficiencia, porque no se hace pasar la incidencia por todos los niveles. El personal de este primer nivel ha tener una idea básica del funcionamiento del casino y, en concreto, de resolución de dudas básicas con los procedimientos previamente definidos. Por otro lado, deben redirigir los problemas adecuadamente realizando para ello, un primer análisis que deberán hacerlo adecuadamente. El perfil que se pide para este nivel es de técnico en informática o telecomunicaciones. 3.3.2. Segundo nivel Como ya se ha comentado anteriormente, los problemas que no se puedan solucionar en el primer nivel se pasan a un segundo. Los trabajadores de este nivel son ingenieros técnicos en telecomunicaciones, informática e industrial. Es por esto que están más especializados en sus respectivas áreas de la misma forma se encuentran distribuidos en diferentes áreas: Telecomunicaciones (Redes, Internet y comunicaciones) Seguridad Equipos informáticos y periféricos (PCs, impresoras, monitores, teclados, etc.) Máquinas recreativas Base de datos Aplicaciones (Sistemas operativos, software, etc.) De la misma manera, conviene especificar que los trabajadores de este nivel disponen de herramientas más específicas para hacer frente a las incidencias junto con material de repuesto para que, en caso necesario, se pueda remplazar el dispositivo en cuestión mientras se soluciona la incidencia con el aparato original. Esto se realizará por ejemplo con las tragaperras del casino, puesto que al tratarse de máquinas muy utilizadas, al quedar fuera de servicio uno de ellas, el casino termina ingresando menos dinero. De la misma forma, se tendrán en el almacén algunos CPUs, pantallas y otros elementos, para que en caso de avería se puedan sustituir de forma adecuada sin perder tiempo. Cuando un operador de segundo nivel detecte y evalúe la incidencia y observe que requiere mayor una especialización porque se trata de una incidencia grave o desconocida y él mismo no lo puede arreglar, contactará con el tercer nivel. 3.3.3. Tercer nivel Cada experto recibirá los errores de su especialidad y pueden darse dos casos generales. El primero es que el experto arregle la avería y 41 cierre la incidencia. El segundo es que el experto detecte que el error es debido al mal funcionamiento no reparable de una máquina. En este caso tendrá dos opciones según la vigencia de la garantía: puede exigir a la empresa proveedora el cambio de esa máquina o puede que se deba enviar a reparar o comprar una nueva. En este apartado entran en juego los equipos de sustitución previamente mencionadas. En este caso también se pueden sustituir los equipos averiados por los de sustitución para que se pueda solucionar temporalmente la avería. 3.4. Incidencias proactivas La existencia de programas de monitorización de equipos de la red como puede ser Netmrg hacen posible el seguimiento continuo de estos elementos importantes. Al tratarse de una herramienta muy útil que nos provee de información muy valiosa del estado de los elementos junto con otras variables de las máquinas en cuestión, se asumirá su utilización en el casino. Como se ha mencionado anteriormente, esta herramienta permite la captura de parámetros configurables de las máquinas que se desean, como puede ser el estado del disco duro. De esta forma se hace posible la utilización de alarmas para adelantarnos a errores que se pueden surgir debido al agotamiento de la memoria del disco duro, por ejemplo. Este ejemplo nos da una pequeña idea de lo que son la incidencias proactivas. Se trata de las incidencias que se detectan automáticamente mediante herramientas desarrolladas específicamente para ello o por tanto, se comienzan a solucionar antes de que el usuario tenga constancia, pudiendo solventarlos antes de que se de cuenta. La introducción anterior nos da una pequeña visión de lo que pueden hacer este tipo de herramientas. Pero como se han de gestionar las alertas que provienen de estas herramientas?. Esa es la cuestión que pretende aclarar este punto. De hecho, las incidencias que provienen de esta herramienta se reciben en el primer nivel. 3.4.1. Primer nivel La diferencia entre el primer nivel de las incidencias proactivas y reactivas es que, mientras que en el primer caso las incidencias abre un cliente o trabajador, en el caso de las proactivas, incidencias se reciben automáticamente mediante la utilización software específico para ello. las las las de En nuestro caso en particular, cuando el programa Netmrg detecte una incidencia con cualquier elemento de la red, se pondrá en marcha una aplicación automática que enviará al primer nivel un formulario rellenado con los datos conocidos para que se tenga constancia y se actúe. De esta forma, el primer trabajo del operador de este nivel será la de cumplimentar los datos que faltan por rellenar en el formulario que el sistema no haya podido 42 cumplimentarlos adecuadamente y seguir el mismo procedimiento que con las reactivas. Añadir que la única diferencia de tratamiento que existe entre ambos tipos de incidencia es que en este caso no hay que contactar con ninguna persona al cerrar la incidencia. Este hecho será reflejado en el formulario, que no dispondrá de estos campos. Cabe recordar que aunque se haya detectado una incidencia proactiva repentinamente, algún usuario ha podido darse cuenta y lo comunicará al Service Desk. Por este motivo, conviene que el Service Desk tenga constancia de ello para cuando el cliente llame. 3.4.2. Segundo y tercer nivel Estos dos niveles se comportan exactamente igual que las de las incidencia reactivas. 3.5 Ciclo de vida de las incidencias Se trata de una serie de estados conectados por transiciones. De este modo, el ciclo de vida representa un proceso aprobado para la Gestión de Configuración, Informe de Problemas y documentos de cambios. 43 3.6. Estado de las incidencias El estado de una incidencia muestra en que posición se encuentra en el ciclo de vida de una incidencia (esquema mostrado anteriormente). Todos los miembros deberían conocer el estado la misma y conocer perfectamente su significado. En nuestro caso, los estados son los siguientes: Nueva: Cuando la incidencia no ha sido analizada todavía Aceptada: Se ha analizado y se ha considerado válida Programada: Cuando se ha dejado para más tarde Asignada a operador: Cuando se le haya asignado un experto en concreto Trabando en ella: Cuando en ese momento se este buscando la solución Esperando: Este estado identifica el hecho de que la incidencia queda parada debido a que el equipo que soluciona la incidencia está esperando algún movimiento exterior (que el proveedor realice alguna acción, a la espera de nuevos materiales…) Resuelta: Cuando este resuelta pero falte la última confirmación Cerrada: Cuando se haya resuelto y se tiene la confirmación Es importante mantener la información del estado de la incidencia por su ciclo de vida. Para ello, se implementarás y almacenará el estado y comentarios que se le han asignado en cada momento, por si puedan ser utilizables en otro momento. 3.7. Roles en la gestión de incidencias Los procesos abarcan por completo la jerarquía de la organización. Por tanto, es importante definir las responsabilidades asociadas con las actividades que tienen que desarrollar el proceso. Para continuar con la flexibilidad, es importante definirlas adecuadamente. Los roles que definimos para nuestro caso ese l siguiente: 3.7.1. Director de incidencias Este rol ha de hacer frente a las siguientes responsabilidades: • Estabilizar la eficiencia y la ineficiencia del proceso del a Gestión de Incidencias. • Redactar la información necesaria para la gestión. • Gestionar el trabajo de los trabajadores del soporte de Incidencias. • Monitorizar la ineficiencia de la Gestión de Incidencias y realizar recomendaciones de mejoramiento basándose en ellas. 44 • • Desarrollar y mantener los sistemas de Gestión de Incidencias. Supervisar y asegurar el buen funcionamiento del Service Desk. 3.7.2. Personal de la gestión de incidencias Las responsabilidades de los trabajadores de esta área del primer nivel son: Registro de incidentes Enrutado de las incidencias no cerradas a los grupos de soporte Soporte y clasificación inicial Resolución y recuperación de los incidentes no transferibles al segundo nivel Cierre de incidentes De la misma forma, al personal del segundo nivel le corresponde: Encargarse de los service request Monitorizar los detalles de las incidencias Investigación y diagnóstico de los incidentes Resolución y recuperación de los incidentes asignados 3.8. Actividades de la gestión de incidencias El proceso que se implementará en Sincitiy para la gestión de las incidencias es el mismo que ITIL nos plantea, y vamos a modelarlo en este apartado para adaptarlo de la mejor manera a lo que la empresa necesita. 3.8.1. Identificación y registro de la incidencia Es el punto de entrada del sistema de gestión de incidencias, y lo trataremos como un input. Una vez recibimos este input, los tres primeros pasos a realizar deben ser los siguientes: Alertar al equipo de soporte necesario. Ejecutar las primeras acciones para la solución de la incidencia Es muy importante tener bien registrada la incidencia. Se utilizarán unos formularios en los que se tendrá que rellenar la información más importante necesaria para el tratamiento de ello. Esa información será recogida por el Help Desk y se tendrá que rellenar el formulario que contendrá la siguiente información: Identificador único (se auto-asignará). Clasificación de la incidencia. Fecha y hora (se auto-asignará). Persona que abre la incidencia. Información del usuario que tiene la incidencia (como mínimo 45 nombre y forma de contacto). Descripción de los síntomas. Prioridad. Estado de la incidencia. Persona que está trabajando en la incidencia. Problema conocido asignado. Fecha resolución. Fecha clausura. Los últimos 4 puntos, a la hora de ser abiertos van a permanecer vacíos. 3.8.2. Clasificación y suporte inicial Una vez abierta la incidencia, se dispone a clasificarla, para poder tratarla con más exactitud. En este punto se clasifica la incidencia con algún problema conocido (si existe) que hay guardado en la base de datos de incidencias y problemas, se le asigna la prioridad final, que puede variar a la inicial dependiendo del caso. La clasificación de la incidencia debe tener: Categoría. Las categorías en las que lo podremos clasificar son: Hardware, para incidencias con los equipos. Software, para incidencias relacionados con los programas Incidencias de comunicaciones, relacionados con incidencias en la red, la telefonía, los sistemas DECT... Impacto. Cada incidencia tiene un impacto diferente a la empresa: Alto, afecta al servicio de Sincity de forma grave (dejando sin operatividad alguno de los servicios ofrecidos...) Medio, afecta al servicio directo pero de forma leve. Bajo, no afecta al servicio de forma directa. Urgencia. Cada incidencia deberemos asociarlo a una urgencia, que irá muy ligada a los SLAs que habremos creado en la gestión de nivel de servicio. Este campo indicará con que rapidez se tendrá que dar solución a esta incidencia. El Help Desk, aunque no sea el grupo que está tratando la incidencia, si es el responsable del contacto con el usuario. Debe intentar dar el primer paso en lo que a soporte se refiere, buscando las soluciones más sencillas para la incidencia y comprobando que no sea un error de rápida solución. Debe efectuar de filtro para esas incidencias que no son necesarias el nivel 2. 3.8.3. Diagnostico Mientras al usuario se le da, si es posible, una solución alternativa, como 46 por ejemplo una versión anterior, se estudia como solucionar y volver la normalidad al usuario. El equipo de la gestión de la incidencia debe aportar la siguiente información mientras trabaja con ella: Aceptar la incidencia y proveer de una fecha estimada de resolución. Aportar información del estado de la incidencia (renovando la historia). Contactar con el Help Desk si se encuentra solución alternativa. Revisar y comprobar que no haya un problema conocido asociado. Reasignar la incidencia al Help Desk cuando lo haya solucionado. 3.8.4. Resolución Una vez tenemos una solución para la incidencia, se realizan las tareas necesarias y una vez restablecido el sistema, se reasigna la incidencia Help Desk que será la que se pondrá en contacto con el usuario y dejará la incidencia como solucionada. 3.8.5. Cierre de la incidencia Se le informa al usuario que la incidencia está solucionada, y que deberá ser él el que una vez comprobado que todo vuelve a funcionar, debe cerrar la incidencia. Todo este ciclo de vida es monitorizado por el Service Desk, que irá informando al usuario del estado de la incidencia periódicamente vía mail o teléfono. 3.9. Tipo de incidencias I1: Fallo en una máquina recreativa (que la máquina no se encienda, que el hardware no funcione correctamente, que esté rota, que se apaga, que no acepte tarjetas.....) I3: Fallo en alguna cámara de seguridad I4: Fallo con la tarjeta del usuario I5: Fallo de la máquina para cargar o recoger dinero ATM I6: Fallo de alguna máquina de bonus en tiempo real (interconectado con otras máquinas recreativas de otros casinos) I7: Fallo en el sistema cashless I8: Fallo de alguna máquina de informática corporativa. I9: Fallo de algún teléfono DECT I10: Una máquina no recoge estadísticas I11: Un teléfono móvil no funciona o tiene problemas I12: Fallo en el sistema de player tracking Antes de ver cada tipo de incidencia por separado, detallando más cada uno de ellos, vamos a definir las criticidades marcadas en el marco de ITIL para Sincity: 47 NÚMERO Criticidad 1 NIVEL Muy alta DEFINICION Son las que provocan un fallo de seguridad que pone en peligro al casino o un fallo que impide el desarrollo de la actividad de Sincity de forma total. NÚMERO Criticidad 2 NIVEL Alta DEFINICION Son las que provocan un fallo de seguridad leve o un fallo total en alguna de las actividades de Sincity NÚMERO Criticidad 3 NIVEL Normal DEFINICION Son las que provocan un fallo de forma no total en alguna de las actividades de Sincity. NÚMERO Criticidad 4 NIVEL Baja DEFINICION Son las que provocan un fallo que no repercute de forma directa a las actividades de Sincity Una vez vistos los criterios de criticidad que pueden ser asignados a cada una de las incidencias vamos a tratar ahora cada una de los grupos de incidencias entrando más en su detalle, para estudiar el valor de criticidad y conocerlas de manera exacta. CATEGORIA INCIDENCIA 1 TIPO INCIDENCIA Error en una maquina recreativa 48 DESCRIPCIÓN Que una máquina recreativa falle ya sea a nivel de software como de hardware, impidiendo su función de forma normal CRITICIDAD 2 - Alta AREAS AFECTADAS El servicio de Sincity Dependiendo del error, puede ser de RESPONSABLE DE SOLUCIÓN operaciones (una máquina no enchufada...) o de sistemas (si falla el software...) CATEGORIA INCIDENCIA 2 TIPO INCIDENCIA Fallo en cámara de seguridad DESCRIPCIÓN Una cámara de seguridad deja de operativa o por algún motivo CRITICIDAD 1 - Muy alta AREAS AFECTADAS Seguridad del casino ser Si falla la red o el software lo arregla RESPONSABLE DE SOLUCIÓN sistemas, si el error es de la propia cámara el problema lo soluciona operaciones CATEGORIA INCIDENCIA 3 TIPO INCIDENCIA Fallo de la tarjeta del usuario DESCRIPCIÓN La tarjeta cashless del usuario tiene algún problema CRITICIDAD 3 – Normal AREAS AFECTADAS El servicio de un usuario de Sincity RESPONSABLE DE SOLUCIÓN Operaciones 49 CATEGORIA INCIDENCIA 4 TIPO INCIDENCIA Fallo de la máquina para cargar o recoger dinero ATM DESCRIPCIÓN Una de las ATM no efectúa sus actividades de forma normal CRITICIDAD 2- Alta AREAS AFECTADAS El servicio de Sincity RESPONSABLE DE SOLUCIÓN Operaciones si es error del hardware de la máquina o de sistemas en caso opuesto CATEGORIA INCIDENCIA 5 TIPO INCIDENCIA Fallo en alguna máquina de tiempo real DESCRIPCIÓN Las máquinas para partidas online con otros casinos no funciona de forma correcta, ya sea por error de hardware o de software CRITICIDAD 2- Alta AREAS AFECTADAS El servicio de Sincity RESPONSABLE DE SOLUCIÓN Operaciones si es error del hardware de la máquina o de sistemas en caso opuesto CATEGORIA INCIDENCIA 6 TIPO INCIDENCIA Fallo en el sistema de cashless DESCRIPCIÓN El servicio de cashless deja de funcionar CRITICIDAD 1- Muy alta AREAS AFECTADAS El servicio de Sincity RESPONSABLE DE SOLUCIÓN Sistema de Información 50 CATEGORIA INCIDENCIA 7 TIPO INCIDENCIA Fallo en alguna máquina de informática cooperativa DESCRIPCIÓN Existe algún error en alguno de los PCs utilizados por los departamentos internos de la empresa CRITICIDAD 4- Baja AREAS AFECTADAS Departamentos internos RESPONSABLE DE SOLUCIÓN Operaciones o sistemas de Información CATEGORIA INCIDENCIA 8 TIPO INCIDENCIA Fallo de algún teléfono del servicio DECT DESCRIPCIÓN Los teléfonos DECT o alguno de ellos deja de funcionar CRITICIDAD 4- Baja AREAS AFECTADAS Departamentos internos RESPONSABLE DE SOLUCIÓN Operaciones si es el propio teléfono o sistemas de Información si es de la red DEC CATEGORIA INCIDENCIA 9 TIPO INCIDENCIA Máquina no recoge estadísticas DESCRIPCIÓN El servicio de recogida de estadísticas deja de funcionar. Una o varias máquinas no dan información. CRITICIDAD 2- Alta 51 AREAS AFECTADAS Operaciones/Marketing/Finanzas RESPONSABLE DE SOLUCIÓN Sistemas de Información CATEGORIA INCIDENCIA 10 TIPO INCIDENCIA Fallo en un teléfono móvil DESCRIPCIÓN Alguno de los teléfonos móviles dejan de funcionar o lo hacen incorrectamente CRITICIDAD 4- Baja AREAS AFECTADAS Departamentos internos RESPONSABLE DE SOLUCIÓN Operaciones CATEGORIA INCIDENCIA 11 TIPO INCIDENCIA Fallo en el sistema de player tracking DESCRIPCIÓN El servicio de ‘player tracking’ no funciona o lo hace de forma incorrecta CRITICIDAD 2- Alta AREAS AFECTADAS El servicio de Sincity RESPONSABLE DE SOLUCIÓN Sistemas de información Las tablas de arriba no son un patrón que se tenga que seguir estrictamente. Especialmente la criticidad, que las tablas muestran un valor medio para un caso general, pero que dependerá puntualmente de muchos otros factores, como puede ser la persona de la incidencia (no es lo mismo que falle el móvil del presidente que el de un becario), del número de personas/equipos afectados, del día... Tiene que ser responsabilidad de la persona que abre la incidencia en el Help Desk asignarle una criticidad a cada una de las incidencias. Si se considera que es un caso general se le aplica la tabla arriba especificada, pero si se trata 52 de un caso especial (por lo descrito anteriormente o porque la persona con el rol más importante del Help Desk lo solicita). 3.10. Gestión de problemas En este apartado vamos a definir la gestión de los problemas que tenemos en Sincity. Este apartado va a ir muy relacionado con el anterior, la gestión de incidencias, ya que muchas veces es difícil saber donde está la frontera entre ellos. Por eso, vamos a tener que diferenciarlo antes de entrar más en detalle. La gestión de los problemas es crucial en cualquier empresa. Tiene relación no solo con la disponibilidad de servicio, sino que también es clave para mantener el nivel de SLA y no tener que pagar. En una empresa en la que no exista una buena gestión de los problemas, no podrá ofrecer un nivel de SLA tan alto o no va a ser capaz de llegar al nivel acordado. 3.10.1. Diferenciación entre problema e incidencia Es importante saber diferenciar bien lo que tratamos como problema o como incidencia. Muchas veces se generan confusiones y no se sabe si se está hablando de incidencia o de problema. Debido a este error, el proceso de solución del evento se retrasa o se puede hacer de forma incorrecta debido al caos generado. Por lo tanto, definiendo bien lo que es cada cosa podremos saber de antemano con que estamos tratando, y por lo tanto agilizaremos el proceso. ITIL define que la diferencia entre gestión de problemas y gestión de incidencias es que en el primer caso el objetivo es saber y detectar la causa que genera una incidencia así como buscar la solución y prevención. Aunque difieren en definición, su objetivo es el mismo; dar el servicio de forma correcta al cliente, y solucionar de la forma más eficiente cada fallo que se genere en nuestros sistemas. La resolución de un problema acostumbra a llevar más tiempo de resolución que una incidencia. 3.10.2. Actividades control reactivo de problemas Hay incidencias que son inevitables. Partimos de la idea que en un sistema de telecomunicaciones la existencia de incidencias es imposible de evitar. Muchas de estas incidencias son debidas a fallos puntuales totalmente imprevisibles, que nos causarán problemas hasta que le apliquemos una solución. Pero muchas de las veces, las incidencias son debidas a problemas ya existentes. El control de problemas reactivo consiste en la identificación de la causa que genera un número de incidencias con la finalidad de evitar más incidencias y solucionar las existentes. La forma en que controlamos estos problemas va a determinar como de ágil y de óptimo tratamos el problema. Hacerlo de forma correcta 53 nos va a beneficiar en el aspecto de trabajar los problemas más rápido, ya que evitaremos los caos que muchas veces hay en las empresas cuando suceden este tipo de eventos. Tres pasos son en los que Sincity va a basar el control reactivo de los problemas y que establece ITIL: 3.10.3. Identificación y registro del problema La identificación de los problemas se tendrá que realizar cuando: Una misma incidencia sea recurrente. Cuando exista una incidencia a la que no existe aun un problema conocido. Analizando la red, encontramos un problema que pueda generar incidencias. Cuando aparezca un incidente grave que se tenga que solucionar de forma rápida. Cuando en la fase inicial de una incidencia no podamos clasificar la misma en ninguno de los problemas conocidos. La siguiente imagen muestra cual es el proceso de identificación de un problema. Se tendrá que seguir los siguientes pasos para saber si con esta incidencia tenemos que relacionarla a un nuevo problema. 54 Cuando llega una nueva incidencia, tenemos que comprobar si se trata de un error rutinario y con una solución simple o no. En caso que no lo sea, tendremos que comprobar en nuestra base de datos de incidencias y problemas si ya existe solución a este problema. En caso de encontrarlo, se procede con la solución si no es necesario soporte con el equipo de gestión de problemas (habitualmente, serán casos muy simples). Si el problema no se encuentra en nuestra base de datos de incidencias y problemas, se procederá a la apertura de una alerta de nueva incidencia. Automáticamente, el equipo de gestión de problemas va a ser avisado de esta alerta y se precederá a seguir con el proceso de la gestión de problemas tanto si tenemos uno de nuevo como uno que necesite de soporte. La identificación del problema puede haber sido realizada por personal que no pertenece al equipo de gestión de problemas. En tal caso, una vez registrado el problema, el usuario o persona que haya identificado el problema debe de avisar inmediatamente al equipo de gestión de problemas. 3.10.4. Clasificación del problema Una vez identificado y registrado el problema, tenemos que clasificarlo. Este aso nos va a ayudar a evitar problemas de desconocimiento de situación, para que se entienda mas bien con que problema estamos 55 delante. En este sentido, no solo hace falta clasificarlo por el tipo, sino que tenemos diferentes clasificaciones que ahora pasamos a detallar. Categoría. Las categorías en las que lo podremos clasificar son: o Hardware, para problemas con los equipos. o Software, para problemas relacionados con los programas o Problemas de comunicaciones, relacionados con problemas en la red, la telefonía, los sistemas DECT... Impacto. Cada problema tiene un impacto diferente a la empresa: o Alto, afecta al servicio de Sincity de forma grave (dejando sin operatividad alguno de los servicios ofrecidos...) o Medio, afecta al servicio directo pero de forma leve. o Bajo, no afecta al servicio de forma directa. Urgencia. Cada problema deberemos asociarlo a una urgencia, ue irá muy ligada a los SLAs que habremos creado en la gestión de nivel de servicio. Este campo indicará con que rapidez se tendrá que dar solución a este problema. 3.10.4.1. Investigación y diagnóstico del problema Una vez identificado y clasificado el problema, podremos empezar a actuar para solucionarlo. La investigación del problema es similar a la explicada en la investigación de las incidencias, con la diferencia que el objetivo es diferente. En este caso, lo que vamos a buscar es la causa que genera las incidencias, mientras que en las incidencias buscamos el reestablecimiento del sistema. Una vez somos conscientes del problema, pasamos a solucionarlo. En caso de que no sea un problema conocido, se tiene que insertar en la base de datos de incidencias y problemas el informe correspondiente a este nuevo evento, para que la próxima vez que volvamos a tener este problema podamos solucionarlo de una forma más rápida y eficiente. Para analizar el problema, se utilizará la técnica de Kepner and Tregoe. Esto consiste en separar la tarea del análisis en 5 pasos: Definición de el problema. Se define de forma concreta cual es el problema, anotando en que sentido se desvía de los SLAs. Descripción del problema. Se describe el problema según los siguientes parámetros: o Identidad, cual es el problema y que es lo que falla. o Localización, donde ocurre el problema. o Tiempo, cuando empezó el problema, cuantas veces ocurre, con que frecuencia. o Tamaño, cual es el alcance del problema, cuantas partes están afectadas. Lista de posibles causas. Se define una serie de posibles causas al 56 problema definido. Estudio de la causa mas probable. Se marcan si cada una de las posibles causas pueden relacionarse con todos los sintomas. Verificación de la causa. Una vez filtradas las posibles causas, cada una de ellas debe ser verificada como la fuente del problema. Se realiza la verificación intentando dar elmismo servicio pero sin el elemento que puede ser causa del problema (con otra versión, otro aparato...). Utilizando esta técnica, vamos a poder trabajar ordenadamente para encontrar la causa y solución al problema. 3.10.6. Control de errors El control de errores es un proceso que se basa en la corrección de errores previamente conocidos. Se entienden como errores conocidos las incidencias y los errores cuya causa raíz es conocida y para los que se tiene identificada una solución temporal Work-around o una permanente. El objetivo final de este proceso es cambiar componentes IT para eliminar errores conocidos que afectan la infraestructura IT y de este modo, prever incidencias recurrentes. Veamos con la ayuda de un diagrama como funciona el proceso de control de errores. 57 Expliquemos los diferentes apartados del diagrama. 2.6.1.- Identificación y registro de errores: Un error es identificado cuando se detecte un artículo de configuración (CI) defectuoso. Posteriormente, se le asigna un estado de error conocido una vez que la causa del error haya sido encontrada y se haya identificado un Work-around para ella. Existen dos posibles fuentes de datos de errores conocidos que suministra el sistema de control de errores. La primera es el subsistema de control de problemas en entornos de tiempo real y la segunda, el mismo subsistema, pero esta vez en entornos de desarrollo. La segunda fuente surge de la fase de desarrollo de aplicaciones. Por ejemplo, el desarrollo de nuevas aplicaciones puede generar errores conocidos pero sin resolverse. Por este motivo, este tipo de errores han de ser comunicados al entorno que trabaja en tiempo real cuando dicha aplicación sea puesta en marcha o implementada. Puede que varios departamentos de IT se vean envueltos en esta secuencia, y no sólo una, por lo que la coordinación ha de ser adecuada. 2.6.2.- Evaluación del error: 58 El personal de la gestión de problemas realiza una primera evaluación del error, contando para ello, con el personal especializado. Los problemas en productos mantenidos por el proveedor han de ser identificados por la gestión de problemas o grupos de soporte especializados. Después han de ser comunicados a la persona responsable del soporte del proveedor. Mientras se espera la solución, se ha de monitorizar el soporte dado por el suministrador para comprobar si la respuesta al problema llega en un tiempo razonable. Cuando el software tiene tiempo límite para solucionar los problemas por parte del proveedor, estos suelen especificarse en un contrato o en las condiciones de la licencia. En este caso, los remedios a los problemas han de ser iniciados por la misma tercera parte en caso de que no pueda solucionar el problema en el plazo especificado. De todas formas, de la corrección de errores de este software ha de hacerse cargo el mismo proveedor de así indicarlo las condiciones. 2.6.3.- Registro de la solución del error El proceso de resolución de un error conocido ha de registrarse en el sistema de Gestión de Problemas. Es vital que los datos como el CI (Configuration Item), síntomas y la resolución sean almacenadas en la base de datos de Errores Conocidos. Estos datos serán posteriormente usados para combinar incidentes, proveyendo de esta forma, guías para resoluciones futuras para la resolución de incidentes. 2.6.4.- Cierre de error Después de haber implementado cambios para resolver errores y haber visto que funcionan, el registro de ese error se cierra junto a cualquier incidente o error asociado. Se insertará un campo en la base de datos para insertar el estado del PIR (Post Implementation Review). El PIR consiste en un análisis para comprobar que los arreglos llevados a cabo anteriormente han funcionado realmente. Este campo dirá si se ha llevado este análisis o no. En el caso de las incidencias, sólo habrá que llamar al usuario para comprobar que esta contento. De todas formas, para problemas más serios, habrá que realizar una revisión más formal. 2.6.5.- Monitorización de la solución de problemas/errores La gestión de Problemas ha de monitorizar en todo momento para realizar informes regulares y medir el impacto de los problemas en el servicio al usuario. Del mismo modo, la resolución de problemas se ha de monitorizar y comparar con los SLAs, para que se hagan cumplir. Además de existir en el SLA una número máximo de errores activos en un determinado área en un intervalo de medida concreto, se ha de cuidar también este aspecto. 2.6.7.- Puntos a tener en cuenta a la hora de realizar el control de errores No hay por que solucionar todos los errores conocidos. Se pueden dejar para más tarde algunos errores conocidos si la resolución es demasiado complicada, demasiado caro, técnicamente imposible o requiere demasiado tiempo. En la práctica, el control de errores se 59 basa en seleccionar inversiones justificables para resolver un problema. Una de las responsabilidades del control de errores es la de preparar RFCs. Se han de crear registros de errores estándares clasificados por categorías o por dispositivos concretos para fallos rutinarios de hardware. Esto nos puede ayudar para realizar cálculos sobre tiempo medio entre fallos y tiempo medio que se encuentra fuera de servicio. Si para solucionar un error se ha tenido que crear una herramienta específica, se ha de poner a disposición del resto de trabajadores. 3.10.7. Gestión de Problemas Proactivos Las actividades descritas hasta el momento en los temas Gestión de Errores y Problemas son mayoritariamente reactivos. De la misma forma que ocurre con las incidencias, las actividades de gestión de problemas Preactivos concierne la identificación y resolución de problemas y errores conocidos antes que ocurran los incidentes. De esta forma, se consigue minimizar el impacto adverso en el servicio y en el negocio que puedan tener. La prevención de Problemas comienza con la prevención de problemas individuales y llegan hasta las decisiones estratégicas. Este último aspecto puede que requiera de un mayor coste, como por ejemplo cambiar toda una infraestructura de comunicaciones para mejorar su comportamiento. La prevención de problemas también incluye facilitar información a los usuarios para evitar la necesidad de asistencia que puedan necesitar en un futuro. El proporcionar recomendaciones y herramientas como herramientas online a las personas que buscan soluciones hace que se reduzcan los tiempos de resolución de problemas. De esta forma, se reduce la duración de la espera de las llamadas en espera. Las actividades más destacadas de los procesos de Gestión de Problemas preactivos es el análisis de tendencia y la meta de las acciones preventivas. 2.7.1.- Análisis de tendencia El objetivo del análisis de tendencia es identificar componentes frágiles en la infraestructura IT e investigar las razones de la fragilidad. El análisis de incidencias y problemas puede identificar: Tendencias, como problemas particulares de cierto tipo después de cambios Defectos incipientes de un tipo en particular Problemas recurrentes de un tipo en particular o con un artículo individual 60 La necesidad de mejor documentación o entrenamiento de los clientes La categorización de las incidencias y problemas y el análisis creativo puede revelar y guiar a la identificación de áreas de problemas específicos que necesiten de investigación futura. Por ejemplo, los análisis pueden mostrar que las incidencias relacionadas con la usabilidad del software recién instalado crean el área con mayor crecimiento en el impacto negativo en el negocio. Para realizar el análisis se utilizarán herramientas automáticas, que mediante estadísticas pueden sacar a la luz aspectos no apreciables a simple vista. Los datos que sean necesarios para que esta herramienta funcione han de ser proporcionados mediante la recopilación automática de datos de los problemas e incidencias. 2.7.2.- Acciones preventivas Los datos que derivan de estos análisis han de ser posteriormente tratados para sacar conclusiones y actuar en consecuencia. Es importante tener en cuenta cuales son las áreas de problemas que requieren más atención. Este impacto puede ha de ser medido con el factor “pain” que tiene en cuenta, entre otros aspectos, el volumen de incidentes, el número de clientes afectados, la duración y el coste de resolver la incidencia y, por último el coste al negocio. De esta forma se pretende evitar que se haga demasiado esfuerzo y utilicen demasiados recursos en un grupo de incidentes que constituyan un gran número de ellas pero el impacto sea el mínimo. Después de que se hayan identificado los áreas que requieren mayor atención, la gestión de Problemas ha de actuar de la siguiente manera: Aumentar un RFC Aumentar el feedback respecto al testing, procesos, entrenamiento y documentación Realizar una educación y entrenamiento inicial de los clientes Realizar una educación y entrenamiento inicial de los trabajadores del Service Support Asegurarse de la adherencia de la gestión de problemas y Gestión de Incidente 2.7.3.- Pautas para la Gestión de Problemas El análisis de las tendencias esta sujeto a disponer de la suficiente información como para realizarlo. Los documentos de los proveedores proveen de información inherente sobre los problemas que puedan surgir. Por este motivo hay que analizar estos documentos detalladamente para detectar problemas de hardware antes de que ocurran. Se deben llevar a cabo investigaciones de lo que se ha hecho 61 bien y mal, para que la próxima vez no se repitan los errores. 3.10.8. Informes de históricos Es importante tener actualizada la base de datos con un historial de los acontecimientos que suceden en relación a los problemas, y formar así una especie de enciclopedia de problemas. Vamos a guardar la siguiente información: INFORME DE CONTROL DE PROBLEMAS / ERRORES. Control de los SLAs, anotando si se cumplen, si no se consiguen o si se mejoran. > informe estadístico Número de problemas hasta que se cierra el problema raíz. > informe estadístico Descripciones de hechos asumidos durante la resolución de problemas. > informe de problemas También vamos a controlar una serie de variables que servirán para obtener informes y estadísticas: > informe estadístico o Número de problemas según estado, servicio, impacto y categoría. o Tiempo total para solucionar los problemas. o Tiempo medio y máximo para encontrar el problema. o Resoluciones temporales. Con la información obtenida se podrán generar estudios para cambios en el sistema. Estos informes tienen que ser realizados por el equipo de gestión de problemas y la periodicidad depende de la naturaleza del informe: Informes estadísticos: Una vez a la semana, actualizando los obtenidos hasta la fecha. Informes de problemas: Cada vez que se cierra un problema. 3.10.9. Roles en la gestión de problemas Determinar cual tiene que ser la estructura organizativa del equipo va a simplificar la tarea de saber y depurar las responsabilidades de cada uno. El equipo de gestión de problemas de Sincity va estar formado por: Director de problemas: tiene la responsabilidad de todo el proceso de las actividades de la gestión de problemas. Tiene las siguientes responsabilidades también: o Controlar la eficiencia de los procesos. o Dirigir al equipo de gestión de problemas. o Escoger al equipo y recursos para cada problema. o Controlar las actividades proactivas de gestión de problemas. Equipo de soporte 62 o o Problemas reactivos: Identificación del problema una vez les llegue la notificación. Investigar e identificar los problemas. Trabajar en los problemas más graves e investigar su problema raíz. Problemas proactivos: Identificar las fuentes de posibles problemas. Prevenir de las repeticiones de los problemas. Todo esta estructura va a venir dirigida por el director de sistemas de información, y puede estar sujeta a los cambios deseados por tal persona. 3.10.10. Lista de posibles problemas P1: Fallo de la red de las máquinas P2: Fallo de la red de las cámaras P3: Fallo de la red entre casinos P4: Fallo de la VPN P5: Fallo de elemento de red (router, switch...) P6: Fallo de conexión con su red de los cajeros ATM P7: Fallo del ADSL P8: Fallo de la red de DECT P9: Falla el programa del juego (software) Numero Posibles incidenc Criticidad problemas ia asociados Áreas afectadas Responsable solución 1 Servicio Operaciones Seguridad Sistema de información/Operacione s Servicio Operaciones 2 3 1 4 3 1,3,5,9 2,5,7 de 63 5 2 4,5,6,7 Servicio Sistema de información/Operacione s 6 3 1,3,4,5,7 Servicio Sistema de Información 7 1 1,3,4,5,7 Servicio Sistema de Información 8 4 3,4,5,7 Departamento Sistema de Información s internos 9 4 8 Departamento Sistema de Información s internos 10 2 1,3,4,5 Operaciones/ Marketing/Fin Sistema de Información anzas 11 4 Totalidad Departamento Operaciones s 2 Operaciones/ Marketing/Fin Sistema de Información anzas 12 1,3,4,5 Numero problema Áreas afectadas Responsable de solución 1 Servicio Sistemas de información 2 Seguridad Sistemas de información 3 Varios Sistemas de información 4 Varios Sistemas de información 5 Todos Sistemas de información 6 Servicio Sistemas de información 64 7 Departamentos internos Proveedor de servicios 8 Departamentos internos Sistemas de información 9 Servicio Sistema de información Los problemas no suelen tener criticidad, puesto que es la incidencia a cual le afectan la que lo marca. Es decir, cuando se abra una incidencia, se le asigna una criticidad. Esta criticidad puede venir pre-establecida con la incidencia, pero siempre hay que darle margen a la persona que lo ha abierto para que lo pueda modificar según su criterio. De esta forma, el operador puede ver que una incidencia es menos grave según su criterio. 65 4. GESTIÓN DE LA CONFIGURACIÓN 4.1. Objetivos El tipo de negocio que nos ocupa requiere una forma de trabajar muy eficiente y efectiva. Por ello, es necesario controlar en todo momento los servicios que se ofrecen y la infraestructura sobre la que se ofrecen. Mediante la gestión de la configuración se puede obtener un modelo lógico a través de la identificación, control y mantenimiento de los Ítems de Configuración (CI) existentes. Para esto se deben cumplir los siguientes objetivos: Identificar todos los activos (equipos) y las configuraciones que se utilizan en los casinos MGM y los servicios que ofrece. Proveer información detallada sobre la configuración para soportar otros procesos constituyendo así una base sólida para la Gestión de Servicios. Verificar los registros de la configuración en la CMDB con la configuración de la infraestructura real y corregir cualquier error. 4.2. Implementación de la gestión de configuración 4.2.1. Análisis de los sistemas existentes Mediante el análisis de los sistemas de configuración que se usan actualmente en MGM, los procesos y las funciones, se pueden extraer las necesidades generales de la empresa en términos de gestión de configuración. En este caso, el objetivo es normalizar todos los sistemas y procesos para que se use un sistema común, soportado por procesos consistentes. Para ello se implantará un sistema centralizado donde se almacenará y gestionará la configuración de los CIs de todos los casinos del grupo en una sola CMDB común para todos ellos. Dicho sistema deberá ser compatible con el resto de procesos de gestión de servicio debido a su interacción directa. Por otro lado, se revisarán todos los datos de configuración almacenados en los sistemas antiguos (documentos, bases de datos, ...) y se desarollará un plan de conversión al nuevo sistema. En la figura de la página siguiente se puede observar una aproximación general de infraestructura de cada casino, con la diferenciación de cada servicio que se deberá gestionar. 4.2.2. Elección de las herramientas a utilizar Una vez identificadas las necesidades, se elegirán las herramientas que más se ajusten. Para ello, se tendrá en cuenta la compatibilidad con las herramientas que se usen para soportar otros procesos de gestión de servicio, aunque normalmente se comercializa todo el paquete de herramientas integradas (service desk, incidencias y problemas, 66 configuración ...). En el caso de que fueran herramientas independientes, se debería de implementar una interfaz para la comunicación entre ellas. 67 Security cam Security System Security Guard 68 4.2.3. Diseño de la CMDB El diseño de la CMDB consiste en una primera identificación de los recursos que se desean almacenar para agruparlos en categorías y definir los atributos que contendrán. Estas categorías deben ser grupos representativos, y dentro se pueden definir diversos tipos, para una mayor especificación. En las siguientes tablas se muestran las categorías y los tipos que formarán la CMDB. Categorías Servidores Recreativas Recreativas Recreativas Recreativas Recreativas Tipos Cashless Player tracking Bonus Recreativas Video vigilancia Bonus Bellagio Luxor Grand Las Vegas Excalibur Isla del Tesoro Bellagio Planta 1 Planta 2 Planta ... Luxor Planta 1 Planta 2 Planta ... Grand Las Vegas Planta 1 Planta 2 Planta ... Excalibur Planta 1 Planta 2 Planta ... Categorías Recreativas Isla del Tesoro Tipos Planta 1 Planta 2 Planta ... Redes Cashless Player tracking Bonus Recreativas Video vigilancia Grabadoras targetas magnéticas DataCard Card Technology Advantage Elementos de red Routers Switches Bridges Hubs Cámaras de seguridad Bellagio Luxor Grand Las Vegas Excalibur Isla del Tesoro Aplicaciones Corporativas Recreativas Se ha elegido esta agrupación para reducir el número de CIs dentro de cada tipo y facilitar la gestión. Es decir, debido al número elevado de máquinas recreativas, se clasificarán por plantas (o zonas) dentro de cada casino, en vez de hacerlo por casinos directamente, ya que tendríamos más de 2000 ítems de cada tipo y esto dificultaría la gestión. En cuanto a los atributos de los CIs, la siguiente tabla muestra los que se han elegido y una breve descripción de cada uno de ellos. Los campos que posen un (*) será obligatorio rellenarlos al registrar por primera vez el CI. El resto de atributos se irán usando progresivamente con el paso del tiempo. Atributos Nombre* Número de serie* Descripción Nombre único que identifique al ítem Número de serie del ítem 69 Categoría* Una de las categorías definidas anteriormente Tipo* Un tipo de los definidos anteriormente Situación* Localización física del CI Modelo Modelo del hardware Proveedor* Proveedor del CI Fecha de adquisición* Fecha en la que se compró el CI Nombre del “padre” * Nombre(s) único de CI que están por encima y se relacionan Nombre del “hijo”* Nombre(s) único de CI que están por debajo y se relacionan Relación de parentesco* Tipo de relación entre CIs nombrados anteriormente. Número de problema Número único de los problemas que han afectado al CI Número de incidencia Número único de las incidencias que han afectado al CI RFCs Peticiones de cambio de configuración del CI Comentarios Comentarios adicionales que se quieran añadir 4.2.4. Implementación de la CMDB La implementación de la CMDB se hará tan pronto se tenga la información correspondiente a todos los CIs. Dicha información se obtendrá de forma automatizada mediante herramientas de “autodiscovery” y se completará manualmente. Durante el proceso de recolección de información, la configuración de los CIs no se modificará. De esta forma, se asegura que desde el momento de recolección hasta el momento de registro en la CMDB los CIs no han sufrido cambios en su configuración. No obstante, en entornos como el que nos ocupa, esta práctica puede ser difícil de realizar debido al gran número de CIs que se deben registrar en la CMDB. Por este motivo, en el caso de que sea esencial la modificación de la configuración de un CI ya registrado, se documentará dicho cambio para su posterior modificación una vez este implantada completamente la gestión de la configuración. En el caso del software, se almacenará también en la DSL (Definitive Software Library), donde residirán las copias legales y autorizadas de las aplicaciones utilizadas en la empresa. Solo el personal autorizado podrá añadir, eliminar o actualizar las aplicaciones que residan en la DSL. Además, se dispondrá de un espacio físico para el almacenaje seguro de las copias del software. 4.3. Roles, funciones y responsabilidades Los dos roles principales y que, por lo tanto, desempeñarán el papel más importante en la gestión de la configuración, serán el Configuration Manager y el Configuration Librarian. El primero se encargará principalmente del cumplimiento de los objetivos definidos al inicio y el segundo se ocupará de custodiar y guardar todas las copias de software y la documentación de los CIs. 70 Las responsabilidades específicas del Configuration Manager son, básicamente, la supervisión de todos los procesos que se deben de llevar a cabo para la implantación de la gestión de configuración y la toma de decisiones en los procesos mencionados. A continuación se listan las responsabilidades de forma más extensa: Evaluación de los sistemas de gestión de configuración existentes y el diseño, implementación y gestión del nuevo (o mejorado) sistema en términos de eficiencia y efectividad. Elección de una herramienta para soportar el modelo elegido, teniendo en en cuenta el presupuesto y el tiempo disponibles, así como los requisitos técnicos. Elección de los CIs que integraran la CMDB. Implementación de la CMDB, gestión y mantenimiento de la misma. Asegurar la máxima integridad por medio de backups. Control de acceso y privilegios, roles correctamente definidos. Informes de gestión, indicando sugerencias para resolver defectos en la configuración, análisis de impacto. Informes de estado de CMDB. Ayuda al reconocimiento de CIs que se ven afectados por un error que afecta a otro CI. Evaluación del impacto de los RFCs y autorización de estos, así como la actualización de dichos cambios en la CMDB. Auditorias para comprovar que la infraestructura física se corresponde con lo que se representa en la CMDB y realización de cambios si fuera necesario. En cuanto al Configuration Librarian, sus principales tareas son el control de la introducción, la identificación, el almacenamiento y la retirada de los CIs almacenados en la CMDB. Además también se encargará de ofrecer información del estado de los CIs, así como de nombrar, registrar, almacenar y distribuir los problemas de la CMDB. Con todo ello, sus responsabilidades específicas se listan a continuación: Apoyo en la preparación del plan de implantación de la gestión de la configuración. Creación de la DSL u otras zonas para el almacenaje de los CIs. Apoyo en la identificación de los CIs y las aplicaciones. Mantenimiento de la información del estado actual de los CIs. Remplazado de las copias de software. Almacenaje de las copias originales de software. Notificación a los usuarios de los cambios en las copias de software. Mantenimiento de información de los CIs que se verían afectados por un cambio de software. Apoyo en las auditorias de configuración. 71 5. GESTIÓN DE SEGURIDAD 5.1. Introducción La gestión de seguridad es el proceso de gestión de un definido nivel de seguridad de la información y servicios IT. Incluso gestiona las reacciones de los incidentes de seguridad. El objetivo fundamental de la gestión de la seguridad es garantizar la seguridad de la información. La gestión de seguridad es más que cerrar la sala dónde están los servidores o en escribir siempre una contraseña. Los incidentes de seguridad de la información son los eventos que pueden causar daño a la confidencialidad, integridad o disponibilidad de la información o en el proceso de la información. El valor de la información tiene que ser protegida. Estos valores son estipulados por la confidencialidad, la integridad y la disponibilidad. Confidencialidad: Proteger la información de accesos no autorizados o intercepciones ilegitimas. Integridad: La información que se transmite tiene que ser la misma que se recibe Disponibilidad: La información debe ser accesible cuando sea necesario. El objetivo de la gestión de la seguridad se divide en dos partes: Conocer los requerimientos de seguridad externos. La realización de los requisitos de la seguridad definidos en el acuerdo de nivel de servicio (SLA) y otros requisitos externos que se especifican en el apoyo de contratos, de la legislación y de cualquier política de seguridad impuesta. Conocer los requerimientos de seguridad internos, que es necesario para simplificar la gestión del nivel de servicio para la seguridad de la información. La entrada del proceso de gestión de la seguridad está formada por los SLAs con los requisitos especificados de seguridad, los documentos de la legislación y el soporte de contratos. Estos requisitos pueden también actuar como indicador dominante del funcionamiento (KPIs) que se pueda utilizar para la gestión de proceso y para la justificación de los resultados del proceso de la gestión de la seguridad. La salida da justificación de la información para la realización de los SLAs y un informe con las desviaciones de los requisitos. El proceso de la gestión de la seguridad tiene relaciones con el resto de los procesos ITIL. Sin embargo, en esta sección las relaciones más obvias serán las relaciones con el proceso de la gestión del nivel de servicio y al proceso de la gestión de incidencias. 72 5.1.1. Requisitos de Seguridad El control de los requisitos de seguridad consta de tres fases: - Implementación de Políticas. - Implementar la organización de seguridad - Informar La gestión de seguridad puede ser a nivel físico y a nivel lógico. La seguridad a nivel físico hace referencia a la protección del hardware e instalaciones donde se encuentren ubicados. En este nivel, la gestión de seguridad pasa por tener en cuenta los siguientes aspectos: - Incendios - Robos - Cortes en el suministro de la red eléctrica y/o datos La seguridad a nivel lógico hace referencia a la protección de software, la protección de los datos, procesos y programas. Este tipo de seguridad controla el acceso ordenado de los usuarios a la información, así como que dicho acceso esté autorizado. 5.2. Medidas de la gestión de seguridad 5.2.1. Control El objetivo del subproceso de control es organizar y manejar el proceso de la gestión de seguridad. Establece la estructura de la organización para preparar, aprobar y implementar las políticas de seguridad de la información, la asignación de las responsabilidades y implementar las medidas de seguridad. Es necesario tener analistas especializados en seguridad para realizar estas tareas. El marco de gestión de la seguridad define otros subprocesos para: el desarrollo de la planificación de la seguridad, la implementación de los planes de la seguridad, la evaluación y cómo los resultados de las evaluaciones se traducen a los planes de acción. Además, el marco de la gestión define cómo debe ser divulgado a los clientes. Las actividades que ocurren en el subproceso de control se resumen en la siguiente tabla. Actividades Control Implementar políticas Configurar Descripción Este proceso define los requisitos y las reglas específicos que tienen que ser resueltos para poner a la gestión de la seguridad en implementación. El proceso termina con POLICY STATEMENTS, documentos que especifican los requisitos o las reglas que se deben cumplir. la Este proceso configura la organización que 73 estructura de tendrá la seguridad de la información. Por la seguridad ejemplo en este proceso se instala la estructura de las responsabilidades. Este proceso termina con el MARCO de la GESTIÓN de la SEGURIDAD. Informar Se documenta todos los procesos realizados de forma detallada. Este proceso termina con el INFORME. En la siguiente figura podemos ver las actividades que se realizarán en el proceso de control. Es importante que las dos primeras actividades no estén ligadas porque no son secuenciales. Son actividades desordenadas y después de que hayan ocurrido estas la actividad de informar seguirá secuencialmente. 5.2.2. Planificación La planificación contiene las actividades que en cooperación con la gestión del nivel de servicio conducen a la seguridad de la información en el SLA. Además contiene las actividades que se relacionan con los contratos de soporte que son específicos para la seguridad (de la información). En la planificación, los objetivos formulados en el SLA se especifican en el apartado de los acuerdos del nivel de operaciones (OLA). OLA se puede definir como planes de la seguridad para una entidad interna específica de la organización del proveedor de servicio. Además del SLA, también trabaja con las policy statements del proveedor de servicio. Estas declaraciones de política (policy statements) se han definido en el subproceso de control. Los OLA para la seguridad de la información, se configura y se implementa basándose en el proceso de ITIL. Esto significa que tiene que 74 haber cooperación con los otros procesos de ITIL. Por ejemplo, si la gestión de la seguridad desea cambiar la infraestructura para alcanzar una seguridad máxima, estos cambios serán hechos solamente con el proceso de la gestión de cambio. La siguiente tabla muestra las diferentes actividades que se realizarán para la planificación. Actividades Planificación Crear sección seguridad para SLA Crear contratos soporte la de los de Crear los OLA Informar Descripción Este proceso contiene las actividades que conducen a los acuerdos de seguridad en el acuerdo del nivel de servicio. En el final de este proceso la SECCIÓN de la SEGURIDAD DE LOS ACUERDOS del NIVEL DE SERVICIO es creado. Este proceso contiene las actividades que conducen a los CONTRATOS de SOPORTE. Estos contratos son específicos para la seguridad. Los objetivos generales formulados en el SLA se especifican en ACUERDOS del NIVEL de OPERACIONES. Los OLA se pueden considerar como planes de la seguridad para las unidades específicas de la organización. Se documentan todos los procesos realizados de forma detallada. Este proceso termina con el INFORME. 5.2.3. Implementación La implementación se asegura de que todas las medidas, según lo especificado en la planificación, estén puestas en implementación correctamente. Durante la implementación no se define ni se cambia ninguna medida. Las actividades que ocurren se resumen en la tabla siguiente. Actividades Implementación Clasificar y gestionar los servicios IT Descripción Proceso de agrupar elementos de la configuración por tipo como por software, hardware, documentación, aplicación, etc. El proceso de identificar cambios por tipo como proyectos, petición de validación del cambio, petición del cambio de la infraestructura. Este proceso conduce a los DOCUMENTOS de CLASIFICACIÓN y CONTROL. 75 Implementar Medidas que se adoptan para dar seguridad del seguridad del personal y confianza y las personal medidas de prevenir un fraude. Este proceso se termina con la SEGURIDAD del PERSONAL. Implementar En los requisitos de seguridad y/o las la gestión de reglas específicas del proceso de la seguridad seguridad que deben ser resueltos se realizan y se documentan. Este proceso se termina con POLÍTICAS de la SEGURIDAD. Implementar En los requisitos de seguridad del el control de acceso y/o las reglas específicas del acceso proceso de la seguridad del acceso que deben ser resueltos se realizan y se documentan. Este proceso se termina con CONTROL de ACCESO. Informar Se documentan todos los procesos realizados de forma detallada. Este proceso termina con el INFORME. Para la implementación de la infraestructura de los procesos de seguridad debemos tener presente los aspectos más importantes para asegurar la seguridad en la red de los casinos MGM y las herramientas que mejor se adaptan. Para la política de seguridad se ha contemplado que en el servicio de redes se realizará con Firewalls y tuneles IPSec. Para la detección de debilidades se utilizarán antivirus y autenticación mediante RADIUS. 5.2.4. Evaluación La evaluación de la implementación y de la planificación es muy importante. La evaluación es necesaria para medir el éxito de la implementación y de la planificación de la seguridad. Es también muy importante para los clientes (y posiblemente los terceros). Los resultados se utilizarán para mantener las medidas que convengan. Los resultados de la evaluación pueden conducir a los nuevos requisitos y así a una petición de cambio. Principalmente hay tres clases de evaluación: la autovaloración, la intervención interna, y la intervención externa. Las actividades más importantes para esta evaluación son la supervisión de la seguridad de los sistemas IT y verificar si se cumplen la legislación y la implementación de los planes de la seguridad. Las actividades que ocurren se resumen en la tabla siguiente. Actividades Evaluar Descripción Autovaloración En este proceso se examinan los 76 acuerdos de seguridad puestos en ejecución. El resultado de este proceso es DOCUMENTOS de la AUTOVALORACIÓN. Intervención En este proceso se examinan los interna acuerdos de seguridad puestos en ejecución. Realizado por un analista interno. El resultado de este proceso es INTERVENCIÓN INTERNA. Intervención En este proceso se examinan los externa acuerdos de seguridad puestos en ejecución. Realizado por un analista externo. El resultado de este proceso es INTERVENCIÓN EXTERNA. Evaluación En este proceso se examinan los basada en acuerdos de seguridad puestos en incidencias de ejecución. Se realiza en incidencias en la seguridad la seguridad y que pueden causar una interrupción o una reducción de la calidad de ese servicio. El resultado de este proceso es INCIDENCIAS de la SEGURIDAD. Informar Se documentan todos los procesos realizados de forma detallada. Este proceso termina con el INFORME. Para conseguir controlar todos los aspectos de seguridad se va a utilizar una herramienta de gestión de seguridad que nos permitirá monitorizar todos los aspectos de gestión de redes. 5.2.5. Mantenimiento El mantenimiento de la seguridad es importante para que los procesos de seguridad sigan activos. Los riesgos, según los cambios que se realicen en la infraestructura IT, van cambiando. El mantenimiento afecta en la sección de seguridad de los acuerdos del nivel de servicio (SLA) y a la planificación de la seguridad. Las actividades que ocurren en el mantenimiento se resuman en la tabla siguiente. Actividades Descripción Mantenimiento Mantenimiento Proceso para mantener los acuerdos del de los SLAs nivel de servicio en condiciones apropiadas. El proceso termina con los ACUERDOS MANTENIDOS del NIVEL DE SERVICIO. Mantenimiento Proceso para mantener los acuerdos del de OLA nivel de operaciones en condiciones apropiadas. El proceso termina con ACUERDOS MANTENIDOS del NIVEL de 77 OPERACIONES. Petición de Petición de cambio al SLA y/o al OLA cambio de SLA formulada. Este proceso termina con una y/o OLA PETICIÓN para el CAMBIO. Informar Se documentan todos los procesos realizados de forma detallada. Este proceso termina con el INFORME. 5.3. Factores en la gestión de seguridad Para que la gestión de seguridad tenga éxito, los factores que se deberán cumplir serán los siguientes: Gestión de Confidencialidad, Integridad y Disponibilidad de Servicios IT Proporcionar seguridad a un coste razonable (“Cost Effective”) Implementación de mejoras de seguridad de forma proactiva Creación de una Política de Seguridad Elaboración de un Plan de Seguridad Las medidas y valores para evaluar los factores previamente definidos se pueden ver especificados en la siguiente tabla. Factores Medidas Gestión de Número de incidentes Confidencialidad, causados por fallos Integridad y Disponibilidad externos en la seguridad de Servicios IT Número de incidentes causados por fallos internos en la seguridad Proporcionar seguridad a un coste razonable Menor de 0,1% Porcentaje del coste de Inferior del 50% entrega por usuario de las del coste total de actividades de la infraestructura gestión de la seguridad Porcentaje del coste de entrega por usuario de las medidas de seguridad implementadas Implementación de mejoras de seguridad de forma proactiva Valores Menor de 0,1% Número de Iniciativas de mejora de Seguridad que están en proceso Número de Iniciativas de mejora de Seguridad que no han sido comenzadas Inferior al 2% sobre el coste total de las medidas de seguridad Inversión del 5% cada mes en seguridad Menor al 3% 78 Creación de una Política de Determinar los informes Seguridad que deben ser emitidos Elaboración de un Plan de Seguridad Cada semana Responsables y Roles para cada uno de los subprocesos ACL para asignar permisos dependiendo del rol (accesos correctos mayores del 99,999%) Establecimiento de normas de acceso Definidas mediante ACL Establecimiento de los protocolos de seguridad Definidos y documentados antes de la implementación Fijar niveles de SLA y OLA Se definirá una clausula 79 6. HERRAMIENTAS UTILIZADAS 6.1. Help Desk, HP Openview Service Desk HP Openview Service Desk es una solución basada en el estándar ITIL y en la larga experiencia de gestión de servicio de HP, que permite implementar procesos globales de soporte y provisión de servicios de TI. Integra la gestión de procesos como incidencias, problemas, configuraciones, etc. Permite a los diferentes departamentos de TI trabajar conjuntamente y compartir información para asegurar que los servicios críticos se provisionan y soportan correctamente, ayudando a mantener su ventaja competitiva. Una estrategia adecuada de gestión del servicio ayuda a las organizaciones de soporte a funcionar como un service desk preventivo. Así, el impacto exacto de las incidencias se conoce de inmediato y el service desk dispone de la información y de las herramientas correctas para reestablecer el servicio antes de que los usuarios finales experimenten ninguna dificultad. 6.1.1. GESTIÓN DE INCIDENCIAS HP OpenView Service Desk permite al soporte de primera, segunda y tercera línea resolver rápidamente las incidencias. A través de su estrecha integración con otros procesos de Service Desk los especialistas tienen acceso inmediato a otra información importante: errores conocidos, problemas o cambios asociados al elemento de la incidencia, etc. El acceso a esta información hace aumentar el ratio de llamadas resueltas en el primer contacto, mejorando la productividad tanto del usuario final como del personal de soporte. HP OpenView está bidireccionalmente integrado con otras soluciones de gestión de HP OpenView de manera que se tratan las incidencias rápidamente y con el apropiado orden de prioridad para evitar incumplir o conseguir restablecer el nivel de servicio acordado (SLA). 6.1.2. GESTIÓN DE PROBLEMAS Por gestión de problemas se entiende a menudo gestión de calidad porque el proceso se centra en analizar las llamadas y las incidencias para detectar una pauta. Estos patrones permiten identificar las causas que provocan las incidencias dentro de la infraestructura y en este proceso son resueltos. La base de datos interna de la aplicación así como la integración con bases externas de conocimiento ayuda al usuario a identificar los problemas con más efectividad. 6.1.3. GESTIÓN DE CONFIGURACIONES HP OpenView Service Desk controla los elementos de configuración durante todo su ciclo de vida, proporcionando información a otros 80 procesos como gestión de problemas y de cambios. Incluye también acceso a la información de contratos de servicio y soporte, relaciones entre los EC y la información del personal de la organización. Captura de pantalla de HP Open View, la herramienta seleccionada 6.2. Monitorización, NETMRG La monitorización de los elementos que van a formar parte de nuestra red, va a ser realizada por la aplicación NetMRG. NetMRG es una herramienta open-source para la red que supervisa, alerta, y representa gráficamente el estado de nuestra red. Basado RRDTOOL, la mejor herramienta open-source para representar sistemas gráficos, NetMRG es capaz de crear gráficos de cualquier parámetro de la red. NetMRG está construido desde el punto de vista de un ISP, creando gráficos de los elementos que entienden SNMP. NetMRG “pregunta” a los elementos SNMP, que va a almacenar la información para generar las estadísticas y gráficas. Sus puntos fuertes son: Herramienta open-source. Funcionalidad de slide-show, que permite ir pasando dispositivo por dispositivo automáticamente Uso de plantillas, que facilita la inserción de nuevos dispositivos. 81 Aviso cuando alguno de los sistemas tiene comportamientos anómalos. Permite especificar los momentos en que habrá más movimiento en la red, para que la herramienta sepa si el comportamiento es normal o no. Puede almacenar información por SNMP, Sql o scripts. Captura de pantalla de NetMRG, la herramienta seleccionada para monitorizar la red de los casinos 6.3. Gestión del nivel de servicio, NimBus La idea de una aplicación de gestión del nivel de servicio es la de poder controlar si estamos dentro de los límites del SLA marcado, para poder ofrecer el nivel firmdo. 82 Estructura aplicación para gestionar SLA La gestión del nivel de servicio es un punto muy importante en una empresa. Controlar que estamos dentro de los niveles de SLA firmados permitirá que tengamos controlados el nivel de servicio, viendo cuales son los puntos flacos de nuestro servicio, y poder actuar más rápidamente con el fin de evitar SLAs que no cumplimos. NimBUS simplifica enormemente el proceso de gestión de SLA. La definición de los niveles de servicio se hace en una interfaz gráfica sencilla, y la generación de informes periódicos de nivel de servicio es completamente automatizada. Con NimBUS, los pasos a seguir son: 1. Definir los periodos operativos. Marcamos en que momentos monitorizamos los elementos especificados, que deben coincidir con los marcados en el SLA. 2. Definir los requerimientos de cumplimiento y el periodo de evaluación. En que día empieza la monitorización y cuando termina para generar los informes pertinentes. 3. Definir los Objetivos de Nivel de Servicio (SLO) que componen el acuerdo. Definimos los objetivos del SLA. 4. Opcionalmente, añadir comentarios, especificar servidores FTP y alarmas. 5. Especificar periodos excluidos, p.e. mantenimiento previsto 6. Resultado de los informes. Una vez en posesión del informe de resultados, podremos tomar decisiones sobre que SLAs són inalcanzables, o que equipos/elemento hace que no pudamos cumplir con un SLA específico. Estas decisiones van a ser mucho mas senzillas de realizar y mucho mas certeras si disponemos de los informes. El programa es muy senzillo si se siguen los puntos anteriores, obteniendo como resultado el estado de todos los SLAs. 83 Captura de imagen de la aplicación NimBUS 84 85 ANNEX 1 SLA’S En este apartado vamos a detallar todo lo relacionado con la gestión de los niveles de servicio. Detallamos primero los contratos para luego especificar las penalizaciones correspondientes. SERVICE LEVEL MANAGEMENT – SINCITY SERVICE DESK ACTIVIDAD Soporte primer nivel INDICADORES Número de llamadas recibidas por el Service Desk Llamadas atendidas en menos de 20 segundos Máximo de llamadas perdidas Tíquets registrados correctamente Resolución en primera llamada Ratio tiquets / llamada Disponibilidad C. Mediana C. Baja 17h-2h 18h-1h de lunes a jueves 17h-5h de viernes a domingo Satisfacción del usuario sobre el servicio de CAU SLA Informativ o SLA 2 SLA 2 SLA 2 SLA 2 Informativ o SLA 2 TIPO OBJETIVO Fijo Fijo Fijo Fijo 90 % 4% 99.95 % 70 % Fijo 99.99% Fijo Mejora 80 % C. Alta 7 x 24 SLA 2 87 Tíquets con cierre menor de 3 horas Consultas con un máximo de resolución de 1 hora SLA 2 SLA 2 1.5 % anual Fijo Fijo 92 % 90 % GESTIÓN DE INCIDENCIAS ACTIVIDAD Clasificación y soporte inicial INDICADORES Número de incidencias total registradas Las 10 incidencias más repetidas Número de incidencias por periodo Tiempo máximo para tener definido el plan de acción C. Alta C. Mediana C. Baja 20 minutos 45 minutos 90 minutos Tiempo máximo del inicio del plan de acción Investigación y diagnóstico Solución y recuperación C. Alta C. Mediana C. Baja 30 minutos 1 hora 2 horas Número de incidencias con más de una solución aplicada Incidentes solucionadas con el máximo tiempo C. Alta C. Mediana C. Baja 1 hora 3 horas 7 horas Tiempo máximo de vuelta de la primera llamada SLA TIPO OBJETIVO Informativ o Informativ o Informativ o SLA 2 Múltiple 99.9 % SLA 2 Múltiple 99.9 % SLA 2 Múltiple 4% SLA 2 Múltiple 99 % SLA 2 Múltiple 99.95 % 88 (resolución o seguimiento) C. Alta C. Mediana C. Baja 30 minutos 2 horas 5 horas Número de soluciones en remoto Número de incidencias sin resolver SLA 2 SLA 2 Fijo Fijo 75 % 0.5 % GESTIÓN DE PROBLEMAS ACTIVIDAD Control de errores Gestión preactiva Resolución problemas INDICADORES Incidencias TOP-TEN con plan de acción Problemas mal solucionados Problemas abiertos tras un cierto número de incidencias repetidas: Máximo tres en un día, ocho en un mes Tiempo máximo en la resolución de un problema: 1 hora SLA TIPO OBJETIVO SLA 2 SLA 2 SLA 2 Fijo Fijo Fijo 90 % 0.01 % 100 % SLA 2 Fijo 99.999 % GESTIÓN DE CONFIGURACIÓN ACTIVIDAD Identificación de configuración Informes INDICADORES SLA TIPO OBJETIVO % de la información almacenada en la CMDB SLA 2 Fijo 100 % C. Alta C. Mediana C. Baja 98 % 90 % 85 % % disponibilidad de la CMDB Número de incidencias provocadas por errores de cambios SLA 2 Informativ o Fijo 99 % 89 GESTIÓN DE SEGURIDAD ACTIVIDAD Seguridad gestionada INDICADORES Número de incidentes muy críticos que han supuesto un impacto negativo significativo en la imagen de la empresa Tiempo máximo entre incidente muy crítico y aviso a la dirección general. Máximo 5 minutos % de equipos equipados con antivirus y seguridad extra (firewall…) SLA TIPO OBJETIVO SLA 1 Fijo 0 SLA 1 Fijo 100 % SLA 2 Fijo 100 % SERVICIOS ACTIVIDAD Máquinas recreativas Player tracking INDICADORES SLA TIPO OBJETIVO Máximo tiempo reparación o sustitución: 2 horas SLA 2 Fijo 99.99 % Disponibilidad SLA 2 Múltiple 99 % SLA 2 Múltiple 99.5 % SLA 1 Múltiple 99.999 % Viernes a Domingo 95 % 187 horas/año sin disponibilidad Sistema de bonus Lunes a jueves 90 % 500 horas/año sin disponibilidad Disponibilidad Viernes a Domingo 98 % tiempo 75 horas/año sin disponibilidad Sistema de cashless Lunes a jueves 95 % tiempo 250 horas/año sin disponibilidad Disponibilidad 90 Cámaras de seguridad Disponibilidad cajeros ATM Lunes a jueves Viernes a Domingo 99 % tiempo 99.99 % tiempo 50 horas/año sin 22 minutos/año sin disponibilidad disponibilidad Reparación de una cámara de seguridad o sustitución: 10 minutos Disponibilidad de los cajeros Lunes a jueves 98 % 100 horas/año sin disponibilidad SLA 1 Fijo 98 % SLA1 Múltiple 98.5 % Viernes a Domingo 99.9 % 3 horas/año sin disponibilidad 8760 hores / any Las penalizaciones son las siguientes: Para el SLA tipo 1, cada una de las cláusulas no respetadas va a suponer un 4 % de reducción de la factura. Para el SLA tipo 2, cada una de las cláusulas no respetadas va a suponer un 15 % de reducción de tarifa. En el caso de no respetar más de 2 cláusulas de tipo 2, existirá la posibilidad de finiquitar el servicio sin cargo alguno. Vamos a detallar los SLAs con las empresas externas: ACTIVIDAD Telefonía móvil INDICADORES TIPO OBJETIVO Tiempo de solución en errores Múltiple 99 % Lunes a jueves Viernes a Domingo 4 horas 2 horas Disponibilidad: 98 % del tiempo Fijo 100 % 91 Telefonía fija Tiempo de solución en errores Múltiple 99 % Disponibilidad: 98 % del tiempo Fijo 100 % WAN Tiempo de solución en errores Múltiple 99 % Cajeros ATM Lunes a jueves Viernes a Domingo 2 horas 1 hora Disponibilidad: 98 % del tiempo Tiempo solución de errores Fijo Múltiple 100 % 99 % Fijo 100 % Lunes a jueves 4 horas Lunes a jueves 30 minutos Viernes a Domingo 2 horas Viernes a Domingo 20 minutos Disponibilidad: 99.9 % del tiempo 92 93