Gestion de Servicios de TI V1.1 PDF

Gestión de Servicios de TI
75.46 - Administración y Control de Proyectos II

Agenda
El enfoque histórico
La nueva visión
ITIL: un conjunto de buenas prácticas
Generación de valor
La operación diaria
Complejidad de los servicios
Mantenimiento del valor en el tiempo
Beneficios de ITIL
Cómo se implementa ITIL
Factores críticos de éxito
El desafío de la integración
EL ENFOQUE HISTÓRICO
La situación más común…
Procesos no Servicios no Foco en la

formalizados definidos tecnología
Falta de
Organización Limitada relación
comunicación
reactiva con el negocio
entre áreas de TI
Falta de visión
Dificultad para
de Gestión de
mostrar valor
Servicios
Tendemos a organizarnos de esta forma…
Creación de Silos
Operacionales Gerencia de TI Resultados
Soporte y
Infraestructura Microinformática Comunicaciones Operaciones Seguridad
Desarrollo
Computadoras
Procesamiento Seguridad
Aplicación A Unix portátiles y de LAN
Batch Informática
escritorio
Objetivos
Objetivos
Objetivos
Objetivos
Objetivos
Objetivos
Monitoreo y Seguridad
Aplicación B Windows Impresoras WAN
Control Aplicativa
Periféricos Mesa de
Aplicación C Mainframe
especiales Ayuda
Gestión de
Accesos
Visión tradicional del Servicio
Visión tradicional del Servicio
Negocio 1) Usuarios utilizan

Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3 sistemas de
información.
Usuarios Usuarios Usuarios
2) Sistemas de información
Sistemas implementan la funcionalidad
requerida por el negocio.
3) Tecnología Informática
es vista como el elemento Sistema de
2 3
principal a proveer a los Información 1
usuarios a través de los
sistemas de información
Tecnología Informática
Sistema
Hardware Operativo Base de Datos Datos Aplicaciones Redes …
4) TI organizada en
“silos” enfocados en Organización
proveer tecnología y
Administración
Infraestructura
Operaciones
Desarrollo
niveles de servicio que
Soporte y
Acuerdos Acuerdos Acuerdos Acuerdos
de BD
no necesariamente de Nivel de de Nivel de de Nivel de de Nivel de

Servicio Servicio Servicio Servicio
representan valor para
el negocio. 5) Procesos (por lo
… general
informales)
orientados hacia
Procesos los objetivos
Administración
Soporte y
individuales de
cada área (“silo”).
…
Operaciones de Bases de Infraestructura
Desarrollo
Datos
¿Cómo nos ven los usuarios?
Pero los clientes nos ven así…
• Funcionalidad
+
• Disponibilidad
• Performance
• Continuidad
• Seguridad
• Soporte
• Confiabilidad
LA NUEVA VISIÓN
Se necesita un cambio de foco…
Gerencia de TI
Oficina de Oficina de
Procesos Proyectos
Estrategia de
Servicios
Arquitectura de Centro
Operaciones
Servicios de Soporte
Atención de
Infraestructura Infraestructura Infraestructura de Gestión de
Seguridad Incidentes y
Aplicativa Tecnológica Comunicaciones Ambientes
Pedidos
Arquitectura Hardware Seguridad Procesamiento Gestión de

LAN
Aplicativa Centralizado Informática Batch Accesos
Software Hardware Seguridad Monitoreo y

WAN
Factory Distribuido Aplicativa Control
Administración de
Software de Base
Recursos
Con foco en el servicio a través de los procesos
La nueva visión de TI como Proveedor de Servicios
Negocio 1) Procesos de
Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3
negocio
requieren apoyo
informático.
3 3 3
Proceso 2 Proceso 2 Proceso 2
de Negocio 1 de Negocio 1 de Negocio 1
3) Infraestructura informática Servicios de Calidad 2) Servicios de TI apoyan

