Itil v2.5

Gestión de Servicios Informáticos
75.46 Administración C t l d Proyectos II
75 46 - Ad i i t ió y Control de P t

Lic. Sergio G. Martínez

El concepto de servicio
Cliente Lavadero Transporte Lavadero Industrial
Mismo día：500
En 4 H ： 50
En 4 H ： 50

Precio
P i por el S i i
l Servicio
Día Siguiente：300 En 2 H ： 100 En 2 H ： 100

SLA SLO

La Gestión del Servicio

El concepto de servicio
Los servicios son los medios para entregar valor a los
clientes, facilitando sus tareas para obtener resultados, sin
que los ellos deban asumir los costos específicos ni los riesgos
asociados.
Los proveedores de servicios asumen los riesgos y asignan
costos a cada cliente por los servicios que ellos proveen.
Los resultados se logran a través de la ejecución de tareas y
están limitados por la presencia de ciertas restricciones.
Los servicios facilitan la obtención de resultados por medio
del aumento del rendimiento de las tareas asociadas y la
reducción de los efectos de las restricciones.
El resultado es el incremento de la probabilidad de obtener
los resultados deseados.

Visión tradicional del Servicio Informáticos

etc.
ters
Aplicaciones
Negocio
atos

res
Servidor

Rout
Base de Da
es

A

Cliente de IT
T
Servicio de IT

C e
Servicio de IT

Tendemos a organizarnos de esta forma…

Desarrollo de
Aplicaciones Tecnología Operaciones

Objetivos y Objetivos y Objetivos y
Prioridades Prioridades Prioridades

Pero los clientes nos ven así…

Pero los clientes nos ven así…

• Disponibilidad
• Performance
P f
• Seguridad
• Soporte
• Etc.

Base de Da
es atos
Change
Managemennt
Servidor
res
Co
onfiguratio
on
Managemen nt
A
Aplicaciones
Incident
Managemen nt

Organización
Problem Rout
ters
Managemennt

Se
ervice Lev
vel etc.
Managemen nt

Servicio de IT
Servicio de IT
Negocio

C
Cliente de IT
e T
Nueva visión del Servicio Informáticos

Tradicional Gestión de Servicios Informáticos

Foco en Tecnología Foco en el Negocio
Administrar Infraestructura Proveer Servicios
Usuarios
Us ari s Clientes
Modalidad “Bombero” Prevención y Control
Reactivo Proactivo
Islas Integrado
Caos y arbitrariedad Estabilidad y Confiabilidad
Decisiones ad-hoc y personales Decisiones informadas y repetibles
Procesos informales Estandarización y mejores
prácticas

Visiones de TI


15% Tecnología: Herramientas e
infraestructura

Procesos: Definición, diseño,
estándares, mejora continua.

Gente: Roles y
85% responsabilidades,
administración,
administración desarrollo de
habilidades y disciplinas.

Cultura: Valores, normas tácitas,
experiencia.

ITIL
Information Technology Infrastructure Library
Biblioteca sobre:
◦ Provisión de Servicios basados en IT
◦ Gestión de la Infraestructura de IT
Generados por OGC, recolectando la experiencia de
los f
l referentes de mercado.
d d

ITIL
Mejores Prácticas (no metodología)
Lineamientos (no recetas)
Debe ser adaptado a cada caso:
◦ ¿Qué procesos son críticos en mi caso?
◦ ¿Cómo implemento en concreto cada proceso? (procedimientos,
definición de
d fi i ió d responsabilidades y autoridades, h
bilid d id d herramientas)
i )

¿Qué no es ITIL?
Una herramienta de Software.
La solución que un proveedor quiere imponer.
Un conjunto de procedimientos a cumplir/seguir.
El reemplazo de todo lo que ya hacemos bien.
El único componente requerido para brindar un
mejor servicio.
Independiente del comportamiento y cultura de la
organización.
organización
La solución a todos nuestros males (La bala de
plata).

El modelo ITIL
ITIL V3 está compuesto por las siguientes cinco
publicaciones:
bli i
1. Service Strategy
2.
2 Service Design
S i D i
3. Service Transition
4.
4 Service Operation
5. Continual Service Improvement

La Gestión del Servicio

El concepto de Gestión del Servicio
La Gestión del Servicio es un conjunto de
habilidades organizacionales especializadas para
proveer valor a los clientes en la forma de
servicios.
Las habilidades toman la forma de funciones y
procesos para gestionar los servicios a través de
un ciclo de vida, con especializaciones en:
p
1. Estrategia
2. Diseño
3. Transición
4. Operación
5. Mejora continua
5 M j ti

