Caso de incidencia

Eurotrans S.L.

Eurotrans, S.L. opera en los mercados de Europa y Asia Menor. Transporta mercancías y pasajeros por carretera, usando 1200 camiones y 350 autobuses La dirección Internacional de Eurotrans está ubicada en la oficina central en Utrecht (Holanda)- La oficina regional de Holanda también está en Utrecht. Las otras oficinas regionales están en Dusseldorf (Alemania y Orange (Francia). Eurotrans tiene 20 Oficinas locales de ventas repartidas por varias ciudades Europeas. La compañía emplea a 2800 personas, de las cuales 2200 son conductores. Cada una de las oficinas de ventas tiene donde dos a cuatro personas. Los otros 540 empleados trabajan en las oficinas principales: 220 en Utrecht, 180 en Dusseldorf y 140 en Orange. 

Eurotrans tiene, principalmente, contratos a largo plazo con empresas para proveerles de servicios de transporte terrestre de mercancías y pasajeros. Por ello, Eurotrans conoce el 80% del trabajo con dos meses de antelación. El 20% restante, con frecuencia consiste en trabajos urgentes para las empresas con las que tiene contratos a largo plazo, y en trabajos aislados o puntuales (por un servicio). 

La compañía fue creada hace 10 años como resultado de una fusión entre tres empresas nacionales de transporte, con una visión similar sobre el transporte de terrestre, y cada una fuertemente posicionada en una región particular de Europa. Antes de la fusión, las compañías cooperaban entre sí intercambiándose negocio de transporte de mercancías. Pero esto ha cambiado desde la fusión. Las oficinas principales trabajan estrechamente, y esta fuerte cohesión ha hecho que Eurotrans sea un proveedor fiable de transporte para compañías multinacionales

Gestión de incidencias

Hasta el momento en Eurotrans no existía un proceso correctamente definido para la gestión de incidencias, por lo que se han llevado a cabo las siguientes acciones para la implantación del proceso:

·         Nombramiento del gestor responsable del proceso de gestión de incidencias.

·         Definición de las actividades a realizar mediante este proceso:

o   Gestionar la primera línea de soporte de la Gestión de incidencias.

o   Supervisión de la calidad del proceso de gestión de incidencias respecto a los SLAs acordados

o   Definición de la clasificación de los incidentes apropiada al entorno de Eurotrans

o   Reporte de informes periódicos con la información recopilada.

·         Una vez analizada la infraestructura actual y se ha decidido implantar una infraestructura que facilite la implementación del proceso:

o   Un correcto sistema automatizado de registro de incidentes y relación con los clientes para lo que se ha elegido la Herramienta HP OpenView Service Desk

o   Una Base de Conocimiento actualizada (KB) para comparar nuevos incidentes con los anteriores ya sea en curso o resueltos.

o   Poner directamente a disposición del cliente parte de estos datos (a la manera de FAQs) en una WEB. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.

o   Una CMDB que contenga todas las configuraciones y el impacto que estas puedan tener en la resolución del incidente.

·         Con la Herramienta HP OpenView Service Desk se implementaran también los siguientes procesos:

o   Gestión de Configuraciones

o   Gestión de Incidencias

o   Gestión de Problemas

o   Gestión del Cambios o Gestión del Nivel de Servicio

·          Promocionar nuevos servicios a los clientes existentes y potenciales.

·          Habilitar un espacio Web para canalizar, en la medida de los posible, la interacción con los usuarios a través de este medio:

·          Formar al personal implicado en el proceso de gestión de incidencias.

·          Definición del plan de implantación progresiva del proceso de gestión de incidencias. .

Una vez implantado el proceso de gestión de incidencias, el proceso de gestión se verá modificado de la siguiente manera. Pongamos el ejemplo en que el Service Desk de Eurotrans recibe una llamada de un cliente que ha contratado un servicio de transporte urgente para el transporte de los suministros de uno de sus clientes. El cliente informa de que a pesar de haber solicitado un transporte urgente a través de la Web, el transporte todavía no ha llegado al destino. 

El operador del Service Desk realiza una búsqueda en la base de datos de pedidos y confirma que se realizó el pedido hace varios días pero también observa que éste se ha guardado defectuosamente. Repite la consulta con el fin de asegurarse, pero detecta que el sistema continúa dando error. Siguiendo los procedimientos definidos, el operador realiza las siguientes acciones:

·         Se analiza la prioridad del caso: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.

·         Procede al registro de los datos del incidente.

·         Se realiza una consulta la Base de Datos de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuáles son las posibles soluciones temporales

·         Propone una solución temporal al cliente: indica una zona reservada de la Web desde la que se pueden realizar pedidos "urgentes" vía email.

·         Contacta con el departamento de sistemas ya que este incidente puede reiterarse

·         Consulta, mediante la aplicación que monitoríza la disponibilidad de vehículos para transportes urgentes.

·         Informa al cliente que mediante su servicio urgente recibirá la mercancía solicitada antes del mediodía.

Por otro lado el departamento de sistemas:

·         Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.

·         No consigue identificar la causa del incidente.

·         Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero modificando la prioridad como baja.

El Service Desk recibe la información y determina que:

·         Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución temporal satisfactoria no se requiere un escalado superior.

·         Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas.

·         Da por cerrado el incidente.

Gestión de problemas

A continuación se expone el funcionamiento del proceso de gestión de problemas una vez implantado El service desk de Eurotrans ha escalado el incidente a la Gestión de Problemas ya que no ha podido encontrar un error conocido e implementar la solución al mismo. En este momento la Gestión de Problemas inicia el proceso de análisis del problema según los procedimientos definidos. Para el problema que nos ocupa se decide seguir el modelo de Kepner y Tregoe para encontrar la raíz del problema e implementar una solución o un workaround.

Se inicia el proceso mediante la identificación y clasificación del problema. Para la identificación, del problema se determina que la aplicación online utilizada para la realización de pedidos está produciendo errores en el registro de algunos pedidos, y no se haya correlación con otros componentes de hardware / software. Respecto a la clasificación, se debe en tener en cuenta la identificación, el origen, la frecuencia y el impacto.

A continuación se analizan las posibles causas de este problema que pueden ser

• ·         Errores en la programación de la aplicación de cliente
• ·         Errores en los módulos de registro del servidor Web.
• ·         Errores de configuración de la base de datos.

Se analiza que el origen más probable del problema está en los módulos de registro de la aplicación. Por lo que se realiza la comprobación de la causa más probable analizando la información registrada por la Gestión de incidencias e intentando reproducir el problema.

A continuación se realiza la comprobación de que el error solamente se repite en unas condiciones específicas y para un tipo de pedidos concreto, donde el cliente tiene un nombre con acento, y eliminando el acento el registro se produce correctamente.

Una vez confirmada la raíz del problema se procede a la verificación, recreando un entorno de pruebas del módulo afectado en producción y se realizan las modificaciones pertinentes en la programación para rectificar el problema. Finalmente se comprueba el correcto registro del pedido.

Una vez confirmada la solución al problema, éste se convierte en un error conocido, y se traslada a Control de Errores la responsabilidad. Control de errores creará un RFC con la solución propuesta y realizará la el sí Gestión de Cambios lo considera oportuno.

Referencia:

http://upcommons.upc.edu/bitstream/handle/2099.1/7599/Implementaci%C3%B3n%20de%20una%20metodolog%C3%ADa%20de%20procesos%20para%20la%20mejora%20de%20TI%20en%20una%20empresa%20v1.pdf

Mapa Mental U2

Gestión de Problemas.

Visión General

Las funciones principales de la Gestión de Problemas son:

·   Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.

·   Determinar posibles soluciones a las mismas.

·   Proponer las RFC (Petición de cambio) necesarias para restablecer la calidad del servicio.

·   Realizar Revisiones PIR (Revisión Post Implementación) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.

La Gestión de Problemas puede ser:

• Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.
• Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.

Objetivos

Entre la funciones principales de la Gestión de Problemas figuran:

• Identificar, registrar y clasificar los problemas.
• Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.
• Analizar y determinar las causas de los problemas y proponer soluciones.
• Elevar RFCs (Petición de cambio) a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.
• Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.
• Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto.
• Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:

• Un aumento de la calidad general de los servicios TI.
• Se minimiza el número de incidentes.
• Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.
• La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio.

Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:

• Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.
• Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI.
• Aumento de los costes por la contratación de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados. 

Proceso

Las principales actividades de la Gestión de Problemas son:

• Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.
• Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFC (Petición de cambio) que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.

Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.

Muestra los procesos implicados en la correcta Gestión de Problemas.

Proceso - Control de Problemas

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

El Control de Problemas se compone en esencia de tres fases:

1. Identificación y Registro

Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:

• La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.
• Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.
• Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.

El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.

El registro debe incorporar, entre otra, información sobre:

• Los CIs (Elementos de configuración) implicados.
• Causas del problema.
• Síntomas asociados.
• Soluciones temporales.
• Servicios involucrados.
• Niveles de prioridad, urgencia e impacto.
• Estado: activo, error conocido, cerrado.

2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración CIs (Elementos de configuración) involucrados en el mismo.

Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio).

Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.

Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI.

