2013

ITIL V3.0 GESTION DE CAMBIO

07/01/2013

Contenido
1. 2. 3. 4. 4.1. 4.2. 4.3. 4.4. 4.5. 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10. 5.11. 5.12. 6. Introduccin............................................................................................................................. 2 ITIL V3.0 .................................................................................................................................... 2 Glosario de Trminos ............................................................................................................ 3 Ciclo de Vida del Servicio TI................................................................................................ 4 Estrategia del Servicio. ..................................................................................................... 5 Diseo del Servicio. ........................................................................................................... 5 Transicin de Servicios. ................................................................................................... 5 Operacin del Servicio. .................................................................................................... 6 Mejora Continua del Servicio .......................................................................................... 6 Visin General ................................................................................................................. 6 Introduccin y Objetivos .............................................................................................. 7 Conceptos Bsicos ........................................................................................................ 9 Alcance de la Gestin de Cambios.......................................................................... 10 Proceso ........................................................................................................................... 10 Registro........................................................................................................................... 11 Aceptacin y Clasificacin ........................................................................................ 12 Aprobacin y Planificacin........................................................................................ 13 Implementacin ............................................................................................................ 14 Evaluacin .................................................................................................................. 15 Cambios de Emergencia ........................................................................................ 15 Control del Proceso ................................................................................................. 16

Caso prctico ........................................................................................................................ 17 6.1. Caso Prctico ................................................................................................................ 17

1. Introduccin Es importante asegurar que la gestin de los sistemas TI soporte los intereses del negocio y los objetivos derivados de los objetivos del negocio: Misin o por qu vale la pena cooperar con una organizacin. Objetivos o que es lo que desea conseguir. Polticas o qu decisiones o medidas se han tomado para definir y conseguir los objetivos. Planificacin o en qu forma se implementan las polticas en forma de actividades. Acciones o que tareas se asignan al personal o a organizaciones externas. Cuadro de mando integral o el control y medicin del cumplimiento de objetivos y de rendimiento. Hoy en da, surge la necesidad de contar con servicios de tecnologa de informacin de calidad alineados con las necesidades del negocio y que cubran las expectativas del cliente, adems de que vivimos en una poca de continuos cambios, tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente as, es evidente que toda "evolucin a mejor" requiere necesariamente de un cambio, este cambio se puede realizar de una forma exitosa si nosotros conocemos en detalle lo queremos cambiar para obtener el mayor provecho de la misma. 2. ITIL V3.0 La Information Technology Infrastructure Library ( ITIL ) es un conjunto de prcticas para la gestin de servicios de TI (ITSM) que se centra en alinear los servicios de TI con las necesidades del negocio. En su forma actual (conocida como ITILv3 e ITIL edicin 2011), ITIL se publica en una serie de cinco publicaciones principales, cada uno de los cuales cubre una etapa del ciclo de vida de ITSM. ITILv3 sustenta la norma ISO / IEC 20000 (anteriormente BS15000), la Norma Internacional de Gestin de Servicio para la gestin de servicios de TI, aunque las diferencias entre los dos marcos existen. ITIL describe los procedimientos, tareas y listas de control que no son especficos de cada organizacin, utilizados por una organizacin para establecer un nivel mnimo de competencia. Permite a la organizacin a establecer una lnea de base desde la que se puede planificar, implementar y medir. Se utiliza para demostrar el cumplimiento y para medir la mejora.
http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

ITIL es el enfoque ms ampliamente aceptado para la gestin de servicios de TI en el mundo. ITIL proporciona un conjunto coherente de mejores prcticas, procedentes de los sectores pblico y privado a nivel internacional.
http://www.itil-officialsite.com/

La IT Infrastructure Library (ITIL) es el mtodo ms ampliamente aceptado para la gestin de servicios de TI en el mundo. ITIL es un marco de mejores prcticas que se ha extrado de los sectores pblico y privado a nivel internacional. En l se describe cmo los recursos de TI deben organizarse para ofrecer un valor empresarial, la documentacin de los procesos, las funciones y roles de IT Service Management (ITSM). Adems de este material publicado, ITIL se apoya en un esquema de calificacin global, las organizaciones de formacin acreditadas, y la implementacin y herramientas de evaluacin. Esta formacin ITIL es un programa de grandes maneras de estudiar para el examen para que pueda pasar en su primer intento con xito. Impartido por instructores certificados de los programas de formacin ITIL v3, el programa ofrece una educacin de calidad que con xito le ayudar a mejorar su carrera de IT