Procesos de:
• Transición
• Operación


CENTRO DE SERVICIOS AL
USUARIO

Objetivo
Proveer un punto único de contacto (SPOC) para los
clientes
li
Centralizar la gestión de la resolución de incidentes

Alcance
Restablecer la operación del servicio lo más rápido posible.
Registrar todos los incidentes/solicitudes.
Proveer un primer nivel de soporte y diagnóstico.
Proveer un primer nivel de solución cuando fuese posible.
Mantener informados a los usuarios del progreso de sus
casos.
Llevar a cabo las encuestas de satisfacción de los usuarios.
Cerrar incidentes y solicitudes.
s licit des
Actualizar la CMS.

Actividades
Clasificar, asignar, realizar diagnóstico inicial, priorizar y
escalar a quien corresponda el incidente
l i d l i id
Facilitar la rápida recuperación de los servicios
Ofrecer orientación a los usuarios
Promover el servicio mediante comunicaciones
Proveer información de gestión (tiempo resolución,
incidentes que resultaron ser RFC, cambios planificación
para el próximo período, etc )
período etc.)

Estructuras organizativas
Local
Centralizado
Virtual
Siguiendo al Sol

Local

Usuario Local Usuario Local Usuario Local Usuario Local

Service Desk
Local

Gestión de
Gestión Técnica Gestión de Soporte de Gestión de
Operaciones de TI
Aplicaciones
p terceros Requerimientos
q

Local
Diseñado para soportar las necesidades locales del
negocio.
i
El soporte se encuentra y brinda usualmente en la
misma localidad que está siendo soportada
soportada.
Es práctico para pequeñas organizaciones.
Es impráctico para organizaciones dispersas
E i á ti i i di
geográficamente.

Service Desk centralizado

Sede Cliente 1 Sede Cliente 2 Sede Cliente 3

Service Desk

Segunda línea

Gestión de
Gestión Técnica Gestión de Soporte de Gestión de
Operaciones de TI
Aplicaciones terceros Requerimientos

Service Desk centralizado
Se centraliza la atención de varios centros geográficos
distintos en un S i D k central.
di i Service Desk l
Puede requerirse soporte en forma presencial, pero
esto debe ser manejado y administrado desde el Service
Desk.
Ventajas para las grandes organizaciones:
◦ Reduce los costos operacionales.
◦ Una vista gerencial central consolidada.
g
◦ Mejora el uso de los recursos.

Service Desk virtual

San Francisco
Service Desk
Paris Rio de Janeiro
Service Desk Service Desk

Virtual
Service Desk

Sydney
Beijing Service Desk
Service Desk

Sistema de Gestión
de los Servicios de
Conocimiento
London
Service Desk

Service Desk virtual
La ubicación de los analistas del SD es transparente al
usuario.
i
Puede incluir elementos de tele-trabajo.
Deben existir procesos y procedimientos comunes – un
solo registro de incidentes.
Lenguaje común acordado para la entrada de datos.
L j ú d d l t d d d t
Punto único de contacto con el cliente.
Puede seguir requiriéndose presencia on-site para
algunos puntos.

Siguiendo al Sol
Permite brindar una cobertura de servicio total,
basándose en los husos horarios de las distintas
b á d l h h i d l di i
regiones geográficas desde donde se da servicio.
Se debe considerar en este caso especial atención
caso,
sobre las herramientas, procesos e idioma a utilizar por
las distintas regiones.

Grupos de Service Desk especializados
En algunos casos es recomendable crear grupos de
especialistas dentro de l f ió de S i D k
i li d d la función d Service Desk.
Esto permitirá derivar los incidentes según el tipo de
especialista que pueda resolverlos
resolverlos.

Recomendaciones
Recomendaciones de ambientación:
◦ Luz natural y suficiente espacio físico.
◦ Control acústico del ambiente.
◦ Área de esparcimiento o break.
Recomendaciones para facilitar el contacto único:
◦ Hacer público el número telefónico del Service Desk.
◦ Adhesivos informando el número en los teléfonos.
◦ U l
Utilización de salvapantallas con datos de contacto del S
ó d l ll d d d l Service
Desk.
◦ Incorporar merchandising con el número de contacto.
p g


GESTIÓN DE INCIDENTES

Objetivos
Restaurar la operación normal del servicio afectado lo
más rápido posible, minimizando el impacto en el
á á id ibl i i i d li l
negocio y asegurando que se mantengan los niveles
acordados de calidad y disponibilidad.
p
Se entiende por operación normal del servicio a lo que
se haya definido dentro de los límites del SLA.

