Administración y Control de Proyectos Informáticos ITIL v2.5

Gestión de Servicios InformáticosGestión de Servicios Informáticos
75 46 Ad i i t ió C t l d P t II75.46 - Administración y Control de Proyectos II
Lic. Sergio G. Martínez

Retomando…Retomando…Retomando…Retomando…

El concepto de servicioEl concepto de servicio
Cliente Lavadero Transporte Lavadero Industrial
Mismo día：500 En 4 H ： 50 En 4 H ： 50
P i l S i i

Día Siguiente：300

En 2 H ： 100

En 2 H ： 100
Precio por el Servicio
SLA SLO

La Gestión del Servicio
Los servicios son los medios para entregar valor a los
clientes, facilitando sus tareas para obtener resultados, sinclientes, 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 asignanLos 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.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.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áticosVisión tradicional del Servicio InformáticosVisión tradicional del Servicio InformáticosVisión tradicional del Servicio Informáticos
Negocio
atos
res
nes
ters
etc.
T
Negocio
esdeDa
Servidor
Aplicacio
Rout
edeIT
Servicio de IT
Base
A
Cliente
Servicio de IT
C
Servicio de IT

Tendemos a organizarnos de esta forma…Tendemos a organizarnos de esta forma…Tendemos a organizarnos de esta forma…Tendemos a organizarnos de esta forma…
Desarrollo de
Aplicaciones Tecnología Operaciones
Objetivos y
Prioridades
Objetivos y
Prioridades
Objetivos y
Prioridades

Pero los clientes nos ven así…Pero los clientes nos ven así…Pero los clientes nos ven así…Pero los clientes nos ven así…

Pero los clientes nos ven así…Pero los clientes nos ven así…Pero los clientes nos ven así…Pero los clientes nos ven así…
• Disponibilidad
P f• Performance
• Seguridad
• Soporte
• Etc.

Nueva visión del Servicio InformáticosNueva visión del Servicio InformáticosNueva visión del Servicio InformáticosNueva visión del Servicio Informáticos
Negocio
atos
res
nes
ters
etc.
T
Negocio
esdeDa
Servidor
Aplicacio
Rout
edeIT
Servicio de IT
Base
A
on
nt
nt
nt
nt
vel
nt
Cliente
Servicio de IT
onfiguratio
anagemen
Incident
anagemen
Problem
anagemen
Change
anagemen
erviceLev
anagemen
C
Servicio de IT
Organización
Co
M
M
M
M
Se
M

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

Gestión de Servicios InformáticosGestión de Servicios InformáticosGestión de Servicios InformáticosGestión de Servicios Informáticos
15% Tecnología: Herramientas e
infraestructura
Procesos: Definición, diseño,
estándares, mejora continua.
85%
Gente: Roles y
responsabilidades,
administración desarrollo deadministración, desarrollo de
habilidades y disciplinas.
Cultura:Valores, normas tácitas,
experiencia.

ITILITILITILITIL
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
l f d dlos referentes de mercado.

ITILITILITILITIL
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,
d fi i ió d bilid d id d h i )definición de responsabilidades y autoridades, herramientas)

¿Qué¿Qué nono es ITIL?es ITIL?¿Qué¿Qué nono es ITIL?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ónorganización.
La solución a todos nuestros males (La bala de
plata).plata).

El modelo ITILEl modelo ITILEl modelo ITILEl modelo ITIL
ITILV3 está compuesto por las siguientes cinco
bli ipublicaciones:
1. Service Strategy
2 S i D i2. Service Design
3. ServiceTransition
4 Service Operation4. Service Operation
5. Continual Service Improvement

El concepto de Gestión del ServicioEl concepto de Gestión del Servicio
La Gestión del Servicio
El concepto de Gestión del ServicioEl concepto de Gestión del Servicio
La Gestión del Servicio es un conjunto de
habilidades organizacionales especializadas parahabilidades 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 M j ti5. Mejora continua

Procesos de:
•Transición
• Operación

CENTRO DE SERVICIOS ALCENTRO DE SERVICIOS AL
Gestión de Servicios Informáticos
CENTRO DE SERVICIOS ALCENTRO DE SERVICIOS AL
USUARIOUSUARIO

