2nBorrador

SinCity

2º Borrador

Grupo E

Jurgi BarreñaPatricia Durán

Ignasi PujalsRoger Rossell

Alberto Vílchez

1

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

5.1. Introducción..............................................................................72

3

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

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

Dirección

RRHHMarketingFinanzasOperaciones

LUXOR

Sistem

as

Dirección


BELLAGIO

Sistem

as

GRAND LASVEGAS

Dirección


Sistem

as

Dirección


ISLA DELTESORO

Sistem

asDirección


EXCALIBUR

Sistem

as

En la siguiente tabla se indican los objetivos y beneficios que se desean obtener con la implantación de los procesos ITIL:

Actores Objetivos / BeneficiosDirección - 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.

OperacionesRRHHMarketingFinanzas

- Soporte informático de mayor calidad.- Aumento de productividad gracias al aumento de disponibilidad de los servicios informáticos.- 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 D1 Descripción Pérdidas de ingresos

Detección de problemas

Alguna máquina recreativa averiada.Fallos en los cajeros ATM.Servicio poco satisfactorio.

Consecuencias Pérdidas en las ganancias obtenidas de las apuestas realizadas en el casino.

ID debilidad D2Descripción Retraso del servicio técnico para resolver

incidencias en las máquinas recreativas o los cajeros.


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.

Consecuencias Molestias para los jugadores, que no pueden jugar o realizar apuestas, de lo cual se deriva una pérdida de ingresos.

ID debilidad D3Descripción 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 D4 Descripción Pérdida de conectividad dentro del casino.


Se pierde la conexión a Internet y el acceso a aplicaciones web.

8

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 D5 Descripción 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.

Consecuencias Incomunicación del personal del casino.

ID debilidad D6Descripción Pérdida de clientes.


Puede deberse a averías recurrentes de algunas máquinas.

Consecuencias Pérdida de ingresos.

ID debilidad D7Descripción 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.

Consecuencias Puede conllevar a la pérdida de clientes, y por lo tanto a la de ingresos.

ID debilidad D8Descripción 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.

Consecuencias Entorpecimiento de la labor del personal del casino.

ID debilidad D9Descripción Servicio ineficiente.


Los clientes no reciben el trato que deberían o encuentran dificultades para jugar.

Consecuencias 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 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

9

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ónPriorida

dComplejida

d

Orden solució

n

Debilidades

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

3 Alta 3D1, D2, D3, D4, D5, D7,

D8, D9

P4Personal del casino poco eficiente

4 Baja 5 D1, D7, D9

P5 Equipamiento poco adecuado

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.

ID fortaleza F1

10

Descripción 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 F2Descripción 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 Fidelización de clientes, al haber convertido la visita al casino en un hábito.

ID fortaleza F3Descripción 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

Ventajas Fidelización de clientela al ofrecer servicios y juegos que no se encuentran en otros casinos.

ID fortaleza F4Descripción La empresa sitúa sus establecimientos en lugares con un

nivel de riqueza y un índice de turismo considerablemente altos.

Ventajas 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 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

11

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 problema

Soluciones propuestas

P1

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.

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.

P2 Procurar tener un buen SLA con la compañía que nos asegure en caso de averías su rápida reparación.

P3 Tratar de ser proactivos, de manera que cuando se produzca la incidencia ya se sepa cuál es y cómo resolverla.

P4

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.

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

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

14

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

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 incidenciasDuración 10 días Recursos A-1;A-2Predecesoras Ninguna, primera tarea a realizar en la gestión de incidencias.DescripciónDefinición de las posibles incidencias y realización de una clasificación en función de diferentes parámetros.

Tarea Confección de formulariosDuración 5 días Recursos AP-1;AP-2Predecesoras Definición y clasificación de incidenciasDescripciónDiseñ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-4Predecesoras Definición y clasificación de incidenciasDescripciónDefinició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 procesosDuración 15 días Recursos A-1;A-2;AP-3;AP-4Predecesoras Estructuración de niveles (Workflow de as incidencias)DescripciónDelegació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 IncidenciasDuración 15 días Recursos A-4;AP-3;AP-4Predecesoras Configuración/adaptación de la herramienta elegidaDescripciónFormació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.

1.4.1.2. Implantación Gestión de Problemas

