Mapa Mental U3

Centro de Servicios (Service Desk).

Solución Real.

Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI.

Para ello se han adoptado las siguientes decisiones:

• Se ha nombrado un gestor responsable del Service Desk.
• Se han definido, tras un cuidadoso análisis de las necesidades de la organización y los usuarios, las funciones principales del mismo:
• Gestionar la primera línea de soporte de la Gestión de Incidentes.
• Supervisar la calidad del servicio ofrecido respecto a los SLAs (acuerdos de nivel de servicio).
• Ofrecer información de carácter comercial sobre los servicios ofrecidos.
• Realizar encuestas periódicas sobre el grado de satisfacción del cliente.
• Elaboración de informes periódicos con la información recopilada.
• Realizar una pequeña promoción para presentar los 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:
• Formularios de consultas y alta de incidentes.
• Consulta remota, mediante los web services asociados, del estado de los incidentes activos, históricos de incidencias y cumplimiento de los SLAs (acuerdos de nivel de servicio).
• FAQs (preguntas frecuentes) actualizadas que permitan a los usuarios consultar directamente sobre los servicios prestados, errores conocidos, etc.
• Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de interacción con los usuarios dependiendo de la situación en cuestión.
• Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del Service Desk.
• Impartir formación específica:
• Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de Atención al Cliente".
• Sobre las herramientas de software utilizadas.
• Creación de un detallado plan de implantación progresiva del Service Desk .

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.