ObjetivoObjetivoObjetivoObjetivo
Proveer un punto único de contacto (SPOC) para los
liclientes
Centralizar la gestión de la resolución de incidentes

AlcanceAlcanceAlcanceAlcance
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 s licit desCerrar incidentes y solicitudes.
Actualizar la CMS.

ActividadesActividadesActividadesActividades
Clasificar, asignar, realizar diagnóstico inicial, priorizar y
l i d l i idescalar a quien corresponda el incidente
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 )para el próximo período, etc.)

Estructuras organizativasEstructuras organizativasEstructuras organizativasEstructuras organizativas
Local
Centralizado
Virtual
Siguiendo al Sol

LocalLocalLocalLocal
Usuario Local Usuario Local Usuario Local Usuario Local
Service DeskService Desk
Local
Gestión de
Requerimientos
Soporte de
terceros
Gestión de
Operaciones deTI
Gestión de
Aplicaciones
GestiónTécnica
qp

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

Service Desk centralizadoService Desk centralizado
Sede Cliente 1 Sede Cliente 2 Sede Cliente 3
Service DeskService Desk
Segunda línea
Gestión deSoporte de
Gestión de
Operaciones deTI
Gestión deGestiónTécnica
Requerimientosterceros
Operaciones deTI
Aplicaciones

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

Service Desk virtualService Desk virtual
San Francisco
Service Desk
Virtual
Paris
Service Desk
Rio de Janeiro
Service Desk
Service Desk
Beijing
Sydney
Service Desk
Service Desk
Sistema de Gestión
de los Servicios de
London
Service Desk
Conocimiento

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

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

Grupos deGrupos de ServiceService DeskDesk especializadosespecializadosGrupos deGrupos de ServiceService DeskDesk especializadosespecializados
En algunos casos es recomendable crear grupos de
i li d d l f ió d S i D kespecialistas dentro de la función de Service Desk.
Esto permitirá derivar los incidentes según el tipo de
especialista que pueda resolverlosespecialista que pueda resolverlos.

RecomendacionesRecomendacionesRecomendacionesRecomendaciones
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 ó d l ll d d d l S◦ Utilización de salvapantallas con datos de contacto del Service
Desk.
◦ Incorporar merchandising con el número de contacto.p g

GESTIÓN DE INCIDENTESGESTIÓN DE INCIDENTES
GESTIÓN DE INCIDENTESGESTIÓN DE INCIDENTES

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

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

IncidenteIncidenteIncidenteIncidente
Se refiere tanto a la interrupción no planificada de un
i i d TI l d ió l lid d d éservicio de TI como a la reducción en la calidad de éste.
También se consideran incidentes a aquellas fallas de
elementos de configuración que no hayan impactadoelementos 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 incidentesModelos de incidentesModelos de incidentesModelos de incidentes
Son aquellos incidentes que pueden considerarse
i i l l d lrepetitivos y para los cuales se crea un modelo
predefinido de incidente. Se debe tener en cuenta:
◦ Los pasos a seguir en el incidenteLos pasos a seguir en el incidente.
◦ El orden de estos pasos.
◦ Responsabilidades.p
◦ Procedimientos de escalamiento.
◦ Líneas de tiempo.

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

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

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

RegistroRegistroRegistroRegistro
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: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 d l d◦ Estado del incidente

CategorizaciónCategorizaciónCategorizaciónCategorización
Se debe definir correctamente la granularidad del árbol
d i ióde categorización.
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 í i i i l í d d◦ Utilización de las categorías iniciales por un período corto de
tiempo.
◦ Realizar un análisis de lo registrado.
◦ Implementar las revisiones.
◦ Repetir el punto 4.

PriorizaciónPriorizaciónPriorizaciónPriorizació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◦ Número de servicios 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
usuariosVIP (Gerentes Ejecutivos Directores)usuariosVIP (Gerentes, Ejecutivos, Directores).

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

Diagnóstico inicialDiagnóstico inicialDiagnóstico inicialDiagnóstico inicial
Se utiliza para esto los scripts de diagnóstico y la base de
datos de errores conocidosdatos de errores 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 elEntender el orden cronológico de eventos que causaron el
incidente.
◦ Búsquedas a la KEDB.
C f l d l d◦ Confirmar el impacto del incidente.

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

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

