Centro de servicios (Service Desk). Funcion. NO Proceso

Visión General El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los usuarios y la Gestión de Servicios TI.
Un Centro de Servicios, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio:
Registrando y monitorizando incidentes. Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.
Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes. Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones
Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes. Introducción y Objetivos Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad.Que les ayude a: Resolver rápidamente las interrupciones del servicio. Emitir peticiones de servicio. Informarse sobre el cumplimiento de los SLAs. Recibir información comercial en primera instancia. Diversas formas;

Call Center:

Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.

Centro de Soporte (Help Desk):

Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.

Centro de Servicios (Service Desk):

representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Ofrece otros servicios como; Supervisión de los contratos de mantenimiento y niveles de servicio. Canalización de las Peticiones de Servicio de los clientes. Gestión de las licencias de software.  Centralización de todos los procesos asociados a la Gestión TI.Los principales beneficios de una correcta implementación del Centro de Servicios ;
Reducción de costes mediante una eficiente asignación de recursos.Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo. Apertura de nuevas oportunidades de negocio.  Centralización de procesos que mejoran la gestión de la información y la comunicación. Soporte al servicio proactivo.La implementación de un SD requiere una meticulosa planificación. Cuáles son las necesidades. Cuáles han de ser sus funciones.Quiénes seran los responsables del mismo. Qué cualificaciones profesionales poseeran sus integrantes. Si se deben externalizar ciertos servicios, como, por ejemplo, el soporte técnico del hardware. Qué estructura de SD:
Distribuido, central o virtual, se adapta mejor a nuestras necesidades y las de nuestros clientes. Qué herramientas tecnológicas necesitamos. Qué métricas determinarán el rendimiento del Centro de Servicios.
Otros aspectos relacionados con el «factor humano» para el éxito del CS:
Establecer estrictos protocolos de interacción con el cliente. Motivar al personal encargado de la relación directa con el cliente.Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.Asegurar el compromiso de la dirección con la filosofía del SD.
Sondear a los clientes para conocer mejor sus expectativas y necesidades.Estructura el Centro de Servicios es «EL» punto de contacto de toda la organización TI con clientes y usuarios, es por lo tanto imprescindible que: Sea fácilmente accesible.Ofrezca un servicio de calidad consistente y homogéneo.Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos. Sirva de soporte al negocio. es necesario implementar la adecuada estructura física y lógica.Estructura lógica Los integrantes del Centro de Servicios deben: Conocer todos los protocolos de interacción con el cliente: guiones, checklists,…Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios. Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs.Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios. Recibir formación sobre los productos y servicios de la empresa. Estructura física Dependiendo de las necesidades de servicio: locales, globales, 24/7,…se debe de optar por una estructura diferente para el Centro de Servicios.
Existen tres formatos básicos:Centralizado,Distribuido,Virtual.
SD Centralizado una sola estructura central. Sus ventajas principales son: Se reducen los costes.  Se optimizan los recursos. Se simplifica la gestión. inconvenientes Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y servicios. Se necesita dar servicios de mantenimiento «on-site».

SD Distribuido

Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades, países o continentes). Sus ventajas son obvias en estos casos, sin embargo la deslocalización de los diferentes Centros de Servicios conlleva grandes problemas: Es generalmente más caro. Se complica la gestión y monitorización del servicio. Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks.
SD Virtual la situación geográfica de los Centros de Servicios puede llegar a ser irrelevante. El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos. En un SD virtual: El «conocimiento» está centralizado. Se evitan duplicidades innecesarias con el consiguiente ahorro de costes. Se puede ofrecer un «servicio local» sin incurrir en costes adicionales. La calidad del servicio es homogénea y consistente. Actividades y Funciones Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación con los clientes y usuarios. Actividades que un SD debería ofrecer para merecer ese nombre:
Gestión de Incidentes el Service Desk debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios. Entre sus tareas específicas se incluyen: Registro y monitorización de cada incidente. Comprobación de que el servicio de soporte requerido se incluye en el SLA asociado. Seguimiento del proceso de escalado. Identificación de problemas.  Cierre del incidente y confirmación con el cliente. Centro de información El SD debe informar sobre:Nuevos servicios. El lanzamiento de nuevas versiones para la corrección de errores.El cumplimiento de los SLAs.Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado. El Centro de Servicios obtener información privilegiada a todos los procesos de gestión de los servicios TI.

