Transicion del servicio

1. Transición del servicio
Módulo 4

2. INDICE
¿En qué consiste?
Modelo en V del Servicio
Procesos incluidos en la Transición
Gestión de cambios
Puntos clave en el proceso
Las 7 R de la gestión de cambios
¿Qué es una RFC?
Modelos de Cambio
Tipos de Cambio
PIR, CAB, ECAB y Agenda de cambios
Tipos de aprobación
Gestión de la Configuración y Activos del Servicio
Puntos clave en el proceso
¿Cómo sé que es un CI?
¿Para qué sirve la CMDB?
Línea Base
Biblioteca definitiva de medios DML
Sistema de gestión de la configuración
www.itenea.com

3. INDICE
Gestión de Versiones y de Despliegues
Política de versiones y unidad de release
Pruebas y tipos de despliegues
Gestión del Conocimiento
Sistema de Gestión del Conocimiento del Servicio
SKMS
Relación entre los sistemas SKMS y CMS
Jerarquía DKIW
www.itenea.com

4. ¿En qué consiste?
“Es una guía para la planificación y gestión de recursos
requeridos para establecer con éxito un servicio nuevo o
cambiado en el entorno de producción dentro de coste, calidad
y tiempo estimado”
• Es el puente entre el diseño de los servicios y su operación
diaria: básicamente Gestión de Configuración, de Lanzamientos y
de Cambios, apoyado por procesos adicionales
Estrategia del Servicio Diseño del Servicio Transición del Servicio
Ha definido el marco general Ha diseñado en detalle los Ahora hay que pasarlos a
para establecer servicios servicios Producción…
www.itenea.com

5. ¿En qué consiste?
¿Y esto qué valor proporciona al negocio?
– Capacidad de adaptación rápida a los nuevos requerimientos y desarrollos del
mercado
– Gestión de transición de fusiones, separaciones, adquisiciones y transferencias de
servicios entre compañías
– Predicciones de niveles de servicio y garantías para servicios nuevos y modificados
– Productividad de negocio y personal de cliente gracias a una mejor planificación y
uso de servicios
– Entendimiento de los niveles de riesgos durante el lanzamiento de cambios
www.itenea.com

6. Modelo en V del Servicio
ITIL v3 rescata este modelo. Garantiza que existe una colección de pruebas para cada fase de la construcción del
servicio asegurando la calidad del entregable en cada fase. A la izda se representan los requisitos ya la derecha
cómo probarlos.
Definir requisitos Validar Paquetes
NIVEL 1 de negocio del Servicio,
Plan Revisión del Servicio ofertas y contratos
Definir requisitos Prueba de
NIVEL 2 del servicio aceptación del
Plan Aceptación del Servicio servicio
Diseñar la solución Prueba preparación
NIVEL 3 del servicio operacional del
Plan Pruebas Operacionales Servicio servicio
Diseñar la entrega Prueba de paquete
NIVEL 4 del servicio de entrega del
Plan Pruebas Release servicio
Desarrollar la Prueba de
NIVEL 5 solución del componentes y
servicio construcción
Construir y probar
los componentes
del servicio
www.itenea.com

7. Procesos incluidos en la Transición
Planificación y Gestión de Gestión de la Gestión de Validación y Evaluación* Gestión del
soporte a la Configuración y Versiones y pruebas de Conocimiento
transición* Cambios
Activos del Despliegues Servicios*
Servicio
* No se son objeto de los fundamentos de ITIL
www.itenea.com

8. Gestión de Cambios
“Asegura la utilización de procedimientos estandarizados para la
gestión eficiente de todos los cambios, para minimizar su
impacto en la calidad del servicio y mejorar la operación diaria de la
organización”
“Un elevado porcentaje de problemas en IT provienen de
cambios mal implantados”, lanzar una gestión de cambios
probablemente mejorará la operativa general del servicio.
¿Cuál puede ser el origen de un cambio?
– Pueden ser la solución a una incidencia
– Un cambio de procedimiento de operación de un sistema
– Un cambio en un ítem de configuración o CI
– …
en definitiva, un cambio puede provenir de cualquier proceso o
actividad. La propuesta de los mismos no es responsabilidad de este
proceso, únicamente la gestión.
www.itenea.com