Alcance
Abarca cualquier evento que impacte, o pueda impactar,
a un servicio.
i i
Existen eventos de tipo informativo, para lo cual existe
un tratamiento especial en el proceso de Gestión de
Eventos.
Las Peticiones de Servicio (Service Request) serán
derivados al proceso específico correspondiente.

Incidente
Se refiere tanto a la interrupción no planificada de un
servicio de TI como a la reducción en la calidad de éste.
i i d l d ió l lid d d é
También se consideran incidentes a aquellas fallas de
elementos de configuración que no hayan impactado
(todavía) a un servicio (Ej. la falla de un disco físico
correspondiente a un conjunto de discos espejados).

Modelos de incidentes
Son aquellos incidentes que pueden considerarse
repetitivos y para los cuales se crea un modelo
ii l l d l
predefinido de incidente. Se debe tener en cuenta:
◦ Los pasos a seguir en el incidente
incidente.
◦ El orden de estos pasos.
◦ Responsabilidades.
p
◦ Procedimientos de escalamiento.
◦ Líneas de tiempo.

Incidentes graves
Debe existir un proceso que se encargue del manejo de
incidentes graves.
i id
La definición de qué es un Incidentes graves debe ser
realizada a nivel corporativo, teniendo en cuenta los
corporativo
criterios de priorización e impacto al negocio.
Un Incidente grave no es un problema.
Puede requerirse la utilización de un equipo de
investigación dedicado.

Actividades
Identificación
Registro
Categorización y priorización
Diagnóstico Inicial
Escalamiento
Investigación y diagnóstico
Resolución y recuperación
eso uc ó ecupe ac ó
Cierre

Identificación
Puede ingresar en forma proactiva (monitoreo) o
reactiva (avisos d l usuario).
i ( i del i )

Registro
Todos los incidentes deben ser registrados.
En caso de detectar un Incidente al resolver otro, se
debe abrir un nuevo registro.
Datos básicos a incluir en un registro de incidente:
◦ Número único de referencia
◦ Prioridad
◦ Fecha y hora de registro
◦ CI relacionado
◦ Categoría de cierre
◦ Método de call-back
◦ E d del incidente
Estado d l d

Categorización
Se debe definir correctamente la granularidad del árbol
de
d categorización.
i ió
Pasos para lograr el diseño de las categorías:
◦ Sesión de brainstorming entre los involucrados.
◦ Definición del nivel inicial.
◦ U ili ió d l categorías i i i l por un período corto de
Utilización de las í iniciales í d d
tiempo.
◦ Realizar un análisis de lo registrado.
◦ Implementar las revisiones.
◦ Repetir el punto 4.

Priorización
Normalmente la prioridad de un incidente se define en función de:
◦ La urgencia: Cuán rápido el negocio necesita una solución.
◦ El impacto: Generalmente medido con la cantidad de usuarios afectados por el
incidente.

Otros factores determinantes del nivel de impacto son:
◦ Riesgo de vida.
◦ Número de servicios afectados
afectados.
◦ Nivel de pérdidas financieras.
◦ Efectos en la imagen (reputación) del negocio.
◦ Violación de marcos legales o regulatorios.

Algunas organizaciones necesitarán definir una prioridad especial para
usuarios VIP (Gerentes, Ejecutivos, Directores).
(Gerentes Ejecutivos Directores)

Priorización
Imapcto
p
Alto Medio Bajo
Alta 1 2 3
Urgencia
U Media
M di 2 3 4
Baja 3 4 5
Código de
Códi d Tiempo d resolución
Ti de l ió
prioridad Descripción promedio
1 Críitica 1 hora
2 Alta 8 horas
3 Media 24 horas
4 Baja 48 horas
5 Planificada Planificada

Diagnóstico inicial
Se utiliza para esto los scripts de diagnóstico y la base de
datos de errores conocidos
conocidos.
En esta actividad se intentará resolver el incidente en un
primer nivel de atención.
Escalamiento:
◦ Funcional
◦ J á
Jerárquico
Investigación y diagnóstico:
◦ Entender el orden cronológico de eventos que causaron el
incidente.
◦ Búsquedas a la KEDB.
◦ C f
Confirmar el impacto del incidente.
l d l d

Resolución y recuperación
Involucra la resolución del incidente para lo cual se
pueden usar los siguientes métodos:
d l i i é d
◦ Realizarlo conjuntamente con el usuario.
◦ R l l remotamente.
Resolverlo
◦ Utilizando un grupo de soporte presencial.
◦ Contactando un proveedor externo
externo.