y de telecomunicaciones Funcionalidad
Servicios a los procesos de
configura a los servicios +
Disponibilidad
negocio.
de TI.
Performance
Seguridad
3
Soporte Servicio 1 2
Acuerdos de Nivel
de Servicio
Infraestructura
Sistema
5) Procesos para Hardware Operativo Base de Datos Redes Aplicaciones Datos …
gestionar los servicios
de TI aseguran la
operación de los
equipos de soporte Equipos de
para proveer al Arquitectura de 4) Equipos de soporte operan y
Soporte Servicios,
mantienen la infraestructura de los
negocio servicios de Acuerdos de Nivel Operaciones, Centro
calidad. de Operacional de Soporte, etc. servicios de TI.
Procesos
Aseguramient
Desarrollo de Configuración Nivel de Incidentes y Capacidad y
…
o y Control de Proyectos Continuidad
Software y Cambios Servicios Problemas Disponibilidad
Calidad
Cambio en la visión de TI
Tradicional Gestión de Servicios

Foco en Tecnología Foco en el Negocio
Administrar Infraestructura Proveer Servicios
Usuarios Clientes
Modalidad “Bombero” Prevención y Control
Siempre detrás de las necesidades Generando nuevas posibilidades
Islas Integrado
Procesos informales Estandarización y mejores prácticas

Una problemática compleja
La punta del Iceberg
ADMINISTRAR Y PROVEER
TECNOLOGÍA
INCIDENTES EN PRODUCCIÓN
PEDIDOS DE USUARIOS
Gestión de los Servicios de IT
OPERAR LOS SERVICIOS

RESOLVER LOS PROBLEMAS
CONTROLAR LA CONFIGURACIÓN
ATENDER PEDIDOS DE CAMBIOS
PLANIFICAR Y EJECUTAR
PROYECTOS
DISEÑAR Y DESARROLLAR
CAMBIOS
GESTIONAR LA CALIDAD
INTRODUCIR CAMBIOS AL
AMBIENTE PRODUCTIVO
…
Administración de Servicios de TI
ITIL: UN CONJUNTO DE BUENAS

PRÁCTICAS
¿Qué es ITIL?
 Information Technology Infrastructure Library

 Biblioteca sobre:
 Provisión de Servicios basados en IT
 Administración de la Infraestructura de IT
 Generados por la OGC (UK Office of Government Commerce), recolectando la
experiencia de los referentes de mercado.
 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
responsabilidades y autoridades, herramientas)
¿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.
 Lo único necesario para brindar un mejor servicio.
 Independiente de la cultura organizacional.
 La solución a todos nuestros males.

ITIL V3
Cadena de Valor de TI y sus Procesos
• Gestión de la relación • Gestión de pasajes a producción

con el cliente • Gestión de proyectos • Gestión de cambios a producción
• Cumplimiento de los • Gestión de requerimientos • Gestión de la configuración de
requerimientos de • Diseño y construcción de la producción
demanda solución • Cumplimiento de pedidos de servicio
Actividades Primarias
• Aseguramiento de calidad de • Mantenimiento de servicios

la solución • Resolución de incidentes y problemas
Gestión de la
relación con el
Desarrollo de Soporte del
cliente
soluciones servicio
Gestión de la
demanda
VALOR
• Gestión de las instalaciones
• Gestión de operaciones
Instalaciones y Operaciones
• Gestión de los riesgos, la
seguridad y la conformidad
Actividades de Apoyo
Riesgos, Seguridad y Conformidad
• Gestión del aprovisionamiento,

• Estrategia de TI el personal y los proveedores
• Gestión de la cartera de Aprovisionamiento, Personal y Proveedores
servicios
• Gestión de la capacidad • Gestión de las finanzas de TI
• Gestión de la disponibilidad Finanzas de TI
• Gestión de nivel de servicios
• Gestión de procesos
• Gestión de datos Cartera de Servicios, Arquitectura y Diseño de Servicios
Cadena de Valor de TI e ITIL como Modelo de Referencia
• CMMI – Software Engineering

• ITIL Service Strategy
• Unified Process
• ITIL Service Design
• Agile (SCRUM) • ITIL Service Transition
• PMBOK • ITIL Service Operation

• SWEBOK • ITIL Continual Service Improvement
Gestión de la
relación con el
cliente
soluciones servicio
Gestión de la
demanda
• ITIL Service Operations
VALOR
• COBIT
• ITIL V2 ICT Infrastructure Management
• ITIL Service Transition Instalaciones y Operaciones
• ITIL Service Operations
• ISO 27000

• CMMI – Supplier Sourcing
Aprovisionamiento, Personal y Proveedores

• TOGAF
• Zachman Framework Finanzas de TI
• CMMI -Process aspects
Cartera de Servicios, Arquitectura y Diseño de Servicios