http://hardtimesuniversity.org/programs/itil-v3-0/

3. Glosario de Trminos ASP: Proveedor de Servicios de Aplicaciones Back-out: Proceso de retirada de una versin ya desplegada Back-up: Copias de seguridad BCM: Gestin de la Capacidad del Negocio BCM: Gestin de la Continuidad del Servicio BIA: Anlisis de impacto en el negocio CAB: Comit Asesor del Cambio CCM: Gestin de la Capacidad de Recursos CDB: Base de Datos de la Capacidad CFIA: Anlisis del Impacto de Fallo de Componentes CI: Elemento de Configuracin CIs: Elementos de Configuracin CMDB: Base de Datos de la Gestin de Configuraciones CMI: Cuadro de Mando Integral CMIS: Sistema de Informacin de Gestin de la Capacidad CMS: Sistema de Gestin de la Configuracin CRAMM: Mtodo de Gestin y Anlisis de Riesgos de la CCTA CRM: CSFs: Factores Crticos de xito CSI: Mejora Continua del Servicio CSP: Paquete de Servicio Esencial DAFO: Fortalezas, Debilidades, Oportunidades y Amenazas DML: Biblioteca de Medios Definitivos DS: Repuestos Definitivos ECAB: Comit Asesor de Cambios de Emergencia ELS: Soporte post-implantacin FAQs: Preguntas Frecuentes FSC: Calendario del Cambio FTA: Anlisis del rbol de Fallos GTB: Inversiones de crecimiento del negocio ISMS: Gestin de la Seguridad de la Informacin ISPs: Proveedores de Servicios de Internet ITIL: Biblioteca de la Infraestructura de Tecnologa de Informacin ITSCM: Gestin de la Continuidad de los Servicios de TI KB: Base de Conocimiento KEDB: Base de Datos de Errores Conocidos KPIs: Indicadores Crticos de Rendimiento LOPD: Ley Orgnica de Proteccin de Datos MTBF: Tiempo Medio entre Fallos MTBSI: Tiempo Medio entre Incidencias del Servicio MTTR: Tiempo Medio de Reparacin M_o_R: Gestin de Riesgos OLA: Acuerdos de Nivel de Operacin OLAs: Acuerdos de Nivel de Operacin

PBAs: Patrones de Actividad del Negocio PIR: Revisin Post-Implantacin PSA: Disponibilidad de Servicio Prevista PSO: Parada de Servicio Prevista RACI : Encargado-Responsable-Consultado-Informado RASCI: Encargado-Responsable-Soporte-Consultado-Informado RCA: Anlisis de la Causa Raz RFC: Peticin de Cambio RFCs: Peticiones de Cambio ROI: Retorno de la inversin RTB: Inversiones para mantener el negocio SACs: Criterios de Aceptacin del Servicio SCD: Base de Datos de Proveedores y Contratos SCM: Gestin de la Capacidad del Servicio SDP: Paquete de Diseo del Servicio SIP: Plan de Mejora del Servicio SKMS: Sistema de Gestin del Conocimiento del Servicio SLA: Acuerdos de Nivel de Servicio SLAs: Acuerdos de Nivel de Servicio SLM: Responsable del Nivel del Servicio SLP: Paquete de Nivel del Servicio SLRs: Requisitos del Nivel del Servicio SLRs: Requisitos del Nivel del Servicio SOA: Anlisis de Interrupcin del Servicio SP: Paquete de Servicio SPs: Paquetes del Servicio SQP: Plan de Calidad del Servicio SQP: Plan de Calidad del Servicio SSIP: Plan de Mejora de Proveedor de Servicios SWOT: Fortalezas, Debilidades, Oportunidades y Amenazas TCO: Coste Total de Propiedad TTB: Inversiones para transformar el negocio UC : Contrato de Soporte UCs: Contratos de Soporte VBF: Funcin Vital para el Negocio VOI: Valor de la Inversin

http://itilv3.osiatis.es/glosario.php

4. Ciclo de Vida del Servicio TI