Cierre
Esta actividad será realizada siempre por el Service
Desk.
D k
El Service Desk deberá validar junto con el usuario el
cierre del incidente. También deberá verificar lo
incidente
siguiente:
◦ Categorización de cierre.
g
◦ Encuesta de satisfacción.
◦ Documentación del incidente.
◦ Cierre formal.

Roles y responsabilidades
Administrador de Incidentes
◦ Promover la eficiencia y eficacia del proceso.
◦ Producir información de gestión.
◦ Administrar los recursos humanos.
◦ Monitoreo de la efectividad del proceso y recomendaciones de
mejora.
◦ Desarrollo y mantenimiento de los sistemas de la Gestión de
Incidentes.
◦ Administración de Incidentes Mayores.
◦ Desarrollo y mantenimiento del proceso de la Gestión de
Incidentes y sus procedimientos
procedimientos.

Primera línea
◦ Atención inicial de incidentes
◦ Escalamiento
Segunda línea
◦ Grupo de soporte (puede ser soporte de campo).
◦ Mayor conocimiento técnico.
Tercera línea
◦ Incluye a los grupos de especialistas (Servers, bases de datos,
redes).


GESTIÓN DE PROBLEMAS

Objetivos
Prevenir la ocurrencia de problemas e incidentes
asociados.
i d
Eliminar incidentes recurrentes.
Minimizar el impacto de incidentes que no pudieron ser
prevenidos.

Problema
Causa desconocida de uno o más Incidentes.

