Fundamentos de ITIL - Entel v1 3 - versión impresión

Fundamentos de ITIL V3

Preparado por Gino Bernucci C.

Agenda

• Introducción

• Conceptos Generales

• Estrategia de Servicio

• Diseño de Servicio

• Transición de Servicio

• Operación de Servicio

• Mejora Continua

• Introducción






• Mejora Continua

Agenda

Introducción

• Estructura del Curso

• Objetivo del Curso

• Presentación de los alumnos

Agenda

• Introducción






• Mejora Continua

¿Qué es ITIL®?

I T I L

nformation

echnology

nfrastructure

ibrary

ITIL® es un conjunto de buenas prácticas basada en procesos y funciones alineados e interconectados para la gestión de Servicios TI. Estos abarcan a personas, procesos, tecnología y proveedores, los cuales juntos permiten que las empresas desarrollen y entreguen servicios de calidad, enfocada a la satisfacción del cliente.

Definiciones Generales

• Buena Práctica:

– Conjunto de actividades o forma de hacer algo que probó ser eficiente.

– Aquella que se considera aceptable dentro de una industria, lo que permite que la organización utilice la práctica para cumplir los requerimientos externos y jurídicos.

Breve Historia de ITIL®

1986 •CCTA inicia proyecto GITMM

1989 • ITIL V1

2001 • ITIL V2

2007 • ITIL V3

2011 • ITIL V3 Rev.2011

Evolución de ITIL

https://sites.google.com/site/jguerreroasti/diseno-del-servicio/admcatalogo

Tiempo

Rol TI

http://it-leinus.blogspot.com/2010_12_01_archive.html

2


• Servicio :

– Medio para entregar valor a los Clientes facilitándoles un resultado deseado sin la necesidad de que éstos asuman los costos y riesgos específicos asociados.

• Ejemplo:

– “La gente no quiere taladros de un cuarto de pulgada, quiere agujeros de un cuarto de pulgada”

Profesor Emérito Theodore Levitt, Harvard Business School


• Gestión de Servicio:

– Conjunto de capacidades especializadas de la organización que proporcionan valor a los clientes en forma de servicios

– Toma la forma de un conjunto de Funciones y Procesos para gestionar los Servicios a lo largo de su Ciclo de Vida

La Utilidad y Garantía crean Valor

• Utilidad – lo que desea el cliente

• Garantía: – Cómo se debe entregar lo que el cliente desea

La Utilidad y Garantía crean Valor

• Ejemplos de Utilidad

Acceso seguro a las aplicaciones

Encargados de crédito revisan calificación de

solicitantes

Espacio de trabajo móvil

Reporte de Créditos

Servicios

(Catálogo)

Provee valor al cliente cuando

Sin

Ser obligado por la ubicación o la

hora

Retraso del proceso de

crédito

Utilidad Parte A Utilidad Parte B

(Resultados Soportados) (Limitaciones Eliminadas)

Activos Usados para entregar el Servicio

Capacidades ( Activos Abstractos)

Recursos (Activos Concretos)

A1 Gestión Capital financiero A9

A2 Organización Infraestructura A8

A3 Procesos Aplicaciones A7

A4 Conocimiento Información A6

Personas A5 Personas

Proceso

• Conjunto de actividades coordinadas para producir un resultado.

Entradas Salidas Actividades

Modelo de procesos de ITIL V3

Características de los Procesos

• Medibles

– Los administradores desean medir el costo, la calidad, etc.

– Los profesionales están preocupados por la duración y la productividad


• Resultados Específicos

– Un proceso existe para entregar un resultado específico

– El resultado debe ser identificable y medible


• Si bien un proceso puede ser constante e iterativo, debe ser rastreable conforme a un disparador específico

Procesos vs Departamentos

Funciones y Roles

• Funciones:

– Equipo de personas y las herramientas que ocupan para llevar a cabo uno o más procesos.

– Ej.: Mesa de Servicio

• Rol:

– Conjunto de responsabilidades y actividades con autoridad otorgada a una persona o equipo

– Ej.: Dueño de Proceso, Gestor de Proceso

Dueño del Proceso

• La persona responsable de garantizar que el proceso se lleve a cabo conforme a lo acordado y documentado, y que cumple los objetivos planteados, sus responsabilidad incluyen: – Documentar y publicar el proceso

– Definir KPIs para el proceso

– Mejorar el proceso

– Resolver los problemas en la ejecución del proceso

– Garantizar que el personal está capacitado y conoce los roles de su proceso

Gestor del Proceso

• Es responsable por la gestión operacional del proceso.

• Pueden existir varios Gestores de procesos para un solo proceso.

Dueño del Servicio

• El Dueño del Servicio es responsable de un Servicio específico dentro de una organización, sin importar dónde residen los componentes de tecnología de soporte, procesos y habilidades profesionales

• La propiedad del Servicio es fundamental para la Gestión de Servicios ya que establece la propiedad de los Servicios que cruzan múltiples silos/departamentos

Dueño de Servicio

• Asegura que el servicio es gestionado y alineado a cumplir los requerimientos del negocio

• La definición de un punto único responsable es esencial para proveer el nivel de atención y el foco requerido para la entrega efectiva del servicio.

• Está a cargo de la iniciación y transición del servicio.

• Asegura que la entrega y soporte del servicio cumpla con las expectativas del cliente.

• Funciona como nexo en el ciclo de vida del servicio con los dueños del proceso

Roles Genéricos

• Participantes del Proceso

– Un ejemplo de Participante del Proceso sería: un Analista de Cambios, un Soporte de Nivel "n" o un miembro de un equipo técnico desarrollando un Requerimiento, u otros.

– Sus responsabilidades típicas incluyen:

• Desempeñar actividades

• Crear o actualizar los registros para las actividades

Modelo RACI

Responsable (Responsible) — Encargado de ejecutar la actividad.

Responsable (Accountable) — Dueño de la calidad y los resultados finales (único por actividad)

Consultado (Consulted) — Las personas o funciones que deben ser consultadas

Informado (Informed) — Las personas o funciones que deben ser informadas

R A C I

Modelo RACI

• Regla de Oro: – Sólo puede existir una “A” por cada actividad

– Mínimo debe existir una “R” por cada actividad

Ciclo de Vida del Servicio ITIL V3

Mejoramiento Continuo del

Servicio

Diseño del Servicio

Estrategia del Servicio

Operación del Servicio

Transición del Servicio

ITIL define un ciclo de vida para los servicios que consta de 5 fases.



Servicio





Estrategia del Servicio: Modelar y planear Servicios que tienen utilidad y garantía



Servicio





Diseño del Servicio: Servicios consistentes, rentables y de alta calidad



Servicio





Transición del Servicio: Realizar la transición de servicios nuevos y modificados a la operación



Servicio





Operación del Servicio: Conseguir la efectividad y eficiencia en la entrega de los servicios



Servicio





Mejoramiento Continuo del Servicio: Continuar creando e incrementando el valor a través de mejoras

Estrategia

del Servicio

Diseño del

Servicio

Transición

del Servicio

Operación

del Servicio

Mejoramiento

Continuo del

Servicio

Requerimientos

Cómo se implementa el

servicio

¿Qué Servicios?

Requerimientos operacionales

Cómo se entrega el Servicio

Cómo se brinda soporte al servicio

Métricas

Solicitudes de Cambio

Ciclo de Vida del Servicio

Ciclo de Vida del Servicio

Gestión Financiera

Gestión del

Portafolio Serv.

Gestión de la

Demanda

Gestión Relaciones

con el Negocio

Gestión de la

Capacidad

Gestión de la

Disponibilidad

Gestión de la

Continuidad

Gestión Niveles de

Servicio

Gestión de la

Seguridad de Info

Gestión de Cambios

Gestión de Activos

y Confi.

Gestión de Liber. y

Despliegue

Gestión de la

Catálogo de Serv.

Gestión de

Proveedores

Proceso de Mejora de

7 Pasos

Planificación de

Transición y Sop.

Validación y

Pruebas

Evaluación

Gestión del

Conocimiento

Gestión de

Incidentes

Gestión de

Problemas

Gestión de Accesos

Gestión de Eventos

Gestión de

Requerimientos





Mejora Continua del Servicio

Gestión Estratégica

para los Servicios TI

Coordinación del

Diseño

Ejercicio 1

¿Para qué se utiliza el modelo RACI?

a) Para documentar los roles y las relaciones entre las

partes interesadas en un proceso o actividad

b) Para definir los requisitos de un nuevo proceso o servicio

c) Para analizar el impacto en el negocio de un Incidente

d) Para crear un Cuadro de Mando Integral que muestre el estado completo de la gestión del servicio

Ejercicio 2

El Dueño del Proceso es el responsable de:

a) La adquisición de las herramientas necesarias para soportar el proceso

b) Asegurar que se cumplan las metas especificadas en el Acuerdo de Nivel de Servicio (SLA)

c) Realizar las actividades definidas en el proceso

d) Asegurar que el proceso se ejecute según lo documentado

Ejercicio 3

¿Cómo se describe MEJOR las Funciones?

a) Una recopilación de conocimientos

b) Sistemas de circuito cerrado

c) Unidades definidas dentro de las organizaciones

d) Proyectos enfocados hacia la transformación

Ejercicio 4

¿Cuál de las siguientes afirmaciones es CORRECTA para todos los servicios TI?

a) Proporcionan recursos y capacidades a los clientes

b) Proporcionan costos y riesgos a los clientes

c) Proporcionan soluciones de negocio a los clientes

d) Proporcionan valor a los clientes

Agenda

• Introducción






• Mejora Continua

Objetivos

• Habilitar a la organización de TI para entregar un desempeño superior a las alternativas de la competencia

• A través de: – Implementar la Gestión de Servicios como un

activo estratégico (es de vital importancia para el cliente)

– Planificación y posicionamiento

– Desarrollo de políticas

Objetivos

• Responder preguntas como – ¿Qué servicios ofrecer?

– ¿Cómo diferenciarse de alternativas competitivas?

– ¿Cómo se puede crear valor para el cliente?

– ¿Cómo hacer un caso para inversiones estratégicas?

– ¿Cómo proveer control y visibilidad financiera de la creación de valor?

– ¿Cómo resolvemos conflictos de demanda de los recursos compartidos?

La Creación de Valor

• Depende no sólo de los resultados, también es altamente dependiente de las percepciones de los clientes.

• Las percepciones de los clientes son influenciadas por los atributos del servicio y las indicaciones de valor recibidas por los clientes, según su punto de vista.

Tipo de Proveedor

