Curso Online de ITIL

Fuente: http://itil.osiatis.es/Curso_ITIL/

Fundamentos de la Gestión TI

Gestión de Servicios TI
Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido en una herramienta imprescindible y clave para empresas e instituciones. La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una herramienta más entre muchas otras.

Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la organización pero poco más. Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de ejemplo la Banca Electrónica. Los objetivos de una buena gestión de servicios TI han de ser:
• • • • •

Proporcionar una adecuada gestión de la calidad Aumentar la eficiencia Alinear los procesos de negocio y la infraestructura TI Reducir los riesgos asociados a los Servicios TI Generar negocio

ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:
• •

Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos El establecimiento de estrategias para la gestión operativa de la infraestructura TI

¿Qué es ITIL?
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización. ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones. A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.

ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.

Soporte al Servicio
El soporte al servicio se preocupa de de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del servicio prestado al usuario. El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporte al servicio según los estándares ITIL: Ver Animación:
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_ la_gestion_TI/que_es_ITIL/swf/soporte_al_servicio.swf

Provisión del Servicio
La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles de servicio, su disponibilidad,su continuidad, su viabilidad financiera, la capacidad necesaria de la infraestructura TI y los niveles de seguridad requeridos El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de provisión del servicio según los estándares ITIL: Ver Animación:
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_ la_gestion_TI/que_es_ITIL/swf/provision_del_servicio.swf

Forum ITSMF
El ITSMF es el único Forum completamente indpendiente reconocido por el sector de la Gestión de Servicios Informáticos. Esta asociación, con fines no lucrativos, juega un papel predominante en el desarrollo y promoción de un código de Mejores Prácticas para la gestión de estos servicios. En la actualidad, las empresas dependen cada vez en mayor medida de la tecnología para la promoción y distribución de sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares que permitan la correcta gestión de los procesos informáticos asociados. El objetivo del ITSMF es organizar una red de expertos en Gestión de Servicios Informáticos, ofrecer completa información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas que puedan encontrar en este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos servicios gracias a la utilización de un código de Mejores Prácticas. Más de 1000 compañias, grandes corporaciones y empresas públicas de todo el mundo pertenecen al ITSMF. Osiatis es en la actualidad una de las empresa responsables de las