Impacto, urgencia y prioridad
Los problemas deben priorizarse utilizando los mismos
criterios utilizados para l I id
i i ili d los Incidentes (
(matriz d
i de
prioridades).
Se debe tener en cuenta lo siguiente:
◦ Frecuencia e impacto de incidentes relacionados.
◦ Definición sobre qué constituye un problema
problema.
◦ Incorporar el concepto de severidad del problema (costo,
tiempo de resolución, recursos).

Solución alternativa
En algunos casos puede ser encontrada una solución
alternativa a l i id
l i los incidentes causados por el problema.
d l bl
Es importante que aún así, se continúe con la
investigación de la causa raíz del problema
problema.
Siempre debe registrarse en la herramienta de gestión
el detalle de la solución alternativa encontrada.

Error conocido
Una vez que se complete el diagnóstico del problema y que
se haya encontrado una solución alternativa, se deberá
registrar en la KEDB el error conocido.
De esta manera, si surgen nuevos incidentes o problemas
relacionados, éstos p
, pueden ser resueltos rápidamente.
p
También puede detectarse la necesidad de registrar un error
conocido en una fase previa al diagnóstico, a modo
informativo.
Identificación de errores conocidos
◦ La identificación y registro del error conocido debe llevarse a cabo
aún si todavía no se ha encontrado la solución definitiva del error,
proporcionando información de su existencia y/o posibles registros
de soluciones temporales de prueba.
◦ Para evitar la duplicación de registros, se recomienda centralizar la
administración d la KEDB en un único responsable.
d i i t ió de l ú i bl

Base de datos de errores conocidos
Permite el almacenamiento del conocimiento obtenido a
través d l
t é de la resolución de incidentes y problemas, para
l ió d i id t bl
permitir un rápido diagnóstico y solución en caso que
ocurran.
El registro de error conocido debe contener detalles exactos
de la falla y sus síntomas, además de datos precisos para la
solución (alternativa o definitiva) del problema.
Pueden existir casos donde se decida convivir con un
problema en la infraestructura de TI, cuando el caso de
negocio no justifique la resolución.
f l l ó
Los datos incluidos en la KEDB debe ser fácilmente
accesibles.
accesibles

Gestor de Problemas
Grupos de Resolución de Problemas


GESTIÓN DE CAMBIOS

Gestión de Cambios
Objetivo:
◦ Mantener la Infraestructura bajo control
◦ Asegurar la aplicación de procedimientos estándares para la
atención de los cambios, de manera de minimizar el impacto en
cambios
los servicios.

Gestión de Cambios
Actividades:
◦ Aceptación (recepción y filtro inicial)
◦ Clasificación (menor, significativo, mayor, urgente)
◦ Aprobación y Planificación
◦ Seguimiento de la ejecución
◦ I f
Información de G ó (
ó d Gestión (cantidad de Cambios que no se
d dd C b
aceptaron, cambios OK, etc.)

Actividades
Crear RFC

Propuesta de
Cambios
(opcional)
Registrar el RFC

Actualizar el ca
Iniciador
Solicitado
Revisar el RFC

Gestión del C bi
G ió d l Cambio

ambio y la información de la congig
Listo para evaluación
Evaluar el cambio

Listo para decisión Ordenes de Trabajo
Autorizar la propuesta de Autorizar el
cambio cambio
Change authority
Autorizado

Plan actualizado

guración en el CM
Gestión del Cambio
Planificado Ordenes de Trabajo
Coordinar la implementación
de Cambio*

Gestión del Cambio

MS
Implementado
Revisar y cerrar el registro
Reporte de evaluación
de cambio
Cerrado
*Incluye construcción y prueba del cambio

Crear el RFC
El cambio es originado por pedido de un iniciador.
Para cambios mayores con implicaciones
organizacionales y/o financieras significativas, puede ser
requerida una propuesta de cambio (Change Proposal)
Proposal).
La propuesta de cambio contendrá una descripción
completa del cambio junto con una justificación
financiera y de negocio.
Los procedimientos para registrar y documentar los
cambios deben estar previamente definidos.

Crear el RFC
Número RFC

RFC Iniciación

Motivo del Cambio Descripción del Cambio

Análisis de Riesgo
CI (atributos)
e Impacto / Recursos
Fecha y Hora de
Prioridad U
P i id d y Urgencia
i
Implementación
Implementación
Recomendación del CAB
Programada
Implementador d l
I l t d del
Resultados del Cambio
Cambio

Resutado de las Pruebas Autorizado por

Fecha y Hora de Revisión
Aprobación Post-Implementación

Revisar el RFC
La Gestión de Cambios debe revisar cada uno de los
requerimientos y fil
i i filtrar l que considera que son:
los id
◦ Imprácticos.
◦ R
Repetidos en otros RFC recientes que fueron aprobados,
id i f b d
rechazados o continúan en revisión.
◦ Incompletos.

Evaluar el RFC
Debe evaluarse la implementación de cada cambio. Se
propone seguir el método d l siete ‘R’ d l G ió
i l é d de las i de la Gestión
del Cambio
◦ ¿Quién REQUIERE el cambio?
◦ ¿Cuál es la RAZÓN del cambio?
◦ ¿Cuál es el RETORNO esperado del cambio?
¿ p
◦ ¿Cuáles son los RIESGOS implicados en el cambio?
◦ ¿Cuáles son los RECURSOS necesarios para realizar el cambio?
◦ ¿Quién es RESPONSABLE de la construcción, prueba e
implementación del cambio?
◦ ¿Cuál es la RELACIÓN entre éste y otros cambios?
C ál l é bi ?

Gestión del Cambio

Evaluar el RFC
Categorización de riesgos.
Evaluación de cambios.
Asignación de prioridad.
Planificación de cambios.

Coordinar la Implementación
Los especialistas técnicos deben construir el cambio.
Change Management tiene la responsabilidad de
asegurar que los cambios sean implementados tal como
fueron planificados
planificados.
Verificar los procedimientos de vuelta atrás
(Remediation Plan)
Change Management tiene un rol de control para
asegurar que todos los cambios hayan sido testeados.

Gestión del Cambio

Revisar y Cerrar el RFC
Es necesario realizar una revisión post-implementación
para confirmar
fi
◦ Que el cambio cumplió con sus objetivos.
◦ Q el i i i d y los demás i
Que l iniciador l d á interesados están conformes con el
d á f l
resultado.
◦ Que no se han producido efectos colaterales.

Gestión del Cambio

Administrador de Cambios
◦ Asigna prioridades a los RFC junto con el iniciador.
◦ Rechaza los RFC que son impracticables.
◦ Lista todos los RFC para ser revisados en las reuniones del
CAB.
◦ Elabora la agenda de la reunión y la envía con anticipación a
todos los miembros del CAB.
◦ Decide quiénes deben asistir a las reuniones, dependiendo de la
naturaleza del RFC, qué es lo que será modificado y qué áreas
RFC
de conocimiento técnico son necesarias.

Gestión del Cambio

Administrador de Cambios
◦ Convoca las reuniones del Comité de Cambios / Comité de
Emergencia (CAB/EC : Change Advisory Board / Emergency
Committee) para los cambios urgentes.
◦ Preside todas las reuniones del CAB y del CAB/EC.
◦ Actualiza el registro del cambio.
◦ Revisa todos los cambios implementados.
◦ Cierra los RFC.
◦ Realiza reportes regulares de la gestión.

Gestión del Cambio

Comité de Administración de Cambios
◦ El CAB es un cuerpo que existe para dar soporte en la
autorización de los cambios y en asistir en la evaluación y
priorización de los mismos.
◦ Reglamento del CAB
Deben distribuirse los RFC con antelación a la reunión.
Responder y realizar el análisis de los RFC (mandatorio).
Concurrir a la reunión del CAB (opcional).
Aprobar o rechazar los RFC.
Analizar cambios aplicados sin una referencia al CAB
Revisión del proceso de cambios
Resultados del negocio que salen del proceso de cambio

Gestión del Cambio

Comité de Emergencias
◦ Es un grupo pequeño de personas que se reúnen o contactan
para la evaluar y autorizar los cambios de emergencia.
◦ La selección de los miembros puede depender de la naturaleza
del cambio. Los miembros deben tener conocer y entender
tanto las perspectiva del negocio como los temas técnicos, para
poder tomar las decisiones apropiadas.
◦ El contacto vía teléfono o email puede ser el único medio
factible de reunión.


GESTIÓN DE ACTIVOS DE
SERVICIO Y CONFIGURACIÓN

Gestión de la Configuración
Objetivo:
◦ Identificar, registrar y ofrecer información de todos los
componentes de IT que están bajo el control de Gestión de la
Configuración

Los CI (configuration items) se registran en una CMDB
(configuration management d b )
( fi i database)
Los CI tienen:
◦ Alcance (qué aplicativos, sectores, etc interesan?)
◦ Nivel (registro “1 PC” o registro “1 mouse” + 1 teclado”, etc)
◦ A ib
Atributos
◦ Relaciones
DSL (Definitive Software Library)


SLA Personas Ubicaciones

Información
Capacidad Activos

Información
Disponibilidad Releases
CMDB

Licencias
Documentación

Información
Cambios Incidentes
Financiera

Actividades:
◦ Planificar
◦ Identificar
◦ Controlar
◦ Información de gestión (info de capacidad y crecimiento,
clasificación de los CI’s, cambios que tuvo cada CI, datos
CI s,
incorrectos en la CMDB, etc )

Configuration Management System
Para administrar configuraciones grandes y complejas, la
gestión requiere el uso d algún sistema d soporte, al
ió i l de l ú i de l
que normalmente se conoce como Configuration
Management System.
g y
El CMS mantiene en la CMDB toda la información de
los CI bajo control de configuración según está definida
en el alcance.

Definitive Media Library
La Definitive Media Library es una biblioteca segura en la
cual las versiones definitivas de todos los CI son almacenadas
y protegidas.
En la DML se almacenan todas las copias maestras que han
p
pasado por los controles de calidad.
p
La DML debe incluir copias definitivas de software comprado
(junto con licencias e información) y de software
desarrollado internamente.
Las copias maestras de la documentación de un sistema
también deben ser almacenada de forma electrónica en la
DML.
La DML incluirá un lugar físico para guardar copias.
Sólo lo que ha sido debidamente autorizado podrá aceptarse
en la DML
DML.

Relación entre la DML y la CMDB
DML and CMDB

DML Cis Físicos Información sobre CIs

Cis CMDB
Electrónicos
Registro de
versión

Construcción de
una nueva
versión

Prueba de una Implementación de
nueva versión una nueva versión

Distribución de una
nueva versión en
producción

Configuration Baseline
Es la configuración de un servicio producto o
infraestructura que h sido formalmente revisada,
i f ha id f l i d
acordada
Servirá de base para futuras actividades y puede ser
modificada sólo a través de procedimientos formales de
cambio.
Contiene la estructura, los contenidos y los detalles de
una configuración, y representa un conjunto de CI y sus
relaciones.
relaciones

Configuration Snapshot
Es el estado actual de un CI o de un entorno, por
ejemplo obtenido a través d una herramienta de
j l b id é de h i d
descubrimiento.
Esta foto es guardada en el CMS y queda como un
registro de estado histórico.

Roles del Proceso
Administrador de Activos de Servicio
Administrador de Configuraciones
Analista de Configuraciones
Administrador de la Librería de Medios
Administrador de Herramientas / CSM
Comité de Control de Configuración


GESTIÓN DE LIBERACIONES
Y DESPLIEGUE

Gestión de Liberaciones
Objetivo:
◦ Asegurar que todos los aspectos de la liberación de un cambio
(técnicos y no técnicos) sean tenidos en cuenta.
◦ Facilitar la introducción del software y hardware en un ambiente
de IT controlado

Alcance
Asegurar planes de despliegue e implementación claros
y comprensibles
comprensibles.
Definir paquetes de versiones que puedan ser
construidos, instalados, testeados y desarrollados
eficientemente, para que sea posible una
implementación exitosa.
Permitir introducir servicios nuevos o modificados
modificados,
junto con los sistemas, tecnología y organización que lo
soporten, que sean capaces de cumplir con los SLA.
Lograr clientes, usuarios y personal de sistemas
conformes con las prácticas y los entregables del
p
proceso.

Unidad de implementación
Describe la porción de un servicio o de la
infraestructura d TI que normalmente es lanzada en
i f de l l d
forma conjunta, de acuerdo con la política de versiones
de la organización.
g
Puede variar dependiendo del tipo de elemento o
componente de servicio, sea éste HW o SW.
Las versiones deben ser identificados de forma única de
acuerdo con el esquema definido en la política de
release.
release La identificación del release debe incluir una
referencia a los CI que representa. Servicio A de TI

A1 A2 A3

A2.1 A2.2 A3.1

A2.1.1

Paquete de implementación
Un paquete puede ser una única versión o un conjunto
estructurado de unidades de implementación .
d d id d d i l ió

Formas de implementación
Big Bang vs. Por fases
◦ Big Bang: El servicio nuevo o modificado es implementado conjuntamente a
todos los usuarios.
◦ Por fases: El servicio es implementado inicialmente a una parte de los
usuarios, y luego se repite la misma operación al resto de usuarios siguiendo
un plan.

Push vs. pull
◦ Push: El componente del servicio es distribuido desde una posición central
a las estaciones de trabajo de los usuarios.
◦ Pull: El componente del servicio es colocado en una p
p posición central y los
usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo.

Automatizado vs. manual
◦ E el mecanismo de implementación de las versiones.
Es l d l ó d l

Actividades
Planificación (políticas, recursos)
Preparación y automatización de la instalación
Aceptación (de usuarios y demás áreas afectadas)
Planificación del despliegue
Comunicación
Capacitación
Distribución e instalación (despliegue)
st buc ó sta ac ó ( esp egue)
Información de Gestión (cantidad de despliegues,
cantidad de CI’s impactados en cada despliegue, etc.)

Actividades
Roles de Administración de Cambios Órdenes de Trabajo para
Cambio Menor

Órdenes de Trabajo
para Cambio
Signif icativ o o May or 5
Administración de Cambios

"Planeación de Corrección Menor no autorizada"

"Planeación de Corrección Menor autorizada"
"Planeación de Corrección Menor autorizada"

"Planeación de Corrección Significativa o May no autorizada"

"Planeación de Corrección Significativa o May autorizada"
Administrador de Liberación
Orden de Trabajo para

mpletadas
Empresarial
"Ciclo de Cambio Estándar
Planeación de 8.1 Políticas de
Liberación 8.2
82
Liberaciones" Revisar y Actualizar Políticas

mbio Significativo o Mayor com
Planear Liberación
y Plan de Liberación Anual

mbio Estándar completadas

mbio Menor completadas
Políticas y Plan de Liberación
Sistema de Administración de Anual actualizados
Servicios Plan de Rev ersión de

"Cambio Significativo o Mayo revertido"
Liberación

eración"

"Cambio Menor revert ido"

or
Órdenes de Trabajo para Cam


"Tiempo insuficiente para Libe
Políticas y
P líti

yor

yor
"Cambio Estándar revertido"

"Plan de Corrección Menor"

"Plan de Corrección Mayor"
Plan de
Liberación
Roles de Administración de Anual
Problemas Notas de Liberación
3 (posibles errores
conocidos)
Administración de Problemas

Administrador de Liberación
"Prueba de
Sistema de Aceptación Notif icación sobre
8.4 8.5
8.3 Monitoreo exitosa" serv icio prov isto
Realizar Pre-Producción y Activar Liberación
Preparar Liberación disponible
Validación

"Liberación f allida y
"Liberación implementada"
Corrección no autorizada"

FIN FIN
Roles de Administración de
Incidentes y Requerimientos de
2
Servicio
Administración de
Incidentes y
Requerimientos de Servicio

Roles
Gestor de Implentación y Versión (Release and
Deployment M
D l Manager))
Gestor del Paquete de Implementación (Release
Packaging and Build Manager)
Personal del Despliegue (Deployment staff)