3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis son:

• Determinar las causas del problema.
• Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.

Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:

• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.

Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.

Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.

Proceso - Control de Errores

Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.

Identificación y Registro de errores

El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados.

Análisis y Solución

Se deben investigar diferentes soluciones para el error evaluando en cada momento:

• El posible impacto de las mismas en la infraestructura TI.
• Los costes asociados.
• Sus consecuencias sobre los SLAs (Acuerdo de nivel de servicio).

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFCs (Petición de cambio) de emergencia para su procesamiento urgente por la Gestión de Cambios.

Una vez determinada la solución óptima al problema y antes de elevar una RFCs (Petición de cambio) a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:

• ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.
• ¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?
• ¿Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá unaRFCs (Petición de cambio). Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.

Revisión Post Implementación y Cierre

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFCs (Petición de cambio) elevado a la Gestión de Cambios PIR (Revisión Post Implementación).

Si los resultados de esta PIR (Revisión Post Implementación) son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.

Control del Proceso

El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento.

En particular una buena gestión de problemas debe traducirse en una:

• Disminución del número de incidentes y una más rápida resolución de los mismos.
• Mayor eficacia en la resolución de problemas.
• Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

• Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.
• Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
• Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.

Gestión de Incidentes.

Visión General

La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.

La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Objetivos

Los objetivos principales de la Gestión de Incidentes son:

