Información

Operación del Servicio
t Proceso Gestión de Eventos

Propósitode la Gestión de Eventos
~
... ;---
"'• ". Propósito .

I Gestionar eventos a través de su ciclo de vida.
.
~"':'.t"*:-.~·: " ~ ~ ! incluye actividades para detectar eventos, darles
; sentido y determinar las medidas de control apropiadas.
Objetivos
! Proporciona
L 1 - . , .
la base para el monitoreoy controloperacional.
-- - - JJ
1
t~
r:-- -- - -- -- -,
¡ Se puede utilizarpara automatizar las operaciones normales,
Alcance corno para detectar alertas tempranas y ~llas en E Cs. ~
¿Qué es un evento?
Conceptos Cualquier cambio de estado que tenga importancia
básicos
para la gestión de un servicio de Tlu otro EC.
Figura 143: Propósito de la Gestión de Eventos
El propósito del proceso de gestión de eventos es garantizar que el proveedor de servicios tiene la
capacidad para gestionar los eventos a través de su ciclo de vida. Este proceso ayuda a asegurar
que el proveedor de servicios está abordando la detección de eventos, correlación y gestión de
respuestas de una manera planificada y proactiva.
La gestión de eventos proporciona la base para el monitoreo y control operacional. Aunque

muchos proveedores de servicios se limitan a monitorear eventos de advertencias y de excepción,
este proceso también se puede utilizar para automatizar las actividades operacionales normales .
.IIC..-llllllli-~'\o Términos importantes

Evento: Es un cambio de estado que tiene importancia para la gestión
de un servicio de TI u otro elemento de configuración. Los eventos
requieren que el personal de operaciones de TI tome acciones y a
menudo resultan en el registro de eventos.
5-14 © Global Knowledge Training LLC

Objetivosde la Gestión de Eventos
• Detectar todos los cambios de estado

Propósito
significativosde los ECs.
• Determinar las medidas de controlapropiadas
{respuesta).
• Proporcionarun disparadorpara
iniciar otros procesos operativos.
• Proporcionarmedios para compararel
desempeño real contra los diseños.
Alcance
• Proporcionaruna base para garantizarel
servicio y la emisión de informes del servicio.
Conceptos
básicos
Figura 144: Objetivos de la Gestión de Eventos
De acuerdo con ITIL los siguientes son objetivos del proceso de gestión de eventos:
• Detectar todos los cambios de estado que tienen importancia para la gestión
de un servicio de TI u otro EC
• Determinar las medidas de control apropiadas para los eventos y asegurar
que se comunican a las funciones apropiadas
• Proporcionar el disparador o punto de entrada, para la ejecución de muchos
procesos de la operación del servicio y actividades de gestión de operaciones
• Proporcionar los medios para comparar el desempeño y comportamiento de
la operación con los estándares de diseño y los SLAs
• Proporcionar una base para garantizar el servicio y la emisión de informes del
servicio, así como para la mejora del servicio8
8. ITIL Service Operation, 2nd ed. (Norwich, UK: TSO, 2011), 58.
© Global Knowledge Training LLC 5-15

Alcance de la Gestión de Eventos
La gestión de eventos soporta cualquier

Propósito
aspecto de la gestión del servicio que debe
ser controladoy se puede automatizar:
• ECs:
Objetivos • Monitoreo de estados operativos.
• Actualizaciónautomatizada de estados.
~ --- . • Condicionesambientales.
"· .
...,
fh
/~-
>.
.. -..
• Monitoreo de licenciasde software.
: ·,, · • ~lcance • Monitoreo de la seguridad.
e.
' "
tf." /~
~
~---..t :$ 't,..~ :
~ • Actividadesnormales.
El monitoreoy la gestión de eventos,
Conceptos aunque son diferentes, están relacionados.
básicos
Figura 145: Alcance de la Gestión de Eventos
La gestión de eventos puede soportar muchas actividades en el ambiente del proveedor de

servicios. Cualquier aspecto de la prestación de servicios que deba ser controlad,Q,_Y pu d
automatizado, puede ser soportado por este proceso. ITIL proporciona los siguientes ejemplos:
• ECs (elementos de configuración):

• Se incluirán algunos ECs porque necesitan permanecer en un estado
constante (por ejemplo, un switch en una red tienen que estar siempre
encendido y las herramientas de gestión de eventos lo confirman
monitoreando las respuestas de los "pings").
• Se incluirán algunos ECs porque su estado tiene que cambiar con
frecuencia y la gestión de eventos se puede utilizar para automatizarlo y
actualizar el sistema de gestión de la configuración {CMS), (por ejemplo, la
actualización de un servidor de archivos).
• Condiciones ambientales (detección de fuego y humo)
C, Monitoreo del uso de la licencia de software para garantizar la utilización y
asignación óptima/legal de las licencias
• Seguridad (detección de intrusiones)
• Actividad normal (por ejemplo, rastrear el uso de una aplicación o el
desempeño de un servidor)9
El monitoreo y la gestión de eventos están relacionados entre sí y dependen uno del otro, aunque
son ligeramente diferentes en términos de alcance.
9. ITIL Service Operation, 2nd ed. (Norwich, UK: TSO, 2011), 58-59.

El monitoreo se puede utilizar para comprobar el estado de los ECs y de servicios que operan
dentro de los rangos normales. Esto puede ayudar a asegurar que el servicio o el EC están
funcionando normalmente, incluso cuando no se estén generando eventos. La gestión de eventos
se basa en el monitoreo eficaz de los ECs ydel servicio.
La gestión de eventos se centra en eventos que son importantes para la prestación de un servicio o
la gestión de un EC. Por lo general esto es sólo un subconjunto de lo que se monitorea de manera
más amplia.

Conceptos básicos de la Gestión de Eventos: Tipos de evento

• Eventos informativos: Información que se puede
utilizar para análisis y generación de tendencias para
Propósito entregar información a la toma de decisiones del
proveedor de servicios:
• Trabajo programado terminado. J
• Usuario accedió a una aplicación. J
• Se recibió un correo electrónico. J
Objetivos
• Eventos de advertencia: Información de alertas
anticipadas que se puede aprovechar para minimizar
o prevenir el impacto a algún usuario o al negocio:
• Tiempo de terminación de transacción 10% mayor de lo
normal.
Alcance • Utilización del CPU dentro del 5% de tolerancia máxima.
• Eventos de excepción: Indican situaciones anormales
o fallas que requieren acciones adicionales de
·:'
. ~: ~ ·_ .: -.) seguimiento:
. : Con~~ptos, . , : • Utilización del CPU por encima de niveles aceptables.
: básicos : :::~ • Varios intentos con contraseña incorrecta.
-:: -..
¡¡:- ~:;~'/'~ '\~ . ~e~~

""\
....
• Uso de software no autorizado.
V •• °' ':fl'
Figura 146: Conceptos básicos de la Gestión de Eventos: Tipos de evento
Términos importantes
Alerta: Es una notificación que indica que se ha alcanzado un umbral,
algo ha cambiado, o que se ha producido una falla. Las alertas son
creadas y administradas por el proceso de gestión de eventos.
ITIL define tres tipos de eventos, cada uno de ellos para indicar un nivel diferente de importancia
para el proveedor de servicios. Estos tipos de eventos son:
• Eventos informativos: Ofrecen información que se puede utilizar para el análisis y la

generación de tendencias para entregar información a la toma de decisiones del
proveedor de servicios
• Eventos de advertencia: Ofrecen información de alertas anticipadas que se puede
aprovechar para minimizar o prevenir el impacto a algún usuano o al negocio
• Eventos de excepción: Indican situaciones anormales o fallas que requieren acciones
adicionales de seguimiento
Debido a los amplios y diferentes ambientes de proveedores de servicio y de los servicios que
ofrecen, no existen reglas definitivas que pueden utilizarse. Setenta por ciento de utilización de
CPU puede ser de carácter informativo para algunos proveedores de servicios y representar un
evento de excepción para otros. Cada proveedor de servicios tendrá que aplicar las definiciones
dentro de su ambiente.
Es importante tener en cuenta que todos los tipos de gestión de eventos requieren algún tipo de
detección y notificación (registro a través de acciones de alerta). El proveedor de servicios deberá
trabajar para definir eventos de manera proactiva en su ambiente y asegurar que tiene actividades
planeadas para su correcta detección y comunicación.

Proceso Gestión de Incidentes fum~o-zo-
Propósitode la Gestión de Incidentes 12-eocl, l.D.
Objetivos Restaurar la operaciónnormal de los servicios

lo más rápidoposible. ./
Alcance
• Conceptos básicos ¡ Minimizarel· impactonegativo sobre las

L operacionesdel negocio. - _
Actividades
Interfaces ¿Qué es un incidente?