actividades del Forum en España y Francia (Claude Durand. marcos de trabajo relacionados. Hasta la fecha.com -Forum Internacional de Gestión de Servicios TI Gestión de Servicios TI: Caso Práctico Para mejor ilustrar los contenidos de este "curso" cada capítulo incluye un caso práctico relacionado directamente con los contenidos del mismo. Todos estos casos prácticos se refieren a una compañía (ficticia) dedicada al catering. Director de Desarrollo de Osiatis Francia. se han entregado más de 50.co. y publicaciones. Enlaces de interés Podréis encontrar información adicional en: • • • http://www.nl -Organismo de Certificación http://www. Fue realizado en estrecha cooperación con la OGC y el itSMF.itil. servicios de educación y consultoría. que ha optado por introducir la metodología ITIL para la gestión de sus servicios. Desde 1990. Certificaciones ITIL EXIN e ISEB La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems Examination Board" (ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. herramientas.uk -El Sitio Oficial de ITIL http://www.exin. . El marco de mejores prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones. Gran cantidad de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como un estándar de facto para la Gestión de Servicios TI. Hoy en día. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de certificaciones en tres niveles: • • • Foundation Certificate en Gestión de Servicios TI Practitioner Certificate en Gestión de Servicios TI Manager Certificate en Gestión de Servicios TI El sistema de certificación está basado en los requisitos para representar eficazmente el papel pertinente dentro de una organización TI.000 certificados Foundation a profesionales de más de 30 países. es tesorero de la asociación en ese país). "Cater Matters". se considera a ITIL como el marco de trabajo y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos.itsmf. ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI.

La dirección de "Cater Matters". ha decidido adoptar la metodología ITIL como la base de todos sus procesos y servicios. Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción y distribución. Organización de sus actividades en torno a los procesos.. Servicios de catering para eventos (congresos. . ."Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye: • • • • Servicios de comedor de grandes empresas. La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de entrega.. Servicios de restauración para hoteles. Designación de responsables o gestores para cada uno de los procesos críticos. Establecimiento de estrictos protocolos de monitorización de la calidad del servicio. Servicios de catering para colegios. Entre las decisiones adoptadas consecuentemente caben destacar: • • • • Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes y el resto de la infraestructura TI.). tras un concienzudo análisis de la situación. actos institucionales.

en su concepción más moderna. Un Centro de Servicios. El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los servicios ofrecidos: • • • Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios. Emitir peticiones de servicio. Recibir información comercial en primera instancia. Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes. Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas. debe funcionar como centro neurálgico de todos los procesos de soporte al servicio: • • • • Registrando y monitorizando incidentes. Informarse sobre el cumplimiento de los SLAs. 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. excepto en los casos más triviales. a otras instancias de soporte y/o comerciales. 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 . del Centro de Servicios es servir de punto de contacto entre los los usuarios y la Gestión de Servicios TI. 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. Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que estan recibiendo una atención personalizada y ágil que les ayude a: • • • • Resolver rápidamente las interrupciones del servicio. eficiente y continuo e independiente de su localización geográfica. aunque no único. Introducción y Objetivos Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad.Centro de servicios (Service Desk) Visión General El objetivo primordial.

usuarios y la propia organización TI tales como: o Supervisión de los contratos de mantenimiento y niveles de servicio. Los principales beneficios de una correcta implementción del Centro de Servicios se resumen en: • • • • • Reducción de costes mediante una eficiente asignación de recursos. por ejemplo.centrado en los procesos de negocio. es imprescindible ponderar otros aspectos más directamente relacionados con el "factor humano" y que son tan importantes o más que los puramente técnicos para el éxito del Centro de Servicios: • • • • • Establecer estrictos protocolos de interacción con el cliente. o Centralización de todos los procesos asociados a la Gestión TI. Además de estas cuestiones de carácter técnico. En primera instancia debe establecerse: • • • • • • • • Cuáles son las necesidades. Qué métricas determinarán el rendimiento del Centro de Servicios. el soporte técnico del hardware. se adapta mejor a nuestras necesidades y las de nuestros clientes. Implementación La implementación de un Service Desk requiere una meticulosa planificación. Sondear a los clientes para conocer mejor sus expectativas y necesidades. Qué estructura de Service Desk: distribuido. central o virtual. Asegurar el compromiso de la dirección con la filosofía del Service Desk. Soporte al servicio proactivo. Motivar al personal encargado de la relación directa con el cliente. Apertura de nuevas oportunidades de negocio. como. Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo. Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte. Qué cualificaciones profesionales poseeran sus integrantes. Centralización de procesos que mejoran la gestión de la información y la comunicación. Cuáles han de ser sus funciones. o Canalización de las Peticiones de Servicio de los clientes. Si se deben externalizar ciertos servicios. Qué herramientas tecnológicas necesitamos. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes. El objetivo NO es implementar lo más rápidamente posible un Centro de Servicios sino implantar un Centro de Servicios cuyos objetivos se alineen con nuestros procesos de negocio. optimicen la imagen externa de . o Gestión de las licencias de software. mejoren la satisfacción de nuestros clientes. Quiénes seran los responsables del mismo.

. Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica. checklists. 24/7. es por lo tanto imprescindible que: • • • • Sea fácilmente accesible. Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios. Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios. Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos.. globales. Estructura física Dependiendo de las necesidades de servicio: locales. Recibir formación sobre los productos y servicios de la empresa...se debe de optar por una estructura diferente para el Centro de Servicios. Existen tres formatos básicos: • • • Centralizado Distribuido Virtual Describimos a continuación sus principales características: Service Desk Centralizado En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura central. Estructura lógica Los integrantes del Centro de Servicios deben: • • • • • Conocer todos los protocolos de interacción con el cliente: guiones. Ofrezca un servicio de calidad consistente y homogéneo.. Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs.. Estructura Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda la organización TI con clientes y usuarios.. Sirva de soporte al negocio.nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de negocio.

productos y servicios. Sus ventajas son obvias en estos casos. Se complica la gestión y monitorización del servicio. países o continentes). Se optimizan los recursos. Se necesita dar servicios de mantenimiento "on-site".Sus ventajas principales son: • • • Se reducen los costes. sin embargo la deslocalización de los diferentes Centros de Servicios conlleva grandes problemas: • • • Es generalmente más caro. Se simplifica la gestión. Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks. Service Desk Distribuido Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades. Sin embargo surgen importantes inconvenientes cuando: • • Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas. .

. Se puede ofrecer un "servicio local" sin incurrir en costes adicionales. En un Service Desk virtual: • • • • El "conocimiento" está centralizado.Service Desk Virtual En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de los Centros de Servicios puede llegar a ser irrelevante. La calidad del servicio es homogénea y consistente. El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos. Se evitan duplicidades innecesarias con el consiguiente ahorro de costes.

Entre sus tareas específicas se incluyen: • • Registro y monitorización de cada incidente. 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. . de que su función principal es gestionar la relación con los clientes y usuarios manteniéndoles puntualmente informado de todos aquellos procesos de su interés. Sin embargo.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. no cabe duda. A continuación describimos algunas de las actividades que un Service Desk debería ofrecer para merecer ese nombre: Gestión de Incidentes Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y personal. Comprobación de que el servicio de soporte requerido se incluye en el SLA asociado.

informando sobre: • • • • Nuevos servicios. Es imprescindible. El cumplimiento de los SLAs. evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado. "El éxito de su Service Desk es el éxito de su empresa" y el mismo depende en gran medida de las personas que lo integren. Todos hemos sufrido frustrantes experiencias con grandes empresas que prometen un soporte continuo y de alta calidad y que a la hora de la verdad disponen de un centro de contacto con personal poco preparado. Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio. . Cierre del incidente y confirmación con el cliente. 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..• • • Seguimiento del proceso de escalado. Relaciones con los proveedores El Centro de Servicios es asimismo responsable de la relación con los proveedores de servicios de mantenimiento externos. El Centro de Servicios se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos los procesos de gestión de los servicios TI. Equipo y formación La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service Desk. Identificación de problemas. El lanzamiento de nuevas versiones para la corrección de errores. cuando no directamente mal educado. . Idealmente.. para ofrecer un servicio de calidad. el personal del Service Desk debe: • Compartir la filosofía de atención al cliente de la organización. Es para ello imprescindible que se lleve un adecuado registro de toda la interacción con los usuarios y clientes. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante. Centro de información El Service Desk debe ser la principal fuente de información de los clientes y usuarios.

su satisfacción . aunque ésta. En los informes de control se deben considerar aspectos tales como: • • • • • • Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax. Comprender las necesidades de los clientes y redirigirlos. Cumplimiento de los SLAs. También es imprescindible el compromiso de la dirección con: • • • Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento. si fuera necesario. recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión. El trabajo en equipo. Control del proceso La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente. obviamente. Ser capaz de trabajar en equipo. Número de llamadas gestionadas por cada miembro del personal del Service Desk.• • • • • Comunicarse con corrección y buena educación y de una manera que el cliente pueda comprender. Porcentaje de incidentes que se cierran en primera línea de soporte. por último. La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica. Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto. a los expertos en cuestión. Un continuo apoyo al equipo en la siempre difícil tarea del trato directo con los clientes. Conocer en profundidad los servicios y productos ofrecidos. Y. Controlar todas la herramientas tecnológicas a su disposición para ofrecer un servicio de alta calidad. no sea responsabilidad exclusiva de éste. Es importante que se intenten establecer métricas bien definidas para medir el rendimiento del Centro de Servicios y la apreciación que los usuarios tienen de éste. Otra importante tarea de control es supervisar el grado de satisfacción del cliente. 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. Porcentaje de consultas respondidas en primera instancia. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.

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. o FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios prestados. tras un cuidadoso análisis de las necesidades de la organización y los usuarios. 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.respecto a la solución ofrecida. Para ello se han adoptado las siguientes decisiones: • • • • • • • • Se ha nombrado un gestor responsable del Service Desk. o Elaboración de informes periódicos con la información recopilada. Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del Service Desk. históricos de incidencias y cumplimiento de los SLAs. las funciones principales del mismo: o Gestionar la primera línea de soporte de la Gestión de Incidentes. errores conocidos. o Realizar encuestas periódicas sobre el grado de satisfacción del cliente. en la medida de los posible. mediante los web services asociados. la interacción con los usuarios a través de este medio: o Formularios de consultas y alta de incidentes. Impartir formación específica: o Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de Atención al Cliente". etc. Se han definido. proveedores y la organización TI. Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y potenciales. Creación de un detallado plan de implantación progresiva del Service Desk . o Consulta remota. etc. o Sobre las herramientas de software utilizadas. o Supervisar la calidad del servicio ofrecido respecto a los SLAs. Toda esta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio. o Ofrecer información de carácter comercial sobre los servicios ofrecidos. del estado de los incidentes activos. . Habilitar un espacio web para canalizar.

pues a diferencia de esta última. es obvio. por lo que el Centro de Servicios (Service Desk) debe jugar una papel esencial en el mismo.swf Introducción y Objetivos Los objetivos principales de la Gestión de Incidentes son: • • • Detectar cualquiera alteración en los servicios TI. Esta actividad requiere un estrecho contacto con los usuarios. Sien embargo. El siguiente diagrama resume el proceso de gestión de incidentes: . Registrar y clasificar estas alteraciones.osiatis. que existe una fuerte interrelación entre ambas. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas. no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente.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.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_inci dentes/vision_general_gestion_de_incidentes/swf/incidentes. Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil.

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. cambio de información de acceso. Optimización de los recursos disponibles. Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes. 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. 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. o puede causar. Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.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. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente. Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente. 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. una interrupción o una reducción de calidad del mismo”. etc. No están bien definidos los niveles de calidad de servicio ni los productos soportados. Mayor control de los procesos y monitorización del servicio. Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como: • • • • Reducción de los niveles de servicio. siempre que estos servicios se consideren estándar. . lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias. 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. Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.

la prioridad del incidente. Por ejemplo. Es conveniente establecer un protocolo para determinar. La prioridad del incidente puede cambiar durante su ciclo de vida. se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones. 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. 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 .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. 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. 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. en primera instancia.

integrar diferentes niveles en el caso de PYMES Proceso El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes: Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI . 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. A este proceso se le denomina escalado. asignar más recursos para la resolución de un incidente específico. o por el contrario .pueda tomar decisiones que se escapan de su responsabilidad. 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. El proceso de escalado puede resumirse gráficamente* como sigue: * El escalado puede incluir más niveles en grandes organizaciones.

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. 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.Ver Animación: http://itil.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_inci dentes/proceso_gestion_de_incidentes/swf/proceso. o que pueda ser obtenida de la propia CMDB (hardware interrelacionado). Las incidencias pueden provenir de diversas fuentes tales como usuarios. 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. descripción del incidente. los siguientes pasos: • Categorización: se asigna una categoría (que puede estar a su vez subdividida en uno o más niveles) dependiendo del tipo de incidente o del grupo de trabajo .osiatis. 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.swf 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. Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora.. El proceso de clasificación debe implementar. el mismo Centro de Servicios o el soporte técnico. gestión de aplicaciones. entre otros. al menos.).. etc. sistemas afectados. 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. 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.

Se identifican los servicios afectados por el incidente. 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. Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado. 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 halla solucionado el incidente se: • • • • • Confirma con los usuarios la solución satisfactoria del mismo. Si fuera necesario se puede emitir una Petición de Cambio (RFC). según criterios preestablecidos. Análisis. Reclasifica el incidente si fuera necesario. resuelto. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados. un nivel de prioridad. Control del Proceso La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes. Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente. suspendido. por ejemplo: . Cierra el incidente. 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. cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.• • • responsable de su resolución. Incorpora el proceso de resolución a la KB. 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). Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina. Estos informes deben aportar información esencial para. activo. Durante toda la vida del incidente los diferente agentes implicados deben actualizar la información almacenada a en las bases de datos para que todos los estamentos implicados dispongan de cumplida información sobre el estado del mismo.

• • • • • 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. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia. Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes. Uso de los recursos disponibles en el Centro de Servicios. Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente. 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. Costes asociados. o Convertir el “know how” de los técnicos en un activo duradero de la empresa. 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. Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos. Caso Práctico . Algunos de los aspectos clave a considerar son: • • • • • • • Número de incidentes clasificados temporalmente y por prioridades. Nivel de cumplimiento del SLA. Grado de satisfacción del cliente. Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Porcentaje de incidentes. 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. o Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Una (KB) actualizada permite: o Evitar escalados innecesarios. costes asociados al servicio. clasificados por prioridades. 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. etc. 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. resueltos en primera instancia por el Centro de Servicios.

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. las siguientes decisiones: • • • • • • • Evalúa la prioridad: aunque el impacto es bajo. 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. Registra los datos del incidente. Consulta. 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. Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la mañana. No consigue identificar la causa del incidente. el sistema funciona correctamente. la disponibilidad de los helados solicitados. . Da por cerrado el incidente. Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas. basándose en los protocolos establecidos. de manera general. el incidente es urgente pues el cliente necesita rápidamente el suministro.El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes. El operador toma. Por otro lado el departamento de sistemas: • • • Realiza una serie de pruebas y comprueba que. Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes del mediodía. El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando. mediante la aplicación que monitoriza las existencias de almacén. 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.

Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil. 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. Determinar posibles soluciones a las mismas. 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. . del servicio TI.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.osiatis. Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas. Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.swf Introducción y Objetivos Como se explico en la sección de Gestión de Incidentes. La Gestión de Problemas puede ser: Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_prob lemas/vision_general_gestion_de_problemas/problemas. 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. aún no identificada. real o potencial. de una serie de incidentes o un incidente aislado de importancia significativa. Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario. Cabe diferenciar entre: Problema: causa subyacente.