9. Gestión de Cambios
Puntos clave en el proceso:
• La gestión de cambios asegura que todos los cambios son
justificados, evaluados, autorizados, probados y revisados.
• Todos los posibles afectados por el cambio lo conocen de
antemano y están de acuerdo
Sin embargo, la gestión de cambios no se responsabiliza de:
• Proponer los cambios que hay que realizar
• Implementar cambios (sólo DIRIGE el proceso, la implantación la
realiza el proceso de Gestión de Versiones y Despliegues)
• Identificar componentes afectados por un cambio (de esto
último se encarga el proceso de la Gestión de la Configuración y
Activos del Servicio que es el que mantiene la CMDB)
www.itenea.com

10. Gestión de Cambios
Las 7 Rs de la Gestión de Cambios
Las siguientes cuestiones han de ser respondidas para todos los
cambios. Sin esta información la evaluación del impacto no se puede
completar:
1. Who RAISED the change? (¿quién eleva el cambio?)
2. What is the REASON for the change? (¿cuál es la razón del cambio?)
3. What is the RETURN required from the change? (¿qué es espera de este cambio?)
4. What are the RISKS involved in the change? (¿cuáles son los riesgos asocidados a este
cambio?)
5. What RESOURCES are required to deliver the change? (¿qué recursos son necesarios
para lanzar el cambio?)
6. Who is RESPONSIBLE for the build, test and implementation of the change? (¿quién
son los responsables de la construcción, pruebas y despliegue del cambio?)
7. What is the RELATIONSHIP between this change and other changes?
(¿cuál es la relación entre este cambio y otros que están pendientes?)
www.itenea.com

11. Gestión de Cambios
¿Qué es una RFC (Request for Change)?
Es el documento o formulario que se emplea para proponer o elevar
un cambio al proceso. Puede estar desencadenado por todo tipo de causas: cambio
de localización física de un CI, cambio de proveedor, nueva legislación, resolución de un
problema…
¿Qué incluye habitualmente?
• Núm. ID RFC • Recomendaciones del CAB
• Descripción de ítems afectados• Fecha y firma de autorización
• Razón del cambio • Fecha prevista implantación (fecha o release)
• Efecto de no implementarlo • Procedimiento marcha atrás
• Fecha • Fecha real implantación
• Impacto - urgencia • Resultados de la revisión (incluyendo nuevos RFC si
• Prioridad existen)
• ID del Problema que soluciona • Estado (iniciado – evaluado – rechazado – bloqueado
…)
www.itenea.com

12. Gestión de Cambios
Alguien pensará lo siguiente de este proceso: “Añadirá burocracia, tiempo, y nos atará de
manos a la hora de implantar cambios rápidos”, sin embargo para pequeños cambios o
cambios frecuentes se pueden acordarse procedimientos estándar que no requieran la
aprobación de Gestión de Cambios y con el registro de un mínimo de información. Para
cambios complejos, nos aseguramos que los cambios llevan el respaldo de la dirección de
IT y se ha evaluado su impacto global, riesgo, y coste.
www.itenea.com

13. Gestión de Cambios
Modelos de Cambio
• Es una forma repetible de vérselas con una Categoría particular del
Cambio. El modelo de cambio define pasos específicos
preestablecidos que han de seguirse para un Cambio de esta
Categoría. El modelo de cambio puede ser muy simple, sin requisitos de aprobación
(ej. Restablecimiento de contraseña) o puede ser muy complejo con varios pasos que
exigen aprobación (ej. Edición de software).
• Dependientes del tipo (Hw-Sw), o severidad, u otros criterios
• Predefinidos y acordados con la organización
• Tareas diferentes según el modelo: más o menos aprobación, más
o menos tests, más o menos seguimiento…
www.itenea.com

14. Gestión de Cambios
Tipos de cambio
• Normal: cambios que siguen el proceso de forma normal. Ej.
Actualización a Windows 7 para todos los portátiles de la compañía
• Estándar: pre-aprobados por la Gestión de Cambios. Ej.
Actualizaciones PC, cambio en política de firewall
• Emergencia: han de ser diseñados cuidadosamente y probados
para evitar que el propio cambio tenga mayor impacto negativo
que la propia incidencia. Ej. Actualización de firmware de la cabina de
almacenamiento que ha dejado de funcionar.
www.itenea.com