• Tipo 1: Proveedor interno de servicios que vive dentro de la misma organización a la que atiende.

• Tipo 2: Proveedor interno que entrega/soporta servicios de TI compartidos con más de una unidad de negocio.

• Tipo 3: Proveedor de servicios que entrega/soporta servicios de TI a clientes externos.

Procesos

• Gestión de Relaciones con el negocio

• Gestión del Portafolio de Servicios

• Gestión Financiera para Servicios de TI

• Gestión de la Demanda

Gestión de Relaciones con el Negocio (BRM)

• Alcance – Para los proveedores de servicios internos, la gestión de

relacionamiento de negocio es ejecutado usualmente por un representante senior del departamento de TI y un representante senior por parte del negocio. Acá se debe hacer énfasis en alinear los objetivos de negocio con las actividades que desarrolla TI para dar soporte a dichos objetivos.

– En el caso de proveedores de servicios externos, la gestión de relación de negocio es usualmente ejecutado por roles dedicados y específicos (también conocidos como gerente de cuentas o account managers) dedicándose cada uno a gestionar uno o mas clientes como parte de sus responsabilidades. Acá se debe hacer énfasis en maximizar el valor de contrato a través de la satisfacción de usuarios.

• Propósito – Establecer y mantener una relación de negocios entre el

proveedor de servicios y el cliente basado en el entendimiento del cliente y sus necesidades de negocio.

– Identificar las necesidades del cliente y asegurar que el proveedor es capaz de alcanzar dichos objetivos, considerando sus cambios en el tiempo y acorde a las circunstancias.

– Asegurar que el proveedor de servicios entiende dichos cambios y apoya al negocio en identificar correctamente el valor que entrega el servicio.

– Asegura que las expectativas del cliente no exceden lo que están dispuestos a pagar y que el proveedor de servicio puede cumplir las expectativas antes de iniciar la entrega de los servicios.


• Objetivos

– Asegurar que el proveedor de servicios entiende la perspectiva de servicios del cliente y, por lo tanto, capaz de priorizar sus servicios y componentes asociados.

– Asegurar altos niveles de satisfacción de los usuarios/clientes al cumplir sus requerimientos.

– Establecer y mantener una relación constructiva entre el proveedor y el cliente basado en el entendimiento de los elementos relevantes del negocio.

– Identificar los cambios en los ambientes del cliente que potencialmente pudieran impactar el tipo, nivel o utilización de los servicios provistos.


• Objetivos

– Identificar las tendencias de tecnologías que potencialmente pudieran impactar el tipo, nivel o utilización de los servicios provistos.

– Establecer y articular los requerimientos de negocio para nuevos servicios o cambios de servicios existentes.

– Mediar en caso de conflictos causados por requerimientos del cliente

– Establecer procesos formales de escalamientos y quejas para el cliente


• Gestión de relaciones con el negocio y el gestor de relaciones con el negocio – El proceso de BRM es usualmente confundido con el rol

del gestor del proceso BRM. Esto es porque el rol suele ser de alto nivel y muchos clientes asocian las actividades de gestión con la persona que ejecuta el rol.

– Rol del gestor del proceso BRM también genera confusión con el proceso, pues el rol usualmente entrega información a otros procesos de gestión como Gestión del Portafolio, Gestión de la Demanda y Capacidad y, por ende, parece ser confuso que procesos y actividades realmente ejecuta el rol del gestor del proceso BRM.


Procesos





Gestión del Portafolio de Servicios

• ¿Qué es el Portafolio de Servicios?

https://sites.google.com/site/jguerreroasti/diseno-del-servicio/admcatalogo


• Una mirada un poco más simplificada:

http://www.garethpoxon.com/2012/06/service-portfolio-whats-on-menu.html


• Fases del portafolio de servicio – Pipeline de Servicios

• Servicios en desarrollo o proyectados

– Catálogo de servicios • Es la parte del portafolio de

servicio visible a los cliente.

– Servicios retirados • Son servicios dentro del

catálogo de servicios que están fuera de producción.

http://www.garethpoxon.com/2012/04/service-portfolio-management-cooking-up.html


• Fases del portafolio de servicio – Pipeline de Servicios

• Servicios en desarrollo o proyectados

– Catálogo de servicios • Es la parte del portafolio de

servicio visible a los cliente.

– Servicios retirados • Son servicios dentro del

catálogo de servicios que están fuera de producción.

http://fineans.usac.edu.gt:8001/rid=1J4T1Y76N-1PNWZDM-9YB/Service Strategy - ITIL.cmap

El Catálogo es un subconjunto del porfolio de

servicio • Contiene la lista de servicios

activos y aprobados • Proyección de capacidades

reales y actuales • Puerta de adquisición para

los clientes • Precio, nivel de servicio

comprometido y términos del suministro del servicio

• Comunica la información referente a Políticas, Pautas y responsabilidades.

Procesos





Gestión Financiera

“La economía no reside en escatimar dinero, sino en gastarlo sabiamente”

Thoman Henry Huxley

• Propósito

– Proveer al Negocio y a TI de la cuantificación, en términos financieros del valor de los Servicios de TI y el valor de los activos que soportan la entrega de estos Servicios

Gestión Financiera

• Objetivos – Visibilidad y cumplimiento (Financiera y contable) – Valorizar los servicios y dar claro entendimiento del

costo de proveer un servicio – Entender el valor que se debe cobrar a los clientes al

utilizar un servicio – Apoyar y fundamentar la toma de decisiones a través

del ciclo de vida del servicio

• En resumen: proporcionar una gestión efectiva en costos de los activos y recursos utilizados para proporcionar los servicios de TI.

Gestión Financiera

• Conceptos básicos

– Presupuesto / Planificación

– Contabilidad

– Valorización del Servicio (Cargos o Precios)

– Tipos de costos:

• Fijos y variables

• Capital y Operacional

• Directos e Indirectos

Gestión Financiera

• ROI (Return On Investment) – Retorno de la inversión – Cuantificar el valor de una inversión – Por ejemplo, invirtió 1.000 dólares en una

certificación y, como resultado, ha vendido consultorías por 1.400 dólares. Por consiguiente, resta los 1.000 dólares del costo de su certificación de los 1.400 dólares de ventas, con lo que obtiene 400 dólares. Esta cantidad son los beneficios que recupera como resultado de su inversión inicial de 1.000 dólares. Su ROI, expresado como porcentaje de su inversión inicial, sería del 40% (400/1.000 multiplicado por 100).

Gestión Financiera

• BC (Business Case) – Caso de Negocio – Una herramienta de planificación que soporta las

decisiones y predice los resultados de una acción en particular. Se usa para la justificación de las inversiones (incluye el ROI y el VOI)

– Estructura sugerida: • Introducción

• Métodos y Supuestos

• Impactos de Negocio

• Riesgos y Contingencias

• Recomendaciones

Procesos





Gestión de la Demanda

• Objetivos

– Entender e influenciar la demanda de los clientes por los Servicios.

– Optimizar el uso de la capacidad, moviendo cargas de trabajo hacia tiempos, recursos o lugares menos utilizados


• Desafíos: – Capacidad excesiva genera costos sin crear valor

– Capacidad insuficiente tiene impacto en la calidad de los Servicios entregados y limita el crecimiento de los mismos

– A diferencia de los bienes, los Servicios no pueden ser armados con anticipación o almacenados en un inventario, para así anticiparse a la demanda.

– La demanda puede ser influenciada de diferentes formas: • Ej.: Tarifa Punta y Tarifa Valle en el Metro de Santiago


• Por lo general, cuanto mejor funciona un servicio, mayor demanda genera. Ésta, a su vez, provoca exigencias de capacidad que los responsables compensan, como es natural, incrementando los activos del servicio. Se genera así un ciclo de consumo-producción en el que el consumo es un estímulo positivo para la producción y viceversa:

http://itilv3.osiatis.es/estrategia_servicios_TI/gestion_demanda.php


• Patrones de Actividad del Negocio (Patterns of Business Activity)

– Corresponde a lo consumido en la realidad

• Perfiles de Usuario (User Profiles):

– Corresponde a quiénes consumen los servicios

• Cada UP se puede asociar con un PBA o más.

Ejercicio 1

Cuál de las siguientes afirmaciones es CORRECTA en referencia a la Creación de Valor por medio de servicios?

a) La percepción del cliente respecto al servicio es un factor importante en la Creación de Valor

b) El valor de un servicio solo puede medirse en términos financieros

c) Entregar los resultados esperados del cliente no resulta importante en el valor de un servicio

d) Las preferencias del proveedor de servicio influencian la percepción del valor de un servicio

Ejercicio 2

¿Qué significa "Garantía de un Servicio"? a) El servicio es adecuado para un propósito

b) No habrá fallos en las aplicaciones ni en la infraestructura asociada al servicio

c) Todos los problemas relacionados con el servicio se arreglan sin costo durante un cierto período de tiempo

d) Se garantiza al cliente un determinado nivel de disponibilidad, capacidad, continuidad y seguridad

Ejercicio 3

¿Cuál de los siguientes es una actividad PRINCIPAL de la Gestión de la Demanda?

a) Aumentar el valor al cliente

b) Entender los patrones de actividad del negocio

c) Incrementar el valor de TI

d) Alinear al negocio con los costos de TI

• Introducción






• Mejora Continua

Agenda

Diseño de Servicio

• Descripción – Provee guía para el diseño, el desarrollo de servicios y

procesos de gestión de servicios. Contiene principios de diseño y métodos para convertir objetivos estratégicos en activos de servicios y en portafolios de servicios.

• Conceptos Claves – Las 4 P del diseño

– Paquete para el Diseño de Servicios (SDP)

– Aspectos del Diseño del Servicio

Alcance

• Diseñar nuevos (o modificar) servicios para el ambiente de producción

• Considerar una aproximación holística de todos los aspectos de diseño que pueden ser adoptados.

• Cuando se cambia o corrige cualquier de los elementos individuales del diseño, se debe considerar los 5 grandes aspectos del diseño: – Servicios (soluciones para nuevos o cambiados servicios) – Herramientas (para la gestión de información) – Arquitecturas (tecnología y gestión) – Procesos (que sean requeridos) – Métricas (métodos de medición)

Alcance

• Sólo los cambios “significativos” requieren la actividad de Diseño de Servicio

• Cada organización debe definir que cambio es “significativo” para su realidad

Objetivos

• Diseñar servicios para: – Satisfacer los objetivos del negocio

– Desarrollos eficientes dentro de las escalas de tiempo y costos apropiados

– Identificar y manejar el riesgo para que pueda ser mitigado

