GESTIÓN DE LA CONFIGURACIÓN

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