• Detectar cualquiera alteración en los servicios TI.
• Registrar y clasificar estas alteraciones.
• Asignar el personal encargado de restaurar el servicio según se define en el SLA(Acuerdo de nivel de servicio) correspondiente.

Según el libro de Soporte del Servicio de ITIL® un incidente es:

“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una RFC (Petición de Cambio) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen:

• Mejorar la productividad de los usuarios.
• Cumplimiento de los niveles de servicio acordados en el SLA(Acuerdo de nivel de servicios).
• Mayor control de los procesos y monitorización del servicio.
• Optimización de los recursos disponibles.
• Una CMDB(Base de datos de la gestión de configuraciones) más precisa pues se registran los incidentes en relación con los elementos de configuración.
• Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:

• Reducción de los niveles de servicio.
• Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.
• Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.
• Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:

• No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.
• No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
• No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

Proceso

Muestra los procesos implicados en la correcta Gestión de Incidentes.

Control del Proceso

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.

Estos informes deben aportar información esencial para, por ejemplo:

• La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLA(Acuerdo de nivel de servicio) y que se adopten medidas correctivas en caso de incumplimiento.
• Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
• Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
• Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
• Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:

• Un correcto sistema automatizado de registro de incidentes y relación con los clientes
• Una KB (Base de Conocimiento) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una KB (Base de Conocimiento) actualizada permite:
  • Evitar escalados innecesarios.
  • Convertir el “know how” de los técnicos en un activo duradero de la empresa.
  • Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs (Preguntas frecuentes) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
• Una CMDB(Base de datos de la gestión de configuraciones) que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:

• Número de incidentes clasificados temporalmente y por prioridades.
• Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
• Nivel de cumplimiento del SLA(Acuerdo de nivel de servicio).
• Costes asociados.
• Uso de los recursos disponibles en el Centro de Servicios.
• Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
• Grado de satisfacción del cliente.

Gestión de Versiones.

Visión General

La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción.

Debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB(Base de datos de la gestión de configuraciones) de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.

También debe mantener actualizada la DSL (Biblioteca de Software Definitivo), donde se guardan copias de todo el software en producción, y el DHS (Depósito de Hardware Definitivo), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.

Objetivos

Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio.

La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos.

Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI.

Entre los principales objetivos de la Gestión de Versiones se incluyen:

• Establecer una política de implementación de nuevas versiones de hardware y software.
• Implementar las nuevas versiones de software y hardware en el entorno de producción tras su verificación en un entorno realista de pruebas.
• Garantizar que el proceso de cambio cumpla las especificaciones de la RFC (Petición de Cambio) correspondiente.
• Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se ven correctamente reflejados en la CMDB(Base de datos de la gestión de configuraciones).
• Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la DSL (Biblioteca de Software Definitivo)
• Mantener actualizado el DHS (Depósito de Hardware Definitivo).

Los beneficios de una correcta Gestión de Versiones se resumen en:

• El proceso de cambio se realiza sin deterioro de la calidad de servicio.
• Las nuevas versiones cumplen los objetivos propuestos.
• Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado.
• El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
• El correcto mantenimiento de la DSL (Biblioteca de Software Definitivo) impide que se pierdan (valiosas) copias de los archivos fuente.
• Se reduce el número de copias de software ilegales.
• Control centralizado del software y hardware desplegado.
• Protección contra virus y problemas asociados a versiones de software incontroladas.