Disponibilidad y Niveles de Servicio. generalmente. Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en: • • • Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Aumento de los costes por la contratación de personal especializado. La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad. Analizar tendencias para prevenir incidentes potenciales. clasificar y resolver los problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar. Se minimiza el número de incidentes.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_prob lemas/introduccion_objetivos_gestion_de_problemas/swf/auxiliar2. Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI. Proceso Las principales actividades de la Gestión de Problemas son el: . Los principales beneficios de una correcta Gestión de Problemas: • • • • Un aumento de la calidad general de los servicios TI.Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de Incidentes se resumen en el siguiente interactivo: Ver Animación: http://itil. Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.swf Entre las funciones principales de la Gestión de Problemas figuran: • • • • • • • Identificar. aunque estos se vean sobradamente compensados por los beneficios derivados. en la primera línea de soporte TI ahorrando recursos e innecesarios escalados. Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches. registrar y clasificar los problemas. Analizar y determinar las causas de los problemas y proponer soluciones. Los incidentes se solucionan más rápidamente y. Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto. Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI.osiatis.

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 Ver Animación: http://itil. 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.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. Y cuando la estructura de la organización lo permite. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_prob lemas/proceso_gestion_de_problemas/swf/proceso2.osiatis.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: .swf Proceso .

en principio. 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. Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad. Un factor esencial es la determinación de la prioridad del problema. 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. . Causas del problema. 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. 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. 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. Servicios involucrados. error conocido. entre otra. 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. Síntomas asociados. Identificación y Registro Una de las tareas principales de la Gestión de Problemas es identificar los mismos. 2. El registro debe incorporar. que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo. El registro de problemas es. Clasificación y Asignación de Recursos La clasificación del problema engloba desde las características generales de éste. Sin embargo. información sobre: • • • • • • • Los CIs implicados. cerrado. Estado: activo. que al igual que en el caso de los incidentes.1. Niveles de urgencia. prioridad e impacto. tales como si es un problema de hardware o software. Soluciones temporales. 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).

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. Análisis y Diagnóstico: Error conocido Los objetivos principales del proceso de análisis son: • • Determinar las causas del problema.. Proceso . Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI. . 3.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. en caso de aplicaciones desarrolladas "en la casa".. por ejemplo.Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema. o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión. Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Es moneda frecuente que el problema este causado por: • • • • Errores de procedimiento. Documentación incorrecta. 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. Falta de coordinación entre diferentes áreas. Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. . si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.

. algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados. pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios. Los costes asociados. Sus consecuencias sobre los SLAs. siempre que esto sea posible. En algunos casos. 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. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos. 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.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. ¿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. en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio. En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. todo la información sobre el error y su solución se registrará en las bases de datos asociadas.

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). 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. 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. los tiempos de respuesta y el impacto en la Gestión de Incidentes. 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. Mayor eficacia en la resolución de problemas. la eficacia de las soluciones propuestas. 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. 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. 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. Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. 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. Sin embargo. . etc. 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.

Identificación: En nuestro caso el problema es sencillo de definir: • La aplicación de pedidos online muestra. 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. de forma no previsible. Verificación de la causa verdadera. Clasificación del problema. Clasificación: La clasificación se adaptaría a los siguientes parámetros: • • • • Identificación: Problemas en el registro de pedidos. Errores en los módulos de registro del servidor web. Posibles causas: Entre las causas más probables figuran: • • • Errores en la programación del lado cliente de la aplicación. Se comprueba que el error sólo se reproduce con una determinada marca de helados. La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido. Frecuencia: el problema no es recurrente.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. Impacto: leve. Verificación: . Comprobación de la causa más probable. Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas. que en este caso sigue el modelo de Kepner y Tregoe: • • • • • Identificación del problema. es la primera vez que se detecta. 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. El incidente ha sido resuelto sin una interrupción grave del servicio. errores en el registro de ciertos pedidos. Origen: Módulo de pedidos online. sin que este error parezca tener correlación con otros componentes de hardware / software. Establecimiento de las posibles causas.

es ahora tarea del Control de Errores: • • Elevar una RFC con la solución propuesta. Se comprueba el correcto registro del pedido. El problema se ha convertido en un error conocido. . Se introducen las modificaciones necesarias en la programación.• • • Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción. Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.

Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias.osiatis. Las interacciones y funcionalidades de la Gestión de Configuraciones se resumen sucintamente en el siguiente interactivo: Ver animación: http://itil. realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.swf Introducción y Objetivos Es evidente que no se puede gestionar correctamente lo que se desconoce.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_conf iguraciones/vision_general_gestion_de_configuraciones/swf/gestion_conf iguraciones. de la Gestión de Cambios y Versiones. Mantener actualizada la Base de Datos de Configuraciones: . 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. Interactuar con las Gestiones de Incidentes.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. 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. en particular. Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la misma. Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos. encontrar rápidamente la causa de los problemas. Problemas . 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.

eliminar duplicidades innecesarias. a la Gestión de Incidentes. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización. Servir de apoyo a los otros procesos. que redunda en una mayor calidad de servicio. detectar vulnerabilidades en la infraestructura. ubicación.. lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los agentes implicados. o Interrelación entre los CIs. o Los beneficios de una correcta Gestión de Configuraciones incluyen. estado. o Servicios que ofrecen los diferentes CIs. Mayores niveles de seguridad. Control de licencias. tipo. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs. entre otros: • • • • • • Resolución más rápida de los problemas.. 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. Es preferible. drivers desactualizados. Reducción de costes. 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. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas. Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto mantenimiento de la CMDB.• Registro actualizado de todos los CIs : identificación. El conocimiento detallado de todos los elementos de configuración permite. Una Gestión de Cambios más eficiente. Falta de compromiso: los beneficios de la Gestión de Configuraciones nos son inmediatos y son casi siempre indirectos. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema. cuando sea posible. etc. Definiciones . 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. Una CMDB actualizada permite. Problemas y Cambios. Mayor rapidez en la restauración del servicio. Falta de organización: es importante que haya una correcta asignación de recursos y responsabilidades.. Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB. en particular. etc. por ejemplo. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus. por ejemplo. que la Gestión de Configuraciones sea llevada a cabo por personal independiente y especializado.

impresoras. protocolos de red. routers. acuerdos de niveles de servicio. . Proceso Las principales actividades de la Gestión de Configuraciones son: Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones. Ver animación: . teclados.. Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual. . Software: sistemas operativos. Elementos de configuración: tanto todas las componentes de los servicios TI como los servicios que estos nos ofrecen constituyen diferentes elementos de configuración. por ejemplo. Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir: • • Información detallada de cada elemento de configuración. etc.. todos los componentes que han de ser gestionados por la organización TI. Documentación: manuales.. A modo de ejemplo citaremos: • • • Dispositivos de hardware como PCs. 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. Interrelaciones entre los diferentes elemento de configuración... nivel de profundidad y nomenclatura predefinidos.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. lectores de CDs. monitores. 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. En resumen. Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI. aplicaciones. así como sus componentes: tarjetas de red. Clasificación y Registro: los CIs deben ser registrados conforme al alcance. 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. como.. .

Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks. 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. al menos. Establecer claramente: o El alcance y objetivos. cronograma. para llevar esta labor con éxito. activos. Es imprescindible. etc..es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_conf iguraciones/proceso_gestion_de_configuraciones/swf/proceso. 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. Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable. La información sea suficiente: debe existir.swf 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. Coordinar el proceso estrechamente con la Gestión de Cambios. . o El nivel de detalle o El proceso de implementación: orden de importancia. 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. destacar algunos puntos que consideramos esenciales: • • • • • Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.http://itil. Por ello su implantación es particularmente compleja. en una dejación de responsabilidades.osiatis. a la larga.. al menos un registro de todos los sistemas críticos para la infraestructura TI. creemos conveniente. 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 complementa 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 areal.

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 una factor crítico para el éxito y ésta unificación puede resultar beneficiosa en aquellos caso 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:

.. o Subcomponentes con sus interrelaciones: relaciones padre-hijo. SLAs e informes de seguimiento asociados.. interdependencias. Configuraciones de hardware: o Servidores y estaciones de trabajo... o Interdependencias: relaciones padre-hijo. o Documentación y controladores asociados..• • • Configuraciones de software: o Sistemas operativos. propietarios. . o Aplicaciones instaladas. 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. o Documentación asociada.

. Sin embargo. es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona. Tendemos a asociar la idea de cambio con la de progreso. Las principales razones para la realización de cambios en la infraestructura TI son: • • • • Solución de errores conocidos.osiatis. no lo toques". si éste se lleva a cabo. Mejora de los servicios existentes. siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_camb ios/vision_general_gestion_de_cambios/swf/gestion_cambios. se haga de la forma más eficiente. La Gestión de Cambios debe trabajar para asegurar que los cambios: • • • • • Están justificados. Están convenientemente registrados. Han sido cuidadosamente testeados en un entorno de prueba. es evidente que toda "evolución a mejor" requiere necesariamente de un cambio. Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas.Gestión de Cambios Visión General Vivimos en una época de continuos cambios. puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados. Las interacciones y funcionalidades de la Gestión de Cambios se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil. clasificados y documentados.swf 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. 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. Se llevan a cabo sin perjuicio de la calidad del servicio TI. Se ven reflejados en la CMDB. y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias. y aunque esto no sea necesariamente así. Desarrollo de nuevos servicios.

• 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 reduce el número de "back-outs" necesarios. Los cambios son mejor aceptados y se evitan "tendencias inmovilistas". 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 evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión. .

servicios. Sin embargo. algo imprescindible para la correcta gestión del resto de procesos TI. No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados. 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. necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad. mejorar un servicio o adaptarse a requisitos legales. no se actualiza correctamente la información sobre los CIs en la CMDB. 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 algunos casos también puede incorporar: o Consultores externos. . 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. No se siguen los procedimientos establecidos y. Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso. o Representantes de los colectivos de usuarios.• • La CMDB está correctamente actualizada. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas. Los encargados de la Gestión de Cambios no conocen a fondo las actividades. en particular. 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). independientemente de que este se realice para solucionar un problema. presidido por el Gestor de Cambios. formado principalmente por representantes de las principales áreas de la gestión de servicios TI. o Representantes de los principales proveedores de software y hardware. Consejo Asesor de Cambios (CAB): es un órgano interno.

Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta. Proceso . realizar los cambios asociados a las configuraciones de referencia antes citadas. 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. es importante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados para. todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. por ejemplo. 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. 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.Alcance de la Gestión de Cambios En principio. un PC de referencia con todas sus componentes de hardware y software predefinidas).

cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura. Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. El origen de una RFC puede ser de muy distinta índole: • • • • • • Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados. por ejemplo. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad. excepto en el caso de cambios menores. etc.swf Registro El primer paso del proceso de cambio es registrar adecuadamente las RFCs. Evaluar los resultados del cambio y proceder a su cierre en caso de éxito. Otro: en principio cualquier empleado. Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_camb ios/proceso_gestion_de_cambios/swf/proceso. Coordinar el desarrollo e implementación del cambio. a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM. Convocar reuniones del CAB. 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. software y/o procedimientos. 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.Las principales actividades de la Gestión de Cambios se resumen en: • • • • • Monitorizar y dirigir todo el proceso de cambio. y que por regla general requieren de cambios de hardware. evaluar y aceptar o rechazar las RFCs recibidas. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. Ver Animación: http://itil. la LOPD) puede exigir cambios en la infraestructura TI. para la aprobación de las RFCs y la elaboración del FSC. Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar.osiatis. por ejemplo. Imperativo legal: un cambio de legislación (como. . Registrar. No siempre un cambio implica una RFC. 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.

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. Evaluación final. Fecha de cierre. o Tiempo estimado. Identificador del error conocido asociado (dado el caso). Planes de "back out".Independientemente de su origen el correcto registro inicial de una RFC requerirá. Recursos asignados. "implementado". 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. o Estimación de recursos necesarios para la implementación. de los siguientes datos: • • • • • Fecha de recepción. Aceptación y Clasificación Aceptación Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Prioridad y categoría. . o CIs involucrados. Evaluación preliminar de la Gestión del Cambio. 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. Fecha de implementación. Identificador único de la RFC. . Plan de implementación. La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos: • • • • • • • • • • • • Estatus actualizado: "aceptado". Estatus: que inicialmente será el de "registrado". Revisión post-implementación. Descripción del cambio propuesto: o Motivación. 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... "rechazado". o Propósito. cuando menos. Fecha de aceptación (denegación) del RFC. Cronograma.

Pero esto obviamente no es suficiente.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. los plazos previstos y el nivel de autorización requerido para la implementación del cambio. se decidan actualizar ciertos paquetes de software o se compre nuevo hardware. 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. La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. Urgente: es necesario resolver un problema que esta provocando una interrupción o deterioro grave del servicio. los siguientes niveles de prioridad: • • • • Baja: puede ser conveniente realizar este cambio junto a otros cuando. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. 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. . 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. Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. al menos. disponer siempre de planes de "back out" que permitan la recuperación de la última configuración estable antes del cambio. Aprobación y Planificación La planificación es esencial para una buena gestión del cambio. Es imprescindible. por ejemplo. Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que incluyera. Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad. como mínimo. 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. etc. 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 cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.

Se evitan posibles incompatibilidades entre diferentes cambios.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. algo de lo que se encarga habitualmente la Gestión de Versiones. Esto tiene algunas ventajas: • • • • Se optimizan los recursos necesarios. 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. Sólo se necesita un plan de back-out. Se cumplen los calendarios previstos y la asignación de recursos es la adecuada. Se simplifica el proceso de actualización de la CMDB y la revisión postimplementación. 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 lo es de supervisar y coordinar todo el proceso. Implementación Aunque la Gestión de Cambios NO es la encargada de implementar el cambio. 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. 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.

Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes. ¿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. 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. 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. Es función tanto de la Gestión de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y. Comunicando las ventajas asociadas. Usabilidad. 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. dentro de lo posible. 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). ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la . Cualquier interrupción del servicio de alto impacto.Si es posible. hacerles participes del mismo: • • • Escuchando sus sugerencias. Cambios de Emergencia Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables. Los clientes y proveedores no deben percibir el cambio como algo inesperado.

Por ejemplo. Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente. 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. Incidencias asociadas a cambios realizados. configuraciones registradas incorrectas. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia. Caso Práctico . Porcentaje de cambios exitosos en primera instancia. que serían fuente de nuevas incidencias y problemas. etc. Tiempo medio del cambio dependiendo del impacto y la prioridad Número de cambios de emergencia realizados. debe encontrar una respuesta inmediata. 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. sin embargo. segunda instancia. esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. 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. Es. 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). duración. Numero de back-outs con una detallada explicación de los mismos. nº de cambios aprobados por reunión. Porcentajes de cambios cerrados sin incidencias ulteriores. Número de reuniones del CAB con información estadística asociada: número de asistentes. Si esto no fuera así se podrían provocar situaciones de cambios futuros incompatibles.organización. Control del Proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios. Porcentaje de RFCs aceptados y aprobados. etc. El procedimiento a seguir en estos casos debe estar debidamente previsto. Evaluaciones post-implementación. etc.

aunque cumple básicamente con los objetivos de negocio. 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 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. o Gestionar remotamente junto a los proveedores toda la cadena de suministro. Tras registrar adecuadamente la RFC: • • • Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad normal y un alto impacto. 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 otro lado. Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual. no estaba diseñado para soportar un nivel de actividad elevado. Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web. o Realizar un seguimiento de todo el proceso de pedido.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. Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios. Previamente a la reunión del CAB el Gestor del Cambio elabora. de la Disponibilidad. en estrecha colaboración con las Gestiones de la Capacidad. Desarrollar una serie de WebServices que permitan: o Integrar directamente el sistema de pedidos online en el ERP de la empresa. Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores. Financiera y de Niveles de Servicio. El sistema implantado en la actualidad. así como con la dirección y Gestión de Proyectos: • • • • Una evaluación inicial de costes y recursos necesarios. 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. . Una valoración del impacto de los cambios en la infraestructura TI. Un cronograma preliminar del proceso.

Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio. o Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios. necesarios. Se asegura que todo el cambio ha sido correctamente registrado en la CMDB. o El nuevo sistema funciona sin errores aparentes. 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".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. Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación. Asigna los recursos. . Da por cerrado el cambio. 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". o Ha mejorado la productividad. internos y externos. Evalúa el proceso. 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. Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoria externa de todo el proceso.

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. 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. 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. 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.osiatis. Las interacciones y funcionalidades de la Gestión de Versiones se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil. y el Depósito de Hardware Definitivo (DHS). 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.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_vers iones/vision_general_gestion_de_versiones/swf/gestion_versiones. Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI. 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. poner a prueba e instalar en el entorno de producción los cambios preestablecidos. .swf 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.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.