El Centro de Servicios es asimismo responsable de la relación con los proveedores de servicios de mantenimiento externos. Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk.
Equipo y formación La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su SD. «El éxito de su SD es el éxito de su empresa» y el mismo depende en gran medida de las personas que lo integren. Ofrecer una buena primera impresión Control del proceso La mejor medida del éxito de un Centro de Servicios es la satisfacción del client. metricas para medir el SD
Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax. Porcentaje de incidentes que se cierran en primera línea de soporte.  Porcentaje de consultas respondidas en primera instancia. Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.

 Cumplimiento de los SLAs. Número de llamadas gestionadas por cada miembro del personal del Service Desk.
Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.

Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio.

Caso Practico 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.  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. FAQs 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 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. Introducción y 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 correspondiente. Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk)
Debe jugar una papel esencial en el mismo. El siguiente diagrama resume el proceso de gestión de incidentes:
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software 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 Petición de Cambio (RFC) 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. Mayor control de los procesos y monitorización del servicio. Optimización de los recursos disponibles. Una CMDB 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. Clasificación del Incidente Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas. El nivel de prioridad se basa esencialmente en dos parámetros:

Impacto:

determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.

Urgencia:

depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA. También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes.

Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente. La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones. Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente: Escalado y Soporte Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.
Básicamente hay dos tipos diferentes de escalado:

Escalado funcional

Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.

Escalado jerárquico:

Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico. El proceso de escalado puede resumirse gráficamente* como sigue:  El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES Registro y Clasificación de Incidentes Registro La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo. Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros. El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente. Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.

Asignación de referencia

Al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.

Registro inicial

Se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados…).

Información de apoyo

Se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.

Notificación del incidente

En los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo. Clasificación La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos:

Categorización

Se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.

Establecimiento del nivel de prioridad

Dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.

Asignación de recursos

Si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).

Monitorización del estado y tiempo de respuesta esperado

Se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad. Análisis, Resolución y Cierre de Incidentes En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado. Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados. Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes. Cuando se haya solucionado el incidente se: Confirma con los usuarios la solución satisfactoria del mismo. Incorpora el proceso de resolución a la KB. Reclasifica el incidente si fuera necesario. Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente. Cierra el incidente. 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 SLAs 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 Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite:

o Evitar escalados innecesarios.

o Convertir el “know how” de los técnicos en un activo duradero de la empresa.

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

 Una CMDB 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.

 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.

Caso Práctico

El Service Desk de «Cater Matters» ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes.

Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos

El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días pero también observa que éste se ha guardado defectuosamente.

El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.

El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:

 Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.

 Registra los datos del incidente.

 Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuales 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 previendo que el incidente pueda repetirse a lo largo de la mañana.

 Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los helados solicitados.

 Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados 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 pre-calificando su 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 Peticiones

Visión general

La Gestión de Peticiones, como su nombre indica, es la encargada de atender las peticiones de los usuarios proporcionándoles información y acceso rápido a los servicios estándar de la organización TI.

Es importante aclarar qué entendemos por petición de servicio, un concepto que engloba las solicitudes que los usuarios pueden plantear al departamento de TI:

 Solicitudes de información o consejo.

 Peticiones de cambios estándar (por ejemplo cuando el usuario olvida su contraseña y solicita una nueva)

 Peticiones de acceso a servicios IT.

La Gestión de Peticiones recibe las siguientes entradas para poder iniciar su labor:

 Peticiones de servicio, planteadas por los usuarios.

 RFCs, también de la misma fuente.

 Descripción detallada del servicio, proporcionada por el Portfolio de Servicios.

 Políticas de Seguridad, de la Gestión de Seguridad.

