Embed Size (px)
Citation preview
Gestión de Servicios de TI
75.46 - Administración y Control de Proyectos II
INTRODUCCIÓN
Gestión de Servicios de TI
Situación
Procesos de negocio complejos y cambiantes, tiempos acelerados y
un mercado global imponen requerimientos exigentes.
El negocio depende de la tecnología, que se ha vuelto muy poderosa, pero al mismo tiempo ha aumentado su complejidad de
manera considerable.
No alcanza con gestionar adecuadamente la tecnología, es
necesario adoptar enfoque integral, que permita controlar
todos aspectos de la problemática, aprovechando todo
lo que nuestra industria ha aprendido y madurado.
Necesidad de una nueva perspectiva, con foco en la
gestión desde un punto de vista integrador, consistente y
concentrado en responder a las exigencias de los tiempos que
nos toca vivir.
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
Gestión de Servicios de TI
La situación más común…
Procesos no formalizados
Servicios no definidos
Foco en la tecnología
Falta de comunicación
entre áreas de TI
Limitada relación con el negocio
Organización reactiva
Falta de visión de Gestión de
Servicios
Dificultad para mostrar valor
Tendemos a organizarnos de esta forma…
Gerencia de TI
Soporte y Desarrollo
Aplicación A
Aplicación B
Aplicación C
Infraestructura
Unix
Windows
Mainframe
Microinformática
Computadoras portátiles y de
escritorio
Impresoras
Periféricos especiales
Comunicaciones
LAN
WAN
Operaciones
Procesamiento Batch
Monitoreo y Control
Mesa de Ayuda
Gestión de Accesos
Seguridad
Seguridad Informática
Seguridad Aplicativa
Resultados
Ob
jetiv
os
Ob
jetiv
os
Ob
jetiv
os
Ob
jetiv
os
Ob
jetiv
os
Ob
jetiv
os
Creación de Silos
Operacionales
Visión tradicional del Servicio
Visión tradicional del Servicio
…
Usuarios Usuarios Usuarios
Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3
Negocio
321
Sistema de
Información
…Hardware
Sistema
Operativo Base de Datos Aplicaciones
Tecnología Informática
Datos
Op
era
cio
ne
s
Ad
min
istr
ació
n
de
BD
Redes
So
po
rte
y
Desa
rro
llo
Infr
ae
str
uctu
ra
1) Usuarios utilizan
sistemas de
información.
2) Sistemas de información
implementan la funcionalidad
requerida por el negocio.
Sistemas
3) Tecnología Informática
es vista como el elemento
principal a proveer a los
usuarios a través de los
sistemas de información
4) TI organizada en
“silos” enfocados en
proveer tecnología y
niveles de servicio que
no necesariamente
representan valor para
el negocio.
…
Procesos
Operaciones
Administración
de Bases de
Datos
Soporte y
DesarrolloInfraestructura
Organización
5) Procesos (por lo
general
informales)
orientados hacia
los objetivos
individuales de
cada área (“silo”).
Acuerdos
de Nivel de
Servicio
Acuerdos
de Nivel de
Servicio
Acuerdos
de Nivel de
Servicio
Acuerdos
de Nivel de
Servicio
Pero los clientes nos ven así…
Pero los clientes nos ven así…
• Funcionalidad
+
• Disponibilidad
• Performance
• Continuidad
• Seguridad
• Soporte
• Confiabilidad
LA NUEVA VISIÓN
Gestión de Servicios de TI
Gerencia de TI
Arquitectura de Servicios
Infraestructura Aplicativa
Arquitectura Aplicativa
SoftwareFactory
Infraestructura Tecnológica
Hardware Centralizado
Hardware Distribuido
Software de Base
Infraestructura de Comunicaciones
LAN
WAN
Seguridad
Seguridad Informática
Seguridad Aplicativa
Operaciones
Gestión de Ambientes
Procesamiento Batch
Monitoreo y Control
Administración de Recursos
Centrode Soporte
Atención de Incidentes y
Pedidos
Gestión de Accesos
Oficina de Procesos
Oficina de Proyectos
Estrategia de Servicios
Se necesita un cambio de foco…
Con foco en el servicio a través de los procesos
La nueva visión de TI como Proveedor de Servicios
…
…
32
1Proceso
de Negocio
32
1Proceso
de Negocio
32
1Proceso
de Negocio
Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3
321Servicio
Hardware
Sistema
Operativo Base de Datos Redes Aplicaciones Datos
Infraestructura
Arquitectura de
Servicios,
Operaciones, Centro
de Soporte, etc.
ProyectosConfiguración
y Cambios
Nivel de
Servicios
Incidentes y
Problemas
Capacidad y
Disponibilidad
Procesos
Equipos de
Soporte
1) Procesos de
negocio
requieren apoyo
informático.
2) Servicios de TI apoyan
a los procesos de
negocio.
3) Infraestructura informática
y de telecomunicaciones
configura a los servicios
de TI.
4) Equipos de soporte operan y
mantienen la infraestructura de los
servicios de TI.
5) Procesos para
gestionar los servicios
de TI aseguran la
operación de los
equipos de soporte
para proveer al
negocio servicios de
calidad.
Aseguramient
o y Control de
Calidad
Desarrollo de
Software Continuidad
Servicios
Acuerdos de Nivel
de Servicio
Acuerdos de Nivel
de Operacional
Servicios de Calidad
Funcionalidad
+
Disponibilidad
Performance
Seguridad
Soporte
Negocio
Cambio en la visión de TI
Tradicional Gestión de Servicios
Foco en Tecnología
Administrar Infraestructura
Usuarios
Modalidad “Bombero”
Reactivo
Islas
Procesos informales
Foco en el Negocio
Proveer Servicios
Clientes
Prevención y Control
Proactivo
Integrado
Estandarización y mejores prácticas
La punta del Iceberg
Una problemática compleja
Ge
sti
ón
de l
os
Se
rvic
ios
de I
TADMINISTRAR Y PROVEER
TECNOLOGÍA
INCIDENTES EN PRODUCCIÓN
PEDIDOS DE USUARIOS
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
…
ITIL: UN CONJUNTO DE BUENAS
PRÁCTICAS
Administración de Servicios de TI
¿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)
ITIL V3
¿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.
¿Qué es una Mejor Práctica?
Conjunto de guías que surgen de
Las mejores experiencias.
De los profesionales más calificados y
experimentados.
En un área o dominio específico.
Se basa en
Más de una persona.
Más de una organización.
Más de una tecnología.
Más de un evento.
¿Dónde se ubican las Mejores Prácticas?
• ISO 20000-1 - Especificaciones
Objetivos
• ISO 20000-2 – Código de PrácticaRecomenda-
ciones
• Definición de procesos
ITIL (Mejores Prácticas)
• Implementación de la solución
Procedimientos propios
GENERACIÓN DE VALOR
Gestión de Servicios de TI
¿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
para el propósito
(requerimientos
funcionales)
Garantía o aptitud
para el uso
(requerimientos no
funcionales
¿Cómo se genera el valor?
Medio para entregar valor a los usuarios,
facilitando la obtención de resultados.
Resultados se logran a través de la
ejecución de tareas limitadas por
restricciones.
Los servicios mejoran el
rendimiento de las tareas y/o reducen las restricciones.
Incremento de la probabilidad de
obtener los resultados deseados.
Proveedores asumen riesgos y asignan costos a
clientes por el uso de servicios.
¿A qué llamamos Gestión del Servicio?
Conjunto de habilidades
organizacionales especializadas,
para la provisión de valor a los
clientes en forma de servicios.
Recursos: entradas directas
para la producción (capital
financiero, infraestructura,
aplicaciones e información,
etc.)
Capacidades: aptitud para
coordinar, controlar y
desplegar recursos para
producir valor (gestión,
organización, procesos,
conocimiento, etc.)
La gestión a lo largo del ciclo de vida
La Gestión del Servicio es la habilidad de
transformar los recursos disponibles en servicios
de valor haciendo el mejor uso de las capacidades
organizacionales a lo largo de todo el ciclo de vida
de los servicios.
Generación de valor: “qué” + “cómo”
Utilidad
Funcionalidad del servicio
Garantía
Capacidad y Disponibilidad
Confiabilidad Soporte Continuidad Seguridad
¿Cómo lograr el valor necesario?
Modelado de Negocio
Mercado (usuarios
del servicio)
Demanda (patrones
de uso del
servicio)
Visión y Alcance
del Servicio
Diseño del Servicio
Diseño y Arquitectura del Servicio
Capaci-dad y
Disponibi-lidad
Continui-dad
Seguir-dad
Análisis y Diseño
Aplicativo
Nivel de Servicio
Construcción del Servicio
Montaje de Infraestructura
Hardware y
Software de Base
Comuni-caciones
Construcción de software
Desa-rrollo
Pruebas
Gestión de Proyectos
¿Cómo lograr el valor necesario?
• Identificar los patrones de actividad del negocio (PBA).
• Identificar los perfiles de usuario (UP) y su relación con los PBA.
• Definir los servicios básicos y los servicios de apoyo y sus formas de empaquetamiento.
• Desarrollar los paquetes de nivel de servicio (cubrir patrones de demanda específicos con utilidad y garantía determinada).
Gestión de la demanda
• Proporcionar cuantificación financiera del valor de los servicios de TI y el costo de su infraestructura.
Gestión financiera
• Asegurar un nivel de capacidad justificado para todos los aspectos de TI, de acuerdo a las necesidades de negocio actuales y futuras.
Gestión de la capacidad
• Asegurar que el nivel de disponibilidad de los servicios de TI alcanza o excede las necesidades de negocio (actuales y futuras).
Gestión de la disponibilidad
• Apoyar al proceso de continuidad de negocios asegurando la continuidad operativa de los servicios de TI.
Gestión de la continuidad
• Negociar, acordar y documentar niveles de servicio con representantes del negocio.
• Monitorear e informar la capacidad de TI de entregar los servicios con los niveles acordados.
Gestión de nivel de servicio
Gestión del Nivel de Servicio
Catálogo
de
Servicios
de TI
Cliente
SLRs
SLAs UCs
OLAs Áreas
Internas
Áreas
Externas
Especificación
de Servicio
LA OPERACIÓN DIARIA
Gestión de Servicios de TI
¿Cuál es la situación?
Prepararse para el día
a día
Pedidos de usuarios
Servicios que se rompen
Eventos que requieren atención
Errores ocultos en la
infraestructura
Necesidad de adaptar los servicios al
contexto cambiante
Necesidad de proteger el ambiente productivo
Operación compleja requiere una gestión activa
• Recuperar la operación normal tan pronto como sea posible.
• Proveer un canal para que los usuarios puedan realizar pedidos estándar.
Gestión de incidentes y pedidos de usuario
• Otorgar derechos de uso de los servicios de TI a los usuarios.
• Gestionar la confidencialidad, disponibilidad e integridad de los datos.
Gestión de accesos
• Detectar y clasificar los eventos generados por el monitoreo de la infraestructura y los servicios.
• Determinar las acciones de control adecuadas.
Gestión de eventos
• Encontrar los errores en la infraestructura que causan incidentes.
• Determinar la mejor solución posible para cada caso.
Gestión de problemas
• Proporcionar un mecanismo controlado para procesar los pedidos de cambio a los servicios productivos.
Gestión de cambios
• Procurar que los ambientes productivos se modifiquen lo menos posible, de manera totalmente controlada y con todas las consideraciones necesarias.
Gestión de pasaje a producción
GESTIÓN DE INCIDENTES
Gestión de Servicios Informáticos
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.
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).
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
Urgencia
Alta 1 2 3
Media 2 3 4
Baja 3 4 5
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 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:
Realizarlo conjuntamente con el usuario.
Resolverlo remotamente.
Utilizando un grupo de soporte presencial.
Contactando un 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.
Roles y responsabilidades
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
Gestión de Servicios Informáticos
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
Siguiendo al Sol
Local
Usuario Local
Service Desk
Local
Gestión de
Requerimientos
Soporte de
terceros
Gestión de
Operaciones de TI Gestión de
Aplicaciones
Gestión Técnica
Usuario Local Usuario Local Usuario Local
Local
Diseñado para soportar las necesidades locales del negocio.
El soporte se encuentra y brinda usualmente en la misma localidad que
está siendo soportada.
Es práctico para pequeñas organizaciones.
Es impráctico para organizaciones dispersas geográficamente.
Service Desk centralizado
Sede Cliente 1 Sede Cliente 2 Sede Cliente 3
Service Desk
Segunda línea
Gestión de
Requerimientos
Soporte de
terceros
Gestión de
Operaciones de TI Gestión de
Aplicaciones
Gestión Técnica
Service Desk centralizado
Se centraliza la atención de varios centros geográficos distintos en un
Service Desk central.
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.
Mejora el uso de los recursos.
Service Desk virtual
Virtual
Service Desk
Paris
Service Desk
San Francisco
Service Desk
Rio de Janeiro
Service Desk
Beijing
Service Desk
London
Service Desk
Sydney
Service Desk
Sistema de Gestión
de los Servicios de
Conocimiento
Service Desk virtual
La ubicación de los analistas del SD es transparente al usuario.
Deben existir procesos y procedimientos comunes y un solo registro de
incidentes.
Lenguaje común acordado para la entrada de datos.
Se mantiene el 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 regiones geográficas desde donde se da
servicio.
Se debe considerar en este caso, especial atención 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 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
Gestión de Servicios Informáticos
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.
Roles y responsabilidades
Gestor de Problemas
Grupos de Resolución de Problemas
GESTIÓN DE CAMBIOS
Gestión de Servicios Informáticos
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
Planificado
Cerrado
*Incluye construcción y prueba del cambio
Crear RFC
Propuesta de
Cambios
(opcional)
Autorizar la propuesta de
cambio
Registrar el RFC
Revisar el RFC
Evaluar el cambio
Autorizar el
cambio
Plan actualizado
Coordinar la implementación
de Cambio*
IniciadorSolicitado
Gestión del CambioListo para evaluación
Change authority
Gestión del Cambio
Gestión del Cambio
Reporte de evaluación
Implementado
Revisar y cerrar el registro
de cambio
Ordenes de Trabajo
Ordenes de Trabajo
Autorizado
Listo para decisión
Actu
aliza
r el c
am
bio
y la
info
rmació
n d
e la
congig
ura
ció
n e
n e
l CM
S
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.
Crear el RFC
RFCIniciación
Resultados del Cambio
Implementación
Programada Recomendación del CAB
Prioridad y Urgencia
CI (atributos)
Implementador del
Cambio
Motivo del Cambio
Número RFC
Fecha y Hora de
Implementación
Autorizado por
Fecha y Hora de
Aprobación
Análisis de Riesgo
e Impacto / Recursos
Resutado de las Pruebas
Descripción del Cambio
Revisió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?
Autorizar el RFC
Categorización de riesgos.
Evaluación de cambios.
Asignación de prioridad.
Planificación de cambios.
Gestión del Cambio
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.
Roles y responsabilidades
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.
Roles y responsabilidades
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.
Roles y responsabilidades
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
Roles y responsabilidades
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 Servicios Informáticos
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
Release and Deployment Manager
Release Packaging and Build Manager
Deployment staff
COMPLEJIDAD DE LOS
SERVICIOS
Gestión de Servicios de TI
¿Cuál es la situación?
Necesidad de controlar la
infraestructura
Negocio en contexto dinámico
Procesos de negocio en constante adaptación
Procesos de negocio
dependen de los servicios de
TI
Gran cantidad de servicios de
TI interconectados
Tecnología de los servicios de
TI compleja
Arquitectura aplicativa de
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
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
Gestión de la Configuración
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 incorrectos en la
CMDB, etc )
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
CMDB
Información sobre CIsCis FísicosDML
DML and CMDB
Registro de
versión
Cis
Electrónicos
Construcción de
una nueva versión
Prueba de una
nueva versión
Implementación de
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 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
MANTENIMIENTO DEL VALOR EN
EL TIEMPO
Gestión de Servicios de TI
¿Cuál es la situación?
Pérdida progresiva
de valor
Contexto cambiante
Estrategia de negocio que evoluciona
Servicios que sufren
sucesivas adaptaciones
Avances tecnológicos constantes
Cambios organizativos
Mejor comprensión
de los procesos
Implementar la mejora continua para sostener valor
Análisis de Riesgos
• Identificar actuales
amenazas, y el
riesgo que genera
cada una.
• Identificar situaciones
de exposición a
riesgo inaceptables.
• Determinar
alternativas de
mitigación para
reducir probabilidad o
impacto de la
amenaza.
Caso de Negocio
• Articular razones
para justificar la
mejora.
• Proveer datos de
costo y beneficios.
• Analizar el ROI.
El ciclo de Deming
• Planificar
• Hacer
• Revisar
• Actuar
Los 7 pasos de la
mejora de proceso
• Identificar qué debo
medir.
• Determinar qué
puedo medir.
• Reunir los datos.
• Procesar los datos.
• Analizar la
información.
• Presentar y usar la
información.
• Implementar
acciones correctivas.
BENEFICIOS DE ITIL
Administración de Servicios de TI
¿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.
ProductosValor al
Cliente
Procesos de
Negocio
Servicios
de IT
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.
ProductosValor al
Cliente
Procesos de
Negocio
Servicios
de IT
¿CÓMO SE IMPLEMENTA ITIL?
Administración de Servicios de TI
¿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
0 - Incompleto El proceso no se ejecuta adecuadamente
1 – Ejecutado Acuerdo general en que se hace
2 - Administrado Planificado y controlado
Productos estándar
3 - Establecido Proceso definido para la ejecución y administración
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
Riesgo
Pro
du
ctiv
idad
yC
alid
ad
Resultado
Temas a tener en cuenta en cada fase de una implementación
Personas
Conocer cultura Establecer visión Cambio cultural
Participación de las distintas áreas
ComunicarFormar
Marketing
ComunicarCapacitar
Establecer grupos de interés
Procesos
Gap AnalysisSeleccionar procesosPriorizar
implementación
Diseñar procesosDocumentar
Implementarlos
MedirOptimizarIntegrar
Herramientas
Relevar tecnologíaSeleccionar y adquirir nueva
tecnología
Automatizar Procesos
Migrar datosRealizar pruebas
Integrar
Administrar ActualizarIntegrar
Antes(Planificación)
Durante(Diseño
e implementación)
Después (Seguimiento y
Mejora Continua)
FACTORES CRÍTICOS DE ÉXITO
Administración de Servicios de TI
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
Gestión de Servicios de TI
Visión integral de los procesos de gestión de servicios de TI
FIN
MUCHAS GRACIAS
excelza.blogspot.com