Interrupciónno planeada de un servicioden, o
Reducción en la calidad de un serviciode TI, o
Falla de un EC que aún no ha afectado a un servicio
Figura 147: Propósito de la Gestión de Incidentes
Incidente: Es una interrupción no planificada de un servicio de TI o la
reducción en la calidad de un servicio de TI o falla de un EC que aún no
ha afectado un servicio de TI (por ejemplo, la falla de un disco en un
conjunto de discos espejo)
Operación normal del servicio: Es el estado de operación que indica
que los servicios y ECs funcionando dentro de los niveles de servicios y
operación acordados
El propósito de la gestión de incidentes es asegurar que se mantienen los niveles de servicio

acordados mediante la restauración de la operación normal del servicio a la brevedad posible en
caso de un incidente La gestión de incidentes también trabaja para minimizar el impacto negativo
de los incidentes en las operaciones del negocio.

Objetivosde la Gestión de Incidentes

Propósito
l t:s.··,,1;.•:r."( ~ .. !-", ~"' ~ ........ e',.~.}
• Asegurarel uso de métodos y procedimientos
:,/cibjetivqs.
,;Á~r-••t~._ ~ _ :. ....~ ). ~;.:
·~.
:~~
estandarizados.
• Aumentar la visibilidady comunicaciónde
Alcance
incidentes.
... Conceptos básicos • Mejorar la percepción que tiene el negocio
sobre TI.
Actividades
• Alinear actividades a las prioridadesdel
Interfaces negocio.
• Mantener la satisfacción del usuario respecto
de la calidad del serviciode TI.
Figura 148: 'Objetlvos de la Gestión de Incidentes
ITIL define los siguientes objetivos de la gestión de incidentes:
• Asegurar que se utilizan métodos y procedimientos estandarizados para

ofrecer respuestas, análisis, documentación, gestión continua y emisión de
reportes de manera rápida y eficiente
• Aumentar la visibilidad y la comunicación de los incidentes para los negocios y
el personal de soporte
• Mejorar la percepción que tiene el negocio de las TI usando una iniciativa
profesional al resolver y comunicar rápidamente los incidentes que ocurran
• Alinear las actividades y prioridades de la gestión de incidentes con las del
i .
· negocio
•~ Mantener la satisfacción del usuario respecto de la calidad de los servicios de
. >r110

Alcance de la Gestión de Incidentes

Propósito
Dentro de su alcance:
• Cualquierevento que indique la interrupción
de un servicio de TI.
• Cualquier evento que pudiera interrumpirun
serviciode TI.
Actividades Fuera de su alcance:
• Eventos informativosque indican la
Interfaces
operación normal del servicio.
• Solicitudesde servicio.
Figura 149: Alcance de la Gestión de Incidentes
La gestión de incidentes es el proceso que responde a los incidentes. Como la definición de

incidente incluye eventos que están provocando una interrupción del servicio, así como eventos
que podrían afectar un servicio si no se atienden adecuadamente, los incidentes pueden abrirse
antes de que afecten de manera negativa al negocio. Los incidentes los pueden comunicar los
usuarios, el personal técnico o incluso los proveedores.
Si el evento no coincide con la definición de un incidente, estará fuera del alcance de este proceso
y será manejado por otro proceso de gestión de servicios de TI según corresponda. Esto incluiría
los eventos informativos que indican la operación normal del servicio o del dispositivo. Además,
si los clientes se ponen en contacto con el service desk y hacen solicitudes que no están
relacionadas con un incidente, esto ocasionará que el service desk registre una solicitud de
servicio, la cual se manejará fuera de la gestión de incidentes en el proceso de cumplimentación de
solicitud.

Conceptos básicos de la Gestión de Incidentes
Modelos de incidentes y plazos

Propósito Modelos de incidentes: Pasos predefinidos para
manejar tipos conocidos de incidentes de una manera
Objetivos
acordada.
Alcance Plazos:
.~. ~ • Se deben acordar para todas las etapas de manejo
"Y C,oncepto~ ·bási<;o,
,,. "'~ ~"'- ~"' . . : i~ de incidentes.
Modelos de • Difieren en función de la prioridad de los incidentes.
incidentes y
lazos • Se deben sustentar en objetivos de respuesta y de
Seguimiento del resolución acordados con SLAs.
estado de • Corresponden a objetivos dentro de los OLAs y
incidentes
UCs, según corresponda.
Incidentes
graves
• Se comunican a todos los grupos de soporte.
• Se deben de usar herramientas de gestión_ de
Actividades servicios para automatizar los plazos con base en
reglas predefinidas.
Interfaces
Figura 150: Modelos de incidentes y plazos
Modelos de incidentes
Modelos de incidente: Una manera de redefinir las medidas que
deberán adoptarse para manejar un tipo particular de mct ente de una
forma acordada.
El ambiente de cada uno de los proveedores de servicios tendrá cierto número de tipos de
incidentes que tienen posibilidad de ocurrir más de una vez debido a la naturaleza del servicio
prestado. Por ejemplo, es probable que los proveedores de servicios de red experimenten una alta
frecuencia de incidentes relacionados con la red, con solo pocos criterios que se pueden
estandarizar. El proveedor de servicios debe trabajar para crear modelos de incidentes para este
tipo de incidentes y garantizar que se responde de manera eficaz y consistente. Una vez creados,
los modelos de incidentes deben introducirse en el sistema de gestión de incidentes y
automatizarse en la medida de lo posible. Los modelos de incidentes se deben definir, almacenar y
gestionar como parte de un SKMS más extenso.
Los modelos de incidentes deben incluir la siguiente información:
• Las medidas que se deben adoptar para controlar el incidente

• El orden cronológico en que se deben tomar estas medidas, definiendo
cualquier dependencia o ca-procesamiento
• Responsabilidades - quién debe hacer qué

• Precauciones que se deben tomar antes de resolver el incidente, por ejemplo,

copias de seguridad de los datos, archivos de configuración o pasos para
cumplir con los lineamientos de salud y seguridad relacionadas
• Plazos y umbrales para finalizar con las acciones
• Procedimientos de escalamiento - quién debe ser contactado y cuándo
• Cualquier actividad relacionada con la preservación de evidencia
(especialmente importante en incidentes relacionados con la seguridad y la
capacidad}"
Plazos
Los plazos representan el intervalo de tiempo dentro del cual deben ocurrir determinados eventos.
En el contexto de la gestión de incidentes esto está relacionado con conocer y entender que cada
actividad dentro del proceso contribuirá con cuánto tiempo será necesario para resolver el
incidente. Por ejemplo, el proveedor de servicios deberá considerar el tiempo puede permanecer
un incidente con el analista de soporte de primer nivel antes de escalarse a recursos más técnicos.
El incumplimiento en la gestión de actividades en este nivel puede resultar en la ruptura del
proceso y la incapacidad del proveedor de servicios para restablecer el servicio dentro de los
plazos convenidos. Este concepto puede aplicarse a todas las actividades dentro del proceso,
incluida la frecuencia de la notificación de las actualizaciones de estado al usuario que reportó el
incidente.
Los plazos deberán definirse y acordarse en todas las etapas del manejo de incidentes, con base en
la prioridad del incidente. Los incidentes de alta prioridad se pueden escalar más rápido que los
incidentes de baja prioridad, por ejemplo.
El proveedor de servicios deberá sustentar estos plazos en los periodos de tiempo para la
resolución de incidentes acordados y documentados en los SLAs. Cuando proceda, estos plazos
deberán estar representados como metas en los OLAs y UCs para cada uno de los servicios, con el
fin de asegurar que cada equipo interno y externo comprende el nivel de respuesta al que debe
adherirse. Estas metas se deben comunicar a todos los grupos de soporte para asegurar que cada
grupo entiende contra que lo medirán.
Siempre que se sea posible, se deberán utilizar herramientas de gestión de servicios para
automatizar estos plazos. Por ejemplo, las herramientas para incidentes podrían escalar incidentes
a la gerencia de manera automática a medida que se acerca el plazo límite de resolución acordado
o en caso de que un incidente se haya presentado al service desk, pero no se ha resuelto ni
reconocido dentro de los tiempos de respuesta acordados.

Seguimiento del estado de incidentes

Propósito
Se debe realizar un seguimiento de incidentes
Objetivos a lo largo de su ciclo de vida:
• Manejado y escalados adecuadamente.
Alcance
• Estado del incidente debidamente
'! Conceptos básico comunicado.
Modelos de • Capturado en el sistema de gestión de
incidentes y
lazos
incidentes.
Seguimiento del Ejemplo del estado de incidentes:
estado de
incidentes • Abierto
Incidentes • En progreso
graves
• Resuelto
Actividades • Cerrado
Interfaces
Figura 151: Seguimiento del estado de incidentes
Es necesario hacer un seguimiento del estado de los incidentes a lo largo de su ciclo de vida para
dar soporte en el manejo adecuado y en el escalamiento de incidentes, así como para facilitar la
información precisa sobre el estado de los incidentes. Los códigos de estado deberán capturarse en
cada registro de incidente para poder aprovechar la automatización y la capacidad de emisión de
reportes.
ITIL proporciona los siguientes ejemplos del estado de los incidentes:
• Abierto: Se ha reconocido un incidente, pero aún no se le ha asignado un