Las principales razones que respaldan la implementación del proceso de Gestión de Peticiones en la organización TI son:

 Proporciona al departamento comercial un acceso rápido y efectivo a servicios estándar. Esto mejora su productividad, la calidad de los servicios comerciales y los propios productos.

 Reduce la burocracia asociada al proceso de petición de acceso a servicios nuevos o ya existentes, reduciendo asimismo los costes.

 Incrementa el nivel de control sobre los servicios al centralizar la concesión de acceso a los mismos.

 Reduce costes al centralizar la negociación con proveedores respecto al acceso a los servicios, y también al reducir el coste del soporte.

Introducción y Objetivos

Los objetivos de la Gestión de Peticiones incluyen:

 Proporcionar un canal de comunicación a través del cual los usuarios puedan solicitar y recibir servicios estándar para los que existe una aprobación previa.

 Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el procedimiento para obtenerlos.

 Localizar y distribuir los componentes de servicios estándar solicitados.

 Ayudar a resolver quejas o comentarios ofreciendo información general.

Las dificultades y desafíos a los que se puede enfrentar la Gestión de Peticiones son:

 A la hora de documentar y definir claramente el tipo de peticiones que van a ser gestionadas.

 Al establecer funcionalidades de autoayuda para que los usuarios interactúen mejor con el proceso de envío de peticiones.

 Si el alcance del proceso de Gestión de Peticiones no está bien definido, las personas implicadas no tendrán una idea clara sobre cómo se desarrollará.

 Si las interfaces de envío de peticiones tienen un diseño pobre o la implementación no es correcta, resultará muy complicado a los usuarios remitir sus sugerencias, quejas, etc.

 Si las aplicaciones de gestión interna no son adecuadas, la Gestión de Peticiones puede ver disminuida considerablemente su capacidad para asumir gran cantidad de trabajo.

 Una monitorización insuficiente o ineficaz.

Proceso

Las actividades incluidas en el proceso de Gestión de Peticiones son:

 Selección de peticiones. Los usuarios, a través de las herramientas destinadas a tal fin por la Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipologías predefinidas.

 Aprobación financiera de la petición. Dado que la mayoría de peticiones tienen implicaciones financieras, se considera su coste y se decide si tramitar la petición o no.

 Tramitación. La petición es cursada por la persona o personas adecuadas según cada caso.

 Cierre. Tras notificar al Centro de Servicios y comprobar desde aquél que el usuario ha quedado conforme con la gestión se procede a cerrarla.

Selección de peticiones de un menú

La Gestión de Peticiones hace posible que los propios usuarios emitan sus peticiones de servicio a través de una interfaz web. En ella, el cliente podrá escoger de entre las “peticiones tipo” predefinidas la que más se ajusta a su caso.

Esto se puede combinar con otras herramientas destinadas a enviar la petición directamente al equipo de back-end.

Aprobación financiera

La mayoría de las peticiones conllevan un gasto, independientemente de los acuerdos financieros en vigor. Por eso, antes de autorizar una petición es principal determinar primero los costes que ésta acarreará de ser cursada.

Se pueden definir, para determinadas peticiones estándares, unos precios fijos que ayuden a gestionar con rapidez aquellos casos más frecuentes.

Tramitación y cierre

Esta actividad consiste en cursar la propia petición, por lo que las acciones a desempeñar dependerán de la naturaleza de la misma.

El Centro de Servicios puede encargarse de las más simples, mientras que otras precisarán de una intervención especializada. Algunas organizaciones disponen de grupos de expertos para cursar cada tipo de petición, o incluso derivan ciertas actividades a proveedores externos.

El Centro de Servicios, independientemente de si la unidad que tramita la petición es interna o externa, debe monitorizar todo el proceso y perseguir nuevos progresos.

Una vez resuelta la petición, se notifica al Centro de Servicios para que compruebe si el usuario está satisfecho con el resultado y proceda a su cierre.