GENERACIÓN DE VALOR
¿Qué es un servicio de TI?
Medio para entregar valor a los usuarios,

facilitando la obtención de resultados que
desean obtener sin la necesidad de asumir los
costos y riesgos implicados.
Utilidad o aptitud Garantía o aptitud

para el propósito para el uso
(requerimientos (requerimientos no
funcionales) funcionales
Generación de valor: “qué” + “cómo”
Utilidad Garantía
Funcionalidad Capacidad y
Confiabilidad Soporte Continuidad Seguridad
del servicio Disponibilidad
¿Cómo lograr el valor necesario?
Modelado Operación del

Diseño del Servicio Construcción del Servicio
de Negocio Servicio
Demanda
Mercado (necesi- Gestión de
Gestión de Monitoreo
(usuarios dades y Montaje de Incidentes,
Nivel de Servicio Diseño y Arquitectura del Servicio Construcción de software Pasajes a y Gestión
del patrones Infraestructura Problemas
Producción de Eventos
servicio) de uso del y Pedidos
servicio)
Capaci-dad
Especifi- SLA Análisis y Hardware y
y Continui- Comuni-
cación del OLA Seguir-dad Diseño Software Desarrollo Pruebas
Disponibi- dad caciones
Servicio UC Aplicativo de Base
lidad
Gestión de Cambios
Gestión de
Gestión de Proyectos
Servicios
Cartera
de Valor
Modelado del Negocio y Diseño del Servicio
Gestión de la demanda Gestión de la disponibilidad

• Identificar los patrones de actividad del
negocio (PBA). • Asegurar que el nivel de disponibilidad de
• Identificar los perfiles de usuario (UP) y su los servicios de TI alcanza o excede las
relación con los PBA. necesidades de negocio (actuales y futuras).
• Definir los servicios básicos y los servicios de
apoyo y sus formas de empaquetamiento.
• Desarrollar los paquetes de nivel de servicio Gestión de la continuidad
(cubrir patrones de demanda específicos con
utilidad y garantía determinada).
• Apoyar al proceso de continuidad de negocios
asegurando la continuidad operativa de los
Gestión financiera servicios de TI.
• Proporcionar cuantificación financiera del valor
de los servicios de TI y el costo de su
Gestión de nivel de servicio
infraestructura.
Gestión de la capacidad • Negociar, acordar y documentar niveles de

servicio con representantes del negocio.
• Asegurar un nivel de capacidad justificado para • Monitorear e informar la capacidad de TI de
todos los aspectos de TI, de acuerdo a las entregar los servicios con los niveles
necesidades de negocio actuales y futuras. acordados.
Gestión del Nivel de Servicio
Pilares de
los SLA
SLR OLA
Necesidades Catálogo de Acuerdos de Áreas internas de TI

nivel operacional
Servicios de TI
SLA UC
Áreas de Negocio
Compromiso Contratos de
soporte
Respuesta a las
necesidades del negocio
Especificación Proveedores externos de TI
Utilidad
de Servicio de TI +
Garantía
LA OPERACIÓN DIARIA
¿Cuál es la situación?
Eventos que Errores ocultos

requieren en la
atención infraestructura
Necesidad de
adaptar los
Servicios que
servicios al
se rompen
contexto
cambiante
Prepararse Necesidad de
Pedidos de proteger el
usuarios para el día ambiente
a día productivo
Operación compleja requiere una gestión activa
Gestión de accesos
Gestión de problemas
• Otorgar derechos de uso de los
servicios de TI a los usuarios. • Encontrar los errores en la
• Gestionar la confidencialidad, infraestructura que causan incidentes.
disponibilidad e integridad de los datos. • Determinar la mejor solución posible
para cada caso.
Gestión de eventos
Gestión de cambios
• Detectar y clasificar los eventos
generados por el monitoreo de la • Proporcionar un mecanismo controlado
infraestructura y los servicios. para procesar los pedidos de cambio a
• Determinar las acciones de control los servicios productivos.
adecuadas.
Gestión de pasaje a producción
Gestión de incidentes y pedidos
de usuario
• Procurar que los ambientes productivos
• Recuperar la operación normal tan se modifiquen lo menos posible, de
pronto como sea posible. manera totalmente controlada y con
• Proveer un canal para que los usuarios todas las consideraciones necesarias.
puedan realizar pedidos estándar.
Gestión de Servicios Informáticos
GESTIÓN DE INCIDENTES
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.
 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).