ITIL es un marco pblico que resea buenas prcticas para la gestin de servicios en Tecnologa de Informacin. Provee un esquema para la gestin de las tecnologas de la informacin y se enfoca en la medicin y mejora continua de la calidad del Servicio proporcionado por TI otorgado desde la perspectiva del cliente y del negocio. Este enfoque se ha convertido en el factor clave para el xito mundial de ITIL, y ha contribuido a la extensin de su uso en las principales reas y empresas de tecnologa. Entre los beneficios clave obtenidos por las organizaciones que lo utilizan se encuentran:

Incrementar la satisfaccin de usuario y cliente con los servicios de TI Mejorar la disponibilidad del servicio, ligado directamente a incrementar los beneficios y rendimientos de la empresa El ahorro financiero en la reduccin de retrabajos y tiempo perdido, as como la mejora en la gestin de recursos Mejora la toma de decisiones y disminuye los riesgos

El ciclo de vida del servicio es un acercamiento a la gestin de las reas de Tecnologa que pone nfasis en la Estrategia, Diseo, Transicin, Operacin y Mejora Continua de los servicios proporcionados al negocio, a travs de diferentes funciones, procesos y sistemas necesarios para gestionar estos servicios a lo largo de su ciclo de vida.

El Ciclo de Vida de la Gestin del Servicio consta de cinco fases: 4.1. Estrategia del Servicio. En esta fase se presenta el cmo alinear los servicios proporcionados por TI a los objetivos estratgicos del negocio. Los requerimientos del servicio son identificados y estipulados dentro del Paquete del Nivel del Servicio (SLP) en un conjunto definido de resultados a entregar al negocio, estableciendo adems su validez financiera y generando las bases para su diseo, transicin y operacin. Aqu se expone el cmo transformar la Gestin del Servicio en un activo estratgico. 4.2. Diseo del Servicio. Aqu se disean y desarrollan los servicios, los procesos y las capacidades de la Gestin del Servicio a fin de asegurar el cumplimiento del valor establecido como parte de la estrategia. Se utilizan los principios y mtodos de diseo para convertir objetivos estratgicos en planes tcticos que garanticen y mejoren los niveles de disponibilidad, capacidad, seguridad y continuidad de todos los servicios. 4.3. Transicin de Servicios. Es en esta fase en donde se desarrollan y mejoran las capacidades para la transicin de nuevos servicios y/o cambios a los ya existentes, asegurando los requerimientos de la estrategia de servicio. Es una gua para gestionar la complejidad relacionada con los cambios a servicios y

gestin de procesos de servicios, previniendo consecuencias indeseables, como fallas e interrupciones. 4.4. Operacin del Servicio. Esta fase demuestra cmo se puede alcanzar la efectividad y eficiencia en la entrega y soporte de servicios para asegurar valor tanto al cliente como al proveedor del servicio. La Operacin del Servicio es donde los planes, diseos y optimizaciones son ejecutados y medidos. Desde el punto de vista del cliente, la Operacin del Servicio es donde realmente se aprecia el valor del servicio.

4.5.Mejora Continua del Servicio.

Se preocupa de crear y mantener el valor para el cliente a travs de un mejor diseo, introduccin y operacin de los servicios, asociando esfuerzos de mejora y resultados con la Estrategia, Diseo, Transicin y Operacin del Servicio, identificando las oportunidades para mejorar las debilidades o fallas dentro de cualquiera de stas etapas.
http://www.customercareassociates.com/index.php?option=com_content&view=article&id=41&Itemid=21

5. Gestin de Cambio 5.1. Visin General Vivimos en una poca de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente as, es evidente que toda "evolucin a mejor" requiere necesariamente de un cambio. Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que an se rigen por el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho ms peligroso el estancamiento en servicios y tecnologas desactualizados. Las principales razones para la realizacin de cambios en la infraestructura TI son: Solucin de errores conocidos. Desarrollo de nuevos servicios. Mejora de los servicios existentes. Imperativo legal.

El principal objetivo de la Gestin de Cambios es la evaluacin y planificacin del proceso de cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI. Las interacciones y funcionalidades de la Gestin de Cambios se resumen en el siguiente grfico:

5.2. Introduccin y Objetivos El objetivo primordial de la Gestin de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estndar. La Gestin de Cambios debe trabajar para asegurar que los cambios: Estn justificados.

Se llevan a cabo sin perjuicio de la calidad del servicio TI. Estn convenientemente registrados, clasificados y documentados. Han sido cuidadosamente testeados en un entorno de prueba. Se ven reflejados en la CMDB. Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementacin. Las actividades principales de la Gestin de Cambios se resumen sucintamente en el siguiente diagrama:

Los principales beneficios derivados de una correcta gestin del cambio son: Se reduce el nmero de incidentes y problemas potencialmente asociados a todo cambio. Se puede retornar a configuraciones estables de manera sencilla y rpida en caso de que el cambio tenga un impacto negativo en la estructura TI. Se reduce el nmero de "back-outs" necesarios. Los cambios son mejor aceptados y se evitan "tendencias inmovilistas". Se evalan los verdaderos costes asociados al cambio y por lo tanto es ms sencillo valorar el retorno real a la inversin. La CMDB est correctamente actualizada, algo imprescindible para la correcta gestin del resto de procesos TI. Se desarrollan procedimientos de cambio estndar que permiten la rpida actualizacin de sistemas no crticos.

La implementacin de una adecuada poltica de gestin de cambios tambin se encuentra con algunas serias dificultades:

Los diferentes departamentos deben aceptar la autoridad de la Gestin de Cambios sobre todo en lo que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales. No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la informacin sobre los CIs en la CMDB. Los encargados de la Gestin de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organizacin incapacitndoles para desarrollar correctamente su actividad. Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso. No existe el compromiso suficiente de la direccin por implementar rigurosamente los procesos asociados. Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.

5.3. Conceptos Bsicos En el resto de este captulo se utilizar con frecuencia el concepto de Gestor de Cambios y Consejo Asesor del Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivas atribuciones: Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el ltimo responsable de todas las tareas asignadas a la Gestin de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores especficos para cada una de las diferentes reas. Consejo Asesor de Cambios (CAB): es un rgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales reas de la gestin de servicios TI. Sin embargo, en algunos casos tambin puede incorporar: o o o Consultores externos. Representantes de los colectivos de usuarios. Representantes de los principales proveedores de software y hardware.

5.4. Alcance de la Gestin de Cambios En principio, todo cambio no estndar debe considerarse tarea de la Gestin de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante sta. El alcance de la Gestin de Cambios debe ir en paralelo con el de la Gestin de Configuraciones: todos los cambios de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados. Al igual que a la hora de implementar la Gestin de Configuraciones se sugiri como medida simplificadora la creacin de "configuraciones de referencia" o paquetes de hardware y software estndar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos estn previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas. Estos protocolos de cambio estndar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestin ms rpida y eficiente de cambios menores o de bajo impacto en la organizacin TI.

5.5. Proceso Las principales actividades de la Gestin de Cambios se resumen en: Monitorizar y dirigir todo el proceso de cambio. Registrar, evaluar y aceptar o rechazar las RFCs recibidas. Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobacin de las RFCs y la elaboracin del FSC. Coordinar el desarrollo e implementacin del cambio. Evaluar los resultados del cambio y proceder a su cierre en caso de xito.

Nota: los botones del grfico permiten acceder a informacin mas detallada sobre la interrelacin con otros procesos TI.

5.6. Registro El primer paso del proceso de cambio es registrar adecuadamente las RFCs. El origen de una RFC puede ser de muy distinta ndole: Gestin de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayora de los casos esta solucin acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con informacin del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso. Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados. Estrategia empresarial: la direccin puede decidir una redireccin estratgica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantacin de un nuevo CRM, etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos. Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualizacin. Imperativo legal: un cambio de legislacin (como, por ejemplo, la LOPD) puede exigir cambios en la infraestructura TI. Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.

No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten peridicamente pueden acordarse procedimientos estndar que no requiera la aprobacin de laGestin de Cambios en cada caso. Independientemente de su origen el correcto registro inicial de una RFC requerir, cuando menos, de los siguientes datos: Fecha de recepcin. Identificador nico de la RFC. Identificador del error conocido asociado (dado el caso). Descripcin del cambio propuesto: o o o o o Motivacin. Propsito. CIs involucrados. Estimacin de recursos necesarios para la implementacin. Tiempo estimado.

Estatus: que inicialmente ser el de "registrado".

Este registro deber ser actualizado con toda la informacin generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobacin hasta la evaluacin final y cierre. La informacin de registro debe ser actualizada durante todo el proceso y debe incluir al menos: Estatus actualizado: "aceptado", "rechazado", "implementado", ... Fecha de aceptacin (denegacin) del RFC. Evaluacin preliminar de la Gestin del Cambio. Prioridad y categora. Planes de "back out". Recursos asignados. Fecha de implementacin. Plan de implementacin. Cronograma. Revisin post-implementacin. Evaluacin final. Fecha de cierre.