17

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 problemasDuración 10 días Recursos A-1;A-2Predecesoras Definición y clasificación de incidenciasDescripciónDefinició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 formulariosDuración 5 días Recursos AP-1;AP-2Predecesoras Definición y clasificación de problemasDescripciónDiseñ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-2Predecesoras Confección de formulariosDescripciónDelegació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 ProblemasDuración 5 días Recursos A-2Predecesoras Configuración/adaptación de la herramienta elegidaDescripciónFormació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 Definición de objetivos y métricas

Duración 10 días Recursos A-1;A-2;AP-3;AP-4Predecesoras

Definición funciones, responsabilidades y procesos de gestión de incidencias

DescripciónDefinición de los objetivos específicos del service desk y las métricas necesarias para medir su grado de cumplimiento.

18

Tarea Elección del modeloDuración 5 días Recursos A-1;A-2Predecesoras Definición de objetivos y métricasDescripciónAná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-2Predecesoras Elección del modeloDescripciónDelegació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 Elección de la herramienta a usarDuración 5 días Recursos A-4;A-3Predecesoras

Elección del modelo y Diseño del nuevo modelo de inventario (G. Configuración)

DescripciónElecció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 elegidaDuración 20 días Recursos A-3;AP-1;P-1;P-2;P-3Predecesoras Elección de la herramienta a usarDescripciónConfiguració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 incidenciasDuración 5 días Recursos A-2;AP-2Predecesoras Elección de la herramienta a usarDescripciónDiseñ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.

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 Análisis de sistemas de configuración existentes

19

Duración 5 díasRecursos AP-4;A-4

Predecesoras

Ninguna, realización con antelación para proporcionar info de la CMDB al Service Desk

DescripciónAná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 inventarioDuración 10 días Recursos A-3;A-4;AP-3;AP-4Predecesoras Análisis de sistemas de configuración existentesDescripciónDiseñ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 inventarioDuración 15 días Recursos A-3;AP-1;P-2;P-3;P-1Predecesoras Diseño del nuevo modelo de inventarioDescripciónImplementació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ónDuración 10 días Recursos A-4;AP-2;A-1Predecesoras Implementación del nuevo modelo de inventarioDescripciónFormació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 amenazasDuración 5 días Recursos AS-1;AS-2Predecesoras Puesta en marcha del Service Desk.DescripciónAná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 protegerDuración 5 días Recursos AS-3;A-1Predecesoras Análisis de amenazasDescripción

20

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.

TareaDefinición de procesos (plan, implantación, evaluación, control mantenimiento y documentación)

Duración 10 días Recursos AS-1;AS-2;AS-3Predecesoras Elección de los recursos a protegerDescripciónDefinició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 responsabilidadesDuración 5 días Recursos AS-1;A-2Predecesoras Definición de procesosDescripciónDelegació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 seguridadDuración 10 días Recursos AS-2;AS-3Predecesoras Definición de procesosDescripciónFormació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.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 correccionesDuración 20 días Recursos T-1;T-2;P-1;P-2;P-3Predecesoras Puesta en marcha: Gestión de incidencias y problemasDescripciónTesteo 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

21

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 correccionesDuración 20 días Recursos T-1;T-2;P-1;P-2;P-3Predecesoras Puesta en marcha: Gestión de configuración y seguridadDescripciónTesteo 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 3º Periodo de pruebas y realización de correccionesDuración 10 días Recursos T-1;P-1;P-2;A-1Predecesoras

Puesta en marcha: Gestión de incidencias y problemas (resto de casinos)

DescripciónTesteo 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 4º Periodo de pruebas y realización de correccionesDuración 10 días Recursos T-2;P-1;P-2;P-3;A-3Predecesoras

Puesta en marcha: Gestión de configuración y seguridad (resto de casinos)

DescripciónTesteo 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.

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.

22

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 Cantidad Abreviación

Jefe de proyecto 1Analista 4 A-[1...4]Analista programador

4 AP-[1...4]

Programador 3 P-[1...3]Testeador senior 2 T-[1...2]Analista seguridad 3 AS-[1...3]

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ónJefe proyecto 1.544 horas

A-1 760 horasA-2 752 horasA-3 752 horasA-4 760 horasAP-1 640 horasAP-2 640 horasAP-3 640 horasAP-4 624 horasT-1 400 horasT-2 400 horasP-1 760 horasP-2 760 horasP-3 800 horas

AS-1 240 horasAS-2 240 horasAS-3 240 horas

24

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 incidenciasFactores criticos de éxito (CSFs) Indicadores de prestaciones clave (KPIs)Resolución rápida de incidencias Incremento de incidencias resueltas por el primer nivel Reducción de incidencias clasificadas incorrectamente