Objetivos
 Restaurar la operación normal del servicio afectado lo más rápido

posible, minimizando el impacto en el negocio y asegurando que se
mantengan los niveles acordados de calidad y disponibilidad.
 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.

 Los Pedidos de Servicio (Service Request) serán derivados al proceso
específico correspondiente.
Modelos de incidentes
 Son aquellos incidentes que pueden considerarse repetitivos y para los

cuales se crea un modelo predefinido de incidente. Se debe tener en
cuenta:
 Los pasos a seguir en el incidente.
 El orden de estos pasos.
 Responsabilidades.
 Procedimientos de escalamiento.
 Líneas de tiempo.
Incidentes graves
 Debe existir un proceso que se encargue del manejo de incidentes

graves.
 La definición de qué es un Incidentes graves debe ser realizada a nivel
corporativo, teniendo en cuenta los 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
 Cierre
Identificación
 Puede ingresar en forma proactiva (monitoreo) o reactiva (avisos del

usuario).
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
 Estado del incidente
Categorización
 Se debe definir correctamente la granularidad del árbol de

categorización.
 Pasos para lograr el diseño de las categorías:
1. Sesión de brainstorming entre los involucrados.
2. Definición del nivel inicial.
3. Utilización de las categorías iniciales por un período corto de
tiempo.
4. Realizar un análisis de lo registrado.
5. Implementar las revisiones necesarias.
6. Repetir desde el punto 3.
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.
 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).
Priorización
Imapcto
Alto Medio Bajo
Alta 1 2 3
Urgencia Media 2 3 4
Baja 3 4 5
Código de Tiempo de resolución

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.
 En esta actividad se intentará resolver el incidente en un primer nivel de
atención.
 Escalamiento:
 Funcional
 Jerárquico
 Investigación y diagnóstico:
 Entender el orden cronológico de eventos que causaron el incidente.
 Búsquedas a la KEDB.
 Confirmar el impacto del incidente.
Resolución y recuperación
 Involucra la resolución del incidente para lo cual se pueden usar los

siguientes métodos:
 Resolución conjunta con el usuario.
 Resolución remota.
 Resolución por soporte de campo.
 Resolución por proveedor externo.
Cierre
 Esta actividad será realizada siempre por el Service Desk.

 El Service Desk deberá validar junto con el usuario el cierre del
incidente. También deberá verificar lo siguiente:
 Categorización de cierre.
 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.
 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).
CENTRO DE SERVICIOS AL
USUARIO
Objetivo
 Proveer un punto único de contacto (SPOC) para los clientes

 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.
 Verificar la CMDB.
Actividades
 Clasificar, asignar, realizar diagnóstico inicial, priorizar y escalar 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
Estructuras organizativas
 Local
 Centralizado
 Virtual
Local
 Diseñado para soportar las necesidades locales del

negocio.
Usuario Local UsuarioyLocal Usuario Local Usuario Local
 El soporte se encuentra brinda usualmente en la misma
localidad que está siendo soportada.
 Es práctico para pequeñas organizaciones.
 Service Desk dispersas
Es impráctico para organizaciones
Local
geográficamente.
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 Service Desk central.
 Puede requerirse
Sede Cliente 1 soporte en
Sede forma
Cliente 2 presencial,
Sede Cliente 3pero esto
debe ser manejado y administrado desde el Service Desk.
 Ventajas para las grandes organizaciones:
Service Desk
 Reduce los costos operacionales.
 Proporciona una vista gerencial central consolidada.
Segunda línea
 Mejora el uso de los recursos.
Gestión de
Gestión Técnica Gestión de Soporte de Gestión de
Operaciones de TI
Aplicaciones terceros Requerimientos
Service Desk virtual
 La ubicación de los analistas del SD es transparente al

usuario.
 Deben existir procesos y procedimientos
San Francisco
Service Desk
comunes y un solo
registro de incidentes.
Paris Rio de Janeiro
Service Desk Service Desk
 Lenguaje común acordado para la entrada de datos.
Virtual
Service Desk
 Se mantiene el punto único de contacto con el cliente.