5.7. Aceptacin y Clasificacin Aceptacin Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificacin si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definicin. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan

realizar nuevas alegaciones consecuentemente modificada.

favor

de

dicha RFC o

para

que

pueda

ser

La aceptacin del cambio no implica su posterior aprobacin por el CAB y es slo indicacin de que se ha encontrada justificado su ulterior procesamiento. Clasificacin Tras su aceptacin se deben asignar a la RFC una prioridad y categora dependiendo de la urgencia y el impacto de la misma. La prioridad determinar la importancia relativa de esta RFC respecto a otras RFCs pendientes y ser el dato relevante para establecer el calendario de cambios a realizar. La categora determina la dificultad e impacto de la RFC y ser el parmetro relevante para determinar la asignacin de recursos necesarios, los plazos previstos y el nivel de autorizacin requerido para la implementacin del cambio. Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debera considerar una clasificacin que incluyera, al menos, los siguientes niveles de prioridad: Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc. Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algn otro cambio de ms alta prioridad. Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su prxima reunin y adoptar las medidas pertinentes que permitan una pronta solucin. Urgente: es necesario resolver un problema que esta provocando una interrupcin o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente.

La determinacin de la categora se basa en el impacto sobre la organizacin y el esfuerzo requerido para su implementacin. El abanico de posibilidades incluye desde cambios que apenas requieren la participacin del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobacin directa de la Direccin. Los cambios menores pueden no necesitar la aprobacin del CAB y ser implementados directamente. Cualquier otro cambio habr de ser discutido en el CAB y se habr de solicitar la colaboracin de personal especializado para realizar tareas de asesoramiento.

5.8. Aprobacin y Planificacin La planificacin es esencial para una buena gestin del cambio. Los sistemas de gestin de la informacin son muy susceptibles a los cambios de configuracin por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reaccin en cadena con resultados catastrficos. Es imprescindible, como mnimo, disponer siempre de planes de "back out" que permitan la recuperacin de la ltima configuracin estable antes del cambio. Pero esto obviamente no es suficiente.

En primer lugar el CAB debe reunirse peridicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente. Para su aprobacin el cambio se debe evaluar minuciosamente: Cules son los beneficios esperados del cambio propuesto? Justifican esos beneficios los costes asociados al proceso de cambio? Cules son los riesgos asociados? Disponemos de los recursos necesarios para llevar a cabo el cambio con garantas de xito? Puede demorarse el cambio? Cul ser el impacto general sobre la infraestructura y la calidad de los servicios TI? Puede el cambio afectar los niveles establecidos de seguridad TI?

En el caso de cambios que tengan un alto impacto debe tambin consultarse a la direccin pues pueden entrar en consideracin aspectos de carcter estratgico y de poltica general de la organizacin. Una vez aprobado el cambio (en caso contrario se seguira el proceso ya descrito para el caso de no aceptacin) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldran a un solo cambio. Esto tiene algunas ventajas: Se optimizan los recursos necesarios. Se evitan posibles incompatibilidades entre diferentes cambios. Slo se necesita un plan de back-out. Se simplifica el proceso de actualizacin de la CMDB y la revisin postimplementacin.

5.9. Implementacin Aunque la Gestin de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestin de Versiones, si lo es de supervisar y coordinar todo el proceso. En la fase de desarrollo del cambio se deber monitorizar el proceso para asegurar que: Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas. Se cumplen los calendarios previstos y la asignacin de recursos es la adecuada. El entorno de pruebas es realista y simula adecuadamente el entorno de produccin. Los planes de "back-out" permitirn la rpida recuperacin de la ltima configuracin estable.

Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoracin preliminar de los nuevos sistemas en lo que respecta a su: Funcionalidad. Usabilidad. Accesibilidad.

La opinin de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios). Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es funcin tanto de la Gestin de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles participes del mismo: Escuchando sus sugerencias. Comunicando las ventajas asociadas. Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepcin de mejora debe ser compartida por usuarios y clientes. Evaluacin

5.10.

