Manual OSA Español PDF

ITIL® Análisis y Soporte
Operacional (OSA)
(Certificación Oficial ITIL - Serie
Intermedia Competencias)
Todos los derechos reservados. Ninguna parte de esta documentación puede ser reproducida, almacenada en un
sistema de recuperación, o transmitida por medio alguno, electrónico, mecánico, fotográfico, o de otra forma sin la
previa autorización por escrito del propietario de los derechos. No se asume responsabilidad de patente con respecto
al uso de la información aquí contenida. Aun cuando todas las precauciones han sido tomadas en la preparación de
esta publicación, no podrá hacerse responsable al titular de la patente por los daños causados por el uso de la
información aquí contenida.
© Pink Elephant, 2013 a menos que se especifique de otra forma. Todos los derechos reservados.
5575 North Service Road, Suite 200
Burlington, Ontario
L7L 6M1 Canadá
Teléfono: 905-331-5060
Fax: 905-331-5070
ITIL® es una Marca registrada de la Oficina de Comercio del Gobierno en el Reino Unido y otros países.
El texto Citado /IITL que se distingue con tipo de letra itálica, proviene de los libros de ITIL® de la OGC
(Estrategia del Servicio, Diseño del Servicio, Transición del Servicio, Operación del Servicio, Mejoramiento
Continuo del Servicio) Derechos reservados ©Crown 2011. Reproducido bajo la licencia de la OGC.
Syllabus versión 5.3 – 2013

OSA r5.3.1 Mar 2013
Tabla de Contenidos
Descripción del curso....................................................................................................................... 6
ITIL Análisis y Soporte Operacional ........................................................................................... 11

Bienvenido ..................................................................................................................................... 11
Acuerdos del curso......................................................................................................................... 12
Presentaciones ................................................................................................................................ 12
Objetivos del curso ........................................................................................................................ 13
El examen ...................................................................................................................................... 13
Objetivos de aprendizaje ................................................................................................................ 14
Antes de iniciar .............................................................................................................................. 14
Introducción al Análisis y Soporte Operacional .................................................................................... 15

Propósito y objetivos del Análisis y Soporte Operacional ............................................................ 15
Alcance de la Operación del Servicio ............................................................................................ 16
Valor al negocio de la Operación del Servicio .............................................................................. 17
OSA y el ciclo de vida del servicio ................................................................................................ 18
Optimizando el desempeño de la Operación del Servicio ............................................................. 20
Funciones del Análisis y Soporte Operacional ....................................................................................... 21
La función del Service Desk ..................................................................................................................... 22

El Service Desk .............................................................................................................................. 22
El rol del Service Desk .................................................................................................................. 24
Objetivos del Service Desk ............................................................................................................ 25
Service Desk Local ........................................................................................................................ 26
Service Desk Centralizado ............................................................................................................. 27
Service Desk Virtual ...................................................................................................................... 28
Service Desk Sigue al Sol .............................................................................................................. 29
Grupos especializados de Service Desk ......................................................................................... 30
Promocionando el Service Desk como punto único de contacto ................................................... 31
Personal de Service Desk ............................................................................................................... 33
Consideraciones de personal .......................................................................................................... 34
Requerimientos de tecnología ........................................................................................................ 40
Midiendo el desempeño del Service Desk ..................................................................................... 43
Consideraciones para Outsourcing ................................................................................................ 47
Técnicas para los examenes intermedios ....................................................................................... 50
Examen de prueba 1, Escenario 1 - Pregunta 1.............................................................................. 51
La función de la Gestión Técnica ............................................................................................................ 52

El doble rol de la Gestión Técnica ................................................................................................. 52
Objetivos de la Gestión Técnica .................................................................................................... 54
Actividades de la Gestión Técnica ................................................................................................. 55
La función de la Gestión de Aplicaciones ............................................................................................... 57

El rol de la Gestión de Aplicaciones .............................................................................................. 57
Objetivos de la Gestión de Aplicaciones ....................................................................................... 59
Actividades de la Gestión de Aplicaciones .................................................................................... 60
2
La función de la Gestión de Operaciones de TI ..................................................................................... 62
El rol de la Gestión de Operaciones de TI .................................................................................... 62
Objetivos de la Gestión de Operaciones de TI............................................................................... 64
Control de Operaciones de TI ........................................................................................................ 65
Gestión de instalaciones ................................................................................................................. 66
Organización de la Gestión de Operaciones de TI ........................................................................ 68
Herramientas para la gestión de los servicios ................................................................................ 69
Requerimientos genéricos de tecnología........................................................................................ 74
Examen de prueba 1, Escenario 6 - Pregunta 6.............................................................................. 77
Roles activos en la Operación del Servicio.............................................................................................. 78

Roles en las cuatro funciones ......................................................................................................... 78
Roles genéricos en la Operación del Servicio................................................................................ 83
Procesos del Análisis y Soporte Operacional .......................................................................................... 85
Gestión de Eventos .................................................................................................................................... 85

Propósito de la Gestión de Eventos................................................................................................ 86
Objetivos de la Gestión de Eventos ............................................................................................... 87
Alcance y valor de la Gestión de Eventos ..................................................................................... 87
Políticas - Ejemplos ....................................................................................................................... 89
Conceptos de la Gestión de Eventos .............................................................................................. 90
Diseño para Gestión de Eventos ................................................................................................... 92
Actividades de la Gestión de Eventos ............................................................................................ 94
Disparadores/Entradas/Salidas ..................................................................................................... 100
Gestión de Información dentro de la Gestión de Eventos ............................................................ 102
Mediciones de procesos ............................................................................................................... 103
Midiendo la Gestión de Eventos .................................................................................................. 105
Interfaces de la Gestión de Eventos ............................................................................................. 107
Requerimientos de Tecnología .................................................................................................... 109
Retos y riesgos de la Gestión de Eventos .................................................................................... 111
Examen de prueba 1, Escenario 4 - Pregunta 4............................................................................ 112
Gestión de Incidentes .............................................................................................................................. 113

Propósito de la Gestión de Incidentes .......................................................................................... 113
Objetivos y alcance de la Gestión de Incidentes .......................................................................... 114
Valor al negocio de la Gestión de Incidentes ............................................................................... 115
Políticas - Ejemplos ..................................................................................................................... 116
Conceptos de la Gestión de Incidentes ........................................................................................ 118
Ciclo de vida expandido del incidente ......................................................................................... 120
Actividades de la Gestión de Incidentes ...................................................................................... 121
Gestión de la información en Gestión de Incidentes.................................................................... 132
Midiendo la Gestión de Incidentes .............................................................................................. 134
Interfaces de la Gestión de Incidentes.......................................................................................... 137
Requerimientos de tecnología ...................................................................................................... 139
Retos y riesgos de la Gestión de Incidentes ................................................................................. 141
3
Cumplimiento de Solicitudes.................................................................................................................. 143
Propósito y objetivos de Cumplimiento de Solicitudes .............................................................. 143
Alcance de Cumplimiento de Solicitudes .................................................................................... 145
Valor al negocio ........................................................................................................................... 146
Conceptos de Cumplimiento de Solicitudes ................................................................................ 147
Actividades de Cumplimiento de Solicitudes .............................................................................. 150
Gestión de información dentro de Cumplimiento de Solicitudes ................................................ 156
Midiendo Cumplimiento de Solicitudes ...................................................................................... 156
Interfaces de Cumplimiento de Solicitudes ................................................................................. 158
Retos y riesgos de Cumplimiento de Solicitudes ......................................................................... 161
Gestión de Problemas ............................................................................................................................. 163

Propósito de la Gestión de Problemas ......................................................................................... 163
Objetivos de la Gestión de Problemas ......................................................................................... 164
Alcance de la Gestión de Problemas ............................................................................................ 164
Aspectos reactivos y proactivos ................................................................................................... 166
Valor al negocio de la Gestión de Problemas .............................................................................. 167
Conceptos de la Gestión de Problemas ........................................................................................ 169
Técnicas de la Gestión de Problemas ........................................................................................... 171
Actividades de la Gestión de Problemas ...................................................................................... 175
Gestión de la Información en Gestión de Problemas ................................................................... 182
Midiendo la Gestión de Problemas .............................................................................................. 184
Interfaces de la Gestión de Problemas ......................................................................................... 187
Retos y riesgos de la Gestión de Problemas ................................................................................ 192
Gestión de Acceso.................................................................................................................................... 194

Propósito de Gestión de Acceso .................................................................................................. 194
Objetivos de Gestión de Acceso .................................................................................................. 195
Alcance de Gestión de Acceso ..................................................................................................... 195
Valor al negocio de Gestión de Acceso ....................................................................................... 197
Conceptos de Gestión de Acceso ................................................................................................. 199
Actividades de Gestión de Acceso ............................................................................................... 200
Gestión de la información en Gestión de Acceso ........................................................................ 206
Midiendo la Gestión de Acceso ................................................................................................... 208
Interfaces de la Gestión de Acceso .............................................................................................. 209
Retos y riesgos de Gestión de Acceso ......................................................................................... 212
Roles en los cinco procesos ..................................................................................................................... 214

4
Consideraciones de Implementación ..................................................................................................... 223
Operación del Servicio y la Gestión de Proyectos ....................................................................... 223
Evaluando y gestionando riesgos en la Operación de Servicios .................................................. 224
El personal operativo en Diseño del Servicio y Transición del Servicio ..................................... 225
Planeación e implementación de tecnologías de gestión de servicios ......................................... 226
Retos de la implementación ......................................................................................................... 229
Riesgos de la implementación ..................................................................................................... 232
Factores Críticos de Éxito ............................................................................................................ 234
Gracias ......................................................................................................................................... 238
5
Descripción del Curso
ITIL Análisis y Soporte Operacional

Certificación Oficial ITIL - Serie Intermedia Competencias
Esta certificación oficial de ITIL Serie Intermedia Competencias le permite especializarse en los
procesos de ITIL necesarios para crear una infraestructura de TI estable en la que el negocio
confíe. Incluye una combinación de capacitación guiada por instructor y ejercicios para ayudar al
participante a aprender sobre la aplicación práctica de los conceptos de ITIL, estructuras
organizacionales, roles, funciones y actividades de los siguientes procesos:
 Gestión de Incidentes
 Gestión de Problemas
 Cumplimiento de Solicitudes
 Gestión de Eventos
 Gestión de Acceso
QUÉ APRENDERÁ
 Cómo los procesos del OSA y sus funciones entregan valor al negocio al soportar el ciclo
de vida del servicio
 Revisión a profundidad de los procesos y sus actividades asociadas, funciones, roles,
responsabilidades, retos, riesgos y factores críticos de éxito:
o Gestión de Incidentes: Se enfoca en restaurar los servicios tan rápido como sea
posible de acuerdo a los niveles de servicio acordados
o Gestión de Problemas: Se enfoca en la prevención de los problemas y la
eliminación de incidentes recurrentes
o Cumplimiento de Solicitudes: Administra el cumplimiento de las solicitudes de
servicio, con la meta de proveer rápidamente el acceso a los servicios estándares
para que el personal mejore su productividad
o Gestión de Eventos: Se enfoca en las ocurrencias detectables que tiene
significado para la gestión de la infraestructura de TI o para la entrega del servicio
de TI
o Gestión de Acceso: Otorga a los usuarios autorizados el derecho a usar un
servicio mientras previene el acceso a los usuarios no autorizados
 Revisión a fondo de estas funciones críticas:
o Gestión de Operaciones de TI
o Gestión Técnica
o Gestión de Aplicaciones
o Service Desk
 El impacto que el análisis y soporte operacional tiene en las actividades operativas y otros
procesos como Cambios, Configuración, Liberación e Implementación, Capacidad,
Disponibilidad, Conocimiento, Financiera de Servicios de TI y Continuidad.
 Consideraciones de tecnología e implementación
6
USTÉD APRENDERÁ A
 Entregar valor a su organización profundizando en los procesos de ITIL que permitan

minimizar el tiempo de caída de los servicios manteniendo al personal productivo y al
negocio operando tan eficientemente como sea posible
 Crear un modelo de prioridad de TI cubriendo incidentes, problemas y cambios en apoyo
a los acuerdos de niveles de servicio
 Identificar y eliminar incidentes de su entorno de producción
 Incrementar la disponibilidad operacional reduciendo hasta en un 80% los incidentes
mayores
 Reducir el costo de manejo de incidentes a través de procedimientos y políticas de
escalamiento
 Mejorar la efectividad del Service Desk definiendo roles y responsabilidades para el
personal del mismo y roles de soporte
 Mejorar la satisfacción del usuario y reducir los costos del cumplimiento de las
solicitudes de servicio
ACREDITACIÓN DEL CURSO E INSTRUCTOR
Pink Elephant está acreditado a nivel global para proporcionar educación de ITIL para el
programa de certificación. La organización está acreditada por el Instituto de Examinación para
las Ciencias de la Información (EXIN), el Comité de Examinación de Sistemas de Examinación
(ISEB), y los Servicios de Certificación Oficiales (LCS).
Su instructor es un miembro del equipo de consultoría de Pink Elephant certificado y altamente
experimentado en ITIL, él o ella está calificado para impartir este curso de acuerdo a lo definido
en el Programa interno de Instructor Certificado de Pink Elephant. Puede esperar aprender de un
individuo con el conocimiento más profundo de la industria en cómo dirigir un proyecto exitoso
de implementación. Este conocimiento es el resultado directo de la neutralidad de Pink Elephant
con respecto al proveedor- así como varios años de experiencia implementando procesos de ITIL
en una gran variedad de organizaciones en todo el mundo.
QUIÉN DEBE ASISTIR Y PREREQUISITOS
 Personas que cuenten con el certificado de Fundamentos de ITIL y que deseen continuar
con las certificaciones avanzadas de ITIL
 Personas involucradas con los procesos y funciones del OSA y que requieran un
profundo entendimiento de cómo ellos pueden ser utilizados para mejorar la calidad del
soporte de los servicios de TI en su organización
 Profesionales de TI trabajando dentro de una organización que haya adoptado ITIL y que
necesiten estar informados acerca de cómo contribuir en un programa de mejora continua
del servicio
Usted debe contar con el certificado “ITIL Foundation Certificate in IT Service Management”.
Su certificado debe ser presentado como evidencia para obtener su admisión a este curso.
7
EXAMEN Y CERTIFICACIONES
 Este curso prepara a los participantes para el examen ITIL Intermediate Certificate:
Operational Support & Analysis. Este examen de 90 minutos está programado para el
último día del curso. Consiste en ocho preguntas de opción múltiple, basado en escenario
y respuestas graduadas. Para preparar a los participantes para el examen final, se
entregará un examen de prueba durante el curso. La calificación aprobatoria es del 70%
para recibir su certificado.
 Usted obtendrá 4 créditos de ITIL
 Usted obtendrá 32 Professional Development Units (PDUs) para administración de
proyectos
 Usted obtendrá 3.2 Continuing Education Units
 Usted obtendrá 38 créditos Continuing Professional Education
TAMAÑO DE LA CLASE
El tamaño máximo de la case es de 18 estudiantes por instructor.
Nota importante: Debido a la naturaleza de este curso, es recomendado que los

estudiantes cumplan con al menos 12 horas de auto estudio basados en el temario del curso
Análisis y Soporte Operacional (OSA) así como el libro Service Operation como
preparación del examen.
Usted puede comprar esta publicación en varios formatos de estas fuentes:
 ITIL V3 Online Bookshop – www.best-management-practice.com/Online-Bookshop/

 ITIL Books – www.itilbooks.com
 The Stationery Office (TSO) – www.tso.co.uk/bookshop
 Amazon – www.amazon.com
Estructura de acreditación de ITIL

The Cabinet Office
The Cabinet Office es el departamento del gobierno del Reino Unido que administra el
portafolio de ITIL.
El Acreditador
APM Group Limited desarrolla y administra el esquema de acreditación.
Institutos de Examinación (EIs)

Las examinaciones profesionales basadas en ITIL son ofrecidas a través de institutos
acreditados por el APM Group. Los EIs están autorizados para operar el esquema de
examinación de ITIL a través de una red de organizaciones acreditadas de capacitación.
La lista de EIs puede ser vista en el sitio oficial de ITIL:
http://www.itil-officialsite.com/ExaminationInstitutes/ExamInstitutes.aspx
8
Organizaciones autorizadas de capacitación
Pink Elephant es un proveedor de educación, capacitación, consultoría, soluciones en
línea y servicios de conferencia. Pink Elephant es un proveedor de educación acreditado
en ITIL.
Organizaciones practicantes
ITIL es independiente de la industria y es usada por organizaciones alrededor del mundo.
Estas organizaciones han implementado ITIL y han contribuido a su difusión.
9
Esta página está en blanco intencionalmente
10
Introducción al Análisis y Soporte Operacional
11
12
13
14
Service Desk
15
Service Desk
 Los servicios mismos: Las actividades del día a día que forman parte de un servicio son
incluidas en la Operación del Servicio, ya sea que son desempeñadas por el proveedor
de servicios, un proveedor externo o el usuario o cliente de ese servicio.
 Los procesos de gestión de servicios: La ejecución y gestión de varios de los procesos de
gestión de servicios son desempeñados en Operación del Servicio. Aunque un número de
procesos de ITIL (como gestión de cambios o de capacidad) se originan en Diseño del
Servicio o Transición del Servicio, ellos están en uso continuo en Operación del Servicio.
Algunos procesos no son incluidos específicamente en Operación del Servicio como
Gestión de la Estrategia para Servicios de TI o los procesos de Diseño del Servicio.
Estos procesos se enfocan en una planeación y mejoras a largo plazo que están fuera del
alcance de Operación del Servicio, sin embargo proveen entradas e influyen en todo el
ciclo de vida del servicio.
 Tecnología: Todos los servicios requieren de alguna forma tecnología para entregarse.
Administrar esta tecnología no es un asunto separado sino una parte integral de la
gestión de servicios. La mayor parte de Operación del Servicio de ITIL está preocupada
con la gestión de la infraestructura usada para entregar los servicios.
 Gente: Sin importar qué servicios, procesos y tecnología son gestionados, se trata de
personas. Son las personas que impulsan la demanda por los servicios y productos y es
la gente quien decide cómo será realizado. Al final, es la gente quien administra la
tecnología, procesos y servicios. Una falla en el reconocimiento de esto, resultará en la
falla de las actividades de la gestión de servicios
16
Service Desk
Seleccionar y adoptar las mejores prácticas, ayuda a las organizaciones a entregar beneficios
significativos. Adoptar e implementar un enfoque consistente para la Operación del Servicio
traerá:
 Reducción de los costos no planeados tanto para el negocio como para TI a través de un
óptimo manejo de las interrupciones del servicio e identificación de su causa raíz.
 Reducción de la duración y frecuencia de las interrupciones del servicio que permitirán
al negocio tomar ventaja del valor creado por el servicio que reciben.
 Proveer resultados operacionales y datos que puedan ser usados por otros procesos de
ITIL para mejorar los servicios y proveer justificación para invertir en actividades de
mejoras y tecnologías de soporte.
 Lograr las metas y objetivos de las políticas de seguridad de la organización al asegurar
que los servicios de TI serán accedidos sólo por aquellos autorizados.
 Proveer un rápido y efectivo acceso a los servicios estándar que el negocio pueda usar
para mejorar su productividad o la calidad de los servicios y productos del negocio.
 Proveer la base para la operación automatizada que incremente la eficiencia y permita a
los recursos humanos ser utilizados para trabajo de manera innovadora como el diseño
de nuevas funcionalidades o definir nuevas formas con las que el negocio pueda explotar
la tecnología para incrementar su ventaja competitiva.
17
Service Desk
 Estrategia del Servicio es donde la creación del valor para el negocio inicia con la
identificación y entendimiento de los requerimientos y necesidades de sus clientes. Este
valor es reconocido a través de los procesos y funciones del OSA como servicios que son
entregados y soportados en la Operación del Servicio.
 Diseño del Servicio produce el Paquete de Diseño del Servicio (SDP) que abarca los
requerimientos operacionales. Entradas de los procesos del OSA son necesarias para
asegurar que los requerimientos son incorporados en esta fase.
 Transición del Servicio dependerá de la participación de las funciones del OSA en la
evaluación, construcción, pruebas e implementación de los servicios.
 Mejora Continua del Servicio analizará los datos e información entregada vía los
procesos del OSA para identificar posibles mejoras a los servicios y a los procesos del
OSA. De igual manera, OSA recomendará o iniciará mejoras a los servicios vía
solicitudes de cambio y otras actividades operativas
18
Service Desk
19
Service Desk
La Operación del Servicio es optimizada en dos maneras:
 Mejoras a largo plazo: Estan basadas en evaluar el desempeño y salida de todos los
procesos de Operación del Servicio, tecnologías, funciones y salidas en el tiempo.
Los reportes son analizados y se toman decisiones sobre qué mejoras son necesarias y
cómo se implementan a través de Diseño y Transición del Servicio. Ejemplos incluyen la
implementación de un nuevo conjunto de herramientas, cambios al diseño de los
procesos, reconfiguración de la infraestructura, etc. Este tipo de mejoras son cubiertas a
detalle en el libro de ITIL Mejora Continua del Servicio.
 Mejoras a corto plazo: Estas son mejoras hechas para prácticas recurrentes dentro de
los procesos, funciones y tecnologías que soportan la operación del servicio mismo.
Estas son generalmente pequeños cambios que son implementados sin cambiar la
naturaleza del proceso o tecnología. Ejemplo son los ajustes a la infraestructura,
balanceo de cargas, reubicación de personal, capacitación, etc.
20
Service Desk
21
Service Desk
22
Service Desk
El Service Desk es vitalmente importante para una organización de TI y deberá ser el Punto
Único de Contacto para los usuarios de TI durante las operaciones del día a día. De manera
adicional al manejo de los incidentes y solicitudes de servicio, también provee una interfaz para
otras actividades tales como solicitudes de cambio del cliente, licencias de software, Gestión de
Activos del Servicio y Configuración, Gestión de la Disponibilidad, Gestión Financiera para
Servicios de TI y Gestión de Continuidad de los Servicios de TI
El valor de un Service Desk efectivo, no debe ser subestimado, un buen Service Desk a menudo
puede compensar las deficiencias en otras áreas de la organización de TI, pero por otro lado, un
Service Desk pobre (o la ausencia de un Service Desk) puede dar una mala impresión de manera
equivocada respecto a una organización efectiva de TI
23
Service Desk
Aunque hoy en día se requiere poca justificación sobre el Service Desk, los siguientes beneficios
son útiles para demostrar su valor:
 Mejora en el Servicio al cliente, percepción y satisfacción

 Aumento de la accesibilidad a través de un Punto Único de Contacto, comunicación e
información
 Mejor calidad y respuesta más rápida a las solicitudes de los usuarios o clientes
 Mejor trabajo en equipo y comunicación
 Mayor atención y un enfoque proactivo en el aprovisionamiento de los servicios
 Reducción en el impacto adverso al negocio
 Mayor control y administración de la infraestructura
 Mejor uso de los recursos de soporte de TI e incremento en la productividad del personal
del negocio
 Mayor gestión significativa de la información para soportar la toma de decisiones
 Es una práctica común que el Service Desk ofrezca las posiciones iniciales para el
personal de ITSM
Es importante contratar individuos con habilidades que entiendan al negocio y hayan sido
capacitados de manera adecuada. Esto asegura que los usuarios están contactando una persona
que pueda responder a sus inquietudes y tengo el conocimiento del negocio y la tecnología. Esto
tiene el propósito de mantener los niveles de soporte en la primera línea y asegurar que el
analista del Service Desk no se agota rápidamente con el estrés excesivo.
24
Service Desk
Entre las principales responsabilidades se incluyen:
 Registrar todos los detalles relevantes de los incidentes/solicitudes de servicio,

asignando códigos de categorización y priorización
 Proveer primer nivel de investigación y diagnóstico
 Resolver incidentes/solicitudes de servicio en el primer contacto siempre que sea posible
 Escalar incidentes/solicitudes de servicio que no puedan resolver en los tiempos
acordados
 Mantener informados a los usuarios del progreso de los incidentes/solicitudes de servicio
 Cerrar los incidentes solicitudes de servicio resueltos
 Realizar encuestas o llamadas de satisfacción a los clientes y usuarios según lo acordado
 Comunicación con los usuarios – manteniéndolos informados del progreso de los
incidentes, notificando cambios inminentes o cortes acordados, etc.
 Actualizar el CMS bajo la dirección y aprobación de Gestión de Activos del Servicio y
Configuración si así se acuerda
25
Service Desk
Hoy en día están disponibles múltiples opciones para cómo estructurar y establecer el Service
Desk. Cada organización deberá seleccionar la opción o combinación de opciones que mayor le
convenga de acuerdo a sus necesidades y cumpla los requerimientos de los clientes y usuarios.
Service Desk Local

Este es cuando un Service Desk es colocado dentro o físicamente cerca a la comunidad de los
usuarios que atiende. Esto a menudo ayuda a la comunicación y proporciona una presencia
claramente visible que a varios usuarios les gusta, pero también a menudo puede ser ineficiente
y costoso para mantener el personal local atado a la espera de manejar incidentes cuando los
volúmenes y tasa de llamadas no lo justifiquen.
Dentro de las razones para mantener un Service Desk Local se incluyen:
 Diferencias de idioma y culturales o políticas

 Diferentes zonas horarias
 Grupos especializados para usuarios
 La existencia de servicios a la medida o especializados que requieren conocimiento
especializado
 Estado de los usuarios VIP/críticos
26
Service Desk
Service Desk Centralizado

Es posible reducir el número de Service Desks al fusionarlos en una sola localidad (o en un
menor número de localidades) al llevar al personal en uno o más estructuras de Service Desk
Centralizado. Esto puede ser más eficiente y rentable permitiendo menor personal para
enfrentar un mayor volumen de llamadas y también llevarlo a niveles superiores de habilidades
a través de una mayor familiarización de una mayor frecuencia de ocurrencia de eventos. Aún
podría ser necesario mantener algo de presencia local para manejar solicitudes de soporte
físico, pero el personal puede ser controlado y desplegado desde el Service Desk Centralizado.
27
Service Desk
Service Desk Virtual

Mediante el uso de la tecnología, particularmente el Internet y el uso de herramientas de soporte
corporativo, es posible de dar la impresión de un Service Desk simple o centralizado cuando de
hecho el personal puede estar disperso o localizado en un número o tipo de localidades
geográficas. Esto hace posible el trabajo desde casa, grupos secundarios de soporte,
outsourcing o cualquier combinación necesaria para cubrir la demanda de los usuarios. Sin
embrago, es importante señalar que las salvaguardas son necesarias en todas estas
circunstancias para garantizar consistencia y uniformidad en la calidad del servicio y
condiciones culturales.
28
Service Desk
Siguiendo al Sol
Algunas organizaciones globales o internacionales tal vez deseen combinar dos o más de sus
Service Desks dispersos geográficamente para proveer un servicio de 24 horas siguiendo al sol.
Por ejemplo, un Service Desk en la región Asia-Pacífico podría manejar las llamadas durante su
horario laboral estándar y al final del periodo pase la responsabilidad de cualquier incidente
abierto a un Service Desk con base en Europa. Este Service Desk manejará aquellas llamadas e
incidentes durante su jornada laboral para posteriormente pasárselo a un Service Desk con base
en EE.UU. quien finalmente regresará la responsabilidad al Service Desk localizado en la
región Asia – Pacífico para completar el ciclo.
Esto puede ofrecer una cobertura de 24 horas a un costo relativamente bajo, debido a que
ningún Service Desk tenga que trabajar más de una jornada laboral. Sin embrago, las mismas
salvaguardas como procesos comunes, herramientas, bases de datos compartidas y aspectos
culturales deberán ser direccionados para proceder con este enfoque, así como un proceso de
escalamiento bien definido y controlado como son requeridos
29
Service Desk
Para algunas organizaciones, pudiera ser benéfico crear grupos especializados dentro de una
estructura general del Service Desk, por lo tanto, aquellos incidentes relacionados a un Servicio
de TI en particular, pueden ser direccionados de manera directa (normalmente vía la selección
de una opción en el teléfono o mediante una interfaz web) al grupo de especialistas. Esto puede
permitir una resolución más rápida de estos incidentes, a través de una capacitación
especializada.
Se requiere tener cuidado de no complicar las opciones. Por lo tanto, los grupos de especialistas
sólo deben ser considerados para un número muy pequeño de servicios clave cuando así existan
y cuando la tasa de llamadas respecto a esos servicios justifica un grupo separado de
especialistas.
30
Service Desk
Tener en cuenta la construcción del Punto Único de Contacto
Independientemente de la combinación de opciones seleccionadas para cumplir la estructura

general del Service Desk de la organización, los usuarios individuales no deben de tener duda
alguna sobre a quién contactar si requiere ayuda o dónde puede acceder para obtener soporte
vía auto ayuda. Un número de teléfono único (o un número para cada grupo si se opta por
Service Desks separados) debería ser proporcionado y publicado, así como una cuenta única de
correo electrónico y una página web de contacto al Service Desk.
Existen varias maneras para ayudar a publicitar el número telefónico y cuenta de correo
electrónico del Service Desk para que sean fácilmente disponibles para los usuarios, tales como:
 Incluir el número telefónico del Service Desk en las etiquetas de Hardware de los CI.
Adjunto al componente, el usuario probablemente llame acerca del mismo
 Imprimir detalles del contacto del Service Desk en los aparatos telefónicos
 Para las PCs y Laptops, utilizar un papel tapiz personalizado con los detalles de
contacto del Service Desk junto con información obtenida del sistema que necesitará
cuando contacte al Service Desk (tal como la dirección IP, versión del sistema operativo,
etc.)
 Imprimir el número del Service Desk en artículos promocionales (plumas, tapete para
ratones, tazas, etc.)
 Colocar detalles del Service Desk en sitios prominentes en la intranet/internet
 Incluir estos detalles del Service Desk en las hojas o correos de las encuesta de
satisfacción
31
Service Desk
 Repetir los detalles en toda la correspondencia enviada a los usuarios (junto con los
números de referencia)
 Colocar los detalles en los pizarrones de noticias o espacios físicos donde los usuarios
visitan con regularidad, es decir, entradas a los edificios, comedores, etc.)
Una campaña de sensibilización también puede incluir boletines en papel o electrónicos

enfocado a informar a los usuarios y clientes del Service Desk del concepto del Punto Único de
Contacto. El boletín debería enfatizar los beneficios para el negocio y TI del uso del Punto Único
de Contacto. Con el fin de generar interés sobre el Service Desk, se podría utilizar algunos
concursos de trivia, rompecabezas y otros juegos de prueba de conocimiento de los lectores.
Estos se pueden incluir en los boletines y sitios de internet/intranet.
32
Service Desk
33
Service Desk
34
Service Desk
Niveles de personal
Los niveles del personal deben ser apropiados con base en la demanda generada por el negocio.
La tasa de llamadas puede fluctuar dramáticamente pero la tasa y tipo de llamada deben ser
analizadas al momento de planificar un nuevo Service Desk. Una vez que esta información es
conocida, el personal del Service Desk puede ser calculado acorde a las necesidades reales.
Varias organizaciones encuentran que el pico del número de llamadas durante el inicio y fin de
la jornada laboral caen rápidamente, así como durante la primera parte de la tarde. Esto,
obviamente varía dependiendo del negocio de la organización pero es muy común un patrón
recurrente para varias organizaciones. En tales circunstancias, en ocasiones es posible utilizar
personal de tiempo parcial, empleados que trabajen desde casa, personal de segundo y tercer
nivel que cubran las horas pico.
Los siguientes factores beberían considerarse cuando se decidan los niveles de personal:
 Expectativas del servicio a clientes

 Requerimientos del negocio, tales como presupuesto, tiempos de respuesta, etc.
 El nivel de herramientas de auto ayuda disponibles y automatización para el manejo de
las solicitudes de servicio. Por ejemplo, reseteo de passwords
 Tamaño, antigüedad relativa, diseño y complejidad de la infraestructura de TI y el
catálogo de Servicios. Por ejemplo, el tipo y número de incidentes, la relación entre
software estándar e implementaciones personalizadas, etc.
 El número de usuarios y clientes a soportar, así como factores asociados tales como:
o Número de usuarios y clientes que hablan diferentes idiomas
o Nivel de habilidades
35
Service Desk
Incidentes y tipos de Solicitudes de Servicio (pudiendo incluir RFCs):
 Duración del tiempo requerido por tipo de llamada. Por ejemplo, simples solicitudes,
solicitudes de aplicaciones especializadas, hardware, etc.
 Experiencia requerida local o externa
 El volumen y tipo de incidentes y solicitudes de servicio
 El período de soporte cubierto y requerido basado en:
o Horario cubierto
o Requerimientos de soporte requerido
o Zonas horarias a ser cubiertas
o Localidades a ser cubiertas, particularmente si el Service Desk también realiza
soporte en sitio
o Distancias y tiempos entre localidades
o Patrones de cargas de trabajo. Por ejemplo, diario, fin de mes, etc.
o Los objetivos de niveles de servicio comprometidos (tiempo de respuesta, tiempo de
solución, etc.)
 El tipo de respuesta requerido:
o Teléfono
o Correo electrónico/Fax/Correo de voz/Video
o Chat en línea
o Texto
o Atención física
o Acceso/control remoto
 El nivel de capacitación requerido
 Las tecnologías de soporte disponibles. Por ejemplo, sistemas de telefonía, soporte
remoto, etc.
 El nivel de habilidades existente en el personal
 El proceso y procedimientos en uso
Todos estos elementos deberían ser cuidadosamente considerados antes de tomar alguna
decisión sobre el nivel de personal para el Service Desk. También debería ser reflejado en el
nivel de documentación requerido. Recuera que entre mejor el servicio, mayor será su uso por
parte del negocio
Una serie de herramientas se encuentran disponibles para ayudar a determinar el número

apropiado del personal en el Service Desk. Estas herramientas de modelado de cargas de
trabajo son dependientes del conocimiento detallado de la organización tales como volúmenes y
patrones de llamadas, servicios y perfiles de usuarios, etc.
Niveles de habilidades
La organización deberá decidir sobre el nivel y rango de habilidades requeridas por el personal
en su Service Desk, y asegurar que estas habilidades estén disponibles en los tiempos
apropiados.
36
Service Desk
Una gama de habilidades son posibles, empezando por el registro de llamadas sólo de un
servicio – cuando el personal del Service Desk requiere habilidades técnicas muy básicas – o a
través de un Service Desk técnico cuando las habilidades técnicas del personal son más
utilizadas en la organización. En el primer caso, existirá un manejo alto de las llamadas pero
una tasa baja de resolución, mientras en el segundo caso se revertirá.
La decisión sobre las habilidades requeridas casi siempre será dirigida por los tiempos de
resolución establecidos (acordados con el negocio y capturados en los objetivos de niveles de
servicio). La complejidad del sistema de soporte y “lo que el negocio está dispuesto a pagar”.
Existe una fuerte correlación entre costos y objetivos de respuesta y resolución – hablando
generalmente, entre más cortos los tiempos establecidos es más alto el costo porque son
requeridos más recursos.
Si bien puede haber casos en los que la dependencia del negocio o criticidad hace imperativo un
Service Desk con habilidades técnicas, el enfoque óptimo y la mejor relación costo-beneficio
generalmente es tener un primer nivel para registrar llamadas en el Service Desk con un
escalamiento rápido y efectivo al segundo y tercer nivel con mayores habilidades para resolver
donde el personal puede ser concentrado y utilizado de manera efectiva. Sin embargo, este punto
de partida puede ser mejorado con el transcurrir del tiempo al proveer al personal del primer
nivel con una base del conocimiento, scripts de diagnóstico y herramientas de soporte integral
(incluyendo un CMS), así como capacitación y conciencia continua, de modo que la tasa de
resolución el primer nivel puede ser incrementado de manera gradual.
Esto también se puede lograr mediante la localización del personal de segundo nivel en el
Service Desk, efectivamente, creando una estructura de dos niveles. Esto tiene la ventaja de
hacer el personal de segundo nivel disponible para ayudar a liderar con las llamadas durante
las horas pico y capacitar al personal de menor rango, con el fin de incrementar la tasa de
resolución de la primera llamada. Sin embargo, a menudo el personal de segundo nivel tiene
otras responsabilidades fuera del Service Desk. Adicionalmente, se tiene que liderar con las
llamadas de rutina lo que puede provocar desmotivación en el personal con mayor experiencia.
Un posible inconveniente adicional es que el Service Desk se convierta en buen resolutor de
llamadas, mientras que el personal de segundo nivel debe concentrarse en encontrar la causa
raíz en lugar de atender las llamadas.
Otro factor a considerar al momento de decidir sobre las necesidades de capacitación para el
personal del Service Desk es que el nivel de personalización o la especialización de los servicios
soportados. Entre más especializado sea el servicio, es más probable que el conocimiento sea
requerido durante la primer llamada.
Las mejoras en los tiempos de resolución no deberán dejarse al azar, sino deben ser parte de un
enfoque continuo para la mejora del servicio. Una vez que el nivel de habilidades ha sido
identificado, habrá una tarea continua para asegurar que el Service Desk sea operado de tal
manera que el personal necesario obtenga y mantenga las habilidades necesarias – y que el
personal con un balance correcto de habilidades sea responsable de los tiempos apropiados
para mantener una consistencia en la entrega de los servicios.
37
Service Desk
Esto involucrará un programa de capacitación y concientización el cual deberá incluir:
 Habilidades interpersonales, tales como habilidades para contestar el teléfono, buena

comunicación, atención al escuchar u capacitación sobre atención al cliente
 Conciencia sobre el negocio: conocimiento específico sobre las áreas del negocio de la
organización, conductores, estructura, prioridades, etc.
 Conocimiento de los servicios de TI clave de la organización para los cuales se provee
soporte
 Conocimiento técnico y capacitación técnica profunda al nivel apropiado, dependiendo
de la tasa de resolución buscada)
 Dependiendo del nivel de soporte provisto, algunas habilidades de diagnóstico. Por
ejemplo, Kepner y Tregoe
 Técnicas y herramientas de soporte
 Sensibilización y capacitación sobre los nuevos sistemas y tecnologías, de preferencia
previo a su introducción
 Procedimientos y procesos (en particular Gestión de Incidentes, Cambios y Activos de
Servicio y Configuración – pero también una visión generar sobre todos los procesos de
ITSM)
 Habilidades de mecanografía para asegurar la captura rápida y precisa sobre los
detalles de los incidentes y solicitudes de servicio
Capacitación
Es vital que todos los empleados del Service Desk sean adecuadamente capacitados antes de
formar parte del Service Desk. Esto debe incluir:
 Un programa formal de inducción

 Un programa de conciencia del negocio que incluya invertirle tiempo en conocer el
negocio
 Programas de mentoría que incluyan conocer de primera mano las actividades que realiza
el personal del Service Desk, así como el de soporte
Los mentores tal vez requieran ser capacitados sobre cómo ser un buen mentor. Habilidades
técnicas y experiencia en el Service Desk no es suficiente para ser mentor. Habilidades para
transferir de manera efectiva el conocimiento y enseñar sin ser condescendiente o amenazador
son igualmente importantes.
Será necesario un programa para mantener al personal del Service Desk actualizado con respecto
al conocimiento para que tomen conciencia sobre los nuevos desarrollos, servicios y tecnologías.
El calendario de este tipo de eventos es crítico para no afectar la operación normal. Varios
Service Desks encuentran que es mejor organizar tutoriales cortos durante periodos de carga de
trabajo ligera cuando el personal está menos requerido para la atención de llamadas.
Retención del personal

Es muy importante que todos los gerentes de TI reconozcan la importancia del Service Desk y
del personal que trabaja en él, así como darle esta atención especial. Cualquier pérdida
significativa del personal puede interrumpir y llevar a la inconsistencia en la entrega del
38
Service Desk
servicio, por lo tanto, se debe hacer un esfuerzo para hacer del Service Desk un lugar de trabajo
atractivo.
Súper usuarios
Algunas organizaciones encuentran útil designar un miembro de la comunidad de los usuarios
como “Súper usuario” para actuar como punto de enlace con TI en lo general y con el Service
Desk en lo particular.
Los Súper usuarios pueden recibir alguna capacitación y conciencia adicional, así como usarse
como un medio de comunicación en ambas direcciones. Se les puede pedir que filtren solicitudes
y asuntos relacionados con la comunidad de los usuarios (en algunos casos, se puede llegar más
allá como que ellos sean los que levanten los incidentes o solicitudes); esto puede ayudar a
prevenir “tormentas de incidentes” cuando un servicio o componente clave falle afectando un
gran número de usuarios. También pueden ser utilizados para difundir información del Service
Desk a su comunidad de usuarios local, lo cual puede ser muy útil en la difusión de los detalles
del servicio a todos los usuarios con gran rapidez.
Es muy importante señalar que los Súper usuarios deben registrar todas las llamadas que
manejen, y no sólo aquellas que ellos pasan a TI. Esto significará accesos, capacitación sobre
cómo utilizar la herramienta para registrar los incidentes. Esto ayudará a medir las actividades
de los Súper usuarios y también asegurar que no abusen de sus puestos. Adicionalmente, esto
asegurará información histórica de valor para mantener la calidad en la atención de los
incidentes y entrega de los servicios.
También es posible para los Súper usuarios que se involucren en:

 Capacitar al personal en su área
 Proveer soporte para incidentes menores o cumplir solicitudes sencillas
 Participar en nuevas liberaciones e implementaciones
Los Súper usuarios no necesariamente provén soporte de todo TI. En varias ocasiones, un Súper
usuario sólo proveerá soporte para una aplicación en específico, módulo o unidad de negocio.
Como usuario de negocio, el Súper usuario normalmente tiene conocimiento profundo sobre el
funcionamiento de los procesos clave del negocio y cómo trabajan los servicios en la práctica.
Esto es un conocimiento muy útil para compartir con el personal del Service Desk para brindar
una mejor calidad del servicio en el futuro
Antes de iniciar la selección y capacitación de los potenciales Súper usuarios, y específicamente

su administración, será necesario un compromiso firmado confirmando que tendrán el tiempo e
interés para desempeñar este rol.
Un Súper usuario es un enlace valioso entre el negocio y el Service Desk, por lo tanto deberá
recibir capacitación, responsabilidad y expectativa apropiada. Este rol de Súper usuario puede
ser vulnerable a mal uso si las responsabilidades y el proceso que gobierna las actividades del
rol no son comunicadas de manera clara a los usuarios. Por lo tanto, es imperativo que el Súper
usuario no sea visto como un reemplazo o medio para eludir el Service Desk.
39
Service Desk
Service Desk
Se deben proporcionar herramientas adecuadas y el apoyo tecnológico para que el personal del
Service Desk pueda desempeñar sus funciones lo más eficiente y eficaz posible. Esto incluirá lo
siguiente.
Telefonía
Debido a que es probable que un alto porcentaje de incidentes sean registrados por llamadas
telefónicas de los usuarios, el Service Desk debe contar con buenos servicios y telefonía
moderna. Esto debe incluir:
 Un sistema de distribución automática de llamadas (ACD) para permitir un número de
teléfono único (o números si un Service Desk distribuido o segmentada es la opción
preferida) y competencias del grupo para contestar. Advertencia: Si las opciones se
ofrecen a través del sistema ACD, y la selección es a través del teclado o de la respuesta
interactiva de voz (IVR), no utilice demasiados niveles de opciones u ofrecer opciones
ambiguas. Asimismo, no incluya "callejones sin salida" u opciones que una vez elegidas,
no permiten que la persona que llama vuelva a los menús anteriores
 Un software de integración de telefonía por computadora (CTI) para permitir el
reconocimiento de llamadas (a través del ACD vinculado) y la población automatizada
de datos de los usuarios en el registro de incidentes en el CMS
 Voz sobre protocolo de Internet (VoIP) - El uso de ésta tecnología puede reducir
significativamente los costos de telefonía al tratar con usuarios remotos e
internacionales
40
Service Desk
 Un software estadístico que permita obtener las estadísticas de telefonía a recabar y que
sea fácilmente impresas para su análisis - esto debe permitir que se obtenga la siguiente
información para cualquier período seleccionado:
o Número de llamadas recibidas, en total y desglosado por cualquier 'corte' - donde
cualquier sistema de llamadas ha sido elegido y está siendo prestado por un sistema
IVR / respuesta del teclado
o Perfiles de llamadas de entrada y tiempos de respuesta
o Tasa de abandono de llamadas
o Tasa de manejo de llamadas individuales por analista del Service Desk
o Duración promedio de la llamadas
 Manos libres, con capacidades de acceso de doble usuario (por lo menos en algunos de
los auriculares) para su uso durante el entrenamiento del nuevo personal, etc.
Herramientas de Soporte
Hay una serie de herramientas de soporte libres de Service Desk disponibles en el mercado y
algunas organizaciones pueden optar por realizar sus propios sistemas de registro y gestión de
incidentes. Si una organización tiene la intención de implementar seriamente ITSM, entonces se
debe de integrar un conjunto complejo de herramientas ITSM, también será necesario que tenga
un CMS y que ofrezca soporte integrado para todos los procesos de ITIL definidos.
Los elementos específicos de dicha herramienta que será especialmente benéfica para el Service
Desk incluyen los siguientes.
Base de Datos de Errores Conocidos

Una KEDB integrada debe ser utilizada para almacenar los detalles de los incidentes,
problemas, soluciones temporales, causas raíz y sus soluciones, por lo que cualquier
recurrencia de incidentes pueda ser diagnosticada y corregida de manera oportuna.
Para facilitar esto, se necesita la funcionalidad para clasificar y recuperar rápidamente los
errores conocidos previos, usando la coincidencia de patrones de búsqueda de palabras clave
contra los síntomas. La Gestión de la KEDB es responsabilidad de Gestión de Problemas, pero
el Service Desk la utilizará para facilitar la velocidad en el manejo de los incidentes.
Scripts de Diagnóstico
Se debe desarrollar Scripts de Diagnostico Multi-nivel, almacenar y gestionar para que el
personal del Service Desk pueda determinar la causa de las fallas. Se debe pedir a los Grupos
especializados de soporte y a los proveedores que proporcionen detalles de las fallas probables
y las preguntas clave que se realicen para identificar exactamente lo que ha sucedido mal - y los
detalles de las acciones de resolución a utilizar.
Estos datos deben ser incluidos en secuencias de comandos contextuales que deben aparecer en
la pantalla, dependiendo de la clasificación de múltiples niveles del incidente, y debe ser
impulsado por las respuestas de los usuarios a las preguntas de diagnóstico.
41
Service Desk
Interfaz Web de Autoayuda

A menudo es efectivo y conveniente proporcionar algún tipo de funcionalidad automatizada
"Autoayuda", para que los usuarios puedan buscar y obtener la ayuda que les permita resolver
sus propias dificultades. Idealmente, esto debería ser a través de una interfaz web 24/7 que esté
dirigida por un menú de selección y puede incluir lo siguiente, según sea conveniente:
 Preguntas frecuentes (FAQ) y soluciones

 Capacidad de búsqueda de “Cómo hacerlo”, para guiar a los usuarios a través de una
lista contextual de tareas o actividades
 Un servicio de anuncios tipo boletín, que contenga los detalles de los problemas de
servicio y problemas pendientes junto con los tiempos de restauración previstos
 Capacidades de cambio de contraseña - usando software de protección de contraseñas
para comprobar identidades, contraseñas de autorización y realizar cambios sin la
necesidad de la intervención del Service Desk
 Aviso de cualquier tiempo de inactividad planificado, cortes de servicios o
degradaciones.
La solución de Autoayuda debe incluir la capacidad para que los usuarios registren los
incidentes, esto se puede utilizar durante períodos que el Service Desk está cerrado (si no
funciona 24/7) y serán atendidos por el personal del Service Desk al comienzo del próximo
turno.
Algunos cuidados que se debe tener para asegurar que las actividades de Autoayuda
seleccionadas para su inclusión no sean demasiado avanzados para el usuario promedio y que
se incluyen los “salvavidas” para evitar que poco de conocimiento sea algo peligroso. Puede
ser posible ofrecer opciones de autoayuda un poco más avanzadas para "Súper usuarios" que
han recibido capacitación adicional. También es necesario tener mucho cuidado con las
suposiciones hechas al personal del Service Desk acerca de la cantidad de uso que los usuarios
hacen de los servicios de autoayuda.
Tenga en cuenta que, como ya se ha cubierto en la lista anterior, es posible combinar algunas de
las actividades más simples de cumplimiento de solicitudes como parte de una estrategia global
de autoayuda del sistema - que también pueden ser de gran beneficio en la reducción de
llamadas al Service Desk.
Control Remoto
A menudo es útil para los analistas de Service Desk ser capaces de tomar el control del
escritorio de los usuarios con el fin de llevar a cabo las investigaciones o los ajustes correctos,
etc. Para ello, se necesitarán facilidades de control remoto
Herramientas de Soporte de Planeación de Continuidad de los Servicios de TI para ITSM

Las organizaciones tienden a convertirse rápidamente en dependientes de sus herramientas de
ITSM y será más difícil trabajar sin ellas. Un análisis completo de impacto al negocio y
evaluación de riesgos se debe realizar y se debe desarrollar planes para asegurar la
Continuidad del Servicio de TI adecuada y los niveles de resistencia.
42
Service Desk
Midiendo el desempeño del Service Desk

Se deben establecerse métricas para establecer el rendimiento del Service Desk y que sea
evaluado en intervalos regulares. Esto es importante para medir la salud, madurez, eficiencia,
eficacia y oportunidades de mejora en la operación del Service Desk.
Las métricas de rendimiento para el Service Desk deben ser realistas y cuidadosamente
seleccionadas. Es común seleccionar aquellos indicadores que están fácilmente disponibles y
pueden parecer ser un buen indicador de rendimiento, sin embargo, esto puede ser engañoso.
Por ejemplo, el número total de llamadas recibidas por el Service Desk no es en sí misma una
indicación de un buen o mal desempeño y de hecho puede ser causada por acontecimientos que
son completamente ajenas a la voluntad del Service Desk, tal como un período particularmente
activo para la organización o el lanzamiento de una nueva versión de un sistema corporativo
importante.
Un aumento en el número de llamadas al Service Desk puede indicar servicios menos fiables en
ese período de tiempo pero también puede indicar una mayor confianza de los usuarios en un
Service Desk que está madurando, lo que resulta en una mayor probabilidad de que los usuarios
buscan ayuda en lugar de tratar hacer frente solo. Para que este tipo de métrica pueda ser fiable
y llegar a una conclusión, se necesita la comparación de períodos anteriores para cualquier
mejora del servicio realizado desde la última línea base, o cambios en la fiabilidad del mismo,
problemas, etc. para aislar la causa real del aumento de llamadas.
43
Service Desk
Por lo tanto, se necesita un análisis más detallado y métricas más detalladas, por ejemplo:
 El porcentaje de llamadas resueltas durante el primer contacto con el Service Desk. Por
ejemplo, cuando el usuario todavía está en el teléfono para reportar la llamada
 El porcentaje de llamadas resueltas por el personal del Service Desk, sin tener que
buscar apoyo en otros grupos. Tenga en cuenta que algunos Service Desk pueden elegir
la asignación de personal más técnico en segundo nivel que el personal del Service Desk.
En tales casos, es importante a la hora de hacer comparaciones separar también por: (i)
porcentaje de resolución por parte de Service Desk solo, y (ii) el porcentaje resuelto por
el personal de servicio de primer nivel del Service Desk y del personal del segundo nivel
de apoyo combinado
 El tiempo promedio para resolver un incidente (cuando se resuelve en primer nivel)
 Tiempo promedio para escalar un incidente (cuando no es posible su resolución en
primer nivel)
 Costo promedio del manejo de un incidente. Tres indicadores deben ser considerados
aquí:
o Costo total del Service Desk dividido por el número de llamadas. Esto proporcionará
un valor promedio que será útil como un índice para fines de planificación, pero no
representa con precisión los costos relativos de diferentes tipos de llamadas
o Porcentaje de tiempo de duración de llamada en el Service Desk global y el costo por
minuto (costos totales para el período dividido por el total de minutos de duración de
las llamadas). Esto se puede utilizar para calcular el costo de las llamadas
individuales y dar una cifra más precisa
o El costo por tipo de llamada. Mediante la evaluación de los tipos de incidentes con
duración de la llamada, una imagen más refinada surge y da una indicación de los
tipos de incidentes que tienden a costar más resolver. Estos deben convertirse en
objetivos probables en la búsqueda de mejoras
 Porcentaje de actualizaciones de datos de clientes o usuarios realizadas en tiempos
objetivo, tal como se define los SLAs
 Tiempo promedio para revisar y cerrar una llamada resuelta
 El número de llamadas desglosadas según la hora del día y día de la semana, junto con
las métricas de tiempo promedio de llamadas, es crítico para determinar el número de
personal necesario
Encuestas de satisfacción de Cliente/Usuario

Así como el seguimiento de las métricas "duras" de desempeño del Service Desk (a través de los
indicadores descritos anteriormente), también es importante evaluar medidas “flexibles”, como
lo bien que los clientes y usuarios sienten que sus llamadas han sido contestadas, si sienten que
el operador del Service Desk fue cortés y profesional y si se percibe confianza en el usuario.
Este tipo de métricas se obtiene mejor a partir de los propios usuarios a través de encuestas de
satisfacción. Las ventajas y desventajas de los diferentes tipos de encuestas se demuestran la
siguiente tabla.
44
Service Desk
Técnicas y Herramientas para Encuestas
Técnica/Herramienta Ventajas Desventajas

Encuesta después de la llamada Tasa de respuesta alta- el Las personas pueden sentirse
Las personas que llaman se les usuario ya está en la línea. presionados a tomar la encuesta,
pide que permanezcan en el La experiencia es reciente. lo que resulta en una experiencia
teléfono después de la llamada y de servicio negativa. El
luego se les pide que califiquen el evaluador se ve como parte del
servicio recibido. Service Desk encuestado, lo que
puede desalentar respuestas
objetivas.
Encuesta telefónica saliente Mayor respuesta – el usuario Podría ser visto como una
Los clientes y usuarios que han que llama se entrevista intromisión - interrumpe al
utilizado el Servicio Desk se directamente. Categorías usuario / cliente trabajo. La
ponen en contacto algún tiempo especiales de usuario o cliente percepción puede haber
después de su experiencia con él. puede ser un objeto de cambiado
realimentación.
Entrevistas personales El entrevistador es capaz de Las entrevistas consumen mucho
Los clientes y usuarios son observar señales no verbales, tiempo.
entrevistados personalmente por así como señales verbales. Los
los elementos que realiza la usuarios y clientes sienten un Podría convertirse en sesiones de
encuesta. mayor grado de atención quejas.
personal.
Entrevistas en grupo Un mayor número de usuarios y La gente no puede expresarse
Los clientes y usuarios son clientes pueden ser libremente delante de sus
entrevistados en grupos pequeños entrevistados. Las preguntas son compañeros o directivos.
más genéricas y por lo tanto
más consistentes las entrevistas. Opiniones de la gente pueden
cambiar fácilmente por otros en
el grupo.
Encuestas por correo Pueden ser dirigidas a clientes Son laboriosas para procesar. El
Cuestionarios de la encuesta se específicos o a todos los porcentaje de personas que
envían a un grupo objetivo de usuarios. Puede ser anónima, respondieron a las encuestas por
clientes y usuarios. Se les pide permitiendo a la gente correo tiende a ser pequeña. La
que devuelvan sus respuestas por expresarse con mayor libertad. mala interpretación de una
correo electrónico o correo Encuestas por correo pregunta puede afectar el
postal. electrónico pueden ser creadas resultado.
usando formularios
automatizados que hacen que
sea más conveniente y fácil para
el usuario responder y aumentar
la probabilidad de que se
complete.
Encuestas en línea. Grandes audiencias potenciales El tipo y porcentaje de
Los cuestionarios se publican en pueden completar el encuestados no se puede
un sitio web y los usuarios y cuestionario en su propio predecir.
clientes alentados por correo tiempo. Los enlaces a sitios web
electrónico o enlaces de un sitio populares son un buen
se les pide participar en la recordatorio sin ser
encuesta. entrometido.
45
Service Desk
Entorno del Service Desk

El entorno donde el Service Desk debe ser cuidadosamente elegido. Siempre que sea posible,
las instalaciones deberán facilitar:
 Un lugar donde se coloca la función entera con suficiente luz natural y espacio global -
para permitir una adecuada recepción y espacio de almacenamiento y espacio para
moverse si es necesario.
 Fácil acceso a las consolas, pantallas de control y tableros de mensajes para obtener
rápidamente una imagen de cualquier operación clave o eventos de servicio, o los
problemas que pueden estar ocurriendo
 Un ambiente tranquilo con control acústico suficiente para que una conversación
telefónica no se vea interrumpida por otra
 Entornos agradables y muebles cómodos, con el fin de aligerar el ambiente (el Service
Desk puede ser un lugar muy estresante para trabajar, ¡así que todo ayuda!)
 Un lugar de descanso y un área de relajamiento por separado y cerca del personal para
que puedan tomar pequeños descansos cuando sea necesario, sin estar lejos por mucho
tiempo
46
Service Desk
Outsourcing del Service Desk

La decisión de externalizar es una cuestión estratégica para los altos directivos - y se trata en
detalle en Estrategia del Servicio y Diseño del Servicio de ITIL. Muchas de las directrices de
esta sección no son exclusivas del Service Desk y se puede aplicar a cualquier función, áreas
de soporte o servicios que se externalizan (o subcontratan).
Independientemente de las razones o la extensión del Service Desk, el contrato de outsourcing

es vital que la organización se reserve la responsabilidad de las actividades y servicios
prestados por el Service Desk. La organización es responsable en última instancia por los
resultados de la decisión. Y por lo tanto, debe determinar qué servicios proporcionará el
proveedor externo y no al revés
Si la ruta de outsourcing es elegida, algunas “salvaguardas” son necesarios para garantizar

que el Service Desk tercerizado funciona de manera efectiva y eficiente con otros equipos de TI y
departamentos de la organización, y que el control de la gestión de servicios de punta a punta
se mantiene (esto es particularmente importante para las organizaciones que buscan certificarse
en ISO / IEC 20000 un control de gestión en general tiene que ser demostrado). Algunas de estas
medidas de seguridad se exponen a continuación.
Herramientas y Procesos Comunes

El Service Desk no tiene la responsabilidad de todos los procesos y procedimientos que se
entregan. Por ejemplo, una solicitud de servicio es recibido por el Service Desk pero la petición
se cumple por el equipo interno de TI en operación.
47
Service Desk
Si el Service Desk se tiene en outsourcing, se debe tener cuidado para que las herramientas sean
consistentes con las que todavía se utilizan en la organización del cliente. El outsourcing a
menudo es visto como una oportunidad para reemplazar herramientas obsoletas o inadecuadas,
sólo para descubrir que hay problemas graves de integración entre la nueva herramienta y las
herramientas existentes y procesos.
Por esta razón, es importante asegurarse de que estos asuntos sean investigados y que los
requisitos del cliente sean especificados adecuadamente antes de que se genere el contrato de
outsourcing. Las Herramientas de Service Desk deben no sólo soportar al Service Desk en
outsourcing, sino que también debe apoyar los procesos de la organización del cliente y los
requisitos del negocio.
Idealmente el Service Desk subcontratado debe utilizar las mismas herramientas y procesos (o,
como mínimo, las herramientas de interfaz y los procesos) para permitir el flujo suave entre el
Service Desk y los grupos de apoyo de segundo y tercer nivel.
Además, el Service Desk subcontratado debe tener acceso a:

 Todos la información y registros de incidentes
 Información y registros de problemas
 Datos de Errores conocidos
 Agenda de Cambios
 Fuentes de conocimiento internas (especialmente de los expertos técnicos o de
aplicaciones)
 SKMS
 CMS
 Alertas de herramientas de monitoreo.
A menudo es un reto la integración de procesos y herramientas en una organización menos

madura con los de una organización más madura. Una suposición común pero incorrecta es que
la madurez de la organización de alguna manera se traducirá en una mayor madurez en la otra.
La participación activa para asegurar la alineación de los procesos y herramientas es esencial
para una transición sin problemas y la gestión continua de los servicios entre las organizaciones
internas y externas. De hecho, si esto no se aborda directamente, podría resultar en el fallo del
contrato.
También se suele asumir erróneamente que la evidencia de gestión de la calidad y madurez del
servicio en un colaborador externo puede ser garantizada al establecer requisitos en el proceso
de contratación de “conformidad con ITIL y/o ISO/IEC 20000”. Estas declaraciones pueden
indicar que un posible proveedor utiliza el marco de ITIL en su prestación de servicios a los
clientes, o que han obtenido la certificación de las normas por sus prácticas internas, pero es
igualmente importante contar con la tecnología que permita demostrar que el proveedor de
servicios tiene la capacidad para gestionar los servicios y la interfaz con las prácticas internas
con armonía. No existe una norma de cumplimiento que asegure esto, por lo que los esfuerzos
de contratación deben incluir preguntas específicas para cumplir con este requisito. Más
información sobre la adquisición de un proveedor externo se puede encontrar en Diseño del
Servicio de ITIL.
48
Service Desk
Objetivos de SLAs
Los objetivos de los SLAs para el manejo de incidentes en general y los tiempos de resolución
deben ser acordados con los clientes y entre todos los equipos y departamentos - y objetivos de
los OLAs / UCs deben ser coordinadas y acordadas con los grupos de soporte individuales para
sustentar y apoyar los objetivos de los SLAs.
Buena Comunicación
Las líneas de comunicación entre el Service Desk externalizados y los otros grupos de apoyo
tienen que trabajar de manera eficaz. Esto puede ser ayudado por algunos o todos de los
siguientes pasos:
 Ubicación física cercana

 Reuniones de enlace/revisión periódicas
 Capacitación constante, tutoriales entre los equipos y departamentos
 Acuerdos de asociación cuando el personal de ambas organizaciones se apoyan
conjuntamente para proveer de personal del Service Desk
 Planes de comunicación y las metas de desempeño se documentarán de manera
consistente en los OLAs y UCs
En los casos en que se ubica el Service Desk en el extranjero, no todas estas medidas serán
posibles. Sin embargo, la necesidad de capacitación y comunicación del personal del Service
Desk sigue siendo crítica, y más aún en los casos en que existen diferencias lingüísticas y
culturales.
Propiedad de los Datos

Propiedad clara de los datos recogidos por el Service Desk subcontratado debe ser establecida.
La propiedad de todos los datos relativos a usuarios, clientes, CIs afectados, servicios,
incidentes, solicitudes de servicio, cambios, etc. debe permanecer con la organización que es
esta externalizando la actividad, pero ambas organizaciones necesitan tener acceso a la misma.
Todos los requisitos de presentación de informes y las cuestiones alrededor de la propiedad de

los datos se deben especificar en el UCs con la empresa que presta el servicio de outsourcing.
49
Service Desk
50
Service Desk
51
Gestión Técnica
52
Gestión Técnica
Mediante el desempeño de estos dos roles, la Gestión Técnica es capaz de garantizar que la
organización tenga acceso al tipo y nivel correcto de recursos humanos para gestionar la
tecnología y cumplir así los objetivos de negocio. La definición de los requerimientos para estos
roles inicia en Estrategia del Servicio y se expande en Diseño del Servicio, se valida en
Transición del Servicio y se refina en CSI.
Otro rol muy importante que juega Gestión Técnica es proporcionar orientación a operaciones
de TI sobre cómo llevar a cabo una mejor manera la gestión operacional cotidiana de la
tecnología. Este rol se lleva a cabo parcialmente durante el proceso de Diseño del Servicio, pero
también es parte de la comunicación diaria con Gestión de Operaciones de TI al buscar
alcanzar la estabilidad y desempeño óptimo.
53
Gestión Técnica
54
Gestión Técnica
Algunos ejemplos:
 Identificar el conocimiento y habilidades especializadas requeridos para gestionar y

operar la infraestructura y entregar los servicios de TI
 Documentar las habilidades que existen en la organización, así como aquellas
habilidades que necesitarán ser desarrolladas
 Comenzar programas de capacitación y mantener registros de la capacitación de todo el
personal técnicos
 Diseñar y entregar la capacitación a los usuarios del Service Desk y otros grupos
 Reclutar o contratar recursos con habilidades que no puedan ser desarrolladas
internamente, o donde haya insuficiencias
 Definir los estándares para el diseño de nuevas arquitecturas y participar en la
definición, diseño y desarrollo de arquitecturas de tecnología
 Investigar y desarrollar soluciones que puedan ayudar a expandir el portafolio de
servicios y que puedan ser utilizadas para simplificar o automatizar las operaciones de
TI, reducir costos o incrementar los niveles de servicio de TI
 Participar en proyectos, no sólo durante el Diseño del Servicio y la Transición del
Servicio, sino también para CSI o proyectos de operaciones, tales como actualizaciones
de versión de sistemas operativos, proyectos de consolidación de servidores o
movimientos físicos
 Llevar a cabo la Ingeniería de la Disponibilidad y Gestión de la Capacidad para los
servicios de TI con el fin de alcanzar los niveles de servicio requeridos por el negocio
 Evaluar los riesgos, identificar dependencias críticas entre los servicios y sistemas así
como definir e implementar medidas de respuesta.
55
Gestión Técnica
 Diseñar y efectuar pruebas de funcionalidad, desempeño y manejo de los servicios de TI

para soportar las actividades de Transición del Servicio.
 Gestionar a los proveedores- muchos departamentos o grupos de Gestión Técnica son los
únicos que saben exactamente lo que se requiere de un proveedor y cómo medirlos y
manejarlos
 Definir y gestionar los estándares y herramientas de Gestión de Eventos
 Participara en la resolución de incidentes y problemas
 Soportar a Gestión de Problemas en la validación y mantenimiento de la KEDB
 Soportar el proceso de Gestión de Cambios donde puede ser necesario confiar en los
conocimientos y dominio técnicos para evaluar los cambios
 Ayudar en la implantación de liberaciones
 Proporcionar información para mantener operacionalmente el CMS y sus datos
 Identificar oportunidades de mejora
 Garantizar que toda la documentación de los sistemas y la operación esté actualizada y
sea utilizada apropiadamente
 Actualizar y mantener los datos usados para reportar las capacidades técnicas y del
servicio, por ejemplo: Gestión de la Capacidad, Gestión de la Disponibilidad, Gestión de
Problemas, etc.
 Ayudar a la Gestión Financiera de los Servicios de TI para identificar el costo de la
tecnología y recursos humanos utilizados para gestionar los servicios de TI
 Definir las actividades operacionales desempeñadas como parte de Gestión de
Operaciones de TI
56
Gestión de Aplicaciones
57
Función Gestión de Aplicaciones

Gestión de Aplicaciones es responsable de administrar las aplicaciones a lo largo de su ciclo de
vida. Esto difiere del desarrollo de aplicaciones en el sentido de que Gestión de Aplicaciones
cubre todo el ciclo de vida continuo de una aplicación, incluyendo los requerimientos, diseño,
construcción, implantación, operación y optimización. Desarrollo de aplicaciones tiene que ver
principalmente con las actividades que sólo se llevan a cabo una vez para los requerimientos,
diseño y construcción de las aplicaciones.
Roles de Gestión de Aplicaciones

Gestión de Aplicaciones es para las aplicaciones lo que Gestión Técnica es para la
infraestructura de TI. Las actividades de Gestión de Aplicaciones son desempeñadas en todas
las aplicaciones, ya sea compradas o desarrolladas internamente. Una de las decisiones clave a
las que contribuyen es sobre la definición de hacer o comprar la aplicación.
Al desempeñar estos roles, Gestión de Aplicaciones es capaz de garantizar que la organización

tenga acceso al tipo y nivel correctos de recursos humanos para gestionar las aplicaciones y por
lo tanto, a cumplir con los objetivos de negocio. Esto comienza en Estrategia del Servicio y se
amplía en Diseño del Servicio, se prueba en Transición del Servicio y se refina en CSI. Uno de
sus objetivos clave es garantizar un balance entre el nivel de habilidades y el costo de estos
recursos.
Gestión de Aplicaciones también desempeña otros roles específicos:
 Proporcionar orientación a operaciones de TI con respecto a cómo llevar a cabo de la

mejor manera la gestión operacional del día a día de las aplicaciones. Este rol se ejecuta
en parte durante el proceso de Diseño del Servicio, pero también es parte de la
comunicación cotidiana con Gestión de Operaciones de TI al buscar alcanzar la
estabilidad y el desempeño óptimo.
 La integración del ciclo de vida de Gestión de Aplicaciones en el ciclo de vida del
servicio.
58
Los objetivos son alcanzados a través de:
 Aplicaciones que están bien diseñadas, son resistentes a los cambios y efectivas en costo
 Garantizar que la funcionalidad requerida está disponible para alcanzar los resultados
de negocio necesita
 La organización de habilidades técnicas para mantener las aplicaciones operacionales
en condiciones óptimas
 Prontitud en el empleo de habilidades técnicas para diagnosticar y resolver rápidamente
las fallas que lleguen a ocurrir
59
Actividades Genéricas de Gestión de Aplicaciones

Mientras que la mayoría de los equipos o departamentos de Gestión de Aplicaciones están
dedicados a conjuntos de aplicaciones específicas, existe un cierto número de actividades que
tienen en común. Estas incluyen:
 Identificar los conocimientos y grado de dominio requeridos para administrar y operar
las aplicaciones en la entrega de servicios de TI
 Iniciar programas de capacitación para desarrollar y refinar las habilidades en los
recursos adecuados de Gestión de Aplicaciones y mantener registros de la capacitación
de estos recursos
 Reclutar o contratar recursos con las habilidades que no puedan ser desarrolladas
internamente o donde existan insuficiencias
 Diseñar y entregar la capacitación para usuarios finales
 Realizar con recursos internos (insourcing) actividades específicas donde las habilidades
requeridas no están disponibles internamente o en el mercado abierto, o donde resulte
más efectivo en costo hacerlo así
 Definir estándares usados en el diseño de nuevas arquitecturas y participación en la
definición de arquitecturas de aplicaciones durante el proceso de Estrategia del Servicio
 Investigar y desarrollar soluciones que puedan ayudar a expandir el portafolio de
servicios o que puedan ser usadas para simplificar o automatizar las operaciones de TI,
reducir costos o incrementar los niveles de servicio de TI
 Participar en el diseño y construcción de nuevos servicios
 Participar en proyectos, no solo durante el proceso de Diseño del Servicio, sino también
para CSI o proyectos operacionales, tales como actualizaciones de versión de sistemas
operativos, proyectos de consolidación o movimientos físicos
60
 Diseñar y ejecutar pruebas de funcionalidad, desempeño y manejo de los servicios de TI.

Diseñar aplicaciones para alcanzar los niveles de servicio requeridos por el negocio
 Asistir en la evaluación de riesgos, identificar dependencias críticas entre los servicios y
sistemas así como definir e implementar medidas de respuesta.
 Gestionar a los proveedores
 Estar involucrado en la definición de estándares de Gestión de Eventos y especialmente
en la instrumentación de aplicaciones para la generación de eventos significativos
 Proporcionar recursos de Gestión de Aplicaciones que puedan contribuir a la ejecución
de los procesos de Gestión de Problemas
 Definir sistemas de codificación que sean usados en la Gestión de Problemas (ej.:
categorías de incidentes)
 Proporcionar recursos para soportar la Gestión de Problemas en la validación y
mantenimiento de la KEDB junto con los equipos de desarrollo de aplicaciones
 Soportar la Gestión de Cambios con los conocimientos y el dominio técnico de las
aplicaciones para evaluar los cambios
 Participar en las actividades de Liberación e Implementación. Frecuentemente, Gestión
de Aplicaciones es quien maneja el proceso de Gestión de Liberación e Implementación
para las aplicaciones que gestionan
 Definir, gestionar y mantener los atributos y relaciones de los CIs de las aplicaciones en
el CMS
 Identificar oportunidades de mejora y ayudar en la evaluación de soluciones alternativas
 Coordinar con los equipos de desarrollo para garantizar que se establezcan mecanismos
para almacenar y mantener la documentación relacionada con las aplicaciones
 Llevar a cabo el análisis de las necesidades de capacitación y mantener los inventarios
de habilidades
 Ayudar a la Gestión Financiera de los servicios de TI para identificar el costo de la
gestión de las aplicaciones actuales
 Definir las actividades operacionales relacionadas con las aplicaciones que serán
desempeñadas como parte de Gestión de Operaciones de TI
 Alimentar y dar mantenimiento a las políticas de configuración de software
Para todas las aplicaciones clave serán necesarios equipos o departamentos de Gestión de
Aplicaciones. La naturaleza exacta de su rol variará dependiendo de las aplicaciones que
sean soportadas, pero las responsabilidades genéricas normalmente incluyen:
 Soporte de tercer nivel para incidentes relacionados con la o las aplicaciones

 Involucramiento en los planes de pruebas de operación y en temas de desarrollo
 Seguimiento a fallas del sistema y gestión de parches
 Involucramiento en situaciones de operación y soporte de aplicaciones
 Dimensionamiento y desempeño de aplicaciones; métricas de volumen y pruebas de
carga, etc.
 Involucramiento en el desarrollo de políticas de liberación
 Identificación de mejoras a software existente, desde ambas perspectivas, funcional y
administrativa
61
Gestión de Operaciones de TI
62
En el negocio, el término “Gestión de Operaciones” se usa con el significado de departamento,

grupo o equipo de personas responsable de desempeñar las actividades cotidianas de la
organización.
Gestión de Operaciones generalmente tiene las siguientes características:
 Se está ejecutando trabajo para garantizar que un dispositivo, sistema o proceso está
realmente corriendo o trabajando (contrariamente a la estrategia o la planeación
 Es aquí donde los planes se convierten en acciones
 El enfoque es en actividades diarias o de corto plazo, aunque hay que hacer notar que
estas actividades generalmente serán desempeñadas y repetidas a lo largo de un periodo
de tiempo relativamente extenso (contrariamente a una actividad del tipo de las
realizadas en un proyecto)
 Esta actividades son ejecutadas por personal técnico especializado, el cual,
frecuentemente tiene que pasar por capacitación técnica para aprender a desempeñar
cada actividad
 El enfoque está en construir acciones consistentes y repetitivas que, si se repiten con la
suficiente frecuencia con el nivel de calidad adecuado, garantizarán el éxito de la
operación
 Aquí es donde se entrega y se mide el valor real de la organización
 Existe una dependencia, en inversión en equipo o recursos humanos o en ambas
 El valor generado debe exceder el costo de la inversión y todos los otros gastos
organizacionales(tales como costos administrativos y de mercadotecnia) si realmente se
desea que el negocio tenga éxito
De forma similar, la Gestión de Operaciones de TI puede ser definida como la función

responsable de la gestión y el mantenimiento cotidiano de la infraestructura de TI de una
organización para garantizar que se entregue al negocio el nivel de servicios de TI acordado.
Operaciones de TI puede definirse como el conjunto de actividades involucradas para que la

infraestructura de TI funcione día a día con el propósito de entregar servicios de acuerdo con
los niveles acordados para cumplir con los objetivos establecidos del negocio.
63
64
Control de Operaciones de TI
Control de operaciones de TI supervisa la ejecución y el monitoreo de las actividades
operacionales y eventos en la infraestructura de TI. Esto puede hacerse con la ayuda de un
puente de operaciones o un centro de operaciones de red. Adicionalmente a la ejecución de
tareas rutinarias de todas las áreas técnicas, Control de Operaciones de TI también desempeña
las siguientes tareas específicas:
 Administración de consola/ puente de operaciones, que se refiere a definir una

capacidad central de observación y monitoreo y posteriormente usar dichas consolas
para ejercer la Gestión de Eventos, el monitoreo y el control de actividades
 Programación de tareas, o la gestión de trabajos batch o scripts rutinarios
 Respaldo y restauración en representación de todos los equipos y departamentos
técnicos y de Gestión de Aplicaciones y también en representación de los usuarios
 Gestión de impresión y salidas para la organización y distribución de todas la
impresiones centralizadas o salidas electrónicas
 Desempeño de las actividades de mantenimiento en representación de los equipos o
departamentos técnicos o de Gestión de Aplicaciones
65
Gestión de Instalaciones
Gestión de Instalaciones se refiere a la administración del ambiente físico de TI, típicamente un
centro de datos o cuartos de computadoras y sites de recuperación junto con el equipo de
generación de energía y enfriamiento. Gestión de Instalaciones también incluye la coordinación
de proyectos de consolidación a gran escala, por ejemplo, la consolidación de centros de datos,
o proyectos de consolidación de servidores. En algunos casos, la gestión del centro de datos se
hace a través de un tercero externo, en cuyo caso la gestión de instalaciones se refiere a la
administración del contrato de outsourcing.
Como ocurre en muchos de los procesos y funciones de ITSM, Gestión de Operaciones de TI

juega un doble rol:
 Gestión de Operaciones de TI es responsable de la ejecución de las actividades y los

estándares de desempeño definidos durante Diseño del Servicio y probados durante
Transición del Servicio. En este sentido, el rol de operaciones de TI es principalmente
mantener el estatus quo. La estabilidad de la infraestructura de TI y la consistencia de
los servicios de TI es de interés fundamental para las operaciones de TI. Incluso las
mejoras operacionales están encaminadas a encontrar mejores y más simples formas de
hacer lo mismo.
 Al mismo tiempo, operaciones de TI es parte del proceso de adicionar valor a las

diferentes líneas de negocio y de soportar la red de valor. La capacidad del negocio para
cumplir sus objetivos y seguir siendo competitivos depende del resultado y la
confiabilidad de la operación cotidiana de TI. Como tal, Gestión de Operaciones debe
ser capaz de adaptarse continuamente a los requerimientos y la demanda del negocio. Al
66
negocio no le interesa si operaciones de TI cumplió con un procedimiento estándar o que

un servidor se desempeñó óptimamente. Conforme la demanda y los requerimientos del
negocio cambian, Gestión de Operaciones de TI debe ser capaz de seguir a la par,
desafiando frecuentemente el status quo.
Operaciones de TI debe lograr un balance entre estos roles, para lo que requerirá de lo
siguiente:
 Entendimiento de cómo se utiliza la tecnología para proporcionar servicios de TI

 Entendimiento de la importancia relativa y el impacto de dichos servicios en el negocio
 Procedimientos y manuales que describan el rol de operaciones de TI en ambos, tanto en
la administración de la tecnología como en la entrega de servicios de TI
 Un conjunto de métricas claramente diferenciadas para reportar al negocio el
cumplimiento de los objetivos del servicio; y para reportar a los gerentes de TI sobre la
eficiencia y efectividad de las operaciones de TI
 Todo el personal de operaciones de TI entiende exactamente cómo afecta el desempeño
de la tecnología en la entrega de los servicios de TI
 Entendimiento de la importancia relativa y el impacto de dichos servicios en el negocio
 Una estrategia de costos destinada a balancear los requerimientos de las diferentes
unidades de negocio con los ahorros en costos, disponibles a través de la optimización
de la tecnología existente o la inversión en nueva tecnología
 Una estrategia de ROI basada en el valor más que en el costo
67
Organización de Gestión de Operaciones de TI

La tabla de técnicas y herramientas para encuestas mostrada anteriormente en esta sección
demostró que Gestión de Operaciones de TI es una función por sí misma; sin embrago, es
importante recordar que la función está compuesta por personal de otros grupos técnicos y de
Gestión de Aplicaciones.
Esto significa que algunos departamentos o grupos técnicos y de Gestión de Aplicaciones

administrarán y ejecutarán sus propias actividades operacionales. Otros delegarán estas
actividades a un departamento dedicado a operaciones de TI.
No hay un solo método para asignar actividades, ya que depende de la madurez y estabilidad de
la infraestructura que se está administrando. Por ejemplo, las áreas técnicas y de Gestión de
Aplicaciones que son bastante nuevas e inestables tienden a administrar sus propias
operaciones. Los grupos donde la tecnología o aplicaciones son estables, maduras y bien
entendidas, tienden a haber estandarizado más sus operaciones y por lo tanto se sentirán más
cómodas delegando estas actividades.
68
Tecnología
Las herramientas permitirán que los procesos de Diseño del Servicio trabajen más
efectivamente. Las herramientas aumentarán la eficiencia y la efectividad y proporcionarán
abundancia de información gerencial, llevando a la identificación de debilidades y
oportunidades de mejora. Los beneficios a largo plazo que se obtienen con el uso de
herramientas son ahorros en el costo y aumento en la productividad, lo cual a su vez puede
llevar a elevar la calidad de la provisión de los servicios de TI.
El uso de herramientas permitirá la centralización de procesos clave y la automatización e

integración de los procesos fundamentales de gestión de servicios. Los datos brutos recopilados
por las herramientas pueden ser analizados, resultando en la identificación de “tendencias”. Se
pueden implementar medidas preventivas, nuevamente, elevando la calidad de la provisión de
servicios de TI.
Definiendo los Requerimientos de la Herramienta

Algunos puntos que las organizaciones deben considerar al evaluar las herramientas de gestión
de servicios incluyen:
 Estructura de los datos, manejo e integración de los datos

 Integración de componentes de infraestructura de distintos fabricantes y la necesidad de
poder incluir nuevos componentes en el futuro – esto establecerá demandas especiales en
las capacidades de la herramienta para el manejo y modelado de datos
 Conformidad con los estándares abiertos internacionales
 Flexibilidad en la implementación, uso y compartición de datos.
 Capacidad de ser usado - la facilidad de uso ofrecida por la interface de usuario
69
Tecnología
 Soporte para el monitoreo de los niveles de servicio

 Clientes distribuidos con una base de datos compartida centralizada (ej.: cliente
servidor)
 Requerimientos de conversión para datos previamente monitoreados
 Respaldo, control y seguridad de los datos
 Opciones de soporte provistas por el fabricante de la herramienta
 Escalabilidad en el aumento de la capacidad (el número de usuarios, volumen de los
datos y otros)
Se deben considerar los requerimientos exactos para la herramienta. ¿Cuáles son los
requerimientos mandatorios y cuáles son los requerimientos deseables? Generalmente, la
herramienta debe soportar los procesos, no al revés, minimizando la modificación de los
procesos para que encajen con la herramienta.
De ser posible, es mejor comprar una herramienta completamente integrada (aunque no a

expensas de la eficiencia y efectividad) para soportar muchos (si no es que todos) los procesos
de gestión de servicios. Si esto no es posible, se debe considerar realizar interfaces entre las
distintas herramientas.
Es esencial tener una declaración de requerimientos (SoR) para ser usada durante el proceso de
selección- esta declaración puede ser usada como lista de verificación. Los requerimientos de la
herramienta deben ser categorizados usando el análisis MoSCoW
 M – (Must) Debe tener esto

 S – (Should) Debería tener esto de ser posible
 C – (Could) Podría tener esto si no afecta nada más
 W – (Won’t) No tendrá esto ahora, pero me gustaría que lo tuviera en el futuro
La herramienta debe ser suficientemente flexible para soportar los derechos de acceso
requeridos. Se debe poder determinar a quién se le permite el acceso a qué datos y con qué
propósito- por ejemplo, acceso de lectura para clientes.
Selección de la Herramienta
En las etapas iniciales, se debe considerar la plataforma en la cual se espera que opere la
herramienta -esta puede ser hardware y software existente o una nueva compra. Pueden existir
restricciones establecidas por la estrategia de TI- por ejemplo, puede ser que todos los productos
nuevos tengan que residir en servidores específicos. Esto puede restringir qué productos pueden
ser incluidos en el proceso de evaluación. Debe asegurarse de que la compra entre dentro de los
presupuestos existentes aprobados.
Durante las etapas iniciales del proceso de selección, se debe pensar en la credibilidad del
fabricante y la herramienta. ¿Seguirán dando soporte a la compra dentro de algunos meses o
años? Considere el historial del proveedor así como el de la herramienta. Llame al Service Desk
del proveedor para ver qué tan fácil es ponerse en contacto y haga algunas preguntas para
evaluar su competencia técnica. Pida al fabricante que le programe una visita con un cliente de
referencia para ver cuál ha sido su experiencia con la herramienta en la práctica- de ser
70
Tecnología
posible, sin el proveedor o fabricante presente. Asegúrese de que la organización tiene

requerimientos similares de la herramienta. Vea la herramienta en operación y hable con los
usuarios de cuáles han sido sus experiencias, tanto iniciales como actuales.
Determine las necesidades de capacitación de la organización y evalúe la capacidad del

proveedor para proporcionar la capacitación apropiada. También tendrán que ser evaluadas la
capacitación cotidiana y las actualizaciones a la herramienta (cambios de versión y cambios en
los requerimientos de usuarios) para determinar los costos de soporte y capacitación. En
particular, considere los costos de capacitación, instalaciones para capacitación, tiempo
requerido, que tan pronto después de la capacitación se pondrá en uso la herramienta, y durante
el proyecto de implementación asegúrese de que se proporcione suficiente capacitación – piense
en cómo impactará la nueva herramienta tanto a TI como al cliente. También asegúrese de que
las interfaces con otras herramientas y la telefonía estén funcionando correctamente. Es muy
conveniente identificar si la combinación planeada ha sido usada (o intentada) en algún otro
lado y con qué resultados. Considere los periodos corriendo en paralelo junto con las
soluciones existentes antes de finalmente ir en vivo.
Sin embargo, cualquier producto debe ser rechazado y considerado como no adecuado, si no
todos los requerimientos mandatorios (los “debe tener”) son cubiertos. En algunas
circunstancias, será imposible encontrar un producto de software existente que cumpla con
todos los requerimientos mandatorios o coincida en la menos un 80%. En este caso, el producto
que ofrezca el mejor diseño funcional debe ser seleccionado y los elementos no adecuados
recodificados. Dentro de lo posible, este proceso de mejora debe ser realizado por el fabricante.
En ciertos casos, parte de los costos de mejora pueden ser cubiertos por el comprador. Algunos
productos han sido diseñados para incluir puntos de enlace para el usuario- esto proporciona
accesibilidad al código escrito localmente en puntos clave del procedimiento, sin necesidad de
que el paquete sea modificado.
Consideraciones de Implementación
El trabajo no termina cuando el producto ha sido seleccionado. En muchos sentidos, esto podría
ser considerado sólo el comienzo. Ahora se debe implementar la herramienta. Una vez que la
plataforma de hardware ha sido preparada y el software instalado, se debe considerar la
alimentación de los datos. ¿Qué, de dónde, cómo y cuándo? El tiempo es importante para las
pruebas, los procesos de implementación y los procesos de puesta en producción. Los recursos
deben estar disponibles para asegurar que sea exitoso. Es decir, no programe la implementación
durante periodos en los que se sabe que los recursos estarán muy ocupados, tales como en cierre
de fin de año.
También se deben considerar los proveedores de servicios administrados y de servicios de

aplicaciones que pudieran proporcionar la misma funcionalidad.
Proceso y Criterio de Evaluación

Cualquiera que sea la herramienta o tipo de herramienta elegida, el cumplimiento de los
requerimientos puede diferenciarse entre:
71
Tecnología
 Listo para usarse: El requerimiento ya está cumplido

 Configuración: La herramienta puede ser configurada con x número de días de esfuerzo
para cumplir con el requerimiento, esto se conservará a través de las actualizaciones de
versión del producto
 Personalización (customization): La herramienta puede ser reprogramada con x días de
esfuerzo para cumplir con el requerimiento, y esto podría tener que repetirse con cada
actualización de versión del producto
Siempre es preferible evitar la personalización excesiva de cualquier producto debido a los altos
costos incurridos en la actualización de versión. Los fabricantes pueden no estar dispuestos a
soportar versiones anteriores, y los compradores pueden no tener los recursos necesarios para
la re-aplicación de cualquier adecuación hecha a la medida. La personalización también puede
liberar al fabricante de muchas de sus obligaciones de soporte- esto sería desastroso si, como
resultado, su sistema de gestión de servicios no estuviera disponible por un largo periodo de
tiempo. Se incurriría en costos adicionales para proporcionar la capacitación necesaria a la
medida. Sería imposible aprovechar cualquier capacitación programada a precio económico
organizada por el proveedor de software.
Proceso de Evaluación de la Herramienta
¿Qué Requerimientos?
Identificar Productos
Criterio de Selección
Evaluar Productos
Reducir Lista
Evaluar
Calificar Productos Seleccionar Producto
© Crown copyright 2011 Reproducido bajo licencia de la Oficina del Gabinete. Basado en la Figura 7.1 Diseño del Servicio 7.2.4
72
Tecnología
El diagrama anterior muestra el enfoque estándar para identificar los requerimientos antes de
identificar los productos, pero en la práctica puede haber algún elemento de traslape, donde la
exploración de las herramientas en el mercado nos abra los ojos a nuevas opciones que
modifiquen los requerimientos. Estas etapas son abordadas principalmente en la evaluación de
productos de software empaquetado, pero un enfoque similar podría ser usado al evaluar
software hecho a la medida. Genere un SoR claro que identifique los requerimientos del negocio
junto con las características mandatorias y aquellas funcionalidades que serían deseables.
También identifique las políticas y estándares propios a los cuales se debe apegar el producto.
Dichos estándares pueden incluir que corra bajo un sistema de software particular, o sobre un
hardware específico.
Recuerde las consideraciones sobre qué tan adecuado es el proveedor y lleve a cabo una
evaluación formal de los productos que está considerando.
Si se usan herramientas adecuadas y bien desarrolladas para soportar los procesos, los
resultados alcanzados serán mucho mejores y frecuentemente los costos generales de la
provisión del servicio serán menores.
Seleccionar la herramienta adecuada implica prestar atención a varios puntos:
 Que cumpla en un 80% con todos los requerimientos funcionales y técnicos

 Que cumpla todos los requerimientos mandatorios
 Poca (si es que se requiere alguna) personalización del producto requerida
 Apego por parte de la herramienta y del proveedor a las mejores prácticas de gestión de
servicios
 Una estructura y manejo de datos segura
 Integración con otras herramientas de gestión de servicios y de gestión operacional
 Soporte de estándares abiertos e interfaces
 Orientado al negocio, no orientado a la tecnología
 Costos de administración y mantenimiento dentro del presupuesto
 Niveles aceptables de mantenimiento y políticas de liberación
 Seguridad e integridad
 Disponibilidad de capacitación y servicios de consultoría
 Buena generación de reportes
 Escalabilidad y crecimiento
73
Tecnología
Requerimientos Genéricos
Se requiere de una tecnología de ITSM integrada (o conjunto de herramientas, ya que algunos
proveedores venden su tecnología como “módulos” mientras que algunas organizaciones
pueden elegir integrar productos de distintos proveedores) que incluya la siguiente
funcionalidad básica.
Auto-ayuda
Muchas organizaciones encuentran benéfico ofrecer capacidades de auto-ayuda a sus usuarios.
Por lo tanto, la tecnología debe soportar esta capacidad mediante algún tipo de interface de
usuario permitiendo definir páginas web para tener acceso a opciones de auto-ayuda y
solicitudes de servicio a través de menús - con una interface directa a los procesos de back-end
del software.
Flujos de trabajo o Motor de Proceso

Se requiere un flujo de trabajo o motor de control de proceso para permitir la pre-definición y
control de procesos definidos tales como un ciclo de vida de incidentes, el ciclo de vida de
cumplimiento de solicitudes, el ciclo de vida de problemas, el modelo de cambios, etc. Este debe
permitir predefinir responsabilidades, actividades, escalas de tiempo, rutas de escalación y
alertas para después administrarlas automáticamente.
Sistema de Gestión de la Configuración Integrado

Los paquetes de herramientas deben tener un CMS para permitir que los activos de
infraestructura de TI de la organización, sus componentes, servicios y cualquier CI subordinado
(tales como contratos, ubicaciones, licencias, proveedores – cualquier cosa que la organización
74
Tecnología
de TI desee controlar) puedan ser mantenidos, junto con todos los atributos relevantes, en una
ubicación central, y para permitir que las relaciones entre cada uno puedan ser almacenadas y
mantenidas, y ligadas a incidentes, problemas, errores conocidos y registros de cambio según
aplique.
Tecnologías de Descubrimiento/Instalación/Licenciamiento
Para alimentar o verificar los datos del CMS y para ayudar en el manejo de licencias, se
requerirá de herramientas de búsqueda o de auditoría automatizada. Tales herramientas deben
ser capaces de ser ejecutadas desde cualquier ubicación en la red y permitir la búsqueda y
recuperación de información relacionada con todos los componentes que constituyen o están
conectados con la infraestructura de TI.
Dicha tecnología debe permitir “filtrar” para que los datos que se obtengan puedan ser
revisados y aprobados y sólo los datos requeridos sean extraídos. También es muy útil que se
puedan extraer y reportar “sólo los datos que han cambiado” desde la última auditoría
Con frecuencia, la misma tecnología puede ser usada para instalar nuevo software en
localidades destino, este es un requerimiento esencial para todos los equipos o departamentos
de Operación del Servicio, para permitir que parches, software de transporte, etc., sean
distribuidos a los usuarios correctos.
Una interface con las capacidades de “auto-ayuda” es deseable para permitir solicitar
descargas autorizadas de software a través de ella, pero manejadas automáticamente por el
software de instalación.
Las herramientas que permiten la comparación automática de los detalles de las licencias de
software que se poseen (idealmente en el CMS) contra el número real de licencias instaladas-
con el reporte de las discrepancias – son extremadamente deseables.
Control Remoto
Con frecuencia es útil para los analistas del Service Desk y otros grupos de soporte tener la
capacidad de tomar el control del equipo del usuario (bajo las condiciones de seguridad
apropiadamente controladas) para permitirles llevar a cabo investigaciones, corregir
configuraciones, etc. Serán necesarias herramientas que permitan este nivel de control remoto.
Utilidades de Diagnóstico
Podría resultar extremadamente útil para el Service desk y otros grupos de soporte si la
tecnología incorporara la capacidad de crear y usar scripts de diagnóstico y otras utilerías de
diagnóstico (tales como, por ejemplo, herramientas de razonamiento basadas en casos) para
ayudar con el diagnóstico inicial de incidentes. Idealmente, estos deben ser “sensibles al
contexto” y permitir scripts automatizados tanto como sea posible.
Reporte
No tiene sentido alguno almacenar datos a menos de que puedan ser fácilmente recuperados y
utilizados para cumplir con los objetivos de la organización. Por eso, la tecnología debe
incorporar buenas capacidades de reporte, así como permitir interfaces estándar que puedan
75
Tecnología
ser usadas para capturar datos en paquetes para reporte estándar de la industria, tableros de
control, etc. Idealmente, los reportes instantáneos en pantalla, así como los reportes impresos
pueden ser provistos a través del uso de “los diez reportes más relevantes” dependientes del
contexto.
Tableros de control (Dashboards)

La tecnología tipo tableros de control es útil para permitir “en un solo vistazo” visualizar los
niveles generales de desempeño y disponibilidad de los servicios de TI. Estas pantallas pueden
ser incluidas en reportes de nivel gerencial para los usuarios y clientes- pero también pueden
dar información en tiempo real para su inclusión en páginas web de TI para reportar
dinámicamente, y pueden ser usadas para fines de soporte e investigación. Las capacidades
para ofrecer vistas personalizadas de la información con el fin de satisfacer niveles específicos
de interés pueden resultar particularmente útiles.
Sin embargo, a veces representan una vista técnica de la infraestructura más que una del
servicio, en cuyo caso pueden resultar menos interesantes para los clientes y usuarios. Para los
ejecutivos y gerencia de TI, puede ser deseable el uso de un enfoque de balanced scorecard
resumido en una vista de tableros de control como una manera de reportar la calidad y el
desempeño general de TI.
Integración con el Negocio

Para facilitar una mayor alineación con el negocio, las aplicaciones de negocio y las
herramientas deben poder comunicarse con las herramientas de soporte de ITSM para
proporcionar la funcionalidad requerida.
Tecnologías de Software Como un Servicio (SaaS)

Las tecnologías SaaS ofrecen capacidades de gestión de servicios sobre internet. Los beneficios
fundamentales son que se puede implementar una funcionalidad gerencial sin incurrir en gastos
de capital en hardware, software y el trabajo de instalación. Con las tecnologías SaaS los
servicios de administración sólo necesitan ser accesados a través de un navegador web. Los
beneficios clave pueden incluir menores costos de capital y de arranque y una implementación
más rápida de soluciones gerenciales, así como un enfoque prefabricado para manejar la
Continuidad de Servicios de dichas soluciones en caso de una interrupción mayor en el negocio.
Aunque inicialmente resultan atractivas, se debe tener cuidado al considerar posibles

restricciones como:
 El nivel de personalización y los cambios a la funcionalidad que serán permitidos (ej.: si

TI puede usar el esquema que desee para la clasificación de incidentes o se verá forzado
a usar sólo lo que el fabricante permita)
 Si el proveedor de la herramienta proporcionará un ambiente dedicado específico a las
funciones de TI del negocio o utilizará un ambiente compartido que puede limitar el tipo
de adecuaciones a la medida y personalización que pueden realizarse
76
Tecnología
 Las horas de disponibilidad del servicio que puedan ser provistas (ej.: si el proveedor
tiene periodos de tiempo cuando los servicios no están disponibles debido a
mantenimiento)
 Flexibilidad en la actualización de versiones para manejar nueva funcionalidad o nuevas
tecnologías
 Esquemas de licenciamiento que puedan volverse restrictivos o caros desde el punto de
vista del costo total de propiedad
 Límites en el tamaño de almacenamiento para elementos tales como registros de
incidentes e historial o qué tan frecuentemente pueden ser accesados
 Restricciones en la Gestión de Seguridad y Acceso o exposición al riesgo relacionada
con las soluciones de administración que están siendo usadas
 Integración de la solución del fabricante con otras herramientas de gestión de servicios
77
Roles en Operación del Servicio
78
Roles del Service Desk
Rol Responsabilidades Típicas

Gerente del  Asignar personas a los roles requeridos
Service  Gestionar recursos asignados al service desk, incluyendo supervisor(es)
Desk  Gestionar las actividades del service desk
 Actuar como punto de escalación para el (los) supervisor(es)
 Asumir un rol más amplio de cliente de servicios
 Reportar a los gerentes senior sobre cualquier situación que pudiera impactar
significativamente al negocio
 Asistir a las juntas del CAB
 Asumir la responsabilidad general de los incidentes y las solicitudes de servicio
en manos del service desk
 Monitorear y reportar el desempeño del service desk
 Identificar oportunidades de mejora para su inclusión en el registro de CSI
 Trabajar con el gerente de CSI para revisar y priorizar mejoras en el registro
de CSI
 Realizar mejoras al service desk
Supervisor  Asegurar que los niveles de personal asignado y de sus habilidades se
del Service mantengan a lo largo de las horas de operación a través de la administración
Desk de la programación de turnos del personal, etc.
 Llevar a cabo actividades de recursos humanos según sea necesario
 Actuar como punto de escalación cuando se reciban llamadas difíciles o
controversiales.
 Generar estadísticas y reportes gerenciales
 Representar al service desk en las juntas
 Coordinar la capacitación y sesiones de concientización del personal
 Colaborar con la gerencia senior y Gestión de Cambios
 Llevar a cabo sesiones informativas para el personal del service desk sobre los
cambios o implementaciones que puedan afectar los volúmenes del service desk
 Ayudar a los analistas a proporcionar soporte de primer nivel cuando las
cargas de trabajo son elevadas, o cuando se requiere de experiencia adicional
Analista del El rol principal del analista del service desk es el de proporcionar soporte de
Service primer nivel tomando llamadas y manejando los incidentes o solicitudes de
Desk servicio resultantes usando los procesos de reporte de incidentes y Cumplimiento
de Solicitudes, alineado a los objetivos descritos anteriormente. Es bastante
común tener este rol como una combinación entre el rol de analista de primer
nivel y el de analista de Cumplimiento de Solicitudes.
Súper Usuarios del negocio que actúan como puntos de colaboración con TI. Sus
Usuarios responsabilidades normalmente incluyen:
 Facilitar la comunicación entre TI y el negocio a nivel operacional
 Reforzar las expectativas de los usuarios con respecto a los niveles de servicio
que han sido acordados
 Capacitación de personal para los usuarios dentro de su área
 Proporcionar soporte para incidentes menores o cumplimiento de solicitudes
simples
79

 Escalar solicitudes e incidentes al service desk si no se resuelven localmente
 Ayudar al service desk para situaciones cotidianas y problemas según sea
necesario (ej.: registrar el número de ocurrencias de incidentes durante un
periodo específico de tiempo (ej.: durante un turno, etc.) para un problema
recurrente y después hacer una sola llamada al service desk para cubrir todas
las ocurrencias)
 Involucramiento en las nuevas liberaciones e implementaciones
Roles de Gestión de Operaciones de TI

Gerente de  Proporcionar liderazgo general, control y toma de decisiones y asumir la
Operaciones responsabilidad de equipos y departamento de gestión de operaciones de TI
de IT  Reportar a la gerencia senior sobre todas las situaciones de operaciones de TI
 Administrar a todos los gerentes/supervisores de equipo o departamento de
operaciones de TI
Líder de  Asumir la responsabilidad general del liderazgo, control y toma de decisiones
Turno durante la duración del turno.
 Garantizar que las actividades operacionales sean ejecutadas
satisfactoriamente dentro de las escalas de tiempo acordadas según las
políticas y procedimientos de la compañía
 Colaborar con los otros líderes de turno para garantizar la entrega,
continuidad y consistencia entre los turnos
 Actuar como línea de reporte para todos los analistas de operaciones durante
su turno
 Asumir responsabilidad general por la salud, integridad y seguridad del turno
(a menos que se designe específicamente a otros miembros del equipo)
Analista de Los analistas de operaciones de TI son personal experimentado de operaciones
Operaciones de TI capaz de determinar la forma más efectiva y eficiente de conducir una
de TI serie de operaciones, normalmente en ambientes diversos de alto volumen.
Este rol normalmente es desempeñado como parte de la gerencia técnica, pero
en organizaciones grandes puede ser que el volumen y diversidad de las
actividades operacionales requiera de una planeación y ejecución más a fondo.
Algunos ejemplos son generar un calendario de trabajos y la definición de una
estrategia y calendario de respaldos.
Operador de  Desempeñar respaldos y calendarizar trabajos de mantenimiento, ej.:
TI mantenimiento de bases de datos, depuración de archivos, etc.
 Consola de operaciones, ej.: monitoreo del estatus de sistemas específicos,
colas de trabajo, etc., y proporcionar intervención de primer nivel cuando sea
necesario
 Administrar los dispositivos de impresión, recarga de papel, tóner, etc.
 Garantizar que los trabajos batch, de almacenamiento, etc. sean realizados
 Hacer imágenes para la distribución/instalación de nuevos servidores,
equipos de escritorio o portátiles
 Instalación física de equipo estándar en el centro de datos
80
Roles de Gestión Técnica

Gerente  Tomar la responsabilidad general del liderazgo, control y toma de decisiones
Técnico/ del equipo técnico o departamento
Líder de  Proporcionar conocimiento técnico y liderazgo en las áreas específicas
Equipo cubiertas por el equipo o departamento
 Garantizar la capacitación necesaria, que se mantengan los niveles de
concientización y experiencia dentro del equipo o departamento
 Reportar a la gerencia senior sobre todas las situaciones técnicas relevantes a
su área de responsabilidad
 Desempeñar la administración de todos los miembros del equipo o
departamento
Analista/  Trabajar con los usuarios, patrocinadores, gestión de aplicaciones y otros
Arquitecto involucrados para determinar sus necesidades cambiantes
Técnico  Trabajar con gestión de aplicaciones y otras áreas en la gestión técnica para
determinar el nivel más alto de requerimientos del sistema necesario para
cumplir con los requerimientos dentro de las restricciones de presupuesto y
tecnología
 Definir y mantener el conocimiento sobre cómo están relacionados los
sistemas y garantizar que las dependencias sean comprendidas y
administradas de acuerdo a ello.
 Desempeñar análisis costo-beneficio para determinar los medios más
apropiados para cumplir con los requerimientos establecidos.
 Desarrollar modelos operacionales que garantizarán el uso óptimo de los
recursos y el nivel apropiado de desempeño
 Garantizar que la infraestructura sea configurada para ser administrada
efectivamente dada la arquitectura tecnológica de la organización, las
habilidades y herramientas disponibles
 Garantizar el desempeño consistente y confiable de la infraestructura para
entregar los niveles requeridos de servicio para el negocio
 Definir todas las tareas requeridas para gestionar la infraestructura y
garantizar que estas tareas sean desempeñadas adecuadamente
 Proporcionar información para el diseño de datos de configuración requerida
para administrar y dar seguimiento a la infraestructura y las aplicaciones
efectivamente
Operador Este término se usa para referirse a cualquier miembro del personal que
Técnico desempeñe tareas operacionales del día a día en gestión técnica. Normalmente,
estas tareas son delegadas a un equipo dedicado de operaciones de TI y por lo
tanto, este rol se discute en la descripción del rol de operador de TI.
81
Roles de Gestión de Aplicaciones
Roles Responsabilidades Típicas

Gerente de  Asumir la responsabilidad general del liderazgo, control y toma de
Aplicaciones/ decisiones del equipo o departamento de aplicaciones
Líder de  Proporcionar conocimiento técnico y liderazgo en las actividades
Equipo específicas de soporte de aplicaciones cubiertas por el equipo o
departamento
 Garantizar que se mantenga la capacitación técnica, los niveles de
concientización y experiencia dentro del equipo o departamento relevantes a
las aplicaciones que están siendo soportadas y a los procesos que están
siendo usados
 Comunicación cotidiana con los usuarios y clientes con respecto al
desempeño de las aplicaciones y a los requerimientos cambiantes del
negocio
 Reportar a la gerencia senior sobre todas las situaciones relevantes a las
aplicaciones que están siendo soportadas
 Administrar a todos los miembros del equipo o departamento
Analista/  Trabajar con usuarios, patrocinadores y otros involucrados para
Arquitecto de determinar sus necesidades cambiantes
Aplicaciones  Trabajar con la gerencia técnica para determinar el nivel más alto de
requerimientos del sistema necesarios para cubrir los requerimientos del
negocio dentro de las limitantes de presupuesto y tecnología
 Desempeñar el análisis costo beneficio para determinar el medio más
adecuado de cumplir con el requerimiento establecido
 Desarrollar modelos operacionales que garantizarán el uso óptimo de los
recursos y el nivel apropiado de desempeño
 Garantizar que las aplicaciones sean diseñadas para ser administradas
efectivamente dada la arquitectura tecnológica de la organización, las
habilidades y herramientas disponibles
 Desarrollar y mantener estándares para el dimensionamiento, desempeño
y modelado de aplicaciones
 Generar un grupo de requerimientos de pruebas de aceptación, junto con
los diseñadores, ingenieros de pruebas y el usuario, los cuales
determinarán que todos los requerimientos de alto nivel han sido cubiertos
con respecto a la su función y manejabilidad.
 Proporcionar información para el diseño de datos de configuración
requerida para administrar y dar seguimiento a las aplicaciones
efectivamente
82
Dueño del Servicio

El dueño del servicio es responsable final de la entrega de un servicio específico de TI. El dueño
del servicio es responsable ante el cliente de la iniciación, transición y mantenimiento y soporte
cotidiano de un servicio en particular y rinde cuentas ante el director de TI o director de gestión
de servicios sobre la entrega del servicio. La responsabilidad del dueño del servicio sobre un
servicio específico dentro de una organización es independiente de dónde residan los
componentes de tecnología procesos o capacidades profesionales que lo soportan. El dueño del
servicio es responsable de la mejora continua y la gestión de cambios que afecten el servicio a
su cargo. El dueño del servicio es un interesado primario en todos los procesos subyacentes de
TI que habilitan o soportan el servicio del que son dueños.
Dueño del Proceso

El rol de dueño del proceso es responsable de asegurar que un proceso sea adecuado a su
propósito. Este rol frecuentemente es asignado a la misma persona que lleva el rol de gerente de
proceso, pero ambos roles pueden estar separados en una organización más grande. El rol de
dueño del proceso es responsable de garantizar que su proceso sea desempeñado de acuerdo
con el estándar acordado y documentado y de que cumpla con el propósito para el cual se
definió el proceso.
Gerente del Proceso

El rol de gerente del proceso es responsable de la gestión operacional de un proceso. Pueden
existir varios gerentes de proceso para un proceso, por ejemplo, los gerentes de cambio
regionales o gerentes de continuidad del servicio de TI para cada centro de datos. Con
frecuencia, el rol de gerente del proceso es asignado a la persona que lleva a cabo el rol de
dueño del proceso, pero ambos roles pueden estar separados en organizaciones más grandes.
83
Las responsabilidades del gerente del proceso incluyen:
 Trabajar con el dueño del proceso para planear y coordinar todas las actividades del
proceso
 Garantizar que todas las actividades sea llevadas a cabo conforme a lo requerido a
través del ciclo de vida del servicio
 Asignar personas a los roles requeridos
 Administrar los recursos asignados al proceso
 Trabajar con los dueños del servicio y otros gerentes de proceso para garantizar que los
servicios estén funcionando con normalidad
 Monitoreo y reporte del desempeño del proceso
 Identificar las oportunidades de mejora para su inclusión en el registro de CSI
 Trabajar con el gerente de CSI y el dueño del proceso para revisar y priorizar las
mejoras en el registro de CSI
 Efectuar mejoras a la implementación del proceso
Practicante del Proceso

Un practicante del proceso es responsable de llevar a cabo una o más actividades del proceso.
En algunas organizaciones, y para algunos procesos, el rol de practicante del proceso puede
combinarse con el rol de gerente del proceso, en otras puede haber un número mayor de
practicantes llevando a cabo diferentes partes del proceso.
Las responsabilidades del practicante del proceso generalmente incluyen:
 Llevar a cabo una o más actividades de un proceso

 Entender cómo contribuye su rol a la entrega general de un servicio y a la creación de
valor para el negocio
 Trabajar con otros involucrados, tales como su gerente, colegas, usuarios y clientes para
garantizar que sus contribuciones sean efectivas
 Garantizar que las entradas, salidas e interfaces para sus actividades sean correctas
 Crear o actualizar registros para mostrar que las actividades han sido llevadas a cabo
correctamente
84
Gestión de Eventos
85
Gestión de Eventos
Gestión de Eventos es la base del monitoreo y control operacional. Si se programan eventos

para comunicar información operacional así como advertencias y excepciones, pueden ser
usados como base para automatizar muchas actividades de gestión de operaciones rutinarias,
por ejemplo, ejecutar scripts en dispositivos remotos, o enviar trabajos para ser procesados, o
hasta balancear dinámicamente la demanda de un servicio a través de varios dispositivos para
mejorar el desempeño
86
Gestión de Eventos
87
Gestión de Eventos
Alcance
Gestión de Eventos puede aplicarse a cualquier aspecto de la gestión de servicios que necesite
ser controlado y que pueda ser automatizado. Esto incluye:
Elementos de Configuración (CIs):

 Algunos CIS serán incluidos porque necesitan permanecer en un estado constante (ej.:
un switch de una red necesita permanecer prendido y las herramientas de Gestión de
Eventos confirman esto al monitorear las respuestas a los “pings”)

 Algunos CIs serán incluidos porque su estatus necesita cambiar frecuentemente y
Gestión de Eventos puede ser usado para automatizar esto y actualizar el sistema de
gestión de la configuración (CMS) (ej.: la actualización de un servidor de archivos)
 Condiciones ambientales (ej.: detección de humo y fuego)
 Monitoreo del uso de licencias de software para garantizar la utilización óptima/legal y
su ubicación
 Seguridad (ej.: detección de intrusos)
 Actividad normal (ej.: rastreo del uso de una aplicación o el desempeño de un servidor)
La Diferencia Entre Monitoreo y Gestión de Eventos

Monitoreo y Gestión de Eventos están íntimamente relacionados, pero son ligeramente
diferentes en su naturaleza. Gestión de Eventos se enfoca en generar y detectar notificaciones
significativas sobre el estatus de la infraestructura y los servicios de TI.
Si bien es cierto que el monitoreo es requerido para detectar y rastrear estas notificaciones, el
monitoreo es más amplio que Gestión de Eventos. Por ejemplo, las herramientas de monitoreo
verificarán el estatus de un dispositivo para garantizar que esté operando dentro de los límites
aceptables, aún si ese dispositivo no está generando eventos.
Para ponerlo más simple, Gestión de Eventos trabaja con las ocurrencias que son
específicamente generadas para ser monitoreadas. Monitoreo rastrea estas ocurrencias, pero
también buscará activamente condiciones que no generan eventos.
Valor para el Negocio

El valor de Gestión de Eventos para el negocio generalmente es indirecto; sin embargo, es
posible determinar las bases de su valor como sigue:
Gestión de Eventos proporciona mecanismos para la detección temprana de incidentes. Gestión

de Eventos hace posible que algunos tipos de actividad automatizada sean monitoreados por
excepción.
Cuando se integra con otros procesos de gestión de servicios (tales como por ejemplo
disponibilidad o Gestión de la Capacidad) Gestión de Eventos puede mostrar cambios de estatus
o excepciones que permitan a la persona o equipo apropiado llevar a cabo una respuesta
temprana, mejorando así el desempeño del proceso. Gestión de Eventos proporciona una base
para las operaciones automatizadas, aumentando así la eficiencia y permitiendo que los
recursos humanos costosos sean empleados en trabajos más innovadores, tales como el diseño
88
Gestión de Eventos
de nueva funcionalidad mejorada o definir nuevas formas en las cuales el negocio pueda
explotar la tecnología para aumentar su ventaja competitiva.
Algunos ejemplos de políticas de Gestión de Eventos podrían incluir:
 La notificación de eventos sólo debe dirigirse a aquellos responsables de manejar las

acciones adicionales o decisiones relacionadas con ellos. Esto evita las notificaciones
innecesarias a aquellos no involucrados directamente en el procesamiento de eventos. La
Gestión de Eventos y el soporte deben ser centralizados tanto como sea razonablemente
posible. Esto evita conflictos en el manejo de los eventos. Soporta una respuesta
operacional apropiada consistente para los nuevos eventos y los cambios que pudieran
ocurrir en las acciones de manejo de eventos.
 Todos los eventos de aplicaciones deben utilizar un conjunto común de estándares y

protocolos de mensajería y registro cuando sea posible. Esto permite un manejo
consistente de eventos. Las acciones de manejo de eventos deben ser automatizadas
cuando sea posible. Esto elimina incidentes potenciales que pudieran ser causados por el
error humano. Debe establecerse un esquema de clasificación estándar que haga
referencia a los procesos comunes de manejo y escalación. Esto apoya un enfoque
consistente para tomar acciones sobre los eventos en forma que se soporten los objetivos
operacionales y de nivel de servicio. Todos los eventos reconocidos deben ser capturados
y registrados en la bitácora. Esto proporcionará un medio para examinar los incidentes,
problemas y tendencias después de que los eventos han ocurrido.
89
Gestión de Eventos
Tipos de Eventos
 Eventos Informativos
o Una carga de trabajo programad ha sido completada
o Un usuario se ha conectado para usar una aplicación
o Un correo electrónico ha llegado a su receptor destinado
 Eventos de Advertencia
o La utilización de la memoria de un servidor está llegando dentro del 5% de su nivel
más alto de desempeño aceptable
o El tiempo para que se complete una tarea es 10% mayor de lo normal
o Los eventos de advertencia significan una operación inusual, pero no excepcional.
Estos indican que una situación puede requerir de un monitoreo más cercano. En
algunos casos, la condición se resolverá por sí misma, por ejemplo en caso de una
combinación inusual de cargas de trabajo – conforme sean completadas, la
operación normal se restablecerá. En otros casos, puede que sea necesaria la
intervención del operador si la situación se repite o si continúa por demasiado
tiempo. Estas reglas o políticas son definidas en los objetivos de monitoreo y control
para ese dispositivo o servicio.
 Eventos de Excepción
o Un usuario intenta conectarse a una aplicación con la contraseña incorrecta
o Una situación inusual ha ocurrido en un proceso de negocio que puede indicar una
excepción que requiera mayor investigación del negocio (ej.: una alerta de una
página web indica que un sitio de autorización de pago no está disponible –
impactando la aprobación financiera de transacciones de negocio)
90
Gestión de Eventos
o El CPU de un dispositivo está por arriba de su tasa de utilización aceptable

o El escaneo de una PC revela la instalación de software no autorizado
Filtración de Eventos
Uno de los principios más importante de Gestión de Eventos es alcanzar el nivel correcto de
filtración para enfocar las acciones de gestión y control en aquellos eventos que sean
significativos. Esto puede volverse complicado por el hecho de que la relevancia de los eventos
cambia. Por ejemplo, un usuario que accesa hoy a un sistema es normal, pero si ese usuario
deja la organización y trata de conectarse es una violación de seguridad.
Uso de Conjuntos de Reglas de Eventos y Motores de Correlación

Un conjunto de reglas consiste en varias reglas que definen como serán procesados y evaluados
los mensajes de eventos para un evento en particular. Por ejemplo, un evento de advertencia
puede ser generado cada vez que el archivo de registro de la bitácora de un disco alcanza su
capacidad máxima, pero un evento de excepción será generado si más de cuatro eventos de
advertencia han sido generados. Normalmente, las reglas mismas están embebidas en
tecnologías de monitoreo y manejo de eventos. Consisten en algoritmos de tipo Booleano para
correlacionar eventos que han sido generados para crear eventos adicionales que necesitan ser
comunicados. Estos algoritmos pueden ser codificados en software de Gestión de Eventos,
normalmente conocidos como motores de correlación.
91
Gestión de Eventos
La Gestión de Eventos efectiva no está diseñada una vez que un servicio ha sido liberado a
operaciones. Debido a que Gestión de Eventos es la base para monitorear el desempeño y la
disponibilidad de un servicio, los objetivos y mecanismos exactos para monitorear deben ser
especificados y acordados durante los procesos de disponibilidad y Gestión de Capacidad. Los
mecanismos de pruebas y evaluación del evento diseñado deben ser incluidos con las
actividades llevadas a cabo durante la Transición del Servicio.
Consideraciones Clave
 ¿Qué necesita ser monitoreado?
 ¿Qué tipo de monitoreo se requiere (ej.: activo o pasivo; desempeño o salida)?
 ¿Cuándo necesitamos generar un evento?
 ¿Qué tipo de información necesita ser comunicada en el evento?
 ¿A quién están destinados los mensajes?
 ¿Quién será responsable de reconocer, comunicar, escalar y tomar acciones en los
eventos?
Instrumentación
Instrumentación es la definición de lo que puede ser monitoreado con respecto a los CIs y la
forma en que su comportamiento puede ser afectado. En otras palabras, instrumentación se
trata de definir y diseñar exactamente cómo monitorear y controlar la infraestructura y los
servicios de TI.
Mensajes de Error
Los mensajes de error son importantes para todos los componentes (hardware, software, redes,
etc.,) Es particularmente importante que todas las aplicaciones de software estén diseñadas para
92
Gestión de Eventos
soportar la Gestión de Eventos. Esto podría incluir proporcionar mensajes de error

significativos y/o códigos que puedan indicar con claridad el punto específico de falla y la causa
más probable. En tal caso, las pruebas de nuevas aplicaciones deben incluir pruebas de
generación de eventos precisos.
Detección de Eventos y Mecanismos de Alerta

Un buen diseño de Gestión de Eventos también incluye el diseño y alimentación de las
herramientas usadas para filtrar, correlacionar y escalar eventos. Específicamente, el motor de
correlación necesitará ser alimentado con las reglas y criterios que determinarán la relevancia
y acción subsecuente de cada tipo de evento.
A través del diseño de la detección de eventos y los mecanismos de alerta se requiere lo

siguiente:
 Conocimiento del negocio en relación con cualquier proceso de negocio que sea
manejado a través de Gestión de Eventos
 Conocimiento detallado de los requerimientos de nivel de servicio del servicio que está
siendo soportado por cada CI
 Conocimiento de lo que constituye la operación normal y anormal del CI
 Conocimiento de la relevancia de múltiples eventos similares (en el mismo CI o varios
CIs similares)
 Entendimiento de lo que necesitan saber para soportar efectivamente al CI
 Información que pueda ayudar en el diagnóstico de problemas con el CI
 Estar familiarizado con la priorización de incidentes y los códigos de categorización
para que si se requiere crear un registro de incidente, estos códigos puedan ser provistos
 Conocimiento de los CIs que pueden ser dependientes del CI afectado, o aquellos CIs de
los que éste depende.
 Disponibilidad de información de errores conocidos de los fabricantes o de
experiencias previas
93
Gestión de Eventos
Ocurre un Notificación de evento

evento Actividades de Gestión de
Eventos
Detección de evento
Evento registrado
Correlación y
filtración de evento
de primer nivel
Informativo Excepción
¿Es significativo?
Advertencia
Correlación de evento
de segundo nivel
¿Acción
No
subsecuente
requerida?
Sí
Selección de
respuesta
Auto respuesta Alerta

Incidente/
Problema/
Incidente Cambio Cambio
Problema
Intervención Gestión de Gestión de Gestión de
humana incidentes Problemas Cambios
Sí Cumplimiento
¿Solicitar
acción? de Solicitudes
No
Revisar
acciones
No
¿Efectiva?
Sí
Cerrar evento © Crown copyright 2011 Reproduced

Fin under license from the Cabinet Office
Figure 4.2 Service Operation 4.1.5
94
Gestión de Eventos
Ocurre el Evento
Los eventos ocurren continuamente, pero no todos son detectados o registrados. Por eso es
importante que todos los involucrados en el diseño, desarrollo, gestión y soporte de los servicios
y la infraestructura de TI sobre la que corren entiendan los tipos de eventos que necesitan ser
detectados.
Notificación del Evento

La mayoría de los CIs están diseñados para comunicar cierta información sobre sí mismos en
alguna de estas dos formas:
 Un dispositivo es interrogado por la herramienta de gestión, que recopila cierta
información específica. Generalmente, esto se conoce como “polling” o sondeo del
estatus
 El CI genera una notificación cuando ciertas condiciones se cumplen. La capacidad para
generar estas notificaciones tiene que ser diseñada y construida dentro del CI, por
ejemplo una rutina de programación (hook) insertada en una aplicación
Detección del Evento

Una vez que la notificación del evento ha sido generada, será detectada por un agente corriendo
en el mismo sistema, o transmitida directamente a una herramienta de gestión diseñada
específicamente para leer e interpretar el significado del evento.
Registro del Evento

Debe existir un registro del evento y cualesquiera acciones subsecuentes. El evento puede ser
capturado como un registro de evento en la herramienta de Gestión de Eventos o simplemente
puede ser dejada como una entrada en el log del sistema del dispositivo o aplicación que generó
el evento. Si este es el caso, a pesar de esto, necesita haber una orden levantada para el
personal apropiado de gestión de operaciones para verificar los logs con regularidad e
instrucciones claras sobre cómo usar cada log. También debe recordarse que la información del
evento en los logs puede no ser significativa hasta que ocurra un incidente; y donde el personal
de Gestión Técnica use los logs para investigar dónde se originó el incidente. Esto significa que
los procedimientos de Gestión de Eventos para cada sistema o equipo necesitan definir
estándares de cuánto tiempo se deben conservar los eventos en los logs antes de ser archivados
y borrados.
Correlación y Filtración de Evento de primer nivel

El propósito de la correlación y filtración de eventos de primer nivel es decidir si comunicar el
evento a la herramienta de gestión o ignorarlo. Si se ignora, el evento normalmente será
registrado en el archivo de log del dispositivo, pero no se tomará una acción subsecuente.
Relevancia del Evento

Cada organización tendrá su propia categorización de la relevancia de un evento, pero se
sugiere que al menos estas tres categorías generales estén representadas.
 Informativo
 Advertencia
 Excepción
95
Gestión de Eventos
Correlación de Evento de segundo nivel

Si un evento es una advertencia, se tiene que tomar una decisión sobre exactamente cuál es la
relevancia y qué acciones necesitan tomarse para enfrentarlo. Es aquí donde se determina el
significado del evento. Esta correlación es normalmente hecha por un “motor de correlación”
generalmente es parte de una herramienta de gestión que compara el evento con un conjunto de
criterios y reglas en un orden prescrito.
¿Acción subsecuente requerida?

Si la actividad de correlación de segundo nivel reconoce un evento, se requerirá una respuesta.
Pueden existir muchos diferentes tipos de respuestas, cada una diseñada específicamente para la
tarea que tiene que iniciar.
Algunos ejemplos incluyen:
 Generar un registro en el sistema de Gestión de Incidentes, iniciando así el proceso de
Gestión de Incidentes
 Generar un RFC, iniciando así el proceso de Gestión de Cambios
 Un RFC autorizado que ha sido implementado pero que causó el evento, o un cambio no
autorizado que ha sido detectado – en cualquiera de estos casos esto será referido a
Gestión de Cambios para su investigación
 Los scripts que ejecutan acciones específicas, tales como someter trabajos batch o
reiniciar un dispositivo
 Sistemas de envío de mensajes que notificarán a la persona o equipo sobre el evento a
través de teléfono celular
 Acciones de base de datos que restringen el acceso de un usuario a registros o campos
específicos, o que creen o borren entradas en la base de datos
Selección de Respuesta
En este punto del proceso, hay varias opciones de respuestas disponibles. Es importante notar
que las opciones de respuesta pueden ser elegidas en cualquier combinación. Por ejemplo,
puede ser necesario preservar la entrada del log para futura referencia, pero al mismo tiempo
escalar el evento a un miembro del equipo de gestión de operaciones para su acción.
Algunos eventos son entendidos los suficientemente bien como para que la respuesta apropiada
ya haya sido bien definida y automatizada. Normalmente esto es resultado de un buen diseño o
una experiencia previa (normalmente Gestión de Problemas). Esta respuesta iniciará la acción y
después evaluará si fue completada exitosamente. Si no, un registro de incidente o problema
será creado. Algunos ejemplos de auto respuestas incluyen:
 Reiniciar un dispositivo
 Reiniciar un servicio
 Someter un trabajo a un proceso batch
 Cambiar un parámetro a un dispositivo
 Bloquear un dispositivo o una aplicación para protegerlo contra acceso no autorizado
Alerta e Intervención Humana

Si un evento requiere de intervención humana, necesitará ser escalado. El propósito de la alerta
es asegurar que la persona con las habilidades apropiadas para enfrentar el evento sea
96
Gestión de Eventos
notificada. La alerta contendrá toda la información necesaria para que esa persona pueda
determinar la acción apropiada- incluyendo referencia a cualquier documentación requerida
(ej.: manuales de usuario). Es importante resaltar que esto no es necesariamente lo mismo que
la escalación funcional de un incidente, donde el énfasis está en restaurar el servicio dentro del
tiempo acordado (que puede requerir de varias actividades). La alerta requiere que una
persona, o equipo desempeñe una acción específica, posiblemente en un dispositivo específico y
posiblemente a una hora específica, ej.: cambiar un cartucho de tóner en una impresora cuando
el nivel está bajo.
¿Incidente, Problema o Cambio?

Algunos eventos representarán una situación donde la respuesta apropiada necesitará ser
manejada a través de los procesos de gestión de incidentes, problemas o cambios. Estos son
discutidos más adelante, pero es importante hacer notar que un solo evento puede iniciar alguno
o una combinación de estos tres procesos- por ejemplo, una falla severa no-crítica es registrada
como un incidente, pero como la causa subyacente no se conoce, se crea un registro de
problema para determinar la causa raíz y la resolución y un RFC es registrado para reubicar la
carga de trabajo en un servidor alternativo mientras el problema es resuelto.
Abrir una Solicitud de Cambio (RFC)

Existen dos lugares en el proceso de Gestión de Eventos donde una RFC puede ser creada:
 Cuando ocurre una excepción, por ejemplo, un escaneo de un segmento de la red revela
que dos nuevos dispositivos han sido agregados sin la autorización necesaria. Una forma
de enfrentar esta situación es abrir una RFC, que puede ser usada como vehículo para el
proceso de Gestión de Cambios para manejar la excepción (como alternativa al enfoque
más convencional de abrir un incidente que podría ser enrutado a través del Service
Desk a Gestión de Cambios). Aquí es adecuado hacer una investigación por parte de
Gestión de Cambios debido a que cambios no autorizados implican que el proceso de
Gestión de Cambios no fue efectivo.
 Correlación identifica que un cambio es necesario, en este caso la actividad de
correlación del evento determina que la respuesta apropiada a un evento es que algo sea
cambiado. Por ejemplo, un umbral de desempeño ha sido alcanzado y un parámetro de
un servidor principal necesita ser ajustado. ¿Cómo determina esto la actividad de
correlación? Fue programada para hacer eso ya sea en el proceso de Diseño del
Servicio o porque esto ha sucedido antes y Gestión de Problemas o gestión de
operaciones actualizó el motor de correlación para tomar esta acción.
Abrir un Registro de Incidente

Al igual que con una RFC, un incidente puede ser generado inmediatamente cuando una
excepción es detectada, o cuando el motor de correlación determina que un tipo específico o
combinación de eventos constituyen un incidente. Cuando un registro de incidente es abierto, se
debe incluir tanta información como sea posible- con ligas hacia los eventos concernientes y si
es posible un script completo de diagnóstico.
Abrir o Ligar a un Registro de Problema
97
Gestión de Eventos
Es raro que un registro de problema sea abierto sin incidentes relacionados (por ejemplo, como
resultado del análisis de una falla de servicio o una evaluación de madurez, o debido a un
elevado número de errores de reintentos de red, aun cuando todavía no ha ocurrido una falla).
En la mayoría de los casos estos pasos se refieren a ligar un incidente con un registro de
problema existente. Esto ayudará a los equipos de Gestión de Problemas a reevaluar la
severidad e impacto de un problema, y puede resultar en un cambio de prioridad a un problema
sin resolver. Las tecnologías de Gestión de Eventos también pueden ser usadas para evaluar el
impacto de los incidentes y levantar registros de problemas automáticamente, para permitir que
el análisis de causa raíz comience inmediatamente.
Tipos Especiales de Incidentes

En algunos casos, un evento indicará una excepción que no tiene un impacto directo en un
servicio de TI; por ejemplo, una unidad de aire acondicionado redundante falla, o hay una
entrada no autorizada a un centro de datos. Los lineamientos para estos eventos son los
siguientes:
 Un incidente debe ser registrado usando un modelo de incidente que sea apropiado para
ese tipo de excepción, ej.: un incidente de operaciones o incidente de seguridad. El
incidente debe ser escalado al grupo que gestiona ese tipo de incidente
 Como no hay caída del sistema, el modelo de incidentes usado debe reflejar que fue una
situación operacional más que una situación de servicio. Las estadísticas normalmente
no serían reportadas a los clientes o usuarios, a menos que puedan ser usadas para
demostrar que el dinero invertido en la redundancia fue una buena inversión.
 Los incidentes no deben ser usados para calcular el tiempo sin servicio, y de hecho
pueden ser usados para demostrar que tan proactivo fue TI en para tener los servicios
disponibles.
Revisar Acciones
Con miles de eventos siendo generados cada día, no es posible revisar formalmente cada evento
de manera individual. Sin embargo, es importante verificar que cualquier evento significativo o
excepciones hayan sido manejados apropiadamente, o dar seguimiento a las tendencias o
contabilizar los tipos de eventos, etc. En muchos casos, esto puede hacerse automáticamente,
por ejemplo sondeando un servidor que había sido reiniciado usando un script automatizado
para ver que esté funcionando correctamente.
En casos donde los eventos han iniciado un incidente, problema y/o cambio, la revisión de la
acción no debe duplicar cualquier revisión que pudo haber sido hecha como parte de esos
procesos. Más bien, la intención es garantizar que la entrega entre el proceso de Gestión de
Eventos y otros procesos tuvo lugar conforme a lo diseñado y que la acción esperada
efectivamente sí ocurrió. Esto garantizará que los incidentes, problemas o cambios originados
dentro de gestión de operaciones no se pierdan entre los equipos o departamentos.
La revisión también será usada como entrada en mejora continua y en la evaluación y auditoría
del proceso de Gestión de Eventos.
98
Gestión de Eventos
Cerrar Evento
Algunos eventos permanecerán abiertos hasta que ciertas acciones ocurran, por ejemplo, un
evento que está ligado a un incidente abierto. Sin embargo, la mayoría de los eventos no están
“abiertos o cerrados”. Los eventos informativos simplemente son registrados y posteriormente
utilizados como entrada a otros procesos, tales como gestión de respaldos y almacenamiento.
Los eventos de auto respuesta normalmente son cerrados por la generación de un segundo
evento.
Algunas veces resulta muy difícil relacionar eventos abiertos y cerrados si están en diferentes
formatos. Se sugiere que los dispositivos en la infraestructura generen estos eventos en el mismo
formato y especifiquen el cambio de estatus. Esto permite al paso de correlación en el proceso
relacionar fácilmente las notificaciones abiertas y cerradas.
En el caso de eventos que generan incidentes, problemas o cambios, estos deben ser
formalmente cerrados con una liga hacia el registro apropiado del otro proceso.
99
Gestión de Eventos
Disparadores
Gestión de Eventos puede ser iniciado por cualquier tipo de cambio en el estado. La clave es
definir cuál de estos cambios de estado necesita que se actúe en respuesta. Como ejemplos de
detonadores podríamos incluir:
 Excepciones a cualquier nivel de desempeño de un CI definido en las especificaciones de
diseño, OLAs o SOPs
 Excepciones a un procedimiento automatizado o proceso, ej.: un cambio en una rutina
que ha sido asignado a un equipo de desarrollo no ha sido completado a tiempo
 Una excepción dentro de un proceso de negocio que está siendo monitoreado por
Gestión de Eventos
 La culminación de una tarea o trabajo automatizado
 Un cambio de estatus en un CI como un servidor o una base de datos
 Acceso a una aplicación o base de datos por un usuario o procedimiento o trabajo
automatizado
 Una situación donde un dispositivo, base de datos, o aplicación, etc., ha alcanzado un
umbral predefinido de desempeño.
Entradas
Las entradas al proceso de Gestión de Eventos vendrán principalmente de Diseño del Servicio y
Transición del Servicio. Algunos ejemplos de esto pueden incluir:
 Requerimientos operacionales y de niveles de servicio asociados con eventos y sus
acciones
 Alarmas, alertas y umbrales para el reconocimiento de eventos
100
Gestión de Eventos
 Tablas de correlación de eventos, reglas, códigos de evento y soluciones de respuesta

automatizadas que soportarán actividades de Gestión de Eventos
 Roles y responsabilidades para reconocer eventos y comunicarlos a aquellos que lo
necesitan para manejarlos
Salidas
Algunos ejemplos de salidas de Gestión de Eventos pueden incluir:
 Eventos que han sido comunicados y escalados a aquellos responsables de una acción
subsecuente
 Logs de eventos que describen qué eventos ocurrieron y cualquier actividad de
escalación y comunicación llevada a cabo para soportar el análisis, diagnóstico
actividades adicionales de CSI
 Eventos que indican que ha ocurrido un incidente
 Eventos que indican la violación potencial de un objetivo de SLA u OLA
 Eventos y alertas que indican el estatus de terminación de una actividad de
implementación, operacional u otra actividad de soporte
 Alimentar el SKMS con información e historia de eventos
101
Gestión de Eventos
La información clave involucrada en la Gestión de Eventos incluye la siguiente:

 Mensajes, tales como mensajes SNMP que son una forma estándar de comunicar
información técnica sobre el estatus de los componentes de una infraestructura de TI
 Bases de datos, tales como bases de información de gestión de dispositivos de TI que
contienen información sobre ese dispositivo, incluyendo su sistema operativo, versión del
sistema básico de entrada/salida (BIOS), configuración de los parámetros del sistema,
etc. La capacidad de interrogar estas bases de datos y compararlas contra una norma es
vital para ser capaz de generar eventos
 Software del fabricante con herramientas de monitoreo
 Motores de correlación que contienen reglas detalladas para determinar la relevancia y
respuesta apropiada a los eventos
No existe un registro de eventos estándar para todos los tipos de evento. El contenido exacto y
formato del registro dependerá de las herramientas que sean usadas, lo que esté siendo
monitoreado (ej.: un servidor y las herramientas de Gestión de Cambios tendrán datos muy
diferentes y probablemente utilizarán un formato diferente). Sin embargo, hay algunos datos
clave que normalmente se requiere de cada evento que serán útiles en el análisis. Normalmente
debe incluir:
 Dispositivo
 Componente
 Tipo de falla
 Fecha/hora
 Parámetros de excepción
102
Gestión de Eventos
 Identificador única para permitir el rastreo del evento a través de la infraestructura de

Gestión de Eventos y su correlación en los otros procesos de ITSM como Incidentes,
Problemas y Cambios
 Valor
Demostrar el valor de los procesos de gestión de servicios requiere el establecimiento de un

enfoque de medición para determinar la eficiencia y efectividad de los procesos. Los indicadores
clave de desempeño soportan las reglas para los procesos, mientras que las mediciones soportan
los KPIs.
Tenga en mente lo siguiente:

 Las mediciones son establecidas para mejorar los servicios y su rendición de cuentas
 Identificar los procesos de gestión de servicios que soportan los objetivos de los procesos
críticos de negocio
 Presentar una perspectiva precisa y balanceada al incluir KPIs de distintas categorías:
cumplimiento, calidad, desempeño y valor
103
Gestión de Eventos
Valor del KPI para Gestión de Eventos: Reducción del Tiempo promedio de
Reparación (MTTR)
¿CÓMO PUEDE CONTRIBUIR GESTIÓN DE EVENTOS A LA

REDUCCIÓN EN MTTR DE UN SERVICIO?
El valor de las métricas está en su capacidad de proporcionar fundamentos basados en los

hechos para definir:
 Retroalimentación estratégica para mostrar el estatus presente de la organización desde

muchas perspectivas para los tomadores de decisiones
 Retroalimentación de diagnóstico en varios servicios y procesos para guiar las mejoras
en bases continuas
 Tendencias en el desempeño a través del tiempo conforme se van rastreando las métricas
 Retroalimentación sobre los métodos de medición en sí mismos y cuáles métricas deben
ser rastreadas
 Entradas cuantitativas para métodos y modelos de pronóstico para los sistemas de
soporte a las decisiones
Generación de Reportes
Un enfoque ideal para construir un marco de reporte del servicio enfocado en el negocio es
tomarse el tiempo para definir y acordar la política y las reglas con el negocio y Diseño del
Servicio sobre cómo se implementará y manejará la generación de reportes. Esto incluye:
 Audiencia(s) objetivo y las vistas de negocio relacionadas basadas en lo que es el

servicio entregado
 Acuerdo sobre qué medir y reportar
 Definiciones acordadas de todos los términos y límites
 Bases de todos los cálculos
 Calendario de reportes
 Acceso a los reportes y medios a utilizar
 Juntas programadas para revisar y discutir los reportes
104
Gestión de Eventos
Una Nota en Relación a los CSFs y KPIs:

Cada organización debe identificar los CSF apropiados con base en sus objetivos para el
proceso. Cada muestra de CSF está seguida de un pequeño número de KPIs típicos que soportan
el CSF. Estos KPIs no deben ser adoptados sin una cuidadosa consideración. Cada
organización debe desarrollar KPIs que sean apropiados para su nivel de madurez, sus CSF y
sus circunstancias particulares. Lo alcanzado comparado contra los KPIs debe ser monitoreado
y usado para identificar las oportunidades de mejora, que deben ser registradas en el registro de
mejora continua del servicio (CSI) para su evaluación y posible implementación.
105
Gestión de Eventos
Muestra de Factores Críticos de Éxito e Indicadores Clave de Desempeño
Factores Críticos de Éxito Indicadores Clave de Desempeño

Detectar todos los cambios de estado  Número e índice de eventos comparados con el número de
que han tenido relevancia para los incidentes
CIs y los servicios administrados  Número y porcentaje de cada tipo de evento por
plataforma o aplicación contra el número total de
plataformas y aplicaciones que soportan los servicios de TI
en operación (buscando identificar los servicios de TI que
puedan estar en riesgo por la falta de capacidad para
detectar sus eventos)
Garantizar que todos los eventos  Número y porcentaje de eventos que requirieron
sean comunicados a las funciones intervención humana y si esta se llevó a cabo
apropiadas que necesitan estar  Número de incidentes que ocurrieron y porcentaje de estos
informadas o tomar acciones de que fueron disparados sin un evento correspondiente
control adicionales
Proporcionar el detonador, o punto  Número y porcentaje de eventos que requirieron
de entrada, para la ejecución de intervención humana y si esta se llevó a cabo
muchos procesos de Operación del 
Servicio y actividades de gestión de
operaciones
Proporcionar los medios para  Número y porcentaje de incidentes que fueron resueltos sin
comparar el desempeño operativo impacto en el negocio (indica la efectividad general del
actual y el comportamiento contra proceso de Gestión de Eventos y las soluciones de soporte)
los estándares de diseño y SLAs  Número y porcentaje de eventos que resultaron en
incidentes o cambios
 Número y porcentaje de eventos causados por problemas
existentes o errores conocidos (esto puede resultar en un
cambio a la prioridad del trabajo en ese problema o error
conocido)
 Número y porcentaje de eventos indicando situaciones de
desempeño (por ejemplo, crecimiento en el número de veces
que una aplicación excedió su umbral de transacciones en los
últimos seis meses)
 Número y porcentaje de eventos indicando situaciones
potenciales de disponibilidad (ej.: caídas de dispositivos
alternativos, o swapping de carga de trabajo excesivo)
Proporcionar bases para el  Número y porcentaje de eventos repetidos o duplicados
aseguramiento del servicio, reporte y (esto ayudará a ajustar el motor de correlación para eliminar
mejora del servicio la generación innecesaria de eventos y también puede ser
usado para ayudar en el diseño de una mejor funcionalidad
de generación de eventos para los nuevos servicios)
 Número de eventos/alertas generados sin una degradación
real del servicio/funcionalidad (falsos positivos – indicación
de la precisión de los parámetros de instrumentación,
importante para CSI)
106
Gestión de Eventos
Gestión de Eventos puede hacer interface con cualquier proceso que requiera del monitoreo y
control, especialmente aquellos que no requieren de un monitoreo en tiempo real pero que sí
requieren de algún tipo de intervención después de un evento o grupo de eventos. A continuación
se listan ejemplos de interfaces con otros procesos para cada etapa del ciclo de vida.
Diseño del Servicio

 Gestión de Niveles de Servicio – Gestión de Eventos puede jugar un papel importante
en asegurar que el impacto potencial en un SLA sea detectado oportunamente y que
cualquier falla sea rectificada tan pronto como sea posible para que el impacto en los
objetivos de servicio sea minimizado.
 Gestión de Continuidad del Servicio de TI– Interface con las aplicaciones del negocio
y/o procesos del negocio para permitir que los eventos potencialmente relevantes del
negocio sean detectados y se actúe ante ellos (ej.: una aplicación de negocios reporta
una actividad inusual en la cuenta de un cliente que puede indicar algún tipo de fraude o
violación de seguridad)
 Gestión de Capacidad y Disponibilidad – Estos procesos son críticos para definir qué
eventos son relevantes, cuáles deben ser los umbrales apropiados y cómo responder a
ellos. A cambio, Gestión de Eventos mejorará el desempeño y disponibilidad de los
servicios al responder a los eventos cuando ellos ocurran y al reportar sobre los eventos
reales y patrones de eventos para determinar (comparándolos con los objetivos del SLA
y los Indicadores clave de desempeño (KPIs)) si existe algún aspecto del diseño de la
infraestructura o de la operación que pueda ser mejorado.
107
Gestión de Eventos
Transición del Servicio

 Gestión de Activos y Configuración del Servicio– Este proceso puede usar eventos
para determinar el estado actual de cualquier CI en la infraestructura. Comparar los
eventos con sus líneas bases autorizadas en el CMS ayudará a determinar si está
ocurriendo una actividad de cambio no autorizada en la organización. Además, este
proceso puede usar a Gestión de Eventos para determinar el estatus del ciclo de vida de
los activos.
 Gestión del Conocimiento – Los eventos pueden ser una rica fuente de información que
puede ser procesada para su inclusión en los sistemas de Gestión de Conocimiento. Por
ejemplo, los patrones de desempeño pueden ser correlacionados con la actividad del
negocio y ser usados como entrada en decisiones futuras de diseño y de estrategia
 Gestión de Cambios – Tiene interfaces con Gestión de Cambios para identificar las
condiciones que pueden requerir una acción o respuesta
Operación del Servicio

 Gestión de Incidentes y Problemas – Tiene interfaces con las actividades para resolver
incidentes y problemas para identificar las condiciones que pueden requerir una acción
o respuesta
 Gestión de Accesos – Los eventos se pueden usar para detectar intentos no autorizados
de acceso y violaciones de seguridad.
Mejora Continua del Servicio

 A través de monitorear automáticamente los eventos y generar alertas, algunas de las
cuales pueden requerir actividades de CSI para corregirse
 Identificando situaciones y condiciones anormales, lo que ayuda a predecir y prevenir
situaciones y condiciones, evitando así posibles fallas de servicio y de los componentes
 Utilizando el formato acordado de reporte
 Analizando la precisión de los datos procesados
108
Gestión de Eventos
 Interfaz abierta que corra en ambientes múltiples para permitir monitorear y alertar
servicios heterogéneos y la totalidad de la infraestructura de TI de una organización
 Fácil de implementar, con costos mínimos de instalación
 Agentes “estándar” para monitorear los ambientes/componentes/sistemas más comunes
 Interfaces abiertas para aceptar cualquier entrada de evento estándar (ej.: SNMP) y la
generación de varias alertas
 Canalización centralizada de todos los eventos hacia una sola ubicación, que pueda
programarse para aceptar diferentes ubicaciones en varios momentos
 Funcionalidad configurable y programable para correlacionar eventos
similares/idénticos
 Capacidad para manipular eventos en forma programada después de que han sido
generados y antes de que sean comunicados y presentados
 Capacidad para suprimir o marcar eventos durante periodos de baja del servicio
programados, tales como aquellos necesarios para responder a eventos dado que puede
no ser necesaria una acción durante esos momentos
 Soporte para etapas de diseño/pruebas – para que las nuevas aplicaciones/servicios
puedan ser monitoreados durante las etapas de diseño/pruebas y los resultados
alimentados de vuelta en el diseño y la transición
 Evaluación y manejo programable de alertas dependiendo de los síntomas e impacto
 Capacidad para permitir a un operador reconocer una alerta, y si no se captura una
respuesta dentro de un marco de tiempo definido, escalar la alerta
 Buena funcionalidad de reporte para permitir la retroalimentación en las etapas de
diseño y la transición así como un “tablero de control” de información gerencial y de
usuario del negocio que sea significativo.
109
Gestión de Eventos
Dicha tecnología debe permitir una interface directa con los procesos de Gestión de Incidentes
de la organización (a través de una entrada en el registro de incidentes), así como la capacidad
de escalación hacia el personal del soporte, proveedores externos, ingenieros y otros a través de
correo electrónico, mensajería SMS etc.
Una situación potencial importante que se presenta con estas tecnologías puede ser el volumen
significativo de mensajes que son creados desde el evento actual y el impacto del flujo en ambos
sentidos, lo que puede hacer difícil determinar cuál es la verdadera situación por resolver.
El software especializado en Gestión de Eventos puede separar mensajes falso-positivos. Los

eventos son capturados y evaluados por tecnologías de correlación basadas en reglas, modelos y
políticas que pueden interpretar una serie de eventos y derivar, aislar y reportar sobre la
verdadera causa e impacto. Estas tecnologías soportan la misión de CSI al proporcionar
información sobre los impactos en la disponibilidad y los umbrales de desempeño que han sido
excedidos relativos a la capacidad de utilización. Datos bien correlacionados de Gestión de
Eventos proporcionan un método efectivo en costo para mejorar la efectividad de la
infraestructura de dominio cruzado que soporta la provisión de servicios de negocios.
Una consecuencia de las revisiones extensivas y frecuentemente complejas llevadas a cabo por
estos productos de Gestión de Eventos es la recopilación de datos brutos de desempeño para ser
usados por muchos procesos, por ejemplo, dentro de las actividades de análisis Gestión de la
Capacidad. Esto permitiría por ejemplo simular intentos de acceso en cualquier momento
durante el día o la noche para verificar la disponibilidad de la base de datos y el desempeño.
110
Gestión de Eventos
Retos
 Un reto inicial sería obtener fondos para las herramientas necesarias y el esfuerzo
requerido para instalar y explotar los beneficios de las herramientas. Para poder
obtener los fondos necesarios se debe de preparar un caso de negocio convincente
mostrando los cómo los beneficios de una efectiva Gestión de Eventos puede superar los
costos – dando un ROI positivo
 Una de los retos mayores es establecer el nivel correcto de filtrado. Establecer
incorrectamente el nivel de filtrado puede resultar en estar inundado de eventos
relativamente insignificantes, o no ser capaz de detectar eventos relativamente
importantes hasta que ya es demasiado tarde.
 Desplegar los agentes de monitoreo necesarios a través de toda la infraestructura de TI
puede ser una actividad difícil y consumidora de tiempo, requiriendo un compromiso
continuo a través de un periodo más o menos largo de tiempo- existe el peligro de que
otras actividades puedan surgir, desviando los recursos y retrasando la implementación
 El monitoreo automático de actividades puede generar tráfico adicional en la red que
pudiera tener impactos negativos en los niveles de capacidad planeados de la red. Esto
podría llevar a acciones que redujeran la frecuencia del sondeo o la comunicación entre
los agentes y el sistema, resultando en menos tráfico, pero podría retrasar la
identificación de eventos
 Adquirir las habilidades necesarias puede ser consumidor de tiempo y costoso
 Implantar herramientas de Gestión de Eventos sin establecer procesos para operarlas,
procesos para implantar monitores y agentes para CIs nuevos, y procesos para
actualizar filtros, reglas de correlación o disparadores puede poner en riesgo el valor de
la inversión hecha en estas herramientas
111
Gestión de Eventos
Riesgos
Los riesgos clave son aquellos que acabamos de mencionar.
112
113
‘La Operación Normal del Servicio’ se define como un estado operacional donde los servicios y
los CIs son desempeñados dentro de sus niveles de servicio y operacionales acordados.
Objetivos
 Garantizar que sean usados métodos y procedimientos estandarizados para una pronta y
eficiente respuesta, análisis, documentación, gestión cotidiana y reporte de incidentes
 Aumentar la visibilidad y comunicación de incidentes para el negocio y el personal de
soporte de TI
 Mejorar la percepción del negocio con respecto a TI a través del uso de un enfoque
profesional al resolver y comunicar rápidamente los incidentes cuando ocurren
 Alinear las actividades y prioridades de Gestión de Incidentes con las del negocio
 Mantener la satisfacción del usuario a través de calidad en los servicios de TI
Alcance
Gestión de Incidentes incluye cualquier evento que interrumpa o pudiera interrumpir un
servicio. Esto incluye eventos que son comunicados directamente por los usuarios, ya sea a
través del Service Desk o a través de una interface de Gestión de Eventos hacia las herramientas
de Gestión de Incidentes.
Los incidentes también pueden ser reportados y/o registrados en la bitácora por el personal
técnico (si por ejemplo, ellos notan algo inadecuado con el hardware o un componente de red,
ellos lo pueden reportar o registrar un incidente y referirlo al Service Desk). No obstante, esto
no quiere decir, que todos los eventos sean incidentes. Muchas clases de eventos no son
relacionados en lo absoluto con interrupciones, pero son indicadores de una operación normal o
son simplemente informativos.
114
A pesar de que tanto incidentes como solicitudes de servicio son reportados al Service Desk, esto
no significa que son lo mismo. Las solicitudes de servicio no representan una interrupción de los
servicios acordados, pero son una forma de cubrir las necesidades del cliente y pueden estar
cubriendo un objetivo acordado en un SLA. Las solicitudes de servicio son atendidas a través del
proceso de cumplimiento de solicitudes.
Valor para el Negocio

El valor de Gestión de Incidentes incluye:
 La capacidad para reducir trabajos y costos no planeados tanto para el negocio como
para el personal de TI causados por incidentes
 La capacidad para detectar y resolver los incidentes lo que resulta en menos tiempo de
caída del servicio para el negocio, y que a su vez significa mayor disponibilidad del
servicio. Esto quiere decir que el negocio es capaz de explotar la funcionalidad del
servicio como fue diseñado
 La capacidad de alinear la actividad de TI con las prioridades del negocio en tiempo
real. Esto debido a que Gestión de Incidentes incluye la capacidad de identificar las
prioridades del negocio y asignar dinámicamente los recursos según sea necesario.
 La capacidad de identificar mejoras potenciales a los servicios. Esto ocurre como
resultado de entender lo que constituye un incidente y también de estar en contacto con
las actividades del personal operativo del negocio.
 Durante su manejo de incidentes, el Service Desk puede identificar requerimientos
adicionales de servicio o capacitación encontrados en TI o en el negocio.
115
Gestión de Incidentes es altamente visible para el negocio, por eso es más fácil demostrar su
valor que con la mayoría de las áreas de Operación del Servicio. Por esta razón, con
frecuencia, Gestión de Incidentes es uno de los primeros procesos a ser implementados en los
proyectos de gestión de servicios. El beneficio agregado de hacer esto es que Gestión de
Incidentes puede ser usado para resaltar otras áreas que requieren atención- proporcionando
así una justificación para hacer un gasto en implementar otros procesos.
Políticas
Algunos ejemplos de políticas de Gestión de Incidentes pueden incluir:
 Los incidentes y sus estatus deben ser comunicadas oportuna y efectivamente. Esto
implica establecer una buena función de Service Desk para coordinar la comunicación
sobre los incidentes hacia aquellos impactados por ellos así como hacia aquellos
trabajando para resolverlos. Los incidentes deben ser resueltos dentro de los rangos de
tiempo aceptables para el negocio. Esto implica que se establezcan los niveles acordados
de servicio, niveles operacionales y sus contratos de soporte (UCs), que esté disponible
un rápido acceso a la información de incidentes, errores conocidos y configuración y
exista un soporte apropiado para la tecnología para registrar, clasificar, priorizar y
diagnosticar eficientemente los incidentes.
 La satisfacción del cliente debe mantenerse todo el tiempo. Esto implica que a lo largo
de todas las etapas del proceso se emplee efectivamente personal de soporte
adecuadamente capacitado en lo técnico así como en su orientación al cliente
 El procesamiento y manejo de incidentes debe estar alineado con los niveles generales y
objetivos del servicio. Esto garantiza que las actividades de Gestión de Incidentes
soporten los niveles de servicio y los objetivos al priorizar dichas actividades basados en
116
las necesidades reales del negocio. Todos los incidentes deben ser almacenados y
gestionados en un solo sistema de gestión. El estatus y la información detallada del
incidente deben ser registrados y actualizados periódicamente en registros de incidentes.
Todos los incidentes deben apegarse a un esquema de clasificación estándar que sea
consistente a través de toda la empresa. Esto proporciona un acceso más rápido a
información de incidentes y solución de problemas. Proporciona un mejor soporte para
el diagnóstico de Gestión de Problemas y actividades de tendencia proactiva. Los
registros de incidentes deben ser auditados regularmente para garantizar que han sido
registrados y categorizados correctamente. Esto garantiza que la información de
incidentes sea precisa, esté correctamente categorizada y otras áreas de soporte puedan
confiar en ella. Todos los registros de incidentes deben utilizar un formato y establecer
campos de información comunes cuando sea posible para garantizar que toda la
información requerida sobre incidentes esté disponible en un formato común para
soportar actividades de Gestión de Incidentes y sea compartida fácilmente con otras
áreas de soporte que dependen de la información de incidentes.
 Siempre que sea posible, debe establecerse un conjunto de criterios común y acordado
para priorizar y escalar los incidentes. Esto garantiza que se establezcan medios
aceptados para priorizar y escalar los incidentes con base en las políticas acordadas y
no únicamente determinadas por los individuos dentro de la organización de soporte de
TI.
117
Escalas de Tiempo
Se deben acordar las escalas de tiempo para todas las etapas de manejo de incidentes (estas
diferirán dependiendo del nivel de prioridad del incidente), con base en los objetivos generales
de respuesta y resolución de incidentes dentro de los SLAs, y capturados como objetivos dentro
de los OLAs y UCs. Todos los grupos de soporte deben estar completamente conscientes de estas
escalas de tiempo. Las herramientas de gestión de servicios deben ser usadas para automatizar
las escalas de tiempo y escalar los incidentes conforme sea requerido con base en las reglas
predefinidas.
Modelos de Incidentes
Muchos incidentes no son nuevos – implican lidiar con algo que ya ha ocurrido antes y que
puede volver a ocurrir. Por esta razón, muchas para muchas organizaciones resultará útil
predefinir modelos estándar de incidentes y aplicarlos a los incidentes apropiados cuando
ocurran.
Un modelo de incidente es una forma de predefinir los pasos que deben seguirse para manejar
un proceso (en este caso un proceso para liderar con un tipo particular de incidente) de la
forma acordada. Las herramientas de soporte pueden ser usadas para gestionar los procesos
requeridos. Esto garantizará que los incidentes “estándar” sean manejados a través de una ruta
predefinida y dentro de escalas predefinidas de tiempo.
El modelo de incidentes debe incluir:

 Los pasos que deben seguirse para manejar el incidente
 El orden cronológico en el que deben seguirse estos pasos, con cualquier dependencia o
co-procesamiento definido
118
 Responsabilidades; quién debe hacer qué

 Se deben tomar precauciones antes de resolver el incidente, tales como respaldar los
datos, archivos de configuración, o pasos a completar relativos a los lineamientos de
salud y seguridad
 Escalas de tiempo y umbrales para completar las acciones
 Procedimientos de escalación; quién debe ser contactado y cuándo
 Cualquier actividad de preservación de evidencia necesaria (particularmente relevantes
para los incidentes relativos a la seguridad y la capacidad)
Estos modelos deben ser ingresados en las herramientas de soporte de manejo de incidentes que
se estén usando y las herramientas deben automatizar el manejo, gestión y escalación del
proceso. Los modelos de incidentes deben ser almacenados en el SKMS
Incidentes Mayores
Se debe usar un procedimiento independiente, con escalas de tiempo más reducidas y mayor
urgencia para los incidentes “mayores”. Se debe acordar una definición de lo que constituye un
Incidente mayor e idealmente se debe mapear en el esquema general de priorización de
incidentes- de tal forma que sea manejado a través de este procedimiento separado.
Si la causa del incidente necesita ser investigada al mismo tiempo, entonces el gerente de
problemas también estaría involucrado, pero el gerente de incidentes debe garantizar que la
restauración del servicio y la causa subyacente se mantengan por separado. Durante todo el
incidente, el Service Desk garantizaría que todas las actividades sean registradas y que los
usuarios están completamente informados sobre el progreso. Mientras el Service Desk puede ser
responsable de garantizar que el registro del incidente/ incidente mayor esté siempre
actualizado, la responsabilidad también puede residir en otra parte (como en los otros equipos
técnicos).
Rastreo de Estatus de Incidentes

Los incidentes deben ser rastreados a través de su ciclo de vida para soportar el manejo y
reporte adecuados sobre el estatus de los incidentes. Dentro del sistema de Gestión de
Incidentes, los códigos de estatus deben estar ligados con los incidentes para indicar dónde se
encuentran en relación con el ciclo de vida. Algunos ejemplos de estos podrían incluir:
 Abierto Un incidente ha sido reconocido pero todavía no ha sido asignado a un recurso

de soporte para su resolución.
 En progreso El incidente está en proceso de ser investigado y resuelto
 Resuelto Se ha establecido una solución para el incidente pero el estado normal de
Operación del Servicio aún no ha sido validado por el negocio o usuario final
 Cerrado El usuario o el negocio está de acuerdo en que el incidente ha sido resuelto y
que el estado normal de las operaciones ha sido restaurado
119
Ciclo de Vida de Incidentes Ampliado

Diseño del Servicio de ITIL y Mejora Continua del Servicio de ITIL describen el ciclo de vida
de incidentes ampliado el cual puede ser usado para ayudar a entender todas las contribuciones
al impacto de los incidentes y a planear cómo pudieran ser controlados o reducidos.
120
Actividades de Gestión de Incidentes

Gestión de Interface Llamada Correo
Eventos Web telefónica electrónico
Identificación del
Incidente
A Cumplimiento de
No Solicitudes (si esto es
¿Es
realmente una solicitud de
incidente? servicio) o Gestión de
Portafolio de Servicios
(si es una propuesta de
Sí
cambio)
Registro de Incidente
Categorización de
Incidente
Priorización de
Incidente
Procedimiento Sí
de Incidente ¿Incidente
Mayor?
Mayor
No
Diagnóstico Inicial
Escalación
Funcional
Sí ¿Escalación Sí
¿Requiere
Funcional?
escalación?
No No
No Investigación y
Sí diagnóstico No
¿Escalación
jerárquica?
Escalación
a Gerencia
¿Solución
identificada?
Yes
Solución y
Recuperación
Cierre de Incidente
Fin
© Crown copyright 2011 Reproducido bajo licencia del la
Oficina del Gabinete.
Figura 4.3 Operación del Servicio 4.2.5
121
Identificación de Incidentes
Aunque el trabajo no puede comenzar para atender un incidente hasta que se sabe que ha
ocurrido un incidente, normalmente es inaceptable, desde una perspectiva de negocio, esperar
hasta que un usuario haya sido impactado y contacte al Service Desk. Hasta donde sea posible,
todos los componentes clave deben ser monitoreados para que las fallas o fallas potenciales
sean detectados de forma temprana. Esto significa que el proceso de Gestión de Incidentes
puede ser arrancado rápidamente. ¡Idealmente, los incidentes deben ser resueltos antes de que
tengan un impacto en los usuarios!
Registro de Incidentes
Todos los incidentes deben ser completamente registrados y marcados con fecha/hora, sin
importar si son levantados a través de una llamada telefónica al Service Desk, detectados
automáticamente a través de la alerta de eventos, o desde cualquier otra fuente.
La información necesaria para cada incidente puede incluir:
 Número único de referencia

 Categorización del incidente (comúnmente dividido entre dos y cuatro subcategorías)
 Urgencia, impacto y prioridad del incidente
 Fecha/hora en que fue registrado
 Nombre/ID de la persona y /o grupo que registra el incidente
 Método de notificación (teléfono, automático, correo, en persona, etc.)
 Nombre/departamento/teléfono/ubicación del usuario
 Método de contacto con el usuario (teléfono, correo, etc.)
 Descripción de los síntomas
 Estatus de incidentes (activo, en espera, cerrado, etc.)
 CI relacionado
 Grupo/persona de soporte al que se le asigna el incidente
 Problema relacionado/error conocido
 Actividades emprendidas para resolver el incidente y cuándo se efectuaron
 Fecha y hora de solución
 Categoría de cierre, fecha y hora
Tome en cuenta que si el Service Desk no trabaja 24/7 y la responsabilidad del registro y
manejo de incidentes de primera línea se transfiere a otro grupo, tal como operaciones de TI o
soporte de red, fuera de las horas del Service Desk, entonces este personal necesita ser
igualmente riguroso sobre registrar los detalles de los incidentes. Se le necesita proporcionar un
entrenamiento y concientización completos a dicho personal sobre este tema.
Conforme ocurren actividades adicionales para resolver un incidente, los registros del incidente
deben ser actualizados con información relevante y detalles para que se mantenga la historia
completa. Como ejemplos de esto podríamos incluir cambiar la categorización o prioridad una
vez que se ha dado un mayor diagnóstico o han ocurrido actividades de escalación.
122
Categorización de Incidentes
Parte del registro inicial debe ser asignar el código adecuado de categorización del incidente
para que el tipo exacto de incidente sea registrado. Esto será importante más adelante cuando
se revisen los tipos/frecuencias de incidentes para establecer tendencias para su uso en Gestión
de Problemas, Gestión de Proveedores y otras actividades de ITSM.
La categorización multinivel está disponible en la mayoría de las herramientas – normalmente

de tres a cuatro niveles de granularidad. Por ejemplo, un incidente puede ser categorizado como
se muestra a continuación.
Ubicación Aplicación
impactada impactada
Servicio Base de datos

impactado impactada
O
Sistema Servidor
impactado impactado
Aplicación Drive de disco

impactada impactado
© Crown copyright 2011 Reproducido bajo licenica de la Oficina del Gabinete.

Figura 4.4 Operación del Servicio 4.2.5.3
Las técnicas para establecer categorías desde cero incluyen:
1 Llevar a cabo una sesión de lluvia de ideas entre los grupos relevantes de soporte,
involucrando al supervisor del Service Desk y a los gerentes de incidentes y problemas.
2 Usar esta sesión para hacer el mejor intento por decidir las categorías de alto nivel,
idealmente teniendo en mente al cliente, para que el servicio (o en el peor de los casos,
la aplicación) encabece la lista – e incluir otra categoría. Configurar las herramientas
relevantes de registro para usar estas categorías durante un periodo de prueba.
3 Usar las categorías por un periodo de prueba corto (lo suficientemente largo para que
varios cientos de incidentes caigan en cada categoría, pero no demasiado largo como
para que el análisis tome demasiado tiempo en realizarse).
4 Lleve a cabo un análisis de los incidentes registrados durante el periodo de prueba. El
número de incidentes registrado en cada categoría de nivel superior confirmará si vale
la pena mantener esa categoría- y un análisis más detallado de la “otra” categoría debe
permitir la identificación de cualquier categoría adicional de mayor nivel que sea
necesaria.
5 Un análisis de desglose de incidentes dentro de cada categoría de nivel superior debe
ser usado para decidir las categorías de nivel inferior que serán requeridas.
123
6 Revisar y repetir estas actividades después de un periodo adicional de, digamos uno a
tres meses y de nuevo revisar con regularidad para asegurar que siguen siendo
relevantes. Sea consciente de que cualquier cambio significativo a la categorización
puede causar algunas dificultades para identificar las tendencias de incidentes o el
reporte gerencial, por lo que deben ser estabilizadas a menos de que los cambios sean
verdaderamente requeridos.
Si se está usando un esquema de categorización, pero se cree que no está funcionando

satisfactoriamente, la idea básica de la técnica sugerida anteriormente puede ser usada para
revisar y corregir el esquema existente.
Priorización de Incidentes
Otro aspecto importante de registrar cada incidente es acordar y asignar un código de prioridad
adecuado, ya que esto determinará cómo será manejado el incidente tanto por la herramienta
de soporte como por el personal de soporte.
Normalmente la priorización puede ser determinada tomando en cuenta ambos, la urgencia del
incidente (que tan rápido requiere de una solución el negocio) y el nivel de impacto que está
causando al negocio. Los factores que pueden contribuir a los niveles de impacto son:
 Riesgo o amenaza de vida

 El número de servicios afectado – pueden ser varios servicios
 El nivel de pérdida financiera
 El efecto en la reputación del negocio
 Violaciones regulatorias o legislativas
Una manera efectiva de calcular estos elementos y obtener un nivel general de prioridad para
cada incidente se muestra en la siguiente tabla:
Sistema de codificación de prioridad simple

Impacto
Urgencia Alto Medio Bajo
Alto 1 2 3
Medio 2 3 4
Bajo 3 4 5
Código de Descripción Tiempo objetivo de solución
prioridad
1 Crítico 1 hora
2 Alto 8 horas
3 Medio 24 horas
4 Bajo 48 horas
5 Planeación Planeado
© Crown copyright 2011 Reproducido bajo la licencia de la Oficina del Gabinete
Tabla 4.1 Operación del Servicio 4.2.5.4
124
En todos los casos se deben proporcionar lineamientos claros -con ejemplos prácticos- para
todo el equipo de soporte para permitirles determinar los niveles correctos de impacto y
urgencia, para que puedan asignar la prioridad correcta. Tal orientación debe ser generada
durante las negociaciones de nivel de servicio.
Sin embargo, cabe hacer notar que habrá ocasiones donde, debido a su propia conveniencia, los
niveles normales de prioridad tendrán que ser ignorados. Cuando un usuario insiste en que el
nivel de prioridad del incidentes debe exceder los lineamentos normales, el Service Desk debe
cumplir con dicha solicitud- y si posteriormente resulta ser incorrecto, esto puede ser resuelto
como una situación a nivel de línea superior de reporte, más que como una disputa que ocurra
con el usuario mientras que el incidente está siendo reportado.
Diagnóstico Inicial
Si el incidente ha sido canalizado a través del Service Desk, el analista del Service Desk debe
llevar a cabo el diagnóstico inicial, normalmente cuando el usuario todavía está al teléfono- si
la llamada es levantada de esta forma- para tratar de descubrir los síntomas completos del
incidente y para determinar exactamente lo que está fallando y cómo corregirlo. Es en este
momento que los scripts de diagnóstico y la información de errores conocidos pueden ser más
valiosos al permitir un diagnóstico temprano y preciso.
De ser posible, el analista del Service Desk puede resolver el incidente mientras el usuario está
al teléfono – y cerrar el incidente si se está de acuerdo en que la resolución y la recuperación
han sido exitosas. Si el analista del Service Desk no puede resolver el incidente mientras que el
usuario está al teléfono, pero existe la expectativa de que el Service Desk puede ser capaz de
hacerlo dentro del límite de tiempo acordado sin la ayuda de otros grupos de soporte, el analista
debe informarle esto al usuario, darle al usuario un número de referencia del incidente e
intentar encontrar una solución.
Procedimiento de Correspondencia de Incidentes

Muchos incidentes ya han ocurrido anteriormente y se conocen bien las acciones apropiadas
para darles solución. Sin embargo, es necesario tener un procedimiento para encontrar la
correspondencia entre la clasificación del incidente contra los problemas y errores conocidos.
Esta coincidencia exitosa proporciona un acceso rápido y eficiente a acciones de solución
probadas, reduciendo el tiempo que toma restablecer el servicio al usuario. El proceso de
clasificación y correspondencia permite que Gestión de Incidentes se lleve a cabo más
rápidamente y minimiza la necesidad de escalación a otro personal de soporte.
El uso efectivo de la correspondencia de incidentes garantiza que los incidentes no estén siendo
investigados redundantemente para darles solución una y otra vez. Se puede desarrollar un
procedimiento para ayudar al Service Desk y a otro personal de soporte a hacer la
correspondencia de los incidentes para encontrar las soluciones rápidamente cuando sea
posible.
125
Ejemplo de un Procedimiento de Correspondencia de Incidentes
Procedimiento de
correspondencia (parte
de diagnóstico inicial)
Extraer solución o acción Sí ¿Correspondencia Actualizar cuenta de

temporal de la base de en BD de errores incidente en registro de
datos de errores conocidos conocidos?
problema
No
Actualizar cuenta de
incidente en registro de Actualizar registro de
incidente con ID de
errores conocidos ¿Correspondencia Sí
con registro de problema problema
existente?
Actualizar registro de
incidente con ID de error No
conocido Actualizar registro de
incidente con datos de
clasificación
¿Rutina de Sí
Actualizar registro de Incidentes?
incidente con datos de
clasificación
No
Informar al cliente de la
Registrar nuevo
acción temporal
problema
Regresar a
diagnóstico inicial
© Crown copyright 2011 Reproducido baja la licencia de la Oficina del Gabinete.

Figura 4.5 Operación del Servicio 4.2.5.5
126
Escalamiento de Incidente
Escalamiento Funcional
Tan pronto como queda claro que el Service Desk es capaz resolver el incidente por sí mismo (o
cuando los tiempos objetivo de resolución de primer punto han sido excedidos- lo que ocurra
primero), el incidente debe ser inmediatamente escalado para soporte adicional.
¡Note que la posesión del incidente se mantiene en el Service Desk! Sin importar hacia donde
sea referido un incidente durante su vida, la posesión del incidente debe permanecer con el
Service Desk en todo momento. El Service Desk sigue siendo responsable de rastrear el
progreso, mantener informados a los usuarios y finalmente hacer el cierre del incidente.
Escalamiento Jerárquico
Si los incidentes son de naturaleza seria (por ejemplo, incidentes de alta prioridad) los gerentes
apropiados de TI deben ser notificados, al menos con fines informativos. La escalación
jerárquica también es usada en la “investigación y el diagnóstico” y “la solución y
recuperación” en caso de que los pasos estén llevando demasiado tiempo o demuestren ser
demasiado difíciles. La escalación jerárquica debe continuar hacia la cadena de mando
superior para que los gerentes senior estén enterados y puedan estar preparados para tomar las
acciones necesarias, tales como asignar recursos adicionales o involucrar
proveedores/especialistas en mantenimiento. La escalación jerárquica también es usada cuando
está en disputa a quién está asignado el incidente.
Por supuesto, la escalación jerárquica, puede ser iniciada por el usuario o gerencia del cliente
afectada, según lo juzguen conveniente – es por ello que es importante que los gerentes de TI
estén informados para que puedan anticipar y estar preparados ante una escalación como esta.
Los niveles exactos y escalas de tiempo para ambas escalaciones, funcional y jerárquica,
necesitan ser acordados tomando en cuenta los objetivos de SLA, y contenidos dentro de las
herramientas de soporte que pueden ser usados para vigilar y controlar el flujo del proceso
dentro de las escalas de tiempo acordadas. El Service Desk debe mantener al usuario informado
sobre cualquier escalación relevante que ocurra y asegurar que cualquier registro de incidente
sea actualizado de acuerdo a esto, para mantener un historial completo de las acciones.
Nota con Respecto a la Asignación del Personal para Manejar los Incidentes
Puede haber muchos incidentes en fila con el mismo nivel de prioridad, así que inicialmente será
trabajo del Service Desk y/o personal de Gestión de Incidentes, junto con los gerentes de los
distintos grupos de soporte hacia los cuales son escalados los incidentes, decidir el orden en que
los incidentes deben ser elegidos para trabajar activamente en ellos. Estos gerentes deben
garantizar que los incidentes sean atendidos en verdadero orden de prioridad de negocio y que
no se permita al personal elegir arbitrariamente los incidentes que atenderán.
Investigación y Diagnóstico
Es probable que un incidente reportado requiera algún grado de investigación y diagnóstico.
Cada uno de los grupos de soporte involucrados con el manejo de incidentes investigará y
127
diagnosticará lo que está mal – y todas estas actividades (incluyendo los detalles de cualquiera
de las acciones tomadas para tratar de resolver o recrear el incidente) deben ser completamente
documentadas en el registro de incidentes para que en todo momento se lleve un registro
histórico completo de todas las actividades.
Note que frecuentemente se puede perder tiempo valioso si las acciones de investigación y
diagnóstico, (o inclusive acciones de solución y recuperación) son llevadas a cabo en forma
serial. Cuando sea posible, dichas actividades deben hacerse en paralelo para reducir las
escalas de tiempo- y las herramientas de soporte deben estar diseñadas y/o ser seleccionadas
para permitir esto. Sin embargo, se debe tener cuidado para coordinar las actividades,
particularmente las actividades de solución o recuperación; de otro modo, las acciones de los
diferentes grupos pueden entrar en conflicto o complicar más la solución.
Probablemente la investigación incluya acciones como:

 Establecer exactamente lo que falló o lo que ha sido visto por el usuario
 Entender el orden cronológico de los eventos
 Confirmar el impacto total del incidente, incluyendo el número y rango de usuarios
afectados
 Identificar cualquier evento que pudo haber disparado el incidente (ej.: ¿un cambio
reciente, alguna acción del usuario?)
 Búsquedas detalladas de conocimiento buscando ocurrencias previas revisando los
registros de incidentes/problemas y/o base de datos de errores conocidos (KEDBs) o
registros de errores o bases de datos de conocimientos de los fabricantes/proveedores.
Estas coincidenticas pueden no haber sido obvias durante el diagnóstico inicial
Solución y Recuperación
Cuando una solución potencial ha sido identificada, esta debe ser aplicada y probada. Las
acciones específicas a ser emprendidas y la gente que estará involucrada en ejecutar las
acciones de recuperación pueden variar, dependiendo de la naturaleza de la falla, pero podrían
implicar:
 Pedir al usuario que lleve a cabo actividades directas en su propio equipo de escritorio o
equipo remoto
 Que el Service Desk implemente la solución ya sea centralmente (digamos, reiniciando
un servidor) o remotamente, usando software para tomar control del equipo del usuario
para diagnosticar e implementar una solución
 Grupos de soporte de especialistas a los que se les pide implementar acciones de
recuperación específicas (ej.: soporte de red reconfigurando un ruteador)
 Un tercero, proveedor externo o de mantenimiento al que se le pide resolver la falla
 Aun cuando una solución ha sido encontrada, se deben llevar a cabo suficientes pruebas
para garantizar que la acción de recuperación sea completa y que el estado normal de
Operación del Servicio haya sido restaurado.
Sin importar las acciones tomadas, o quién las ejecuta, el registro del incidente debe ser
actualizado de acuerdo con la información relevante y los detalles para que se mantenga un
128
historial completo. El grupo que da solución debe pasar el incidente de regreso al Service Desk
para el cierre.
Cierre del Incidente

El Service Desk debe verificar que el incidente esté completamente resuelto y que los usuarios
estén satisfechos y dispuestos a acordar que el incidente puede cerrarse. El Service Desk
también debe revisar lo siguiente:
 Categorías de cierre: Verificar y confirmar que la categorización inicial del incidente fue
correcta, o cuando la categorización posteriormente resultó ser incorrecta, actualizar el
registro para incluir una categorización de cierre correcta para el incidente – buscando,
de ser necesario el consejo u orientación del grupo o grupos que lo resolvieron
 Encuesta de satisfacción del usuario: Efectuar una encuesta de satisfacción a través de
una llamada o un correo electrónico para el porcentaje acordado de incidentes
 Documentación del incidente: Ir en búsqueda de cualquier detalle relevante y
garantizar que el registro del incidente esté totalmente documentado para que se guarde
un registro histórico completo con el suficiente nivel de detalle.
 ¿Problema continuo o recurrente? Determinar (en conjunto con los grupos de
resolución) si el incidente fue resuelto sin que la causa raíz haya sido identificada. En
este caso, es probable que el incidente sea recurrente y se requiera acción preventiva
adicional para evitar esto. En todos los casos, determinar si un registro de problema
relativo al incidente ya ha sido levantado. Si no, levantar un nuevo registro de problema
en conjunto con el proceso de Gestión de Problemas para que una acción preventiva sea
iniciada.
 Cierre formal: Cerrar formalmente el incidente del registro
* Note que algunas organizaciones pueden elegir utilizar un periodo automático de

cierre, para algunos incidentes específicos, o inclusive para todos los incidentes (ej.: los
incidentes serán cerrados automáticamente después de dos días de trabajo si no se da un
contacto adicional por parte del usuario). Cuando se considera este enfoque, primero
debe ser ampliamente discutido y acordado con los usuarios – y ampliamente publicitado
para que todos los usuarios y personal de TI estén conscientes de esto. Para cierto tipo
de incidentes, puede resultar inapropiado usar este método, como en incidentes mayores
o aquellos que involucran VIPs.
Reglas para Reabrir Incidentes

A pesar de todo el cuidado que se tenga, habrá ocasiones en los que los incidentes vuelvan a
ocurrir, aún cuando hayan sido formalmente cerrados. La elección hecha debe tomar en cuenta
sus efectos sobre el conjunto de datos, para que la recurrencia y trabajo asociados sean
claramente registrados y reportados con precisión. Debido a casos como estos, es recomendable
contar con reglas predefinidas al respecto de sí y cuando puede reabrirse un incidente. Por
ejemplo, puede tener sentido, acordar que si el incidente vuelve a ocurrir en el lapso de un día
laboral, puede ser reabierto – pero más allá de este punto se debe levantar un nuevo incidente,
pero ligado al incidente(s) previo(s).
129
El umbral/ reglas de tiempo exactos pueden variar entre las distintas organizaciones, pero
deben acordarse y documentarse reglas claras y dar orientación al personal del Service Desk
para que se apliquen con uniformidad.
Disparadores
Los incidentes pueden ser detonados de muchas formas. El camino más común es cuando un
usuario llama al Service Desk o completa un incidente capturándolo en una pantalla web, pero
cada vez aumenta más el número de incidentes levantados automáticamente a través de
herramientas de Gestión de Eventos. El personal técnico puede notar fallas potenciales y
levantar un incidente, o pedir al Service Desk que lo levante, para que la falla pueda ser
atendida. Algunos incidentes también pueden surgir a iniciativa de los proveedores – que
pueden enviar algún tipo de notificación sobre alguna necesidad potencial o real que requiera
atención.
Entradas
Algunos ejemplos de entradas para el proceso de Gestión de Incidentes pueden incluir:
 Información sobre los CIs y su estatus

 Información sobre errores conocidos y sus soluciones temporales
 Comunicación y retroalimentación sobre los incidentes y sus síntomas
 Comunicación y retroalimentación sobre RFCs y liberaciones que han sido
implementadas o que se planea implementar
 Comunicación de eventos que fueron detonados por Gestión de Eventos
130
 Objetivos operacionales y de niveles de servicio

 Retroalimentación del cliente sobre el éxito de las actividades para la resolución de un
incidente y la calidad general de las actividades de Gestión de Incidentes
 Criterios acordados para priorizar y escalar los incidentes.
Salidas
Algunos ejemplos de salidas del proceso de Gestión de Incidentes pueden incluir:
 Incidentes resueltos y acciones tomadas para lograr su resolución

 Registros de Gestión de Incidentes actualizados con detalles e historia precisos del
incidente
 Clasificación actualizada de los incidentes empleada para soportar proactivamente las
actividades de Gestión de Problemas
 Levantamiento de registros de problemas para incidentes donde una causa subyacente
no ha sido identificada
 Validación de que los incidentes no han sido recurrentes para problemas que han sido
resueltos
 Retroalimentación de incidentes relacionados con cambios y liberaciones
 Identificación de CIs asociados con o impactados por incidentes
 Retroalimentación de la satisfacción de los clientes que han experimentado incidentes
 Retroalimentación en el nivel y calidad de las tecnologías de monitoreo y actividades de
Gestión de Eventos
 Comunicaciones sobre los incidentes y el detalle de la historia de la solución para
apoyar la identificación de la calidad general del servicio
131
Herramientas de Gestión de Incidentes

Estas contienen información sobre:
 Historia de los incidentes y problemas
 Categorías de incidentes
 Acciones tomadas para resolver los incidentes
 Scripts de diagnóstico que pueden ayudar a los analistas de primera línea a resolver el
incidente, o al menos reunir información que ayudará a los analistas de segunda o
tercera línea a resolverlo más rápidamente
Registros de Incidente
Estos incluyen la siguiente información:
 Número único de referencia
 Clasificación de incidentes
 Fecha y hora de registro y de cualquier actividad subsecuente
 Nombre e identidad de la persona que registra y actualiza el registro del incidente
 Nombre/organización/detalles de contacto del o los usuarios afectados
 Descripción de los síntomas del incidente
 Detalles de cualquier acción tomada para tratar de diagnosticar, resolver o recrear el
incidente
 Categoría, impacto, urgencia y prioridad del incidente
 Relaciones con otros incidentes, problemas, cambios o errores conocidos
 Detalles de cierre incluyendo tiempo, categoría, acción tomada e identidad de la persona
que cierra el registro
 Otros datos registrados sobre el incidente (ver SO sección 4.2.5.2)
132
 Catálogo de servicios, que puede incluir los siguientes datos:

o Objetivos clave de entrega del servicio, niveles y metas
o Información sobre el servicio en términos que el cliente y usuarios entiendan
o Información que pueda ser usada para comunicarse con los clientes y usuarios
Gestión de Incidentes también requiere acceso al CMS. Esto ayudará a identificar el CIs
afectado por el incidente y también para estimar el impacto del incidente.
La KEDB proporciona información valiosa sobre las posibles soluciones y acciones temporales
de solución.
133
134
La siguiente lista incluye algunos ejemplos de CSFs y KPIs para Gestión de Incidentes.

Resolver los incidentes tan pronto  Tiempo transcurrido promedio para lograr resolver o darle la
como sea posible minimizando los vuelta a un incidente, desglosado por código de impacto
impactos al negocio  Porcentaje de incidentes cerrados por la Mesa de Servicio sin
referencia a otros niveles de soporte (normalmente referido como
“primer punto de contacto”)
 Desglose de incidentes en cada etapa (ej.: registrado, trabajo
en progreso, cerrado, etc.)
 Número y porcentaje de incidentes resueltos remotamente, sin
la necesidad de una visita
 Número de incidentes resueltos sin impacto al negocio (ej.: el
incidente fue levantado por Gestión de Eventos y resueltos antes
de que pudiera impactar al negocio)
Mantener la calidad de los  Número total de incidentes (como una medida de control)
servicios de TI  Tamaño de fila de incidentes actuales pendientes para
cada servicio de TI
 Número y porcentaje de incidentes mayores para cada
servicio de TI
Mantener la satisfacción del  Calificación promedio de encuestas a usuarios/clientes
usuario con los servicios de TI (total y por categoría de pregunta)
 Porcentaje de encuestas de satisfacción contestadas
contra el número total de encuestas de satisfacción
enviadas
Elevar la visibilidad y la  Número promedio de llamadas al Service Desk u otros
comunicación de los incidentes contactos por parte los usuarios de negocio por incidentes
para el negocio y el personal de ya reportados
soporte de TI  Número de quejas o situaciones de los usuarios del
negocio sobre el contenido y calidad de las comunicaciones
de los incidentes. Número y porcentaje de eventos indicando
situaciones de desempeño (por ejemplo, crecimiento en el
número de veces que una aplicación ha excedido su umbral
de transacciones en los últimos seis meses)
 Número y porcentaje de eventos indicando situaciones
potenciales de disponibilidad (ej.: caídas de dispositivos
alternos o swapping excesivo de cargas de trabajo)
Alinear las actividades de Gestión  Porcentaje de incidentes manejados dentro del tiempo de
de Incidentes y las prioridades respuesta acordado (los objetivos de tiempo de respuesta de
con las del negocio incidentes pueden ser especificados en los SLAs, por
ejemplo, por códigos de impacto y urgencia )
 Costo promedio por incidente
Asegurar que se utilicen métodos  Número y porcentaje de incidentes incorrectamente
y procedimientos estandarizados asignados
para una pronta y eficiente  Número y porcentaje de incidentes incorrectamente
respuesta, análisis, categorizados
135
documentación, gestión cotidiana  Número y porcentaje de incidentes procesados por agente

y reporte de incidentes para del Service Desk
mantener la confianza del  Número y porcentaje de incidentes relacionados con
negocio en las capacidades de TI cambios y liberaciones
También resulta útil desglosar y categorizar las métricas de incidentes por categoría, marco de
tiempo, impacto, urgencia, servicio impactado, ubicación y prioridad y compararlos con
periodos previos. Esto puede proporcionar información de entrada a Gestión de Problemas, CSI
y otros procesos buscando identificar asuntos, problemas y tendencias u otras situaciones.
Los reportes deben ser generados bajo la autoridad del gerente de incidentes, quien debe
preparar un calendario y lista distribución, en colaboración con el Service Desk y los grupos de
soporte que manejan incidentes. Las listas de distribución deben al menos incluir a la gerencia
de servicios de TI y grupos de especialistas de soporte. También considere poner los datos a
disposición de los usuarios y clientes, por ejemplo a través de reportes de SLA.
Aquí tenemos algunos indicadores clave de desempeño adicionales para el valor de Gestión de
Incidentes:
Indicador Clave de Desempeño Comentario

Disponibilidad mejorada Al reducir el tiempo para restaurar el servicio
Reducción de violaciones en el nivel de A través del uso de un modelo de prioridad,
servicio posesión del incidente, monitoreo y rastreo
acordados
Reducción del tiempo promedio para Escalaciones y priorizaciones mejoradas, uso
reparación (MTTR) de correspondencia de incidentes con errores
conocidos
Reducción de incidentes mayores Escalando a Gestión de Problemas para el
análisis y eliminación de la causa raíz
136

 Gestión del Nivel de Servicio La capacidad de resolver incidentes en un tiempo
específico es una parte clave de entregar un nivel de servicio acordado. La Gestión de
Incidentes permite a SLM definir respuestas medibles para las interrupciones del
servicio. También proporciona reportes que permiten a SLM revisar los SLAs objetiva y
regularmente. En particular, Gestión de Incidentes es capaz de apoyar en definir dónde
están más débiles los servicios, para que SLM pueda definir acciones como parte del
plan de mejora del servicio (SIP) (para más detalles ver Mejora Continua del Servicio de
ITIL). SLM define los niveles aceptables de servicio dentro de los cuales trabaja Gestión
de Incidentes, incluyendo:
o Tiempos de respuesta de incidentes
o Definiciones de impacto
o Tiempos fijos objetivo
o Definiciones de servicios, las cuales están mapeadas hacia los usuarios
o Reglas para solicitar servicios
o Expectativas para proporcionar retroalimentación a los usuarios
 Gestión de Seguridad de la Información Proporcionar información relativa a

incidentes de seguridad según sea necesario para soportar las actividades de Diseño del
Servicio y obtener una visión completa de la efectividad de las medidas de seguridad
como un todo basado en una revisión a profundidad de los incidentes de seguridad. Esto
es posible manteniendo archivos de log y de auditoría y registros de incidentes
137
 Gestión de la Capacidad Gestión de Incidentes proporciona un detonador para el

monitoreo del desempeño donde parezca haber un problema de desempeño. Gestión de
la Capacidad puede desarrollar soluciones temporales para los incidentes.
 Gestión de la Disponibilidad usará datos de Gestión de Incidentes para determinar la
disponibilidad de los servicios de TI y buscar donde puede mejorarse el ciclo de vida de
incidentes.

 Gestión de Activos del Servicio y Configuración Este proceso proporciona los datos
utilizados para identificar y hacer avanzar los incidentes. Uno de los usos del CMS es
identificar equipo defectuoso y evaluar el impacto de un incidente. El CMS también
contiene información sobre qué categorías de incidentes deben ser asignados a qué
grupo de soporte. Por su parte, Gestión de Incidentes puede mantener el estatus de CIs
defectuosos. También puede ayudar a Gestión de Activos del Servicio y Configuración a
auditar la infraestructura cuando se trabaja para resolver un incidente.
 Gestión de Cambios Cuando se requiere un cambio para poder implementar una
solución temporal o definitiva, este tendrá que ser registrado como una RFC y avanzará
a través de Gestión de Cambios. Por su parte, Gestión de Incidentes es capaz de detectar
y resolver incidentes que surjan de cambios fallidos.

 Gestión de Problemas Para algunos incidentes, resultará apropiado involucrar a
Gestión de Problemas para investigar y resolver la causa subyacente para así prevenir o
reducir el impacto de su recurrencia. Gestión de Incidentes proporciona un punto donde
estos son reportados. A cambio, Gestión de Problemas, puede proporcionar errores
conocidos para una resolución de incidentes más rápida a través de soluciones
temporales que puedan ser usadas para restablecer el servicio.
 Gestión de Accesos Los incidentes deben ser levantados cuando se detecten intentos no
autorizados de acceso y violaciones de seguridad. También debe mantenerse un historial
para soportar actividades de investigación forense y la resolución de violaciones de
acceso

 Gestión de Incidentes y Service Desk soportan la actividad del análisis de datos de CSI
al:
o Documentar y revisar las tendencias de incidentes en incidentes, solicitudes de
servicio y estadísticas telefónicas a lo largo de un periodo de tiempo para
identificar cualquier patrón consistente
o Comparar los resultados con reportes mensuales, trimestrales o anuales
o Comparar los resultados con los niveles acordados de servicio
o Identificar oportunidades de mejora
o Analizar la precisión de los datos procesados
o Gestión de Incidentes y Service Desk soportan la actividad de presentación de
CSI al:
o Soportar la preparación de reportes
o Proporcionar información para priorizar SIPs o mejoras
138
o Implementar actividades incrementales o ligeros ajustes que no requieran de la

aprobación del negocio
Se requiere tecnología de ITSM integrada con la siguiente funcionalidad:

 Capacidades de registro de incidentes que permitan la captura eficiente de datos de
incidentes, categorización, priorización, rastreo y reporte de incidentes
 Un CMS integral que permita hacer y mantener relaciones de forma automatizada entre
los incidentes, solicitudes de servicio, problemas, errores conocidos, soluciones
temporales y otros CIs.
 El CMS que pueda ser usado para asistir en determinar la prioridad y ayudar en la
investigación y diagnóstico
 Un motor de flujo de proceso para permitir que los procesos sean predefinidos
(incluyendo modelos predefinidos de incidentes) y controlados automáticamente – con un
ruteo interno flexible hacia todos los grupos de soporte relevantes e interfaces externas
(ej.: correo electrónico) – usando tiempos objetivo para automatizar el control del flujo
de trabajo y las rutas de escalación
 Capacidades de alerta y escalación automatizadas para prevenir que un incidente sea
pasado por alto o se retrase
 Interface abierta con herramientas de Gestión de Eventos, para que cualquier falla
pueda ser automáticamente levantada como incidente
 Una interface web que ofrezca auto ayuda y permita la captura de solicitudes de servicio
a través de pantallas de internet/intranet
139
 Una KEDB integrada para que los incidentes/problemas diagnosticados y/o resueltos
puedan ser registrados y consultados para ayudar a comunicar soluciones de incidentes
futuras
 Características de reporte de fácil utilización para permitir la generación de métricas de
incidentes y con el propósito de facilitar el análisis de incidentes Gestión de Problemas y
Gestión de la Disponibilidad
 Herramientas de diagnóstico (ya sea integradas o interfaces con productos separados),
como se mencionó dentro de Service Desk
 Capacidades de reporte que permitan un acceso eficiente al historial de incidentes y
sintetice los incidentes por categoría, prioridad, estatus (ej.: abierto, cerrado, en
progreso, etc.), CIs impactados, u otros medios para proporcionar datos y soporte para
las actividades reactivas y proactivas de Gestión de Problemas
Solución Automatizada de Incidentes/Problemas

Existen muchos productos en el mercado que soportan la automatización de los procesos
manuales tradicionales, laboriosos o en los que fácilmente se puede fallar, para el
descubrimiento y resolución de incidentes y problemas. Al utilizar datos provenientes de
monitores de detección proactiva, cualquier caída en un componente o servicio genera una
alerta que automáticamente dispara procedimientos de diagnóstico y reparación. Entonces,
estos procedimientos identifican la causa raíz y resuelven la situación usando técnicas pre-
programadas o scripts de auto corrección, reduciendo el MTRS de muchas causas comunes de
incidentes y en algunos casos, previniendo completamente caídas del servicio. Estas
herramientas también pueden documentar información relacionada con auditorías dentro del
registro de incidente o problema para su análisis futuro y la identificación de otras
oportunidades de CSI proactivas potenciales.
140
Retos
Los siguientes retos existirán para lograr una Gestión de Incidentes exitosa
 La capacidad de detectar incidentes tan pronto como sea posible. Esto requerirá de la
configuración de herramientas de Gestión de Eventos, la educación de los usuarios para
reportar los incidentes, y el uso de grupos especializados de Service Desk (ver sección
6.3.3.5)
 Convencer a todo el personal (equipos técnicos así como usuarios) de que los incidentes
deben ser registrados y empujar el uso de capacidades de auto ayuda bajo ambiente web
(que pueden agilizar la ayuda y reducir el requerimiento de recursos)
 Disponibilidad de información sobre problemas y errores conocidos. Esto permitirá al
personal de Gestión de Incidentes aprender sobre incidentes previos y también dar
seguimiento al estatus de las soluciones.
 Integración en el CMS para determinar las relaciones entre los CIs y referirse al
historial de los CIs cuando se lleve a cabo el soporte de primera línea
 Integración en el proceso de SLM. Esto ayudará a Gestión de Incidentes a evaluar
correctamente el impacto y la prioridad de los incidentes y ayudar a definir y ejecutar
procesos de escalación. SLM también se beneficiará de la información obtenida durante
Gestión de Incidentes, por ejemplo, al determinar si los objetivos de desempeño del nivel
de servicio son realistas y alcanzables
141
Riesgos
Los riesgos para una Gestión de Incidentes exitosa son en realidad similares a algunos de los
retos y lo opuesto a algunos de los CSFs mencionados anteriormente. Incluyen:
 Ser inundados con incidentes que no puedan ser manejados dentro de las escalas de
tiempo aceptables debido a la falta de recursos disponibles o adecuadamente
capacitados
 Generación no intencional de una fila incidentes pendientes creados por herramientas de
soporte no adecuadas para generan alertas y solicitar progreso
 Falta de fuentes de información adecuadas y/o oportunas debido a herramientas
inapropiadas o a la falta de integración
 Discordancia entre los objetivos o las acciones debido a OLA y/o UCs mal alineados o
inexistentes
142
Gestión de Problemas
143
Objetivos
 Mantener la satisfacción del usuario y el cliente a través de un manejo eficiente y
profesional de todos los requerimientos de servicio.
 Proveer un canal para los usuarios para requerir y recibir los servicios estándar que
tienen una autorización predefinida y procesos de calificación existentes
 Proveer información a los usuarios y clientes acerca de la disponibilidad de los servicios
y el procedimiento para poder obtener estos.
 Fuente y entrega de componentes para atender requerimientos estándar de los servicios
(Ej. Licencias o Software)
 Asistir con información general, quejas y comentarios
144
Los procesos necesarios para atender un requerimientos varían dependiendo de lo que se está
solicitando pero por lo general deben dividirse en un conjunto de actividades que deben ser
ejecutadas. Para cada requerimiento las actividades deber ser documentadas en un modelo de
atención de requerimientos y almacenadas en el SKMS.
Es una decisión organizacional el cómo manejar los requerimientos de servicio. Algunas

organizaciones pueden decidir incorporar requerimientos de servicio dentro del proceso de
Administración de Incidentes (en la herramienta) categorizado como solicitud. Organizaciones
con un alto volumen de requerimientos de servicio pueden decidir direccionar estos
requerimientos a un grupo separado de trabajo.
Nota: Tenga en cuenta que en última instancia le corresponderá a cada organización decidir y
documentar las solicitudes de servicio que se manejan a través del proceso de Cumplimiento de
Solicitudes y que tendrá que pasar a través de otros procesos, como el Proceso de
Administración del Negocio para enviar las solicitudes de servicios nuevos o modificados.
Habrá siempre ciertas circunstancias que impidan una aplicación genérica del proceso.
145
146
Modelos de Requerimientos
Algunos requerimientos de servicio pueden ocurrir con frecuencia y requerirán un manejo
consistente para alcanzar los niveles de servicio. Para facilitar esto, muchas organizaciones
crean modelos de requerimientos predefinidos (pueden incluir uno o más cambios estándar para
completar las actividades del requerimiento). Este es un concepto similar a los modelos de
incidentes descritos en el proceso de Gestión de Incidentes, pero aplicado a los requerimientos
de servicio.
Selección de Menú
El cumplimiento de solicitudes ofrece la oportunidad para aplicar prácticas de auto ayuda,
donde los usuarios pueden generar un requerimiento de servicio usando tecnología. Idealmente
los usuarios tienen un menú tipo selección vía web o un portal de requerimientos donde ellos
pueden seleccionar los detalles del requerimiento de servicio de una lista predefinida. De esta
manera, las expectativas apropiadas pueden ser fijadas por medio de objetivos / fechas de
entrega y / o implementación (en línea con los objetivos del SLA).
Herramientas web especializadas para ofrecer este tipo de servicio, pueden ser utilizadas
siempre con una interfaz directa con las herramientas para la gestión de los servicios de TI.
Seguimiento del estado de los requerimientos

Los requerimientos deben tener un seguimiento a través de su ciclo de vida para soportar el
manejo y el reporte del estado de los requerimientos. Con los sistemas para el manejo de
requerimientos los códigos de los estados pueden ser vinculados para indicar donde están en
relación a su ciclo de vida. Ejemplo de esto e pueden ser:
147
 Proyecto: Un requerimiento es creado en el estado de proyecto. Esto puede ser usado

para registrar un requerimiento que no va a ser manejado por el proceso de
Cumplimiento de Solicitudes.
 En revisión: Requerimientos que deben ser autorizados y están bajo revisión para que se
puedan llevar a cabo las actividades del requerimiento.
 Suspendido: El requerimiento ha sido suspendido.
 Esperando por autorización: El requerimiento ha sido enviado para su autorización
 Rechazado: El requerimiento ha sido rechazado
 Cancelado: El requerimiento ya no es requerido por el usuario
 En progreso: El requerimiento está en proceso para ser atendido
 Completado: El requerimiento ha sido atendido.
 Cerrado: El usuario está de acuerdo con que el requerimiento ha sido atendido y el
requerimiento ha sido cerrado.
Priorización de requerimientos
Todos los requerimientos de servicio deben seguir un criterio para la asignación de la
prioridad. Ver la siguiente sección.
Escalar Requerimientos
En algunos casos, puede ser necesario escalar los requerimientos para resolver ciertas
situaciones o tomar futuras acciones que pueden no ser parte del conjunto de actividades
estándares para el cumplimiento del requerimiento.
• Un requerimiento fue enviado a una función incorrecta
• El SLA para el cumplimiento de la solicitud puede estar en peligro de no cumplirse
• Un usuario no está de acuerdo en que la solicitud se ha cumplido a su entera
satisfacción
• La solicitud se ha usado en lugar de un requisito más complicado
Aprobación Financiera
Un paso extra importante que es probable sea necesario cuando se trata de un requerimiento es
la aprobación financiera.
La mayoría de las peticiones tendrán algún tipo de consecuencias financieras,
independientemente del tipo de acuerdos comerciales vigentes. El costo de satisfacer la solicitud
de servicio se debe establecer primero. Puede ser posible acordar precios fijos para
'requerimientos estándar' y la aprobación previa de las mismas puede ser parte del de la
Gestión financiera anual de la Compañía. En todos los demás casos, una estimación de los
costos debe ser elaborado y presentado al usuario para su aprobación financiera (el usuario
puede tener que buscar la aprobación a su Gerencia / Canal financiero). Si la aprobación se
da, además de cumplir con la solicitud, el proceso también debe incluir el cargo (facturación o
cruce de cargos) por el trabajo realizado - si el cargo tiene lugar.
Otras Aprobaciones
En algunos casos aprobaciones adicionales pueden ser requeridas, tales como cumplimiento o
aprobación del negocio. El proceso de Cumplimiento de Solicitudes debe tener la habilidad para
definir y checar las aprobaciones cuando sean necesarias. Los procedimientos para obtener
148
aprobaciones deben ser incluidos como parte de los modelos para la atención de
requerimientos, para ahorrar tiempo en el procesamiento de la solicitud.
Coordinación del cumplimiento de actividades.

El cumplimiento real dependerá de la naturaleza de la solicitud de servicio. Algunas solicitudes
más simples pueden ser completadas por el Service Desk, en su rol de primera línea de soporte,
mientras que otras tendrán que ser enviadas a grupos de especialistas y / o proveedores
requeridos para su cumplimiento.
Algunas organizaciones pueden tener grupos especializados de cumplimiento (para "recoger,

empacar y despachar ') o puede tener subcontratadas algunas actividades con un proveedor
externo (s). El Service Desk debe vigila, seguir el progreso y mantener informados a los
usuarios.
Cierre
Cuando un requerimiento de servicio es cumplido este debe ser referido al Service Desk para su
cierre. El Service Desk debe a través del cierre checar la satisfacción del usuario con la
solución brindada.
149
Actividades de Cumplimiento de
Recepción de solicitud
Solicitudes
Hacia Gestión
Service ¿Es realmente de incidentes o
Desk No hacia Gestión
una solicitud
RFC de servicio? del Portafolio de
Correo Servicios si es
Interfaz web una propuesta
Si de cambio
Rgistro de la
solicitud
No Regreso a
¿Es válida? solicitante
Si
Categorización
de la solicitud
Priorización de
la solicitud
Gestión de
acceso
Autorización de
la solicitud
Gestión
Financiera
¿Sol Aut.? No Regreso a

solicitante
Yes
Revisión de
solicitud
Si
¿Escalar?
Escalación No
funcional
Ejecutar modelo de
solicitud
¿Cambio Si
a CI?
No Gestión de
Cambios
Regreso a No
solicitante Cumplida?
Si
Gestión
Cierre de
Financiera
solicitud
© Crown copyright 2011 Reproduced under license
from the Cabinet Office. Figure 4.6 Service Fin
Operation 4.3.5
150
Recibir la Solicitud
El trabajo no se iniciará hasta que una solicitud formal sea recibida. Las peticiones son
normalmente a través del Service Desk, pero puede venir de un RFC o vía web. Las plantillas
estándar se deben utilizar para capturar la información obligatoria de la solicitud. La solicitud
debe ser revisada para asegurar que sean relevantes y no un incidente si éste es el caso será
cerrado y el registro de un incidente iniciado.
Registro y validación de Solicitudes

Todas los requerimientos de servicio deben ser registras al igual que la fecha y hora,
independiente de como hayan sido solicitados.
Toda la información relevante relacionada a la naturaleza del requerimiento debe ser registrada
así como mantener un historial completo, de tal manera que si el requerimiento fue referido a
otro grupo de soporte, ellos tendrán la información relevante para poder atender el mismo
La información necesaria para un requerimiento de servicio se describe a continuación:
 Único número de referencia

 Categorización del requerimiento (a menudo se divide en sub-categorías, incluyendo el
servicio del requerimiento que está pidiendo)
 Urgencia, Impacto y Priorización del requerimiento
 Fecha y Hora de registro
 Nombre/Código de la persona y/o grupo que está haciendo el requerimiento
 Método de notificación (teléfono, interface Web, RFC, email, personal etc.)
 Nombre/Área/Teléfono/Ubicación del usuario
 Centro de costos en caso de tener un cargo asociado
 Método para regresar la llamada
 Descripción del requerimiento
 Estatus del requerimiento (en progreso, esperando autorización, cerrado etc.)
 CIs relacionados
 Grupo o persona de soporte que tomara el requerimiento de servicio
 Hora y Fecha de cumplimiento
 Hora y Fecha de Cierre
Si el Service Desk no está disponible (la responsabilidad del registro puede recaer en otras áreas
por ejemplo Operaciones). En este caso estos grupos necesitan ser capacitados en cómo manejar
los requerimientos de servicio.
Requerimiento y que este se encuentre en el alcance de los servicios de TI ofrecidos. Las

herramientas para la automatización del catálogo de servicios pueden incluir características que
ayuden en la publicación de servicios y que estos sean accesibles a los usuarios. Estas
herramientas aseguran que la fuente de los requerimientos es válida y que solo tipos validos de
requerimientos son solicitados. Adicionalmente los pasos para la autorización puede ser
automatizada a través de estas herramientas.
151
Categorización de Solicitudes
Parte del registro inicial debe ser colocar un código de categoría que especifique el
requerimiento que se está registrado. Esto puede ser importante después cuando se deseen ver
los tipos/ frecuencias para establecer tendencias y determinar cómo los servicios están siendo
usados y cuales requerimientos son los más frecuentes
Ejemplos de categorías pueden incluir:

 Por servicio: Categorizar los requerimientos por el servicio del que hace parte, Por
ejemplo: Establecer una nueva cuenta de mail puede ser parte del servicio de correo
 Por actividad: Categorizar los requerimientos por tipo de actividad que se está
haciendo. Por ejemplo: Reseteo de password, instalación de máquinas, remplazo de
cartucho de impresora.
 Por tipo: Categorizar el requerimiento por tipo de requerimiento, tales como
requerimiento de información versus cambio estándar
 Por función: Categorizar el requerimiento por la función que será usada para cumplir el
requerimiento
Priorización de Solicitudes
Otro aspecto importante de registrar los requerimientos es acordar un código de priorización,
así como determinar cómo los servicios serán direccionados por la herramienta de soporte y al
Staff de soporte.
La priorización puede normalmente ser determinada tomando en cuenta la urgencia del

requerimiento (que tan rápido el negocio necesita que sea atendido) y el nivel de impacto que
este puede causar. Los factores que pueden contribuir al impacto son:
 El número de servicios impactados por el cumplimento de las actividades

 El número de usuarios o unidades de negocio impactadas para el cumplimiento de las
actividades
 Si el solicitante está en un nivel ejecutivo de la empresa o una función de nivel
administrativo más bajo
 El nivel de ganancia o pérdida financiera si la petición se cumple o no cumple
 Efecto sobre la reputación de la empresa si la petición no se cumple
 Multas regulatorias o legislativas o sanciones si la petición no se cumple
Algunas organizaciones pueden también reconocer usuarios Vips, los cuales deben ser
manejados como de alta prioridad. Pero en algunos casos estos son los mejores atendidos y
documentados, sin embargo esto debiera ser aplicado para todo lo reportado al Service Desk.
Autorización de Solicitudes
El trabajo no debe tomar lugar si el requerimiento de servicio no ha sido propiamente
autorizado. Una autorización simple puede ser hecha vía el Service Desk o pueden existir pre-
autorizaciones basadas en tipos de requerimientos. En algunos casos , una autorización más
rigurosa puede necesitar de otro tipo de fuentes antes que el trabajo pueda ser realizado, tales
como del proceso de Gestión de Accesos para determinar cuando el requerimiento es
152
autorizado realmente para ser llevado a cabo o la Gestión financiera para autorizar cualquier
costo asociado con el cumplimiento del requerimiento.
Un requerimiento de servicio que no fue autorizado debe ser regresado explicando la razón del
rechazo y el registro del requerimiento debe ser actualizado con el estado actual.
Revisión de Solicitudes
En este estado, el requerimiento es revisado para determinar la función apropiada que va a
cumplir este. En muchos casos el Service Desk puede ejecutar todo lo necesario para cumplir las
actividades (por ejemplo cumplir un requerimiento de información). En otros casos el
requerimiento puede ser escalado a otra función que ejecute actividades especializadas para el
cumplimiento de este. Cuando un requerimiento es revisado, escalado y trabajado el registro de
este debe ser actualizado para reflejar el estado actual.
Herramientas automatizadas pueden ser usadas para capturar, registrar, analizar y ejecutar los
requerimientos sin las intervención humana. Un ejemplo puede ser cuando los usuarios pueden
utilizar herramientas de self- service que automáticamente reseteen el password de las cuentas
de usuarios o solicitar equipos tales como teléfonos celulares.
Ejecución del Modelo de Solicitudes

Una función puede tener asignadas actividades para cumplir los requerimientos, un modelo de
requerimiento puede ser usado para documentar un flujo estándar de un proceso, roles,
responsabilidades para cumplir el requerimiento. Esto asegura que se tiene un conjunto de
actividades que son repetibles y consistentes y que para ciertos tipo de requerimiento siempre se
seguirán, minimizando el riesgo de retrasos o fallas en el cumplimientos del requerimiento.
Los modelos de requerimientos pueden ser descritos como pasos de un proceso y actividades y
estos pueden ser:
 Almacenados como documentos de referencia que pueden ser accesados como parte del
SKMS.
 Almacenados a través de configuraciones especializadas con herramientas de Work Flow
Automatizadas
 Almacenadas a través de códigos y configuraciones como parte de las soluciones de auto
ayuda basadas en Web
Un requerimiento de servicio que impacta a los CIs, en el ambiente de producción debe ser
autorizado a través del proceso de Gestión de Cambios. En muchos casos esto pueden ser
cambios estándar. El uso de estos asegura que la gestión del cambio se mantiene al tanto de
todos los cambios que han tenido lugar así como los provocados por el cumplimiento de un
requerimiento de servicio.
Cierre de Solicitudes
Una vez que el requerimiento de servicio ha sido completado, el Service Desk debe ser
notificado. Este debe checar que el requerimiento haya sido cumplido y que los usuarios están
satisfechos y están de acuerdo con que el requerimiento sea cerrado. El service Desk debe
checar lo siguiente:
153

Requerimientos Financieros: La Gestión Financiera puede necesitar ser notificada de
cualquier costo incurrido para cumplir las actividades del requerimiento o si el
requerimiento requiere ser facturado.
 Categorización de cierre: Checar y confirmar que la categorización fue la correcta o
donde la categorización resultó ser incorrecta, actualizar el registro con la
categorización correcta (buscar la orientación del grupo(s) de solución según sea
necesario)
 Encuesta de satisfacción: Enviar la encuesta de satisfacción mediante una llamada o vía
email de un porcentaje acordado de los requerimientos
 Documentación del requerimiento: Darle un seguimiento a los detalles pendientes y
garantizar que el registro de la solicitud esté plenamente documentado, de manera que el
registro histórico tiene en un nivel suficiente de detalle y está completo
 Cierre Formal: Cerrar formalmente el registro del requerimiento
Reglas para reabrir una Solicitud
Las reglas sobre como reabrir un requerimiento necesitan ser predefinidas considerando el
impacto sobre el seguimiento y reporteo.
154
Disparadores
La mayoría de los requerimientos son disparados por los usuarios mediante una llamada al
Service Desk o mediante herramientas de auto ayuda basadas en Web. Este último suele
implicar la selección de un listado de tipos de solicitudes disponibles
Entradas
Ejemplos de entradas al proceso pueden incluir:
 Ordenes de trabajo
 Formatos de autorización
 Requerimientos de servicio
 RFCs
 Requerimientos desde diferentes fuentes tales como llamadas telefónicas, interfaces WEB
o correo electrónico
 Requerimientos de información
Salidas
Ejemplos de salidas del proceso pueden ser:
 Requerimientos de servicio autorizados o rechazados
 Reportes de estado
 Requerimientos atendidos
 Incidentes ( reenrutados)
 RFC / Cambios estándar
 Actualización de Activos / CIs
 Requerimientos cerrados
 Requerimientos cancelados
155
156
Ejemplo de Factores Críticos de Éxito e Indicadores Clave de desempeño

Las solicitudes se deben cumplir de manera  El tiempo promedio para el manejo de
eficiente y oportuna y deben estar alineadas cada tipo de solicitud de servicio
con los objetivos de nivel de servicio  El número y porcentaje de solicitudes de
acordados para cada tipo de solicitud servicio atendidas dentro de los niveles de
servicio acordados
 Desglose de las solicitudes de servicio en
cada estado (por ejemplo, registrada, en
curso, cerrada, etc.)
 Porcentaje de solicitudes de servicio
cerradas por el Service Desk
 Número y porcentaje de solicitudes de
servicio resuelta de manera remota o
mediante herramientas automáticas, sin la
necesidad de soporte en sitio
 El número total de peticiones (como
medida de control)
 El costo promedio por tipo de solicitud de
servicio
Solo las solicitudes de servicio autorizadas  Porcentaje de solicitudes de servicio
deben ser atendidas atendidas que fueron autorizadas
apropiadamente
 Número de incidentes relacionados con
amenazas de seguridad que recaen en
Se debe mantener la satisfacción del usuario  Nivel de satisfacción del usuario con
respecto a las solicitudes de servicio )
medido a través de una encuesta de
satisfacción)
 Número total de incidentes relacionados
con las actividades de las solicitudes de
servicio
 El tamaño de los backlog de las solicitudes
de servicio.
157
Estrategia del Servicio

 Gestión financiera para TI: Puede ser necesaria una interfaz con este proceso si los cosos
para el cumplimiento de las solicitudes de servicio necesitan ser reportadas o recuperadas.

 Gestión del Catálogo de Servicios: Este proceso debe estar estrechamente ligado con el
cumplimiento de solicitudes para asegurar que las solicitudes disponibles con comunicadas
al usuario y vinculadas en el Catálogo de Servicio. Los cambios para solicitudes
disponibles deben estar sincronizados con la Gestión del Catálogo de servicios
158
 Gestión de liberación e implementación: Algunas solicitudes podrían ser acerca de

implementar nuevos componentes o actualizaciones a estos, que pueden ser liberadas de
manera automática. En algunos casos una liberación puede ser predefinida, construida y
probada pero solo será desplegada a petición de aquellos que quieren la 'liberación'
 Gestión de activos del servicio y configuraciones: Después del despliegue, el CMS tendrá
que ser actualizado para reflejar los cambios que se hayan realizado como parte de las
actividades de la solicitud. La información del ciclo de vida de los Activos, las etiquetas
de activos y otra información relacionada puede también ser necesario actualizarla como
parte de las actividades que involucran movimientos, altas o cambios en los activos del
servicio. Revisiones y actualizaciones referentes a Licencias de Software también pueden
ser necesarias
 Gestión del Cambio: Cuando un cambio es requerido para cumplir una solicitud, podría ser
necesario registrar un RFC y ser gestionado a través del proceso de Gestión de Cambios

 Gestión de Incidentes y Problemas: Algunas solicitudes de servicio pueden ser solicitados
vía el Service Desk, y pueden ser inicialmente direccionados a través del Proceso de
Gestión de Incidentes. Algunas organizaciones pueden definir que todas las solicitudes de
servicio serán manejadas de esta manera, pero otras pueden escoger tener procesos
separados, por razones ya discutidas anteriormente en este capítulo.
 Gestión de Accesos: Este proceso puede ser involucrado dentro de las actividades del
cumplimiento de solicitudes para asegurar que están autorizadas y son de conformidad con
la política de seguridad de la información. Además, la salida del proceso de cumplimiento de
solicitudes puede producir información o resultados útiles para la Gestión de Accesos
159
160
Los siguientes cambios deben darse para que el Cumplimiento de Solicitudes sea exitoso:
 Deben estar claramente definidos y documentados los tipos de solicitudes que van a ser
manejados mediante el proceso del cumplimiento de solicitudes (y aquellos que serán
recibidos por el Service Desk y serán manejados como incidentes o los que tendrá que ir
a través de la gestión del cambio ), así todas las partes tendrán absolutamente claro el
alcance
 Establecer herramientas de auto ayuda, las cuales permiten a los usuarios interactuar
con éxito en el proceso de Cumplimiento de solicitudes. Estas herramientas pueden
proporcionar una interfaz eficiente para los usuarios. Es esencial que estas se integren
con las herramientas usadas para gestionar los incidentes y/o los Cambios
 Los objetivos de niveles de servicio necesitan ser acordados y comunicados por cada tipo
de requerimiento. Establecer objetivos puede ser más complicado cuando se consideran
varios tipos de usuarios, así como VIPs, Ejecutivos y staff administrativo.
 Los costos para atender las solicitudes deben ser acordados. Esto puede ser parte del
proceso de Gestión de Niveles de Servicio. Cualquier variación de los servicios también
debe tener en cuenta la variación de costos que se identifiquen
 Los acuerdos deben incluir quienes son los autorizados para pedir los requerimientos.
También se debe tener en cuenta los resultados de las solicitudes de servicio para
asegurarse de que no violen la política de seguridad de la información. Un ejemplo de
esto podría ser una actividad para cumplir una solicitud relacionada con información
confidencial, como los datos financieros de los clientes
 La información acerca de las solicitudes debe estar disponible y de fácil acceso. Esto
implica que las solicitudes de servicio disponibles son publicadas a los usuarios como
parte del Catálogo de Servicios. Es importante que esta parte del Catálogo de Servicios
161
sea de fácil acceso, y debe ser reconocida como la primera fuente de información que los
usuarios tienen para acceder a un servicio.
 Las solicitudes necesitan seguir un procedimiento estándar. Esto implica que se debe
documentar y comunicar un modelo de solicitud para cada servicio que sea solicitado.
Esto debe incluir todos los procedimientos, políticas, roles y responsabilidades, así como
las funciones que serán asignadas para ejecutar el modelo y la habilidad para generar
órdenes de compra u órdenes de trabajo.
 El cumplimiento de las solicitudes tiene un alto impacto en la satisfacción del usuario.
Los requerimientos que son manejados incorrectamente o no se tratan a tiempo
proyectan una mala imagen de TI y su capacidad para hacer las cosas. Por lo tanto, se
debe mantener una gran atención a la satisfacción del usuario. Esto implica que las
solicitudes de servicio deben ser atendidas en tiempo y forma. Se debe realizar una
retroalimentación permanente con el fin de monitorear la satisfacción del usuario con
respecto a la gestión de las solicitudes.
Riesgos
Los riesgos que pueden encontrarse en el Cumplimiento de Solicitudes son los siguientes:
 Una definición pobre del alcance, donde la gente no tiene claro cuál es el proceso para a
Gestión de Solicitudes
 Pobre definición o implementación de interfaces para el usuarios, lo que puede hacer
que sea difícil levantar las solicitudes que ellos requieren.
 Procesos de cumplimiento de back-end mal diseñados u operados, que son incapaces de
lidiar con el volumen o naturaleza de las peticiones que se hacen.
 Capacidades de monitoreo inadecuados por que las métricas exactas no pueden ser
obtenidas.
162
163
164
Alcance
La Gestión de Problemas incluye las actividades requeridas para diagnosticar la causa raíz de
los incidentes y determinar la solución para los problemas. También es responsable de asegurar
que la solución es implementada a través de los procedimientos establecidos, especialmente el
de Gestión de Cambios y Gestión de Liberaciones e Implementaciones
La Gestión de Problemas mantiene la información acerca de los problemas, las soluciones

temporales y definitivas, por lo que TI es capaz de reducir el número y el impacto de los
incidentes. Con respecto a esto la Gestión de problemas tiene una interfaz importante con la
Gestión del Conocimiento y usa herramientas tales como la KEDB que es usada por ambos
procesos.
La Gestión de Incidentes y de Problemas , son procesos separados, los cuales están

estrechamente relacionados y usualmente utilizan las mismas herramientas, así como la
categorización, impacto y prioridad pueden ser los mismos para estos procesos. Esto asegurará
una comunicación eficaz cuando se trata de incidentes y problemas relacionados.
165
La gestión de problemas tiene los dos aspectos, reactivo y proactivo:

 En su parte reactiva las actividades de la Gestión de problemas son ejecutadas como
reacción a un incidente, la parte proactiva toma lugar cuando se busca mejorar la
disponibilidad o las satisfacción del usuario con respecto a los servicios de TI. Los
ejemplos de Gestión de Problemas proactiva pueden incluir llevar a cabo revisiones
periódicas de los registros de los incidentes para encontrar patrones y tendencias
que pueden indicar la presencia de una error en la infraestructura
 Conducir revisión de incidentes mayores en donde se busca: ¿Cómo puede ser
prevenida la recurrencia? , mediante la identificación de la Causa raíz.
 Llevar a cabo revisiones periódicas programadas de los Logs y los registros de
mantenimiento, identificar patrones y tendencias de las actividades que pueden
indicar que existe un problema
 Llevar a cabo revisiones periódicas programadas de los registros de eventos y
detectar patrones y tendencias de los sucesos de advertencia y de excepciones que
pueden indicar la presencia de un problema
 Llevar a cabo sesiones de lluvia de ideas para identificar las tendencias que podrían
indicar la existencia de problemas
 Uso de hojas de verificación para recoger de manera proactiva los datos sobre los
problemas en la calidad del servicio que pueden ayudar a detectar problemas
166
Las actividades de la Gestión de problemas reactiva y proactiva son generalmente conducidas

en el alcance de la Operación del Servicio. Existe una estrecha relación entre la Gestión de
problemas proactiva y las actividades del Ciclo de Mejora continua del Servicio, quien soporta
la identificación e implementación de las mejoras en el Servicio. La Gestión de Problemas
Proactiva apoya esas actividades a través de análisis de tendencias y la focalización en la
acción preventiva. Los Problemas identificados serán entregados al Proceso de Mejora
Continua quien registra y gestiona las oportunidades de mejora.
 Mayor disponibilidad de servicios de TI mediante la reducción del número y la duración

de los incidentes que pueden presentarse. La Gestión de Problemas trabaja en conjunto
con la Gestión de Incidentes y Gestión del Cambio para asegurarse de que la
disponibilidad y calidad de servicio se incrementen. Cuando se resuelven los incidentes,
la información acerca de la resolución es registrada. Con el tiempo, esta información se
utiliza para acelerar el tiempo de resolución y encontrar soluciones permanentes,
reduciendo el número y el tiempo de resolución de los incidentes.
 Mayor productividad del personal de TI mediante la reducción de mano de obra
utilizada por resolver incidentes y la creación de la habilidad para resolver con mayor
rapidez a través de los errores conocidos y soluciones registradas.
 Reducción del gasto en soluciones temporales o parches que no funcionan
 Reducción en el costo del esfuerzo que implica la atención de incidentes repetidos
167
Políticas
Ejemplos de políticas de Gestión de Problemas pudieran ser:
 Los problemas deben ser manejados por separado de los incidentes. Esto
proporcionará una separación clara entre muchas actividades dela Gestión de
problemas que son proactivas y actividades de Gestión de Incidentes que son en su
mayoría reactivas. Esto implica que se deben tener las habilidades tecnológicas para
gestionar problemas por separado de los incidentes
 Todos los problemas deben ser almacenados y administrados en un único sistema de
gestión. Esto proporciona una fuente reconocida de la información y ayuda a que
los esfuerzos involucrados en la investigación y generación de reportes sean
menores. Esto implica que se deben garantizar los registros de Gestión de problemas.
Tecnologías de apoyo deben estar bien integradas con el negocio y deben existir
interfaces a otras tecnologías que apoyan la gestión de servicios
 Todos los problemas deben utilizar un esquema de clasificación estándar que sea
coherente en toda la empresa. Esto proporciona un acceso más rápido al problema y
la información dela investigación del mismo. Ofrece un mejor soporte para el
diagnóstico y actividades proactivas del proceso. Esto implica una clasificación de
categorías bien definida y comunicada oportunamente
168
Actividades de Gestión de problemas Reactivo y Proactivo:

Las actividades reactivas y proactivas de la Gestión de Problemas buscan encontrar problemas,
y gestionar estos a través del proceso de Gestión de Problemas, encontrar la causa raíz de los
incidentes asociados y prevenir futuras recurrencias de estos. La diferencia entre Gestión de
Problemas reactiva y proactiva radica en cómo se dispara el proceso de Gestión de Problemas:
 La Gestión de problemas reactiva es disparada como reacción a un incidente que
tomo lugar. Las actividades de la Gestión de problemas reactiva complementan las
actividades de Gestión de Incidentes, por enfocarse en la causa raíz de un incidente,
para prevenir recurrencias e identificar las soluciones temporales cuando es
necesario.
 La Gestión de problemas proactiva es disparada por las actividades que buscan
mejorar los servicios. Un ejemplo pueden ser las actividades de análisis de
tendencias para encontrar la causa raíz de un historial de incidentes y prevenir su
recurrencia. La gestión de problemas proactiva complementa la Mejora continua de
los servicios ayudando identificar soluciones temporales y mejoras que pueden
ayudar a incrementar la calidad del servicio
Enfocar los esfuerzos en prevenir incidentes, ayuda a proporcionar un mejor servicio a los
clientes y hacer un uso más eficaz de los recursos disponibles dentro de la organización de TI.
169
Modelos de Problemas
Muchos de los problemas pueden ser únicos, pero algunos pueden ser el resultado de los
problemas latentes en donde la solución permanente es vista como demasiado costosa y la
decisión pudiera ser "vivir" con la situación. Los registros de errores conocidos así como en
los modelos de Problema pueden ayudar al diagnóstico más rápido de algún problema.
Incidentes vs. Problemas

Un incidente es una interrupción no planeada a un Servicio de TI o la reducción en la calidad de
un servicio de TI. Un problema tiene una visión diferente de un incidente ya que busca
comprender la causa raíz, que puede ser también la causa de otros incidentes. Los incidentes
no 'se convierten en' problemas. Si bien las actividades de gestión de incidentes se centran en la
restauración de los servicios, las actividades de gestión de problemas se centran en encontrar
maneras de prevenir incidentes. Es bastante común tener incidentes que son también problemas.
Las reglas para invocar el proceso de la Gestión de problemas pueden variar y están a la
discreción de cada organización. Algunas situaciones generales donde se puede invocar Gestión
de Problemas pueden incluir situaciones en las que:
 La Gestión de Incidentes no puede ligar un incidente con los problemas existentes y

errores conocidos
 El análisis de tendencias de los incidentes registrados revela un problema que
podría existir
 Un Incidente mayor se ha producido y se requiere llevar a cabo las actividades de
gestión de problemas para identificar la causa raíz
 Otras funciones de TI identifican que existe un posible problema
 El Service Desk puede haber resuelto un incidente, pero no se ha determinado una
causa y sospecha que es probable que se repita
 Análisis de un incidente con un grupo de apoyo que revela la existencia de un
problema de fondo, o es probable que puedan existir
 Una notificación de un proveedor que existe un problema que debe resolverse
Detección de errores en el Ambiente de Desarrollo

Es probable que durante la prueba de nuevas aplicaciones, sistemas o liberaciones se le da
importancia a trabajar sobre los errores más graves, pero es posible que los errores de mejor
importancia no se corrijan - a menudo debido al balance que se busca tener entre, entregar la
nueva funcionalidad a la empresa tan pronto como sea posible y garantizar el código
totalmente libre de errores.
Cuando se toma la decisión de lanzar liberaciones al ambiente productivo que presentan errores
conocidos, estos deben ser registrados en la KEDB, junto con detalles de las soluciones
temporales o actividades de solución.
La experiencia ha demostrado que si esto no ocurre, se presenta un aumento en los costos de

soporte cuando los usuarios comienzan a experimentar las fallas y aumentan los incidentes que
tienen que ser re-diagnosticados y resueltos de nuevo.
170
Análisis Cronológico
Cuando se trata de un problema difícil, puede haber informes contradictorios sobre exactamente
lo que ha pasado y cuándo. Por lo tanto, es muy útil documentar todos los eventos en orden
cronológico, para proporcionar una cronología de los acontecimientos. Esto a menudo hace que
sea posible ver los eventos que pueden haber sido provocados por los demás - o para descartar
cualquier reclamo que no es compatible con la secuencia de los acontecimientos.
Análisis de Valor de Impacto

Se toma una visión más amplia del impacto de un incidente o problema, o tipo de incidente /
problema. En lugar de analizar el número de incidentes / problemas de un tipo determinado en
un período determinado, se realiza un análisis más a profundidad para determinar exactamente
qué nivel de dolor (impacto) fue causado a la organización / negocio por estos incidentes /
problemas. Normalmente, esto puede incluir tomar en cuenta:
 El número de personas afectadas

 La duración de la caída
 El costo para la empresa (si esto puede ser fácilmente calculado o estimado)
Tomando todos estos factores en cuenta, se puede obtener una imagen mucho más detallada de
los incidentes / problemas o tipos de incidentes / problemas que están causando más dolor, para
permitir una mejor atención a las cosas que realmente importan y merecen la más alta prioridad
a la hora determinar acciones de resolución.
171
Kepner & Tregoe

Charles Kepner and Benjamin Tregoe desarrollaron un camino para el análisis de problemas
que puede ser usado formalmente para investigar la causa raíz de los problemas. Ellos
definieron las siguientes etapas:
 Definir el problema
 Describir el problema en términos de identificación, ubicación , tiempo y tamaño
 Establecer posibles causas
 Probar la causa más probable
 Verificar la causa real
Lluvia de ideas
A menudo puede ser valioso reunir a las personas pertinentes, ya sea físicamente o por medios
electrónicos, y realizar 'lluvia de ideas' acerca del problema. Las personas dan ideas sobre lo
que puede ser la causa potencial y las posibles medidas para resolver el problema. Las sesiones
de lluvia de ideas puede ser muy constructivas e innovadoras, pero es igualmente importante
que alguien, tal vez el encargado del problema, documente los resultados y las acciones
acordadas y mantenga un grado de control en las sesiones.
5-Por qué
Este enfoque simple pero muy eficaz es útil como una forma de llegar a la causa raíz de un
problema. Su acción consiste en comenzar con una descripción de qué evento se llevó a cabo y
luego preguntar ¿por qué ocurrió esto? La respuesta resultante se da, seguido de otra ronda de
¿por qué ocurrió esto? Por lo general, en la quinta iteración, se habrá encontrado una causa
verdadera.
Aislamiento de fallas
Este enfoque implica la re-ejecución de las transacciones o eventos que han producido un
problema, de forma gradual, un CI a la vez, hasta que se identifique el CI que fallo. El esfuerzo
de re-ejecución se enfoca en el primer CI encontrado al inicio de la transacción o evento, y se
comprueba su correcto funcionamiento. El esfuerzo se desplaza a la siguiente CI en la cadena de
eventos, el próximo CI y luego el siguiente, hasta que se encuentre la falla .Si la falla no puede
ser recreada, una variación de esta técnica se puede intentar que implica indagar sobre el
estado saludable de los CI involucrados con la transacción o evento. Por ejemplo, si un CI se
considera como posible causa de la falla, el resto de las CI en la ruta de transacción no son
tratados para recrear la falla.
Mapeo de Afinidad
Esta técnica se puede utilizar para organizar grandes cantidades de información (ideas,
opiniones, problemas) en grupos basados en características comunes. Se realiza normalmente
en una sesión de lluvia de ideas con el personal clave. Conceptos clave, como las posibles
soluciones, se escriben en tarjetas individuales y se pegan en la pared o pizarra. Los
participantes y / o el facilitador deben mover las tarjetas y agruparlas. Se debe dar una idea o
frase que identifique cada grupo de las tarjetas. Cada una de los grupos de tarjetas deben ser
examinadas para identificar la causa raíz.
172
Prueba de hipótesis
Este método se puede utilizar para generar una lista de posibles causas raíz y luego determinar
si cada hipótesis es verdadera o falsa. Las hipótesis pueden estar relacionadas con las
potenciales causas raíz de un problema. Con la información obtenida de los incidentes y otra
información operativa, un equipo puede generar una lluvia de ideas y obtener una lista de
posibles causas que pueden estar relacionadas a los incidentes que se están estudiando. Cada
causa se convierte entonces en declaraciones comprobables o hipótesis y se le asigna a una o
más personas. Datos adicionales deben ser reunidos según sea necesario para cada declaración
y un análisis apropiado debe ser realizado para aceptar o rechazar cada hipótesis.
Puesto de Observación Técnica

En algunos casos, los problemas pueden estar relacionados con los incidentes que se producen
intermitentemente por razones o causas desconocidas. Este enfoque consiste en preestablecer
un grupo de personal especializado en el apoyo técnico de TI para enfocarse en un problema
específico. Su objetivo es verificar los eventos en tiempo real a medida que ocurren, con el
objetivo específico de la captura y la identificación de la situación específica y las posibles
causas del problema.
Diagramas Ishikawa
Kaoru Ishikawa (1915-1989), líder en el control de calidad japonés, desarrolló un método para
documentar las causas y los efectos que pueden ser útiles para ayudar a identificar donde algo
puede ir mal, o puede mejorar. Este diagrama es normalmente el resultado de una sesión de
lluvia de ideas, donde resuelven problemas. El objetivo principal está representado por el tronco
del diagrama, y los factores primarios están representados como ramas. Factores secundarios
se añaden entonces como tallos, y así sucesivamente. Crear el diagrama estimula la discusión y
a menudo conduce a una mayor comprensión de un problema complejo.
Análisis de Pareto
Esta es una técnica usada para separar las causas potenciales más importantes de las más
triviales.
173
La siguiente tabla puede ser útil en la identificación de los tipos de situaciones en las que cada
técnica puede ser utilizada.
Situación de los Problemas y las Técnicas más útiles para identificar la Causa Raíz
Situación del Problema Técnica de Análisis Sugerida

Problemas complejos en donde la secuencia Análisis Cronológico
de eventos necesitan ser estructurados para Observación Técnica
determinar exactamente qué está pasando
Incertidumbre sobre qué problemas deben Análisis de Valor del Impacto
abordarse primero Lluvia de Ideas
Incertidumbre si una de las causas que se 5 – Porqués
presenta es realmente la causa Prueba de Hipótesis
Problemas intermitentes que parecen ir y Observación Técnica
venir y no pueden ser recreados o repetidos Kepner-Tregoe
en un ambiente de pruebas Prueba de Hipótesis
Lluvia de Ideas
Incertidumbre sobre dónde empezar para los Análisis de Pareto
problemas que parecen tener múltiples Kepner-Tregoe
causas Diagrama de Ishikawa
Lluvia de Ideas
No se logra identificar el punto exacto de Aislamiento de fallas
falla de un problema Diagrama de Ishikawa
Kepner-Tregoe
Mapeo de afinidad
Lluvia de Ideas
Incertidumbre de dónde empezar cuando se 5 ¿Por qué?
trata de encontrar la causa raíz Kepner-Tregoe
Lluvia de Ideas
Mapeo de afinidad
© Crown Copyright 2011. Reproducido bajo licencia de ña Oficina del Gabinete. Tabla 4.2 Service Operation 4.4.4.3
174
Actividades de Gestión de Problemas

Service Gestión de Gestión de Gestión Proveedor o
Desk eventos incidentes proactiva de contratista
problemas
Detección del
problema
Registro del
problema
Categorización del
problema
categorization
Priorización del
problema
Investigación
CMS y diagnóstico
Gestión de Implementar Si ¿Solución

incidentes solucion temp. temporal?
No
Base de
Crear registro de datos de
error conocido (si errores
es necesario) conocidos
Gestión de Si
¿Se necesita
cambios RFC
cambio?
No
Resolución de
problema
No
¿Resuelto?
 Lecciones aprendidas
Si  Revisión del problema
Cierre del problema
SKMS
Si Revisión de
¿Problema
mayor? problema
No Mejoramiento
continuo del
Fin servicio
 Acciones de mejora
 Comunicaciones
175
Este es un gráfico simplificado para mostrar el flujo del proceso normal, pero en realidad
algunos de los estados pueden ser iterativos o puede tener variaciones con el fin de manejar las
situaciones particulares. Por ejemplo, las actividades de gestión proactiva de los problemas
pueden identificar nuevos registros de problemas que a su vez pueden llegar a ser de entrada a
este flujo.
Detección de Problemas
Es probable que múltiples maneras de detectar problemas existan en las organizaciones. Estos
pueden incluir factores que disparen la Gestión de Problemas reactiva y proactiva.
Disparadores de Gestión de Problemas reactiva:

 La sospecha o detección de la causa de uno o más incidentes por el Service Desk, lo que
resulta en un registro de problemas - la mesa puede haber resuelto el incidente, pero no
se ha determinado una causa y sospecha que es probable que se repita, lo que generará
levantar un registro de problema para que la causa raíz se resuelva. Puede ser obvio
desde el principio que un incidente o incidentes, ha sido causado por un problema grave,
por lo que se registrará un problema rápidamente.
 Análisis de un incidente por parte de un grupo de apoyo técnico, que revela la existencia
de un problema de fondo, o que es probable que exista
 Detección automática de una falla de la infraestructura o de la aplicación por medio de
herramientas de eventos / alerta, que pueden determinar automáticamente que se trata
de un incidente y esto puede disparar la necesidad de un registro de problema
 Una notificación de un proveedor o contratista acerca de que existe un problema que
tiene que resolverse
Disparadores de Gestión de Problemas Proactiva:

 Análisis de los incidentes que disparan la necesidad de solicitar un registro de problema
para que la causa raíz sea investigada más a fondo
 La tendencia de los registros históricos de los incidentes para identificar una o más
causas raíz, mismas que si son removidas se evitará que se repitan. En este caso, se
dispara la necesidad de registro de un problema.
 Actividades para mejorar la calidad de un servicio dan lugar a la necesidad de disparar
un registro de problema y así poder identificar futuras acciones de mejora que deberán
ser tomadas
Un análisis frecuente y regular de los datos de incidentes y problemas se debe realizar para
identificar las tendencias y entenderlas. Esto requerirá una categorización detallada de los
incidentes / problemas y de informes periódicos de los patrones y las áreas de alta incidencia.
Un Top ten de informes, con capacidades de búsquedas sencillas (Listas desplegables) a los
niveles inferiores, es útil para identificar tendencias.
Registro de Problemas
Todos los datos pertinentes deben ser capturados para permitir el control y la escalación en
caso de ser necesario.
176
Los Incidentes relacionados deben ser vinculados refiriéndose al problema, cuando sea
necesario todos los datos del registro del incidente deben ser copiados en el registro del
problema. Normalmente los datos pueden incluir:
 Datos del usuario

 Detalles del Servicio
 Detalles del equipo
 Fecha / hora de registro
 Prioridad y categorización
 Descripción del incidente
 Los números de registro de incidentes o de referencias cruzadas
 Los detalles de todas las acciones de recuperación o de diagnóstico intentadas
Categorización de Problemas
Los problemas deben ser clasificados en la misma forma que los incidentes (y es aconsejable
utilizar el mismo sistema de clasificación), de modo que la verdadera naturaleza del problema
se pueda rastrear fácilmente en el futuro y la información para gestionar se pueda obtener. Esto
también permite que los incidentes y los problemas sean más fácilmente vinculados.
Priorización de Problemas
Los problemas deben ser priorizados de la misma forma que los incidentes. La frecuencia y el
impacto de los incidentes relacionados también deben tenerse en cuenta. Una definición y
orientación clara deben ser proporcionadas para apoyar al personal sobre lo que constituye un
problema, y los objetivos de los servicios relacionados para cada prioridad.
La priorización de problemas también debe tener en cuenta la gravedad de los problemas. El

impacto en este contexto se refiere a que tan grave es el problema de un servicio o desde la
perspectiva del cliente, así como de la de infraestructura, por ejemplo:
 ¿Se puede recuperar el sistema, o necesita ser reemplazado?

 ¿Cuánto costará?
 ¿Cuántas personas y que habilidades, serán necesarias para solucionar el problema?
 ¿Cuánto tiempo se necesita para solucionar el problema?
 ¿Qué tan extenso es el problema (por ejemplo, número de entidades de crédito que se
ven afectadas)?
Investigación y Diagnóstico de Problemas

En esta etapa, la investigación debe llevarse a cabo para tratar de diagnosticar la causa raíz del
problema - la velocidad y la naturaleza de esta investigación variarán dependiendo del impacto,
la gravedad y urgencia del problema - debe tenerse el nivel adecuado de los recursos y
conocimientos en la búsqueda de una solución acorde con la prioridad y el objetivo de servicio
El CMS debe ser utilizado para ayudar a determinar el nivel de impacto e identificar y
diagnosticar el punto exacto de la falla. La KEDB también debe tener mecanismos para
vincular problemas parecidos (por ejemplo, búsquedas de palabras clave) y se debe utilizar
para ver si el problema se ha producido antes y, en caso afirmativo, para encontrar la solución.
177
A menudo es útil tratar de recrear el problema para comprender lo que fallo, y luego tratar
mediante diversas formas de encontrar la solución más adecuada y rentable. Puede ser posible
para volver a recrear el problema trabajar en un ambiente de pruebas que sea parecido al
ambiente de producción. Esto permite que las actividades de investigación y diagnóstico sean
eficaces sin causar más interrupciones para los usuarios.
Soluciones temporales
Las Soluciones temporales se utilizan como una forma temporal de mitigar los problemas que
se enfrentan, por ejemplo la intervención manual para permitir que un programa batch
termine. Una solución permanente aún debe ser trabajada por ejemplo, En el caso de que el
programa esta corrupto, ¿qué tenemos que hacer para asegurarse de que no vuelva a ocurrir?
Cuando se encuentra una solución temporal a un problema, lo que es importante es que el

registro del problema permanece abierto y los detalles de la solución deben ser documentados
en el registro del problema.
En algunos casos puede haber varias soluciones asociadas a un problema. Las actividades de
investigación y diagnóstico del problema continúan, puede haber una serie de mejoras que no
resuelven el problema, sino que conducen a una mejora progresiva de la calidad de las
soluciones disponibles. Estos pueden tener un impacto en la priorización y soluciones a los
sucesivos problemas y pueden reducir el impacto de futuros incidentes relacionados, ya sea
mediante la reducción de la probabilidad o la mejora en la velocidad de su resolución.
Creando un registro de Error Conocido

Un error conocido se define como un problema con una causa raíz documentada y una solución
temporal. El registro de error conocido debe tener referencia al problema relacionado y
documentar las medidas que se están tomando para resolver el problema, su causa y solución
temporal. Todos los registros de errores conocidos se deben almacenar en la KEDB.
Los registros de errores conocidos deben ser registrados con una solución temporal y / o
permanente, y pueden ser registrados en cualquier momento del proceso en general, incluso
antes de que el diagnóstico haya finalizado, esto con fines informativos para especificar una
solución aún sin confirmar.
Resolución de Problemas
Se refiera a una vez que la causa raíz se ha encontrado y desarrollado una solución que se debe
aplicar para resolver el problema. En realidad, pueden ser necesarias medidas de seguridad
para asegurarse de que la resolución no causa problemas adicionales. Si se requiere algún
cambio en la funcionalidad, un RFC debe ser levantado y autorizado antes de que la resolución
puede ser aplicada. Si el problema es muy grave y se necesita una solución urgente por razones
de negocios, entonces un RFC de emergencia debe ser levantado. La resolución se debe aplicar
sólo cuando el cambio ha sido autorizado y programado para su liberación. Mientras tanto, la
KEDB debe utilizarse para ayudar a resolver rápidamente cualquier otro incidente / problema
que se produzca
Puede haber algunos problemas para los cuales la resolución no puede ser justificada (por
ejemplo, donde el impacto es limitado, pero el costo de la resolución es muy alto). En estos
178
casos se puede tomar la decisión de cancelar el registro de problema y en el registro de errores

conocidos describir la solución con el fin de resolver cualquier recurrencia rápidamente. Se
debe tener cuidado de utilizar el código apropiado para marcar el registro de problemas de
modo que no cuente para el rendimiento del equipo que realiza el proceso y de modo que la
reanudación no autorizada no tenga lugar.
En algunos casos, las soluciones temporales son usadas para mitigar el impacto del problema
que no cuenta con una solución definitiva. En este caso, el problema se debe re priorizar basado
en el impacto de las soluciones aplicadas y se deben continuar las actividades de investigación y
de diagnóstico.
Cierre del Problema

Cuando se ha aplicado una solución definitiva, el registro del problema debe ser formalmente
cerrado - al igual que los registros de incidentes relacionados que aún están abiertos. Una
validación debe realizarse en este momento para garantizar que el registro contiene una
descripción histórica completa de todos los eventos - y si no, el registro debe ser actualizado.
El estado de cualquier registro de errores conocidos relacionados debe actualizarse para

mostrar que se ha aplicado la solución.
Revisión de un Problema Mayor

Después de cada problema mayor (según lo determinado por el sistema de priorización), y
mientras los recuerdos aún están frescos, una revisión debe llevarse a cabo para aprender las
lecciones y aplicarlas en situaciones futuras. En concreto, la revisión debe examinar:
 Las cosas que se hicieron correctamente

 Las cosas que se hicieron mal
 ¿Qué se podría hacer mejor en el futuro?
 Cómo prevenir la recurrencia
 Si se ha identificado alguna responsabilidad de terceros y si se necesitan acciones de
seguimiento
Estas revisiones se pueden utilizar como parte de la formación y sensibilización del personal de
soporte - y las lecciones aprendidas deben ser documentadas en los procedimientos apropiados,
instrucciones de trabajo, secuencias de comandos de diagnóstico o registros de error conocidos.
El administrador de problemas facilita la reunión y documentos de las acciones acordadas.
Las principales críticas de problemas también pueden ser una fuente de información para la
gestión proactiva de los problemas a través de la identificación de las causas raíz que pueden
ser descubiertas en el transcurso de la revisión.
El conocimiento obtenido de la revisión debe ser incorporado en una reunión de seguimiento del
servicio con el cliente para garantizar que el este es consciente de las medidas adoptadas y los
planes necesarios para prevenir futuros incidentes graves que se produzcan. Esto ayuda a
mejorar la satisfacción del cliente y asegurar al negocio que la Operación del Servicio se
encarga de los principales incidentes de manera responsable y trabaja activamente para evitar
su futura repetición.
179
Disparadores
Con el enfoque reactivo de la Gestión de Problemas, la gran mayoría de los registros de
problemas se disparan en respuesta a uno o más incidentes, y muchos son levantados o se
inician a través del personal del Service Desk. Otros registros de problemas y sus
correspondientes registros de errores conocidos, pueden ser disparados en las pruebas,
especialmente en las últimas etapas de pruebas, como usuario de pruebas / ensayos de
aceptación (UAT), si se toma la decisión de seguir adelante con una implementación a pesar de
que se conocen algunos fallos. Los proveedores pueden provocar la necesidad de algunos
registros de problemas a través de la notificación de los fallos potenciales o deficiencias
conocidas en sus productos o servicios (por ejemplo, un aviso puede darse con respecto a la
utilización de un CI particular y un registro de problemas puede ser levantado para facilitar la
investigación por parte de personal técnico de la condición de tales CIs dentro de la
infraestructura de TI de la organización).
Con el enfoque proactivo de la gestión de problemas, los registros de problemas pueden ser
provocados por la identificación de patrones y tendencias en los incidentes al revisar los
registros de incidentes históricos. Una revisión de otras fuentes, como los registros de
operaciones, las comunicaciones de operaciones o registros de eventos también puede disparar
de forma proactiva registros de problemas cuando la aparición de un problema subyacente se
hace evidente.
Entradas
Ejemplos de entradas para el proceso de Gestión de Problemas pueden incluir:
180
 Los registros de incidentes de incidentes que han provocado las actividades de

gestión de problemas
 Los informes de incidentes y el historial que se utilizarán para apoyar las actividades
de tendencias del enfoque proactivo de problema
 Información sobre los CI y su estatus
 Comunicación y retroalimentación sobre los incidentes y sus síntomas
 Comunicación y retroalimentación sobre las RFC y comunicados que han sido
implementadas o previstos para implementarse
 Comunicación de los eventos que fueron disparados en Gestión de Eventos
 Objetivos operacionales y de niveles de servicio
 Retroalimentación de los clientes en el éxito de las actividades de resolución de
problemas y la calidad general de las actividades de Gestión de Problemas
 Los criterios acordados para la priorización y escalación de problemas
 Salidas de la gestión y análisis de riesgos
Salidas
Ejemplos de salidas del proceso de Gestión de Problemas pueden incluir:
 Los problemas y las medidas adoptadas para lograr su resolución

 Actualización de los registros de Gestión de Problemas con el detalle preciso del
problema y su historial
 RFCs para remover problemas en la infraestructura
 Soluciones temporales para incidentes
 Registros de Errores conocidos
 Reportes de la Gestión de Problemas
 Salidas y recomendaciones de mejora para las actividades de revisión a problemas
mayores
181
Sistema de Gestión de Configuraciones

El CMS llevará todos los detalles de todos los componentes de la infraestructura de TI, así como
las relaciones entre estos componentes. Actuará como una fuente valiosa para el diagnóstico de
problemas para evaluar el impacto de los problemas (por ejemplo, si el disco se ha reducido,
que datos están en ese disco, que servicios utilizan esos datos, los usuarios que utilizan estos
servicios). No solo tendrá detalles de las actividades anteriores, sino que también podrá ser
utilizado como una valiosa fuente de información histórica para ayudar a identificar las
tendencias o debilidades potenciales - una parte clave de la gestión de problemas proactiva.

El propósito de una KEDB es permitir el almacenamiento de los conocimientos previos de los
incidentes y problemas - y cómo se superaron - para permitir el diagnóstico y resolución más
rápida si se repiten.
El registro de error conocido debería incluir datos exactos de la avería y los síntomas que se
produjeron, junto con los detalles precisos de cualquier solución o acción de resolución que se
pueden tomar para restablecer el servicio y / o resolver el problema. Una contabilización de los
incidentes también será útil para determinar la frecuencia con la que los incidentes son
probables que se repitan e influir en las prioridades, etc.
Cabe señalar que un caso de negocio para una solución permanente para algunos problemas no
exista. Por ejemplo, si un problema no causa graves trastornos y una solución existe y / o el
costo de la solución del problema es mayor a los beneficios de una solución permanente,
entonces se puede tomar la decisión de tolerar el problema. Sin embargo, todavía será deseable
182
diagnosticar y aplicar una solución lo más rápidamente posible, que es donde la KEDB puede
ayudar.
Es esencial que los datos puestos en la base de datos puedan ser recuperados rápidamente y con
precisión. El administrador de problemas debe estar plenamente capacitado y familiarizado con
los métodos / algoritmos de búsqueda utilizados por la base de datos seleccionada y se debe
asegurar cuidadosamente que cuando se agregan nuevos registros, los criterios clave de
búsqueda relevantes se incluyen correctamente.
Se debe tener cuidado para evitar la duplicación de los registros (es decir, el mismo problema se
describe en dos o más formas como registros separados). Para evitar esto, el administrador de
problemas debe ser la única persona capaz de generar un nuevo registro. Otros grupos de
apoyo deben ser alentados a proponer nuevos registros, pero éstos deben ser examinados por el
administrador de problemas antes del ingreso a la KEDB. En las grandes organizaciones,
donde se utiliza un solo KEDB (recomendado) con el personal de gestión de problemas en
varios lugares, un procedimiento debe acordarse para garantizar que la duplicación de
registros KEDB no pueda ocurrir. Esto puede implicar la designación de un solo miembro del
personal como el gestor central KEDB.
La KEDB debe utilizarse durante las fases de diagnóstico de incidentes y problemas para tratar
de acelerar el proceso de resolución - y nuevos registros se deben añadir lo antes posible
cuando un nuevo problema ha sido identificado y diagnosticado.
Todo el personal de soporte debe estar plenamente capacitado y familiarizado con el valor que
la KEDB puede ofrecer y la manera en que se debe utilizar. Deben ser capaces de recuperar y
utilizar los datos fácilmente.
La KEDB forma parte del CMS y puede ser parte de un gran SKMS.
183
184

Minimizar el impacto en el negocio  El número de errores conocidos añadidos a la
de incidentes que no se pueden KEDB
prevenir  El porcentaje de precisión de la KEDB (a partir de
las auditorías a la base de datos)
 Porcentaje de casos cerrados por el Service Desk
sin hacer referencia a otros niveles de apoyo (a
menudo referido como 'primer contacto')
 El tiempo de resolución promedio de incidentes
vinculados a registros de problemas
Mantener la calidad de los servicios  Número total de problemas (como medida de
de TI a través de la eliminación de control)
incidentes recurrentes  Tamaño del backlog actual de problemas para cada
servicio de TI
 Número de incidentes repetidos para cada servicio
de TI
Proporcionar calidad y la  El número de problemas mayores (abiertos,
profesionalidad de las actividades de cerrados y backlog)
gestión de problemas para mantener  El porcentaje de revisiones a incidentes mayores
la confianza de las organización en realizadas con éxito
las capacidades de TI  KPI El porcentaje de revisiones a incidentes
mayores realizadas con éxito y en tiempo
 Número y porcentaje de problemas incorrectamente
asignados
 Número y porcentaje de problemas incorrectamente
categorizados
 La acumulación de problemas pendientes y la
tendencia (¿estática, reduciendo o aumentando?)
 Número y porcentaje de los problemas que
superaron sus tiempos de resolución originales
 KPI Porcentaje de problemas resueltos dentro de los
objetivos del SLA (¡y el porcentaje que no lo son!)
 El costo promedio por problema
También es útil descomponer y categorizar los indicadores de problemas por categoría, marco
de tiempo, el impacto, la urgencia, el servicio afectado, el lugar y prioridad y compararlos con
periodos anteriores. Esto puede proporcionar información a CSI y otros procesos que tratan de
identificar los problemas, las tendencias de los problemas u otras situaciones.
185
Éstos son algunos de los indicadores clave de desempeño adicionales para el valor de la Gestión
de Problemas:
Indicadores Clave de Desempeño Comentario

Mejora de la Disponibilidad Descubriendo y removiendo errores en la
infraestructura
Reducción de brechas de niveles de Servicio Descubriendo y removiendo errores en la
infraestructura
Reducción del tiempo medio de reparación Al proporcionar soluciones temporales y
(MTTR) resoluciones de errores conocidos
Reducción de Incidentes mayores Descubriendo y removiendo errores en la
infraestructura
186
La relación primaria entre Incidentes y Gestión de Problemas ha sido ya comentada. Ejemplos

de otras interfaces clave son listados abajo acorde al ciclo de vida

 Gestión Financiera para los servicios de TI. Asistir en la evaluación del impacto de
soluciones permanentes y soluciones temporales propuestas, así como los “análisis de
valor/dolor”. Gestión de Problemas provee información de la gestión relacionada a los
costos de resolver y prevenir problemas, la cual es usada como entrada para el sistema
de presupuesto y contabilidad y el cálculo del costo total de propiedad (TCO)

 Gestión de la Disponibilidad: Está involucrado en determinar cómo reducir los tiempos
de no disponibilidad e incrementar los tiempos disponibles del servicio. Como tal, tiene
una relación cercana con Gestión de Problemas, especialmente en los temas proactivos.
Mucha de la información disponible en Gestión en Gestión de Problemas será
comunicada a Gestión de la Disponibilidad
 Gestión de la Capacidad: Algunos problemas requerirán investigación a través de los

grupos y técnicas de Gestión de la Capacidad, por ejemplo problemas de desempeño.
Gestión de la Capacidad también ayudará en la evaluación de medidas proactivas.
Gestión de Problemas provee información de gestión relacionada a la calidad de
decisiones tomadas, realizadas durante el proceso de planificación de la capacidad
187
 Gestión de la Continuidad de los Servicios de TI: Gestión de problemas actúa como un

punto de entrada en la Gestión de la continuidad de los servicios de TI, cuando un
problema significativo no es resuelto antes de que éste comience a tener un impacto
mayor en el negocio
 Gestión de Niveles de Servicio: La presencia de incidentes y problemas afectan el nivel

de servicio entregado, medido por Gestión de Niveles de Servicio, Gestión de Problemas
contribuye a la mejora en los niveles de servicio y la información gestionada es usada
como la base de algunos de los componentes de las revisiones del SLA. Gestión de
Niveles de Servicio también provee parámetros dentro de los cuales opera Gestión de
Problemas, como información de impacto y el efecto en los servicios de soluciones
propuestas y medidas proactivas

 Gestión del Cambio: Gestión de Problemas asegura que todas las soluciones
permanentes y temporales que requieran un cambio a un CI, sean iniciadas por Gestión
de Cambios a través de un RFC. Gestión Cambios monitorizará el progreso de los
cambios y mantendrá informado a Gestión de Problemas. Gestión de Problemas está
también involucrado en rectificar las situaciones causadas por cambios fallidos
 Gestión Activos de Servicio y Configuraciones: Gestión de Problemas usa la CMS para

identificar fallas en los CIs y también determinar el impacto de los problemas y
soluciones
 Gestión Liberaciones y Despliegues: Este proceso es responsable de los despliegues de

las soluciones a los problemas en el ambiente de producción. También asiste en asegurar
que los errores conocidos asociados, sean transferidos de la KEDB de desarrollo hacia
el KEDB de producción. Gestión de Problemas ayudará a resolver problemas causados
por fallas durante el proceso de liberaciones
 Gestión del Conocimiento: El SKMS puede ser usado para formar la base para la KEDB
y mantener o integrarse con los registros de problemas

 El proceso de mejora de los siete pasos: La ocurrencia incidentes y problemas provee
una base para la identificación de oportunidades para la mejora del servicio y
adicionarse a los registros de CSI. Las actividades de Gestión Proactiva de Problemas
podría también identificar problemas subyacentes y fallas en el servicio, que si son
dirigidos, pueden contribuir a incrementar la calidad y satisfacción de cliente y usuarios
finales
Gestión de Problemas juega un rol clave en las actividades de análisis de CSI, como éste
proceso soporta otros procesos en la identificación de tendencias y realización de
análisis de causa raíz. Gestión de Problemas es usualmente asociado con la reducción de
incidentes, pero un buen proceso de Gestión de Problemas está también involucrado en
188
ayudar a definir procesos relativos a problemas, así también aquellos asociados con el
servicio
Por lo tanto, en conjunto, Gestión de Problemas busca:
 Investigar la causa raíz, en cuanto a estar lidereando tendencias identificadas

 Recomendar oportunidades de mejora
 Comparar resultados con resultados previos
 Comparar resultados con niveles de servicio acordados
Gestión de Problemas soporta la actividad de presentación de CIS a través de:
 Proveer entradas dentro de las iniciativas de mejora y priorizar las iniciativas de

mejoras
 Soportar la preparación de reportes
 Proveer entradas en la priorización de SIP(Plan de mejora del servicio) o mejoras
 Implementación incremental o actividades de ajuste fino que no requieran
aprobación del negocio
189
Tecnología de Gestión de Servicios integrada

Una herramienta integrada de ITSM (Gestión de Servicios de TI) es necesario que pueda
diferenciar incidentes de problemas, de modo que, separados los registros de problemas, puedan
éstos últimos, ser el elemento primario para acometer contra la causa subyacente de los
incidentes, pero ligados a los incidentes en cuestión. La funcionalidad de los registros de
problemas debería ser similar a la funcionalidad de los registros de incidentes y también
permitir ligar múltiples incidentes contra los registros de problemas
Gestión de Cambios
La integración con Gestión de Cambios es muy importante, para que los registros de las
solicitudes, eventos, incidentes y problemas, puedan ser relacionados con el RFC que causo el
problema. Esto es para evaluar el éxito del proceso de Gestión de Cambios (así como incidentes
y los registros de errores conocidos) y para que los RFCs puedan fácilmente ser utilizados para
controlar las actividades necesarias, para resolver problemas que han sido identificados a
través del análisis de causa raíz o análisis proactivo de tendencias
CMS integrada
Es también importante tener una CMS integrada, la cual permita que los registros de problemas
puedan ligarse a los componentes afectados y los servicios impactados (y a cualquier CI
relevante).
Gestión de Activos del Servicio y Configuraciones forma parte del gran SKMS, el cual incluye
vínculos a muchos repositorios de datos usados en la Operación del Servicio. El proceso y las
prácticas de Gestión de Activos del Servicio y Configuraciones y sus requerimientos
tecnológicos subyacentes están incluidos en Transición del servicio de ITIL
190

Una efectiva KEDB será un requerimiento esencial, la cual permitirá fácilmente guardar y
recuperar datos de errores conocidos
Buenas facilidades para reporteo y/o informes son necesarios para facilitar la generación de
reportes de gestión, permitiendo a los datos ser incorporados automáticamente sin la necesidad
de re indexar los datos e incluir funcionalidades de hacer “zoom”(drill down) para el análisis
de incidentes y problemas.
191
Retos
 Una mayor dependencia para Gestión de Problemas, es el establecimiento de un
efectivo proceso y herramienta de Gestión de Incidentes. Esto asegurará que los
problemas sean identificados tan pronto como sea posible y que tanto como sea
posible el trabajo sea realizado en precalificar. Un retro crítico existe en asegurar
que los dos procesos tienen interfaces formales y prácticas comunes de trabajo
 Las habilidades y capacidades de los grupos de solución de problemas para
identificar las verdaderas causas raíz de los incidentes, es a menudo un desafío.
Muchas veces los grupos de soporte describirán la causa raíz basada en síntomas o
las acciones realizadas para la solución. Las técnicas descritas en la sección 4.4.4
pueden ser usadas para ayudar a determinar la verdadera causa subyacente de un
incidente. Creando un enfoque de “¿Por qué sucedió?” o “¿Que puede hacerse para
prevenir que el incidente ocurra de nuevo?” puede ser también de utilidad
 La habilidad para relacionar incidentes con problemas puede ser un reto, si la
herramienta usada para registrar los incidentes es diferente de la que se usa para
registrar los problemas. En algunos casos, la herramienta de incidentes existe sin
capacidades para dar seguimiento a problemas de forma separada
 La habilidad para integrar las actividades de Gestión de Problemas con la CMS,
para determinar las relaciones entre los CIs y referirlos a los históricos de los CIs
cuando se realizan actividades de soporte de problemas
 Asegurar que Gestión de Problemas pueda usar todo el conocimiento y recursos
disponibles de Gestión de Activos del Servicio y Configuraciones, para investigar y
resolver problemas
192
 Asegurar que la capacitación continua de los grupos técnicos tanto en aspectos

técnicos de sus actividades, así como también las implicaciones al negocio de los
servicios que ellos soportan y los procesos que utilizan, estén implementados
 La habilidad para tener una buena relación de trabajo, entre los grupos de segundo y
tercer nivel que trabajan en actividades de soporte a problemas y los grupos de
primera línea
 Asegurar que los impactos al negocio estén bien entendidos, por todos los grupos que
trabajan en la solución de problemas
Riesgos
Los riesgos para el éxito de Gestión de Problemas son hoy en día similares a algunos de los
retos y lo contrario a algunos de los Factores Críticos de Éxito mencionados con anterioridad.
Estos incluyen:
 Ser inundado de problemas que no puedan ser manejados en escalas de tiempo

aceptables, debido a la falta de recursos disponibles o capacitados adecuadamente
 Problemas empantanados y sin progreso, debido a inadecuadas herramientas de
soporte para la investigación
 Falta de adecuada y/u oportunas fuentes de información, debido a inadecuadas
herramientas o falta de integración
 Grupos de soporte de Problemas que podrían no estar adecuadamente capacitados
para; investigar los problemas, encontrar las causas subyacentes o identificar las
acciones apropiadas para remover los errores
 Confundir los objetivos o acciones, debido a una alineación deficiente o no existente
con los OLAs y/o UCs
193
Gestión de Acceso
194
Gestión de Acceso
195
Gestión de Acceso
Alcance
La Gestión de Acceso es la ejecución efectiva de las políticas de Gestión de Seguridad de la
Información, ya que permite a la organización gestionar la confidencialidad, disponibilidad e
integridad de los datos de la organización y de la propiedad intelectual.
La Gestión de Acceso garantiza la correcta concesión de los permisos de acceso a los usuarios,
pero no garantiza que este acceso está disponible en los momentos acordados - esto es
proporcionado por la Gestión de la Disponibilidad.
La Gestión de Acceso es un proceso que se ejecuta por todas las funciones de la Gestión Técnica
y de Aplicaciones y generalmente no es una función separada. Sin embargo, es probable que
exista un único punto de coordinación para su control, por lo general, en la Gestión de
Operaciones o en el Service Desk.
Gestión de Acceso puede ser iniciado por una solicitud de servicio.
196
Gestión de Acceso
197
Gestión de Acceso
 La Gestión de Acceso y sus actividades asociadas deben ser guiadas/dirigidas por las
políticas y controles definidos en Gestión de Seguridad de la Información. La Gestión
de Acceso debe registrar y controlar los accesos para la utilización de los servicios y
garantizar que los derechos que se prestan se emplean correctamente. Esto implica
que las capacidades apropiadas para el registro y control de accesos se han
establecido junto con los controles para generar eventos de acceso no autorizado y el
uso indebido de los servicios.
 La Gestión de Acceso debe mantener el acceso a los servicios alineados con los
cambios del personal así como las transferencias y terminaciones. Esto implica que
la comunicación con las funciones de recursos humanos sea establecida para
notificar acerca de eventos y cambios de personal en forma oportuna
 La Gestión de Accesos debe mantener un historial preciso de quién ha accedido o
intentado acceder a los servicios. Esto proporciona información a quienes realicen
actividades de auditoría y cumplimiento. También ayuda a otras personas que
pueden estar involucradas con las actividades de seguridad forense en la
investigación de las violaciones de seguridad. Esto implica que los registros
mantienen los derechos de acceso y muestran que permisos se han otorgado a qué
servicios y por quién
 Procedimientos para el manejo, escalamiento y la comunicación de los eventos de
seguridad deben estar claramente definidas y documentados, de conformidad con las
políticas de Seguridad de la Información. Esto implica que aquellos que ejecutan las
actividades de Gestión de Acceso comprenden plenamente las políticas y los
procedimientos para el manejo de eventos de seguridad
198
Gestión de Acceso
La Gestión de Acceso es el proceso que permite a los usuarios utilizar los servicios que se
documentan en el catálogo de servicios. Se compone de los siguientes conceptos básicos:
 El acceso se refiere al nivel y alcance de la funcionalidad de un servicio o de los
datos que el usuario tiene derecho a utilizar
 Identidad se refiere a la información sobre los usuarios mismos que los distingue
como un individuo y que verifica su estatus dentro de la organización. Por definición,
la identidad de un usuario es único para ese usuario
 Permisos (también llamados privilegios) se refieren a la configuración real por la
cual se facilita al usuario el acceso a un servicio o grupo de servicios. Permisos
típicos o niveles de acceso, incluyen leer, escribir, ejecutar, modificar y eliminar
 Servicios o grupos de servicios. La mayoría de los usuarios no utilizan un único
servicio y los usuarios que llevan a cabo una serie de actividades similares utilizan
un conjunto similar de servicios. En lugar de proporcionar acceso a cada servicio
para cada usuario por separado, es más eficiente para poder conceder a cada
usuario - o grupo de usuarios - acceso a todo el conjunto de servicios que tienen
derecho a utilizar al mismo tiempo
 Directorio de Servicios se refieren a determinados tipos de herramientas que se
utilizan para gestionar el acceso y los derechos
199
Gestión de Acceso
Actividades de la Gestión de Accesos

Petición Solicitud de Petición de Petición o
De Servicio RH script de
Cambio aplicacion
Recibir petición
Verificación
No
Usuario
válido_
SI
No Solicitud
válida_
Si
No
Validar y monitorear No Informacion
¿Quitar Solicitud
status de identidad de Gestión
Acceso? acceso?
de la
Seguridad
system
Si Si
Quitar o restrigir
permisos Proveer permisos
Informacion
de Gestión
de la
Seguridad
system
Registrar y
monitorear Acceso
Yes Gestión de
¿Esun Incidentes
incidente?
No
Fin
© Crown copyright 2011 Reproduced under license from the

Cabinet Office. Figure 4.9 Service Operation 4.5.5
200
Gestión de Acceso
Solicitar Acceso
Un Acceso (o restricción) puede ser solicitado mediante uno de cualquier mecanismo,
incluyendo:
 Una solicitud de servicio generada por el sistema de recursos humanos. Esto se hace
generalmente cuando una persona es contratada, promovido, transferido o cuando
salen de la empresa
 Un RFC
 Una solicitud de servicio tramitada a través el sistema de solicitudes
 Al ejecutar una secuencia de comandos pre-autorizada o una opción (por ejemplo,
descargar una aplicación desde un servidor de prueba cómo y cuándo sea necesario)
Verificación
La Gestión de Acceso tiene que verificar cada solicitud de acceso a un servicio de TI desde dos
perspectivas:
 Que el usuario solicita el acceso es quien dice ser
 Que tengan una necesidad legítima para utilizar ese servicio
La primera perspectiva se consigue normalmente por el usuario al proporciona su nombre de

usuario y contraseña. Dependiendo de las políticas de seguridad de la organización, el uso del
nombre de usuario y la contraseña son generalmente aceptadas como prueba de que la persona
es un usuario legítimo. Sin embargo, para los servicios más sensibles puede ser necesario una
autenticación adicional (biométrico, el uso de una clave de acceso electrónico, dispositivo de
encriptación, la base de datos de preguntas y respuestas, dato sólo conocido por el usuario, etc.)
La segunda perspectiva requerirá alguna verificación independiente, aparte de la petición del

usuario. Por ejemplo:
 Notificación de recursos humanos que la persona es un empleado nuevo y requiere
un nombre de usuario y acceso a un conjunto estándar de servicios
 Notificación de recursos humanos que el usuario ha sido promovido y requiere el
acceso a recursos adicionales
 Autorización de un adecuada de un gerente (definida en el proceso)
 La presentación de una solicitud de servicio (con evidencia de apoyo) a través del
Service Desk
 Presentación de un RFC (con evidencia de apoyo) a través de la gestión del cambio,
o la ejecución de un cambio estándar predefinido
 Una política que indica que el usuario puede tener acceso a un servicio opcional si lo
requiere
Para los servicios nuevos el registro de cambios debe especificar qué usuarios o grupos de
usuarios tendrán acceso al servicio. La gestión de Acceso comprobará que los usuarios sigan
autorizados para el acceso y así de forma automática otorgar el acceso como se especifica en el
RFC.
Proporcionar Permisos
La Gestión de Acceso no decide quién tiene acceso a qué servicios de TI. Por el contrario, la
Gestión de Acceso sólo ejecuta las políticas y regulaciones definidas en la Estrategia del
201
Gestión de Acceso
Servicio y Diseño del Servicio. La Gestión de Acceso hace cumplir las decisiones de restringir o
permitir el acceso, en lugar de tomar la decisión.
Tan pronto como un usuario ha sido verificado, la Gestión de Acceso proporcionará a ese
usuario los permisos de uso del servicio solicitado. En la mayoría de los casos esto se traducirá
en una solicitud para cada equipo o departamento involucrado en la entrega del servicio para
que tomen las acciones correspondientes. Si es posible, estas tareas deben ser automatizadas.
Revisar y monitorizar el estatus de la identidad

Conforme los usuarios trabajan en la organización, sus roles cambian y también lo hacen sus
necesidades para acceder a los servicios. Los ejemplos de cambios incluyen:
 Cambios de trabajo: En este caso el usuario posiblemente tendrá acceso a servicios
diferentes o adicionales
 Promociones o descensos de categoría: El usuario probablemente utilizará el mismo
conjunto de servicios, pero necesita tener acceso a diferentes niveles de
funcionalidad o datos
 Transferencias: En esta situación, el usuario puede necesitar el acceso a exactamente
el mismo conjunto de servicios, pero en una región diferente con diferentes prácticas
de trabajo y los conjunto de datos diferentes
 Renuncia o muerte: El acceso debe ser completamente eliminado para evitar que el
nombre de usuario que se utiliza como una laguna en la seguridad
 Jubilación: En muchas organizaciones, un empleado que se jubila todavía puede
tener acceso a un conjunto limitado de servicios, incluidos los sistemas de beneficios
o sistemas que les permiten comprar productos de la empresa a un precio reducido
 Medidas disciplinarias: En algunos casos, la organización requerirá una restricción
temporal para impedir al usuario el acceso a algunos o todos los servicios que
normalmente tienen acceso. Debe haber una característica del proceso y
herramientas para hacer esto, en lugar de tener que eliminar y reinstalar los
derechos de acceso del usuario
 Despidos: Cuando un empleado o contratista es despedido o cuando se emprende
una acción legal contra un cliente (por ejemplo, por incumplir con el pago de los
productos comprados en Internet), el acceso debe ser revocado inmediatamente.
Además, la Gestión de Acceso, en colaboración con Gestión de Seguridad de la
Información, deberán tomar medidas proactivas para prevenir y detectar acciones
maliciosas en contra de la organización de ese usuario
La Gestión de Acceso debe entender y documentar el ciclo de vida del usuario típico para cada
tipo de usuario y utilizarlo para automatizar el proceso. Herramientas de gestión de accesos
deben proporcionar características que permitan mover al usuario de un estado a otro o de un
grupo a otro, de forma sencilla y con registro para auditoría
Registro y Seguimiento del Acceso

La Gestión de Acceso no sólo debe responder a las solicitudes. También es responsable de
asegurar que los permisos que ha brindado sean utilizados de forma correcta.
202
Gestión de Acceso
En este sentido, el seguimiento y el control de los accesos se debe de incluir en las actividades
de monitoreo de la Gestión técnicas y de aplicaciones y todos los procesos Operación del
Servicio.
Las excepciones deben ser manejadas por la Gestión de Incidentes, posiblemente haciendo uso
de modelos de incidentes diseñados específicamente para tratar el abuso de los permisos de
acceso. Tenga en cuenta que la visibilidad de este tipo de acciones debe ser restringida. Poner
esta información a disposición de todos los que tienen acceso al sistema de Gestión de
Incidentes expone a vulnerabilidades.
Gestión de Seguridad de la Información juega un papel fundamental en la detección de accesos

no autorizados y comparándolos con los permisos que le fueron proporcionados por la Gestión
de Acceso. Esto requerirá la participación de la Gestión de Acceso en la definición de los
parámetros para el uso de las herramientas de detección de intrusos
La Gestión de Acceso también puede ser necesaria para proporcionar un registro de acceso de
los servicios específicos durante las investigaciones forenses. Si un usuario es sospechoso de
violación de la política, el uso inadecuado de los recursos, o el uso fraudulento de datos, la
Gestión de Accesos puede ser requerido para proporcionar evidencia de las fechas, horas e
incluso contenido de acceso del usuario a los servicios específicos. Esto es normalmente
proporcionado por el personal operativo de ese servicio, pero trabajando como parte del
proceso de gestión de acceso.
Remover o Restringir Permisos

Al igual que ofrece permisos de uso de un servicio, la Gestión de Acceso es también responsable
de revocar esos derechos. Una vez más, esto no es una decisión que hace por sí mismo. Por el
contrario, ejecutará las decisiones y políticas realizadas durante Estrategia del Servicio y
diseño, así como las decisiones tomadas por los directivos de la organización.
Remover el acceso suele hacerse en las siguientes circunstancias:

 Muerte
 Renuncia
 Despido
 Cuando el usuario ha cambiado de rol y ya no requiere el acceso al servicio
 Transferencia o viajar a un área donde el acceso regional diferente se aplica
En otros casos no es necesario eliminar el acceso, pero sólo utilizar restricciones más severas.
Estas podrían incluir la reducción del nivel, el tiempo o la duración de acceso. Situaciones en
las que debe restringirse el acceso incluyen:
 Cuando el usuario ha cambiado roles o ha sido degradados y ya no requiere el
mismo nivel de acceso
 Cuando el usuario está bajo investigación, pero aún requiere el acceso a los
servicios básicos, tales como el correo electrónico. En este caso, el correo
electrónico puede ser objeto de análisis adicional (pero esto tendría que ser
203
Gestión de Acceso
manejado con mucho cuidado y en plena concordancia con la política de seguridad

de la organización)
 Cuando un usuario está fuera de la organización por una asignación temporal y no
deberán tener acceso a ese servicio durante un tiempo
204
Gestión de Acceso
205
Gestión de Acceso
Identidad
La identidad de los usuarios es la información sobre los mismos que los distingue como
individuos y que verifica su estatus dentro de la organización. Por definición, la identidad de un
usuario es única para ese usuario. Debido a que hay casos en que dos usuarios comparten una
pieza común de información (por ejemplo, que tienen el mismo nombre), la identidad se
establece habitualmente mediante más de una pieza de información, por ejemplo:
 Nombre
 Dirección
 Información de contacto, por ejemplo, teléfono, dirección de correo electrónico, etc.
 Documentación física, por ejemplo licencia de conducir, pasaporte, certificado de
matrimonio, etc.
 Los números que hacen referencia a un documento o una inscripción en una base de
datos, por ejemplo, número de empleado, número de identificación fiscal, número de
identidad del gobierno, el número de licencia de conducir, etc.
 La información biométrica, por ejemplo, huellas dactilares, imágenes de la retina, los
patrones de reconocimiento de voz, ADN, etc.
 Fecha de Espiración (si es relevante).
 La identidad del usuario se proporciona a cualquier persona con una necesidad legítima
de acceder a los servicios y la información de la organización. Estos podrían incluir:
o Empleados
o Contratistas
o Personal del proveedor (por ejemplo, los administradores de cuentas, personal de
apoyo, etc.)
206
Gestión de Acceso
o Los clientes (sobre todo en la compra de productos o servicios a través de

Internet)
Usuarios, Grupos, Roles y Grupos de Servicios

Mientras que cada usuario tiene una identidad individual, y cada servicio de TI puede ser visto
como una entidad por derecho propio, a menudo es útil agruparlos juntos para que puedan ser
manejados más fácilmente. A veces los términos, "perfil de usuario”, “plantilla de usuario" o
"función de usuario" se utiliza para describir este tipo de agrupación.
La mayoría de las organizaciones cuentan con un conjunto estándar de servicios para todos los
usuarios individuales, independientemente de su cargo o puesto de trabajo (excluyendo los
clientes, que no tienen ninguna visibilidad a los servicios y procesos internos). Estos incluyen
servicios tales como mensajería, ofimática, soporte de escritorio, telefonía etc. A usuarios
nuevos se les proporcionan automáticamente estos permisos para estos servicios.
Sin embargo, la mayoría de los usuarios también tienen un papel especial que desempeñar. Por
ejemplo, además de los servicios estándar, el usuario también realiza una función de gestión de
marketing, lo que requiere que tengan acceso a algo de marketing especializado y herramientas
de modelado y datos financieros.
Algunos grupos pueden tener requisitos específicos, como los trabajadores de campo o casa que
puedan tener que marcar o utilizar conexiones de red privadas virtuales, con implicaciones de
seguridad que pueden tener que ser más estrechamente controlados
Para que sea más fácil para la Gestión de Acceso proporcionar los permisos correspondientes,
se utiliza un catálogo de todas las funciones de la organización y los servicios que apoyan a
cada función. Este catálogo de funciones deberá ser compilado y mantenida por la Gestión de
Accesos en conjunto con recursos humanos, con frecuencia se puede automatizar en las
herramientas de directorio de servicios.
Además de desempeñar diferentes roles, los usuarios también pueden pertenecer a diferentes
grupos. Por ejemplo, todos los contratistas están obligados a registrar sus hojas de tiempo en un
sistema de tarjeta de tiempo dedicado, el cual no es utilizado por los empleados. La Gestión de
Accesos evaluará todos los roles que desempeña un usuario, así como los grupos a los que
pertenecen y asegurará que se proporcionen todos los permisos de uso de los servicios
asociados.
Técnicas de control de acceso basadas en funciones también pueden ser utilizadas por la
Gestión de Accesos para autenticar y autorizar a los usuarios para operaciones específicas. Con
estas técnicas, el acceso se asigna a funciones específicas en lugar de directamente a los
usuarios. A través de este enfoque, los usuarios se autentican y autorizan indirectamente a
través de los roles que están asignados.
Tenga en cuenta que todos los datos contenidos en los usuarios estarán sujetos a la legislación
de protección de datos (esto existe en la mayoría de las ubicaciones geográficas de una forma u
otra) por lo que debe ser manejada y protegida como parte de los procedimientos de seguridad
de la organización.
207
Gestión de Acceso
Algunos factores críticos de éxito e indicadores claves de desempeño de ejemplo:

Garantizar que la confidencialidad,  Porcentaje de incidentes que implicaron intentos o
integridad y disponibilidad de los accesos inapropiados a los servicios
servicios está protegida de acuerdo  Número de los hallazgos de auditoria que
con las políticas de seguridad de la descubrieron configuración incorrecta de acceso para
información. los usuarios que han cambiado roles o salido de la
empresa
 Número de incidentes que requirieron un reseteo de
permisos de acceso
 Número de incidentes casados por configuración
incorrecta de accesos
Proporcionar acceso adecuado a los  Porcentaje de solicitudes de acceso (petición de
servicios de manera oportuna servicio, RFC, etc.) que se proporcionaron dentro de los
respondiendo a las necesidades del SLAs y OLAs establecidos
negocio.
Proveer comunicación a tiempo sobre  Duración promedio de los incidentes relacionados
accesos inapropiados o abusos a los con el acceso (desde el momento del descubrimiento
servicios hasta la escalación)
208
Gestión de Acceso
Gestión de Acceso puede interactuar con muchos de los procesos que solicitan o son la interfaz
con los servicios de TI. Controles y permisos adecuados a los servicios deben garantizarse de
acuerdo con la política de seguridad de la información. Ejemplos de interfaces con otros
procesos se enumeran a continuación para cada etapa del ciclo de vida de servicio

 Gestión de la Demanda: Este proceso ayuda a identificar los niveles de recursos
necesarios para manejar grandes volúmenes esperados de las solicitudes de acceso
 Gestión Estratégica para Servicios de TI: Se puede determinar que algunas
actividades de gestión de acceso (especialmente para las organizaciones más
grandes) pueden ser manejadas más eficientemente dentro de las organizaciones de
negocio individuales en lugar de en una función de gestión de acceso centralizado

 Gestión de Seguridad de la Información: Este proceso proporciona las políticas de
seguridad y protección de datos y las herramientas necesarias para ejecutar la
Gestión de Accesos. Las interfaces con procesos de recursos humanos deben estar
establecidas para verificar la identidad del usuario, así como para asegurarse de que
tienen derecho a los servicios que se solicita
 Gestión del Catálogo de Servicios: Este proceso proporciona métodos y medios por
los cuales los usuarios pueden acceder a diferentes servicios de TI, descripciones de
servicios y vistas que están autorizados
209
Gestión de Acceso
 Gestión de Continuidad de los Servicios de TI: Las interfaces pueden ser necesarios
para gestionar el acceso a los servicios en el caso de una interrupción de importante
o en condiciones en que los servicios temporalmente provienen de otros lugares
 Gestión de Niveles de Servicio: Este proceso mantiene los acuerdos para el acceso a
cada servicio. Esto incluirá los criterios de quién tiene derecho a acceder a cada
servicio, cuál será el costo de ese acceso, en su caso, y qué niveles de acceso se
concederán a los diferentes tipos de usuario (por ejemplo, administradores o
personal)

 Gestión de Cambios: Este proceso controla las peticiones de acceso. Esto es porque
cualquier solicitud de acceso a un servicio es un cambio, a pesar de que generalmente se
procesa como un cambio estándar o petición de servicio (posiblemente utilizando un
modelo) una vez que los criterios de acceso se han acordado a través de SLM
 Gestión de Activos de Servicio y Configuración: Interfaces para este proceso son
necesarios para identificar el almacenamiento de datos e interrogar a los CI para
determinar los detalles de acceso actual

 Cumplimiento de Solicitudes: Este proceso proporciona métodos y medios por los
cuales los usuarios pueden solicitar el acceso a los servicios estándar que están
disponibles para ellos
210
Gestión de Acceso
 Tecnología de gestión de recursos humanos para validar la identidad de los usuarios

y el seguimiento de su estado
 Tecnología de Directorio de Servicios
 Esta tecnología permite a los administradores a asignar nombres a los recursos de
una red y proporcionar acceso a dichos recursos en función del perfil del usuario.
Herramientas de directorios de Servicios también permiten a la Gestión de Acceso
crear roles y grupos y para vincularlos con los usuarios y los recursos
 Funcionalidad para gestionar accesos en Aplicaciones, Middleware, Sistemas
Operativos y Redes
 Sistemas de Gestión de Cambios
 Tecnología de Cumplimiento de Solicitudes
211
Gestión de Acceso
Retos
 Monitoreo y presentación de informes sobre la actividad de acceso, así como los
incidentes y problemas relacionados con el acceso
 Verificación de la identidad de un usuario (que la persona es quien dice ser)
 Verificación de la identidad de la persona que aprueba
 Verificar que el usuario reúne los requisitos para acceder a un servicio específico
 Vinculación de los permisos de acceso múltiple a un usuario individual
 Determinación del estado de los usuarios en cualquier momento (por ejemplo, para
determinar si siguen siendo empleados de la organización cuando se conectan a un
sistema)
 Gestión de cambios en los requisitos de acceso de un usuario
 Restricción de los derechos de acceso a usuarios no autorizados
 Construir y mantener una base de datos de todos los usuarios y los derechos que se
les ha concedido
Riesgos
 La falta de tecnologías adecuadas de apoyo para gestionar y controlar el acceso a
los servicios, lo que a su vez puede dar lugar a una dependencia en tareas manuales
propensos a errores para el manejo de los controles de acceso
 Controlar el acceso de "back door", como interfaces de aplicaciones y cambios en las
reglas de firewall para necesidades especiales
 Gestionar y controlar el acceso a los servicios externos de otros proveedores
 La falta de apoyo de la Dirección en las actividades de gestión y los controles de
acceso
212
Gestión de Acceso
 Asegurar que los niveles necesarios de acceso a los servicios y los controles de
gestión necesarios se proporcionan en forma de no entorpecer innecesariamente la
capacidad de los usuarios para conducir actividades de negocio
213
Roles en los Procesos de Operación del Servicio
GESTIÓN DE EVENTOS
Dueño del Proceso de Gestión de Eventos

 Planificación y gestión del soporte a las herramientas y procesos de gestión de eventos
 Trabajar con otros dueños de procesos para asegurar que haya un enfoque integrado
para el diseño e implementación de la gestión de eventos, gestión de incidentes,
cumplimiento de solicitudes, gestión de accesos y gestión de problemas
Gestor del Procesos de Gestión de Eventos

 Planificación y gestión del soporte a las herramientas de gestión de eventos y procesos
 Coordinar Interfaces entre la gestión de eventos y otros procesos de gestión de servicios
Personal del Service Desk

El Service Desk no está típicamente implicado en la gestión de eventos como tal, a menos que un
evento requiera algún tipo de respuesta que se encuentra dentro del alcance de las actividades
definida para el Service Desk, por ejemplo, notificar a un usuario de que un informe esté listo.
Sin embargo, generalmente este tipo de actividad se realiza por el puente operaciones, a menos
que el Service Desk y el puente de operaciones se hayan combinado.
La investigación y la resolución de los acontecimientos que se han identificado como incidentes

estarán a cargo de la mesa de servicio y luego se escalará al equipo o equipos de operación
apropiados.
214
El Service Desk es también responsable de la comunicación de la información sobre este tipo de

incidentes hacia los equipos relevantes de la Gestión Técnica y Gestión de Aplicaciones y en su
caso al usuario.
Personal de la Gestión Técnica y Gestión de Aplicaciones

El personal de Gestión Técnica y Gestión de Aplicaciones desempeñan varias funciones
importantes, como las siguientes:
 Durante el diseño de servicios, participarán en el diseño de los aspectos de la garantía
del servicio, tales como la clasificación de los eventos, la actualización de los motores de
correlación, o asegurar que las respuestas automáticas se definan
 Durante la transición del servicio, se pondrá a prueba el servicio para asegurarse de que
los eventos se generan correctamente y que las respuestas son apropiadas definidas
 Durante la operación del servicio, estos equipos normalmente realizan la gestión de
eventos para los sistemas bajo su control. No es habitual que los equipos tengan una
persona dedicada a administrar la gestión de eventos, pero cada gerente o jefe de equipo
se asegurará de que los procedimientos correspondientes se definan y se ejecuten de
acuerdo con el proceso y los requisitos de las políticas
 La Gestión técnica y gestión de aplicaciones también estarán involucrados en el manejo
de incidentes y problemas relacionados con eventos
 Si las actividades de gestión de eventos se delegan al Service Desk o a la gestión de
operaciones, la gestión de aplicaciones y la gestión técnica deben asegurar que el
personal esté debidamente capacitado y que tengan acceso a las herramientas necesarias
para que puedan realizar estas tareas
Personal de Gestión de Operaciones de TI

Cuando la Gestión de Operaciones de TI está separada de la gestión técnica o la gestión de
aplicaciones, es común que el monitoreo de eventos y la primera línea de respuesta que se
delegue en la gestión de TI operaciones. Los operadores de cada área tendrá la tarea de
monitoreo de los eventos, respondiendo según sea necesario, o asegurarse que los incidentes se
crean según corresponda. Las instrucciones para hacerlo deben ser incluidas en el SOP para
esos equipos.
El monitoreo de eventos comúnmente se delega al puente de operaciones (donde exista). El

puente de operaciones puede iniciar y coordinar o realizar incluso, las respuestas requeridas
por el servicio, o proporcionar soporte de primer nivel para aquellos eventos que generan un
incidente.
GESTIÓN DE INCIDENTES
Dueño del Proceso de Gestión de Incidentes

 Diseño de modelos de incidentes y flujos de trabajo
para el diseño e implementación de la gestión de incidentes, gestión de problemas,
gestión de eventos, gestión de acceso y cumplimiento petición
215
Gerente del Proceso de Gestión de Incidentes

 Planificación y gestión del soporte a las herramientas y procesos de gestión de
incidentes
 Coordinación de interfaces entre la Gestión de incidentes y otros procesos de la gestión
de servicios
 Conducir con eficiencia y eficacia del proceso de gestión de incidentes
 Producir información para la Gestión
 Gestionar el trabajo del personal de soporte de incidentes (de primera y segunda línea)
 Seguimiento de la eficacia de la gestión de incidentes y formulación de recomendaciones
para la mejora
 Desarrollar y mantener los sistemas de gestión de incidentes
 Gestión de incidentes mayores
 Desarrollar y mantener el proceso y procedimientos de gestión de incidentes
En muchas organizaciones el papel de gestor de incidentes se asigna al supervisor de la mesa

de servicio, aunque en las grandes organizaciones con grandes volúmenes un rol por separado
puede ser necesario. En cualquier caso, es importante que el gerente de incidentes se le dé la
autoridad para gestionar los incidentes con eficacia a través de primero, segundo y tercer nivel.
Analista de Primer Nivel

Este rol proporciona soporte de primera nivel para los incidentes mediante el proceso de
gestión de incidentes. Es común encontrar esta función junto con el rol de analista de Service
Desk.
Las responsabilidades principales incluyen:

 Registrar Incidentes
 Escalar incidentes a grupos de apoyo de especialistas cuando sea necesario
 Análisis para la priorización y correcta clasificación, y la prestación de apoyo inicial
 Proporcionar propiedad, control, seguimiento y comunicación de incidentes
 Proporcionar resolución y recuperación de incidentes no asignados a grupos de apoyo
especializados
 Cierre de Incidentes
 Monitoreo del estatus y el progreso hacia la resolución de los incidentes asignados
 Mantener a los usuarios y al Service Desk informados sobre el progreso incidente
 Escalación de incidentes según sea necesario por las políticas de escalación
establecidas
Analista de Segundo Nivel

Muchas organizaciones optan por tener un grupo de apoyo de segunda nivel, formada por
personal con un mayor (aunque todavía general) conocimiento técnico que el Service Desk- y
con más tiempo para dedicar al diagnóstico y la resolución de incidente sin la interferencia de
las interrupciones telefónicas. Las responsabilidades principales serían similares a la función de
analista de primera nivel. Tal grupo puede manejar muchos de los incidentes menos
complicados, dejando a los grupos de soporte más especializados (tercer nivel) concentrarse en
tratar con incidentes que requieren mayor análisis y / o los nuevos desarrollos, etc.
216
Cuando un grupo de segunda nivel se utiliza, a menudo hay ventajas al ubicar este grupo cerca
de la mesa de servicio, para permitir una buena comunicación y para facilitar el movimiento de
personal entre los grupos, que pueden ser útiles para la formación / sensibilización y durante
períodos de mucho trabajo o la escasez de personal. Un gerente de soporte de segunda nivel (o
supervisor si es sólo un grupo pequeño) normalmente se dirigirá este grupo.
Analista de Tercer nivel

El tercer nivel de soporte será proporcionado por una serie de grupos internos de técnicos y / o
de terceros proveedores. La lista puede variar de una organización a otra, pero es probable que
incluya:
 Soporte de Red
 Soporte de Voz (si es independiente)
 Soporte de Servidores
 Soporte de Equipos de escritorio
 Gestión de Aplicaciones
 Soporte en Bases de Datos
 Ingenieros de mantenimiento de Hardware
 Mantenimiento/Proveedores de soporte a equipos de ambiente
Tenga en cuenta que dependiendo si una organización decide tercerizar sus servicios de apoyo,
cualquiera de los grupos anteriores pueden ser grupos internos o externos.
CUMPLIMIENTO DE SOLICITUDES DE SERVICIO
Dueño del Proceso de Cumplimiento de Solicitudes

 Diseñar modelos de solicitud de cumplimiento y flujos de trabajo
para el diseño e implementación de cumplimiento solicitudes de servicio, gestión de
incidentes, gestión de eventos, gestión de accesos y gestión de problemas
Gerente del Proceso de Cumplimiento de Solicitudes

 Planificación y gestión del soporte para las procesos y herramientas de cumplimiento de
 Coordinación de interfaces entre el proceso de cumplimiento de solicitudes de servicios
y otros procesos de la gestión de servicios
 Manejo del personal, los clientes y dudas de la gestión, solicitudes, problemas y
preguntas
 Asegurar que las actividades de cumplimiento solicitudes de servicios operen en línea
con los objetivos de niveles de servicio
 Revisión y análisis de toda los reportes de solicitudes de servicio para buscar mejoras
de forma proactiva
 Supervisar las acciones para obtener retroalimentación de los clientes sobre la calidad
de las actividades de cumplimiento de solicitudes de servicio
217
 Ayudar con actividades para identificar adecuadamente los niveles de personal

necesarios para atender la demanda de actividades de cumplimiento de solicitudes de
servicio
 Asegurar todas las solicitudes de servicio autorizados se están cumpliendo en forma
oportuna
 Representación de las actividades de cumplimiento de servicio en las reuniones del CAB
 Revisar la priorización inicial y autorización de solicitudes de servicio para determinar
la exactitud y consistencia
Analista de Cumplimiento de Solicitudes

Este rol coordina el cumplimiento de las solicitudes de servicio para mantener altos niveles de
satisfacción con los servicios de TI. Supervisa, gestiona y coordina todas las actividades de
respuesta a una solicitud de servicio y sirve como un único punto de contacto hasta que se haya
cumplido.
Las responsabilidades del analista de cumplimiento solicitudes típicamente incluyen:

 Proporcionar un único punto de contacto y responsabilidad de extremo a extremo para
asegurar que las solicitudes de servicio se han procesado
 Proporcionar una clasificación inicial de solicitudes de servicio para determinar qué
recursos de TI deben comprometerse a cumplirlas
 Comunicar las solicitudes de servicio a otros recursos informáticos que estarán
involucrados en el cumplimiento de estas
 Escalación de solicitudes de servicio en línea con los objetivos de nivel de servicio
establecidos
 Asegurar que las solicitudes de servicio estén debidamente registradas
Manejo inicial de las solicitudes de servicio que comúnmente es llevada a cabo por la mesa de
servicio y el personal de gestión de incidentes.
El eventual cumplimiento de la solicitudes de servicio se llevará a cabo por el equipo de

operación de servicio correspondiente (s) o departamentos y / o por proveedores externos,
según corresponda. A menudo la gestión de las facilidades, adquisiciones y otras áreas de
negocio ayudan en el cumplimiento de una solicitud de servicio. En la mayoría de los casos no
habrá necesidad de crear funciones adicionales o puestos.
En casos excepcionales en los que un número muy elevado de solicitudes de servicio se manejen,
o cuando las solicitudes son de importancia crítica para la organización, puede ser conveniente
contar con una o más miembros del equipo de gestión de incidentes dedicado al manejo y
gestión de solicitudes de servicio
GESTIÓN DEPROBLEMAS
Dueño del Proceso de Gestión de Problemas

 Diseño de modelos de problemas y flujos de trabajo
218
para el diseño e implementación de la gestión de problemas, gestión de incidentes,
gestión de eventos, gestión de acceso y cumplimiento solicitudes
Gerente del Proceso de Gestión de Problemas

Debe haber una persona designada (o, en organizaciones más grandes, un equipo), responsable
de la gestión de problemas. Las organizaciones más pequeñas pueden no ser capaz de justificar
un recurso a tiempo completo para este rol, en estos casos puede ser combinada con otras
funciones, pero es esencial que no se deje solo a los recursos técnicos para llevar a cabo esta
función. Es necesario que haya un único punto de coordinación y un propietario de las
actividades de Gestión de problemas.
Las responsabilidades del gerente del proceso de gestión de Problemas habitualmente,
incluirán:
 Planificación y gestión del soporte para las procesos y herramientas de gestión de
Problemas
 Coordinar interfaces entre la Gestión de problemas y otros procesos de gestión de
servicios
 Servir de enlace con todos los grupos de resolución de problemas para asegurar la
resolución rápida de los problemas dentro de los objetivos del SLA
 La propiedad y el mantenimiento de la KEDB
 Responsable de la inclusión de todos los errores conocidos y la gestión de los algoritmos
de búsqueda
 Cierre formal de todos los registros de problemas
 Servir de enlace con los proveedores, contratistas etc., para garantizar que los terceros
cumplan con sus obligaciones contractuales, en especial en lo que respecta a la
resolución de problemas y el suministro de información y datos relacionada con el
problema
 Organizar, ejecutar, documentar y todas las actividades de seguimiento relativas a los
revisión de problemas mayores
Analista de Gestión de Problemas

La resolución de los problemas es probable que sea realizada por uno o más grupos de soporte
técnico y / o proveedores o contratistas de apoyo. Estos pueden incluir los recursos de apoyo
que pueden trabajar en muchas áreas diferentes, pero se reunirán para llevar a cabo actividades
de resolución de problemas bajo la coordinación del gerente dela gestión de problemas.
Las responsabilidades del analista problemas típicamente incluyen:

 Revisión de los datos de incidentes para analizar los problemas asignados
 Analizar los problemas para una correcta priorización y clasificación
 Investigar los problemas asignados a través de la resolución o de la causa raíz
 Coordinar las acciones de otros que sean necesarios para ayudar en las acciones de
análisis y resolución de problemas y errores conocidos
 Crear RFCs para resolver problemas
 Monitoreo del progreso en la resolución de los errores conocidos y asesorar a el
personal de manejo de incidentes sobre la mejor solución disponible para los incidentes
219
 Actualización de la KEDB con errores conocidos y soluciones temporales nuevas o

actualizadas.
 Asistir en el manejo de incidentes mayores y la identificación de sus causas
Cuando un problema individual es lo suficientemente grave y lo justifique, un equipo de gestión

de problemas dedicado debe ser formulado para trabajar juntos en la superación de este problema
en particular. El resolutor del problema tiene el rol de asegurar que el número y nivel de los
recursos está disponible en el equipo y que exista la comunicación para la escalación y la cadena
de gestión de todas las organizaciones interesadas.
GESTIÓN DE ACCESO
Dueño del Proceso de Gestión de Acceso

 Diseño de modelos de Accesos y flujos de trabajo
para el diseño e implementación de la gestión de problemas, gestión de incidentes,
gestión de eventos, gestión de acceso y cumplimiento solicitudes
Gerente del Proceso de Gestión de Acceso

 Planificación y gestión del soporte para las procesos y herramientas de gestión de
Accesos
 Coordinar Interfaces entre la gestión de accesos y otros procesos de gestión de
servicios
Nota: Debido a que la Gestión de Acceso es la ejecución de la gestión de seguridad y

disponibilidad, estas dos áreas serán responsables de la definición de los roles adecuados. Es
importante que haya un proceso de gestión de acceso único y un único conjunto de políticas
relacionadas con la gestión de los permisos y el acceso. Este proceso y las políticas
relacionadas son susceptibles de ser establecidas y mantenidas por la gestión de seguridad de
información y ejecutado por las funciones de operación de diversos servicios. Sus actividades se
pueden resumir de la siguiente manera.
Personal del Service Desk

El Service Desk puede ser utilizado como un medio para solicitar el acceso a un servicio. Esto se
realiza normalmente utilizando una solicitud de servicio. El Service Desk validará la solicitud
mediante la comprobación de que la solicitud ha sido autorizada en el nivel apropiado de
autoridad, que el usuario es un empleado legítimo contratista o cliente y que reúnen los
requisitos para el acceso.
Una vez realizadas estas comprobaciones (por lo general mediante el acceso a las bases de
datos y documentos pertinentes SLM) se remitirá la solicitud al equipo apropiado para facilitar
el acceso. Es muy común que la mesa de servicio delegue la responsabilidad de proporcionar el
acceso a servicios simples durante la llamada.
El Service Desk también será responsable de la comunicación con el usuario para asegurarse de
que saben que el acceso ha sido concedido, y para garantizar que reciban cualquier otra ayuda
220
requerida. El Service Desk también está bien capacitado para detectar y reportar incidentes
relacionados con el acceso. Por ejemplo, los usuarios que intentan acceder a los servicios sin
autorización, o usuarios que denuncian incidentes que indican que un sistema o servicio se ha
utilizado de forma inapropiada, es decir, un ex empleado que utiliza un nombre de usuario
antiguo para acceder y realizar cambios no autorizados.
Personal de Gestión Técnica y Gestión de Aplicaciones

La Gestión Técnica y Gestión de Aplicaciones desempeñan varias funciones importantes de la
siguiente manera:
 Durante el diseño del servicio, se asegurarán de que se creen mecanismos para
simplificar y controlar la administración de accesos para cada servicio que está
diseñado. Ellos también deben especificar las formas en la que pueden ser detectados
y detenidos los abusos de los permisos.
 Durante la transición del servicio, pondrá a prueba el servicio para asegurarse de
que el acceso se puede conceder, controlar y prevenir como fue diseñado
 Durante la operación del servicio, estos equipos normalmente realizan la gestión de
acceso a los sistemas bajo su control. No es habitual que los equipos tengan a una
persona dedicada a gestionar la administración de accesos, sino que cada gerente o
jefe de equipo se asegurará de que los procedimientos correspondientes se definan y
se ejecutan de acuerdo con los requisitos y políticas del proceso.
 La Gestión técnica y la gestión de aplicaciones también estarán involucrados en el
manejo de incidentes y problemas relacionados con la Gestión de accesos
 Si las actividades de la Gestión de Accesos se delegan al Service Desk o a la gestión
de operaciones, la gestión técnica y la gestión de aplicaciones debe asegurar que el
personal esté debidamente capacitado y que tengan acceso a las herramientas
necesarias para que puedan realizar estas tareas
Personal de la Gestión de Operaciones de TI

Cuando la operación de TI está separada de la gestión técnica o la gestión de aplicaciones, es
común que las tareas operativas de gestión de acceso se deleguen en la gestión de operaciones
de TI. Los operadores de cada área se encargarán de suministrar o revocar el acceso a sistemas
clave o recursos. Las circunstancias en las que pueden hacerlo y las instrucciones de cómo
hacerlo, deben ser incluidas en los manuales para esos equipos.
El puente operaciones, si existe, se puede utilizar para controlar los eventos relacionados con la
Gestión de Acceso e incluso puede proporcionar soporte de primera nivel y la coordinación en
la resolución de esos eventos en su caso.
221
222
223
Debido a que la Operación del Servicio es considerada como el negocio del día a día, a veces hay
una tendencia a no utilizar la gestión de proyectos, cuando es totalmente apropiado para hacerlo
(por ejemplo, para cambios de infraestructura de gran tamaño). La utilización de la gestión
proyectos asegura que el nivel adecuado de controles se aplique y que los costos y los recursos
se gestionen de manera adecuada.
224
Todos los grupos de TI estarán involucrados durante el Diseño del Servicio y Transición del
Servicio para garantizar que los componentes o servicios nuevos están diseñados, probados y
aplicados para proporcionar los niveles correctos de funcionalidad, disponibilidad de
capacidad, etc.
Además, el personal de Operación del Servicio debe participar durante las primeras etapas de
Diseño del Servicio y Transición del Servicio para garantizar que cuando los nuevos servicios
lleguen al entorno operativo sean adecuados a los objetivos, desde una perspectiva de
Operación del Servicio, y sean "soportables" en el futuro.
Tenga en cuenta que el cambio no es sólo tecnología. También se requiere capacitación, la

sensibilización, el cambio cultural, los problemas de motivación y mucho más.
225
Hay una serie de factores que las organizaciones necesitan para planificar en la preparación, y
durante la implementación y aplicación de las herramientas de soporte de ITSM. Estos incluyen
los siguientes.
Licencias
El costo global de las herramientas de ITSM, en particular la herramienta integrada que
constituirá el núcleo del conjunto de herramientas requeridas, generalmente se determina por el
número y tipo de licencias de usuario que la organización necesita.
Estas herramientas se venden a menudo en formato modular, por lo que la funcionalidad exacta
de cada módulo debe ser bien comprendida y algunos dimensionamiento inicial debe llevarse a
cabo para determinar el número - y de qué tipo - de los usuarios tendrán acceso a cada módulo
Las licencias a menudo están disponibles en los siguientes tipos (la terminología exacta puede
variar dependiendo de su proveedor de software).
Licencias Dedicadas
Para uso de los empleados que requieren un uso frecuente y prolongado del módulo (por
ejemplo, personal de Service Desk necesita una licencia especial para utilizar un módulo de
Gestión de Incidentes).
Licencias compartidas
Las licencias que son compartidos por los usuarios que no necesitan tener acceso a la
herramienta de forma prolongada o módulos de la misma. Las licencias compartidas son a
226
menudo más caras que las licencias dedicadas pero debido a su naturaleza no es necesario tener
muchas de ellas.
Licencias Web
Las licencias web ofrecen una forma de interfaz ligera para los usuarios con requisitos mínimos
en cuanto a la funcionalidad de las herramientas. Estos normalmente se ejecuta a través de la
web de como Software como Servicio (SaaS) basado soluciones. Un ejemplo de una solución
está accediendo a la autoayuda. Estas licencias son a menudo mucho más baratas que otros tipos
y en algunos casos se ofrecen sin costo alguno.
Algunos miembros del personal pueden requerir el acceso a las licencias múltiples (por ejemplo,
personal de soporte puede requerir una licencia exclusiva o compartida en la oficina durante el
día, pero puede requerir una licencia web en la prestación de apoyo fuera del horario de casa).
Tenga en cuenta que las licencias puedan ser necesarios para los clientes / usuarios /
proveedores utilizando la misma herramienta para crear, ver o actualizar o reportes o registros.
Tenga en cuenta que algunos acuerdos de licencia (de cualquiera de los tipos mencionados
anteriormente) pueden restringir el uso del software a un dispositivo individual o CPU.
Servicio bajo demanda

Ha habido una tendencia en la industria de TI para que los proveedores de TI puedan ofrecer
aplicaciones "bajo demanda", donde se da acceso a la aplicación por un período de demanda y
luego se termina el acceso cuando ya no es necesario - y es basado en el tiempo dedicado al
uso de la aplicación. Este tipo de acceso puede ser ofrecido por algunos proveedores de
herramientas ITSM - que podría ser atractivo para las organizaciones más pequeñas o si las
herramientas en cuestión están muy especializadas y se utiliza con poca frecuencia.
En todos los casos, la estructura de las licencias debe ser investigada y comprendas a fondo
durante las investigaciones de contratación y mucho antes de que las herramientas sean
Implementadas, esto para que el costo final no venga con ningún tipo de sorpresa.
Implementación
Muchas herramientas de ITSM, particularmente de descubrimiento y herramientas de
supervisión de eventos, requerirá algún software de cliente / agente de implementación en todas
las ubicaciones de destino antes de que puedan ser utilizadas. Esto necesitará una cuidadosa
planificación y ejecución, y deberá ser manejado a través de la Gestión de Liberaciones e
implementación.
A pesar de que la implementación por red sea posible, esto necesitará una cuidadosa
programación y pruebas y los registros deben mantenerse durante toda la implementación para
que el personal de soporte conozca que ha sido actualizado y que no. Alguna forma de Gestión
de Cambios puede ser necesaria y la CMS debe ser actualizado a medida que avanza la
implementación.
227
A menudo es necesario reiniciar dispositivos para que el software del cliente sea reconocido - y
esto debe ser arreglado de antemano, de lo contrario se pueden producir retrasos largos si el
personal generalmente no apagar sus equipos durante la noche.
Puede haber problemas particulares en la implementación en laptops y otros equipos portátiles

y es posible que se necesiten arreglos especiales para que el personal se conecte y reciba el
nuevo software.
Comprobación de Capacidad
Asegúrese de que los lugares de destino tienen las especificaciones necesarias para recibir el
nuevo software si no tendrán que ser reemplazados.
La capacidad de la red también debe ser evaluada para determinar si se puede manejar la
transmisión de gestión de información, la transmisión de archivos de registro y la distribución
de los clientes, y también posiblemente software y los archivos de configuración.
Tiempo de despliegue de la tecnología

Hay que tener cuidado para asegurar que las herramientas se implementen en el momento
oportuno en relación con el nivel de la organización, sofisticación y conocimiento de ITSM. Si
las herramientas se implementan demasiado pronto, puede ser visto como una panacea
inmediata y las acciones necesarias para cambiar los procesos, las prácticas de trabajo o
actitudes que son un obstáculo pueden ser pasado por alto.
Algunos procesos simplemente no se puede hacer sin herramientas adecuadas, por lo que hay un
delicado equilibrio que se mantiene para asegurar las herramientas se introducen cuando se
necesitan - ¡pero no antes!
La capacitación es otro factor. La capacitación debe ser ofrecida en un "justo a tiempo".

Demasiado pronto y el conocimiento se perderá antes de que la herramienta se pueda usar,
demasiado tarde y no habrá tiempo suficiente para familiarizarse con la herramienta antes de su
liberación. Regímenes de capacitación continua también se debe planificar para nuevos usuarios,
para la demanda en curso y para usurarios futuros.
Tipos de Introducción
Una decisión que se necesita sobre el tipo de introducción que es necesario - si ir para la
introducción de un 'Big Bang' o algún tipo de enfoque por etapas. Como la mayoría de las
organizaciones no comenzará a partir de una situación de "greenfield (totalmente nuevo)", y
contará con servicios en tiempo real para seguir funcionando durante la introducción, un
enfoque gradual es más probable que sea necesario.
En muchos casos, una nueva herramienta será la sustitución de una antigua, probablemente
menos sofisticada, la herramienta y el cambio entre las dos es otro factor que debe ser
planificado.
A menudo, esto implica decidir qué datos necesitan ser migrados de la herramienta vieja a la
nueva - y esto puede requerir reformatear los datos para lograr los resultados requeridos.
228
Idealmente, esta transferencia debe hacerse electrónicamente, pero en algunos casos, una
pequeña cantidad de datos tienen que ser retrabajados y esto se debe de tenerse en cuenta en los
planes.
Precaución: generalmente las herramientas viejas dependen más de entradas y mantenimiento

manuales de los datos de modo que si la migración de datos es electrónica, una auditoría debe
llevarse a cabo para verificar la calidad de los datos.
Cuando la transferencia de datos es complicado o consume mucho tiempo para logarla, una
alternativa podría ser la de establecer un período de corrida en paralelo - con la vieja
herramienta disponible por un período inicial junto a la nueva, de modo que los se pueda hacer
referencia a los datos históricos si es necesario. En tales casos, será prudente que la
herramienta anterior sea sólo lectura porque se pueden cometer errores al ingresar los nuevos
datos en la herramienta antigua
Restos para Operación del Servicio

 Falta de compromiso con el personal de desarrollo y de proyectos
 Justificación de fondos - la inversión en esta área es a menudo visto como una sobrecarga
de la infraestructura. Algunos ejemplos en los que un ROI positivo se pueden hacer son:
o Reducción de los costos de licencias de software a través de una mejor gestión de las
licencias y copias implementadas
229
o Reducción de los costos de soporte, debido a un menor número de incidentes y

problemas y reducción de los tiempos de resolución
o Reducción de plantilla a través de procesos más acordes, que conducen a una menor
duplicación de actividades y un mejor uso de los recursos existentes
o Menos "perdida de negocio” debido a la mala calidad de servicios de TI
o Mejor utilización de la infraestructura existente y el aplazamiento de los gastos
debido a la una mejor Gestión de la Capacidad
Restos para los Gerentes de Operación del Servicio

Debido a las diferencias entre las actividades de diseño y las operativas la siguiente es una lista
de algunos de los retos que los gerentes de la Operación del Servicio deben esperar enfrentar.
 Diseño de servicios tiende a concentrarse en un servicio individual a la vez, mientras
que la Operación del Servicio tiende a centrarse en la entrega y el apoyo a todos los
servicios al mismo tiempo. Los Gerentes de la Operación deben trabajar en estrecha
colaboración con Diseño del Servicio y Transición del Servicio para facilitar la
perspectiva de operación para asegurar que los resultados del diseño y de la transición
apoyen totalmente las necesidades de operación
 El Diseño de servicio a menudo se llevará a cabo en proyectos, mientras que la
Operación del Servicio se centra en las actividades y procesos de gestión en curso.
Resultado de esto es que el personal de operaciones a menudo no están disponible para
participar en las actividades de proyectos de Diseño de servicios, esto se traduce en
servicios de TI que son difíciles de manejar, o que no incluyen suficientes elementos de
administración de diseño. Además, el personal de proyectos una vez que haya terminado
el diseño de un servicio de TI podría pasar al siguiente proyecto y no estará disponible
para apoyar a las dificultades en el entorno operativo. Superar este reto requiere que la
Operación del Servicio planifique que su personal participe activamente en proyectos
de diseño, involucrarse en las actividades de transición y participar en el soporte
temprano de los servicios introducidos en el entorno operativo
 Las dos etapas en el ciclo de vida tienen diferentes métricas, lo que alienta a Diseño del
Servicio a completar el proyecto a tiempo, según las especificaciones y dentro del
presupuesto. En muchos casos, es difícil prever como se verá cómo y cuánto va a costar
el servicio después de que se haya implementado y operado por algún tiempo. Cuando no
se ejecuta como se esperaba, la Gestión de Operaciones será la responsable. Si bien este
desafío siempre será una realidad en la gestión de servicios, esto puede resolverse
mediante la participación activa en la etapa de transición de servicio del ciclo de vida.
El objetivo de la Transición del Servicio es asegurar que los servicios diseñados
funcionará como se esperaba y el gerente de operaciones pueda proporcionar los
conocimientos necesarios para la Transición del Servicio para evaluar y remediar, los
problemas antes de que se conviertan en problemas en el entorno operativo
 Transiciones de Servicio que no se utilizan efectivamente para manejar la transición
entre las etapas de diseño y operación. Por ejemplo, algunas organizaciones sólo utilizan
la Gestión de Cambios para programar la implementación de los cambios que ya se han
hecho - en lugar de probar para ver si el cambio hará correctamente la transición entre
el diseño y la operación. Es imperativo que las prácticas de Transición del Servicio
sigan las políticas de la organización para prevenir prácticas de mala Gestión de
230
Cambios. Los Gerentes de Operación, Cambios y Transición debes tener la autoridad

para negar cualquier cambio que no se pruebe antes de llevarlo al entorno operativo.
Estos retos sólo pueden abordarse si el personal de Operación del Servicio participa en el
Diseño del Servicio y la Transición, y para ello será necesario que estén formalmente
encargados para hacer esto y sean medidos. Los roles identificados en los procesos de Diseño
del Servicio se debe incluir en la Gestión técnica y la Gestión de aplicaciones de TI incluyendo
descripciones de puestos del personal y el tiempo asignado a cada proyecto por proyecto.
Uno de los retos más importantes que enfrentan los gerentes de Operación del Servicio es el
equilibrio de muchas relaciones internas y externas. La mayoría de las organizaciones de TI hoy
en día son complejas y conforme un servicio se convierte más en un “commodity” hay un
incremento de valoren uso, asociaciones y modelos de servicios compartidos. Mientras que esto
es una ventaja significativa para las dinámicamente cambiantes necesidades de negocio, esto
aumenta la complejidad de la gestión de los servicios cohesiva y eficiente y proporcionar la
costura invisible entre el cliente y la intrincada red de cómo los servicios son efectivamente
entregados.
Un gerente de Operación del Servicio debe invertir en conocimientos de gestión de relaciones y
habilidades para ayudar a lidiar con la complejidad de este desafío.
Además, hay desafíos genéricos que no sólo aplican a la Operación del Servicio, sino en todo el
ciclo de vida completo. Estos pueden incluir:
 Habilitación de casi todos los procesos de negocios y servicio de TI, lo que resulta en un
gran grupo de clientes e interesados que está involucrados y afectados por las prácticas
y procesos de gestión de servicios.
 Armonización y la integración de los procesos y disciplinas utilizadas en todo el ciclo de
vida
 Lograr un equilibrio entre el pragmatismo y burocracia
 Crear un ambiente que fomente la estandarización, simplificación y difusión del
conocimiento
 Establecimiento de "quién está haciendo qué, cuándo y dónde" y "quién debe hacer qué,
cuándo y dónde"
 Desarrollo de una cultura que anime a la gente a colaborar y trabajar juntos de manera
efectiva y un ambiente que fomente los cambios culturales necesarios para obtener un
compromiso de las personas
 El desarrollo de las métricas de rendimiento y métodos de medición estándar
 Entender los requerimientos del negocio y las prioridades de negocio y asegurar que
estos sean lo más importante a tener en mente al diseñar e implementar los procesos
 Comprensión de la gente y la cultura de la organización y la resistencia potencial de
cambiar
 La comunicación eficaz tanto para explicar lo que está sucediendo y cómo las personas
se verán afectadas y escuchar los requerimientos y necesidades de los individuos
 Obtener el compromiso de la alta dirección, así como de todos los niveles del personal
 Falta de información, monitoreo y métricas
231
 Perdida de Servicio: El riesgo fundamental para el negocio en Operación del Servicio

es la pérdida de servicios críticos de TI con el consiguiente impacto negativo sobre sus
empleados, clientes y finanzas
 Falta de fondos y de recursos: Los fondos deben estar justificadas, asignados y
mantenidos en reserva para su propósito original
 Pérdida del impulso: Cuando el personal la gestión del servicio ve como "sabor del
mes" en lugar un cambio permanentemente la forma de trabajar para el futuro, como
resultado se pierde cualquier impulso
 Perdida del personal clave: : A veces la pérdida de una o dos personas clave puede
tener un impacto severo: para tratar de minimizar este efecto, las organizaciones deben
buscar capacitar al personal de forma integral y reducir la dependencia en los
individuos
 Resistencia al cambio: A veces la gente suele oponerse a cosas nuevas y no están
dispuestos a cambiar. Destacar los Beneficios de educación, formación, comunicación
ayudará
 Falta de apoyo de la Dirección: A menudo, esto ocurre entre los mandos medios que no
pueden ver la visión global o poner las manos en los beneficios que más personal
subalterno puede ganar
 Diseño defectuoso: Si el diseño inicial es defectuosa, una implementación exitosa nunca
dará los resultados necesarios – y el rediseño en última instancia, será necesario
 Desconfianza: En algunas organizaciones la gestión de servicios puede ser vista con
recelo tanto por TI y el negocio. El personal de TI lo ve como un intento de controlarlos,
mientras que el negocio lo percibe como un intento de TI para obtener más fondos sin
tener que mejorar algo
232
 Diferentes expectativas del cliente: Mientras que el personal operativo es animado a

ejecutar las normas, las expectativas de los clientes y usuarios a veces difieren. En otros
casos, un cliente puede haber pagado más por un servicio superior, pero cuando un
usuario de un área diferente ve el servicio superior, se sienten engañados
Además, existen riesgos genéricos que no sólo se aplican a la Operación del Servicio, sino en
todo el ciclo de vida completo. Estos pueden incluir:
 Baja madurez en un proceso afecta a los demás

 Sobre o sub-ingeniería de procesos
 Pobre integración de los procesos
 Requisitos de negocio poco claros
 Falta de tiempo, recursos y presupuesto
 El balance incorrecto entre la innovación, el riesgo y el costo
 Infraestructura, clientes y socios mal alineados que comprometen el cumplimiento de los
requisitos generales de la empresa
 Rendición de cuentas, la responsabilidad y la práctica de los cambios que desmotivan la
fuerza de trabajo
 Alineación del personal clave
 Costos adicionales no planificados
 Resistencia al cambio
 Compartir el conocimiento
 Sistemas inmaduros y herramientas con poca o ninguna integración
233
Apoyo de la Dirección
El Apoyo de la dirección es esencial para la obtención y mantenimiento del financiamiento y
dotación de recursos. El apoyo debe ser visible y demostrado
Apoyo del Negocio

El negocio debe de apoyar la operación de servicio. Donde una apropiada Operación de servicio
debe implicar al negocio y buscar oportunidades para mejorar.
Campeones (Champions)
La capacidad de guiar a otros a través de su entusiasmo y compromiso para ITSM. Los
“Champions” pueden venir de todos los niveles de la organización, desde la alta dirección o más
miembros jóvenes del personal. Los “Champions” a menudo surgen como producto de los
programas de capacitación formales
Reclutamiento y retención del personal

Asegurar el número adecuado de personal con las habilidades necesarias es fundamental. Los
desafíos incluyen:
 Proyectos para nuevos servicios suelen ser bastante buenos en las especificaciones de
nuevas habilidades requeridas, pero a menudo subestiman el número de personal
requerido y la forma de retener a los nuevos conocimientos
 Escasez de recursos (personal) que tienen una buena comprensión de la gestión del
servicio. Tener gente técnica capacitada es necesaria, pero es necesario que haya un
número de personas clave que sean capaces de moverse entre los temas de tecnología y
las cuestiones de servicio
234
 Debido a que estas personas claves son bastante escasos, es bastante común
capacitarlos, sólo para que ellos renuncien y se unan a otra compañía por un mejor
salario. Caminos claros de carrera e incentivos buenas deben formar parte de todas las
iniciativas de gestión de servicios
 Intentar asignar demasiado, demasiado pronto al personal existente. El logro de la
Operación del Servicio eficiente tomará tiempo, pero si se aborda correctamente, se
logrará
 Entrenamiento y tutoría en curso deben estar siempre disponibles para apoyar
proactivamente las necesidades de personal, y abordar sus problemas y las
preocupaciones
 Capacidades automatizadas o de alguna otra forma, debe tener lugar para fomentar una
cultura de trabajo en equipo y que las personas puedan trabajar bien en equipo
Capacitación de Gestión de Servicios

Inculcar una cultura de gestión de servicios a través de programas de formación y sensibilización
es fundamental para el éxito de la gestión del servicio en cualquier organización. La gente tiene
que entender lo que significa para ellos y cuáles son sus responsabilidades. Ejemplos de
capacitación potencial de gestión de servicios incluyen:
 La formación del personal de TI sobre los procesos que se han implementado. Esto
incluirá capacitación genérica para que entiendan los conceptos completamente, así
como de capacitación especialmente dirigida a los procesos propios de la organización
 Capacitación sobre o “habilidades suaves” o de “personas”, especialmente para los
empleados en posiciones de cara al cliente
 Capacitación sobre la comprensión del negocio, y la importancia de lograr una cultura
de servicio
 Cuando las implementan herramientas , debe de haber capacitación sobre cómo utilizar
y gestionar esas herramientas
 Asimismo, los clientes y los usuarios necesitan una capacitación adecuada sobre cómo
trabajar con TI- servicios de acceso, solicitar cambios, presentar solicitudes, usar
herramientas, etc.
 Capacitación sobre herramientas y técnicas que permitan a los individuos para trabajar
bien dentro de los equipos
Herramientas Adecuadas
Muchos procesos y actividades de Operación del servicio no pueden realizarse eficazmente sin
las herramientas adecuadas.
Validez de las pruebas

La calidad de los servicios de TI proporcionados en la operación de servicio depende de la
calidad de los sistemas y componentes entregados en el entorno de operación.
235
Medición y Presentación de Informes

Definir cómo las cosas van a ser medidas y reportadas a fin de que se comprendan los objetivos
y la dirección puede identificar las áreas que necesitan atención.
CSFs de Transición a Operación

La prestación de servicios, en todas las organizaciones, tiene que ser adaptado a las exigencias
actuales y cambiantes de negocio. El objetivo es mejorar continuamente la calidad del servicio,
alineado a los requerimientos del negocio, de manera rentable. Para cumplir este objetivo, los
siguientes factores críticos de éxito se deben considerar para la Transición del Servicio:
 Comprender y manejar las diferentes perspectivas de los interesados en las que se basa
la gestión eficaz de los riesgos dentro de una organización y el establecimiento y
mantenimiento de grupos de interés generando el compromiso
 Tener relaciones e interfaces definidas con la gestión de proyectos
 Mantener los contactos y gestionar todas las relaciones durante la transición del
servicio
 La integración con las otras etapas del ciclo de vida, procesos y disciplinas que
impactan la transición servicio
 Entender las dependencias inherentes entre los sistemas heredados, las nuevas
tecnologías y los elementos humanos que dan lugar a las dependencias desconocidas y
son riesgosos para cambiar
 Automatización de procesos para eliminar errores y reducir el tiempo de ciclo
 Crear y mantener conocimientos nuevos y actualizados en forma que las personas
puedan encontrarlo y utilizarlo
 El desarrollo de sistemas de buena calidad, las herramientas, los procesos y
procedimientos necesarios para gestionar una transición práctica de servicio
 Buena gestión de servicio , tecnología y buenas herramientas de Infraestructura
 Ser capaz de valorar y aprovechar el entorno cultural y político
 Ser capaz de comprender las configuraciones de servicio y técnicos y sus dependencias
 Desarrollar un conocimiento profundo de los factores duros (procesos y procedimientos)
y los factores blandos (habilidades y competencias) necesarios para gestionar una
transición práctica de servicio
 El desarrollo de una fuerza laboral con los conocimientos necesarios y habilidades, la
formación adecuada y la correcta cultura de servicio
 Definir claramente las responsabilidades finales (accountabilities), funciones y
responsabilidades
 El establecimiento de una cultura que permita compartir el conocimiento libre y
voluntariamente
 Demostrar la mejora en el ciclo de tiempo para la implementación de un cambio y
menor variación en la predicción del tiempo , costo y calidad durante y después de la
transición
 Demostrar mejoras en la satisfacción de los usuarios y clientes durante la transición de
servicio
236
 Demostrar que los beneficios de establecer y mejorar las prácticas de transición de

servicios y los procesos de transición de servicios son mayores que los costos (a través
de la organización y los servicios)
 Ser capaz de comunicar la actitud y el enfoque de la organización a los riesgos a través
de la gestión de riesgos con mayor eficacia en las actividades de servicios de transición
 La construcción de un conocimiento profundo de los riesgos que han afectado o podrían
afectar las transiciones de servicio exitosas en el portafolio de servicios
237
238
ITIL® Intermediate Capability Stream:
OPERATIONAL SUPPORT AND ANALYSIS (OSA)

CERTIFICATE
Sample Paper 2, version 6.1
Gradient Style, Complex Multiple Choice
SCENARIO BOOKLET
This booklet contains the scenarios upon which the eight examination questions will be based. All
questions are contained within the Question Booklet and each question will clearly state the scenario
to which the question relates. In order to answer each of the eight questions, you will need to read the
related scenario carefully.
On the basis of the information provided in the scenario, you will be required to select which of the
four answer options provided (A, B, C or D) you believe to be the optimum answer. You may choose
ONE answer only, and the Gradient Scoring system works as follows:
• If you select the CORRECT answer, you will be awarded 5 marks for the question
• If you select the SECOND BEST answer, you will be awarded 3 marks for the question
• If you select the THIRD BEST answer, you will be awarded 1 mark for the question
• If you select the DISTRACTER (the incorrect answer), you will receive no marks for the
question
In order to pass this examination, you must achieve a total of 28 marks or more out of a maximum of
40 marks (70%).
© The Official ITIL Accreditor 2012. The Swirl logo™ is a trade mark of the Cabinet Office.
ITIL® is a registered trade mark of the Cabinet Office. ITIL Intermediate Capability OSASample2 SCENARIO BOOKLET v6.1.
This document must not be reproduced without express permission from The Accreditor.
Page 1 of 9
Version 6.1 (Live) Owner – The Official ITIL Accreditor
Scenario One
You are the IT service manager for a large financial services provider, and are responsible for the
end-to-end services provided by the existing legacy mainframe systems. You report to the chief
information officer (CIO). Reporting to you are the development teams, the project and programme
management team, the IT operations teams, including the data centre manager, and the continual
service improvement team.
In order to update the services and to position the company for the commercial challenges ahead, it
has been agreed at board level that the infrastructure will be redesigned and the current 20 systems
migrated and consolidated onto a single new service. This new service will greatly reduce IT operating
costs for both manpower and technology, and will enable the business divisions to radically
restructure their operating capability.
The transformation programme started three months ago. It is still in the planning phase and has only
just received final sign-off from the board. Resources are currently being identified and engaged to
join the programme team, the communication plan is being developed, and the programme risks,
assumptions and constraints are being refined. No detailed design has yet been undertaken, and the
overall programme is expected to last two years.
You have learned that the programme director is calling an initial meeting next week to officially
launch the programme, to outline the programme proposition, and to get input from all those involved.
© The Official ITIL Accreditor 2012. ITIL Intermediate Capability OSASample2 SCENARIO BOOKLET v6.1.
Page 2 of 9
Version 6.1 (Live) Owner –The Official ITIL Accreditor
Scenario Two
A well-known insurance company has improved its business over the last 10 years by exploiting the
internet. It relies on many IT services to provide its external customers with the ability to obtain fast
and accurate quotes from the company’s website.
It is a dynamic company that retains a competitive advantage by responding quickly to trends in the
insurance market with new offerings to external customers. This requires that the staff and business
processes are flexible so that the company can respond rapidly to market needs. Accordingly, the
company encourages staff to change or share roles regularly. This results in many requests to move
or purchase IT equipment. There are also frequent requests to make changes to system access when
users change roles.
You are the service desk manager and joined the company three months ago. Until now, the service
desk has dealt with all service requests as incidents. You are in the process of planning to implement
a request fulfilment process. The process will be initiated by service desk staff and involves other
support groups. Service requests will continue to be logged in the incident management system but
will be categorized as ‘requests’ for workflow and reporting purposes.
You are analysing the most frequently occurring service requests that the new process will handle
and have produced a report of some of the common calls that are received by the service desk. This
report is shown below:
Item # Incident description

1 User reported error with PC – faulty mouse replaced by desktop team
2 User request to add two new fields to the customer screen of the sales system
3 User request to purchase a new toner cartridge for printer
4 User reported slow response when using e-mail applications
5 User request for advice on how to use a spreadsheet application
6 User reported a printer failure
7 User forgot password – password reset
8 User required additional access to the sales system
9 User submitted request to move their PC to a different office
10 User unable to log into PC
Page 3 of 9
Scenario Three
An organization has recently purchased a new event management support tool that the service
operation team is in the process of installing and configuring. A particular question has come up
regarding the retention of data relating to events that occur.
All people involved have agreed that events that are classified as ‘warning’ or ‘exception’ need to be
retained for a lengthy period after the event has been dealt with.
However, concerns regarding the amount of space that will be required and the volume of data to be
stored and potentially accessed, have caused some senior technical staff to propose that events
categorized as ‘informational’ need only be retained for a minimal period. A retention period of one
week has been proposed, the logic being that if any follow-up issues have not occurred by then they
are extremely unlikely to occur at all.
Other team members have argued that this does not make sense. The data may be needed for some
time beyond this point, so should be retained indefinitely.
The organization’s legal department has advised that there may also be legislative or compliance
issues and if so the data may need to be retained for up to six years.
Page 4 of 9
Scenario Four
A financial services organization with offices worldwide has begun a three-year project to replace
many of the legacy applications hosted on their mainframe with web-based services. The project is
part of a strategic corporate initiative to streamline key business processes and to make better use of
IT to create competitive advantage. The goals of this initiative are to:
• Reduce costs
• Maximize resources
• Improve enterprise-wide information security
• Ensure compliance with legislative and regulatory controls.
When the new web-based services are available, varying levels of access to these services will be
granted to employees, contractors and, in some cases, select customers. Business sponsors have
emphasized that because the current market place is extremely dynamic and competitive, it is critical
that access is granted as quickly as possible when requests are submitted. However, security is also
a concern and the business expects IT to play a key role in securing the organization’s information
assets.
A new access management process has been implemented that is based on ITIL best practices. A
project is underway to clarify the procedures for creating and utilizing user profiles to grant and
manage access on an ongoing basis.
Page 5 of 9
Scenario Five
A large insurance company has grown rapidly in the past several years through a series of
acquisitions. The acquired companies continue to operate fairly autonomously, each with its own IT
department; however, several corporate systems, such as e-mail and an enterprise resource planning
(ERP) system, have been deployed. A new corporate document management system (DMS) is in the
process of being deployed.
A centralized service desk provides a single point of contact for managing incidents and the separate
IT departments each support their own systems and also provide second and third-line support for the
corporate systems to their respective user communities. A common set of high-level incident
management procedures is being followed, although each of the IT departments is still using its own
logging and management system.
The chief executive officer (CEO) oversees a chief information officer (CIO) group comprising the
CIOs from each of the separate IT departments. The CEO has challenged this group to identify
opportunities to reduce costs, share resources, and consolidate operational activities. The CEO is
also frustrated by recent problems encountered when deploying the new DMS and significant outages
affecting the ERP system. To date, a lack of data gathering standards has made it difficult to
investigate and analyse these problems. However, the CIO Group needs to quickly determine why
these problems are occurring and to establish ways of minimizing the impact, because both of these
systems are critical to the company’s overall success.
Discussion is under way to determine how to make best use of existing resources – particularly the
technical and application management resources – to deal with these issues. Each of the IT
departments is experiencing staffing shortages and most CIOs indicate that their technical and
application management functions are currently over-utilized.
Page 6 of 9
Scenario Six
A construction company designs and implements customized projects for clients. The company is
heavily dependent on their IT organization which develops specialized in-house solutions for them.
Several times in the past, these solutions provided a clear strategic advantage over their competition
and for this reason the company has retained a high level of specialized experts. The company is also
using a standard enterprise resource planning (ERP) system and a standard desktop software
package and has acquired a high level of expertise in supporting these services.
ITIL best practices have been implemented within the company and most of the processes are
considered effective and efficient. The service desk owns the problem management process. It is
perceived as being very effective because it managed to solve 103 out of 104 identified problems last
year, and the mean time for solving a problem was five days. Service level agreements (SLAs) are
also in place and are actively used. The quality of service, together with the highly respected SLAs,
has built IT a solid reputation within the company.
For these reasons, the CIO is particularly shocked about recent user complaints that the number of
incidents is continually increasing and has reached an unacceptable level. You have been asked to
look into the situation and to make a proposal for the best way forward.
After analysing the incident reports from the last three years, you find that the number of incidents has
doubled to over 300,000 per year. In the same period the number of users has increased by just 12
percent. You also note that there appear to be 2,000 incidents of the same type for the ERP system.
Last year, the service desk was able to solve 81 percent of all incidents immediately while users were
on the phone. Over the course of the year there were only 29 major incidents, all of which were
solved inside the agreed resolution times. In fact, over 98 percent of all incidents were solved inside
of agreed SLA resolution times.
Page 7 of 9
Scenario Seven
The IT department of a large European supermarket chain consists of 250 staff. Generally the
department has a good reputation, but as the company has expanded, service levels have dropped.
The IT department started to implement service management six months ago; the service desk (SD)
was reviewed and improvements made, new staff employed and a revised incident management
process was introduced. While internal users welcomed this change, a number of issues were
identified.
The following report provides a representative sample of records from the incident management
system. You are the SD manager and must review the report to identify the issues that must be dealt
with.
No Category Incident description Resolution

Escalated to network team.
1010 Desktop Unable to log in to the PC network
Resolved by network team.
Could not verify user details.
1030 Request Forgotten password
Escalated to desktop team.
1060 Request User submitting RFC Escalated to SD manager.
1110 Server Windows server reboot Logged by server team.
1120 Request Request for new toner cartridge Escalated to desktop team.
1205 Desktop PC locked up when logging in Escalated to server team.
Escalated to server team.
1240 Network Network slow Network team later confirming its
resolution.
Could not locate details of printer.
1250 Printer Printing problems
Escalated to network team.
1315 Request New PC request Escalated to SD manager.
Could not locate user details so user
1330 e-mail Slow response sending e-mail requested to telephone back later if it does
not improve.
Escalated to desktop team.
1350 Server Network is very slow
Closed by network team.
Escalated to server team.
1405 Network PC hung – blue screen error Desktop team closed incident after visit to
user.
Third occurrence today so escalated to SD
1425 Desktop PC log-in problems
manager as possible problem.
Page 8 of 9
Scenario Eight
A company is seeking to recruit a service management expert to strengthen their service operation
teams, in particular the technical and operations management division. Through the standard
selection process each candidate was asked to prepare a statement outlining what they believed to
be the main objective and purpose of service operation.
The statements would then be used to select a candidate for second interview.
Candidate #1
Maintain operational stability while introducing new or changed services into supported
environments. The purpose of the service operation stage of the service lifecycle is to co-
ordinate and carry out the activities and processes required to deliver and manage services at
agreed levels from one state to another while managing risk to business users and customers.
Service operation is also responsible for the ongoing management of the technology that is used
to deliver and support services.
Candidate #2
Maintain stability in service operation, allowing for changes in design, scale, scope and
service levels. The purpose of the service operation stage of the service lifecycle is to co-
ordinate and carry out the activities and processes required to deliver and manage services at
agreed levels to business users and customers. Service operation is also responsible for the
ongoing management of the technology that is used to deliver and support services.
Candidate #3
Manage services in supported environments, achieving effectiveness and efficiency to

ensure value for the customer, the user and the service provider. The purpose of the service
operation stage of the service lifecycle is to achieve service quality, operational efficiency and
business continuity, and to ensure that the portfolio of supported services continues to be aligned
with business and user needs. Service operation is also responsible for management of the
technology used to deliver and support services.
Candidate #4
Maintain stability in the design and development of services and service management
practices. The purpose of the service operation stage of the service lifecycle is to co-ordinate the
principles and methods for converting strategic objectives into portfolios of services and service
assets to be managed. Service operation is also responsible for managing the ongoing
expectation of service performance and alignment of capabilities and business strategies.
Page 9 of 9

CERTIFICATE
QUESTION BOOKLET
Gradient Style Multiple Choice

90 minute paper
8 questions, Closed Book
Instructions
1. All 8 questions should be attempted.

2. You should refer to the accompanying Scenario Booklet to answer each question.
3. All answers are to be marked on the answer grid provided.
4. You have 90 minutes to complete this paper.
5. You must achieve 28 or more out of a possible 40 marks (70%) to pass this examination.
ITIL® is a registered trade mark of the Cabinet Office. ITIL Intermediate Capability OSASample2 QUESTION BOOKLET v6.1.
Page 1 of 9
Question One
Refer to Scenario One

As the IT service manager you are the main sponsor of the transformation programme. You have not
been invited to the initial programme launch meeting.
Which one of the following options BEST describes the actions that should be taken?
A. You recognize that this is a major programme which will impact the services provided to your
customers. As the main sponsor of the programme it is important for you to demonstrate your support
and to understand in detail exactly what is going on, and you therefore ask to be included in the
meeting. You also ask to check the meeting invitation list so that you can ensure that all IT operations
areas and functions are appropriately represented in the different phases of the programme’s life
cycle.
B. The programme is only just starting and has two years to run, so it is unlikely that any important
information will be provided at this meeting. You have learned that some of your direct reports have
been invited so you have asked them to update you following the meeting. Your plan is to let things
progress before you get involved as your main concern is the delivery and operation of the new
service.
C. You recognize that this is a major programme which will significantly impact the services provided to
your customers. As the main sponsor of the programme it is important for you to demonstrate your
support and to understand and sign off on the programme’s components, especially programme risks,
assumptions, constraints, resources and costs. You therefore ask to be included in the meeting. You
also check the meeting invitation list to ensure that all IT operations areas and functions which will
play a role in the different phases of the programme’s life cycle are appropriately represented.
D. You recognize that this is a major programme which will impact on the services being provided to
your customers. As the main sponsor of the programme it is important for you to understand exactly
what is going on and you therefore ask at this stage to be copied in on the minutes and actions from
the meeting. You may wish to be included in the meetings at a later date. You also check the meeting
invitation list to ensure that all IT operations areas and functions which will play a role in the different
phases of the programme’s life cycle are appropriately represented.
© The Official ITIL Accreditor 2012. ITIL Intermediate Capability OSASample2 QUESTION BOOKLET v6.1.
Page 2 of 9
Question Two
Refer to Scenario Two

Which of the following BEST describes those items that could be handled using a request fulfilment
process?
A. 1, 2, 3, 4, 6, 7 and 8 can be handled by request fulfilment because they are common tasks that can
follow a predetermined procedure. 9 is a request for change and should be logged and handled using
the change management process. 5 and 10 require investigation to determine the nature of the issue
and therefore should be handled as incidents.
B. 3, 5, 7, 8, and 9 can be handled by request fulfilment because they are common tasks that can follow
a predetermined procedure. 2 is a request for change and should be logged and handled using the
change management process. 1, 4, 6 and 10 require investigation to determine the nature of the
issue and therefore should be handled as incidents.
C. 2, 3, 5, 7, 8, and 9 can be handled by request fulfilment because they are common tasks that can
follow a predetermined procedure. 1, 4, 6 and 10 require investigation to determine the nature of the
issue and therefore should be handled as incidents.
D. 3, 5 and 7 can be handled by request fulfilment because they are common tasks that can follow a
predetermined procedure. 2 and 9 are requests for change and should be logged and handled using
the change management process. 8 should be handled by the access management process. 1, 4, 6
and 10 require investigation to determine the nature of the issue and therefore should be handled as
incidents.
Page 3 of 9
Question Three
Refer to Scenario Three

Based on ITIL best practice, which one of the following solutions is CORRECT?
A. There is a clear need for the ‘informational’ events to be retained. The data will be needed for
trending purposes and may be used by problem management, capacity management, availability
management and, potentially, by several other processes. You take into account the suggestions of
the organization’s legal department regarding legislative and compliance issues and define a policy
that ensures the data will be retained for a minimum of six years and three months.
B. You believe that the ‘informational’ events should be retained for a longer period than just one week,
but you are uncertain as to what the correct retention period should be. You decide to consult the
business users and those IT groups that might use the data, and to hold specific discussions with the
legal and compliance departments to decide exactly how long the data should be retained. You then
document a retention policy that ensures that all of the data is retained for the agreed period.
C. You agree with the senior technical groups that the data is extremely unlikely to be needed beyond
one week and that, on the balance of risk, the cost of retaining this data is a waste of resources. In
order to achieve the most cost-effective solution you document and implement the one-week
retention policy. You advise the legal department of your decision in case any related IT governance
issues arise in the future.
D. You believe that the ‘informational’ events should be retained for a longer period than just one week,
but you are uncertain as to what the correct retention period should be. You decide to consult the
business users and those IT groups that might use the data, and to hold specific discussions with the
legal and compliance departments to decide exactly how long the data relating to each event type is
needed. You then document a retention policy that handles each event type in accordance with the
specific business need.
Page 4 of 9
Question Four
Refer to Scenario Four

Which one of the following options BEST describes how to utilize user profiles in support of business
goals?
A. • Define a standard set of services (for example, messaging and office automation) and grant
access to all users.
• On a case-by-case basis, determine the additional services that only select customers can
access.
• Use directory services-type technology to automate the granting of access to individuals, based
on their needs.
• Establish a process with information security management that ensures that the access
management team is informed when new employees join the company so that the appropriate
level of access can be granted.
B. • Catalogue each user role requiring access and the services each role can access.
• Determine any groups users belong to that require additional access or a different level of
access such as tighter security – for example, contractors and customers.
• Work with human resources to determine the secure data that identifies each user and how
changes to the status of users such as new hires, terminations, moves, and transfers will be
communicated.
• Work with information security management to ensure compliance with local data protection
legislation and to automate the granting of access.
C. • Document the role performed by each user, along with the standard and specialized services
that support each role.
• Regularly review each role to ensure the appropriate level of access is being provided to the
associated services.
• Establish a process that ensures access management is informed when new employees join the
company so that the appropriate level of access can be granted.
• Use directory services-type technology to automate the granting of access to individuals based
on their roles.
D. • Catalogue each user role requiring access and the services each role can access.
• Determine any groups of users that may have unique requirements such as mobile users and
home office workers.
• Work with the information security management team to develop procedures for the handling of
user data to ensure compliance with local data protection legislation.
• Work with the information security management team to address the granting of access to roles
that require a tighter level of security, such as contractors and selected customers, and also to
automate the granting of access.
Page 5 of 9
Question Five
Refer to Scenario Five

Which one of the following options is the BEST approach to resolve these challenges and support the
chief executive officer’s (CEO’s) goals?
A. • Expand the scope of the centralized service desk to include all services
• Ensure the service desk is logging all incidents and problems
• Provide training and have the service desk update a known error database (KEDB) as
incidents are resolved
• Provide users with self-service access to the KEDB
• Ensure technical and application management resources are involved in continual service
improvement activities
B. • Delegate routine maintenance, back-up, restore and monitoring activities to IT operations

management
• Initiate a project to define and deploy a common set of incident and problem categories
• Establish virtual teams to handle problems, using specialists as needed
• Use technical and application management resources to populate and maintain the KEDB
• Ensure technical and application management resources are engaged early in the service
lifecycle
C. • Delegate back-up, restore and routine maintenance activities to IT operations management

• Delegate monitoring activities to the centralized service desk
• Provide users with self-service access to the KEDB
• Ensure technical and application management resources are involved in continual service
improvement activities
D. • Delegate monitoring activities to IT operations management

• Initiate a project to define and deploy a common set of incident and problem categories
• Ensure the service desk is logging all incidents and problems
• Establish a corporate problem management team and hire or transfer individuals who are
skilled in problem investigation and diagnosis techniques
Page 6 of 9
Question Six
Refer to Scenario Six

Which one of the following actions BEST describes what the chief information officer (CIO) should do
regarding the user complaints?
A. As the statistics show clearly that IT support is functioning optimally no actions are required at this
time. The service desk is solving 81 percent of all incidents while on the phone. Incident management
is solving nearly all the remaining incidents inside the agreed resolution times and problem
management is particularly effective, solving 103 problems out of 104.
B. Increase the external consultancy budget so that service desk and incident management can call
external support earlier and as required to help deal with the additional incidents during peak periods.
Even though the service level agreements are being met, this will help to satisfy the user complaints.
C. As well as owning the problem management process, appoint the service desk supervisor as the
problem manager and ensure one day each week is spent looking at the cause of incidents to
determine if more problems can be identified to enable prevention of recurring incidents
D. Appoint a new problem manager to separate the role from the incident management and service desk
roles. The problem manager should be tasked with analysing existing data to see if more problems
can be identified to enable prevention of further recurring incidents.
Page 7 of 9
Question Seven
Refer to Scenario Seven

From the information contained within the report, which one of the following BEST identifies the issues?
A. • Many requests are logged as incidents, indicating a deficiency in communicating the

difference between standard and normal changes
• Re-routing of incidents by support teams indicates a lack of incident coordination by the
service desk (SD)
• Evidence that resolution of many incidents is unrelated to the original category indicates a
lack of understanding of categorization
• Poor and incomplete incident recording indicates a lack of guidance for, or training of, the
SD staff
B. • Re-routing of incidents by support teams is evidence of poor first-line fix rate

• Evidence of incorrect incident prioritization indicates a lack of guidance to, or training for, the
SD staff
• Evidence suggests that the configuration management system is out of date or does not
support incident management (IM)
• Evidence that some users are bypassing the SD is an indication that the awareness
campaign aimed at users about SD’s role is incomplete
C. • Evidence that the SD has no access to common solutions or workarounds indicates a poor
problem management process
• Poor and incomplete incident recording indicates a lack of guidance to, or training for, the
SD staff
• Simple requests are dealt with as incidents and escalated to support teams, indicating the
need for a request fulfilment process
• Re-routing of incidents by support teams indicates an inadequacy in support teams’
operational procedures
D. • Evidence that the resolution of many incidents is unrelated to the original category indicates
inconsistent and incorrect use of categorization
• Re-routing of incidents by support teams indicates a lack of incident coordination by the SD
• Low first-line resolution rates and inconsistent handling of incidents of similar types indicate
a lack of knowledge, guidance and training
• A lack of incident ownership by the SD
Page 8 of 9
Question Eight
Refer to Scenario Eight
Which of the following candidates would MOST LIKELY be called back for a second interview?
A. Candidate #1
B. Candidate #2
C. Candidate #3
D. Candidate #4
Page 9 of 9

CERTIFICATE
ANSWERS AND RATIONALES
ITIL® is a registered trade mark of the Cabinet Office. ITIL Intermediate Capability OSASample2 ANSWERSandRATIONALES v6.1.
Page 1 of 13
Answer Key:
Scenario Question Correct: 2nd Best: 3rd Best: Distracter:

5 Marks 3 Marks 1 Mark 0 Marks
One 1 C A D B
Two 2 B C D A
Three 3 D B A C
Four 4 B D C A
Five 5 B D C A
Six 6 D C B A
Seven 7 D A C B
Eight 8 B C A D
© The Official ITIL Accreditor 2012. ITIL Intermediate Capability OSASample2 ANSWERSandRATIONALES v6.1.
Page 2 of 13
QUESTION One Scenario One
Question Rationale To be able to understand the following:
• The importance of senior management sponsorship
• The benefits of project/programme management in service operations; the
importance of risk assessment and risk management
• The importance of involving IT operations staff in all phases of the programme,
especially during the design and transition phases
MOST CORRECT (5) C This option represents the most correct answer as it highlights that the
programme will have a significant impact on the services provided to current
customers.
Given that the IT service manager is the main sponsor, it is important that they
attend the meeting to make their support and commitment to the programme
visible.
This option also identifies the importance of recognizing that IT operations staff
need to be involved during the planning phases of the programme, rather than
after the solution has been developed and tested and is ready for operations.
The programme sponsor is actually verifying that this is the case by asking to
look at the list of invitees to the meeting.
This option also highlights the importance of risk assessment and
management. It shows that the sponsor will look at, and sign off on, the
identified risks, on the programme’s assumptions and constraints, resourcing
(shows commitment) and costs or funding (again demonstrates commitment).
SECOND BEST (3) A This difference between this answer and the best answer is that it fails to
recognize the importance of risk management, project assumptions,
constraints, resourcing and costs.
THIRD BEST (1) D This answer is less accurate compared to the previous option. It does not
highlight the importance of making the sponsor’s support visible by attending
the meeting in person. It also shows that the sponsor is satisfied just to be
copied in on the meeting’s minutes, and the phrase “may wish to be included
at a later date” indicates less interest in the programme.
DISTRACTER (0) B This option demonstrates a totally relaxed approach on the part of the sponsor
of the programme. It shows the sponsor’s lack of interest in the early stages of
the programme, which is when the main decisions need to be made and buy-in
achieved. The sponsor’s actions do not demonstrate a committed or
supportive attitude towards the programme, and this attitude could be
replicated in his direct reports and copied by programme team members.
There seems to also be a lack of interest from the sponsor in making sure that
the right parties be involved in the programme from the beginning.
Syllabus Unit / ITIL SC: OSA09 Technology and implementation considerations
Module supported
Blooms Taxonomy Level 4 Analysis – The ability to use the practices and concepts in a situation or
Testing Level unprompted use of an abstraction. Can apply what is learned in the classroom, in
workplace situations. Can separate concepts into component parts to understand
structure and can distinguish between facts and inferences.
Application – The candidate must apply their knowledge of the need for management
support, risk mitigation and acceptable project involvement in order to select the
correct option that provides a balanced approach.
Subjects covered Categories covered:
• Service operation and project management
• Assessing and managing risk in service operation
• Operational staff in service design and transition
• Management support
• Critical success factors and risks
Book Section Refs SO 8.2 – Implementing service operation – Service operation and project
management
Page 3 of 13
SO 8.3 – implementing service operation – Assessing and managing risk in service
operation
SO 8.4 – Implementing service operation – Operational staff in service design and
transition
SO 9.2 – Challenges, critical success factors and risks – Critical success factors
SO 9.3 – Challenges, critical success factors and risks – Risks
Difficulty Easy
Page 4 of 13
QUESTION Two Scenario Two
Question Rationale This question focuses on the request fulfilment process and requires an
understanding of the types of requests that should be handled by the process.
MOST CORRECT (5) B All statements are correct.
Sentence 1 – Correct. All are examples of service requests.
Sentence 2 – This is a request to change a screen and therefore must be
handled by the change management process. It is possible that the service
desk could be used to log changes, but this will be done using the change
management system, not the incident management system.
Sentence 3 – Correct. All are examples of incidents.
SECOND BEST (3) C Sentence 1 – Mostly correct, with the exception that 2 is a request to change a
screen and therefore must be handled by the change management process. It
is possible that the service desk could be used to log changes, but this will be
done using the change management system, not the incident management
system.
Sentence 2 – Correct.
THIRD BEST (1) D Sentence 1 – All are examples of service requests.
Sentence 2 – 2 is a request to change a screen and therefore must be handled
by the change management process. However, 9 is a very low-risk request to
move a PC that could be handled via request fulfilment; particularly in an
organization such as the one in the scenario that often receives this type of
request.
Sentence 3 – 8 is an access request but these should be logged as service
requests which then trigger the access management process; particularly as it
is a user that is requesting access.
DISTRACTER (0) A Sentence 1 – 1 and 6 are incidents, not service requests. 2 is a request to
change a screen and therefore must be handled by the change management
process. It is possible that the service desk could be used to log changes, but
this will be done using the change management system, not the incident
management system.
Sentence 2 – 9 is a very-low risk change that can be handled via the request
fulfilment process; particularly in an organization such as the one in the
scenario that often receives this type of request.
Sentence 3 – It is correct that 10 is a service request, but 5 is not. Questions
can be handled as service requests.
Syllabus Unit / ITIL SC: OSA04 Request fulfilment
Module supported
Blooms Taxonomy Level 3 Applying – Use ideas, principles and theories in new, particular and concrete
Testing Level situations. Behavioural tasks at this level involve both knowing and comprehension
and might include choosing appropriate procedures, applying principles, using an
approach or identifying the selection of options.
Application – The candidate must be able to distinguish between service requests,

change requests and incidents to select the correct answer option.
• Service desk
• Request fulfilment
Book Section Refs SO 4.3.1 – Service operation processes – Request fulfilment – Purpose and
objectives
SO 4.3.2 – Service operation processes – Request fulfilment - Scope
Difficulty Moderate
Page 5 of 13
QUESTION Three Scenario Three
Question Rationale This question focuses on data retention in relation to event management and, in
particular, event categorization. The correct answers also involve good discussion –
in this case discussion with the business and IT users to determine the most
appropriate data retention periods for each separate event type, so as to best meet
business needs and outcomes.
MOST CORRECT (5) D This is the best solution. Consulting all of the stakeholders will generate a
good discussion and will allow an accurate picture of retention needs to be
established. By treating each event type separately and establishing a policy
that matches the exact needs of each event type, no more or no less data than
necessary will be retained
SECOND BEST (3) B Consulting the stakeholders to determine exact retention needs is very valid
but, in this solution, all event types are treated in the same way, which will
inevitably mean retaining all of the data for the same amount of time as the
type which must be retained longest. Although no required data will be deleted
when it might still be needed, it is likely that a lot of data will be retained long
after it ceases to be required.
THIRD BEST (1) A To keep all data for more than six years on the basis that there MAY be a legal
requirement to retain some of the data for this period would be excessive. The
only redeeming feature is that the probably small amount of data that may be
needed will definitely be available.
DISTRACTER (0) C This is the wrong answer. Data will need to be kept, at least initially, long
enough for trends to be established or problems requiring investigation to
come to light. One week is likely to be totally insufficient for this. Stakeholders
should be consulted to determine a realistic and acceptable retention period.
Syllabus Unit / ITIL SC: OSA02 Event management
Module supported
Application – The candidate must apply their knowledge of event management, and
balance the cost, risks and potential legislative requirements for data retention to
distinguish which option is the best to meet the issues described in the scenario.
• Event management
Book Section Refs SO 4.1.5.6 – Service operation processes – Event management – Process activities,
methods and techniques - Significance of events
SO 4.1.5.9 – Service operation processes – Event management – Process activities,
methods and techniques - Response selection
Difficulty Moderate
Page 6 of 13
QUESTION Four Scenario Four
Question Rationale This question examines a candidate’s understanding of the access management
process, particularly relative to users, groups, roles and service groups.
MOST CORRECT (5) B This reflects all of the factors that must be considered.
Bullet 1 – Having a catalogue of roles enables access management to function
more efficiently and so helps reduce costs and maximize resources. Defining
roles also makes it possible to grant and restrict access more quickly and as
required by the business.
Bullet 2 – Supports the business goal to improve enterprise-wide information
security.
Bullet 3 – Ensures security is considered throughout the user lifecycle.
Bullet 4 – Supports the business goal to ensure compliance with legislative
and regulatory controls and also supports the business goal to reduce costs
and maximize resources by automating the granting of access.
SECOND BEST (3) D This answer addresses most factors but lacks some necessary specifics.
Bullet 1 - Having a catalogue of roles enables access management to function
more efficiently and so helps reduce costs and maximize resources. Defining
roles also makes it possible to grant and restrict access more quickly and as
required by the business.
Bullet 2 – Supports the business goal to function more efficiently by defining
and using ‘groups’ to grant and restrict access.
Bullet 3 - Supports the business goal to ensure compliance with legislative and
regulatory controls.
Bullet 4 - Supports the business goal to improve enterprise-wide information
security. Also supports the business goal of reducing costs and maximizing
resources by automating the granting of access.
While each of these answers is accurate, this answer fails to mention working
in conjunction with human resources (HR) to maintain the catalogue of roles.
As unclear roles and responsibilities is one of the challenges to be overcome,
this is not the best answer.
THIRD BEST (1) C This answer has some merit but lacks specifics.
Bullet 1 – Defining roles enables access management to function more
efficiently and so helps reduce costs and maximize resources. Defining roles
also makes it possible to grant and restrict access more quickly and as
required by the business. This answer would be better if it suggested creating
a catalogue of roles.
Bullet 2 – This is an accurate statement but does not address the need to work
with HR to maintain the catalogue of roles.
Bullet 3 – While important, this answer fails to mention roles and
responsibilities, which is a key challenge to be overcome.
Bullet 4 - Supports the business goal of reducing costs and maximizing
resources by automating the granting of access.
This answer, in general, fails to clarify roles and responsibilities. It also fails to
mention engaging security at all and so does not support a key business goal.
DISTRACTER (0) A This answer is wrong. It is too broad and impractical and does not reflect ITIL
guidance, nor does it support business goals.
Bullet 1 – While defining a standard set of services is appropriate, granting
access to all users is not. For example, customers and contractors are not
typically granted access to internal systems.
Bullet 2 – This answer is highly impractical and so would not support the
business goals of reducing costs and maximizing resources.
Bullet 3 – This answer incorrectly suggests using technology to grant access
based on individual needs. This would be a highly ineffective use of
technology. Using roles and groups would allow access to be granted and
restricted much more quickly, would be more cost-effective, and would be a
better use of resources.
Page 7 of 13
Bullet 4 – This answer incorrectly states that information security will be
responsible for informing access management about new employees (vs. HR).
Neither does it address how to grant access to contractors and customers.
This answer, in general, fails to support business goals and accurately reflect
ITIL guidance. It does not clarify roles and responsibilities. It also fails to
mention the need to ensure compliance with local data protection legislation.
Syllabus Unit / ITIL SC: OSA06 Access management
Module supported
Application – The candidate must apply their knowledge of access management and
also assess the objectives described in the scenario to select a balanced option that
meets the needs defined by the process and the business.
• Access management
Book Section Refs SO 4.5.7.2 – Service operation processes – Access management – Information
management – Users, groups, roles and service groups
Difficulty Hard
Page 8 of 13
QUESTION Five Scenario Five
Question Rationale This question tests the candidates’ understanding of the technical and application
management functions and their relationship to the service desk and IT operations
management functions.
MOST CORRECT (5) B This answer best addresses the issues in the scenario.
Bullet 1 – Addresses the CEO’s goal of consolidating operational activities.
This approach will also help relieve the over-utilization of the technical and
application management functions.
Bullet 2 – Addresses the need to improve data gathering standards.
Bullet 3 – Addresses the CEO’s goal of sharing resources. It also
acknowledges the need to devote resources to problem management.
Bullet 4 – Having a known error database (KEDB) will support problem
management activities and help reduce the impact and cost of outages.
Bullet 5 – Addresses the need to reduce and/or prevent problems with new
services by engaging technical and application management staff in service
design and service transition activities.
SECOND BEST (3) D This answer is good but lacks some specifics.
Bullet 1 – While accurate, this answer is a bit narrow in focus. Other activities
that could be delegated include back-up, restore, and routine maintenance and
operational activities.
Bullet 2 – Addresses the need to improve data-gathering standards.
Bullet 3 – Partially correct – logging all incidents is important and is the
responsibility of the service desk. However, the service desk is not responsible
for logging all problems – that is the responsibility of technical and application
management via the problem management process.
Bullet 4 – Although this answer addresses the need to devote resources to
problem management it does not support the CEO’s goal of sharing resources.
Bullet 5– Having a KEDB will support problem management activities and help
reduce the impact of outages.
THIRD BEST (1) C This answer has some merit but fails to address some of the issues presented
in the scenario.
Bullet 1 – Partially supports the CEO’s goal of consolidating operational
activities.
Bullet 2 – While accurate, this answer is a bit narrow in focus. It does not state
what happens if incidents are detected. There is no indication that the service
desk is rectifying the situation, so significant technical support involvement
could still be required.
Bullet 3 – Having a KEDB will support problem management activities and help
reduce the impact of outages.
Bullet 4 – Providing users with access to a KEDB is a bit premature.
Bullet 5 – While this is an accurate statement, involving technical and
application management resources early in the service lifecycle will better help
resolve the issues in this scenario.
This answer does not address devoting resources to problem management
activities and so does not address the CEO’s challenge to determine why
problems are occurring. Furthermore, because there are no formal problem
management activities, it is unlikely that the KEDB will be accurate, complete,
and current at all times.
DISTRACTER (0) A This answer is incorrect.
Bullet 1 – While it may be perceived that expanding the service desk will result
in cost savings, there is really nothing in the scenario to indicate this is
necessary or a priority.
Bullet 2 – Partially correct – logging all incidents is important and is the
responsibility of the service desk. However, without data-gathering standards,
the data will not be as valuable as it could be as input to the problem
management process. Also, the service desk is not responsible for logging all
Page 9 of 13
problems – that is the responsibility of technical and application management
via the problem management process.
Bullet 3 – It is technical and application management’s responsibility to
validate and maintain the KEDB.
Bullet 4 – Providing users with access to the KEDB is a bit premature
Bullet 5 – While this is an accurate statement, involving technical and
application management resources early in the service lifecycle will better help
resolve the issues in this scenario.
This answer is wrong because it does not address many of the issues in the
scenario such as consolidating operational activities and sharing resources. It
does not address devoting resources to problem management activities and so
does not address the CEO’s challenge to determine why problems are
occurring. Nor does it address defining data-gathering standards and so it is
unlikely that the KEDB will be accurate, complete, and current at all times.
Syllabus Unit / ITIL SC: OSA08 Functions
Module supported
Application – The candidate must have a sound knowledge of service operation

functions in order to assess the issues in the scenario and the proper use of the
functions and to select the answer option which provide the best balance for each for
these.
• Technical management
• IT operations management
• Application management
Book Section Refs SO 6.4.1 – Organizing for service operation – Technical management – Technical
management role
SO 6.4.2 - Organizing for service operation – Technical management – Technical
management objectives
SO 6.4.3 - Organizing for service operation – Technical management – Generic
technical management activities
SO 6.5.1 – Organizing for service operation – IT operations management – IT
operations management role
SO 6.5.2 - Organizing for service operation – IT operations management – IT
operations management objectives
SO 6.5.3 - Organizing for service operation – IT operations management – IT
operations management organization
SO 6.6.1 – Organizing for service operation – Application management – Application
management role
SO 6.6.2 - Organizing for service operation – Application management – Application
management objectives
SO 6.6.5 - Organizing for service operation – Application management – Application
management generic activities
Difficulty Moderate
Page 10 of 13
QUESTION Six Scenario Six
Question Rationale This question focuses on the value of the problem management process, its
separation from incident management and its impact on recurring incidents.
MOST CORRECT (5) D It is ITIL best practice to separate the incident and problem manager roles.
Also, this option focuses on the recurrence of incidents on the ERP system to
prevent them from recurring and to begin a more proactive problem
management practice.
SECOND BEST (3) C Getting the service desk manager to put more focus on problem management
will help the situation, but with this volume of incidents it is difficult to imagine
that this is a job that can be completed satisfactorily in only one day each
week.
THIRD BEST (1) B This will produce a small effect in terms of reducing the incident downtime, but
will have very little effect on preventing recurring incidents.
DISTRACTER (0) A This is the worst reaction. Not reacting to a rising number of user complaints,
that are proven to be justified, is the best way to compromise a good
reputation very quickly and to lose user confidence, impacting harshly on user
satisfaction.
Syllabus Unit / ITIL SC: OSA05 Problem management
Module supported
Level 4 Analysis – The ability to use the practices and concepts in a situation or
unprompted use of an abstraction. Can apply what is learned in the classroom, in
Application – The candidate must apply their knowledge of problem management

and be able to determine that part of the issue described in the scenario stems from
a lack of role separation and that ITIL recommends separating them, thereby leading
to the correct answer option.
Subjects covered Categories Covered:
• Problem management
Book Section Refs SO 4.4 – Service operation processes – Problem management
SO 4.4.1 – Service operation processes – Problem management – Purpose and
objectives
Difficulty Easy
Page 11 of 13
QUESTION Seven Scenario Seven
Question Rationale This question requires candidates to apply their knowledge of incident management
(IM) and the service desk (SD) to a typical scenario. It involves analysing the incident
report provided to identify deficiencies and to identify areas of improvement within the
SD function and the IM process.
MOST CORRECT (5) D All statements are supported by evidence in the report. The resolution action in
the report shows that the incident category assigned during incident recording
is often inaccurate, which results in routing the incident to the wrong resolving
group. Further, the SD does not seem to own incidents throughout the incident
lifecycle as they do not solely close incidents or coordinate their re-routing
when required.
SECOND BEST (3) A Three of the four bullets within this option are supported to some degree by
evidence within the scenario. However, there is no evidence within the
scenario to support the first bullet.
THIRD BEST (1) C Two of the four bullets within this option are supported to some degree by
evidence within the scenario. However, there is no evidence within the
scenario to support either the first or fourth bullets.
DISTRACTER (0) B The fact that incidents are passed between support groups is not evidence of a
poor first-line fix rate. There is no evidence in the report to indicate poor
prioritization. There is no evidence in the report that users are bypassing the
SD. Nor is there evidence to support the claim that the CMS is at fault.
Syllabus Unit / ITIL SC: OSA03 Incident management
Module supported ITIL SC: OSA07 Service desk
Level 4 Analysis – The ability to use the practices and concepts in a situation or
unprompted use of an abstraction. Can apply what is learned in the classroom, in
Application – The candidate must be able to distinguish the cause and effect of how
the SD is handling incidents, the reasons that precipitate this and what this evidence
points to, along with what effect this has.
• Incident management
• Service desk
Book Section Refs SO 4.2.5.3 – Service operation processes – Incident management – Process
activities, methods and techniques – Incident categorization
SO 4.2.5.6 - Service operation processes – Incident management – Process
activities, methods and techniques – Incident escalation
SO 6.3.5 – Organizing for service operation – Service desk – Measuring service desk
performance
Difficulty Moderate
Page 12 of 13
QUESTION Eight Scenario Eight
Question Rationale This question focuses on the overview and context of service operation within the
lifecycle. It tests the candidate’s knowledge of OSA01 – Introduction.
MOST CORRECT (5) B Candidate #2: This candidate has described service operation correctly.
The purpose of the service operation stage of the service lifecycle is to
coordinate and carry out the activities and processes required to deliver and
manage services at agreed levels to business users and customers. Service
operation is also responsible for the ongoing management of the technology
that is used to deliver and support services.
SECOND BEST (3) C Candidate #3: This candidate begins to describe service operation correctly
but goes on to introduce too many elements of continual service improvement
such as achieving service quality, operational efficiency and business
continuity and ensuring that the portfolio of supported services continues to be
aligned with business and user needs. These are not elements of service
operation.
THIRD BEST (1) A Candidate #1: This candidate’s focus is very much confused with service
transition. While they have some elements referring to operation, the answer is
very much centred on moving the organization from one state to another.
DISTRACTER (0) D Candidate #4: Has no correct elements described. It is more focused on
service strategy, if anything.
Syllabus Unit / ITIL SC OSA: 01 Introduction
Module supported
Blooms Taxonomy Level 2 Comprehending - Understand or grasp the meaning of what is being
Testing Level communicated and make use of the idea. Tasks include illustrating, inferring,
summarizing and interpreting.
Application – This question requires the candidate to accurately recall the purpose
and main objectives of service operation in the context of the service lifecycle.
• Overview
• Introduction – Context
Book Section Refs SO 1.1 – Introduction – Overview
SO 1.2 – Introduction – Context
Difficulty Easy
Page 13 of 13

Idioma

Manual OSA Español PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual OSA Español PDF

Título original:

Cargado por

Copyright:

Formatos disponibles

ITIL® Análisis y Soporte

Syllabus versión 5.3 – 2013

Descripción del curso....................................................................................................................... 6

ITIL Análisis y Soporte Operacional ........................................................................................... 11

Introducción al Análisis y Soporte Operacional .................................................................................... 15

Funciones del Análisis y Soporte Operacional ....................................................................................... 21

La función del Service Desk ..................................................................................................................... 22

La función de la Gestión Técnica ............................................................................................................ 52

La función de la Gestión de Aplicaciones ............................................................................................... 57

Roles activos en la Operación del Servicio.............................................................................................. 78

Procesos del Análisis y Soporte Operacional .......................................................................................... 85

Gestión de Eventos .................................................................................................................................... 85

Gestión de Incidentes .............................................................................................................................. 113

Gestión de Problemas ............................................................................................................................. 163

Gestión de Acceso.................................................................................................................................... 194

Roles en los cinco procesos ..................................................................................................................... 214

Gracias ......................................................................................................................................... 238

ITIL Análisis y Soporte Operacional

 Entregar valor a su organización profundizando en los procesos de ITIL que permitan

ACREDITACIÓN DEL CURSO E INSTRUCTOR

QUIÉN DEBE ASISTIR Y PREREQUISITOS

El tamaño máximo de la case es de 18 estudiantes por instructor.

Nota importante: Debido a la naturaleza de este curso, es recomendado que los

Usted puede comprar esta publicación en varios formatos de estas fuentes:

 ITIL V3 Online Bookshop – www.best-management-practice.com/Online-Bookshop/

Estructura de acreditación de ITIL

Institutos de Examinación (EIs)

La Operación del Servicio es optimizada en dos maneras:

 Mejora en el Servicio al cliente, percepción y satisfacción

Entre las principales responsabilidades se incluyen:

 Registrar todos los detalles relevantes de los incidentes/solicitudes de servicio,

Service Desk Local

Dentro de las razones para mantener un Service Desk Local se incluyen:

 Diferencias de idioma y culturales o políticas

Service Desk Centralizado

Service Desk Virtual

Tener en cuenta la construcción del Punto Único de Contacto

Independientemente de la combinación de opciones seleccionadas para cumplir la estructura

Una campaña de sensibilización también puede incluir boletines en papel o electrónicos

 Expectativas del servicio a clientes

Incidentes y tipos de Solicitudes de Servicio (pudiendo incluir RFCs):

Una serie de herramientas se encuentran disponibles para ayudar a determinar el número

Esto involucrará un programa de capacitación y concientización el cual deberá incluir:

 Habilidades interpersonales, tales como habilidades para contestar el teléfono, buena

 Un programa formal de inducción

Retención del personal

También es posible para los Súper usuarios que se involucren en:

Antes de iniciar la selección y capacitación de los potenciales Súper usuarios, y específicamente

Base de Datos de Errores Conocidos

Interfaz Web de Autoayuda

 Preguntas frecuentes (FAQ) y soluciones

Herramientas de Soporte de Planeación de Continuidad de los Servicios de TI para ITSM

Midiendo el desempeño del Service Desk

Encuestas de satisfacción de Cliente/Usuario

Técnicas y Herramientas para Encuestas

Técnica/Herramienta Ventajas Desventajas

Entorno del Service Desk

Outsourcing del Service Desk

Independientemente de las razones o la extensión del Service Desk, el contrato de outsourcing

Si la ruta de outsourcing es elegida, algunas “salvaguardas” son necesarios para garantizar

Herramientas y Procesos Comunes