Roles y responsabilidadesRoles y responsabilidadesRoles y responsabilidadesRoles 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.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 procedimientosIncidentes y sus 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 PROBLEMASGESTIÓN DE PROBLEMAS
GESTIÓN DE PROBLEMASGESTIÓN DE PROBLEMAS

ObjetivosObjetivosObjetivosObjetivos
Prevenir la ocurrencia de problemas e incidentes
i dasociados.
Eliminar incidentes recurrentes.
Minimizar el impacto de incidentes que no pudieron ser
prevenidos.

ProblemaProblemaProblemaProblema
Causa desconocida de uno o más Incidentes.

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

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

Error conocidoError conocidoError conocidoError conocido
Una vez que se complete el diagnóstico del problema y que
se haya encontrado una solución alternativa, se deberá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 pueden ser resueltos rápidamente., p 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,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
d i i t ió d l KEDB ú i bladministración de la KEDB en un único responsable.

Base de datos de errores conocidosBase de datos de errores conocidosBase de datos de errores conocidosBase de datos de errores conocidos
Permite el almacenamiento del conocimiento obtenido a
t é d l l ió d i id t bltravés de la resolución de incidentes y problemas, para
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.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
f l l ónegocio no justifique la resolución.
Los datos incluidos en la KEDB debe ser fácilmente
accesiblesaccesibles.

Gestor de Problemas
Grupos de Resolución de Problemas

GESTIÓN DE CAMBIOSGESTIÓN DE CAMBIOS
GESTIÓN DE CAMBIOSGESTIÓN DE CAMBIOS

Gestión de CambiosGestión de CambiosGestión de CambiosGestió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 enatención de los cambios, de manera de minimizar el impacto en
los servicios.

Gestión de CambiosGestión de CambiosGestión de CambiosGestió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 ó d G ó ( d d d C b◦ Información de Gestión (cantidad de Cambios que no se
aceptaron, cambios OK, etc.)

ActividadesActividadesActividadesActividadesCrearRFC
Propuesta de
Cambios
(opcional)
RegistrarelRFC
Revisar el RFC
Iniciador
Solicitado
G ió d lC bi
Actualizarelca
Evaluarel cambio
Gestión delCambio
Listo para evaluación
Ordenes de TrabajoListo para decisión
ambioylainform
Autorizar la propuesta de
cambio
Autorizarel
cambio
Plan actualizado
Change authority
Autorizado
acióndelacongig
Planificado
Coordinarla implementación
de Cambio*
Gestión delCambio
Gestión delCambio
Ordenes de Trabajo
guraciónenelCM
Cerrado
*Incluye construccióny prueba delcambio
Gestión delCambio
Reporte de evaluación
Implementado
Revisary cerrar el registro
de cambio
MS

Crear el RFCCrear el RFCCrear el RFCCrear 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)requerida una propuesta de cambio (Change Proposal).
La propuesta de cambio contendrá una descripción
completa del cambio junto con una justificacióncompleta 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 RFCCrear el RFCCrear el RFCCrear el RFC
RFCRFC
Número RFCNúmero RFC
RFCRFC IniciaciónIniciación
Motivo del CambioMotivo del Cambio Descripción del CambioDescripción del Cambio
P i id d U iP i id d U i
CI (atributos)CI (atributos)
Fecha y Hora deFecha y Hora de
Análisis de Riesgo
e Impacto / Recursos
Análisis de Riesgo
e Impacto / Recursos
Implementación
Programada
Implementación
Programada
Recomendación del CABRecomendación del CAB
Prioridad y UrgenciaPrioridad y Urgencia
I l t d d lI l t d d l
y
Implementación
y
Implementación
Resultados del CambioResultados del Cambio
Implementador del
Cambio
Implementador del
Cambio
Autorizado porAutorizado porResutado de las PruebasResutado de las Pruebas
Fecha y Hora de
Aprobación
Fecha y Hora de
Aprobación
Revisión
Post-Implementación
Revisión
Post-Implementación

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