Interacción entre los principales
procesos d Transición y Operación
de T ó O ó
Incidente
escalado

CLIENTES Incidente / Gestión de
Requerimiento Incidentes
De Servicio Incidente Problema
resuelto
Marketing Service
Ventas Desk
Finanzas Incidente /
Requerimiento
Clientes externos De servicio
Etc. resuelto
Gestión de
Gestión de Problemas
la Configu‐
l C fi
Cis ración RFC
Base de
conocimiento

SLA
RFC
Catálogo
de
Servicios

Gestión de Gestión de
Release Cambios

Escenario Genérico
¿Tiene
SLA?
¿Qué hacer?
Cliente
Incidente 1
Incident
Manager
Restauración de servicio (1), SL Gold, Tiempo: 15m.
Incidente 2

Restauración de servicio (2), SL “Silver”, Tiempo: 1hr.

Se evitan futuros
incidentes ¿Tiene
relacionados con
l i d Identifica la
Id ifi l SLA?
la Causa Raíz Causa Raíz Incidentes
Registrados
¿Cuál es el mejor
Release/Operations momento? Change Problem
Manager Manager Manager

Service Request for
Order Change

Escenario Genérico
Cliente
Incidente 1
Incident
Restauración de servicio (1), SL Gold, Tiempo: 15m. Manager
Incidente 2