Mejora de la productividadAumento del número de incidencias tratadas por cada operador de primer nivel

Reducción del coste de tratamiento de incidenciasMejora de la calidad del servicio

Reducción de la no-disponibilidad del servicio causado por 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)

Satisfacción del usuarioMejora en encuestas de satisfacción del usuario en resolución de incidencias

Reducción del tiempo de espera para el Service Desk Reducción del llamadas perdidas en el SD

Gestión de problemasFactores criticos de éxito (CSFs) Indicadores de prestaciones clave (KPIs)Mejora de la calidad de servicio 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

Minimizar impacto de problemas 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

Reducción del tiempo de realización de reparaciones para errores conocidos

25

Reducción del coste para los usuarios

Reducción de la interrupción de servicios para usuarios de la empresa

Incremento de cambios realizados proactivamente

Gestión de la configuraciónFactor de éxito (CSFs) Prestaciones clave (KPIs)Control de equipamiento tecnológico Reducción de equipos mal configurados en la CMDB Incremento del registro de equipos en CMDB Incremento de la velocidad de registro de equiposSoporte a otros procesos 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ónMejora de la calidad de servicio

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

Gestión de seguridadFactor de éxito (CSFs) Prestaciones clave (KPIs)Protección ante individuos 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

Protección ante software Reducción del tiempo medio de detección de malware

maliciosoReducció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 malwareProtección ante urtos 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 pueden obtener a partir de encuestas obligatorias de satisfacción de personal y encuestas voluntarias realizadas a los propios clientes.

26

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.

27

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ónDuración 3 meses Recursos 2 Analistas programadoresDescripciónDespué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 loImplantado.

Tarea Análisis de resultadosFrecuencia Anual Recursos Datos obtenidos a partir de la evaluaciónDescripciónRealizar 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 informesFrecuencia Semestral Recursos Informes mensuales de lasDescripciónA 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.

28

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

2.3. Tipo Service Desk

El Centro de Atención a los Usuarios (CAU) es el único punto de contacto y

29

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 clientes, las tecnologías que se utilizaran serán:

- HP Openview Service Desk (definido en el capitulo de herramientas utilizadas)

- Internet- VoIP

30

- 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éfonoEn 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 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 incidenciasAproximadamente el 80% de las incidencias se resolverán en menos de dos horas.

31

Carga de trabajoSe 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

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

32

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 menudoo Las que requieren más personalo 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

33

problemas.

34

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.

Tercer nivel: Se trata del último nivel del escalado de la solución de problemas. Lo componen expertos en diferentes áreas

35

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.

36

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

37

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 de la incidenciao Número de incidencia (Predetermianda) o Localizador o 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 de él. Por otra parte, los campos como fecha de resolución, ID de la

38

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 nivel puede pasar el ticket con la calificación de sustitución directamente al departamento pertinente . De esta forma se gana en

39

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 nivelComo 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 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

40

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 las reactivas es que, mientras que en el primer caso las incidencias las abre un cliente o trabajador, en el caso de las proactivas, las incidencias se reciben automáticamente mediante la utilización de software específico para ello.

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

41

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.

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

42

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

43

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

44

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

45

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:

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.


NIVEL Alta

DEFINICION Son las que provocan un fallo de seguridad leve o un fallo total en alguna de las actividades de Sincity


46

NIVEL Normal

DEFINICION Son las que provocan un fallo de forma no total en alguna de las actividades de Sincity.


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

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

RESPONSABLE DE SOLUCIÓN Dependiendo del error, puede ser de operaciones (una máquina no enchufada...) o de sistemas (si falla el software...)


TIPO INCIDENCIA Fallo en cámara de seguridad

DESCRIPCIÓN Una cámara de seguridad deja de ser operativa o por algún motivo

47

CRITICIDAD 1 - Muy alta

AREAS AFECTADAS Seguridad del casino

RESPONSABLE DE SOLUCIÓN Si falla la red o el software lo arregla sistemas, si el error es de la propia cámara el problema lo soluciona operaciones


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


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


RESPONSABLE DE SOLUCIÓN Operaciones si es error del hardware de la máquina o de sistemas en caso opuesto


TIPO INCIDENCIA Fallo en alguna máquina de tiempo real

48

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


RESPONSABLE DE SOLUCIÓN Operaciones si es error del hardware de la máquina o de sistemas en caso opuesto


TIPO INCIDENCIA Fallo en el sistema de cashless