Evaluar el RFCEvaluar el RFCEvaluar el RFCEvaluar el RFC
Debe evaluarse la implementación de cada cambio. Se
i l é d d l i ‘R’ d l G iópropone seguir el método de las siete ‘R’ de la Gestión
del Cambio
◦ ¿Quién REQUIERE el 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?
C ál l RELACIÓN é bi ?◦ ¿Cuál es la RELACIÓN entre éste y otros cambios?

Evaluar el RFCEvaluar el RFC
Gestión del Cambio
Evaluar el RFCEvaluar el RFC
Categorización de riesgos.
Evaluación de cambios.
Asignación de prioridad.
Planificación de cambios.

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

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

Roles y responsabilidadesRoles y responsabilidades
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 aElabora 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é áreasnaturaleza del RFC, qué es lo que será modificado y qué áreas
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).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◦ 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.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 DEGESTIÓN DE ACTIVOS DE
GESTIÓN DE ACTIVOS DEGESTIÓN DE ACTIVOS DE
SERVICIOY CONFIGURACIÓNSERVICIOY CONFIGURACIÓN

Gestión de la ConfiguraciónGestión de la ConfiguraciónGestión de la ConfiguraciónGestió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
( fi i d b )(configuration management 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)DSL (Definitive Software Library)

Activos
Personas UbicacionesSLA
Información
Capacidad
Información
ReleasesDisponibilidad
CMDB
Documentación
Información
Licencias
IncidentesCambios
Información
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, datosclasificación de los CIs, cambios que tuvo cada CI, datos
incorrectos en la CMDB, etc )

Configuration Management SystemConfiguration Management SystemConfiguration Management SystemConfiguration Management System
Para administrar configuraciones grandes y complejas, la
ió i l d l ú i d lgestión requiere el uso de algún sistema de soporte, al
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 LibraryDefinitive Media LibraryDefinitive Media LibraryDefinitive Media Library
La Definitive Media Library es una biblioteca segura en la
cual las versiones definitivas de todos los CI son almacenadascual las versiones definitivas de todos los CI son almacenadas
y protegidas.
En la DML se almacenan todas las copias maestras que han
pasado por los controles de calidad.p 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 DMLen la DML.

Relación entre la DML y la CMDBRelación entre la DML y la CMDBRelación entre la DML y la CMDBRelación entre la DML y la CMDB
DML and CMDB
Información sobre CIsCis FísicosDML
CMDB
Registro de
versión
Cis
Electrónicos
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

ConfigurationConfiguration BaselineBaselineConfigurationConfiguration BaselineBaseline
Es la configuración de un servicio producto o
i f h id f l i dinfraestructura que ha sido formalmente revisada,
acordada
Servirá de base para futuras actividades y puede serServirá 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
relacionesrelaciones.

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

Roles delRoles del ProcesoProcesoRoles delRoles del ProcesoProceso
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 LIBERACIONESGESTIÓN DE LIBERACIONES
GESTIÓN DE LIBERACIONESGESTIÓN DE LIBERACIONES
Y DESPLIEGUEY DESPLIEGUE

Gestión de LiberacionesGestión de LiberacionesGestión de LiberacionesGestió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◦ Facilitar la introducción del software y hardware en un ambiente
de IT controlado

Asegurar planes de despliegue e implementación claros
y comprensiblesy comprensibles.
Definir paquetes de versiones que puedan ser
construidos, instalados, testeados y desarrolladosy
eficientemente, para que sea posible una
implementación exitosa.
Permitir introducir servicios nuevos o modificadosPermitir introducir servicios nuevos o 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
proceso.p

Unidad de implementaciónUnidad de implementaciónUnidad de implementaciónUnidad de implementación
Describe la porción de un servicio o de la
i f d TI l l dinfraestructura de TI que normalmente es lanzada en
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 La identificación del release debe incluir unarelease. La identificación del release debe incluir una
referencia a los CI que representa.
A1 A2 A3
ServicioA deTI
A1 A2 A3
A2.1 A2.2 A3.1
A2.1.1

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

Formas de implementaciónFormas de implementaciónFormas de implementaciónFormas 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 posición central y losp p y
usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo.
Automatizado vs. manual
E l d l ó d l◦ Es el mecanismo de implementación de las versiones.

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 ó e sta ac ó ( esp egue)
Información de Gestión (cantidad de despliegues,
cantidad de CI’s impactados en cada despliegue, etc.)