• Diseñar procesos eficientes y efectivos para la transición, operación y mejora de servicios de TI de alta calidad

Objetivos

• Diseño seguro y adaptable para las infraestructuras de TI, sus ambientes, las aplicaciones, los recursos de data/información y las capacidades.

• Diseño de métodos y métricas para analizar el proceso.

• Producir y mantener los planes de TI, procesos, políticas, arquitecturas estándar y un marco de trabajo en todas las áreas de diseño.

Objetivos

• Desarrollo de habilidades y capacidades dentro de TI considerando las actividades de estrategia y diseño en las tareas operativas

• Contribuir con la mejora de la calidad de todos los servicios de TI

Valor al Negocio

• Entregar servicios rentables y de calidad, así como asegurar el cumplimiento de los requisitos del negocio

• Principales beneficios para el negocio: – Menor TCO

– Mejoras en la calidad del Servicio

– Mejoras en la consistencia del Servicio

– Implementación más sencilla de Servicios

– Mayor eficiencia en el rendimiento del Servicio

Las 4 P del Diseño

People

• Personas, habilidades y competencias involucradas en el suministro de los servicios de TI

Products

• La tecnología y los sistemas de gestión usados en el suministro de los servicios de TI

Processes

• Los procesos, roles y actividades involucrados en el suministro de los servicios de TI

Partners

• Los vendedores, los fabricantes y los proveedores usados para asistir y soportar el suministro de los servicios de TI

SDP (Service Design Package)

• Se desarrolla durante la fase de diseño cada vez que: – se diseñe un servicio nuevo

– se hace un cambio importante en un servicio

• Este paquete es entonces pasado desde el Diseño de Servicio a la Transición de Servicios con toda la información relacionada a los aspectos del servicio y sus requerimientos.

• Es el producto de la fase de Diseño

Contenido de un SDP

• Requerimientos – de negocio

– de aplicabilidad del servicio

– de contactos

• Diseño de servicio – Requerimientos funcionales

– Requerimientos de niveles de servicios

– Requerimientos de gestión de servicios y operacionales

– Diseño y topología del servicio

Contenido de un SDP

• Plan de ciclo de vida de servicio

– Programa del servicio

– Plan de transición del servicio

– Plan de aceptación operacional del servicio

– Criterios de aceptación del servicio

Diseño de Soluciones

Tipos de entrega de servicios

• Opciones de Entrega de servicio (1/2) – Tipo In-sourcing

• Utiliza recursos internos para proveer servicios en todo el ciclo de vida

– Tipo Outsourcing • Utiliza recursos externos para proveer servicios en todo el

ciclo de vida

– Tipo Co-sourcing • Utiliza recursos internos y externos para proveer servicios en

todo el ciclo de vida

– Tipo Partnership or multi-sourcing • Utiliza acuerdos entre 2 o más organizaciones para proveer

servicios en un cliente


• Opciones de Entrega de servicio (2/2) – Tipo Externalización del Proceso de Negocio (BPO)

• Utiliza recursos externos (incluyendo la gestión del servicio) en otras ubicaciones

– Tipo Provisión de Servicios de Aplicación (ASP) • Utiliza acuerdos entre el cliente y un Application Service

Provider

– Tipo Externalización del proceso de conocimiento (KPO) • A diferencia de BPO, no solo brinda «expertise» en la

ejecución de un proceso, sino que además provee dominio y conocimiento para análisis y gestión «adelantada»


• Situaciones de Sourcing

– On-shore (dentro de las instalaciones del cliente)

– Off-shore (fuera de las instalaciones del cliente)

Procesos

• Coordinación del Diseño

• Gestión del Catálogo de Servicio

• Gestión de Niveles de Servicio

• Gestión de Disponibilidad

• Gestión de la Capacidad

• Gestión de la Continuidad

• Gestión de la Seguridad de la Información

• Gestión de Proveedores

Coordinación del Diseño

• Las actividades del diseño de servicio son detalladas y complejas.

• Solamente a través de acciones bien coordinadas pueden ayudar al proveedor de servicios a crear diseños apropiados y eficaces para alcanzar los objetivos de negocio.


• Objetivos (1/2) – Asegurar el diseño de servicios apropiados,

incluyendo la gestión, arquitecturas, tecnología, procesos, información y métricas para cumplir y evolucionar los resultados de negocio.

– Coordinar todas las actividades de diseño a través de proyectos, cambios, proveedores y equipos de soporte para gestionar correctamente los recursos asociados al diseño.

– Planificar y coordinar los recursos y capacidades requeridas para diseñar nuevos servicios o cambiar servicios existentes.


• Objetivos (2/2) – Producir los paquetes de diseño de servicio

(SDP’s) y asegurar su correcta gestión

– Gestionar los criterios de calidad, requerimientos y puntos de entrega entre las diferentes etapas del ciclo de vida del servicio.

– Mejorar la efectividad y eficiencia de las actividades de diseño de servicio y sus procesos.

– Monitorear y mejorar el desempeño de la etapa de diseño de servicio

Coordinación de Diseño

• El proceso incluye – Asistir y soportar cada proyecto u otros cambios a través de

todas las actividades y procesos del diseño de servicio – Mantener las políticas, guías, estándares, presupuestos,

modelos, recursos y capacidades para las actividades y procesos para diseñar servicios.

– Planificar y proyectar los recursos necesarios para las demandas futuras de diseño de servicios.

– Revisar, medir y mejorar el desempeño de todas las actividades y procesos de diseño de servicio.

– Asegurar que todos los requerimientos son apropiadamente gestionados para cumplir con utilidad y garantía.

– Asegurar la creación de los SDP’s correspondientes y su mantenimiento durante el ciclo de vida de servicio

Coordinación de Diseño

• El proceso NO incluye

– Responsabilidades por actividades o procesos fuera de la etapa del diseño de servicio

– Responsabilidad de la solución detallada de diseño o la producción de partes individuales de SDP’s (es responsabilidad de cada proyecto de manera individual o de los procesos de gestión de servicio).

Procesos









Gestión del Catálogo de Servicio

• Objetivo – Crear y manejar un Catálogo de Servicio preciso y

consistente de todos los servicios entregados

– Mantener una sola fuente de información que consolida los servicios, es controlada y contiene información exacta de los servicios existentes en la operación

• Alcance – Proveer y mantener información exacta sobre todos

los servicios que han sido o están siendo transicionados al ambiente de producción.


• Actividades – Definición del servicio

– Producción y mantención de un Catálogo de Servicios

– Interfaces, dependencias y consistencia entre el Catálogo de Servicios y el Portafolio de Servicios

– Interfaces y dependencias entre todos los servicios (incluyendo lo servicios de soporte) entre el Catálogo de Servicios y la CMS (Configuration Management System)

– Interfaces y dependencias entre todos los servicios, componentes de soportes e Ítems de Configuración (CI’s - Configuration Items) entre el Catálogo de Servicios y la CMS.


• El Catálogo de Servicios… – Es parte del Portafolio de Servicios

– Posee los detalles de todos los servicios operacionales y preparados para la transición

– Se divide en dos grupos: • Catálogo de Servicios de Negocio

– Detalles de todos los servicios de TI entregados al cliente

– Visible para los clientes

• Catálogo de Servicios Técnicos – Detalles de todo el soporte de servicios con los pormenores

técnicos

– No es visible para el cliente


http://www.overti.es/procesos-itsm/gestion-catalogo-servicios-itsm.aspx

Procesos









Gestión de Niveles de Servicio

• Objetivos – Definir, documentar, acordar, monitorear, medir, reportar y

revisar los niveles de los servicios de TI que se proveen – Proveer y mejorar las relaciones y comunicaciones con el

negocio y los clientes – Asegurar el desarrollo y aplicación de objetivos específicos y

medibles para todos los servicios – Monitorear y mejorar la satisfacción del cliente basado en la

calidad del servicio entregado – Asegurar que tanto el departamento de TI como el cliente

poseen un claro entendimiento y claras expectativas de los servicios que serán entregados

– Asegurar que las mejoras proactivas identificadas puedan ser implementadas a costos justificables


• Propósito

– El propósito del SLM es asegurar que todos los servicios activos en la operación y su rendimiento son continuamente medidos de manera profesional y consistente a través de la organización, asegurando también que los servicios y los reportes que se produzcan cumplan con las necesidades del negocio y de los clientes.


• Acuerdo de Nivel de Servicio (SLA – Service Level Agreement)

– Es un acuerdo escrito entre un proveedor de Servicios TI y el, o los clientes TI, definiendo las claves de los objetivos y las responsabilidades del servicio, de ambas partes.


• Acuerdo de Nivel de operación (OLA – Operational Level Agreement) – Es un acuerdo entre la Unidad de TI y otra parte de la

misma Organización.

– Contiene la descripción de los Servicios TI que se proveen, así como los compromisos de ambas partes para cumplir el SLA.

– Ejemplos: • OLA entre la Unidad de TI y el departamento de Compras, para la

obtención de hardware en plazos previamente comprometidos.

• OLA entre el Centro de Servicio al Usuarios y un Grupo de Soporte para la realización de la Resolución del Incidente en plazos previamente acordados.


• Requerimientos de Nivel de Servicio (SLR – Service Level Requirement) – Es un acuerdo escrito entre un proveedor de Servicios TI y

el, o los clientes TI, definiendo los requerimientos de los objetivos para un servicio (SLA futuro).

• Contratos de soporte terceros (UC – Underpinning Contracts) – Contrato formal entre un proveedor de servicios TI y un

Tercero (Supplier)

• Plan de Mejora de Servicio (SIP – Service Inprovement Plan) – Un plan general organizado con acciones priorizadas para

mejorar servicios.


• Revisión de Servicio (Service Review)

– Se deben realizar de manera regular con los clientes (o sus representantes de negocio) para analizar si se lograron los objetivos en el periodo anterior y prever cualquier incidente o desviación en el periodo futuro. Usualmente estas reuniones se realizan de manera mensual o, por lo menos, trimestralmente.


• ¿Y la Gestión de Relaciones con el Negocio?

– La gestión de niveles de servicio existe para asegurar que se cumplen los niveles de servicio

– La Gestión de Relaciones con el Negocio está enfocada desde un ámbito más estratégico.

– La Gestión de Relaciones con el Negocio tiene como misión identificar las necesidades del cliente y asegurar que el proveedor de servicios es capaz de cumplir con los requerimientos de los clientes y ver qué servicios (junto con el cliente) serán provistos


• En resumen

Procesos









Gestión de Disponibilidad

• Alcance

– Asegurar que los niveles de disponibilidad entregada en todos los servicios estén acorde o excedan las necesidades acordadas actuales y futuras del negocio de forma costo-efectiva.