Control del proceso

 Número total de peticiones de servicio.

 Ruptura de peticiones de servicio en cada etapa.

 Tamaño de la copia de seguridad de las peticiones más destacadas.

 Tiempo medio que dura la gestión de cada tipo de petición de servicio.

 Número y porcentaje de peticiones de servicio completadas en los tiempos acordados.

 Coste medio de cada tipo de petición de servicio.

 Nivel de satisfacción del cliente con la gestión de las peticiones de servicio.

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 peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.

 Realizar Revisiones Post Implementación (PIR) 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.

Introducción y Objetivos

Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo.

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.

Cabe diferenciar entre:

Problema:

causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.

Error conocido:

Un problema se transforma en un error conocido cuando se han determinado sus causas.

Proceso

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

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 RFCs 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.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas:

Nota

Los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI

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 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) 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.

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC 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 RFC 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á una RFC. 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 RFC elevado a la Gestión de Cambios (PIR).

Si los resultados de esta PIR 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.

Caso Práctico

El Service Desk de «Cater Matters» ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.

La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:

 Identificación del problema.

 Clasificación del problema.

 Establecimiento de las posibles causas.

 Comprobación de la causa más probable.

 Verificación de la causa verdadera.

Identificación:

En nuestro caso el problema es sencillo de definir:

 La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.

Clasificación:

La clasificación se adaptaría a los siguientes parámetros:

 Identificación: Problemas en el registro de pedidos.

 Origen: Módulo de pedidos online.

 Frecuencia: el problema no es recurrente, es la primera vez que se detecta.

 Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.

Posibles causas:

Entre las causas más probables figuran:

 Errores en la programación del lado cliente de la aplicación.

 Errores en los módulos de registro del servidor web.

 Errores de configuración de la base de datos.

Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.

Comprobación de la causa más probable:

con la ayuda de la información registrada por la Gestión de Incidentes:

 Se intenta reproducir el problema.

 Se comprueba que el error sólo se reproduce con una determinada marca de helados.

 Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.

Verificación:

 Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.

 Se introducen las modificaciones necesarias en la programación.

 Se comprueba el correcto registro del pedido.

El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:

 Elevar una RFC con la solución propuesta.

 Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.

Gestión de Cambios

Visión 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 «evolución a mejor» requiere necesariamente de un cambio.

Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún 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 más peligroso el estancamiento en servicios y tecnologías desactualizados.

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.

Introducción y 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.

 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 sucintamente en el siguiente diagrama:

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 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 en la CMDB.

 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

En el resto de este capítulo 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 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.

 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 gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:

o Consultores externos.

o Representantes de los colectivos de usuarios.

o 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 inventariados en la CMDB 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 RFCs recibidas.

 Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y la elaboración del FSC.

 Coordinar el desarrollo e implementación del cambio.

 Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

Registro

El primer paso del proceso de cambio es registrar adecuadamente las RFCs.

El origen de una RFC puede ser de muy distinta índole:

Gestión de Problemas

Se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información 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 dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación 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 actualización.

Imperativo legal