15. Gestión de Cambios
Revisión posterior a la implementación (PIR Post Implementation
Review)
Término o método para confirmar que el cambio ha cumplido sus objetivos, que los
clientes están satisfechos y no hay “efectos secundarios”
Consejo asesor de cambios (CAB Change Advisory Board)
– comité con representación de TIC y del negocio, formado por expertos que
asesoran en la implantación de cambios
– aprueba cambios y asesora al Gestor de Cambios en su evaluación y priorización
– su composición varía según los cambios a evaluar, pero siempre incluye usuarios /
negocio. Puede haber desarrolladores, proveedores, personal de administración,
etc
– no es necesaria una reunión física
www.itenea.com

16. Gestión de Cambios
Consejo asesor de cambios de emergencia (ECAB Emergency
CAB)
– asiste en la toma de decisiones para cambios urgentes
– sólo en situaciones de crisis
– con autoridad para tomar decisiones rápidas
– su composición y forma de convocatoria se definen en los procedimientos
– se puede decidir que el ECAB sea únicamente el Director IT
– no acelera el proceso
Agenda de Cambios (Change Calendar)
– Planificación de todos los cambios aprobados, acordada por todos los participantes,
y comunicada por el Service Desk a afectados si existe indisponibilidad ante un
cambio
– Se elabora en el CAB
www.itenea.com

17. Gestión de Cambios
Tipos de Aprobación ante un cambio:
• Financiera: los recursos necesarios para el cambio han sido
evaluados y aprobados
• Técnica: es viable
• De negocio: el cliente o usuario debe estar de acuerdo con el
cambio solicitado
www.itenea.com

18. Gestión de la Configuración y de los Activos del Servicio
“Proceso que se encarga de definir y controlar los componentes
de servicios y de la infraestructura, y mantener la información
exacta y precisa de la configuración (el estado histórico, planificado y
actual de los servicios e infraestructura)”
Proporciona información precisa y fiable al resto de la
organización de todos los elementos que configuran la infraestructura
IT.
Mantiene actualizada la CMDB (Configuration Management DataBase)
mediante:
– Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado...
– Interrelación entre los CIs.
– Servicios que ofrecen los diferentes CIs.
Sirve de apoyo a los otros procesos, en particular, a la Gestión de
Incidencias, Problemas y Cambios.
www.itenea.com

19. Gestión de la Configuración y de los Activos del Servicio
Puntos clave en el proceso:
• Mantiene los Elementos de Configuración (CIs Configuration
Items): todos los componentes a gestionar por el departamento IT
para entregar los servicios (un módem, una aplicación, una base de datos, un
Plan de Contingencia…)
• Mantiene la CMDB: Configuration Management Data Base que
proporciona:
– Información detallada de los CIs
– Interrelaciones entre ellos
• Realiza el control de CIs desde que se planea su adquisición
hasta su retirada
www.itenea.com

20. Gestión de la Configuración y de los Activos del Servicio
¿ Cómo sé qué es un CI ?
• Es necesario para entregar un servicio
• Es único en cuanto a su identificación (ojo, no incluir por ejemplo la
localización en el nombre)
• Está sujeto a cambios y se puede gestionar
• Solamente si su control resulta útil para la entrega de los servicios
¿Un PC es un PC? ¿O es un monitor + ratón + teclado + CPU…? La profundidad y el
alcance se define en cada caso, no obstante, habitualmente controlar un componente
como por ejemplo, un ratón, puede ser más costoso económicamente que sustituirlo
por otro nuevo en caso de avería.
www.itenea.com