DESCRIPCIÓN El servicio de cashless deja de funcionar

CRITICIDAD 1- Muy alta


RESPONSABLE DE SOLUCIÓN Sistema de Información


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


49

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


RESPONSABLE DE SOLUCIÓN Operaciones si es el propio teléfono o sistemas de Información si es de la red DEC


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

AREAS AFECTADAS Operaciones/Marketing/Finanzas

RESPONSABLE DE SOLUCIÓN Sistemas de Información


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


RESPONSABLE DE SOLUCIÓN Operaciones

50


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


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

51

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

52

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

53

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

54

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.

55

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: 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

56

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

57

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

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

58

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

59

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

60

Numero incidencia

Criticidad

Posibles problemas asociados

Áreas afectadas

Responsable de solución

1 2 1,3,5,9 Servicio Operaciones

3 1 2,5,7 Seguridad Sistema de información/Operaciones

4 3 Servicio Operaciones

5 2 4,5,6,7 Servicio Sistema de información/Operaciones

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 Departamentos internos

Sistema de Información

9 4 8 Departamentos internos


10 2 1,3,4,5 Operaciones/Marketing/Finanzas


11 4 Totalidad Departamentos

Operaciones

12 2 1,3,4,5 Operaciones/Marketing/Finanzas


Numero problema

Áreas afectadas Responsable de solución

1 Servicio Sistemas de información

61

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

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.

62

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, configuración ...). En el caso de que fueran herramientas independientes, se debería de implementar una interfaz para la comunicación entre ellas.

63

Security cam

Security System

Security Guard

64

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 Tipos Categorías TiposServidores Cashless Recreativas Isla del Tesoro Planta 1 Player tracking Planta 2 Bonus Planta ... Recreativas Redes Cashless Video vigilancia Player trackingRecreativas Bonus Bellagio Bonus Luxor Recreativas Grand Las Vegas Video vigilancia

ExcaliburGrabadoras targetas magnéticas DataCard

Isla del Tesoro Card TechnologyRecreativas Bellagio Planta 1 Advantage Planta 2 Elementos de red Routers Planta ... SwitchesRecreativas Luxor Planta 1 Bridges Planta 2 Hubs Planta ... Cámaras de seguridad BellagioRecreativas Grand Las Vegas Planta 1 Luxor Planta 2 Grand Las Vegas Planta ... ExcaliburRecreativas Excalibur Planta 1 Isla del Tesoro Planta 2 Aplicaciones Corporativas Planta ... 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 DescripciónNombre* Nombre único que identifique al ítemNúmero de serie* Número de serie del ítem

65

Categoría* Una de las categorías definidas anteriormenteTipo* Un tipo de los definidos anteriormenteSituación* Localización física del CIModelo Modelo del hardwareProveedor* Proveedor del CIFecha de adquisición* Fecha en la que se compró el CINombre del “padre” * Nombre(s) único de CI que están por encima y se relacionanNombre del “hijo”* Nombre(s) único de CI que están por debajo y se relacionanRelació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 CINúmero de incidencia Número único de las incidencias que han afectado al CIRFCs Peticiones de cambio de configuración del CIComentarios 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.

Las responsabilidades específicas del Configuration Manager son, básicamente, la supervisión de todos los procesos que se deben de llevar

66

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.

67

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 recibeDisponibilidad: 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.

5.1.1. Requisitos de Seguridad

68

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 DescripciónControl Implementar

políticasEste 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.

Configurar la estructura de la seguridad

Este proceso configura la organización que tendrá la seguridad de la información. Por ejemplo en este proceso se instala la estructura de las responsabilidades. Este proceso termina con el MARCO de la GESTIÓN de la SEGURIDAD.

69

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

70

Actividades DescripciónPlanificación

Crear la sección de seguridad para SLA

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.

Crear los contratos de soporte

Este proceso contiene las actividades que conducen a los CONTRATOS de SOPORTE. Estos contratos son específicos para la seguridad.

Crear los OLA 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.

Informar 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 DescripciónImplementación Clasificar y

gestionar los servicios IT

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.

Implementar seguridad del personal

Medidas que se adoptan para dar seguridad del personal y confianza y las medidas de prevenir un fraude. Este proceso se termina con la SEGURIDAD del PERSONAL.

Implementar la gestión de seguridad

En los requisitos de seguridad y/o las reglas específicas del proceso de la seguridad que deben ser resueltos se realizan y se documentan. Este proceso

71

se termina con POLÍTICAS de la SEGURIDAD.