Antes de proceder al cierre del cambio es necesario realizar una evaluacin que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organizacin. Los aspectos fundamentales a tener en cuenta son: Se cumplieron los objetivos previstos? En que medida se aparto el proceso de las previsiones realizadas por la Gestin de Cambios. Provoc el cambio problemas o interrupciones del servicio imprevistas? Cul ha sido la percepcin de los usuarios respecto al cambio? Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?Por qu?

Si la evaluacin final determina que el proceso y los resultados han sido satisfactorios se proceder al cierre de la RFC y toda la informacin se incluir en la PIR asociada.

5.11.

Cambios de Emergencia

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificacin deficiente a veces resultan inevitables. Cualquier interrupcin del servicio de alto impacto, ya sea por el nmero de usuarios afectados o porque se han visto involucrados sistemas o servicios crticos para la organizacin, debe encontrar una respuesta inmediata. Es frecuente que la solucin al problema requiera un cambio y que ste haya de realizarse siguiendo un procedimiento de urgencia. El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validacin de los cambios urgentes que pueden requerir: La reunin urgente del CAB y/o EC si esto fuera posible. Una decisin del Gestor del Cambio si es imposible demorar la resolucin del problema o ste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunin del EC).

Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentacin asociada al cambio se realicen a posteriori. Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma informacin de la que dispondramos tras un cambio normal. Si esto no fuera as se podran provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que seran fuente de nuevas incidencias y problemas.

5.12.

Control del Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestin de Cambios. Para que estos informes ofrezcan una informacin precisa y de sencilla evaluacin es imprescindible elaborar mtricas de referencia que cubran aspectos tales como: RFCs solicitados. Porcentaje de RFCs aceptados y aprobados. Nmero de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente. Tiempo medio del cambio dependiendo del impacto y la prioridad Nmero de cambios de emergencia realizados. Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc. Numero de back-outs con una detallada explicacin de los mismos. Evaluaciones post-implementacin. Porcentajes de cambios cerrados sin incidencias ulteriores. Incidencias asociadas a cambios realizados. Nmero de reuniones del CAB con informacin estadstica asociada: nmero de asistentes, duracin, n de cambios aprobados por reunin, etc.

6. Caso prctico

Modelo de Gestin de cambios basado en ITIL V3.0

6.1. Caso Prctico Las organizaciones actuales se apoyan en diferentes tecnologas para incrementar el valor agregado del negocio y centrar sus esfuerzos y recursos en alcanzar altos niveles de satisfaccin al cliente y beneficios econmicos. Una relativa dependencia de los negocios en dichas tecnologas se ha generado. Esta dependencia es necesaria pero muy riesgosa si no se definen procedimientos y polticas que garanticen una gestin eficiente de ellas. Garantizar total disponibilidad, capacidad y seguridad de la informacin y las tecnologas de acuerdo a las demandas del negocio podra ser un verdadero dolor de cabeza. Departamentos de Tecnologas de Informacin se han constituido para dar a las compaas la tranquilidad de que la informacin es confiable, est disponible en todo momento y la infraestructura tecnolgica necesaria para su operacin funciona correctamente. Sin embargo, cuanto ms grande es la organizacin, ms compleja se hace la administracin de dichos recursos. Una de las gestiones que ms riesgo involucra es la Gestin de Cambios. La plantilla de Gestin de Cambios se ha basado en los principios de las prcticas ITIL V3 para ayudarlo a garantizar una apropiada planeacin de los cambios, una completa evaluacin del riesgo e impacto, la definicin de los niveles de autorizacin, y una correcta comunicacin, implementacin y documentacin. La definicin de un flujo de proceso estndar, las responsabilidades, la informacin que debe ser registrada en cada actividad y a trazabilidad de cada cambio le permitirn priorizar y responder eficazmente las solicitudes. Adicionalmente podr reducir cambios no exitosos, cumplir con requerimientos externos, mejorar las estimaciones de tiempo y costo de los proyectos, aportar a la productividad, reducir tiempos de respuesta y captar valiosa informacin para el mejoramiento continuo. Analice e implemente los cambios ms convenientes para su organizacin de manera gil y eficiente.

Figura Modelo de Gestin de Cambios basado en ITIL V3