recurso de soporte para su resolución.
• En progreso: El incidente está en proceso de ser investigado y resuelto.
• Resuelto: Se ha encontrado 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 el
usuario final.
• Cerrado: El usuario o el negocio ha aceptado que el incidente se ha resuelto y
que el estado normal de las operaciones ha sido restaurado.12

Incidentes graves
Propósito
Incidentes graves:
Objetivos • Incidentes con alto impacto - interrupción
grave para el negocio.
Alcance
• Deben definirseclaramente y reflejarse en
esquema de priorizaciónde incidentes.
Modelos de
incidentes y
Procedimientopara incidentesgraves:
lazos • Establecer un equipoespecíficopara
Seguimiento del incidentesgraves.
estado de
incidentes • Dirigidoy administradopor el gerente de
Incidentes incidentes.
graves • Enfocado en una resoluciónmás rápida y en
Actividades minimizar el impacto.
Interfaces
Figura 152: Conceptos básicos de la Gestión de Incidentes Incidentes graves
L,, t.:c: : : ~Q Términos importantes

Incidentes graves: La categoría de impacto más alta de un incidente.
Un incidente grave tiene como resultado una interrupción importante en
el negocio.
Procedimiento para incidentes graves: Un procedimiento separado,
con plazos más cortos y mayor urgencia, que deberá utilizarse para los
incidentes graves.
Los incidentes graves requieren elevados niveles de respuesta por parte del proveedor de servicios.
Deberán existir definiciones claras para determinar qué es un incidente grave y se deberá definir el
procedimiento para un incidente grave y deberá comunicarse para ejecutar la respuesta
organizacional cuando ocurra un incidente grave. Idealmente, los incidentes graves deberían
reflejarse en el esquema de priorización utilizado para reforzar la claridad sobre cuándo debe
seguirse el procedimiento de incidentes graves, así como para respaldar cualquier actividad
automatizada posible dentro del sistema de gestión de incidentes.

(J Actividadesde la Gestión de Incidentes

Propósito Gestión de Correo
eventos electrónico
Objetivos
Alcance Hacia cumplimientode solicitud

(si se trata de una solicitud de
I
servicio) o gestión del portafolio ,
No--. de servicios (si se trata de una !
.., Conceptos básicos propueota de cambio)
" s
i;. · Actividadés\,
--"~~:~\-~~
,.,,,,. ~
.. :r~, ..
.. :
;._"~ \, ~~,
.
SI
Registrar
incidente
Interfaces
Categorizar
incidente
.__ SI
Basado en el material (ITIL©) de AXELOS.
No
+ Reproducción con permiso de AXELOS.
Adaptación de la figura 4.3. Operación del Servicio.
Figura 153: Actividades de la Gestión de lncidentes13
Identificación de incidentes
La gestión de incidentes no puede empezar a trabajar sobre los incidentes hasta que se sepa que
está ocurriendo un incidente. Esto no significa que el proveedor de servicio deba esperar a que los
usuarios se vean afectados. En su lugar, la gestión de eventos puede apoyar a la gestión de
incidentes, garantizando que todos los componentes clave son monitoreados de manera eficiente,
para que las fallas se puedan detectar a tiempo; idealmente antes de que el usuario se vea afectado
en absoluto.
Hay muchas maneras en las que un proveedor de servicios puede percatarse de que está ocurriendo
un incidente. La Figura 153 muestra algunos ejemplos comunes.
Registro de incidentes
Independientemente de la forma en la que se identifiquen, todos los incidentes deberán registrarse
y marcarse con la fecha y la hora. Como algunas de las comunicaciones con los usuarios pueden
abarcar varios incidentes, el service desk ( o personal de soporte) deberán tener cuidado de generar
un registro de de incidente individual por cada incidente que se reporte.
Aunque ITIL establece que el service desk es responsable de registrar todos los incidentes, esta
responsabilidad puede ser delegada a otras áreas del proveedor de servicios en caso necesario.
Esto puede incluir incidentes iniciados por la tecnología, por ejemplo usuarios que envían los
incidentes a través de un formulario en línea o herramientas de gestión de eventos que crean un
registro de incidentes automáticamente cuando se detectan eventos que pueden afectar a los
servicios. Puede ser que algunos proveedores de servicios no tengan un service desk 24x7 (24
horas al día, siete días a la semana), sin embargo cuentan con otras funciones como operaciones de
TI in situ 24x7.
13. ITIL Service Operation, 2nd ed. (Norwich, UK: TSO, 2011 ), 77.

En estos casos, el service desk puede delegar la responsabilidad del registro de incidentes a estos
otros grupos. Cualquier grupo involucrado en el registro de incidentes debe estar rigurosamente
entrenado para registrar los detalles del incidente.
El registro de cada incidente debe incluir todos los detalles relacionados con el incidente. Este
registro se debe actualizar a medida que avanza el incidente a través del ciclo de vida del
incidente, y servir como un registro histórico que diga qué sucedió y cómo ser resolvió.
Categorización de incidentes
Como parte inicial del registro de incidentes, se deberá asignar una categoría al incidente. Esto
puede ayudar a filtrar las solicitudes de servicio que deban canalizarse hacia el cumplimiento de
solicitudes, así como apoyar las actividades derivadas del proceso de gestión de incidentes. La
categorización ayudará a facilitar el escalamiento del incidente y las decisiones de enrutamiento,
así como a prever tendencias y análisis importantes que podrían utilizarse para los procesos de
gestión de problemas y de proveedores.
La categoría de un incidente puede cambiar durante el ciclo de vida del incidente a medida que
surgen los detalles y aumenta el conocimiento y comprensión del proveedor de servicios sobre la
categoría. La categoría se deberá actualizar y mantener durante la vida de cada incidente.
Priorización de incidentes
La prioridad se debe registrar con cada incidente ya que de esta manera se podrá determinar de
qué manera el personal deberá manejar el incidente y las herramientas de soporte. Mayores niveles
de prioridad se reflejarán en plazos de resolución más rápidos e influirán en los tickets que de
incidentes que deban tener precedencia. La prioridad se puede expresar de la siguiente manera:
Prioridad = Impacto y Urgencia
La prioridad debería basarse en la urgencia y el impacto de cada incidente. La urgencia se refiere a

la rapidez con que la empresa necesita una solución del incidente. Hay ocasiones en que estarán
presentes niveles de mayor o menor urgencia y se deberán tener en cuenta. El impacto se refiere al
impacto general que el incidente está teniendo sobre el negocio.
Se deberá ofrecer a todo el personal de soporte una orientación clara, con ejemplos prácticos y
relevantes para el ambiente en cuestión, para asegurar que son capaces de asignar correctamente
los niveles de urgencia e impacto a cada incidente.
En ocasiones la prioridad de un incidente se tendrá que omitir. Puede haber ocasiones en las que
un usuario sea inflexible en cuanto a que un incidente debe tener una prioridad superior a la que
dictan las directrices. En estos casos, el service desk deberá cumplir. Si resulta ser incorrecta más
adelante, se puede escalar a la gerencia para que el problema se resuelva por los canales más
apropiados. En algunas organizaciones se podrán reconocer VIPs con niveles de respuesta más
elevados.

Actividadesde la Gestión de Incidentes (cont.)

Propósito Diagnóstico
inicial
Objetivos
l
+- SI
Alcance
No
.,.. Conceptos básicos ! No
-, . No
~·, Actividades ·-
il-1, ~"" "r • ~ ... , "-
Interfaces
Sí
+
Basado en el material (ITIL@) de AXELOS.
Reproducción con permiso de AXELOS. Fin

Adaptación de la figura 4.3. Operación del Servicio.
Figura 154: Actividades de la Gestión de Incidentes (cont.) 14
Diagnóstico inicial
Error conocido: Es un problema que tiene una causa raíz
documentada y una solución temporal. Los errores conocidos son
creados y gestionados por la gestión de problemas. Los errores
conocidos también pueden ser identificados por los desarrolladores o
por los proveedores.
Solución temporal: Una manera de reducir o eliminar el impacto de un
incidente o problema, para el cual aún no se tiene una solución
definitiva. Las soluciones temporales están documentadas en los
registros de errores conocidos. Las soluciones temporales para los
incidentes que no tienen registros de problemas asociados se
documentan en el registro de incidentes.
Los guiones de diagnóstico, modelos de incidentes y registros de errores conocidos pueden ser
muy valiosos en esta etapa de la gestión de incidentes. El uso de guiones de diagnóstico y modelos
de incidentes, permitirá al service desk diagnosticar el incidente de una manera que ya ha sido
probada y documentada, ofreciendo un nivel de servicio más consistente y probablemente
acelerando el plazo de solución del incidente. Si el service desk es capaz de identificar un registro
del error conocido relacionado con este incidente, tendrá acceso a una solución temporal para
restaurar el servicio con mayor rapidez.

Escalamiento de incidentes
Escalamiento funcional
Escalamiento funcional: Es la transferencia de un incidente, problema
o cambio a un equipo técnico con un mayor nivel de conocimientos
especializados para ayudar en el escalamiento
Tan pronto como quede claro que el service desk no será capaz de restaurar el servicio dentro de
los plazos convenidos, el incidente debe ser escalado. Incluso con el incidente escalado, la
propiedad del incidente y la responsabilidad de mantener a los usuarios informados sobre el estado
del incidente, seguirá siendo del serv1ce desk. ---
Escalamiento jerárquico
Escalamiento jerárquico: Informar o involucrar a niveles más altos de
la gerencia para ayudar en un escalamiento
Los escalamientos jerárquicos se hacen en una gran variedad de circunstancias y por varias
razones. Pueden ser de carácter informativo, asegurando que se notifica a los gerentes de TI
adecuados en caso de incidentes de alta prioridad. Se pueden hacer escalamientos jerárquicos
cuando sea necesario tomar decisiones, por ejemplo l~ asignación de recursos adicionales o
cuando hay un desacuerdo sobre qué equipo debe ser asignado a un incidente.
Investigación y diagnóstico
Es probable que muchos incidentes requieran algún nivel de investigación y diagnóstico. Esto
puede incluir actividades como establecer exactamente qué es lo que salió mal o qué es lo que está
buscando el usuario e investigar el orden cronológico de los acontecimientos. Todas las
actividades realizadas como parte de la actividad de diagnóstico se deben registrar en el registro de
incidentes para asegurar que se genera un registro histórico completo y actualizado.
Resolución y recuperación
Una vez encontrada una solución, se deben realizar pruebas suficientes para asegurar que el
servicio ha sido restaurado al nivel acordado. Cuando hay varios grupos involucrados, la gestión
de incidente deberá coordinar sus esfuerzos y asegurar que todos los detaJJes se capturen en eL
registro del incidente.
Una vez terminado, el incidente deberá devolverse al service desk para que se cierre.

é) Cierre de incidente
El service desk es responsable de las actividades de cierre del incidente. Cuando el incidente se
regresa al service desk, se deberá confirmar que los usuarios están satisfechos y que el servicio
está totalmente restaurado. Además de confirmar con el usuario, de acuerdo con ITIL las
siguientes son responsabilidades del service desk:
• Categorización de cierre: Compruebe y confirme que la categorización inicial