Sydney
 PuedeBeijing
seguir requiriéndose presencia on-site para
Service Desk algunos
Service Desk
puntos.
Sistema de Gestión
de los Servicios de
Conocimiento
London
Service Desk
Grupos de Service Desk especializados
 En algunos casos es recomendable crear grupos de especialistas dentro

de la función de Service Desk.
 Esto permitirá derivar los incidentes según el tipo de especialista que
pueda 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.
 Utilización de salvapantallas con datos de contacto del Service
Desk.
 Incorporar merchandising con el número de contacto.
GESTIÓN DE PROBLEMAS
Objetivos
 Prevenir la ocurrencia de problemas e incidentes asociados.

 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 los Incidentes (matriz de prioridades).
 Se debe tener en cuenta lo siguiente:
 Frecuencia e impacto de incidentes relacionados.
 Definición sobre qué constituye un 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 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 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 pueden ser resueltos rápidamente.
 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 de la KEDB en un único responsable.
Base de datos de errores conocidos
 Permite el almacenamiento del conocimiento obtenido a travé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.
 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.
 Los datos incluidos en la KEDB debe ser fácilmente 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 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
 Información de Gestión (cantidad de Cambios que no se aceptaron,
cambios OK, etc.)
Actividades
Crear RFC
Propuesta de
Cambios
(opcional)
Registrar el RFC
Actualizar el cambio y la información de la congiguración en el CMS

Iniciador
Solicitado
Revisar el RFC
Gestión del Cambio

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
Gestión del Cambio

Planificado Ordenes de Trabajo
Coordinar la implementación
de Cambio*
Gestión del Cambio

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).
 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.
Registro de un Pedido de Cambio
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 y Urgencia
Implementación
Implementación
Recomendación del CAB
Programada
Implementador 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

filtrar los que considera que son:
 Imprácticos.
 Repetidos en otros RFC recientes que fueron aprobados,
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 de las siete „R‟ 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?
 ¿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?
AutorizarGestión
el RFCdel Cambio
 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.
 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.
Revisar y Cerrar el RFC
 Es necesario realizar una revisión post-implementación para confirmar

 Que el cambio cumplió con sus objetivos.
 Que el iniciador y los demás interesados están conformes con el
resultado.
 Que no se han producido efectos colaterales.
 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 de
conocimiento técnico son necesarias.
 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.
 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
 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 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.
 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, 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.
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)
 Información de Gestión (cantidad de despliegues, cantidad de CI‟s
impactados en cada despliegue, etc.)
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 posición central y los

usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo.
 Automatizado vs. manual
 Es el mecanismo de implementación de las versiones.

Roles
 Administrador de Pasajes a Producción

 Administrador de Construcción de Paquetes
 Personal técnico involucrado
COMPLEJIDAD DE LOS
SERVICIOS
Procesos de
Gran cantidad
negocio
de servicios de
dependen de
TI
los servicios de
interconectados
TI
Procesos de
Tecnología de
negocio en
los servicios de
constante
TI compleja
adaptación
Negocio en Necesidad de Arquitectura

contexto controlar la aplicativa de
dinámico infraestructura múltiples capas
Servicios complejos requieren control
Gestión de la configuración
Crea y mantiene actualizada una base de datos (CMDB)

cuyo contenido representa un modelo de la infraestructura
de los servicios en producción.
Permite identificar, registrar y ofrecer información de todos

los componentes de IT de los ambientes productivos.
Gestiona Ítems de Configuración (elementos que componen

la infraestructura productiva de los servicios de TI).
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 database)
 Los CI tienen:
 Alcance (qué aplicativos, sectores, etc interesan?)
 Nivel (registro “1 PC” o registro “1 mouse” + 1 teclado”, etc)
 Atributos
 Relaciones
 Actividades:
 Planificar
 Identificar
 Controlar
 Proveer información de gestión
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 pasado
por los controles de calidad.
 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.
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 ha sido

formalmente revisada, 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.
Configuration Snapshot
 Es el estado actual de un CI o de un entorno, por ejemplo obtenido a

través de una herramienta de descubrimiento.
 Esta foto es guardada en el CMS y queda como un registro de estado
histórico.
Roles del Proceso
 Administrador de Configuraciones
 Coordinador de Configuraciones
 Dueño de CI
 Administrador de la Librería de Medios
 Administrador de Herramientas / CSM
 Comité de Control de Configuración