• Objetivos – Crear y actualizar el Plan de Disponibilidad, el cual debe reflejar

los requerimientos de negocio actuales y futuros. – Proveer guía y consejo a todos las otras áreas de TI y de negocio

referente a los incidentes relacionados a la disponibilidad. – Apoyar al diagnóstico y la resolución de los incidentes y

problemas relacionados a la Disponibilidad. – Evaluar todos los impactos de los cambios en el plan de

Disponibilidad, el rendimiento y la capacidad para todos los servicios y sus recursos.

– Asegurar que las medidas proactivas para mejorar la disponibilidad de servicios son implementadas cuando sean costo-efectivas.


• Actividades Proactivas – Planificación, diseño y mejora de la disponibilidad

• Actividades Reactivas

– Actividades Operacionales – Monitoreo, mediciones, análisis y manejo de todos los eventos, incidentes y

problemas relacionados con la indisponibilidad de los servicios

• Disponibilidad del Servicio

– Todos los aspectos (end-to-end) de la disponibilidad del servicio

• Disponibilidad de Componentes

– Todos los aspectos de la disponibilidad de los componentes individuales que componen uno o más servicios


• Variables que se identifican en este proceso: – Disponibilidad (Availability)

• Porcentaje de tiempo sobre el total acordado en que los servicios TI han sido accesibles al usuario y han funcionado correctamente.

– Confiabilidad (Reliability) • Medida del tiempo durante el cual los servicios han funcionado correctamente

sin ninguna interrupción.

– Capacidad de mantenimiento y restauración (Maintainability) • Capacidad de mantener el servicio operativo y recuperarlo en caso de

interrupción.

– Capacidad de Servicio (Serviceability) • Determina la disponibilidad de los servicios internos y externos contratados y

su adecuación a los OLA’s y UC’s acordados y establecidos.

– Funciones vitales de negocio (Vital Business Function) • Son funciones que reflejan parte de los procesos de negocio que son críticos y

que se soportan con los servicios de TI.


• Definición de Disponibilidad: – Se mide como un porcentaje

– % 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑 =𝑇𝐴𝑆 −𝑇𝐼

𝑇𝐴𝑆∗ 100

– Donde • TAS: Tiempo Acordado de Servicio

– se encuentra documentado en el SLA

• TI: Tiempo de inactividad (durante el TAS) – se calcula al registrar los tiempos de interrupción que provienen

de los registros de Incidentes y de las interrupciones provocadas por los Cambios. No incluye las interrupciones provocadas por los Cambios acordados ni las ventanas de mantenimiento programadas


• Ejemplo: – Tiempo Acordado de Servicio:

• 24 horas al día, los 7 días a la semana • Menos 4 horas para una ventana acordada de servicio • Menos 4 horas para los tiempos inactivos debido a un cambio acordado o programado

– Total: 160 horas para la semana

– TI provocado por Incidentes: 2 horas – TI provocado por cambios no planificados = 2 horas – Total: 4 horas de tiempo inactivo para la semana

– Tiempo activo = TAS – TI = 160 – 4 = 156

– Disponibilidad = 100 * Tiempo activo / TAS – Disponibilidad = 100 * 156 / 160 = 97,5%


Ejemplo: Una situación donde un servicio 24x7 ha estado en funcionamiento por un periodo de 5,020 horas con solo dos interrupciones, una de 6 horas y una de 14 horas, daría los siguientes resultados:

Salida

Servicio Normal Servicio Normal

Detectar

Diagnosticar

Reparar

Recuperar

Restaurar

Incidente Incidente

Tiempo entre fallas (MTBF)

Tiempo entre incidentes del servicio (MTBSI)

Tiempo de restauración (MTRS)

• Disponibilidad (5020–(6+14)) / 5,020 x 100 = 99.60%

• Confiabilidad (MTBSI) 5.020 / 2 = 2,510 horas

• Confiabilidad (MTBF) 5.020–(6+14) / 2 = 2,500 horas

• Mantenimiento y Restauración (MTRS) (6+14) / 2 = 10 horas


• El Análisis de Falla de Servicio (SFA - Service Failure Analysis) – Técnica diseñada para proveer un acercamiento estructurado para identificar

las causas reales de las interrupciones de servicio. SFA utiliza un rango de orígenes de datos para evaluar dónde y por qué las fallas en disponibilidad ocurren. SFA requiere de una visión holística para realizar mejoras no solo orientados a la tecnología, sino que también mejorar el soporte, procesos, procedimientos y herramientas.

• Los objetivos del SFA son:

– Mejorar la disponibilidad total de los Servicios de TI, desarrollando un grupo de mejoras para implementar o para entregar como información relevante al Plan de Disponibilidad

– Identificar las causas que originan las interrupciones de servicio – Evaluar la efectividad de los procesos y del soporte hacia la organización de TI – Producir reportes que detallen los hallazgos y recomendaciones más

relevantes/importantes – Que las mejoras en la disponibilidad originadas por los SFA sean medidos.

Procesos









Gestión de la Capacidad

• Alcance – El proceso es responsable por asegurar la

capacidad de los servicios de TI y su infraestructura, que sean capaces de cumplir los Niveles de Servicios acordados de manera efectiva tanto en costos como en la entrega en tiempo.

– Considera todos los recursos requeridos para entregar los servicios de TI.

– Desarrolla planes a corto, mediano y largo plazo, alineados a los requerimientos del negocio.


• Objetivos – Creación del plan de capacidad – Proveer información y guía a las áreas de negocio y de TI

sobre todos lo relacionado con capacidad y desempeño. – Asegurar que el desempeño cumpla o exceda los objetivos

definidos – Apoyar a la gestión de Incidentes y Problemas en los temas

relacionados a capacidad – Involucramiento con la gestión del cambio – Evaluar el impacto de las soluciones aplicadas a la

capacidad y el desempeño de los servicios – Velar proactivamente por soluciones de bajo costo para

ampliar el desempeño


• Plan de Capacidad – Documenta tanto el uso de los recursos como el

desempeño de los Servicios actuales.

– Planifica los requerimientos futuros de los recursos de TI que se necesitan para respaldar las actividades futuras del negocio.

– Debería ser utilizado activamente y es un apoyo para la toma de decisiones (ej.: publicarlo anualmente junto al presupuesto).

– Es una de las principales salidas de este proceso


• Gestión de la Capacidad del Negocio – Subproceso que traduce las necesidades y los planes

del negocio en requerimientos para Servicios e infraestructura de TI

• Gestión de la Capacidad del Servicio – Subproceso enfocado en la administración, control y

predicción del desempeño y capacidad de principio a fin del uso y las cargas de trabajo de los Servicios de TI.

– Los SLA’s y SLR son monitoreados y medidos para identificar los asuntos relativos a la capacidad


• Gestión de la Capacidad del Componente

– Subproceso enfocado en la administración, control y predicción del desempeño, uso y capacidad de los componentes individuales de tecnología del área de TI (Ej.: discos duros, memorias, CPU, etc.)


• En resumen:

SLA’s y Catálogo Estrategia del Negocio

Estrategia de TI Problemas e Incidentes

Brechas en SLA’s Plan de Finanzas


Plan de Capacidad BD de Capacidad

Umbrales y alarmas Reportes de Capacidad

Cambios proactivos

Procesos









Gestión de la Continuidad

• Alcance

– Recuperar la continuidad operacional del negocio después de una severa interrupción de los servicios TI (que automatizan los procesos de negocio), debido a desastres naturales u otras fuerzas de causa mayor, que puede tener consecuencias catastróficas para el negocio.


• Objetivos – Dar apoyo al proceso Global de gestión de continuidad del negocio (BCM)

asegurando que los servicios de TI requeridos puedan ser recuperadas dentro de los tiempos acordados.

– Mantener un conjunto de Planes de Continuidad y de Recuperación de Negocios para los Servicios de TI que soporten el Plan de Continuidad de Negocio de la organización.

– Ejecutar ejercicios regulares de Análisis de Impacto al Negocio (BIA) para asegurar que todos los Planes de Continuidad están actualizados y alineados a los requerimientos del negocio.

– Conducir de manera regular Gestión y Análisis de Riesgo, en conjunto con el negocio, la Gestión de Disponibilidad y la Gestión de Seguridad.

– Asegurar que los mecanismos apropiados de Continuidad y Recuperación están activos para cumplir o exceder los objetivos de Continuidad de Negocio.

– Evaluar como impactan los cambios realizados en la infraestructura en el Plan de Continuidad y Plan de Recuperación de Servicios de TI.


• Análisis de Impacto al Negocio (BIA)

– El propósito del BIA es cuantificar el impacto que puede generar en el negocio la perdida de un servicio.

– El impacto puede ser muy alto y claramente identificable – como una perdida financiera – o de bajo impacto – como perdida de ventaja competitiva.

– El BIA identificará los servicios más importantes para la organización y, por lo tanto, es una entrada clave para la estrategia de continuidad.


• El BIA identifica la forma que el daño o pérdida puede tomar:

– Costos adicionales

– Daño en la reputación, en la ventaja competitiva o en la capacidad de operación

– Brechas regulatorias, de salud o seguridad

– Exposición política


http://learnitilv3.blogspot.com/2012/03/more-on-it-service-continuity.html

Procesos









Gestión de la Seguridad

• Alcance – Alinear la seguridad de TI con la seguridad del negocio – Asegurar que la seguridad de la información es eficientemente

gestionada para todos los servicios y para la actividades de gestión de servicio

– ISM necesita ser considerado dentro de todo el marco de gobernabilidad corporativa, para los siguiente: • Proveer la dirección estratégica para las actividades de seguridad • Asegurar que los objetivos son logrados • Asegurar que el riesgo de la seguridad de la información está apropiadamente

manejada • Asegurar que los recursos de información corporativo son usados

responsablemente

– Propósito de ISM: poner foco en todos los aspectos de la seguridad de TI y en el manejo de todas las actividades de la seguridad de TI


• La Triada de la Seguridad de la Información

–Confidencialidad

• Los componentes del sistema serán accesibles sólo por aquellos usuarios autorizados.

–Integridad

• Los componentes del sistema sólo pueden ser creados y modificados por los usuarios autorizados.

–Disponibilidad • Los usuarios deben tener disponibles todos los componentes

del sistema cuando así lo deseen.


• Política de Seguridad de la Información

– Debe incluir:

• Política de control de accesos

• Política de control de contraseñas

• Política de uso de Internet

• Política de antivirus

• Otras políticas relevantes para la organización