Roles de Administración de Cambios Órdenes de Trabajo para
Cambio Menor
Órdenes de Trabajo
para Cambio
Significativo o Mayor 5
Roles de Administración de Cambios Órdenes de Trabajo para
Cambio Menor
Órdenes de Trabajo
para Cambio
Significativo o Mayor 5
Administrador de Liberación
Empresarial
Orden de Trabajo para
Cambio Estándar
"Planeaciónde
Significativo o Mayor
"Planeaciónde
"Ciclo de
Planeación de
Políticas de
Liberación
mpletadas
"Planeaciónde
"Planeaciónde
8 2
5
Administración de Cambios
8.1
Empresarial
Orden de Trabajo para
Cambio Estándar
"Planeaciónde
Significativo o Mayor
"Planeaciónde
"Ciclo de
Planeación de
Políticas de
Liberación
mpletadas
"Planeaciónde
"Planeaciónde
8 2
5
Administración de Cambios
8.1
Sistema de Administración de
Servicios Plan de Reversión de
Liberación
mbioEstándarcompletadas
CorrecciónMenorautorizada"
ido"
CorrecciónSignificativaoMay
orrevertido"
Liberaciones"
Liberación
Políticas y Plan de Liberación
Anual actualizados
mbioMenorcompletadas
mbioSignificativooMayorcom
CorrecciónMenornoautoriza
eración"
8.2
Planear Liberación
Revisar y Actualizar Políticas
y Plan de Liberación Anual
P líti
Sistema de Administración de
Servicios Plan de Reversión de
Liberación
mbioEstándarcompletadas
CorrecciónMenorautorizada"
ido"
orrevertido"
Liberaciones"
Liberación
Políticas y Plan de Liberación
Anual actualizados
mbioMenorcompletadas
mbioSignificativooMayorcom
CorrecciónMenornoautoriza
eración"
8.2
Planear Liberación
Revisar y Actualizar Políticas
y Plan de Liberación Anual
P líti
Roles de Administración de
Problemas
"Prueba de
ÓrdenesdeTrabajoparaCam
"CambioMenorrevert
"PlandeCorrecciónMenor"
yorautorizada"
"PlandeCorrecciónMayor"
"CambioSignificativooMayo
"CambioEstándarrevertido"
da"
yornoautorizada"
Notas de Liberación
(posibles errores
conocidos)
"TiempoinsuficienteparaLibe
Políticas y
Plan de
Liberación
Anual
3
Administración de Problemas
Problemas
"Prueba de
"CambioMenorrevert
"PlandeCorrecciónMenor"
yorautorizada"
"PlandeCorrecciónMayor"
"CambioSignificativooMayo
"CambioEstándarrevertido"
da"
yornoautorizada"
Notas de Liberación
(posibles errores
conocidos)
"TiempoinsuficienteparaLibe
Políticas y
Plan de
Liberación
Anual
3
Administración de Problemas
Sistema de
Monitoreo
disponible
Aceptación
exitosa"
"Liberación implementada"
"Liberación f allida y
Corrección no autorizada"
Notificación sobre
servicio provisto8.3
Preparar Liberación
8.4
Realizar Pre-Producción y
Validación
8.5
Activar Liberación
FINFIN
Sistema de
Monitoreo
disponible
Aceptación
exitosa"
"Liberación implementada"
"Liberación f allida y
Corrección no autorizada"
Notificación sobre
servicio provisto8.3
Preparar Liberación
8.4
Realizar Pre-Producción y
Validación
8.5
Activar Liberación
FINFIN
Incidentes y Requerimientos de
Servicio
2
Administración de
Incidentes y
Requerimientos de Servicio
Incidentes y Requerimientos de
Servicio
2
Administración de
Incidentes y
Requerimientos de Servicio

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

Interacción entre los principalesInteracción entre los principales
d T ó O ód T ó O óprocesos de Transición y Operaciónprocesos de Transición y Operación
Incidente
Service
Desk
Incidente /
Requerimiento
De Servicio
Gestión de
Incidentes
escalado
Incidente
resuelto
Problema
CLIENTES
Marketing
Ventas Desk
Gestión de
l C fi
Incidente /
Requerimiento
De servicio
resuelto
Gestión de
Problemas
Ventas
Finanzas
Clientes externos
Etc.
SLA
Base de
conocimiento
la Configu‐
raciónCis RFC
RFC
Catálogo
de
Servicios
Gestión de
Release
Gestión de
Cambios
RFC
Release Cambios