MANTENIMIENTO DEL VALOR EN

EL TIEMPO
Servicios que
Avances
sufren
tecnológicos
sucesivas
constantes
adaptaciones
Estrategia de
Cambios
negocio que
organizativos
evoluciona
Pérdida Mejor
Contexto comprensión
cambiante progresiva de los
de valor procesos
Implementar la mejora continua para sostener valor
Caso de Negocio
• Articular razones
para justificar la
mejora.
• Proveer datos de
costo y beneficios.
• Analizar el ROI.
Los 7 pasos de la
mejora de proceso
1. Identificar qué debo

medir.
2. Determinar qué
puedo medir.
3. Reunir los datos.
4. Procesar los datos.
5. Analizar la
información.
6. Presentar y usar la
información.
7. Implementar
acciones
correctivas.
BENEFICIOS DE ITIL
¿Por qué implementar ITIL?
 Procesos negocio dependen de servicios de TI.

 La TI es cada vez más compleja, igual su gestión.
 Aumento de marcos regulatorios (SOX, BCRA 4609).
 Cumplimiento con las auditorías (COBIT).
 Exigencias del mercado (Certificación World-Class).
¿Qué puedo esperar de ITIL?
 Optimizar la utilización de recursos.

 Ajustar la disponibilidad y la capacidad.
 Adecuar la escalabilidad.
 Aumentar la confiabilidad de los servicios de TI.
 Mejorar la experiencia del usuario.
 Reducir el riesgo de la operación.
ITIL como impulsor de la Gestión de Servicios de TI
 Promueve la visión de TI como proveedor de servicios.

 Fomenta el foco en el cliente.
 Alinea la organización de TI con el negocio.
 Posiciona a TI como parte importante de la cadena de valor.
 Compromete a dar lo que realmente se puede dar.
 Mejora la calidad de los servicios.
Servicios Procesos de Valor al

Productos
de IT Negocio Cliente
ITIL como impulsor de la Gestión por Procesos
 Estandariza los procesos en base a las mejores prácticas.

 Define sus interrelaciones.
 Define roles y responsabilidades.
 Promueve el uso de conceptos comunes (comunicación).
 Sirve de base para la certificación de personas y empresas.
Servicios Procesos de Valor al

Productos
de IT Negocio Cliente
¿CÓMO SE IMPLEMENTA ITIL?

¿Qué implica realizar un proyecto ITIL?
 Fase inicial (análisis de brecha)

 Conocer la situación actual (Personas, Procesos,
Tecnología).
 Considerar el tamaño de la organización.
 Establecer las motivaciones.
 Clarificar expectativas.
 Diseño
 Diseñar los procesos prioritarios (enfoque
modular).
 Implementación
 Implementar (apoyo de herramientas).
 Institucionalizar.
 Mejora continua
 Manejo del Cambio
¿Más madurez es mejor?
Estado Significado Resultado

0 - Incompleto El proceso no se ejecuta adecuadamente
Riesgo
1 – Ejecutado  Acuerdo general en que se hace
2 - Administrado  Planificadoy controlado

 Productos estándar
3 - Establecido  Proceso definido para la ejecución y administración
Productividad y Calidad
 Cambios al proceso aprobados y documentados
 Existen definición formal de los procesos
4 - Predecible  Ejecución consistente en la práctica

 Performance medida y analizada
 Conocimiento cualitativo de la calidad
 Predecibilidad
5 - Optimizado  Performance optimizada para cumplir los objetivos de

negocio
 Efectividad del proceso medida
 Procesos no efectivos cambiados / eliminados

Temas a tener en cuenta en cada fase de una implementación
Antes Durante Después

(Planificación) (Diseño (Seguimiento y
e implementación) Mejora Continua)
Conocer cultura
Comunicar
Establecer visión Comunicar
Capacitar
Personas Cambio cultural Formar
Establecer grupos
Participación de las Marketing
de interés
distintas áreas
Gap Analysis
Seleccionar Diseñar procesos Medir
Procesos procesos Documentar Optimizar
Priorizar Implementarlos Integrar
implementación
Automatizar
Relevar tecnología
Procesos Administrar
Seleccionar y
Herramientas Migrar datos Actualizar
adquirir nueva
Realizar pruebas Integrar
tecnología
Integrar
FACTORES CRÍTICOS DE ÉXITO