del incidente fue correcta o si posteriormente esta categorización resultó
incorrecta, actualice el registro de modo que se registre una categorización de
cierre correcta para el incidente, mediante el asesoramiento o la orientación
del grupo o grupos que resolvieron el incidente.
• Encuesta de satisfacción de usuarios: Realice una encuesta de satisfacción de
usuarios por teléfono o por correo electrónico, de acuerdo al porcentaje de
incidentes acordado.
• Documentación del incidente: Registre cualquier detalle pendiente y
garantice que el registro del incidente está plenamente documentado para
que exista un registro histórico con suficiente nivel de detalle.
• Problema continuoo recurrente:Determine (junto con los grupos de
solución) si el incidente se resolvió sin haber identificado la causa raíz. En este
/ caso, es probable que el incidente pueda volver a ocurrir y se necesite una
mayor acción preventiva para evitarlo. En todos estos casos, deberá
determinar si ya existe un registro del problema relacionado con el incidente.
Si no existe, es necesario crear un registro del problema en conjunto con el
proceso de gestión de problemas, de modo que se inicien las acciones
preventivas.
• Cierre formal: Cerrar formalmente el registro del incidente.15
Reglas para reabrir incidentes

A pesar del mejor esfuerzo del proveedor de servicios, habrá ocasiones en que los incidentes se
repitan. Cada organización deberá trabajar en crear reglas claras relacionadas la manera en la que
la gestión de incidentes deberá tratar estas ocurrencias. Estas reglas deberán describir el tiempo
que se dedicará para determinar si se reabre un incidente o se registra un ticket nuevo y se vincula
al incidente original. Estas decisiones pueden tener un impacto sobre la notificación de incidentes,
por eso el proveedor de servicios deberá considerar también este impacto al momento de definir
las reglas.

Interfaces de la Gestión de Incidentes con otros procesos

Propósito
Mejora
Transición Operación
Continua
Objetivos del Servicio del Servicio del Servicio
1
Alcance 11-·-G_e_s-ti-ó~n
de
• Gestión de • Gestión de
niveles de activos de problemas.
.,. Conceptos básicos servicio . servicio y
configuración • Gestión de
• Gestión de acceso.
seguridad de • Gestión del
Actividades la cambio.
información.
• Gestión de
capacidad.
• Gestión de
disponibilidad
Figura 155: Interfacesde la Gestión de Incidentes con otros procesos
La gestión de incidentes soporta un gran número de procesos de la gestión del servicio. Los
procesos principales definidos por ITIL que se relacionan con la gestión de incidentes se muestran
en la Figura 155.
Diseño del Servicio

La gestión de incidentes está relacionada con los siguientes procesos dentro del diseño del
servicio:
• Gestión de niveles de servicio: La capacidad para resolver incidentes en un

tiempo específico es parte clave para cumplir con un nivel de servicio
acordado. La gestión de incidentes permite a SLM definir respuestas medibles
para las interrupciones del servicio. También proporciona informes que
permiten a SLM revisar los SLAs de manera objetiva y con regularidad. En
particular, la gestión de incidentes es capaz de ayudar a definir la parte más
débil de los servicios, de tal manera que el SLM pueda definir acciones como
parte del SIP (plan de mejora del servicio). SLM define los niveles aceptables
del servicio dentro de los cuales funciona la gestión de incidentes, incluyendo:
• Tiempos de respuesta a los incidentes
• Definiciones de impacto
• Tiempo objetivo de resolución
• Definiciones del servicio, que se transfieren a los usuarios
• Reglas para solicitar servicios
• Expectativas para dar retroalimentación a los usuarios

• Gestión de la seguridad de la información: Proporcionar información de

incidentes relacionada con la seguridad en la medida de lo necesario, para dar
soporte a las actividades de diseño del servicio y tener una imagen completa
de la eficacia de las medidas de seguridad como un todo, con base en todos
los incidentes de seguridad. Esto es posible si se mantienen archivos de
registro y de auditoría, así como registros del incidente.
• Gestión de capacidad : La gestión de incidentes genera un disparador para
monitorear el desempeño en donde parece que hay un problema de
desempeño. La gestión de capacidad puede desarrollar soluciones temporales
para los incidentes.
• Gestión de la disponibilidad: La gestión de la disponibilidad utilizará datos de
la gestión de incidentes para determinar la disponibilidad de los servicios de TI
y poder determinar en dónde se puede mejorar el ciclo de vida del
incidente.16
Transición del Servicio

La gestión de incidentes está relacionada con los siguientes procesos dentro de la transición del
servicio:
• Gestión de activos de servicio y configuración: Este proceso proporciona los

datos que se utilizan para identificar incidentes y darles avance. Uno de los
usos del CMS es identificar equipo defectuoso y evaluar el impacto de un
incidente. El CMS también contiene información para a qué grupo de soporte
se debe asignar cada una de las categorías del incidente. A su vez, la gestión
de incidentes puede mantener el estado de los ECs defectuosos. También
puede ayudar a la gestión de activos de servicio y configuración a auditar la
infraestructura cuando se trabaja para resolver un incidente.
• Gestión de cambios: Cuando se necesita un cambio para implementar una
solución temporal o definitiva, este deberá anotarse como un RFC y pasar por
la gestión de cambios. A su vez, la gestión de incidente es capaz de detectar y
resolver los incidentes que surgen de los cambios que fracasan."


La gestión de incidentes está relacionada con los siguientes procesos dentro de la operación del
serv1c10:
• Gestión de problemas: En algunos incidentes, será preciso involucrar a la

gestión de problemas para investigar y resolver la causa subyacente para
prevenir o reducir el impacto de una recurrencia. La gestión de incidentes
proporciona un punto en donde se reportan. La gestión de problemas puede a
cambio, proporcionar los errores conocidos para agilizar la resolución de
incidentes a través de soluciones temporales que se pueden utilizar para
restaurar el servicio.
• Gestión de acceso: Los incidentes se deberán generar cuando se detecten
intentos de acceso no autorizados y violaciones a la seguridad. También es
importante tener y mantener un historial de incidentes para soporte de
actividades de investigación forense y la resolución de violaciones de acceso.18

Proceso Gestión de Problemas