Implementar el control de acceso

En los requisitos de seguridad del acceso y/o las reglas específicas del proceso de la seguridad del acceso que deben ser resueltos se realizan y se documentan. Este proceso se termina con CONTROL de ACCESO.


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 DescripciónEvaluar Autovaloració

nEn este proceso se examinan los acuerdos de seguridad puestos en ejecución. El resultado de este proceso es DOCUMENTOS de la AUTOVALORACIÓN.

Intervención interna

En este proceso se examinan los acuerdos de seguridad puestos en ejecución. Realizado por un analista interno. El resultado de este proceso es INTERVENCIÓN INTERNA.

Intervención externa

En este proceso se examinan los acuerdos de seguridad puestos en

72

ejecución. Realizado por un analista externo. El resultado de este proceso es INTERVENCIÓN EXTERNA.

Evaluación basada en incidencias de la seguridad

En este proceso se examinan los acuerdos de seguridad puestos en ejecución. Se realiza en incidencias en 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.


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ónMantenimiento

Mantenimiento de los SLAs

Proceso para mantener los acuerdos del nivel de servicio en condiciones apropiadas. El proceso termina con los ACUERDOS MANTENIDOS del NIVEL DE SERVICIO.

Mantenimiento de OLA

Proceso para mantener los acuerdos del nivel de operaciones en condiciones apropiadas. El proceso termina con ACUERDOS MANTENIDOS del NIVEL de OPERACIONES.

Petición de cambio de SLA y/o OLA

Petición de cambio al SLA y/o al OLA formulada. Este proceso termina con una PETICIÓN para el CAMBIO.


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:

73

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 ValoresGestión de Confidencialidad, Integridad y Disponibilidad de Servicios IT

Número de incidentes causados por fallos externos en la seguridad

Número de incidentes causados por fallos internos en la seguridad

Menor de 0,1%

Menor de 0,1%

Proporcionar seguridad a un coste razonable

Porcentaje del coste de entrega por usuario de las actividades de gestión de la seguridad

Porcentaje del coste de entrega por usuario de las medidas de seguridad implementadas

Inferior del 50% del coste total de la infraestructura

Inferior al 2% sobre el coste total de las medidas de seguridad

Implementación de mejoras de seguridad de forma proactiva

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

Inversión del 5% cada mes en seguridad

Menor al 3%

Creación de una Política de Seguridad

Determinar los informes que deben ser emitidos

Responsables y Roles para cada uno de los subprocesos

Cada semana

ACL para asignar permisos dependiendo del rol (accesos correctos mayores del 99,999%)

Elaboración de un Plan de Seguridad

Establecimiento de normas de acceso

Establecimiento de los protocolos de seguridad

Definidas mediante ACL

Definidos y documentados antes de la

74

Fijar niveles de SLA y OLA

implementación

Se definirá una clausula

75

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 procesos como gestión de problemas y de cambios. Incluye también

76

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. Aviso cuando alguno de los sistemas tiene comportamientos

anómalos.

77

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.

78

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

79

Captura de imagen de la aplicación NimBUS

80

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 – SINCITYSERVICE DESK

ACTIVIDAD INDICADORES SLA TIPO OBJETIVOSoporte primer nivel Número de llamadas recibidas por el Service Desk Informativ

oLlamadas atendidas en menos de 20 segundos SLA 2 Fijo 90 %Máximo de llamadas perdidas SLA 2 Fijo 4 %Tíquets registrados correctamente SLA 2 Fijo 99.95 %Resolución en primera llamada SLA 2 Fijo 70 %Ratio tiquets / llamada Informativ

oDisponibilidad

C. Alta C. Mediana C. Baja7 x 24 17h-2h

de lunes a jueves17h-5h

de viernes a domingo

18h-1h

SLA 2 Fijo 99.99%

Satisfacción del usuario sobre el servicio de CAU SLA 2 FijoMejora 1.5 %

80 %

83

anualTíquets con cierre menor de 3 horas SLA 2 Fijo 92 %Consultas con un máximo de resolución de 1 hora SLA 2 Fijo 90 %

GESTIÓN DE INCIDENCIASACTIVIDAD INDICADORES SLA TIPO OBJETIVO

Clasificación y soporte inicial

Número de incidencias total registradas Informativo

Las 10 incidencias más repetidas Informativo

Número de incidencias por periodo Informativo

Tiempo máximo para tener definido el plan de acción

C. Alta C. Mediana C. Baja20 minutos 45 minutos 90 minutos