• Sistema de Gestión de Seguridad de la Información (ISMS)

– Acorde a las recomendaciones de ISO27001

• Objetivo de ISMS

– Asegurar la protección continua de los servicios existentes y que los nuevos servicios estén en línea con las políticas de seguridad de la empresa


• Conceptos básicos de ISMS: – Incidentes:

• Los incidentes de seguridad no sólo provienen de fallas técnicas sino a menudo causados por errores humanos, fallas en procedimientos y pueden tener implicaciones legales y de bienestar y salud

– Controles: • Los controles deberán ser diseñados para apoyar y reforzar

la Política de Seguridad de la Información

• Es recomendable y más costo efectivo considerar los controles en la fase de diseño del servicio que en el ambiente de producción.


http://ronbpalmer.pbworks.com/f/1217706331/SD-Figure-4_26-Framework-for-Managing-IT-Security.jpg

Procesos









Gestión de Proveedores

• Objetivos – Obtener valor de los proveedores y contratos – Asegurar que los contratos de soporte (UC – Underpinning

Contracts) y los acuerdos con los proveedores están alineados a la cobertura de las necesidades del negocio, a la vez que den soporte y estén alineado con los objetivos acordados en los SLR’s y SLA’s, en conjunto con SLM

– Gestionar la relación con los proveedores – Gestionar el desempeño de los proveedores – Negociar y acordar contratos con proveedores y gestionarlos a

través del ciclo de vida – Mantener la política de proveedores y la Base de Datos de

proveedores y Contratos (SCD – Suppliers and Contract Database).


• Actividades – Evaluación y selección de contratos y proveedores y el mantenimiento

de contratos estándares, términos y condiciones – Desarrollo, negociación y seguimiento de los contratos – Implementación y cumplimiento de las políticas de proveedores – Cumplimiento de las normas, estándares y marcos de referencia de la

compañía contratante y el mantenimiento de la Base de Datos de Contratos y Prooveedores (SCD – Supplier and Contract Database)

– Categorización de contratos y proveedores con la evaluación de riesgo e impacto al negocio

– Implementación y transición de servicio, con revisiones, métricas, renovación y el procedimiento de término de contrato

– Gestión de la resolución de disputas contractuales y del personal – Gestión de los proveedores sub-contratistas – Programa de mejora de servicio (SIP)


• Categorización de Proveedores

Ejercicio 1

¿Cuál de las siguientes es la MEJOR descripción de un Acuerdo de Nivel Operacional (OLA)?

a) Un acuerdo entre un Proveedor de Servicios de TI y otra parte de

la misma organización que apoya la provisión del servicio b) Un acuerdo escrito entre el Proveedor del Servicio de TI y el(los)

Cliente(s) de TI, en el que se definen objetivos claves y responsabilidades por ambas partes

c) Un acuerdo entre dos Proveedores del Servicio respecto al nivel de Servicio que requiere el cliente

d) Un acuerdo entre un Centro de Servicio a Usuarios tercerizado y el cliente de TI sobre los tiempos de reparación y respuesta

Ejercicio 2

¿Cuál es el PRINCIPAL objetivo de la Gestión de la Disponibilidad? a) Monitorizar e informar sobre la disponibilidad de los

servicios y los componentes b) Asegurar que se cumplan todas las metas en los

Acuerdos de Nivel del Servicio (SLA) c) Garantizar los niveles de disponibilidad para los

servicios y los componentes d) Asegurar que la disponibilidad de los servicios sea

igual o exceda las necesidades acordadas del negocio

Ejercicio 3

¿Qué proceso revisa periódicamente los Contratos de Nivel Operacional (OLA)?

a) Gestión de Proveedores

b) Gestión de Niveles del Servicio

c) Gestión del Portafolio de Servicios

d) Gestión de la Demanda

Ejercicio 4

Definir los requisitos funcionales para un nuevo servicio es parte de: a) Operación de Servicio: Gestión de la Aplicación b) Estrategia de Servicio: Gestión de Porfolio de

Servicios c) Diseño de Servicio: Diseñar la arquitectura de la

tecnología d) Diseño de Servicio: Diseñar las soluciones de

servicio

Ejercicio 5

El Paquete de Diseño del Servicio debe detallar todos los aspectos del servicio y sus requerimientos durante las subsiguientes fases de su ciclo de vida. ¿Cuál(es) de los siguientes son elementos válidos? 1. Requerimientos del Negocio acordados y documentados 2. La definición de un servicio para operaciones 3. Requerimientos para procesos nuevos o modificados 4. Métricas para medir el servicio

a) 1 solamente b) 2 y 3 solamente c) 1, 2 y 4 solamente d) Todas

Ejercicio 6

¿Cuál de las siguientes actividades es responsabilidad de la Gestión del Nivel de Servicio (SLM)? a) Diseñar el sistema de Gestión de Configuración desde

una perspectiva de negocio b) Creación de métricas tecnológicas para alinearse con

las necesidades del cliente c) Discutir los logros de servicio con los clientes d) Formación del personal del Centro de Servicio al

Usuario en cómo tratar las quejas de los clientes acerca del servicio de TI

Ejercicio 7

¿Cuál de los siguientes debería ser parte del contenido en un Catálogo de Servicios?

a) La información de versiones de todo el software

b) La estructura organizacional de la compañía

c) Información sobre los activos

d) Detalles de todos los servicios operacionales

Ejercicio 8

¿Cuál de los siguientes describe mejor las Cuatro P’s del Diseño del Servicio? a) Un proceso para el diseño de servicios efectivos b) Los aspectos de Planificación, Perspectiva,

Posicionamiento y Personas en el Diseño del Servicio c) Preguntas que deben hacerse cuando se revisan las

especificaciones del diseño d) Las Personas, Socios, Productos y elementos de

Procesos que deben considerarse en el diseño de los servicios

Agenda

• Introducción






• Mejora Continua

Transición de Servicio

• Alcance – Incorporar los requerimientos de Diseño y Operación en los planes de

Transición – Gestionar la planificación de Transición y sus actividades de soporte – Mantener e integrar los planes de Transición de Servicio con el/los

portafolios de clientes, servicios y contratos – Gestionar el progreso, los cambios, problemas, riesgos y desviaciones

que ocurran durante la Transición de Servicio – Realizar revisiones de calidad para todos los planes de Transición,

Despliegue e Implementación de Servicios – Gestionar y operar los procesos, sistemas de apoyo y herramientas de

la Transición de Servicio – Comunicación con clientes, usuarios e interesados (stakeholders) – Monitorear y mejorar el desempeño de la Transición de Servicios

Transición de Servicio

• Valor al Negocio – Habilidad de manejar un mayor número de cambios sin que

tenga un impacto adverso en la calidad del servicio – Habilidad de reaccionar más rápidamente ante las necesidades

de cambio requeridos por el negocio – Mejora en la tasa de éxito de cambios y versiones – Mejorar las posibilidades de predecir los niveles de servicios y

las garantías respecto a nuevos y modificados servicios – Mejores estimaciones de presupuestos y planificación de

recursos – Mayor cumplimiento de estándares y normas – Mayor entendimiento del nivel de riesgo durante y después de

los cambios de versiones

Procesos

• Planificación y Soporte de Transición

• Gestión de Activos y Configuración

• Gestión de Cambio

• Gestión de Liberación y Despliegue

• Gestión de Conocimiento

Planificación y Soporte de Transición

• Propósito

– El propósito de la planificación y soporte es proveer una planificación completa de la transición de servicios y coordinar los recursos necesarios para su ejecución.


• Objetivos – Planificar y coordinar los recursos para asegurar que los

requerimientos de la estrategia, materializados en el diseño son efectivamente transicionados a la operación.

– Coordinar las actividades a través de los proyectos , proveedores y equipos de trabajo.

– Asegurar que todas las partes involucradas adoptan el marco de trabajo común y sus procesos son re-utilizados para mejorar la efectividad y eficiencia de la planificación integrada.

– Proveer planes claros que permitan de manera fácil su implementación durante la transición.

– Identificar, gestionar y controlar los riesgos para minimizar la posibilidad de falla o interrupción de servicios durante la transición, asegurando que cualquier hallazgo sea reportado al stakeholder apropiado.

– Monitorear y mejorar el desempeño de la transición.


• Alcance – Mantener las políticas, estándares y modelos de las actividades

de transición de servicios – Guiar cada cambio mayor o nuevo servicio a través de todos los

procesos del ciclo de transición – Coordinar los esfuerzos necesarios para ejecutar múltiples

transiciones al mismo tiempo. – Priorizar los requerimientos y recursos para las transiciones de

servicios – Revisar y mejorar el desempeño de las actividades de

planificación y soporte. – Asegurar que la transición de servicios esta debidamente

coordinada a través de la gestión de programas y proyectos.


• No es parte del Alcance

– La construcción, pruebas y despliegue de cambios individuales. Estas actividades se ejecutan a través de:

• Gestión de Cambios y

• Gestión de Liberación y Despliegue.

Procesos






Gestión de Activos y Configuración

• Objetivos

– Proporcionar información precisa sobre la configuración de los Servicios para apoyar en la toma de decisiones

– Minimizar la falta de calidad y cumplimiento causado por activos de Servicio y configuración erróneos.

– Optimizar los activos de Servicio, configuraciones, capacidades y recursos.


• Principales Beneficios

– Evaluar el impacto y la causa de incidentes y problemas

– Evaluar el impacto de cambios propuestos

– Planificar y diseñar servicios nuevos o cambiados

– Planificar la renovación tecnológica y las actualizaciones de SW

– Planificar el despliegue de versiones, migraciones de activos de servicios

– Optimizar la utilización de activos


• Elemento o ítem de Configuración (CI)

– Componentes que deben ser gestionados para entregar un servicio de TI

– Cualquier activo, componente de servicio o ítem que esta bajo el dominio de Gestión de Configuración

– No existe un límite o tamaño de Cl, pueden variar mucho en complejidad, tamaño y tipo, desde un sistema completo a un componente de hardware menor.


• Todo CI debe tener un dueño, ser gestionado y trazable a través del ciclo de vida

• Atributos de un CI

– Los atributos describen las características de un CI que es valioso conocer y mantener en los registros y que apoyará a la SACM y al ITSM.

– El plan de SACM menciona la información de configuración y arquitectura de datos. Esto incluye los atributos a ser grabados por cada tipo de Activo o CI.


• Los atributos de un CI generalmente incluyen – Identificador Único – Tipo de CI – Nombre/descripción – Versión (Ej.: Compilado nº, línea base, release) – Ubicación – Estado – Datos históricos (Ej.: auditorias) – Tipo de relaciones – SLA’s que afectan