Control centralizado del software y hardware desplegado. Se reduce el número de copias de software ilegales. La implementación sincronizada de versiones en entornos altamente distribuidos. Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. así como de toda su documentación asociada. Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado. 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. . Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización. Hay resistencias a aceptar posibles planes de "back-out". 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. 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. 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. No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware. Archivar copias idénticas del software en producción. Las nuevas versiones cumplen los objetivos propuestos. El correcto mantenimiento de la DSL impide que se pierdan (valiosas) copias de los archivos fuente. 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. que todos los cambios se ven correctamente reflejados en la CMDB. 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. en la Biblioteca de Software Definitivo (DSL). La solución a estos problemas pasa por: • • Un firme compromiso de la organización con la Gestión de Versiones y sus responsables. Mantener actualizado el Depósito de Hardware Definitivo (DHS). Protección contra virus y problemas asociados a versiones de software incontroladas.• • • Asegurar. en colaboración con la Gestión de Cambios y Configuraciones. sobre todo cuando ésta no ha sido la política tradicional de la misma.

1.2.0. Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique unívocamente. En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo. 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. El sistema universalmente aceptado es: • • • Versiones mayores: 1.1. etc. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.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.3. El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión: .1. pruebas. por ejemplo. etc.2. etc Aunque en algunos casos esta clasificación se refina aún más (vea. 2. Versiones menores: 1. en: • • • Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad. etc. Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido. características técnicas. 1. producción y archivado. según su impacto en la infraestructura TI.1. Versiones de emergencia: 1. 1.0. Las versiones pueden clasificarse.1. en la ayuda la versión de su navegador).

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.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. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Esto incluye no solo sistemas operativos y aplicaciones sino también controladores de dispositivos y documentación asociada. 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. de esta forma se ofrece una mayor estabilidad al entorno TI. . La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos. 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. Desarrollar o adquirir de terceros las nuevas versiones. en la migración aun nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos. Entre las opciones más habituales cabe contar: • • • Versión delta: sólo se testean e instalan los elementos modificados. 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). DHS El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción. Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no. Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones. 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. DSL La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entorno TI. por ejemplo. Pensemos.

Qué tipo de despliegue es el más adecuado: completo.swf Planificación Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión. Actualizar la DSL. 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. Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción. . Cuál es la vida media útil esperada de la nueva versión. 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.• • • • • • Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.osiatis. . Qué planes de back-out son necesarios. 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.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_vers iones/proceso_gestion_de_versiones/swf/proceso. delta... Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario. 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. Ver Animación: http://itil. sincronizado en todas los emplazamientos. 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. 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. Implementar las nuevas versiones en el entorno de producción. gradual. Validar las nuevas versiones. Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión. el DHS y la CMDB.

En este segundo caso. Las principales actividades realizadas en el proceso de prueba deben incluir: • Pruebas del correcto funcionamiento de la versión en un entorno realista. . si esto fuera necesario o simplemente recomendable. Actualizaciones necesarias de las Bases de Datos asociadas. Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión. 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. la Gestión de Versiones será la responsable de todo el proceso de configuración necesario. Asimismo. Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos. 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. Parte integrante del desarrollo lo componen los planes de back-out asociados. A veces el desarrollo se realizara "en la casa" y muchas otras requerirá la participación de proveedores externos. Creación de logs asociados al proceso de instalación. Estos scripts deberán tener en cuenta aspectos tales como: • • • • Back-up automático de datos. El desarrollo debe incluir. 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. 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). todos los scripts de instalación necesarios para el despliegue de la versión. ordenada y sin perdidas de valiosa información.• • Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.

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. etc. también conocida como rollout. Implementación Llego el momento de la verdad: la distribución de la nueva versión. Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas. Si la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación. introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas . El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. incidentes. Listas de "bugs" o errores detectados. la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los comentarios. quejas. Es imprescindible determinar claramente: • • • Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso. Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos o parciales. La CMDB esté correctamente actualizada. El DHS incorpore repuestos funcionales de los nuevos CIs. Tras la distribución la Gestión de Versiones debe asegurarse de que: • • • • Se incluya una copia de la versión en la DSL. 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.• • • • Pruebas de los procedimientos automáticos o manuales de instalación. El rollout puede ser de varios tipos: • • Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos. Por ejemplo. si se diera el caso. Tras la implementación. Fragmentado: ya sea bien espacial o temporalmente. que la nueva versión haya podido suscitar. Documentación para usuarios y personal de servicio. En particular los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo este puede afectar a sus actividades diarias. Pruebas de los planes de back-out.

que cuando se aborden cuestiones de carácter técnico se obvie el factor humano. 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. 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. Existencia de versiones ilegales de software. no se encuentran en disposición de aprovechar sus ventajas. Durante este proceso de prueba se documentarán y analizarán: o La experiencia subjetiva de usuario. Corrección y alcance de la CMDB y la DHS. Salvo contadas excepciones. y a su vez un grave error. es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena. o La claridad de la documentación que se pondrá a disposición del usuario final. o Las dudas que hayan surgido durante el uso de la nueva versión. Comunicación y Formación Es frecuente. 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.correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios. en el proceso. . Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. Control del Proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones. debido a una incompleta (in)formación. o Los comentarios y sugerencias sobre usabilidad y funcionalidad. Es inútil disponer de un sofisticado servicio TI si los usuarios . a su discreción. Asignación de recursos en cada caso. Incidencias asociadas a nuevas versiones. Cumplimientos de los plazos previstos para cada despliegue. 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.

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. 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. Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión. prueba y distribución de las nuevas versiones de hardware y software asociadas. Desarrollar una serie de WebServices que permitan: o Integrar directamente el sistema de pedidos online en el ERP de la empresa. Se establece un calendario de pruebas con usuarios reales para que estos puedan probar y "aprobar" el nuevo servicio. Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores. Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP. o Realizar un seguimiento de todo el proceso de pedido. . 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. o Gestionar remotamente junto a los proveedores toda la cadena de suministro. Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa las especificaciones del nuevo software y establecer un calendario de desarrollo. 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. Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios. compra. Se procede a la instalación de la nueva versión. Se planifica un despliegue en dos fases: I.• • • Adecuado registro de las nuevas versiones en la CMDB. Se guarda una copia maestra de todo el software en la DSL. La Gestión de Versiones es la encargada del proceso de desarrollo. Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP de la empresa. 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. II. 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 actualiza la CMDB. .

de forma que estos sean asumibles tanto por el cliente como por la organización TI. La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y expectativas del cliente y los costes de los servicios asociados. negocian y supervisan la calidad de los servicios TI ofrecidos.Gestión de Niveles de Servicio Visión General El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente. no es un fin en sí misma sino un medio para aportar valor a los usuarios y clientes. La tecnología. Las interacciones y funcionalidades de la Gestión de Niveles de Servicio se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil.osiatis. La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de negocio y todo ello a unos costes razonables.swf Introducción y Objetivos La Gestión de Niveles de Servicio es el proceso por el cual se definen. La Gestión de los Niveles de Servicio debe: . Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio: • • • Conozca las necesidades de sus clientes. Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs. Defina correctamente los servicios ofrecidos.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_nive les_de_servicio/vision_general_gestion_de_niveles_de_servicio/swf/gest ion_niveles_servicio. al menos en lo que respecta a la gestión de servicios TI.

) para llevar una relación fluida con clientes y proveedores. Centrarse en el cliente y su negocio y no en la tecnología. El personal del Service Desk dispone de la documentación necesaria (SLAs. OLAs. Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de actuación en caso de deterioro del servicio. Los SLAs son excesivamente prolijos y técnicos incumpliendo así sus objetivos primordiales. . No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente. Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente.• • • • • • • • Documentar todos los servicios TI ofrecidos. Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente. Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades. La gestión TI conoce y comprende los servicios ofrecidos lo que facilita los acuerdos con proveedores y subcontratistas. Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos. Se establecen claramente las responsabilidades respectivas de los clientes y proveedores del servicio. Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante los clientes. Establecer los indicadores claves de rendimiento del servicio TI. Presentar los servicios de forma comprensible para el cliente. Los principales beneficios de una correcta Gestión de Niveles de Servicio son: • • • • • • • • • Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente. Lo que repercute a la larga en una mejora del servicio con la consecuente satisfacción de clientes y usuarios. Se establecen objetivos claros y metrizables. Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos. Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en: • • • • No existe una buena comunicación con clientes y usuarios por lo que los SLAs acordados no recogen sus necesidades reales. La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para su mejora.etc. Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP).