Restauración de servicio (2), SL “Silver”, Tiempo: 1hr.

Se evitan futuros
incidentes
CMDB
relacionados con
l i d
Configuration Mgmt. DB
la Causa Raíz Incidentes
Registrados

Release/Operations Change Problem
Manager Manager Manager

Service Request for
Order Change


GESTIÓN DE NIVELES DE
SERVICIO

Gestión de Niveles de Servicio
Objetivo:
◦ Mantener y optimizar la calidad de los servicios de IT, a través de
ciclos constantes de acuerdo y monitoreo para alcanzar los
objetivos de negocios del cliente

SLA:
◦ Service level agreement es un acuerdo escrito entre el
proveedor de servicios de IT y sus clientes donde se definen
puntos claves de servicios y responsabilidades de ambas partes.

Actividades:
◦ Planificar: Establecer el proceso (mediciones actuales, iniciar
acuerdos internos y con proveedores)
◦ Implementar SLA (definir catálogo de servicios acordar SLAs,
servicios, SLAs
definir frecuencia de revisiones y mediciones)
◦ Administrar el proceso (realizar y evaluar mediciones, revalidar
con el cliente, actualizar SLA )
l l l SLAs)


OLAs Áreas
SLRs
Internas

Catálogo
de
Cliente Servicios
S i i
de TI
Áreas
SLAs UCs
Externas