Un cambio de legislación (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 periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión 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 recepción.

 Identificador único de la RFC.

 Identificador del error conocido asociado (dado el caso).

 Descripción del cambio propuesto:

o Motivación.

o Propósito.

o CIs involucrados.

o Estimación de recursos necesarios para la implementación.

o Tiempo estimado.

 Estatus: que inicialmente será el de «registrado».

Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.

La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:

 Estatus actualizado: «aceptado», «rechazado», «implementado», …

 Fecha de aceptación (denegación) del RFC.

 Evaluación preliminar de la Gestión del Cambio.

 Prioridad y categoría.

 Planes de «back out».

 Recursos asignados.

 Fecha de implementación.

 Plan de implementación.

 Cronograma.

 Revisión post-implementación.

 Evaluación final.

 Fecha de cierre.

Aceptación y Clasificación

Aceptación

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 modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. 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 a favor de dicha RFC o para que pueda ser consecuentemente modificada.

La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento.

Clasificación

Tras su aceptación se deben asignar a la RFC una prioridad y categoría 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 categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.

Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación 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 algún otro cambio de más 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 próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.

Urgente:

es necesario resolver un problema que esta provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente.

La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección.

Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.

Aprobación y Planificación

La planificación es esencial para una buena gestión del cambio.

Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de «back out» que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.

En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente.

Para su aprobación el cambio se debe evaluar minuciosamente:

 ¿Cuáles son los beneficios esperados del cambio propuesto?

 ¿Justifican esos beneficios los costes asociados al proceso de cambio?

 ¿Cuáles son los riesgos asociados?

 ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?

 ¿Puede demorarse el cambio?

 ¿Cuál 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 también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.

Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un «paquete de cambios» que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

 Se optimizan los recursos necesarios.

 Se evitan posibles incompatibilidades entre diferentes cambios.

 Sólo se necesita un plan de back-out.

 Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.

Implementación

Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión 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 asignación de recursos es la adecuada.

 El entorno de pruebas es realista y simula adecuadamente el entorno de producción.

 Los planes de «back-out» permitirán la rápida recuperación de la última configuración estable.

Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:

 Funcionalidad.

 Usabilidad.

 Accesibilidad.

La opinión 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 función tanto de la Gestión 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 percepción de mejora debe ser compartida por usuarios y clientes.

Evaluación

Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.

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 Gestión de Cambios.

 ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?

 ¿Cuál ha sido la percepción de los usuarios respecto al cambio?

 ¿Se pusieron en marcha los planes de «back-out» en alguna fase del proceso?¿Por qué?

Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.

Cambios de Emergencia

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables.

Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución 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 validación de los cambios urgentes que pueden requerir:

 La reunión urgente del CAB y/o EC si esto fuera posible.

 Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión 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 documentación asociada al cambio se realicen a posteriori.

Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.

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:

 RFCs solicitados.

 Porcentaje de RFCs 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 con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.

Caso Práctico

Los clientes y proveedores de «Cater Matters» están utilizando cada vez más los servicios online de la empresa para gestionar tanto los pedidos como la cadena de suministro.

El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.

Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más elevados niveles de servicio para incrementar su cuota de mercado.

Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su interconexión con el software de gestión interna de la organización (ERP).

Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene por objetivos:

 Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.

 Desarrollar una serie de WebServices que permitan:

o Integrar directamente el sistema de pedidos online en el ERP de la empresa.

o Realizar un seguimiento de todo el proceso de pedido.

o Gestionar remotamente junto a los proveedores toda la cadena de suministro.

 Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.

Tras registrar adecuadamente la RFC:

 Se le otorga el estatus de «aceptado» y se le asigna provisionalmente una prioridad normal y un alto impacto.

 Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web.

 Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual.

Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de Proyectos:

 Una evaluación inicial de costes y recursos necesarios.

 Una valoración del impacto de los cambios en la infraestructura TI.

 Un cronograma preliminar del proceso.

 Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios.

Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba el cambio y:

 Determina el calendario definitivo del cambio.

 Asigna los recursos, internos y externos, necesarios.

 Desarrolla un plan que permita la convivencia temporal de ambos sistemas online para asegurar la continuidad del servicio:

o Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el «back-out».

o Se desarrollarán aplicaciones de «traducción» que permitan mantener actualizadas las bases de datos antiguas para evitar la perdida de datos en caso de «back-out».

 Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.

 Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoria externa de todo el proceso.

 Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación.

Tras la implementación del cambio y en colaboración con el «Soporte al Servicio» y la «Provisión del Servicio» la Gestión de Cambios:

 Confirma el éxito del cambio:

o El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicio y disponibilidad previstos.

o El nuevo sistema funciona sin errores aparentes.

o Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios.

o Ha mejorado la productividad.

 Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.

 Evalúa el proceso.

 Da por cerrado el cambio.

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.

La Gestión de Versiones 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 de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.

La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), 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.

Introducción y 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 correspondiente.

 Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se ven correctamente reflejados en la CMDB.

 Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la Biblioteca de Software Definitivo (DSL).

 Mantener actualizado el Depósito de Hardware Definitivo (DHS).

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 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.

Conceptos básicos

Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.

Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:

Versiones mayores

Que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.

Versiones menores

Que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.

Versiones de emergencia

Modificaciones que reparan de forma rápida un error conocido.

Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique unívocamente. El sistema universalmente aceptado es:

Versiones mayores

1.0, 2.0, etc.

Versiones menores

1.1, 1.2, 1.3, etc.

Versiones de emergencia

1.1.1, 1.1.2, etc

Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).

En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.

El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión:

El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:

Versión delta

Sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.

Versión completa

Se distribuyen todos los elementos afectados ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.

Paquete de Versiones

La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos.

DSL

La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entorno TI. Esto incluye no solo sistemas operativos y aplicaciones sino también controladores de dispositivos y documentación asociada.

La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en caso de que se deban implementar los planes de back-out.

La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.

DHS

El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción.

Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).

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 y la CMDB.

 Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Versiones:

Nota:

los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.

Planificación

Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto es especialmente importante para los casos de versiones menores y

de emergencia pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.

A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:

 Cómo puede afectar la nueva versión a otras áreas del entramado TI.

 Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.

 Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.

 Qué planes de back-out son necesarios.

 Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI.

 Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito.

 Quiénes serán los responsables directos en las diferentes etapas del proceso

 Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora.

 Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos, gradual, …

 Cuál es la vida media útil esperada de la nueva versión.

 Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.

 Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión.

Desarrollo

La Gestión de Versiones es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas marcadas en las RFCs correspondientes.

A veces el desarrollo se realizara «en la casa» y muchas otras requerirá la participación de proveedores externos. En este segundo caso, la tarea de la Gestión de Versiones será la de asegurar que el paquete o paquetes de software o hardware ofrecidos cumple las especificaciones detalladas en la RFC. Asimismo, la Gestión de Versiones será la responsable de todo el proceso de configuración necesario.

El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación necesarios para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:

 Back-up automático de datos.

 Actualizaciones necesarias de las Bases de Datos asociadas.

 Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.

 Creación de logs asociados al proceso de instalación.

Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrán que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.

Validación

Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva versión con razonables garantías de éxito.

Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en consideración).

Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podrá volver a la última versión estable de una forma rápida, ordenada y sin perdidas de valiosa información.

Las principales actividades realizadas en el proceso de prueba deben incluir:

 Pruebas del correcto funcionamiento de la versión en un entorno realista.

 Pruebas de los procedimientos automáticos o manuales de instalación.

 Listas de «bugs» o errores detectados, si se diera el caso.

 Pruebas de los planes de back-out.

 Documentación para usuarios y personal de servicio.

La Gestión de Cambios será la encargada de dar la validación final a la versión para que se proceda a su instalación. Si la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación.

Implementación

Llego el momento de la verdad: la distribución de la nueva versión, también conocida como rollout.

El rollout puede ser de varios tipos:

Completo y sincronizado

Se realiza de manera integral y simultánea en todos los emplazamientos.

Fragmentado

Ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.

El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. En particular los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo este puede afectar a sus actividades diarias.

Es imprescindible determinar claramente:

 Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso.

 Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.

 Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos o parciales.

Tras la distribución la Gestión de Versiones debe asegurarse de que:

 Se incluya una copia de la versión en la DSL.

 El DHS incorpore repuestos funcionales de los nuevos CIs.

 La CMDB esté correctamente actualizada.

 Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación necesaria para poder sacar el adecuado provecho de las mismas.

Tras la implementación, la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.

Comunicación y Formación

Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.

Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena.

Es inútil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formación, no se encuentran en disposición de aprovechar sus ventajas.

La (in)formación debe estructurarse en distintos niveles:

 Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el proceso.

 Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. Durante este proceso de prueba se documentarán y analizarán:

o La experiencia subjetiva de usuario.

o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayan surgido durante el uso de la nueva versión.

o La claridad de la documentación que se pondrá a disposición del usuario final.

 Cuando se considere oportuno se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.

 Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.

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 y la DHS.

 Existencia de versiones ilegales de software.

 Adecuado registro de las nuevas versiones en la CMDB.

 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.