Conceptos básicos Proveedores.• • • • No se dedican los recursos suficientes pues la dirección los considera como un gasto añadido y no como parte integral del servicio ofrecido. No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs dificultando así la mejora de la calidad del servicio. Problemas de comunicación: no todos los usuarios conocen las características del servicio y los niveles de calidad acordados. No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido. Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente. . clientes y usuarios Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos. Usuarios: las personas que utilizan el servicio.

Incluir. Estimación de recursos. El Catálogo de Servicios debe: • • • • Describir los servicios ofrecidos de manera no técnica y comprensible para clientes y personal no especializado. Encontrarse a disposición del Service Desk y todo el personal que se halle en contacto directo con los clientes. en líneas generales. asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados. Hojas de Especificación Las Hojas de Especificación son. sirviendo de documento de base para la elaboración de los OLAs y UCs correspondientes. Procedimientos de monitorización de proveedores. En resumen. Utilizarse como guía para orientar y dirigir a los clientes. primordialmente. los niveles de servicio asociados con cada uno de los servicios ofrecidos. documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente. El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs correspondientes. el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados. Requisitos de Nivel de Servicio (SLR) El SLR debe incluir información detallada sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de servicios. .Catálogo de Servicios El Catálogo de Servicios no es sólo una herramienta imprescindible a la hora de simplificar la comunicación con el cliente sino que también puede ser una gran ayuda tanto a la organización interna como a la proyección exterior de la organización TI. Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos. Indicadores clave de rendimiento. Programa de Calidad del Servicio (SQP) El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del servicio: • • • • Objetivos de cada servicio.

Acuerdo de Nivel de Operación (OLA) El OLA es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio. o Desarrollo de SLAs tipo. niveles de calidad. El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a disposición de los gestores de los otros procesos TI. o cuando menos comprensible para el cliente. . Implementación de los Acuerdos de Nivel del Servicio: o Negociación. Programa de Mejora del Servicio (SIP) El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio como propuestas de mejora basadas en el avance de la tecnología. por tanto. o Herramientas para la monitorización de la calidad del servicio. es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción. etc. o Acuerdos de Nivel de Operación.Acuerdo de Nivel de Servicio (SLA) El SLA debe recoger en un lenguaje no técnico. Proceso Las principales actividades de la Gestión de Niveles de Servicio se resumen en: • • • Planificación: o Asignación de recursos. Hojas de Especificación del Servicio y Plan de Calidad del Servicio(SQP). o Análisis e identificación de las necesidades del cliente. o Elaboración de un catálogo de servicios. o Control de los proveedores externos. o Elaboración del los Requisitos de Nivel de servicio(SLR). Supervisión y revisión de los Acuerdos de Nivel de Servicio: o Elaboración de informes de rendimiento. tiempos de recuperación. disponibilidad. el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados. o Contratos de Soporte. Tras su firma. Contratos de Soporte (UC) Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI. todos los detalles de los servicios brindados.

resulta imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_nive les_de_servicio/proceso_gestion_de_niveles_de_servicio/swf/proceso. etc. los productos y servicios ofrecidos junto a indicaciones generales del nivel de servicio ofrecido. Si los servicios no se adecuan a las necesidades del cliente. Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI. la calidad de los mismos es deficiente o sus costes son desproporcionados. tiempos de respuesta. Todo el proceso de planificación previo debe estar orientado a dar respuestas a las siguiente preguntas: • • • • • • ¿Qué servicios debemos ofrecer a nuestros clientes? ¿Cuáles son las necesidades de nuestros clientes? ¿Cuál es el nivel adecuado de calidad de servicio? ¿Quiénes y cómo se van a suministrar esos servicios? ¿Cuáles serán los indicadores clave de rendimiento para los servicios prestados? ¿Disponemos de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados? La respuesta a cada una de estas preguntas debe darse en forma de documentos. En primer lugar la Gestión de Niveles de Servicio debe poner a disposición de toda la organización. en un lenguaje comprensible para los no expertos. El objetivo primordial de la Gestión de Niveles de Servicio es definir. La elaboración de este Catálogo de Servicios puede resultar una tarea compleja pues es necesario alinear aspectos técnicos con políticas de negocio pero es un documento imprescindible pues: . tales como disponibilidad.osiatis. algunos de carácter interno y otros accesibles a los clientes. Ver Animación: http://itil. negociar y monitorizar la calidad de los servicios TI ofrecidos. Y.o Elaboración de Programas de Mejora del Servicio (SIP). tendremos clientes insatisfechos y la organización TI será responsable de las consecuencias que se deriven de ello. pero en especial a disposición del Service Desk y la fuerza de ventas un Catálogo de Servicios. si esto no fuera ya de por sí una labor lo suficientemente compleja.swf Planificación La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los estamentos de la organización TI. que pasamos a describir sucintamente a continuación. Este catálogo de servicios debe describir.

sobre como se prestará el servicio. Tiempo y procedimientos de implantación del servicio. con todos los detalles técnicos necesarios. Los niveles de calidad del servicio.• • • • Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades. está información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con el cliente y su responsables técnicos. La continuidad del servicio. Las Hojas de Especificación del Servicio deben contener: • • • Una descripción detallada. en la mayoría de los casos. la complejidad de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente. La escalabilidad del servicio ofrecido. En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan global que permita asignar los recursos a la organización TI. La información contenida en el SLR debe servir de base para elaborar la documentación interna que permita determinar "cómo" se prestara el servicio y "quién o quiénes" serán responsables del mismo. Cómo se implementará el servicio. Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su infraestructura. La interacción del servicio con su infraestructura TI o de otro tipo. Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio (SLR) que debe reflejar las necesidades del cliente y sus expectativas respecto a: • • • • • • • • La funcionalidad y características del servicio. Puede ser utilizado como herramienta de venta. Cuáles serán los indicadores internos de rendimiento y calidad del servicio. La disponibilidad del servicio. establecer metas claras basadas en los indicadores de rendimiento elegidos y asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos asumidos por la organización. por muy detallado y completo que sea el Catálogo de Servicios. Evita malentendidos entre los diferentes actores implicados en la prestación de servicios. El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios. Etc. Delimita las funciones y compromisos de la organización TI. Sin embargo. .

Acuerdos de Nivel de Servicio Los SLAs deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles más específicos del servicio. A pesar de esta diferencia crucial. Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupo involucrado reciba exclusivamente la información correspondiente al nivel en que se integra.En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de los servicios el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos. por su naturaleza. Aspectos culturales locales. Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo. El OLA. Implementación La fase de planificación debe concluir con el elaboración y aceptación de los acuerdos necesarios para la prestación del servicio. los UCs pueden considerarse como una extensión "externa" de los OLAs en el sentido de que persiguen el mismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio. los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados. ya sea en el lado del cliente como del proveedor. involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero que resultan imprescindibles a la organización TI para su organización. La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran: • • • La naturaleza del negocio del cliente. . Acuerdos de Nivel de Operación Los OLAs son documentos de carácter interno de la propia organización TI que determinan los procesos y procedimiento necesarios para ofrecer los niveles de servicio acordados con los clientes. Estos acuerdos incluyen los Acuerdos de Nivel de Servicio. Aspectos organizativos del proveedor y cliente. Contratos de Soporte Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios. Niveles de Operación y Contratos de Soporte.

de los clientes y usuarios. . con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio. los SLAs en vigencia y la evolución del Catálogo de Servicios. Quejas. su rentabilidad y la satisfacción de los clientes y usuarios. Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs. etc. Los informes de rendimiento elaborados deben cubrir factores clave tales como: • • • • • • • • Cumplimiento de los SLAs. UCs. Las principales fuentes principales de información las constituyen: • • • • La documentación disponible: SLAs. La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la organización como los relacionados con la percepción de los usuarios. Costes reales del servicio ofrecido. Utilización de la capacidad predefinida. Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes. La Gestión de la Capacidad y la Disponibilidad: que debe proporcionar la información sobre la infraestructura utilizada para satisfacer la calidad de servicios acordada. La Gestión de Incidentes: que debe informar de las incidencias en el servicio y los tiempos de recuperación. Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experiencia previa. Disponibilidad del servicio. El Centro de Servicios (Service Desk): que mediante su trato diario con los clientes. Tiempos de respuesta. usuarios y organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos. Problemas detectados y cambios realizados para restaurar la calidad del servicio.Monitorización El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorar progresivamente la calidad del servicio ofrecido. Revisión La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de los servicios ofrecidos. justificadas o no. OLAs.