• Estos atributos definirán características físicas y funcionales de cada tipo de Activo o CI. Ej.: Tamaño o capacidad, junto con documentación y especificaciones.


• Tipos de CI

– CI de Ciclo de Vida del Servicio

• Caso de Negocio, Paquetes de Diseño del Servicio, Planes de Prueba

– CI del Servicio

• Activos de la capacidad del servicio: gestión, organización, procesos, conocimiento, personas

• Activos de los recursos del servicio: capital financiero, sistemas, aplicaciones, infraestructura e instalaciones, personas


• Tipos de CI

– CI de la Organización

• Estrategia de Negocio, Políticas, Requerimientos regulatorios

• CI interno: Activos tangibles o intangibles que se requieren para entregar y mantener el servicio

– CI externo

• Servicios subcontratados


• Modelo Lógico

– La Gestión de la Configuración entrega un modelo lógico de los servicios, activos e infraestructura al registrar las relaciones entre los CI’s.

– El verdadero poder del modelo lógico de servicios e infraestructura de la Gestión de la Configuración es que se transforma en “El Modelo” – Una única representación que es utilizada/accedida por todos los grupos de TI y otros grupos, como Recursos Humanos, finanzas, proveedores e incluso clientes.


• Modelo Lógico


• Relaciones (1/2) – Las relaciones describen como los CI’s trabajan juntos para

proveer servicios. Estas relaciones están contenidas en la CMS. – Las relaciones entre CI’s son mantenidas para dar información

de las dependencias. Por ejemplo: • Un CI es parte de otro CI, ej.: un módulo de software es parte de un

programa; un servidor es parte de un centro de datos – Esto se conoce como una relación “padre-hijo”.

• Un CI esta conectado a otro CI, ej.: un computador esta conectado a la red LAN.

• Un CI usa otro CI, ej.: un programa usa un módulo de otro programa; Un servicio de negocio usa un servidor de la infraestructura.

• Un CI esta instalado en otro, ej.: MS Project está instalado en un computador.


• Relaciones (2/2)

– Aunque un CI ‘hijo’ debería ser ’controlado’ por un CI ‘padre’, puede ser ‘usado por’ muchos otros CI’s.

– Las relaciones son también un mecanismo para asociar RFC’s, registro de incidentes, registro de problemas, errores conocidos con los servicios e infraestructura de TI a los cuales hacen referencia.


• Base de Datos de Gestión de Configuraciones (CMDB) – Una base de datos que se utiliza para administrar los

Registros de Configuraciones a lo largo de su Ciclo de Vida

– Registra los atributos de todos los CI’s y las relaciones con otros CI’s

– Puede contener información vinculada al CI, por ejemplo Incidentes, Problemas o Cambios

• La Gestión de Configuraciones brinda mantenimiento a la CMDB


• Sistema de Gestión de Configuraciones (CMS)

– Conserva toda la información de los CI’s dentro del alcance designado

– Mantiene las relaciones entre todos los componentes del Servicio y cualquier registro/documentación relacionado con la Gestión de Servicios

– La información sigue la estructura del modelo DIKW


• Biblioteca Definitiva de Medios (DML) – Es la biblioteca segura en donde las versiones definitivas

autorizadas de todos los CI’s de medios son almacenados y protegidos.

– Acá se mantienen las copias maestras de las versiones que han pasado las revisiones de calidad y las que componen el software de la organización.

– Esta biblioteca puede estar compuesta por una o más librerías de software o áreas de almacenamientos de archivos, separadas por áreas de desarrollo, pruebas o archivos activos.

– Debe almacenar además toda la información relacionada al licenciamiento.

– Almacena copias maestras de la documentación


• Biblioteca Definitiva de Medios (DML)

– Es un repositorio físico y lógico


• Línea base de Configuraciones (Base Line)

– Configuraciones de cada servicio, producto o infraestructura

– Revisado y acordado formalmente

– Base para actividades futuras como auditoria, construcción, vueltas atrás, mediciones de mejora

– Captura la estructura, contenido y detalles de la configuración y representa un conjunto de CI’s que están relacionados entre ellos.

Procesos






Gestión de Cambio

• Meta – Responder a los requerimientos cambiantes del negocio y

los clientes, maximizando el valor y reduciendo incidentes, interrupciones y re-trabajos (implementaciones exitosas)

– Responder a los requerimientos de cambios del negocio y de TI que alinearan los servicios con las necesidades del negocio.

• Objetivo – Asegurar que los cambios son registrados, evaluados,

autorizados, priorizados, planeados, probados, implementados, documentados y revisados de manera controlada.

Gestión de Cambio

• Alcance

– Cubrir todos los cambios que afectan a los elementos (Activos e Ítems de Configuración) que componen la línea base de los servicios, a través de todo su ciclo de vida.

– El proceso debe utilizar métodos estandarizados para manejar los cambios, los cuales deben ser registrados en el Sistema de Gestión de Configuración (CMS - Configuration Management System), optimizando la gestión del riesgo para el negocio.

Gestión de Cambio

• Alcance

– Cada organización debe definir qué cambios están fuera del alcance del proceso de cambios de servicio. Típicamente estos pueden incluir:

• Cambios con impactos más amplios y significativos que solo cambios de servicio (Ej.: cambios en organizaciones departamentales, políticas y operaciones de negocio)

• Cambios a nivel operacional como la reparación de impresoras o componentes de manera rutinaria.

Gestión de Cambio

• RFC (Request for change) – Propuesta formal para que se realice un Cambio. Incluye detalles del

Cambio propuesto, y puede registrarse en papel o electrónicamente.

• Tipos de Cambios – Cambios Normales

• Específicos a servicios ya existentes en la organización

– Cambios estándares • Categoría pre-aprobada, bajo impacto y bajo riesgo • Procedimientos existentes, preestablecidos y controlados

– Cambio de Emergencias • Cambio para resolver un incidente de alto impacto, reparar un error o una falla

en un servicio de TI que tiene un impacto significativo en el negocio • Existe un procedimiento específico de cambios establecido en momentos de

emergencia

Gestión de Cambio

• Modelo de proceso de cambio debe incluir:

– Procedimientos de cambio (Pasos que deben ser ejecutados para gestionar el cambio, incluyendo los incidentes o eventos inesperados)

– Roles y Responsabilidades

– Tiempos comprometidos y umbrales para completar de acciones de cambio

– Procedimiento de escalamiento

Gestión de Cambio

• Roles del proceso – Comité de Cambio - Change Advisory Board (CAB)

• Apoyo al Gestor de Cambio

• Consultado cuando los cambios son significativos

• Grupo multidisciplinario (Técnico, finanzas, continuidad, proveedores)

– Comité de Cambio de Emergencia (ECAB – CAB/EC) • Subgrupo del CAB

• Convocatoria dependiente del tipo de cambio (sólo emergencia)

• Toma de decisión en corto tiempo

Gestión de Cambio

• Categorización del Riesgo

– La posibilidad de “riesgo al negocio” de cualquier cambio debe ser considerado antes de dar cualquier autorización.

– Se puede utilizar una matriz para realizar esta categorización y, de acuerdo a su resultado, conocer el nivel de impacto del cambio y obtener las autorizaciones requeridas para su implementación.

Gestión de Cambio

• Categorización del Riesgo

Gestión de Cambio

• Propuesta de Cambio (RFC) – Las propuestas de cambio deben ser solicitadas e ingresadas antes de

ser formalmente aprobadas para asegurar que los potenciales conflictos están bien identificados.

– Una propuesta de cambio aprobada no implica una aprobación de implementación cambio. Simplemente permite que el servicio sea aprobado formalmente para que la actividad de diseño pueda iniciar.

– Una propuesta de cambio usualmente se utiliza para comunicar las implicancias del cambio. Este usualmente incluye: • Una descripción de alto nivel del cambio (nuevo, cambiado o retirado)

incluyendo los resultados de negocio esperados, como será soportado y la utilidad y garantía a ser provista.

• Un caso de negocio completo incluyendo riesgos, posibles desviaciones y sus alternativas, así como también el presupuesto y expectativas financieras.

• Una propuesta de planificación de diseño e implementación del cambio.

Gestión de Cambio

• Remediación

– Acciones que se toman para recuperar después de una falla en un cambio o despliegue.

– Puede incluir:

• invocación de «vuelta-atrás»

• planes de continuidad de servicios u otras acciones diseñadas para asegurar al negocio su funcionamiento.

Gestión de Cambio

• Las 7 R’s (se utilizan para analizar eficazmente un Cambio) – ¿Quién REQUIERE el Cambio? – ¿Cuál es la RAZON del Cambio? – ¿Cuál es el RESULTADO que se requiere del Cambio? – ¿Cuáles son los RIESGOS involucrados en el Cambio? – ¿Qué RECURSOS se requieren para entregar el

Cambio? – ¿Quién es el RESPONSABLE de la creación, prueba e

implementación del Cambio? – ¿Cuál es la RELACIÓN entre Cambio y otros Cambios?

Gestión de Cambio

• Actividades

Procesos






Gestión de Liberación y Despliegue

• Valor para el Negocio – Entregar cambios de versiones más rápidamente a un

costo razonable y con un riesgo mínimo

– Asegurar a los clientes y usuarios que pueden ocupar un servicio nuevo (o modificado) con tranquilidad y soportar las metas del negocio

– Mejorar la constancia de las implementaciones nuevas o por cambios de versiones

– Contribuir al cumplimiento de las observaciones de auditoria con versiones que son trazables a través del ciclo de vida del servicio


• Unidad de Versiones

– La porción de un servicio o de una la infraestructura que se despliega normalmente junta, de acuerdo a la política de versiones de la organización.

– Habitualmente incluye los componentes suficientes para realizar una función.

– Se debe considerar:

• Cantidad y facilidad de los cambios requeridos para el despliegue

• Recursos necesarios para construir, probar y poner en producción una nueva o cambiada versión

• Complejidad de las interfaces


• Opciones de despliegue – Big Bang v/s Phased Approach

• Despliegue “todo de una sola vez” v/s “por fase”

– Automatizado v/s Manual

– Paquetes de versiones

• Versiones simples o varias versiones en conjunto

• Puede incluir HW, SW, documentación, etc.

• Ejemplo: – Despliegue Por Fase


• Política de despliegue – Define la guía para implementar uno o más servicios, lo

que debería incluir: • La identificación única y nomenclatura de numeración de versiones y

convención de nombres para los diferentes tipos de despliegue y su descripción.

• Los roles y responsabilidades para cada etapa en el despliegue.