Propósito de la Gestión de Problemas
it ..
>~~-. Propósito
< ~ ~~
l•'
Gestionar el ciclo de vida de todos los problemas
. desde su identificación hasta su desaparición.
Objetivos
Entender, documentar y comunicar errores conocidos e

Alcance , iniciar acciones para mejorar o corregir la situación.
.,. Conceptos básico

Minimizar de manera reactiva l.os efectos adversos de
Actividades
l los incidentes y problemas. __
1 ..
J
Interfaces l
Prevenir de manera proactiva la recurrencia de
incidentes relacionados con errores.
1 ------
l
¿Qué es un problema?
I Es la causa de uno o-más incidentes.
Figura 156: Propósito de la Gestión de Problemas
Problema: Es la causa de uno o más incidentes. Por lo general la
causa no se conoce al momento de crear el registro del problema y el
proceso de gestión de problemas es responsable de la investigación
posterior.
El propósito del proceso de gestión de problemas es gestionar el ciclo de vida de los problemas
desde la identificación hasta la eliminación o corrección. La gestión de problemas trata de
encontrar y entender la causa de los problemas, documentar y comunicar errores conocidos al
personal de soporte para minimizar el impacto de los incidentes relacionados con problemas. De
forma proactiva, la gestión de problemas trabaja para evitar que los incidentes se repitan,
corrigiendo el error subyacente que está generando los incidentes.

Objetivosde la Gestión de Problemas
Propósito
• Evitar problemas y la ocurrenciade los
~e:-~·,;";,: ~..,:-.~A;: ~#t~:;t_-,.~ ~ 4 ~
incidentesresultantes.
:·~··objetivo} ' . , .
)~~? ~:•, ~- :< .. O,' :·~-f; • Eliminar los incidentes recurrentes.
Alcance • Minimizar el impacto de los incidentes
que no se pueden evitar.
~ Conceptos básico
Actividades
Interfaces
Figura 157: Objetivos de la Gestión de Problemas
De acuerdo con ITIL los siguientes son objetivos del proceso de gestión de problemas:
• Evitar problemas y la ocurrencia de los incidentes resultantes

• Eliminar los incidentes recurrentes
• Minimizar el impacto de los incidentes que no se pueden evitar19

Alcance de la Gestión de Problemas

La gestión de problemas está principalmente dentro del
Propósito
alcance de la operación del servicio:
• La gestión proactiva de problemas soporta al CSI.
Objetivos • Los problemas se pueden identificar en las actividades de transición.
Gestión reactiva de problemas:
. Alcance • Resuelve los problemas en respuesta a incidentes o eventos
·-~ ~-.., ' ~ - ~ ".!: • "' específicos.
... Conceptos básico Gestión proactiva de problemas - disparados por actividades

de mejora:
• Identifica y resuelve problemas y errores conocidos antes de
Actividades que el incidente reaparezca.
• Se realiza de manera continua, revisando y analizando los registros
de incidentes y las tendencias en busca de signos de causas
Interfaces comunes que puedan corregirse.
• Revisa incidentes graves.
• Revisa registro operativos y de eventos para identificar problemas.
• Lleva a cabo lluvias de ideas para identificar problemas.
• Usa hojas de verificación para recopilar datos relativos a los
problemas.
Figura 158: Alcance de la Gestión de Problemas
La gestión de problemas recae principalmente en el ámbito de la fase de operación del servicio,

como soporte de los servicios operativos. La gestión de problemas soporta las actividades de CSI,
identificando de manera proactiva las causas de los problemas antes de que se repitan los
incidentes. Además, la gestión de problemas trabajará con la etapa de transición del servicio para
identificar y documentar los errores que se detectan en los ambientes de prueba y desarrollo.
Gestión Rroactiva y reactiva de problemas

La gestión de problemas incluye aspectos reactivos y proactivos. Aunque ambos aspectos se
centran en la identificación y corrección de problemas, se activan de manera diferente. ITIL
describe la diferencia entre la gestión reactiva y proactiva de la siguiente manera:
• Con la gestión reactiva de problemas, las actividades del proceso son

desencadenadas como una reacción ante la ocurrencia de un incidente. La
gestión reactiva de problemas complementa las actividades de la gestión de
incidentes, centrándose en la causa subyacente de un incidente para evitar su
recurrencia e identificando soluciones temporales en caso necesario.
• Con la gestión proactiva de problemas, las actividades del proceso son
desencadenadas por actividades que buscan mejorar los servicios. Un ejemplo
podrían ser actividades de análisis de tendencias para buscar causas
subyacentes comunes de incidentes históricos que tuvieron lugar para
prevenir su recurrencia. La gestión proactiva de problemas complementa las
actividades de CSI, ayudando a identificar soluciones temporales y acciones de
mejora que puedan mejorar la calidad de servicio."

Algunas de las responsabilidades y tareas relacionadas con la gestión de problemas incluyen:
• La gestión reactiva de problemas tiene que ver con la solución de los

problemas en respuesta a uno o más incidentes.
• La gestión proactiva de problemas tiene que ver con la identificación y
solución de problemas y errores conocidos, antes de que vuelvan a ocurrir
más incidentes relacionados.
• Mientras que las actividades de la gestión reactiva de problemas se realizan
en respuesta a determinadas situaciones de incidentes, las actividades de la
gestión proactiva de problemas se llevan a cabo como actividades continuas
dirigidas a mejorar la disponibilidad general y la satisfacción del usuario final
con os servrcios e TI. Algunos ejemplos de actividades de gestión proactiva
de problemas incluyen la revisión periódica programada de los registros de
incidentes, para buscar patrones y tendencias en síntomas reportados que
puedan indicar la presencia de errores subyacentes en la infraestructura.
• Conducir revisiones de incidentes importantes donde la revisión de "¿Cómo
podemos evitar la recurrencia?" puede ayudar a la identificación de una causa
subyacente o error.
• Conducir revisiones periódicas programadas de registros operativos y
registros de mantenimiento, identificando patrones y tendencias de
actividades que pueden ser indicio de que puede existir un problema
subyacente.
• Conducir revisiones periódicas programadas de registros de eventos,
buscando patrones y tendencias de eventos de advertencia y de excepción
que puedan indicar la presencia de un problema subyacente.
• Conducir sesiones de lluvia de ideas para identificar tendencias que puedan
indicar la existencia de problemas subyacentes.
• Utilizar hojas de verificación para recopilar datos del servicio o de la calidad
operativa de manera proactiva que puedan ayudar a detectar problemas
subyacentes.21

Conceptos básicos de la Gestión de Problemas
Definiciones importantes
Propósito
Objetivos
Soluciones temporales.
Alcance
Errores conocidos.
Definiciones
importantes
K_EDB (BD de errores conocidos)
Incidentes vs,
problemas
Actividades
Modelos de problema.
Interfaces .J
Figura 159: Definiciones importantes
Soluciones temporales
.. ..-111111tr.~'\Q Solución temporal: Una manera de reducir o eliminar el impacto de un
incidente o problema, para el cual aún no se tiene una solución
definitiva. Las soluciones temporales están documentadas en los
registros de errores conocidos. Las soluciones temporales para los
incidentes que no tienen registros de problemas asociados se
documentan en el registro de incidentes.
Con frecuencia, los recursos del problema son capaces de identificar una forma temporal de
solucionar los problemas o minimizar el impacto. Si bien esta no es una solución permanente, esta
información puede minimizar el impacto de cualquier incidente futuro que ocurra antes de que se
encuentre una solución permanente.
Los detalles de la solución temporal deberán documentarse en el registro del problema. El

personal responsable de manejar incidentes será entonces capaz de identificar y utilizar esta
información al resolver incidentes futuros. El registro del problema deberá permanecer abierto
mientras el equipo dedicado al problema sigue trabajando en una solución permanente.

Errores conocidos y la KEDB
Error conocido: Es un problema que tiene una causa raíz
documentada y una solución temporal. Los errores conocidos son
creaaüs y gestionados por la gestión de problemas. Los errores
conocidos también pueden ser identificados por los desarrolladores o
por los proveedores.
Los errores conocidos describen un problema que tiene una causa raíz documentada y una
solución temporal. Cuando esté listo, este registro deberá crearse dentro de la KEDB (base de
datos de errores conocidos) identificando el problema relacionado y el estado actual. La
información acerca de la causa raíz y las instrucciones relacionadas con la solución temporal,
deberán documentarse junto con el error conocido. Aunque ITIL define un error conocido como
un problema documentado con una causa y una solución temporal, puede haber momentos en los
que es valioso crear un registro de error conocido antes de que haya alcanzado ese estado. Por esta
razón, no es aconsejable imponer un punto de procedimiento concreto para crear un registro de
error conocido, sino permitir cierta flexibilidad en función de la situación específica. Se deberá
crear un registro de error conocido siempre que sea útil hacerlo.
Modelos de problema
Se pueden definir muchas iniciativas para hacer frente a los problemas. Los patrones se repiten a sí
mismos en el tiempo y el proveedor de servicios deberá buscar que se documenten iniciativas
consistentes para el manejo de estas situaciones. Por ejemplo, algunos problemas no se podrán
resolverse debido a lo elevado del costo. La organización puede optar por una iniciativa
consistente para asegurar que estas iniciativas se comunican de manera eficaz, se documentan y se
revisan de manera continua, ya que probablemente el costo de la solución sea menor en el futuro.