evidentemente. Cumplimiento de los niveles de servicio. o Encuestas de satisfacción del cliente. Evaluación del rendimiento y capacitación del personal involucrado. Avances tecnológicos. Gestión de Problemas. Es esencial disponer de: • • • • Unos objetivos claros y contrastables. Reasignación de recursos. en estos casos sea inexcusable. o Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad del servicio. Percepción del cliente y usuarios sobre la calidad de servicio. Control del Proceso El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del cliente pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados. etc. Necesidades de formación adicional a los usuarios de los servicios. Cumplimiento de los OLAs y UCs relacionados. Nuevas necesidades del cliente. El resultado de la revisión debe ser un Programa de Mejora del Servicio (SIP) que tome en cuenta factores tales como: • • • • • • • • • • • Problemas relacionados con el servicio TI y sus posibles causas. Un equipo con experiencia liderado por un Gestor de Niveles de Servicio con la cualificación y experiencia necesarios. sino que debe tener como objetivo mejorar y homogeneizar la calidad del servicio. Indicadores específicos de rendimiento tales como: o Porcentaje de servicios amparados bajo SLAs. Implicaciones de una degradación de la calidad del servicio en la estructura organizativa del cliente.Este proceso de revisión no debe limitarse a aquellos SLAs que por una razón u otra han sido incumplidos. o SIPs elaborados e impacto de los mismos en la calidad del servicio. Evaluación de los costes reales del servicio. El SIP debe ser el documento base para negociar la renovación del SLA con el cliente y debe constituir un documento de referencia para la gestión de otros procesos TI como la Gestión de Cambios. Una asignación clara de tareas y responsabilidades. La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Niveles de Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y la provisión de los servicios TI. aunque. Entre la documentación generada cabría destacar: .

Desarrollo de un Plan Integral de Calidad del Servicio. Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas. Gestor de Niveles de Servicio La dirección ha encargado a uno de sus directivos con más amplia experiencia en la relación con los clientes asumir el puesto de Gestor de Niveles de Servicio.• • • Informes Estadísticos de Rendimiento: donde se detallen los SLAs. Su principal función es negociar y acordar. Creación de "plantillas" para la creación de SLAs asociados a sus principales servicios. Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en la calidad de los servicios prestados y/o adapten estos servicios a las nuevas necesidades de los clientes y a los últimos avances tecnológicos. OLAs y UCs con clientes y proveedores Supervisar el cumplimiento de los acuerdos de provisión del servicio con clientes y proveedores. sus resultados y el grado de satisfacción de los clientes con el servicio prestado. Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la información necesaria para el óptimo funcionamiento de la organización. Negociar los SLAs. Elaboración de un catálogo de servicios. Planes de Mejora: donde se especifiquen las acciones propuestas para la mejora del servicio TI y el impacto que estas han tenido en la calidad del servicio. . Mantener informados a la Dirección y la organización TI sobre el rendimiento de todo el proceso. Determinar la estructura general de los SLAs. en representación de "Cater Matters". Para llevar a cabo esta tarea de la forma más eficiente posible se han determinado una serie de acciones iniciales que se resumen en: • • • • Designación de un Gestor del proceso. costes promedio asociados al proceso. etc. OLAs y UCs. Sus responsabilidades específicas incluyen: • • • • • • • Elaborar y mantener actualizado un catálogo de los servicios ofrecidos por "Cater Matters". Caso Práctico La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicio que adapte a las necesidades de su organización los principios y recomendaciones de ITIL. OLAs y UCs elaborados y el nivel de cumplimiento de los mismos. la provisión de servicios con los clientes.

Protocolos de interacción del Service Desk con los clientes y usuarios. como. horarios nocturnos.). El objetivo del catálogo no es sólo dar a conocer los diferentes servicios sino mostrar claramente al (potencial) cliente cuales son las diferencias entre las diferentes opciones de un mismo "servicio base". La descripción de cada servicio incluye información adicional sobre: • • • • • • • Plazos de entrega. Servicios auxiliares. Pequeñas empresas. por ejemplo. Los niveles de seguridad. Para ello se elabora un catálogo online que permite comparar las diferentes "versiones" y realizar una estimación preliminar de los costes basándose en las diferentes opciones seleccionadas. etc. Cada SLA prototipo incluye: . WebServices asociados. Programas de fidelización. Disponibilidad del servicio (festivos.Elaboración del Catálogo de Servicios Se ha decidido estructurar el Catálogo de Servicios en función de los diferentes tipos de clientes que contratan los servicios de "Cater Matters": • • • Particulares. el reparto y la provisión de mercancía. disponibilidad. Métodos de supervisión y seguimiento en tiempo real de los procesos involucrados en la prestación del servicio. Soporte online. Indicadores clave de rendimiento y satisfacción del cliente. capacidad y redundancia necesarios para asegurar la correcta provisión del servicio en colaboración con los responsables de dichos procesos. Planes de contingencia en casos de deterioro grave de la calidad del servicio. Grandes corporaciones e instituciones y organismos públicos. Disposiciones legales aplicables. Plan de Calidad del Servicio Para asegurar la calidad del servicio se desarrolla un SQP que determina: • • • • • • La responsabilidad de cada uno de los departamentos en el proceso de provisión del servicio. SLAs prototipo A fin de evitar que la elaboración de los SLAs se convierta en una tarea excesivamente compleja y tediosa se desarrollan plantillas para los diferentes tipos de servicios y clientes.

Planes de contingencia si son de aplicación. Tiempos de recuperación en casos de incidentes. Soporte y labores de mantenimiento asociadas. Plazos para la provisión del servicio. . Condiciones de disponibilidad del servicio. Criterios de evaluación de la calidad del servicio. Duración del acuerdo y condiciones para su renovación y/o rescisión. Métodos de facturación y cobro. Responsables del acuerdo tanto por el lado cliente como proveedor.• • • • • • • • • • • Descripción general y no técnica de los servicios acordados. Tiempos de respuesta.

Gestión Financiera de los Servicios TI Visión General Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus procesos de negocio es moneda corriente que no exista una conciencia real de los costes que esta tecnología supone. Esto conlleva serias desventajas: • • • Se desperdician recursos tecnológicos. Es prácticamente imposible establecer una política consistente de precios. El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios. por lo que es necesario evaluar cuidadosamente las necesidades del cliente para que el balance entre ambos sea óptimo. No se presupuestan correctamente los gastos asociados. Las propiedades y funcionalidades de la Gestión Financiera de los Servicios TI se resumen sucintamente en el siguiente interactivo: Ver Animación: http://itil.osiatis. .es/Curso_ITIL/Gestion_Servicios_TI/gestion_financi era/vision_general_gestion_financiera/swf/gestion_financiera. Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podrán evaluar el retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica. Por regla general. a mayor calidad de los servicios mayor es su coste.swf Introducción y Objetivos La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar de manera eficaz y rentable los servicios y la organización TI.

Proporcionar a la organización TI toda la información financiera precisa para la toma de decisiones y fijación de precios. Los principales beneficios de una correcta Gestión Financiera de los Servicios Informáticos se resumen en: • • • • • • Se reducen los costes y aumenta la rentabilidad del servicio. adecuan y justifican (si es de aplicación) los precios del servicio aumentando la satisfacción del cliente. Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen en: • • Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos financieros y/o contables. .Para lograr este objetivo la Gestión Financiera debe: • • • • • Evaluar los costes reales asociados a la prestación de servicios. La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI. Se ajustan. Evaluar el retorno (ROI) de las inversiones TI. Existen múltiple costes ocultos difíciles de evaluar por una deficiente organización financiera. controlan. Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad. La organización TI funciona como una unidad de negocio y es posible evaluar claramente su rendimiento global. Llevar la contabilidad de los gastos asociados a los servicios TI. Asesorar al cliente sobre el valor añadido que proporcionan los servicios TI prestados. Los servicios TI son usados más eficazmente.

Estos costes son más difíciles de determinar y por lo general son prorrateados entre los diferentes servicios y productos. los servidores web asociados a los servicios de Internet. Costes indirectos: aquellos que nos son específicos y exclusivos de un servicio.• • • No existe una estrategia clara que permita elaborar unos presupuestos ajustados a la misma. directa o indirectamente a la prestación del servicio o elaboración del producto: • • Costes Directos: son los costes relacionados específica y exclusivamente con un producto o servicio. Conceptos Básicos Categorías de coste La clasificación de costes por servicio o producto puede realizarse en virtud de uno a más criterios: Costes atribuibles. Un incremento de los costes. la "conectividad" de la organización TI de la que dependen tanto los servicios web como la propia plataforma general de comunicaciones. Costes que dependen o no del "cuánto": • Costes fijos: son independientes del volumen de producción y están normalmente relacionados con gastos en inmovilizado material. como por ejemplo. No hay un compromiso de toda la organización con el proceso. . como por ejemplo.

los fungibles. Tipos de coste Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente. etc. Costes que dependen del horizonte temporal: • • Costes de capital: que proviene de la amortización del inmovilizado material o inversiones a largo plazo. El siguiente diagrama nos muestra una típica estructura de tipos y elementos de coste para una organización TI: * Los costes de Transferencia se corresponden con los cargos internos por servicios prestados por otros departamentos de la empresa o institución. Costes de Operación: son los costes asociados al funcionamiento diario de la organización TI.• Costes variables: incluyen aquellos costes que dependen del volumen de producción y engloban. . Los tipos de coste se subdividen a su vez en elementos de coste. por ejemplo. los gastos de personal que presta los servicios.

Pueden ser a corto plazo. o resultar de una proyección sobre la evolución prevista del negocio en dos o más años. . o Fijación de políticas financieras. Ver Animación: http://itil. Asegurar que los servicios TI están suficientemente financiados. o Elaboración de presupuestos. incluyendo los costes de los servicios prestados en la actualidad. adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías. Los presupuestos realizados pueden tener diferentes horizontes temporales. o Monitorización de los costes. o Definición de elementos de coste.Proceso Las principales actividades de la Gestión Financiera se resumen se resumen en: • • • Presupuestos: o Análisis de la situación financiera. Contabilidad: o Identificación de los costes. Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI. Fijación de precios: o Elaboración de una política de fijación de precios. y teniendo en consideración la aparición de nuevas líneas de servicios.swf Presupuestos La elaboración de presupuestos TI tiene como objetivos principales: • • • Planificar el gasto e inversión TI a largo plazo. o Establecimiento de tarifas por los servicios prestados o productos ofrecidos.es/Curso_ITIL/Gestion_Servicios_TI/gestion_financi era/proceso_gestion_financiera/swf/proceso.osiatis. Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales: • • Presupuesto incremental: el presupuesto se realiza en base al histórico de presupuestos anteriores. Presupuesto "desde cero": se replantea toda la estructura de costes e inversiones a partir de una "hoja en blanco" en base a los servicios prestados en la actualidad y las expectativas de crecimiento en el periodo presupuestado. Establecer objetivos claros que permitan evaluar el rendimiento de la organización TI.

como por ejemplo el aumento del precio de las licencias del software. Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia organización). Sin embargo. Las actividades contables deben permitir: • • • • Una correcta evaluación de los costes reales para su comparación con los presupuestados. Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto para evitar que se conviertan en papel mojado al menor vaivén del mercado. Política de Precios No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización. costes de Personal. La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores externos que no se hallan bajo el control directo de la organización TI. costes generales. etc. si es de aplicación. Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se pueden clasificar de forma genérica en: • • • costes de hardware y software. la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros servicios o departamentos. Contabilidad En principio. Facturar adecuadamente.Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar previamente todos los elementos de coste. asignando a cada servicio/cliente su parte proporcional. la complejidad de las interrelaciones TI dificulta el proceso cuando los responsables de su contabilidad desconocen sus mecanismos básicos y la tecnología que los sustenta. . Evaluar la eficiencia financiera de cada uno de los servicios TI prestados. pero éste es un paso esencial si buscamos que se utilice eficientemente la infraestructura TI. Tomar decisiones de negocio basadas en los costes de los servicios. Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivel de detalle que lo encarezca más allá de lo razonable. los servicios TI.