GESTIÓN DE CAPACIDAD

Gestión de la Capacidad
Objetivo:
◦ Asegurar que todos los aspectos de performance (actuales y
futuros) de los requerimientos de negocio sean provistos de
manera efectiva en costos
◦ Balancear capacidad con demanda

Gestión de la Capacidad
Actividades:
◦ Business Capacity Management:
Asegura que se tengan en cuenta los requerimientos futuros del
negocio para los servicios de IT, planificándolos e implementándolos
en los tiempos requeridos
◦ Service Capacity Management:
Identifica e interpreta la performance actual de los servicios de IT
(donde están los picos? Se cumple con los SLAs?)
◦ Resource Capacity Management:
Identifica e interpreta la capacidad y utilización de cada elemento de
la infraestructura. Está al tanto de nuevas tecnologías. Asegura el uso
óptimo de los recursos.


GESTIÓN DE
DISPONIBILIDAD

Gestión de la Disponibilidad
Objetivo:
◦ Optimizar la capacidad de la infraestructura de IT, los Servicios y
la Organización de soporte para proveer un nivel de
disponibilidad efectivo en costos y que facilite al negocio
alcanzar sus objetivos
◦ Minimizar interrupciones en los servicios

Gestión de la Disponibilidad
Actividades:
◦ Determinar requerimientos (OLO)
◦ Planificar
◦ Monitorear
◦ Información de Gestión


GESTIÓN DE LA
CONTINUIDAD DEL
SERVICIO

Gestión de Continuidad del
Servicio
Objetivo:
◦ Asegurar que los servicios de IT puedan ser recuperados dentro
de los plazos acordados

Gestión de Continuidad del Servicio
Actividades:
◦ Inicio (definición y organización del proyecto, identificación de
políticas, recursos requeridos, etc.)
◦ Requerimientos y estrategia (definición de procesos de negocio
críticos, pérdida potencial, plazos; se trata de una evaluación de
riesgos)
◦ I l
Implementación (d f
ó (definición de procedimientos, contratos con
ó d d
proveedores, instalaciones, capacitación, pruebas)
◦ Administración (pruebas p
(p periódicas)
)


GESTIÓN FINANCIERA

Gestión Financiera
Objetivo:
◦ Costear y distribuir los servicios de IT

Gestión Financiera
Actividades:
◦ Presupuestación
◦ Contabilidad
◦ Distribución
◦ Información de Gestión

Gestión Financiera

Hardware Software Transferencias

Servicios Externos Oficinas Gente


FIN

Itil v2.5

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Itil v2.5

Último

Itil v2.5