Escenario GenéricoEscenario GenéricoEscenario GenéricoEscenario Genérico

Escenario GenéricoEscenario Genérico
¿Tiene
SLA?Escenario GenéricoEscenario Genérico
Incidente 1
Cliente
Incident
Manager
¿Qué hacer?
Incidente 2
Manager
Restauración de servicio (1), SL Gold,Tiempo: 15m.
Se evitan futuros
incidentes
l i d Id ifi l
Restauración de servicio (2), SL “Silver”,Tiempo: 1hr.
¿Tiene
Incidentes
Registrados
relacionados con
la Causa Raíz
Identifica la
Causa Raíz
SLA?
¿Cuál es el mejor
Problem
Manager
Release/Operations
Manager
Change
Manager
¿Cuál es el mejor
momento?
Request for
Change
Service
Order

Escenario GenéricoEscenario GenéricoEscenario GenéricoEscenario Genérico
Incidente 1
Cliente
Incident
Incidente 2
ManagerRestauración de servicio (1), SL Gold,Tiempo: 15m.
Se evitan futuros
incidentes
l i d
Restauración de servicio (2), SL “Silver”,Tiempo: 1hr.
CMDB
Incidentes
Registrados
relacionados con
la Causa Raíz
CMDB
Configuration Mgmt. DB
Problem
Manager
Release/Operations
Manager
Change
Manager
Request for
Change
Service
Order

GESTIÓN DE NIVELES DEGESTIÓN DE NIVELES DE
GESTIÓN DE NIVELES DEGESTIÓN DE NIVELES DE
SERVICIOSERVICIO

Gestión de Niveles de ServicioGestión de Niveles de ServicioGestión de Niveles de ServicioGestió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◦ Implementar SLA (definir catálogo de servicios, acordar SLAs,
definir frecuencia de revisiones y mediciones)
◦ Administrar el proceso (realizar y evaluar mediciones, revalidar
l l l SLA )con el cliente, actualizar SLAs)

SLRs OLAs Áreas
Internas
Catálogo
de
S i iCliente Servicios
de TI
Cliente
SLAs UCs
Áreas
ExternasExternas

GESTIÓN DE CAPACIDADGESTIÓN DE CAPACIDAD
GESTIÓN DE CAPACIDADGESTIÓN DE CAPACIDAD

Gestión de la CapacidadGestión de la CapacidadGestión de la CapacidadGestió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 CapacidadGestión de la CapacidadGestión de la CapacidadGestió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ándolosnegocio 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 DEGESTIÓN DE
GESTIÓN DEGESTIÓN DE
DISPONIBILIDADDISPONIBILIDAD

Gestión de la DisponibilidadGestión de la DisponibilidadGestión de la DisponibilidadGestió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 DisponibilidadGestión de la DisponibilidadGestión de la DisponibilidadGestión de la Disponibilidad
Actividades:
◦ Determinar requerimientos (OLO)
◦ Planificar
◦ Monitorear
◦ Información de Gestión

GESTIÓN DE LAGESTIÓN DE LA
GESTIÓN DE LAGESTIÓN DE LA
CONTINUIDAD DELCONTINUIDAD DEL
SERVICIOSERVICIO

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

Gestión de Continuidad del ServicioGestión de Continuidad del ServicioGestión de Continuidad del ServicioGestió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◦ 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 ó (d f ó d d◦ Implementación (definición de procedimientos, contratos con
proveedores, instalaciones, capacitación, pruebas)
◦ Administración (pruebas periódicas)(p p )

GESTIÓN FINANCIERAGESTIÓN FINANCIERA
GESTIÓN FINANCIERAGESTIÓN FINANCIERA

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

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

Hardware Software Transferencias
Servicios Externos GenteOficinas

FINFIN
FINFIN

Administración y Control de Proyectos Informáticos ITIL v2.5

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Administración y Control de Proyectos Informáticos ITIL v2.5

Más de Pedro Espinosa

Administración y Control de Proyectos Informáticos ITIL v2.5