• Los requerimientos que necesiten CI’s de la DML.

• La frecuencia esperada por cada tipo de despliegue.

• La forma de aceptar y agrupar cambios en el despliegue.

• Criterios y autorización para ingresar en la operación y ser soportado por sus funciones


• Las 4 fases del despliegue – Planificación de liberación y despliegue

• Esta fase comienza con la autorización de cambio requerida para crear el plan de liberación y despliegue y finaliza con la aprobación del plan por parte de la Gestión de cambio.

– Construcción y prueba • El paquete a ser liberado se construye, prueba y registra en la DML. Esta fase

comienza con la aprobación de Gestión de cambio para construir el paquete y finaliza con la aprobación de Gestión de cambio para el paquete a ser liberado y registrado en la DML aprobado por Gestión de Activos y configuración. Esta etapa es única por cada despliegue.

– Despliegue • Se implementa en la operación el paquete. Esta fase inicia con la Gestión de

cambios aprobando la puesta en operación y finaliza con el paso a las funciones de la Operación de Servicio. Pueden haber varias fases de despliegue separadas dependiendo de la planificación de las opciones de despliegue utilizadas.

– Revisión y cierre • Se toma la retroalimentación y experiencia del proceso. El desempeño y sus logros

deben ser revisados y tomar las lecciones aprendidas.


• Modelo de Servicio V (V Model Service) – Modelo usado para representar los diferentes niveles de configuración

que serán construidos y probados para entregar la capacidad del servicio.

– Muestra como la validación y aceptación de servicio deberá comenzar con la definición del requerimiento del servicio. • Lado izquierdo representa la especificación de los requerimientos de servicio

hacia el Diseño del servicio

• Lado derecho hace enfoque en las actividades de validación y pruebas que son

desempeñados contra los que sean definidos al lado izquierdo

– En cada paso del lado izquierdo corresponde una acción y un

involucramiento directo paralelo del lado derecho

Procesos






Gestión de Conocimiento

• Alcance – La entrega de la información correcta al lugar adecuado para facilitar

la toma de decisiones de la organización

• Objetivos

– Proveer información adecuada de servicios disponibles – Obtener servicios más eficientes y de mayor calidad – Contribuir a una reducción de costos y aumento en la satisfacción de

clientes

• Meta

– Mejorar la capacidad del negocio para tomar mejores decisiones a través de contar con información más confiable en todas las fases del ciclo de vida de servicio.


• Modelo DIKW – Data

• Set de hechos discretos respecto a eventos, los que se encuentran en bases de datos estructuradas debido a la forma que se capturan (de manera continua y automática)

– Information (Información)

• La provisión de contexto a la data • Se encuentra en contenidos semi-estructurados como email, documentos de texto y

multimedia

– Knowledge (Conocimiento)

• Corresponde a experiencias, ideas, pensamientos, valores y juicios individuales • Se obtiene con experiencias propias, del equipo y análisis de información y data

– Wisdom (Sabiduría)

• Es lo máximo en discernimiento del material y la aplicación de contexto y reconocimiento de la necesidad de proporcionar además de análisis, buen juicio y sentido común


• Modelo DIKW

http://www.forsythe.com/na/aboutus/news/articles/ImplementingKMPartIConceptsApproach


• Sistema de Gestión de Conocimiento (SKMS) – Enfoque en conocimiento de los datos de la organización

– Apoyo para la toma de decisiones

– Fuente de datos desde la CMBD hacia la CMS y desde ahí hacia la SKMS


• Sistema de Gestión de Conocimiento (SKMS)

http://www.edocms.ca/directories/ITIL/Summary-Notes.html

Ejercicio 1

El alcance de la Gestión de Cambios incluye cambios a los servicios y a otros Elementos de la Configuración (CI) a través de todo el Ciclo de Vida del Servicio.

¿Qué tipo de cambios usualmente NO se incluyen dentro del alcance de la Gestión de Cambios?

a) Cambios en un equipo mainframe

b) Cambios a Operaciones del Negocio

c) Cambios a un Acuerdo de Nivel de Servicio (SLA)

d) El retiro de un servicio

Ejercicio 2

¿Qué proceso es responsable de registrar las relaciones entre los componentes del servicio?

a) Gestión de Niveles de Servicio

b) Gestión del Portafolio de Servicios

c) Gestión de la Configuración y Activos de Servicios

d) Gestión de Incidentes

Ejercicio 3

¿Cuál de las siguientes es una actividad del proceso de Gestión de la Configuración y Activos de Servicios?

a) Contabilizar todos los activos financieros de la organización

b) Especificar los atributos relevantes de cada Elemento de Configuración (CI)

c) Construir modelos de servicio para justificar implantaciones de ITIL

d) Implantar ITIL en la organización

Ejercicio 4

• ¿Cuál(es) de los siguientes se almacenaría en la Biblioteca Definitiva de Medios (DML)? 1. Copias de software que se ha comprado 2. Copias de software desarrollado internamente 3. Documentación relevante de las licencias 4. La Agenda de Cambios

a) Todos b) Sólo 1 y 2 c) Sólo 2, 3 y 4 d) Sólo 1, 2 y 3

Ejercicio 5

¿Cuáles de las siguientes opciones corresponden a objetivos del proceso de Gestión de Liberación y Despliegue?

1. Asegurar la existencia de planes claros de Liberación y Despliegue 2. Asegurar que los Clientes están satisfechos con las prácticas y

productos de la Transición del Servicio 3. Asegurar que haya un mínimo de impacto no previsto hacia los

servicios en producción, operaciones y soporte 4. Proporcionar una capacidad de TI justificada en su costo que esté

alineado con las necesidades de la empresa

a) Sólo 1, 2 y 3 b) Todas c) Sólo 1 y 3 d) Sólo 1, 3 y 4

Ejercicio 6

¿Cuál(es) de los siguientes son ejemplos de herramientas que pueden dar soporte a la fase de Transición del Servicio?

1. Una herramienta para almacenar versiones definitivas de software

2. Una herramienta de flujo de trabajo para gestionar cambios 3. Una herramienta de distribución automatizada de software 4. Herramientas de prueba y validación

a) Sólo 1, 3 y 4 b) Sólo 1, 2 y 3 c) Todas d) Sólo 2, 3 y 4

Ejercicio 7

¿Cuál de las siguientes afirmaciones sobre las relaciones entre el Sistema de Gestión de la Configuración (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS) es CORRECTA?

a) El SKMS es parte del CMS

b) El CMS forma parte del SKMS

c) El CMS y el SKMS son la misma cosa

d) No existe relación entre el CMS y el SKMS

Ejercicio 8

¿Cuál es el rol del Consejo Asesor de Cambios de Emergencia (ECAB)?

a) Asistir al Gestor de Cambios para evitar que Cambios no urgentes sean realizados durante periodos de negocio especialmente volátiles

b) Asistir al Gestor de Cambios implementando Cambios de Emergencia

c) Asistir al Gestor de Cambios en la evaluación de Cambios de Emergencia y decidir si el Cambio debería ser aprobado

d) Asistir al Gestor de Cambios acelerando el Proceso de Cambios de Emergencia para que no haya demoras inaceptables

• Introducción






• Mejora Continua

Agenda

Operación de Servicio

• Meta – Coordinar y ejecutar los procesos requeridos para

proporcionar y gestionar los Servicios de TI de acuerdo a los niveles acordados con los usuarios y clientes del Negocio

• Objetivos – Proveer y gestionar procesos para las operaciones

diarias de los Servicios de TI – Monitorear el desempeño y recopilar datos para

soportar las actividades de mejora y gestión del Servicio

– Cumplir el SLA, OLA y los objetivos del contrato


• Valor al Negocio

– En esta fase es donde se ejecutan y miden los planes, diseños y optimizaciones.

– Desde el punto de vista del cliente, la Operación del Servicio es donde se percibe el valor real.


• Evento

– Es un cambio de estado que es importante para la Gestión de un Elemento de Configuración (CI) o un Servicio.

• Alerta

– Aviso o notificación a la persona con las habilidades apropiadas para atender el evento.


• Incidente

– Es la interrupción no planeada de un Servicio de TI o la reducción en la calidad de un Servicio de TI.

– Falla de un Elemento de Configuración que aún no impacta el Servicio

• Problema

– Causa desconocida de uno o más Incidentes.


• Solicitud de Servicio

– Es la solicitud de información, de asesoramiento o de un Cambio Estándar realizada por los usuarios

– Ejemplos:

• restablecer una contraseña,

• Proporcionar un Servicio de TI estándar a un usuario nuevo

– Por lo general son manejadas por el Service Desk


• Impacto – Medida del efecto de un Incidente, Solicitud de

Servicio, Problema o Cambio en los procesos del Negocio. Por lo general se basa en cómo se verán afectados los niveles de servicio.

• Urgencia – Velocidad relativa que requiere el negocio para la

resolución de un Incidente, Solicitud de Servicio, Problema o Cambio.

– Medida de tiempo que transcurre para que haya una afectación considerable sobre el negocio.


• Prioridad

– Identifica la importancia relativa de un Incidente, Solicitud de Servicio, Problema o Cambio.

– Deriva del Impacto y la Urgencia asociados y se usa para identificar el tiempo que se requiere para emprender acciones.


• Ejemplo de Matriz de Prioridad

http://servicetonic.wordpress.com/2012/01/23/prioridad-basada-en-impacto-y-urgencia/


• Solución Temporal (Workaround)

– Técnica que reduce o elimina el Impacto de un Incidente o Problema para el cual no hay disponible una solución definitiva.

– Ejemplos:

• Reinicio de un Elemento de Configuración que falló.

• Re-enrutamiento de la carga de trabajo.


• Error Conocido

– Un Problema tiene documentadas su causa raíz y una solución temporal

– Son creados y administrados por la Gestión de Problemas


• Base de Datos de Errores Conocidos (KEDB)

– Almacena el conocimiento generado de los Incidentes y Problema, y cómo se pueden resolver, para permitir un diagnóstico y resolución rápidos en caso de que ocurran de nuevo

– Creada por Gestión de Problemas

– Usada por Gestión de Incidentes y Problemas

Procesos

• Gestión de Eventos

• Gestión del Incidentes

• Cumplimiento de Solicitudes

• Gestión de Problemas

• Gestión de Accesos

Gestión de Eventos

• Objetivos

– Detectar Eventos, comprenderlos y determinar la acción de control correspondiente.

– Monitorear Servicios de TI y detectar cuando el desempeño cae por debajo de límites aceptables.

• Tipos de Eventos

– Operación regular: no requiere una acción correctiva