DESCRIPCIN El proceso inicia con la creacin de un RFC (Request For Change Solicitud de Cambio) por parte de una persona o grupo quien planea el cambio y lo somete a revisin tcnica. Una vez completo el RFC, se presenta ante el departamento de Gestin de Cambios, el cual establece una valoracin y evaluacin inicial y decide si acepta, rechaza o solicita cambios al RFC. Los cambios aceptados deben ser aprobados de acuerdo a su clasificacin y nivel de impacto. Cuando el RFC ha sido debidamente autorizado, su implementacin es planeada, comunicada y ejecutada. Luego, dicha implementacin es evaluada por el solicitante, que establece si sta fue exitosa o no. Las acciones necesarias para remediar efectos no esperados o no deseados, se ejecutan de ser necesario. Finalmente el administrador de cambios revisa el desarrollo del cambio y cierra el RFC. MODELO DE DATOS

La entidad definida como entidad de proceso es la Solicitud de Cambio RFC. sta entidad contiene todos los atributos y relaciones necesarias para gestionar y dar seguimiento a un Cambio. Se establecieron relaciones con diferentes entidades paramtricas, para permitir a los usuarios la utilizacin de sus valores predefinidos como informacin del proceso. Algunas de estas entidades son: Tipo de Cambio, Clasificacin, Estado, Impacto, prioridad, entre otras.

La entidad de proceso tambin posee relaciones con la entidad del sistema WFUSER, para la identificacin de los ejecutantes de cada actividad. Para definir, almacenar y dar seguimiento a la informacin de un RFC a lo largo del proceso, se utilizan entidades maestras como: Matriz de impacto, Requerimientos del cambio, Historial, entre otras. El papel de las principales entidades dentro del proceso se describe con mayor detalle a continuacin. ENTIDADES MAESTRAS Esta plantilla de proceso cuenta con cinco entidades maestras, las cuales se describen a continuacin: 1. Para dar seguimiento (trazabilidad) a un RFC dentro del proceso, la entidad "Historial" almacena, en orden cronolgico, la informacin de las principales acciones que se han ejecutado sobre el mismo. De esta manera el usuario puede consultar el estado del proceso en cualquier momento. La entidad "Miembros del CAB" es utilizada para alojar la informacin de las personas que conforman el Comit Asesor de Cambios que evala un determinado cambio. Al momento de comunicar un cambio se deben definir las personas que han de ser notificadas sobre ste. La entidad "Personas a notificar" permite el ingreso de la informacin de dichas personas. Para definir los requerimientos que deben ser desarrollados como parte de un cambio se define la entidad "Requerimientos del Cambio". La informacin bsica de un requerimiento, como su descripcin, fecha lmite de entrega, desarrollador asignado, entre otra, se ingresa en sta entidad. El sub-proceso "Desarrollo de Requerimientos" se inicia por cada registro. Como veremos a continuacin, la entidad "Matriz de impacto" permite al usuario la seleccin de respuestas a las preguntas definidas en la entidad paramtrica "Preguntas" y de esta manera establecer el nivel de impacto de un cambio.

2.

3.

4.

5.

MATRIZ DE IMPACTO La evaluacin del impacto es una de las tareas ms crticas de este proceso. El nivel de autorizacin de un cambio, depende de la valoracin de los posibles efectos que ste ejerza sobre las operaciones del negocio, por lo que stos deben ser analizados cuidadosamente. La matriz de impacto es una herramienta que ayuda al equipo de gestin de cambios a evaluar el impacto de un cambio. Dicha matriz consiste en una serie de preguntas, cada una con un conjunto de respuestas y cada una de estas respuestas con un puntaje relacionado. El puntaje obtenido al totalizar los puntajes relacionados a cada una de las respuestas seleccionadas, define el nivel de impacto de acuerdo a las polticas establecidas. La entidad maestra " Matriz de Impacto", permite responder a las diferentes preguntas definidas en la entidad paramtrica "Preguntas" y determinar el puntaje total de las respuestas seleccionadas.

ENTIDADES PARAMTRICAS Diferentes entidades paramtricas se utilizan para definir la informacin que determina el flujo que seguir el RFC dentro del proceso. Algunas de ellas son totalmente personalizables de acuerdo a sus necesidades y polticas, como se muestra a continuacin: PREGUNTAS Como veremos ms adelante, la evaluacin del impacto de un cambio se realiza, comnmente, mediante la utilizacin de una matriz de impacto. sta matriz consta de una serie de preguntas que ayudan al analista a determinar el potencial impacto que el cambio solicitado podra tener sobre la operacin del negocio. Para definir sus propias preguntas, de acuerdo con la forma en que usted clasifica y valora sus cambios, vaya a la vista de Mdulos y seleccione la opcin entidades. Identifique dentro de las entidades paramtricas la entidad "Pregunta". De clic en "Valores" y agregue o edite las preguntas de la matriz como lo desee.