Incidentes vs. problemas
Propósito Incidentes y problemas no son la misma cosa:

• Los incidentes no "se conviertan" en problemas.
Objetivos • Los incidentes son el síntoma, los problemas son la
causa.
Alcance
La gestión de problemas se puede invocar si:
• Los incidentes no se pueden empatar con un
problema o error conocido.
• El análisis de tendencias revela un error subyacente.
Definiciones
importantes (!)ocurrió un incidente grave.
.____ ___, • Otras funciones de TI identifican un problema.
Incidentes vs.
problemas • El análisis de un grupo de soporte revela un
error subyacente
Actividades • La notificación de un proveedor de que existe un
problema.
Interfaces
Figura 160: Incidentes vs. problemas
Un incidente es una interrupción no planeada de un servicio de TI o la reducción en la calidad de

un servicio de TI. Un problema presenta una vista diferente de un incidente al entender sus causas
subyacentes, que pueden además ser la causa de otros incidentes. Los incidentes no se conviertan
en problemas. Mientras que las actividades de gestión de incidentes se centran en restaurar los
servicios al estado normal de las operación, las actividades de gestión de problemas se centran en
encontrar la manera de evitar que los incidentes ocurran en primer lugar. Es muy común tener
incidentes que también son problemas.
Las reglas para invocar la gestión de problemas durante un incidente puede variar y están a
discreción de las organizaciones individuales. Algunas situaciones generales en las que se puede
desear invocar la gestión de problemas durante un incidente podría incluir situaciones donde:
• La gestión de incidentes no puede encontrar la coincidencia de un incidente

con problemas existentes y errores conocidos.
• El análisis de tendencia de los incidentes registrados revela que puede existir
un problema subyacente.
• Se ha producido un incidente grave, en el que es necesario llevar a cabo
actividades de gestión de problemas para identificar la causa raíz.
• Otras funciones de TI identifican la existencia de un problema.
F.\ El service desk puede haber resuelto un incidente, pero no ha determinado
~ una causa definitiva y se sospecha que es probable que se repita.
• El análisis de un incidente realizado por un grupo de soporte revela que existe
o es probable que exista un problema subyacente.
• Se recibe una notificación de un proveedor de que existe un problema que
debe ser resuelto.22

Actividadesde la Gestión de Problemas