SLA 2 Múltiple 99.9 %

Tiempo máximo del inicio del plan de acción

C. Alta C. Mediana C. Baja30 minutos 1 hora 2 horas


Investigación y diagnóstico

Número de incidencias con más de una solución aplicada

SLA 2 Múltiple 4 %

Solución y recuperación

Incidentes solucionadas con el máximo tiempo

C. Alta C. Mediana C. Baja1 hora 3 horas 7 horas

SLA 2 Múltiple 99 %

Tiempo máximo de vuelta de la primera llamada (resolución o seguimiento)


84

C. Alta C. Mediana C. Baja30 minutos 2 horas 5 horas

Número de soluciones en remoto SLA 2 Fijo 75 %Número de incidencias sin resolver SLA 2 Fijo 0.5 %

GESTIÓN DE PROBLEMASACTIVIDAD INDICADORES SLA TIPO OBJETIVO

Control de errores Incidencias TOP-TEN con plan de acción SLA 2 Fijo 90 %Problemas mal solucionados SLA 2 Fijo 0.01 %

Gestión preactiva Problemas abiertos tras un cierto número de incidencias repetidas:

Máximo tres en un día, ocho en un mes

SLA 2 Fijo 100 %

Resolución problemas

Tiempo máximo en la resolución de un problema: 1 hora

SLA 2 Fijo 99.999 %

GESTIÓN DE CONFIGURACIÓNACTIVIDAD INDICADORES SLA TIPO OBJETIVO

Identificación de configuración

% de la información almacenada en la CMDB

C. Alta C. Mediana C. Baja98 % 90 % 85 %

SLA 2 Fijo 100 %

Informes % disponibilidad de la CMDB SLA 2 Fijo 99 %Número de incidencias provocadas por errores de cambios

Informativo

GESTIÓN DE SEGURIDADACTIVIDAD INDICADORES SLA TIPO OBJETIVO

85

Seguridad gestionada

Número de incidentes muy críticos que han supuesto un impacto negativo significativo en la imagen de la empresa

SLA 1 Fijo 0

Tiempo máximo entre incidente muy crítico y aviso a la dirección general. Máximo 5 minutos

SLA 1 Fijo 100 %

% de equipos equipados con antivirus y seguridad extra (firewall…)

SLA 2 Fijo 100 %

SERVICIOSACTIVIDAD INDICADORES SLA TIPO OBJETIVO

Máquinas recreativas

Máximo tiempo reparación o sustitución: 2 horas SLA 2 Fijo 99.99 %

Player tracking Disponibilidad

Lunes a jueves Viernes a Domingo90 %500 horas/año sin disponibilidad

95 %187 horas/año sin disponibilidad

SLA 2 Múltiple 99 %

Sistema de bonus Disponibilidad

Lunes a jueves Viernes a Domingo95 % tiempo250 horas/año sin disponibilidad

98 % tiempo75 horas/año sin disponibilidad


Sistema de cashless Disponibilidad

Lunes a jueves Viernes a Domingo99 % tiempo50 horas/año sin

99.99 % tiempo22 minutos/año sin


86

disponibilidad disponibilidadCámaras de seguridad

Reparación de una cámara de seguridad o sustitución: 10 minutos

SLA 1 Fijo 98 %

Disponibilidad cajeros ATM

Disponibilidad de los cajeros

Lunes a jueves Viernes a Domingo98 %100 horas/año sin disponibilidad

99.9 %3 horas/año sin disponibilidad

SLA1 Múltiple 98.5 %

8760 hores / anyLas 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 INDICADORES TIPO OBJETIVOTelefonía móvil Tiempo de solución en errores

Lunes a jueves Viernes a Domingo4 horas 2 horas

Múltiple 99 %

Disponibilidad: 98 % del tiempo Fijo 100 %

Telefonía fija Tiempo de solución en errores

Lunes a jueves Viernes a Domingo4 horas 2 horas

Múltiple 99 %

87

Disponibilidad: 98 % del tiempo Fijo 100 %

WAN Tiempo de solución en errores

Lunes a jueves Viernes a Domingo2 horas 1 hora

Múltiple 99 %

Disponibilidad: 98 % del tiempo Fijo 100 %Cajeros ATM Tiempo solución de errores

Lunes a jueves Viernes a Domingo30 minutos 20 minutos

Múltiple 99 %

Disponibilidad: 99.9 % del tiempo Fijo 100 %

88

2nBorrador

Documents

Transcript of 2nBorrador