Transición del servicioMódulo 4

www.itenea.com

INDICE

¿En qué consiste?Modelo en V del ServicioProcesos incluidos en la TransiciónGestión de cambios

Puntos clave en el procesoLas 7 R de la gestión de cambios¿Qué es una RFC?Modelos de CambioTipos de CambioPIR, CAB, ECAB y Agenda de cambiosTipos de aprobación

Gestión de la Configuración y Activos del ServicioPuntos clave en el proceso¿Cómo sé que es un CI?¿Para qué sirve la CMDB?Línea BaseBiblioteca definitiva de medios DMLSistema de gestión de la configuración

www.itenea.com

INDICE

Gestión de Versiones y de DesplieguesPolítica de versiones y unidad de releasePruebas y tipos de despliegues

Gestión del ConocimientoSistema de Gestión del Conocimiento del Servicio SKMSRelación entre los sistemas SKMS y CMSJerarquía DKIW

www.itenea.com

¿En qué consiste?

• Es el puente entre el diseño de los servicios y su operacióndiaria: básicamente Gestión de Configuración, de Lanzamientos yde Cambios, apoyado por procesos adicionales

“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”

Estrategia del Servicio

Ha definido el marco general para establecer servicios

Diseño del Servicio

Ha diseñado en detalle los servicios

Transición del Servicio

Ahora hay que pasarlos a Producción…

www.itenea.com

¿En qué consiste?

¿Y esto qué valor proporciona al negocio?

– Capacidad de adaptación rápida a los nuevos requerimientos y desarrollos delmercado

– Gestión de transición de fusiones, separaciones, adquisiciones y transferencias deservicios 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

Modelo en V del ServicioITIL v3 rescata este modelo. Garantiza que existe una colección de pruebas para cada fase de la construcción delservicio asegurando la calidad del entregable en cada fase. A la izda se representan los requisitos ya la derechacómo probarlos.

Definir requisitos de negocio

Prueba de aceptación del

servicio

Definir requisitos del servicio

Prueba preparación operacional del

servicio

Diseñar la solución del servicio

Diseñar la entrega del servicio

Desarrollar la solución del

servicio

Construir y probar los componentes

del servicio

Prueba de componentes y construcción

Prueba de paquete de entrega del

servicio

Validar Paquetes del Servicio,

ofertas y contratos

Plan Pruebas Release

Plan Pruebas Operacionales Servicio

Plan Aceptación del Servicio

Plan Revisión del ServicioNIVEL 1

NIVEL 2

NIVEL 3

NIVEL 4

NIVEL 5

www.itenea.com

Procesos incluidos en la Transición

Planificación y soporte a la transición*

Gestión de Cambios

Gestión de Versiones y Despliegues

Validación y pruebas de Servicios*

Gestión de la Configuración y

Activos del Servicio

Evaluación* Gestión del Conocimiento

* No se son objeto de los fundamentos de ITIL

www.itenea.com

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 decambios mal implantados”, lanzar una gestión de cambiosprobablemente 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 oactividad. La propuesta de los mismos no es responsabilidad de esteproceso, únicamente la gestión.

www.itenea.com

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 yActivos del Servicio que es el que mantiene la CMDB)

www.itenea.com

Gestión de Cambios

Las 7 Rs de la Gestión de CambiosLas siguientes cuestiones han de ser respondidas para todos loscambios. Sin esta información la evaluación del impacto no se puedecompletar:

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

Gestión de Cambios

¿Qué es una RFC (Request for Change)?Es el documento o formulario que se emplea para proponer o elevarun cambio al proceso. Puede estar desencadenado por todo tipo de causas: cambiode localización física de un CI, cambio de proveedor, nueva legislación, resolución de unproblema…

¿Qué incluye habitualmente?

• Núm. ID RFC• Descripción de ítems afectados• Razón del cambio• Efecto de no implementarlo• Fecha• Impacto - urgencia• Prioridad• ID del Problema que soluciona

• Recomendaciones del CAB• Fecha y firma de autorización• Fecha prevista implantación (fecha o release)• Procedimiento marcha atrás• Fecha real implantación• Resultados de la revisión (incluyendo nuevos RFC si existen)• Estado (iniciado – evaluado – rechazado – bloqueado …)

www.itenea.com

Gestión de Cambios

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

www.itenea.com

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íficospreestablecidos que han de seguirse para un Cambio de estaCategorí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 queexigen 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

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 probadospara evitar que el propio cambio tenga mayor impacto negativoque la propia incidencia. Ej. Actualización de firmware de la cabina dealmacenamiento que ha dejado de funcionar.

www.itenea.com

Gestión de Cambios

Revisión posterior a la implementación (PIR Post ImplementationReview)

Término o método para confirmar que el cambio ha cumplido sus objetivos, que losclientes 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

Gestión de Cambios

Consejo asesor de cambios de emergencia (ECAB EmergencyCAB)

– 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 uncambio

– Se elabora en el CAB

www.itenea.com

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

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 laorganización de todos los elementos que configuran la infraestructuraIT.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 deIncidencias, Problemas y Cambios.

www.itenea.com

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 ITpara entregar los servicios (un módem, una aplicación, una base de datos, unPlan de Contingencia…)

• Mantiene la CMDB: Configuration Management Data Base queproporciona:

– Información detallada de los CIs– Interrelaciones entre ellos

• Realiza el control de CIs desde que se planea su adquisiciónhasta su retirada

www.itenea.com

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 elalcance se define en cada caso, no obstante, habitualmente controlar un componentecomo por ejemplo, un ratón, puede ser más costoso económicamente que sustituirlopor otro nuevo en caso de avería.

www.itenea.com

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

Gestión de la Configuración y de los Activos del Servicio

Línea Base o BaselineEs la configuración de un servicio, producto o infraestructura que hasido 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 amano todos los componentes para planificar una release...

Es una foto de la infraestructura en un momento del tiempo, puedeser una configuración repetible.Nota: Este concepto también aparece en la fase de Mejora Continua del servicio que severá al final de esta documentación. En esencia, una línea base en ITIL es un mecanismoque permite realizar una comparación entre una situación inicial y otra posterior en eltiempo.

Biblioteca Definitiva de Medios (DML Definitive Media Library)Constituye uno o más lugares donde se almacenan con seguridad lasversiones definitivas aprobadas de CIs de Software . La DML tambiénpuede contener CIs asociados tales como licencias y documentación obackups.

www.itenea.com

Gestión de la Configuración y de los Activos del Servicio

Sistema de Gestión de la Configuración (CMS ConfigurationManagement 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 deServicios, 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 deactivos, vista del service desk, vista técnica…

Nota: La CMS engloba a la/s CMDB/s

www.itenea.com

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 ycontrol de calidad de todo el software y hardware instalado en elentorno de producciónSu foco es proteger el entorno productivo, para que cualquierelemento de software o hardware que pase a formar de él hay sidosuficientemente probado y se trate de la versión correcta en elmomento 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

Se utiliza para:• Principales despliegues de software, especialmente instalaciones

iniciales de nuevas aplicaciones, junto con distribución de softwareen 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

Gestión de Versiones y de Despliegues

www.itenea.com

Política de VersionesCubre la numeración de versiones o releases, frecuencia, condicionesespeciales, etc. Por ejemplo, la política definirá que entre releases planeadas sólo seadmitirán parches de emergencia muy estrictos, sin inclusión de mejoras.

La política define también qué nivel de la infraestructura IT controlauna entrega o release:la Unidad de Release es la porción de infraestructura o de unservicio que normalmente se versiona de forma conjunta. Típicamentereúne suficientes componentes como para realizar una función o usoconcreto.Por ejemplo, una organización decide que la unidad de entrega normal para una aplicaciónon-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 deentrega de una aplicación batch puede ser el la aplicación completa.

Gestión de Versiones y de Despliegues

www.itenea.com

• Una release se define en función de la RFC o RFCs que implementa,normalmente una colección de cambios autorizados en unelemento de IT (típicamente consiste en un número de solucionesa problemas y/o mejoras en el servicio)

• También se define como un grupo de CIs de nueva creación omodificados que han sido validados para su instalación en elentorno de producción

Para decidir el nivel adecuado de la unidad de release, esnecesario 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

Gestión de Versiones y de Despliegues

www.itenea.com

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ónTipos de Despliegues

– Completo “Big Bang” vs Faseado: el completo implica el despliegue de formasimultánea en todos los emplazamientos y el faseado contempla la fragmentaciónya sea espacial o temporal.

– Push vs Pull: el despliegue Push consiste en la implantación forzada en unmomento determinado (Ej. introducción de un fichero bat que lanza la instalaciónde una aplicación en el login script de un usuario de Active Directory). Pull implicaque el propio usuario “tira” de la instalación (Ej. cuando ordenamos a la aplicaciónde antivirus una actualización del fichero de firmas)

– Automatizado / Manual

Gestión de Versiones y de Despliegues

www.itenea.com

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óndel Servicio. Algunos ejemplos:

– Los usuarios, Service Desk, proveedores, etc. conocen claramente el nuevoservicio

– Los usuarios saben cómo usar el nuevo servicio y conocen la discontinuidad delviejo, 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

Gestión del Conocimiento

Sistema de Gestión del Conocimiento del Servicio (SKMS ServiceKnowledge Management System)Es el sistema que almacena TODA LA INFORMACIÓN necesaria paragestionar los servicios a lo largo de su ciclo de vida. Tiene unaestructura similar a la CMS (Data, Information, Knowledge,Presentation)

SKMSService Knowledge Management System

CMS Experiencia del staff

Skills de socios y

proveedores

Eventos y alertas de

infraestructura

Datos de aplicaciones Etc, etc.

www.itenea.com

Gestión del Conocimiento

Relación entre los sistemas SKMS y CMSEn ITIL v3 la SKMS contiene a la CMS que a su vez contiene una ovarias CMDBs ¿conoces las muñecas rusas?

CMDBCMDB

CMSSKMS

www.itenea.com

Gestión del Conocimiento

Jerarquía DIKWEn ITIL v3 se emplea el concepto de JERARQUÍA DIKW DataInformation Knowledge Wisdom: es una técnica para transformardatos en sabiduría

DATOS - INFORMACIÓN - CONOCIMIENTO - SABIDURIA

Recopilar e interpretar los datos

Utilización de información útil para generar conocimiento

Capacidad de tomar la mejor decisión