Las principales dificultades con las que topa la Gestión de Versiones son:

• No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante de la Gestión de Versiones en todo el proceso de implementación del cambio.
• No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware.
• Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no ha sido la política tradicional de la misma.
• Se realizan cambios sin tener en cuenta a la Gestión de Versiones argumentado que estos sólo son responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.
• Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable.
• La implementación sincronizada de versiones en entornos altamente distribuidos.

La solución a estos problemas pasa por:

• Un firme compromiso de la organización con la Gestión de Versiones y sus responsables.
• Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI de las ventajas de una correcta gestión de todo el proceso de cambio.

Proceso

Las principales actividades de la Gestión de Versiones se resumen en:

• Establecer una política de planificación para la implementación de nuevas versiones.
• Desarrollar o adquirir de terceros las nuevas versiones.
• Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.
• Validar las nuevas versiones.
• Implementar las nuevas versiones en el entorno de producción.
• Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.
• Actualizar la DSL, el DHS (Depósito de Hardware Definitivo) y la CMDB(Base de datos de la gestión de configuraciones).
• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.

Muestra los procesos implicados en la correcta Gestión de Versiones:

Control del Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:

• Número de lanzamientos de nuevas versiones.
• Número de back-outs y razones de los mismos.
• Incidencias asociadas a nuevas versiones.
• Cumplimientos de los plazos previstos para cada despliegue.
• Asignación de recursos en cada caso.
• Corrección y alcance de la CMDB(Base de datos de la gestión de configuraciones) y la DHS (Depósito de Hardware Definitivo).
• Existencia de versiones ilegales de software.
• Adecuado registro de las nuevas versiones en laCMDB(Base de datos de la gestión de configuraciones)
• Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.
• Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.

Gestión de Cambios.

Visión General

Las principales razones para la realización de cambios en la infraestructura TI son:

• Solución de errores conocidos.
• Desarrollo de nuevos servicios.
• Mejora de los servicios existentes.
• Imperativo legal.

El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.

Objetivos

El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.

La Gestión de Cambios debe trabajar para asegurar que los cambios:

• Están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Están convenientemente registrados, clasificados y documentados.
• Han sido cuidadosamente testeados en un entorno de prueba.
• Se ven reflejados en la CMDB(Base de datos de la gestión de configuraciones).
• Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación.

Las actividades principales de la Gestión de Cambios se resumen en:

Los principales beneficios derivados de una correcta gestión del cambio son:

• Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio.
• Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.
• Se reduce el número de "back-outs" necesarios.
• Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
• Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión.
• La CMDB(Base de datos de la gestión de configuraciones) está correctamente actualizada, algo imprescindible para la correcta gestión del resto de procesos TI.
• Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos.

La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:

• Los diferentes departamentos deben aceptar la autoridad de la Gestión 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 información sobre los CIs (Elemento de configuración) en la CMDB(Base de datos de la gestión de configuraciones).
• Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización incapacitándoles 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 dirección 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.

Conceptos básicos

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 Gestión de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.
• CAB (Consejo Asesor de Cambios): es un órgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:
• Consultores externos.
• Representantes de los colectivos de usuarios.
• Representantes de los principales proveedores de software y hardware.

Alcance de la Gestión de Cambios

En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta.

El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de Configuraciones: todos los cambios de CIs (Elemento de configuración) inventariados en la CMDB(Base de datos de la gestión de configuraciones) deben ser correctamente supervisados y registrados.

Al igual que a la hora de implementar la Gestión de Configuraciones se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas.

Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.

Proceso

Las principales actividades de la Gestión de Cambios se resumen en:

• Monitorizar y dirigir todo el proceso de cambio.
• Registrar, evaluar y aceptar o rechazar las RFC (Petición de Cambio) recibidas.
• Convocar reuniones del CAB (Consejo acesor del cambio) , excepto en el caso de cambios menores, para la aprobación de las RFC (Petición de Cambio) y la elaboración del FSC (Calendario de cambios).
• Coordinar el desarrollo e implementación del cambio.
• Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

Control del Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

• RFC (Petición de Cambio) solicitados.
• Porcentaje de RFC (Petición de Cambio) aceptados y aprobados.
• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
• Tiempo medio del cambio dependiendo del impacto y la prioridad
• Número de cambios de emergencia realizados.
• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
• Numero de back-outs con una detallada explicación de los mismos.
• Evaluaciones post-implementación.
• Porcentajes de cambios cerrados sin incidencias ulteriores.
• Incidencias asociadas a cambios realizados.
• Número de reuniones del CAB (Consejo acesor del cambio) con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.