21. Gestión de la Configuración y de los Activos del Servicio
¿Para qué sirve la CMDB?
Algunos de los usos pueden de la CMDB pueden ser:
– Identificar CIs y sus versiones en entornos de pruebas y producción
– Identificar CIs afectados por un cambio programado
– Identificar todas las Peticiones de Cambio asociadas a un determinado CI
– Identificar CIs adquiridos a un determinado proveedor en un periodo
– Identificar equipamiento y SW de una determinada localización, Ej.: para ayudar
en auditorías
– Identificar problemas asociados a un CI, o todos los CIs afectados por un
problema
– Avisos sobre licencias que deben renovarse
www.itenea.com

22. Gestión de la Configuración y de los Activos del Servicio
Línea Base o Baseline
Es la configuración de un servicio, producto o infraestructura que ha
sido formalmente aprobada y que sirve de referencia para el futuro. Ej.
Para realizar futuros cambios en el desarrollo de un servicio o aplicación, es útil tener a
mano todos los componentes para planificar una release...
Es una foto de la infraestructura en un momento del tiempo, puede
ser una configuración repetible.
Nota: Este concepto también aparece en la fase de Mejora Continua del servicio que se
verá al final de esta documentación. En esencia, una línea base en ITIL es un mecanismo
que permite realizar una comparación entre una situación inicial y otra posterior en el
tiempo.
Biblioteca Definitiva de Medios (DML Definitive Media Library)
Constituye uno o más lugares donde se almacenan con seguridad las
versiones definitivas aprobadas de CIs de Software . La DML también
puede contener CIs asociados tales como licencias y documentación o
backups.
www.itenea.com

23. Gestión de la Configuración y de los Activos del Servicio
Sistema de Gestión de la Configuración (CMS Configuration
Management System):
Amplía el concepto de CMDB de la v2 de ITIL incluyendo varias capas:
• Data: Capa de herramientas y fuentes de datos e información:
CMDBs, DML, aplicaciones corporativas, aplicación ITSM
(incidencias, problemas, cambios), herramientas de discovery…
• Information: Capa de integración de la información (Portfolio de
Servicios, Catálogo de Servicios, etc)
• Knowledge: Capa de procesamiento de conocimiento (reporting,
modelado, análisis del rendimiento…)
• Capa de presentación: vista de cambios, vista de gestión de
activos, vista del service desk, vista técnica…
Nota: La CMS engloba a la/s CMDB/s
www.itenea.com

24. Gestión de Versiones y de Despliegues
“Proceso cuyo objetivo es proteger el entorno productivo, teniendo
en cuenta de forma global todos los aspectos técnicos y no técnicos
de una release (versión)”
Gestión de Lanzamientos es la encargada de la implementación y
control de calidad de todo el software y hardware instalado en el
entorno de producción
Su foco es proteger el entorno productivo, para que cualquier
elemento de software o hardware que pase a formar de él hay sido
suficientemente probado y se trate de la versión correcta en el
momento adecuado. Se encarga de:
– Establecer planes de versión y de despliegue
– Permitir la construcción, pruebas y despliegue del paquete de versión o release
– Transferir el conocimiento a clientes, usuarios y equipo interno (este sería un
ejemplo de aspecto “no técnico”)
– En general, minimizar el impacto de lo no previsto
www.itenea.com

25. Gestión de Versiones y de Despliegues
Se utiliza para:
• Principales despliegues de software, especialmente instalaciones
iniciales de nuevas aplicaciones, junto con distribución de software
en la organización
• Despliegues de hardware grandes o críticos
Actividades principales del proceso:
• Planificación de versiones
• Diseño, compilado y configuración
• Aceptación
• Comunicación, preparación y formación
• Distribución y implementación
www.itenea.com

26. Gestión de Versiones y de Despliegues
Política de Versiones
Cubre la numeración de versiones o releases, frecuencia, condiciones
especiales, etc. Por ejemplo, la política definirá que entre releases planeadas sólo se
admitirán parches de emergencia muy estrictos, sin inclusión de mejoras.
La política define también qué nivel de la infraestructura IT controla
una entrega o release:
la Unidad de Release es la porción de infraestructura o de un
servicio que normalmente se versiona de forma conjunta. Típicamente
reúne suficientes componentes como para realizar una función o uso
concreto.
Por ejemplo, una organización decide que la unidad de entrega normal para una aplicación
on-line es el módulo. Esto significa que cada vez que un CI de una aplicación se modifica,
se debe crear una entrega completa del módulo afectado. Al mismo tiempo la unidad de
entrega de una aplicación batch puede ser el la aplicación completa.
www.itenea.com