RESPUESTAS De acuerdo a las preguntas establecidas, se deben definir respuestas para cada una de ellas, as como el puntaje asociado que determinar el nivel de impacto de un cambio. Dicho nivel de impacto, se calcular totalizando el puntaje de las respuestas seleccionadas y comparando ste con las polticas que usted establezca. Para definir sus propias respuestas y el puntaje asociado a ellas, dirjase a la vista de Mdulos y seleccione la opcin entidades. Identifique la entidad "Respuestas" dentro de las entidades paramtricas. De clic en "Valores" y agregue o edite las respuestas, su puntaje y las preguntas relacionadas como lo desee.

REGLAS IMPORTANTES ESTABLECER NIVEL DE IMPACTO Esta regla se utiliza para totalizar los puntajes relacionados a las respuestas seleccionadas para cada pregunta de la matriz de impacto, y posteriormente, realizar una comparacin de dicho total con los rangos de nivel de impacto que defina el usuario. A continuacin se muestra la estructura de la expresin:

1.

El primer paso es "Obtener las cotas". Esta parte de la expresin obtiene los valores de los rangos que el usuario define para los distintos niveles de impacto. 2. El segundo paso es recorrer los registros de la entidad maestra "Matriz de impacto". 3. El tercer paso es obtener el puntaje total de las respuestas seleccionadas. Aqu se obtiene el puntaje de cada respuesta y se acumula a medida que se recorre la entidad "Matriz de Impacto". 4. Finalmente se compara el puntaje total obtenido con los rangos de nivel de impacto.

PRUEBAS CONCLUIDAS El mltiple sub-proceso de "Desarrollo de Requerimientos", se crea por cada requerimiento definido, para permitir al usuario encargado de su desarrollo, reportar los resultados finales de su gestin. Cuando un requerimiento no cumple de manera satisfactoria con las pruebas realizadas, ste sub-proceso debe ser lanzado de nuevo. Esta regla se utiliza para identificar s hay requerimientos que deben ser modificados. De esta manera se define si el flujo del proceso contina normalmente o debe relanzar sub-procesos de "Desarrollar Requerimientos"

ESTABLECER LA CONFIGURACION DE LOS TEMPORIZADORES Este proceso utiliza un temporizador para controlar el tiempo que un solicitante tiene para evaluar la implementacin de un cambio. Algunos RFC pueden permanecer abiertos esperando que el solicitante evale sus resultados, sin embargo, muchas veces el solicitante est satisfecho con el cambio y simplemente no lo hace. stos RFC deben ser cerrados para facilitar la gestin del equipo de gestin de cambios y no afectar las mtricas de desempeo del proceso. Usted puede establecer el tiempo que dar al solicitante a travs de definiciones de vocabulario. Ingrese en la vista de Mdulos, vaya a la opcin "Procesos" y busque las definiciones constantes de vocabulario. Seleccione la definicin "MAXIMUM TIME TO EVALUATE" e ingrese este valor de acuerdo a sus polticas. Recuerde que el valor que ingrese est definido en minutos.

INDICADORES Esta plantilla de proceso le ayudar a controlar su gestin gracias a las consultas que, de acuerdo a diferentes criterios, le permitirn determinar sus indicadores de desempeo claves o KPIs (por sus siglas en ingls). Las consultas se ejecutan desde la opcin "Consultas Bizagi" en la parte izquierda de la aplicacin web.

CONCLUSIONES

- Una vez implementado un proyecto de TI como por ejemplo el desarrollo/instalacin de un software se requiere dar el soporte y medir la eficiencia de este constantemente.

RECOMENDACIONES - ITIL mediante sus 5 fases ofrece una guia de mejores practicas para un constante seguimiento y soporte mediante indicadores durante el ciclo de vida del producto monitoreado.

BIBLIOGRAFIA

Web Oficial de ITIL http://www.itil-officialsite.com/ Pagina web de BIZAGI http://wiki.bizagi.com/es/ Wiki de BIZAGI http://wiki.bizagi.com/es/index.php?title=Consultas Wikipedia ITIL Biblioteca de Infraestructura de Tecnologa de Informacin http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library