– Operación inusual, pero no excepcional (advertencia)

– Una excepción (error)

Procesos






Gestión de Incidentes

• Objetivo – Restablecer la operación normal del Servicio lo más

rápido posible – Minimizar el impacto negativo en la operación del

negocio – Mantener los niveles óptimos de calidad y

disponibilidad del servicio

• Alcance – Cualquier evento que interrumpe o puede interrumpir

un servicio – No todos los eventos son Incidentes


• Modelo de Incidentes

– Método acordado de pasos predefinidos para manejar un Incidente

– Asegura el manejo de Incidentes estándares a través de un camino predefinido

• Orden cronológico de los pasos

• Responsabilidades (quién debe hacer qué, escalas de tiempo y umbrales para la conclusión de las acciones)

• Procedimientos de escalamiento


• Escalas de tiempo

– Debe ser acordado para todas las etapas del manejo de Incidentes

• Basadas en objetivos de respuesta y resolución (SLA, OLA)

• Se pueden utilizar Herramientas para automatizar las escalas de tiempo y el escalamiento

• Los grupos de soporte deben ser informados


• Incidentes Mayores (Graves)

– Escalas de tiempo más cortas y mayor urgencia

– Considera procedimientos independientes

– Incidente con mayor impacto o prioridad por su potencial impacto al negocio


• Actividades y relación con otros procesos

Procesos






Cumplimiento de Solicitudes

• Objetivos

– Proveer un canal para solicitar y recibir servicios estándares

– Proveer información sobre disponibilidad y procedimientos de obtención de servicios

– Fuente y entrega de componentes de los servicios requeridos (Ej.: Licencias)

– Procesar requerimientos de servicio

Cumplimiento de Solicitudes

• Modelo de Solicitud

– Pasos predefinidos para resolver una solicitud (similar a los modelos de incidentes)

– Se pueden utilizar herramientas para gestionar la Solicitud. De esta forma se asegura que las solicitudes estándares se manejan de acuerdo a una ruta predefinida y dentro de escalas de tiempo definidas

Procesos






Gestión de Problemas

• Objetivos

– Buscar la causa raíz de uno o más incidentes

– Gestionar ciclo de vida todos los problemas

– Eliminar incidentes recurrentes

– Minimizar el Impacto de los Incidentes que no se pueden evitar


• Modelo de Problema

– Los Incidentes pueden ocurrir debido a problemas subyacentes

– Creando registros de Error Conocido en la KEDB asegura diagnósticos más rápidos

– Similar al modelo de incidentes


• Actúa Reactivamente cuando se abre un problema a partir de la ocurrencia de un Incidente

• Actúa Proactivamente cuando barre base de incidentes recurrentes


• Actividades y relación con otros procesos

Procesos






Gestión de Accesos

• Objetivos

– Proveer los derechos de usuario para permitir el uso de un servicio o un grupo de servicios

– Consiste en la ejecución de las políticas y acciones definidas en la Gestión de Seguridad y de la Disponibilidad

Gestión de Accesos

• Acceso

– Nivel y grado de funcionalidad o datos que el usuario puede utilizar

• Identidad

– Información única que distingue a un individuo y que verifica su estado dentro de la Organización

• Derechos (privilegios)

– Ajustes exactos para permitir el acceso

Gestión de Accesos

• Servicios o Grupos de Servicios

– La mayoría de los usuarios no sólo utiliza un Servicio y los usuarios que realizan un conjunto de actividades similares utilizarán un conjunto de Servicios similares. Es más eficiente poder otorgar acceso al mismo tiempo a cada usuario o grupo de usuarios al conjunto completo de Servicios que tienen derecho a utilizar

Funciones

Service Desk

• Unidad funcional conformada por personal dedicado al manejo de diversos requerimientos de servicio, que se reciben vía telefónica, por Web o a través de eventos automáticos

• Constituye el Punto Único de Contacto (SPOC) para los usuarios.

• Se encarga de manejar todos los Incidentes y Solicitudes de Servicio

• La propiedad de todos los Incidentes (no del proceso como tal) permanece en el Service Desk

Service Desk

• Objetivos

– Restaurar el servicio normal

– Registrar todos los requerimientos

– Ser la primera línea de soporte

– Resolver incidentes

– Escalar

– Mantener informados a los usuarios

– Cerrar todos los requerimientos resueltos

Service Desk

• Ideal para compañías con una sola ubicación física • Múltiples “Service Desk Locales” pueden causar

inconvenientes: – Duplicación de recursos – Dificultades de consistencia – Falta de métricas consolidadas

Service Desk

• Mejora el uso de los recursos • Reduce los costos de operación • Consistencia en el servicio • Métricas útiles • Mejora la disponibilidad de los recursos

Service Desk

Gestión Técnica

• Objetivos – Asistir en la planificación, implementación y

mantenimiento de una estructura estable a través de: • Topología técnica bien diseñada (tolerante a fallas, rentable) • Uso adecuado de habilidades técnicas • Uso rápido de la habilidad técnica

– Conocimiento y especialización técnica • Provee recursos para soportar el ciclo de vida de la gestión

del servicio

– Asegurar un equilibrio en el nivel de habilidades, utilización y costos • Provee los consejos a Operaciones sobre cuál es la mejor

manera de realizar las operaciones de tecnología

Gestión de Aplicaciones

• Objetivos – Ser responsable de la gestión de aplicaciones a

través del ciclo de vida

– Diseñar, testear y mejorar las aplicaciones que forman parte de un servicio

– Custodiar el conocimiento técnico y la habilidades relacionadas a la gestión de aplicaciones

– Asegurar que la organización acceda a los recursos adecuados para satisfacer las necesidades del negocio.

Gestión de Operaciones de TI

• Objetivo

– Ejecutar las actividades diarias requeridas para gestionar y mantener la infraestructura de TI para la entrega y soporte de los servicios según los niveles acordados.


• Control de operaciones

– Subconjunto encargado de la ejecución y monitoreo de las actividades y eventos de la infraestructura TI, incluye:

• Gestión de Consola

• Programación de trabajo

• Respaldo y recuperación

• Impresión

• Mantenimiento en nombre de la Gestión Técnica y de Aplicaciones


• Gestión de Instalaciones

– Subconjunto encargado del entorno físico de TI (Ej.: equipos de enfriamiento, de energía, datacenter, sitios de recuperación)

– Incluye la coordinación de proyectos de consolidación de centros de datos o de servidores.

Comunicación en la Operación del Servicio

• Se necesita una excelente comunicación entre las Áreas de TI con usuarios, clientes y entre los equipos de Operación del Servicio

• Esta comunicación incluye: – Equipos de Estrategia, Diseño, Transición y Operación

del Servicio – El día a día – Entre turnos – Reportes de desempeño – Proyectos – Relacionado con cambios, excepciones y emergencias

• Introducción






• Mejora Continua

Agenda

Mejora Continua

• Propósito

– Alinear los Servicios de TI con las necesidades cambiantes del negocio mediante la identificación e implementación de mejoras a los Servicios de TI que soportan los procesos de negocio

Mejora Continua

• Objetivos – Recomendar mejoras en cada etapa del ciclo de vida – Revisión y análisis de los logros de nivel de servicio – Mejorar la calidad del Servicio de TI, la eficiencia y

efectividad de los procesos – Mejorar la efectividad de costos sin sacrificar la

satisfacción del cliente – Garantizar la utilización de métodos de gestión de calidad

aplicables – Garantizar los objetivos y las mediciones claras del proceso – Comprender las métricas y como deben ser los resultados

positivos

Mejora Continua

• Alcance – La salud general de ITSM como disciplina

– La alineación continua del portafolio de servicios con las necesidades del negocio actuales y futuras

– La madurez y la capacidad de la organización, gestión, procesos y personas utilizadas por los servicios

– La mejora continua de todos los aspectos de los servicios de TI y los activos del servicio que los apoyan

Mejora Continua

• Valor al Negocio – Mejora continua, justificable y gradual, en la calidad

del servicio – Alineación continua entre los servicios de TI y los

requerimientos del negocio – Mejoras graduales en la rentabilidad – Oportunidades de mejora identificadas en todas las

fases del ciclo de vida y los procesos – Oportunidades de mejora identificadas en las

estructuras organizacionales, las capacidades de recursos, socios, tecnología, habilidades y capacitación del personal y las comunicaciones

Mejora Continua

• No se puede mejorar aquello que no se conoce y no se puede llegar realmente a conocer aquello que no se puede medir.

• Es indispensable que la organización TI defina una serie de métricas que permitan determinar si se han alcanzado los objetivos propuestos así como la calidad y rendimiento de los procesos y tareas involucrados.

Mejora Continua

• Métricas – Tecnológicas

• Miden la capacidad, disponibilidad y rendimiento de las infraestructuras y aplicaciones

– De Procesos • Miden el rendimiento y calidad de los procesos de

gestión de servicios TI

– De Servicio • Evalúan los servicios ofrecidos de punta a punta, en

términos de sus componentes individuales

Mejora Continua

• Línea de Base – Establecer un punto de partida

• Para determinar si un servicio o proceso debe ser mejorado • Para su posterior comparación

– Debe ser documentado, reconocido y aceptado

• Registro CSI – Una lista clara y priorizada que proporcionar una

visión coordinada y coherente de las oportunidades de mejora

– Parte del Sistema de Gestión de Conocimiento de Servicio (SKMS)

Mejora Continua

• Ciclo de Deming

Mejora Continua

• Enfoque de CSI

Mejora Continua

• Modelo de Mejora de los 7 pasos – Propósito

• Definir y gestionar los pasos necesarios para mejoras

– Objetivos • Identificar oportunidades de mejora

• Reducir el costo de proveer servicios

• Garantizar los servicios de TI que permiten alcanzar los resultados de negocio

• Identificar mediciones para establecer las oportunidades de mejora

• Asegurar que los logros de servicio se adaptan a los requerimientos de negocio

Mejora Continua

• Modelo de Mejora de los 7 pasos – Alcance

• Desempeño y capacidad de los servicios, procesos, socios y tecnología

• Alineación continua del portafolio de servicios de TI con las necesidades actuales y futuras del negocio

• Aprovechar al máximo el uso de la tecnología que posee el negocio

• La explotación de nuevas tecnologías

• Adecuada asignación de roles con el fin de aprovechar los conocimientos técnicos y capacidades dentro de la organización

Mejora Continua

• Modelo de Mejora de los 7 pasos

– e

–

Fundamentos de ITIL - Entel v1 3 - versión impresión

Documents

Transcript of Fundamentos de ITIL - Entel v1 3 - versión impresión