Para que la organización TI pueda funcionar como una verdadera unidad de negocio es imprescindible tanto conocer los costes reales de los servicios prestados como establecer una política de precios que. Los servicios solicitados. Mientras que la Gestión Financiera debe aportar información sobre: . Los precios vigentes en el mercado. Sin embargo. en los aspectos económicos. cuando menos. Factores de escala y necesidades de disponibilidad. Los costes asociados. Los SLAs contratados. permita recuperar los costes en los que se ha incurrido. Los contratos de soporte (UCs) en vigor. Tendencias del mercado y Planes de Mejora del Servicio (SIP). su actividad sea supervisada por la Gestión Financiera. Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para servicios de similar naturaleza. Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los objetivos cumplidos. En algunas ocasiones estas tarifas serán usadas para una facturación real mientras que en otras sólo se utilizarán de referencia para evaluar el rendimiento teórico de la organización TI. Una vez determinada la política de fijación de precios se deben determinar las tarifas de los servicios en función de: • • • • • La política elegida. En primer lugar debe establecerse una política de fijación de precios. Precio negociado: se negocia directamente con el cliente cuál es el precio estipulado por los servicios. Existen múltiples opciones. es recomendable que. entre ellas: • • • • Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios (que puede ser del 0% para "clientes internos"). Por un lado la Gestión de Niveles de Servicio debe proveer información a la Gestión Financiera sobre: • • • • El tipo de servicios demandados por los clientes. Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos. Supervisión No es tarea de la Gestión Financiera de los Servicios TI sino de la Gestión de Niveles de Servicio negociar con los clientes y elaborar el catálogo de servicios.

Se cumplen los objetivos de costes e ingresos. Desviaciones en las previsiones de costes respecto a los gastos reales. . La organización TI funciona de manera "rentable". Control del Proceso El responsable de el proceso de Gestión Financiera no ha de ser de manera imprescindible un miembro de la organización TI. sin embrago. Análisis de eficiencia de cada uno de los servicios TI. Métodos y condiciones de pago.• • • • Los costes reales de los servicios. La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto. Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar su éxito como unos indicadores de rendimiento específicos. imprescindible que disponga de ciertos conocimiento sobre los servicios TI y/o esté correctamente asesorado por especialistas en todo lo referente a la tecnología. Previsiones de costes. Se lleva a cabo una contabilidad precisa asociada a cada servicio. Entre la documentación generada cabría destacar: • • • Resúmenes contables. Entre los primeros cabe destacar: • • • • • ¿Conoce la organización los costes reales de los servicios TI? ¿Los clientes perciben la política de precios como coherente y ajustada al mercado? ¿Colaboran los responsables de los otros procesos TI con la Gestión Financiera? ¿Están los gastos en servicios e infraestructuras TI realmente alineados con los procesos de negocio? ¿Opera la organización TI como una verdadera unidad de negocio? En lo que respecta a los indicadores de rendimiento. Sin una estrecha colaboración entre ambos procesos será imposible llegar a acuerdos que sean rentables y a su vez satisfactorios para el cliente. Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología. Se conoce el ROI de las inversiones TI. estos deben incluir métricas que permitan evaluar si: • • • • • Los gastos TI están correctamente planificados y presupuestados. es.

Pero los objetivos de una Gestión Financiera proactiva van más allá e incluyen una correcta planificación de gastos e inversiones futuras. etc. ya sea directamente o incluidas en otras partidas de carácter general. cuales son los costes asociados al uso de los mismos: amortización. desde hace años. prorrateando entre los diferentes servicios si esto fuera necesario.• Planes de reducción de costes por servicio. hasta la fecha. Todas estas actividades buscan determinar con precisión los costes asociados a los servicios TI ya prestados y proponer tarifas que sean trasladas a los clientes.en la misma medida que ya se hace con los costes de transporte. Establecer una política de precios de coste adicional o "coste + margen". El impacto en los costes de los Planes de Mejora del Servicio (SIP). Gestión de la Capacidad y Gestión de la Disponibilidad se estudian: • • • Los requisitos de los clientes y las tendencias de mercado. fungibles. Evaluar. con los datos disponibles en la actualidad. costes administrativos. mantenimiento. Estimar los costes de difícil asignación u ocultos asociados a los servicios TI. Necesidades futuras y proyecciones de la capacidad TI. El plan de trabajo a corto plazo incluye: • • • • • • • En colaboración con la Gestión de Configuraciones elaborar un listado de todos los CIs que intervienen en la prestación de servicios directos a los clientes. etc. Evaluar los costes indirectos: instalaciones. imposible conocer el impacto de los servicios TI en los costes de cada uno de los servicios de catering prestados. Para ello y en colaboración con la Gestión de Niveles de Servicio. materias primas. La información recopilada servirá de base para la elaboración de los primeros "presupuestos anuales TI" elaborados por la Gestión Financiera. etc. Caso Práctico La organización TI de "Cater Matters" lleva prestando. Evaluar los costes de personal y los costes operativos. Establecer estrictos criterios contables para la administración de los costes TI. Para gestionar el proceso se ha nombrado a un senior manager del departamento TI y a un miembro del departamento financiero de la empresa como responsables del mismo. Sin embargo. servicios esenciales tanto a la propia organización de la empresa como a los clientes externos de sus servicios de catering. La gestión de "Cater Matters" quiere desarrollar una política de fijación de precios de los servicios TI que le permita trasladar sus costes al usuario final del servicio de catering. los gastos TI no han sido contabilizados y presupuestados de manera específica y es. .

Sign up to vote on this title
UsefulNot useful