Caso Práctico

La Gestión de Cambios ha aprobado (véase el caso práctico del capítulo anterior) un RFC que tiene como principales objetivos:

 Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.

 Desarrollar una serie de WebServices que permitan:

o Integrar directamente el sistema de pedidos online en el ERP de la empresa.

o Realizar un seguimiento de todo el proceso de pedido.

o Gestionar remotamente junto a los proveedores toda la cadena de suministro.

 Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.

La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones de hardware y software asociadas. Para ello:

 En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades del nuevo hardware y se encarga de su compra y configuración.

 Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa las especificaciones del nuevo software y establecer un calendario de desarrollo.

 Duplica la estructura web: se compran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el «back-out».

 Se crean scripts de traducción que permitan salvar los nuevos datos en la versión anterior para evitar su perdida en caso de back-out.

 Se establece un calendario de pruebas con usuarios reales para que estos puedan probar y «aprobar» el nuevo servicio.

 Se planifica un despliegue en dos fases:

I. Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP de la empresa.

II. Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP.

 Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQs en la web que incluyen las dudas más frecuentes elevadas por los usuarios en la fase de pruebas.

 Se informa a los usuarios sobre la nueva versión y se avisa de posibles y cortas interrupciones del servicio en la fecha de instalación.

 Se procede a la instalación de la nueva versión.

 Se guarda una copia maestra de todo el software en la DSL.

 Se actualiza la CMDB.

Gestión de Configuraciones

Visión General

Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:

 Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).

 Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.

 Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.

 Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias.

Introducción y Objetivos

Es evidente que no se puede gestionar correctamente lo que se desconoce.

Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la misma. La principal tarea de la Gestión de Configuraciones es llevar un registro actualizado de todos los elementos de configuración de la infraestructura TI junto con sus interrelaciones.

Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos, en particular, de la Gestión de Cambios y Versiones.

Los objetivos principales de la Gestión de Configuraciones se resumen en:

 Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI.

 Mantener actualizada la Base de Datos de Configuraciones:

o Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,…

o Interrelación entre los CIs.

o Servicios que ofrecen los diferentes CIs.

 Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidentes, Problemas y Cambios.

Los beneficios de una correcta Gestión de Configuraciones incluyen, entre otros:

 Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs, drivers

desactualizados, etc. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema.

 Una Gestión de Cambios más eficiente.
Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas.

Reducción de costes

El conocimiento detallado de todos los elementos de configuración permite, por ejemplo, eliminar duplicidades innecesarias.

Control de licencias

Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización.

Mayores niveles de seguridad

Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades en la infraestructura.

Mayor rapidez en la restauración del servicio

Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible.

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

Una incorrecta planificación

Es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones.

Estructura inadecuada de la CMDB

Mantener actualizada una base de datos de configuraciones excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.

Herramientas inadecuadas

Es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB.

 Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto mantenimiento de la CMDB.

Falta de organización

Es importante que haya una correcta asignación de recursos y responsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones sea llevada a cabo por personal independiente y especializado.

Falta de compromiso

Los beneficios de la Gestión de Configuraciones no son inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los agentes implicados.

Definiciones

A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.

Elementos de configuración:

todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:

 Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, …

 Software: sistemas operativos, aplicaciones, protocolos de red, …

 Documentación: manuales, acuerdos de niveles de servicio, …

En resumen, todos los componentes que han de ser gestionados por la organización TI.

Base de Datos de la Gestión de Configuraciones:

esta base de datos debe incluir:

 Información detallada de cada elemento de configuración.

 Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones «padre-hijo» o interdependencias tanto lógicas como físicas

La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización.

Proceso

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

Planificación:

determinar los objetivos y estrategias de la Gestión de Configuraciones.

Clasificación y Registro:

los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos.

Monitorización y Control:

monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.

Realización de auditorías:

para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Elaboración de informes:

para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI.

Nota:

los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.

Planificación

La Gestión de Configuraciones es uno de los pilares de la metodología ITIL®por sus interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es particularmente compleja.

Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:

Designar un responsable

Una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.

 Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.

 Realizar un cuidadoso análisis de los recursos ya existentes:
Gestión de stocks, activos, etc.

 Establecer claramente:

o El alcance y objetivos.

o El nivel de detalle

o El proceso de implementación:
Orden de importancia, cronograma, …

 Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los Departamentos de Compras y Suministros

Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos.

Clasificación y Registro

La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:

Los objetivos sean realistas

Una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.

La información sea suficiente

Debe existir, al menos un registro de todos los sistemas críticos para la infraestructura TI.

Alcance

En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:

 Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios críticos.

 Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.

 Es recomendable incorporar, al menos, la documentación asociada a proyectos, SLAs y licencias.

En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes.

Nivel de detalle y Profundidad

Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel de detalle y profundidad deseados:

 Determinar los atributos que describen a un determinado CI.

 Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.

 Subcomponentes registrados independientemente.

Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:

Atributos

Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.

Relaciones

Conexión en red, impresoras conectadas, etc.

Profundidad

Tarjetas de red, discos duros, tarjetas gráficas, etc.

Nomenclatura

Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:

 La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.

 Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).

 Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y software.

Monitorización

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la degradación de la calidad del servicio.

Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).

Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de , digamos, los switches instalados a la hora de adoptar decisiones de compra de nuevo material:

Control

La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la CMDB.

El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software «en producción».

Las tareas de control deben centrarse en:

 Asegurar que todos los componentes están registrados en la CMDB.

 Monitorizar el estado de todos los componentes.

 Actualizar las interrelaciones entre los CIs.

 Informar sobre el estado de las licencias.

Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.

Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:

 Tras la implementación de una nueva CMDB.

 Antes y después de cambios mayores en la infraestructura.

 Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta.

Las auditorías deben dedicar especial atención a aspectos tales como:

 Uso correcto de la nomenclatura en los registros de los CIs.

 Comunicación con la Gestión de Cambios:
Información sobre RFCs , cambios realizados, …

 Estado de los CIs actualizado.

 Cumplimiento de los niveles de alcance y detalle predeterminados.

 Adecuación de la estructura de la CMDB con la de la estructura TI real.

Control del Proceso

Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada la información almacenada en la CMDB.

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Configuraciones, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

 Alcance y nivel de detalle de la CMDB.

 Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.

 Información sobre CIs que han estado involucrados en incidentes.

 Costes asociados al proceso.

 Sistemas de clasificación y nomenclatura utilizados.

 Informes sobre configuraciones no autorizadas y/o sin licencias.

 Calidad del proceso de registro y clasificación.

 Información estadística y composición de la estructura TI.

En pequeñas organizaciones es a veces conveniente combinar la Gestión de Configuraciones y Cambios para simplificar el proceso de control. La coordinación entre ambos procesos es un factor crítico para el éxito y ésta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total separación de estos procesos.

Caso Práctico

La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una «gran devoradora de recursos» si se establecen criterios excesivamente ambiciosos. Por ello la dirección de «Cater Matters» ha decidido, en una primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:

 Servidores de red local.

 Servidores de Internet.

 Infraestructura informática del Centro de Servicios.

 SLAs

Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de «configuraciones de referencia» aplicables a los CIs arriba descritos.

Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:

 Reducción a medio/largo plazo de los costes asociados.

 Mejora y consistencia de los servicios prestados.

 Simplificación de todos los procesos asociados al soporte al servicio: Incidencias, Problemas, Cambios, Versiones, etc.

El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de realizar un esfuerzo desmedido por lo que se han registrado:

Configuraciones de software

o Sistemas operativos.

o Aplicaciones instaladas.

o Interdependencias: relaciones padre-hijo, propietarios,…

o Documentación asociada.

Configuraciones de hardware

o Servidores y estaciones de trabajo.

o Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,…

o Documentación y controladores asociados.

 SLAs e informes de seguimiento asociados.

A su vez se han instalado herramientas de gestión que permiten la
monitorización remota de todas esas configuraciones y la realización de
auditorías periódicas automatizadas.