27. Gestión de Versiones y de Despliegues
• Una release se define en función de la RFC o RFCs que implementa,
normalmente una colección de cambios autorizados en un
elemento de IT (típicamente consiste en un número de soluciones
a problemas y/o mejoras en el servicio)
• También se define como un grupo de CIs de nueva creación o
modificados que han sido validados para su instalación en el
entorno de producción
Para decidir el nivel adecuado de la unidad de release, es
necesario tener en cuenta:
– La cantidad de cambios necesarios normalmente a cada nivel posible
– La cantidad de recursos y tiempo necesarios para construir, probar, distribuir e
implantar entregas a cada nivel
– Facilidad de implantación
– La complejidad de las interfaces entre la unidad propuesta y el resto de la
infraestructura IT
– El espacio en disco disponible en los entornos de desarrollo, pruebas, aceptación y
producción
www.itenea.com

28. Gestión de Versiones y de Despliegues
Pruebas
• Se resalta la importancia de las pruebas, no sólo técnicas sino
también aspectos de validación con usuarios reales
• Las pruebas deben incluir los planes de back out
• Si la versión no se acepta, se devuelve a Gestión de Cambios para
su reevaluación
Tipos de Despliegues
– Completo “Big Bang” vs Faseado: el completo implica el despliegue de forma
simultánea en todos los emplazamientos y el faseado contempla la fragmentación
ya sea espacial o temporal.
– Push vs Pull: el despliegue Push consiste en la implantación forzada en un
momento determinado (Ej. introducción de un fichero bat que lanza la instalación
de una aplicación en el login script de un usuario de Active Directory). Pull implica
que el propio usuario “tira” de la instalación (Ej. cuando ordenamos a la aplicación
de antivirus una actualización del fichero de firmas)
– Automatizado / Manual
www.itenea.com

29. Gestión del Conocimiento
“Proceso cuyo objetivo es asegurar que se entrega la información
adecuada a la persona adecuada en el momento adecuado – mejorar
la calidad de las decisiones”
La transición del conocimiento es un aspecto básico de la Transición
del Servicio. Algunos ejemplos:
– Los usuarios, Service Desk, proveedores, etc. conocen claramente el nuevo
servicio
– Los usuarios saben cómo usar el nuevo servicio y conocen la discontinuidad del
viejo, si existe
– Se conocen y aceptan los riesgos relacionados con un despliegue
– Registro de errores conocidos y workarounds generados por la Gestión de
Problemas
– Se realiza el traspaso de conocimiento a un proveedor para externalizar o hacer
outsourcing de una parte del servicio y al revés en el caso de que se devuelva
(insourcing)
www.itenea.com

30. Gestión del Conocimiento
Sistema de Gestión del Conocimiento del Servicio (SKMS Service
Knowledge Management System)
Es el sistema que almacena TODA LA INFORMACIÓN necesaria para
gestionar los servicios a lo largo de su ciclo de vida. Tiene una
estructura similar a la CMS (Data, Information, Knowledge,
Presentation)
SKMS
Service Knowledge Management System
Skills de
Experiencia
CMS socios y
del staff
proveedores
Eventos y
Datos de alertas de
Etc, etc.
aplicaciones infraestructur
a
www.itenea.com

31. Gestión del Conocimiento
Relación entre los sistemas SKMS y CMS
En ITIL v3 la SKMS contiene a la CMS que a su vez contiene una o
varias CMDBs ¿conoces las muñecas rusas?
SKMS
CMS
CMDB
www.itenea.com

32. Gestión del Conocimiento
Jerarquía DIKW
En ITIL v3 se emplea el concepto de JERARQUÍA DIKW Data
Information Knowledge Wisdom: es una técnica para transformar
datos en sabiduría
DATOS - INFORMACIÓN - CONOCIMIENTO - SABIDURIA
Recopilar e Utilización de Capacidad de tomar la
interpretar información útil para mejor decisión
los datos generar conocimiento
www.itenea.com