/ 6ervíce desk / /~ / Gestión / Gestión~ / / Proveecb'I
.
¿ 1 :· / de eventos
T.___
/
• __
/
L_- ...,íl -'
incidentes _.· , aclva problema~f
:::::::r , l
/ oonlratis1a /
]-'
J l ¡ '
Deteooión del
·rct>lema
e Categoozacioo
~a
Prioril.acioo del
~
~
( BDerror
ronociclol
1,
.,,.
"'-;;
.¡.
..._ _.,, r Resoixión
del~a
• LecciaMs a,rendídas
~ N!Slllallbs
<~=\·
,.-Sistiema gestián7"\
_.,,,¿Probl
'··~~, !Jave?,,,../
c~Ñ-= ~
No
4-
+-------- *Acciones-de mejora

• Comunicac:iones
Copyright© AXELOS Limited 2011. Todos los derechos reservados,
La reproducción del material es con permiso de AXELOS.
Figura 161: Actividades de la Gestión de Problemas23

Detección de problemas
Hay muchos disparadores o factores desencadenantes de la gestión de problemas y muchas fuentes
dentro de cada organización que pueden identificar y registrar un ticket de problema. Los
incidentes deberán revisarse y analizarse con frecuencia para identificar tendencias a medida que
se vuelven perceptibles. La categorización de incidentes deberá soportar a los "1 O principales"
informes de las categorías que están generando el mayor volumen de incidentes.
Los disparadores de la gestión reactiva de problemas incluyen:
• El Service Desk genera un ticket de problema en respuesta a un incidente

• El análisis de incidentes realizado por personal técnico revela un problema
• La detección automática de una falla a través de la gestión de eventos
• La notificación de un proveedor o contratista de que existe un problema
Los disparadores de la gestión proactiva de problemas incluyen:
• El análisis de múltiples incidentes revela un problema

• Las tendencias de incidentes históricos revelan un problema
• Las actividades destinadas a mejorar la calidad de un servicio resultan en el registro del
problema
Registro de problemas
De la misma manera que los incidentes, los problemas también se deben registrar. Este registro
soporta la gestión continua de un problema. Cada ticket problema deberá vincularse a cualquier
registros de incidente relacionados para dar al personal involucrado en el diagnóstico una imagen
precisa de los síntomas y los efectos.
Los registros del problema deberán incluir una descripción completa y exacta del problema y de
los incidentes relacionados.
Categorización de problemas
Las categorías utilizadas en la gestión de incidentes deberán utilizarse también para los tickets de
problema. El personal involucrado en la solución de incidentes deberá ser capaz de encontrar
fácilmente la coincidencia de los problemas y los errores conocidos. Esta tarea es tremendamente
dificil sin el uso consistente de categorías en todos los tickets de incidentes y problemas.
Priorización del problema

El método para asignar prioridades a los incidentes deberá utilizarse también para los tickets de
problema. El impacto y la urgencia en este caso también debe ser factor a tener en cuenta para la
frecuencia y el impacto de todos los incidentes relacionados. La gravedad del problema desde la
perspectiva del cliente también deberá tenerse en cuenta. Es totalmente posible que un centenar de
incidentes de baja prioridad puedan provocar un problema de alta prioridad que se registra debido
a el impacto acumulado que tendrá en la organización.

Investigación y diagnóstico del problema

Las técnicas adecuadas para analizar el problema se deberán aplicar de acuerdo a la naturaleza del
problema. También se puede consultar el CMS para ayudar a verificar el impacto del problema y
aislar las causas posibles. Es aconsejable intentar recrear y probar el problema en un ambiente de
pruebas. De esta manera los recursos de la gestión de problemas podrán investigar la causa raíz sin
necesidad de interrumpir a los usuarios.
Identificar soluciones temporales y generar registro de error

conocido
Cuando se identifica una solución temporal, se debe generar un registrqje error conocido. Cuando
esté listo, este registro deberá crearse dentro de la KEDB (base de datos de errores conocidos)
identificando el problema relacionado y el estado actual. La información acerca de la causa raíz y
las instrucciones relacionadas con la solución t~mporal, deberán documentarse junto con el error
conocido.
Aunque ITIL define un error conocido como un problema documentado con una causa y una
solución temporal, puede haber momentos en los que es valioso crear un registro de error conocido
antes de que haya alcanzado ese estado. Por esta razón, no es aconsejable imponer un punto de
concreto en el procedimiento para crear un registro de error conocido, sino permitir cierta
flexibilidad en función de la situación específica. Se deberá crear un registro de error conocido
siempre que sea útil hacerlo.
Resolución del problema

Una vez encontrada una solución, la gestión de problemas trabajará para implementar la solución
y resolver el problema. Muchas veces será necesario un cambio a un EC y estará bajo el control de
la gestión de cambios. Cuando la situación lo amerita, se deberá emitir un RFC de emergencia
para autorización acelerada. De lo contrario, se hará un RFC normal y se presentará al proceso de
gestión de cambios. La solución deberá aplicarse una vez que haya sido autorizada y programada.
Existen algunas circunstancias que impidan que un problema se resuelva. En algunas situaciones,
el costo de la solución puede ser superior al impacto de los incidentes que ocasiona. En estos
casos, es posible que la empresa no esté dispuesta a invertir en una solución permanente. Por lo
tanto, el ticket del problema deberá permanecer abierto y estar marcado para que no afecte el
desempeño del proceso de gestión de problemas; después de todo, hay una razón por la que se
quedó sin resolver. Mantener el registro del problema abierto es una manera de reconocer que el
problema sigue ocurriendo y asegura que se revisará periódicamente para evaluar si los costos o el
impacto han cambiado a un grado tal que pueda generarse una solución permanente.
En caso de que el equipo de gestión de problemas no sea capaz de resolver un problema debido a
la incapacidad de diagnosticar la causa, las actividades de investigación deberán seguir adelante. A
medida que se encuentren soluciones temporales, se deberá actualizar la prioridad del problema
para reflejar el impacto actual.
Cierre del problema

Una vez resuelto el problema, los registros relacionados se deberán actualizar y cerrar según
corresponda. El registro del problema deberá cerrarse, así como cualquier registro de incidente
relacionado, de acuerdo con el procedimiento de cierre de incidentes. Si se creó un registro de
error conocido, este registro deberá ser actualizado para reflejar que la solución ha sido aplicada y
el problema ahora está cerrado.

Revisión de un problema grave

Una vez resueltos, todos los problemas graves se deberán revisar como parte de un ejercicio para
documentar cualquiera de las lecciones aprendidas. ITIL sugiere que en las revisiones a los
problemas graves se examinen los siguientes elementos:
• Las cosas que se hicieron bien

• Las cosas que se hicieron mal
• Lo que podría hacerse mejor en el futuro
• Cómo evitar la recurrencia
• Si hubo alguna responsabilidad de terceros y si son necesarias acciones de
seguimiento24

/'
Interfaces de la Gestión de Problemas con otros procesos
Propósito Mejora
Diseño Transición Operación Continua
del Servicio del Servicio del Servicio del Servicio
Objetivos
Alcance
¡· Gestión
financiera de
• Gestión de
disponibilidad
• Gestión del
cambio.
I· Gestión de
incidentes.
• Proceso de
mejora de
I servicios de
TI. • Gestión de • Gestión de siete pasos.
capacidad. activos de
... Conceptos básico 1 servicio y
1 • Gestión de configuración.
continuidad
! del servicio de • Gestión de
Actividades ! TI. liberación e
implementación
• Gestión de
niveles de • Gestión del
servicio. conocimiento.
Figura 162: Interfaces de la Gestión de Problemas con otros procesos
Estrategia del Servicio

El proceso de gestión de problemas está relacionado con el siguiente proceso dentro de la
estrategia del servicio:
• Gestión financiera de servicios de TI: Ayuda a evaluar el impacto de las

resoluciones propuestas o soluciones temporales, así como el análisis del
valor del dolor. La gestión de problemas proporciona información de gestión
sobre el costo de la solución y prevención de problemas que se utiliza como
entrada a los sistemas de presupuestos y contabilidad, así como para los
cálculos del costo total de propiedad.25
Diseño del Servicio

La gestión de problemas está relacionada con los siguientes procesos dentro del diseño del
servicio:
• Gestión de la disponibilidad: Está involucrado en determinar cómo reducir el

tiempo de inactividad y aumentar el tiempo de actividad. Como tal, tiene una
estrecha relación con la gestión de problemas, especialmente en las áreas
proactivas. Gran parte de la información de gestión disponible en la gestión
de problemas será comunicada a la gestión de la disponibilidad.

• Gestión de capacidad : Algunos problemas necesitarán investigación realizada

por equipos de la gestión de capacidad, por ejemplo los problemas de
desempeño. La gestión de capacidad también ayudará a evaluar medidas
proactivas. La gestión de problemas proporciona información de gestión
relacionada con la calidad de las decisiones tomadas durante el proceso de
planificación de la capacidad.
• Gestión de continuidad del servicio de TI: La gestión de problemas actúa
como punto de entrada a la gestión de continuidad de servicios de TI (ITSCM),
cuando un problema significativo no es resuelto antes de que comience a
tener un impacto importante en el negocio.
• Gestión de niveles de servicio : La ocurrencia de incidentes y de problemas
afecta el nivel de la prestación del servicio, medido por el SLM. La gestión de
problemas contribuye a mejorar los niveles de servicio y su información de
gestión se utiliza como base de algunos de los componentes de revisión de
SLA. SLM también proporciona parámetros dentro de los cuales trabaja la
gestión de problemas, por ejemplo el impacto de la información y el efecto
sobre los servicios por resoluciones propuestas y medidas proactivas.26
Transición del Servicio

La gestión de problemas está relacionada con los siguientes procesos dentro de la transición del
servicio:
• Gestión de cambios: La gestión de problemas asegura que todas las

resoluciones o soluciones temporales que requieren un cambio a un EC se
envíen a través de la gestión de cambios mediante un RFC. La gestión de
cambios supervisará el progreso de estos cambios y mantendrá informada a la
gestión de problemas. La gestión de problemas también está involucrada en la
rectificación de la situación provocada por cambios fallidos.
• Gestión de activos de servicio y configuración: La gestión de problemas
utiliza el CMS para identificar ECs defectuosos y también para determinar el
impacto de los problemas y resoluciones.
• Gestión de liberación e implementación: Este proceso es responsable de
implementar soluciones de problemas en el ambiente de producción.
También ayuda a asegurar que los errores conocidos asociados sean
transferidos desde la KEDB de desarrollo a la base de datos de errores
conocidos que está en producción. La gestión de problemas ayudará a
resolver problemas causados por fallas durante el proceso de liberación.
• Gestión del conocimiento: El SKMS se puede usar para formar la base para la
KEDB y contener o integrarse con los registros de problemas.27


El proceso de gestión de problemas está relacionado con el siguiente proceso dentro de la
operación del servicio:
• Gestión de incidentes: La gestión de incidentes y la gestión de problemas dependen

críticamente de la una de la otra. Este tema ya se revisó a detalle en esta sección.
Mejora Continua del Servicio

El proceso de gestión de problemas está relacionado con el siguiente proceso dentro de la mejora
continua del servicio:
• Proceso de mejora en 7 pasos: La ocurrencia de incidentes y de problemas

proporciona una base para la identificación de oportunidades para la mejora
del servicio y para agregarlos al registro CSI. La gestión proactiva de
problemas puede también identificar problemas subyacentes y asuntos del
servicio que si se abordan, pueden contribuir a aumentar la calidad del
servicio y la satisfacción del cliente o usuario final.28

() Proceso de cumplimientode solicitudes

Propósitoy objetivosdel Cumplimiento de Solicitudes
I Propósito:
Gestionar el ciclo de vida de las solicitudes de los
usuarios.
Objetivos: l
Mantener la satisfaccióndel clientey del usuario.
Manejo eficiente.de las solicitudes.
Proporcionarun canal para que los usuariosy clientes
hagan solicitudes.
Proporcionarinformacióna clientesy usuariossobre los
servicios.
Proveer y entregar los componentesde servicios
Alcance requeridos.
Ayudarcon solicitudesde información,quejas, comentarios
y felicitaciones.
Figura 163: Propósito y objetivos del Cumplimiento de Solicitudes29
() Términos importantes
~:--.. ... ~~ Solicitud de servicio: Una solicitud de un usuario para obtener más
información o asesoría o para un cambio estándar o para acceder a un
servicio de TI (por ejemplo, para restablecer una contraseña o para
darle servicios de TI estándar a un usuario nuevo). Por lo general las
solicitudes de servicio son manejadas por un service desk y no
requieren un RFC. ~eqtt:&-t to( 0>0'<13C·
El cumplimiento de solicitudes es el conjunto de procesos genéricos que atiendan las solicitudes

de servicio de los usuarios.
Las solicitudes de servicio son a menudo bastante simples y de bajo costo o pueden incluso ser
una sencilla pregunta. Es su magnitud y frecuencia la que genera la necesidad de un seguimiento
específico y el proceso de cumplimiento.
Tener un proceso separado de cumplimiento de solicitudes también significa que dichas

solicitudes no agregarán una presión exagerada al proceso y sobre las personas que están
encargadas de manejar incidentes que ocasionan las interrupciones del negocio.

Alcance del Cumplimientode Solicitudes
• Las solicitudesson necesidades cotidianasde

Propósito los usuarios, clientes y personal del proveedor
de servicios.
• A veces son manejadas por el proceso de
gestión de incidentes {y herramientas):
• La solicitudesse conviertenen una categoría
especial de incidente.
Objetivos
• ~ veces manejadas mediante un proceso
independiente de cumplimientode solicitudes:
• Adecuado para un gran número de solicitudes.
• Tiposde registroseparado para facilitarel flujo
de trabajoe informesdiferenciados.
Figura 164: Alcance del Cumplimiento de Solicitudes
Las solicitudes se pueden desglosar en una serie de pasos que se almacenan como modelos de
solicitud en el sistema de gestión del conocimiento del servicio.
Aunque algunas organizaciones pueden dejar que las solicitudes de servicio se manejen a través de
sus procesos (y herramientas) de gestión de incidentes, deben estar conscientes del hecho de que
mientras que un incidente es una interrupción no planificada para el negocio, una solicitud de
servicio es algo que puede y debe ser planificada.
Otras organizaciones consideran que es más adecuado manejar las solicitudes de servicio como un
flujo de trabajo completamente separado y registrarlas y gestionarlas como un tipo de registro
separado o dentro de una herramienta independiente de la de incidentes. La precaución es asegurar
que se ha marcado una separación clara entre las solicitudes de servicio y las solicitudes de
cambio.
En última instancia, cada organización tiene que decidir el enfoque que mejor se adapte a sus
circunstancias particulares.
Dar seguimiento a las solicitudes por separado de los incidentes permite a la organización poner
límites claros entre lo que se considera una interrupción del servicio y lo que se considera parte
normal de la operación cotidiana. Algunas organizaciones lo logran a través de la categorización
de incidentes, mientras que otras organizaciones tratan a las solicitudes como entidades propias
/
que siguen flujos de trabajo específicos.
Siempre habrá zonas grises que impidan que se defina una guía genérica, lo que es válido para la
orientación en todos los procesos.

~ Proceso Gestión de Acceso

Propósitoy objetivosde la Gestión de Acceso
La gestiónde acceso otorgaa los usuariosautorizados
el derecho para utilizarun servicio,restringiendoel
acceso a usuariosno autorizados.
¡ Propósito:
Otorgarel derecho a los usuariospara que puedan utilizar
un servicio.
Ejecutar las políticas y acciones definidasen la gestión de
la se uridad de la información.
Í Objetivos:
I Gestionar el acceso a los servicioscon base en las
políticas y acciones definidas en la gestión de la seguridad
de la información. ·
Alcance Responder eficazmente a las solicitudesde acceso.
Monitorear el acceso a los serviciosy garantizar que los
derechos otorgadosno son utilizadosincorrectamente.
Figura 165: Propósito y objetivos de la Gestión de Acceso
La gestión de acceso, también conocida como "gestión de derechos" o "gestión de identidad", es el

proceso responsable de asegurar que los usuarios autorizados tengan los derechos necesarios para
usar un servicio, al mismo tiempo que se impide el acceso a usuarios no autorizados.
Este propósito no abarca la determinación de qué usuarios necesitan acceso a los servicios y datos,
se limita a hacer cumplir esas decisiones de manera cotidiana. La gestión de acceso debe operar
dentro de las políticas y acciones definidas por las etapas de estrategia y diseño del servicio,
incluyendo el proceso de gestión de la seguridad de la información.
Los objetivos del proceso de gestión de acceso son:
• Gestionar el acceso a los servicios con base en las políticas y acciones

definidas en la gestión de la seguridad de la información
• Responder eficientemente a las solicitudes para la concesión de acceso a los
servicios, para cambiar derechos de acceso o para restringir el acceso,
asegurando que los derechos que se otorgan o cambian son los correctos
• Supervisar el acceso a los servicios y garantizar que los derechos otorgados no
son utilizados incorrectamente"

O Alcance de la Gestión de Acceso
Dentro de su alcance:
• Protege la confidencialidad, integridad y disponibilidadde
Propósito los datos y la propiedad intelectual,mediante la ejecución
de las políticasde gestiónde seguridad de la información.
• Asegura que los usuarios autorizados cuentan con los
derechos necesarios para usar los servicios.
• Actua entre funciones,probablemente con un únicopunto
de coordinación.
Objetivos
Fuera de su alcance:
• Decidir quién debe tenerel derecho de utilizarun servicio:
• Responsabilidad de las fases de estrategia y diseño,
especialmente la gestión de la seguridad de la
información.
• Asegurarla disponibilidadde serviciosy datos:
• Responsabilidad de la gestión de la disponibilidad:
Figura 166: Alcance de la Gestión de Acceso
Confidencialidad:Un principio de seguridad que exige que sólo las
personas autorizadas tengan acceso a los sistemas y a los datos.
Integridad: Un principio de seguridad que garantiza que los datos y
elementos de configuración son modificados únicamente por personas y
actividades autorizadas. La integridad considera todas las causas
posibles de modificación, incluidas las fallas de software y hardware,
eventos ambientales y la intervención humana.
Disponibilidad:Habilidad de un servicio de TI u otro elemento de
configuración de desempeñar la función acordada cuando sea
necesario. En el contexto de la seguridad, la disponibilidad de los datos
y la propiedad intelectual se conserva cuando los servicios y los datos
están protegidos contra el acceso, modificación o destrucción no
autorizados.
A nivel operativo, la gestión de acceso ejecuta las políticas de la gestión de seguridad de la

información de la organización. En este rol, el proceso ayuda a garantizar que la confidencialidad,
integridad y disponibilidad de los datos están protegidos. El alcance de la gestión de acceso en este
contexto está en el cumplimiento de las políticas de seguridad, no en la actividad de definir estas
políticas. La gestión de acceso no decide quién debe tener acceso a los servicios y datos; la gestión
de acceso implementa esas decisiones.
/
Asegurar que los usuarios autorizados tienen el acceso que necesitan de acuerdo a su rol o función
es crítico para el proveedor de servicios. Sin acceso a los servicios que necesitan, el negocio o el
cliente no será capaz de darse cuenta del valor de los servicios que se ofrecen.

La gestión de acceso asegura que los servicios y datos que los usuarios necesitan para hacer su
trabajo, están disponibles. La gestión de acceso no garantiza que los servicios como tal estén
disponibles; eso es responsabilidad de la gestión de la disponibilidad.
La gestión de acceso se debe gestionar en toda la empresa. La gestión de acceso se llevará a cabo a
través de múltiples funciones del proveedor de servicios, aunque se beneficia de tener un punto
único y centralizado de coordinación. Este punto es a menudo el service desk o las funciones de
--
gestión de operaciones de TI. El acceso al hardware y al software suele gestionarse a través de
sistemas de gestión de acceso centralizados, aunque muchos de los sistemas de hardware y
software tendrán cierto nivel de funcionalidad de acceso localizada, exigiendo la participación de
especialistas en las funciones de gestión de aplicaciones y gestión técnica.

Información

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Información

Загружено:

Авторское право:

Доступные форматы

Operación del Servicio

t Proceso Gestión de Eventos

"'• ". Propósito .

Figura 143: Propósito de la Gestión de Eventos

La gestión de eventos proporciona la base para el monitoreo y control operacional. Aunque

.IIC..-llllllli-~'\o Términos importantes

5-14 © Global Knowledge Training LLC

Objetivosde la Gestión de Eventos

• Detectar todos los cambios de estado

Figura 144: Objetivos de la Gestión de Eventos

© Global Knowledge Training LLC 5-15

Alcance de la Gestión de Eventos

La gestión de eventos soporta cualquier

Figura 145: Alcance de la Gestión de Eventos

La gestión de eventos puede soportar muchas actividades en el ambiente del proveedor de

• ECs (elementos de configuración):

5-16 © Global Knowledge Training LLC

© Global Knowledge Training LLC 5-17

Conceptos básicos de la Gestión de Eventos: Tipos de evento

¡¡:- ~:;~'/'~ '\~ . ~e~~

Figura 146: Conceptos básicos de la Gestión de Eventos: Tipos de evento

• Eventos informativos: Ofrecen información que se puede utilizar para el análisis y la

5-18 © Global Knowledge Training LLC

Proceso Gestión de Incidentes fum~o-zo-

Propósitode la Gestión de Incidentes 12-eocl, l.D.

Objetivos Restaurar la operaciónnormal de los servicios

• Conceptos básicos ¡ Minimizarel· impactonegativo sobre las

Interfaces ¿Qué es un incidente?

Figura 147: Propósito de la Gestión de Incidentes

El propósito de la gestión de incidentes es asegurar que se mantienen los niveles de servicio

© Global Knowledge Training LLC 5-19

Objetivosde la Gestión de Incidentes

Figura 148: 'Objetlvos de la Gestión de Incidentes

ITIL define los siguientes objetivos de la gestión de incidentes:

• Asegurar que se utilizan métodos y procedimientos estandarizados para

5-20 © Global Knowledge Training LLC

Alcance de la Gestión de Incidentes

Figura 149: Alcance de la Gestión de Incidentes

La gestión de incidentes es el proceso que responde a los incidentes. Como la definición de

© Global Knowledge Training LLC 5-21

Conceptos básicos de la Gestión de Incidentes

Modelos de incidentes y plazos

Figura 150: Modelos de incidentes y plazos

Los modelos de incidentes deben incluir la siguiente información:

• Las medidas que se deben adoptar para controlar el incidente

5-22 © Global Knowledge Training LLC

• Precauciones que se deben tomar antes de resolver el incidente, por ejemplo,

© Global Knowledge Training LLC 5-23

Seguimiento del estado de incidentes

Figura 151: Seguimiento del estado de incidentes

ITIL proporciona los siguientes ejemplos del estado de los incidentes:

• Abierto: Se ha reconocido un incidente, pero aún no se le ha asignado un

5-24 © Global Knowledge Training LLC

Figura 152: Conceptos básicos de la Gestión de Incidentes Incidentes graves

L,, t.:c: : : ~Q Términos importantes

© Global Knowledge Training LLC 5-25

(J Actividadesde la Gestión de Incidentes

Alcance Hacia cumplimientode solicitud

Figura 153: Actividades de la Gestión de lncidentes13

5-26 © Global Knowledge Training LLC

Prioridad = Impacto y Urgencia

La prioridad debería basarse en la urgencia y el impacto de cada incidente. La urgencia se refiere a

© Global Knowledge Training LLC 5-27