Principales aspectos a considerar
 Definir formalmente un proyecto para la

implementación.
 Conseguir y mantener el apoyo de los niveles
directivos (al proyecto y a los administradores de los
procesos).
 Trabajar en equipo: los procesos de Administración
deben ser comprendidos y utilizados por todos y para
todos.
 Definir los servicios que presta TI al resto de la
organización.
 Implementar las mejoras gradualmente (maduración y
quick-wins), utilizar los procesos.
 Dedicar el tiempo necesario para aportar en las
mejoras, capacitación, utilización de los procesos.
EL DESAFÍO DE LA INTEGRACIÓN
Cadena de Valor de TI y sus Procesos
Gestión de la
relación con el
cliente
soluciones servicio
Gestión de la
demanda
VALOR
Instalaciones y Operaciones
Aprovisionamiento, Personal y Proveedores
Finanzas de TI
Cartera de Servicios, Arquitectura y Diseño de Servicios

Visión integral de los procesos de gestión de servicios de TI
excelza.blogspot.com
FIN
MUCHAS GRACIAS

Gestion de Servicios de TI V1.1 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gestion de Servicios de TI V1.1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Gestión de Servicios de TI

75.46 - Administración y Control de Proyectos II

ITIL: un conjunto de buenas prácticas

Complejidad de los servicios

Mantenimiento del valor en el tiempo

Cómo se implementa ITIL

Factores críticos de éxito

Procesos no Servicios no Foco en la

Negocio 1) Usuarios utilizan

Usuarios Usuarios Usuarios

no necesariamente de Nivel de de Nivel de de Nivel de de Nivel de

Arquitectura Hardware Seguridad Procesamiento Gestión de

Software Hardware Seguridad Monitoreo y

3) Infraestructura informática Servicios de Calidad 2) Servicios de TI apoyan

calidad. de Operacional de Soporte, etc. servicios de TI.

Tradicional Gestión de Servicios

Administrar Infraestructura Proveer Servicios

Modalidad “Bombero” Prevención y Control

Siempre detrás de las necesidades Generando nuevas posibilidades

Procesos informales Estandarización y mejores prácticas

La punta del Iceberg

OPERAR LOS SERVICIOS

ITIL: UN CONJUNTO DE BUENAS

 Information Technology Infrastructure Library

 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.

 Lo único necesario para brindar un mejor servicio.

 Independiente de la cultura organizacional.

 La solución a todos nuestros males.

• Gestión de la relación • Gestión de pasajes a producción

• Aseguramiento de calidad de • Mantenimiento de servicios

Riesgos, Seguridad y Conformidad

• Gestión del aprovisionamiento,

• CMMI – Software Engineering

• PMBOK • ITIL Service Operation

• ITIL Service Operations

Riesgos, Seguridad y Conformidad

Aprovisionamiento, Personal y Proveedores

Cartera de Servicios, Arquitectura y Diseño de Servicios

Medio para entregar valor a los usuarios,

Utilidad o aptitud Garantía o aptitud

Modelado Operación del

Gestión de la demanda Gestión de la disponibilidad

Gestión de la capacidad • Negociar, acordar y documentar niveles de

Necesidades Catálogo de Acuerdos de Áreas internas de TI

Eventos que Errores ocultos

 Se refiere tanto a la interrupción no planificada de un servicio de TI

 Restaurar la operación normal del servicio afectado lo más rápido

 Abarca cualquier evento que impacte, o pueda impactar, a un servicio.

 Son aquellos incidentes que pueden considerarse repetitivos y para los

 Debe existir un proceso que se encargue del manejo de incidentes

 Puede ingresar en forma proactiva (monitoreo) o reactiva (avisos del

 Todos los incidentes deben ser registrados.

 Se debe definir correctamente la granularidad del árbol de

 Normalmente la prioridad de un incidente se define en función de:

Código de Tiempo de resolución

 Se utiliza para esto los scripts de diagnóstico y la base de datos de

 Involucra la resolución del incidente para lo cual se pueden usar los

 Esta actividad será realizada siempre por el Service Desk.

 Proveer un punto único de contacto (SPOC) para los clientes

 Restablecer la operación del servicio lo más rápido posible.