OSIATIS
ITIL
Gestión de servicios TI
X
[Seleccionarfecha]
Fundamentos de la Gestión TI ................................................................................................
Gestión de Problemas.........................................................................................................
La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez
genera ingentes c...
¿Qué es ITIL?
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se
...
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 ...
Forum ITSMF
El ITSMF es el único Forum completamente indpendiente reconocido por el sector de la Gestión de
Servicios Info...
realizado en estrecha cooperación con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de
lucro que cooperan pa...
La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la
metodología ITIL com...
Centro de servicios (Service Desk)
Visión General
El objetivo primordial, aunque no único, del Centro de Servicios es serv...
 Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del
mismo.
 Apertura de nu...
 Sabercuándo se debe realizarunescaladoainstanciassuperioresoentrar endiscusionessobre
cumplimientode SLAs.
 Tenerrápido...
Service Desk Distribuido
Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes...
Service Desk Virtual
En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de ...
Actividades y Funciones
Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspecto...
 Nuevosservicios.
 El lanzamientode nuevasversionesparalacorrecciónde errores.
 El cumplimientode los SLAs.
 ...
Este ...
La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente,
no sea respon...
Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater
Matters" ha deci...
Gestión de Incidentes
Visión General
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause u...
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas
de hardware y soft...
Clasificación del Incidente
Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario det...
 Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones
que se escapen de las atri...
Registro y Clasificación de Incidentes
Registro
La admisión y registro del incidente es el primer y necesario paso para un...
Clasificación
La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda se...
 Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por
el servicio prestad...
 Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error
conocido y cuales son las p...
Gestión de Problemas
Visión General
Las funciones principales de la Gestión de Problemas son:
 Investigar las causas suby...
Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el
restablecer lo más rá...
 Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI
ahorrando recursos e inn...
Proceso- Control de Problemas.
El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Erro...
 La base de datos de Incidentes: enprincipiocualquierincidente del que nose conocensuscausasy que se
ha cerrado mediante ...
 Errores de procedimiento.
 Documentaciónincorrecta.
 Faltade coordinaciónentre diferentesáreas.
 ...
Es también posib...
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 cue...
Caso Práctico
El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que
no s...
Gestión de Configuraciones
Visión General
Las cuatro principales funciones de la Gestión de Configuraciones pueden resumir...
Los objetivos principales de la Gestión de Configuraciones se resumen en:
 Proporcionar información precisa y fiable al r...
Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos
nos ofrecen, con...
Planificación
La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e
interde...
 Los objetivossean realistas:una excesivaprofundidadodetalle puede sobrecargarde trabajoa la
organizaciónyresultar,a lala...
Nomenclatura
Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los...
 Asegurar que todos los componentes están registrados en la CMDB.
 Monitorizar el estado de todos los componentes.
 Act...
éxito y ésta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la
infraestructura no justif...
Gestión de Cambios
Visión General
Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la d...
Fundamentos de la gestión ti
Upcoming SlideShare
Loading in …5
×

Fundamentos de la gestión ti

1,691 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,691
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
109
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Fundamentos de la gestión ti

  1. 1. OSIATIS ITIL Gestión de servicios TI X [Seleccionarfecha]
  2. 2. Fundamentos de la Gestión TI ............................................................................................................................... 3 Visión General. ................................................................................................................................................. 3 ¿Qué es ITIL?.................................................................................................................................................... 5 Soporte al Servicio......................................................................................................................................... 6 Provisión del Servicio..................................................................................................................................... 6 Forum ITSMF................................................................................................................................................. 7 Certificaciones ITIL........................................................................................................................................ 7 Caso Práctico.................................................................................................................................................... 8 Centro de servicios (Service Desk)........................................................................................................................ 10 Visión General................................................................................................................................................ 10 Introducción y Objetivos ................................................................................................................................. 10 Implementación.............................................................................................................................................. 11 Estructura ...................................................................................................................................................... 11 Estructura lógica ......................................................................................................................................... 11 Estructura física........................................................................................................................................... 12 Actividades y Funciones .................................................................................................................................. 15 Gestión de Incidentes.................................................................................................................................. 15 Centro de información................................................................................................................................. 15 Relaciones conlos proveedores ................................................................................................................... 16 Equipo y formación......................................................................................................................................... 16 Control del proceso......................................................................................................................................... 16 Control del proceso......................................................................................................................................... 17 Caso Practico.................................................................................................................................................. 17 Gestión de Incidentes ......................................................................................................................................... 19 Visión General................................................................................................................................................ 19 Introducción y Objetivos ................................................................................................................................. 19 Clasificación del Incidente ............................................................................................................................... 21 Escalado y Soporte.......................................................................................................................................... 21 Proceso.......................................................................................................................................................... 22 Registro y Clasificación de Incidentes............................................................................................................... 23 Registro...................................................................................................................................................... 23 Clasificación................................................................................................................................................ 24 Análisis, Resolución y Cierre de Incidentes........................................................................................................ 24 Control del Proceso......................................................................................................................................... 24 Caso Práctico.................................................................................................................................................. 25
  3. 3. Gestión de Problemas......................................................................................................................................... 27 Visión General................................................................................................................................................ 27 Introducción y Objetivos ................................................................................................................................. 27 Proceso.......................................................................................................................................................... 29 Proceso - Control de Problemas. .................................................................................................................. 30 Proceso - Control de Errores. ....................................................................................................................... 32 Identificación y Registro de errores .............................................................................................................. 32 Análisis y Solución....................................................................................................................................... 32 Revisión Post Implementación y Cierre......................................................................................................... 33 Control del Proceso......................................................................................................................................... 33 Caso Práctico.................................................................................................................................................. 34 Gestión de Configuraciones................................................................................................................................. 36 Visión General................................................................................................................................................ 36 Introducción y Objetivos ................................................................................................................................. 36 Definiciones.................................................................................................................................................... 37 Proceso.......................................................................................................................................................... 38 Planificación................................................................................................................................................... 39 Clasificación y Registro.................................................................................................................................... 39 Alcance....................................................................................................................................................... 40 Nivel de detalle y Profundidad ..................................................................................................................... 40 Nomenclatura............................................................................................................................................. 41 Monitorización ............................................................................................................................................... 41 Control........................................................................................................................................................... 41 Auditorías....................................................................................................................................................... 42 Control del Proceso......................................................................................................................................... 42 Caso Práctico.................................................................................................................................................. 43 Gestión de Cambios............................................................................................................................................ 44 Visión General................................................................................................................................................ 44 Fundamentos de la Gestión TI Visión General. 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.
  4. 4. 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
  5. 5. ¿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
  6. 6. 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: Provisióndel 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:
  7. 7. 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, Director de Desarrollo de Osiatis Francia, es tesorero de la asociación en ese país). CertificacionesITIL 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. Fue
  8. 8. realizado en estrecha cooperación con la OGC y el itSMF. 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. Hasta la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30 países. Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI. El marco de mejores prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones, herramientas, servicios de educación y consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, 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. 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. Enlaces de interés Podréis encontrar información adicional en:  http://www.itil.co.uk -El Sitio Oficial de ITIL  http://www.exin.nl -Organismo de Certificación  http://www.itsmf.com -Forum Internacional de 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, "Cater Matters", que ha optado por introducir la metodología ITIL para la gestión de sus servicios. "Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:  Servicios de comedor de grandes empresas.  Servicios de catering para colegios.  Servicios de catering para eventos (congresos, actos institucionales, ...).  Servicios de restauración para hoteles. 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. 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.
  9. 9. La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL como la base de todos sus procesos y servicios. 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.  Organización de sus actividades en torno a los procesos.  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.
  10. 10. Centro de servicios (Service Desk) Visión General El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los los usuarios y la Gestión de Servicios TI. Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio:  Registrando y monitorizando incidentes.  Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.  Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes.  Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes. Introducción y Objetivos Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e independiente de su localización geográfica. 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.  Emitir peticiones de servicio.  Informarse sobre el cumplimiento de los SLAs.  Recibir información comercial en primera instancia. 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, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.  Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.  Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como: o Supervisión de los contratos de mantenimiento y niveles de servicio. o Canalización de las Peticiones de Servicio de los clientes. o Gestión de las licencias de software. o Centralización de todos los procesos asociados a la Gestión TI. 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.
  11. 11.  Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo.  Apertura de nuevas oportunidades de negocio.  Centralización de procesos que mejoran la gestión de la información y la comunicación.  Soporte al servicio proactivo. Implementación La implementación de un Service Desk requiere una meticulosa planificación. En primera instancia debe establecerse:  Cuáles son las necesidades.  Cuáles han de ser sus funciones.  Quiénes seran los responsables del mismo.  Qué cualificaciones profesionales poseeran sus integrantes.  Si se deben externalizar ciertos servicios, como, por ejemplo, el soporte técnico del hardware.  Qué estructura de Service Desk:distribuido, central o virtual, se adapta mejor a nuestras necesidades y las de nuestros clientes.  Qué herramientas tecnológicas necesitamos.  Qué métricas determinarán el rendimiento del Centro de Servicios. Además de estas cuestiones de carácter técnico, 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.  Motivar al personal encargado de la relación directa con el cliente.  Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.  Asegurar el compromiso de la dirección con la filosofía del Service Desk.  Sondear a los clientes para conocer mejor sus expectativas y necesidades. 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, mejoren la satisfacción de nuestros clientes, optimicen la imagen externa de nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de negocio. 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, es por lo tanto imprescindible que:  Seafácilmente accesible.  Ofrezcaun serviciode calidadconsistenteyhomogéneo.  Mantengapuntualmente informadosalosusuariosy lleve unregistrode todala interacciónconlosmismos.  Sirvade soporte al negocio. Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica. Estructura lógica Los integrantes del Centro de Servicios deben:  Conocertodoslosprotocolosde interacciónconel cliente:guiones,checklists,...  Disponerde herramientasde software que lespermitanllevarunregistrode lainteracciónconlosusuarios.
  12. 12.  Sabercuándo se debe realizarunescaladoainstanciassuperioresoentrar endiscusionessobre cumplimientode SLAs.  Tenerrápidoaccesoa lasbasesde conocimientoparaofrecerunmejorservicioalosusuarios.  Recibirformaciónsobre losproductosyserviciosde laempresa. Estructura física Dependiendo de las necesidades de servicio: locales, globales, 24/7,...se debe de optar por una estructura diferente para el Centro de Servicios. Existen tres formatos básicos:  Centralizado  Distribuido  Virtual 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. Sus ventajas principales son:  Se reducenloscostes.  Se optimizanlosrecursos.  Se simplificalagestión. Sin embargo surgen importantes inconvenientes cuando:  Los usuariosse encuentranendiversosemplazamientosgeográficos:diferentesidiomas,productosy servicios.  Se necesitadarserviciosde mantenimiento"on-site".
  13. 13. Service Desk Distribuido Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades, países o continentes). Sus ventajas son obvias en estos casos, sin embargo la deslocalización de los diferentes Centros de Servicios conlleva grandes problemas:  Es generalmentemáscaro.  Se complicala gestiónymonitorizacióndel servicio.  Se dificultael flujode datosyconocimientoentrelosdiferentesService Desks.
  14. 14. 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. El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos. En un Service Desk virtual:  El "conocimiento"estácentralizado.  Se evitanduplicidadesinnecesariasconel consiguiente ahorrode costes.  Se puede ofrecerun"serviciolocal"sinincurrirencostesadicionales.  La calidaddel servicioeshomogéneayconsistente.
  15. 15. Actividades y Funciones Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación con los clientes y usuarios manteniéndoles puntualmente informado de todos aquellos procesos de su interés. A continuación describimos algunas de las actividades que un Service Desk debería ofrecer para merecer ese nombre: Gestiónde Incidentes Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y personal, el Service Desk debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios. Entre sus tareas específicas se incluyen:  Registroymonitorizaciónde cadaincidente.  Comprobaciónde que el serviciode soporte requeridose incluyeenel SLA asociado.  Seguimientodel procesode escalado.  Identificaciónde problemas.  Cierre del incidente yconfirmaciónconel cliente. Centro de información El Service Desk debe ser la principal fuente de información de los clientes y usuarios, informando sobre:
  16. 16.  Nuevosservicios.  El lanzamientode nuevasversionesparalacorrecciónde errores.  El cumplimientode los SLAs.  ... Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado. El Centro de Servicios 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. Es para ello imprescindible que se lleve un adecuado registro de toda la interacción con los usuarios y clientes. Relacionesconlos proveedores El Centro de Servicios es asimismo responsable de la relación con los proveedores de servicios de mantenimiento externos. Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk. Equipo y formación La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service Desk. 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, cuando no directamente mal educado. "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. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante. Idealmente, el personal del Service Desk debe:  Compartir la filosofía de atención al cliente de la organización.  Comunicarse con corrección y buena educación y de una manera que el cliente pueda comprender.  Conocer en profundidad los servicios y productos ofrecidos.  Comprender las necesidades de los clientes y redirigirlos, si fuera necesario, a los expertos en cuestión.  Controlar todas la herramientas tecnológicas a su disposición para ofrecer un servicio de alta calidad.  Ser capaz de trabajar en equipo. La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica. También es imprescindible el compromiso de la dirección con:  Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.  Un continuo apoyo al equipo en la siempre difícil tarea del trato directo con los clientes.  El trabajo en equipo. Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión. Control del proceso
  17. 17. La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, 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. 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.  Porcentaje de incidentes que se cierran en primera línea de soporte.  Porcentaje de consultas respondidas en primera instancia.  Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.  Cumplimiento de los SLAs.  Número de llamadas gestionadas por cada miembro del personal del Service Desk. Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados. Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio. Control del proceso La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, 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. 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.  Porcentaje de incidentes que se cierran en primera línea de soporte.  Porcentaje de consultas respondidas en primera instancia.  Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.  Cumplimiento de los SLAs.  Número de llamadas gestionadas por cada miembro del personal del Service Desk. Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados. Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio. Caso Practico
  18. 18. Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI. Para ello se han adoptado las siguientes decisiones:  Se ha nombrado un gestor responsable del Service Desk.  Se han definido, tras un cuidadoso análisis de las necesidades de la organización y los usuarios, las funciones principales del mismo: o Gestionar la primera línea de soporte de la Gestión de Incidentes. o Supervisar la calidad del servicio ofrecido respecto a los SLAs. o Ofrecer información de carácter comercial sobre los servicios ofrecidos. o Realizar encuestas periódicas sobre el grado de satisfacción del cliente. o Elaboración de informes periódicos con la información recopilada.  Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y potenciales.  Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuarios a través de este medio: o Formularios de consultas y alta de incidentes. o Consulta remota, mediante los web services asociados, del estado de los incidentes activos, históricos de incidencias y cumplimiento de los SLAs. o FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios prestados, errores conocidos, etc.  Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de interacción con los usuarios dependiendo de la situación en cuestión.  Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del Service Desk.  Impartir formación específica: o Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de Atención al Cliente". o Sobre las herramientas de software utilizadas.  Creación de un detallado plan de implantación progresiva del Service Desk .
  19. 19. Gestión de Incidentes Visión General La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas. Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo: Introducción y Objetivos Los objetivos principales de la Gestión de Incidentes son:  Detectar cualquiera alteración en los servicios TI.  Registrar y clasificar estas alteraciones.  Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente. Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe jugar una papel esencial en el mismo. El siguiente diagrama resume el proceso de gestión de incidentes:
  20. 20. Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es: “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”. Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar. Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios. Los principales beneficios de una correcta Gestión de Incidentes incluyen:  Mejorar la productividad de los usuarios.  Cumplimiento de los niveles de servicio acordados en el SLA.  Mayor control de los procesos y monitorización del servicio.  Optimización de los recursos disponibles.  Una CMDB más precisa pues se registran los incidentes en relación con los elementos de configuración.  Y principalmente: mejora la satisfacción general de clientes y usuarios. Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:  Reducción de los niveles de servicio.  Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.  Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.  Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes. Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:  No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.  No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.  No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.
  21. 21. Clasificación del Incidente Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas. El nivel de prioridad se basa esencialmente en dos parámetros:  Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.  Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA. También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes. Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente. La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones. Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente: Escalado y Soporte Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado. Básicamente hay dos tipos diferentes de escalado:  Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.
  22. 22.  Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico. El proceso de escalado puede resumirse gráficamente* como sigue: * El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES 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
  23. 23. Registro y Clasificación de Incidentes Registro La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo. Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros. El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.  La admisiónatramite del incidente:el Centrode Servicios debe de sercapazde evaluarenprimerainstancia si el serviciorequeridose incluye enel SLA del cliente yencasocontrarioreenviarloaunaautoridad competente.  Comprobaciónde que ese incidente aúnnohasidoregistrado:esmonedacorriente que másde unusuario notifique lamismaincidenciayporlo tantohan de evitarse duplicacionesinnecesarias.  Asignaciónde referencia:al incidente se le asignaráunareferenciaque le identificaráunívocamente tanto enlosprocesosinternoscomoenlas comunicacionesconel cliente.  Registro inicial:se han de introducirenlabase de datosasociadala informaciónbásicanecesariaparael procesamientodel incidente (hora,descripcióndel incidente,sistemasafectados...).  Información de apoyo: se incluirácualquierinformaciónrelevante paralaresolucióndel incidente que puede sersolicitadaal cliente atravésde unformularioespecífico,oque puedaserobtenidade lapropia CMDB (hardware interrelacionado),etc.  Notificacióndel incidente:enloscasosen que el incidentepuedaafectaraotros usuariosestosdebenser notificadosparaque conozcancomo estaincidenciapuedeafectarsuflujohabitual de trabajo.
  24. 24. Clasificación La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos:  Categorización:se asignauna categoría (que puede estarasu vezsubdivididaenmásniveles) dependiendo del tipode incidente odel grupode trabajoresponsable de suresolución. Se identificanlosservicios afectadosporel incidente.  Establecimientodel nivel de prioridad:dependiendodelimpactoylaurgenciase determina,segúncriterios preestablecidos,unnivel de prioridad.  Asignaciónde recursos: si el Centrode Servicios no puede resolverel incidenteenprimerainstancia designaraal personal de soporte técnicoresponsablede suresolución(segundonivel).  Monitorizacióndel estado y tiempode respuestaesperado:se asocia unestadoal incidente (porejemplo: registrado,activo,suspendido,resuelto,cerrado) yse estimael tiempode resolucióndelincidenteenbase al SLA correspondienteylaprioridad. Análisis, Resolución y Cierre de Incidentes En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado. Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados. Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo. Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes. Cuando se haya solucionado el incidente se:  Confirma con los usuarios la solución satisfactoria del mismo.  Incorpora el proceso de resolución a la KB.  Reclasifica el incidente si fuera necesario.  Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente.  Cierra el incidente. Control del Proceso La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes. Estos informes deben aportar información esencial para, por ejemplo:  La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
  25. 25.  Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.  Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.  Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.  Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc. Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:  Un correcto sistema automatizado de registro de incidentes y relación con los clientes  Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite: o Evitar escalados innecesarios. o Convertir el “know how” de los técnicos en un activo duradero de la empresa. o Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.  Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente. Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:  Número de incidentes clasificados temporalmente y por prioridades.  Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.  Nivel de cumplimiento del SLA.  Costes asociados.  Uso de los recursos disponibles en el Centro de Servicios.  Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.  Grado de satisfacción del cliente. Caso Práctico El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes. Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días pero también observa que éste se ha guardado defectuosamente. El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando. El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:  Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.  Registra los datos del incidente.
  26. 26.  Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuales son las posibles soluciones temporales  Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden realizar pedidos "urgentes" vía email.  Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la mañana.  Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los helados solicitados.  Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes del mediodía. Por otro lado el departamento de sistemas:  Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.  No consigue identificar la causa del incidente.  Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero pre-calificando su prioridad como baja. El Service Desk recibe la información y determina que:  Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución temporal satisfactoria no se requiere un escalado superior.  Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas.  Da por cerrado el incidente.
  27. 27. Gestión de Problemas Visión General Las funciones principales de la Gestión de Problemas son:  Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.  Determinar posibles soluciones a las mismas.  Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.  Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario. La Gestión de Problemas puede ser: Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos. Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran. Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguiente interactivo: Introducción y Objetivos
  28. 28. Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo. Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones. Cabe diferenciar entre: Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa. Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas. 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: Entre la funciones principales de la Gestión de Problemas figuran:  Identificar, registrar y clasificar los problemas.  Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.  Analizar y determinar las causas de los problemas y proponer soluciones.  Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.  Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.  Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto.  Analizar tendencias para prevenir incidentes potenciales. Los principales beneficios de una correcta Gestión de Problemas:  Un aumento de la calidad general de los servicios TI.  Se minimiza el número de incidentes.
  29. 29.  Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.  La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio. Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:  Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.  Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI.  Aumento de los costes por la contratación de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados. Proceso Las principales actividades de la Gestión de Problemas son el: Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos. Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios. Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio. El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas: Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI
  30. 30. Proceso- Control de Problemas. El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes. El Control de Problemas se compone en esencia de tres fases: 1. Identificacióny Registro Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:
  31. 31.  La base de datos de Incidentes: enprincipiocualquierincidente del que nose conocensuscausasy que se ha cerrado mediante algúntipode solucióntemporalespotencialmenteunproblema.Sinembargo,se habrá de analizarsi este incidente esaisladoosuimpactoen laestructuraTI antesde elevarloalacategoría de problema.  Análisisde la infraestructuraTI: encolaboracióncon laGestiónde Disponibilidadyde Capacidad,laGestión de Problemasdebe analizarlosdiferentesprocesosydeterminarenque aspectosse debe reforzarlos sistemasyestructurasTI para evitarfuturosproblemas.  Deteriorode losNivelesde Servicio: el descensodel rendimientopuede serunaindicaciónde laexistencia de problemassubyacentesque nose hayanmanifestadode formaexplicitacomoincidentes. Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI. El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto. El registro debe incorporar, entre otra, información sobre:  Los CIs implicados.  Causasdel problema.  Síntomasasociados.  Solucionestemporales.  Serviciosinvolucrados.  Nivelesde prioridad,urgenciae impacto.  Estado: activo,errorconocido,cerrado. 2. Clasificacióny AsignacióndeRecursos La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo. Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio). Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto. Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI. 3. Análisis y Diagnóstico:Errorconocido Los objetivos principales del proceso de análisis son:  Determinarlascausasdel problema.  Proporcionarsolucionestemporalesala Gestiónde Incidentes paraminimizarel impactodel problema hasta que se implemente loscambiosnecesariosque loresuelvandefinitivamente. Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:
  32. 32.  Errores de procedimiento.  Documentaciónincorrecta.  Faltade coordinaciónentre diferentesáreas.  ... Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión. Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento. Proceso- Control de Errores. Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido. Identificación y Registro de errores El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados. Análisis y Solución Se deben investigar diferentes soluciones para el error evaluando en cada momento:  El posible impactode lasmismasenlainfraestructuraTI.  Los costesasociados.  Sus consecuenciassobre los SLAs. En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.
  33. 33. 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 convenientedemorarla solución?Yaseaporque se prevéncambiossignificativosenlainfraestructuraTI a corto plazoo por el escasoimpactodel problemaencuestión.  ¿Es la solucióntemporal aportadasuficiente paramantenerunosnivelesde calidadde serviciosaceptable?  ¿Los beneficiosjustificanloscostesasociados? Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos. RevisiónPostImplementación y Cierre Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR). Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes. Control del Proceso El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento. En particular una buena gestión de problemas debe traducirse en una:  Disminución del número de incidentes y una más rápida resolución de los mismos.  Mayor eficacia en la resolución de problemas.  Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio. La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI. Entre la documentación generada cabría destacar:  Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.  Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.  Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc. Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.
  34. 34. Caso Práctico El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio. La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:  Identificación del problema.  Clasificación del problema.  Establecimiento de las posibles causas.  Comprobación de la causa más probable.  Verificación de la causa verdadera. Identificación: En nuestro caso el problema es sencillo de definir:  La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software. Clasificación: La clasificación se adaptaría a los siguientes parámetros:  Identificación: Problemas en el registro de pedidos.  Origen: Módulo de pedidos online.  Frecuencia: el problema no es recurrente, es la primera vez que se detecta.  Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio. Posibles causas: Entre las causas más probables figuran:  Errores en la programación del lado cliente de la aplicación.  Errores en los módulos de registro del servidor web.  Errores de configuración de la base de datos. Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación. Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:  Se intenta reproducir el problema.  Se comprueba que el error sólo se reproduce con una determinada marca de helados.  Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas. Verificación:  Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.  Se introducen las modificaciones necesarias en la programación.  Se comprueba el correcto registro del pedido. El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:  Elevar una RFC con la solución propuesta.  Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.
  35. 35. Gestión de Configuraciones Visión General Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:  Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).  Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.  Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.  Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias. Las interacciones y funcionalidades de la Gestión de Configuraciones se resumen sucintamente en el siguiente interactivo: Introducción y Objetivos Es evidente que no se puede gestionar correctamente lo que se desconoce. Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la misma. La principal tarea de la Gestión de Configuraciones es llevar un registro actualizado de todos los elementos de configuración de la infraestructura TI junto con sus interrelaciones. Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos, en particular, de la Gestión de Cambios y Versiones.
  36. 36. Los objetivos principales de la Gestión de Configuraciones se resumen en:  Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI.  Mantener actualizada la Base de Datos de Configuraciones: o Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,... o Interrelación entre los CIs. o Servicios que ofrecen los diferentes CIs.  Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidentes, Problemas y Cambios. Los beneficios de una correcta Gestión de Configuraciones incluyen, entre otros:  Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs, drivers desactualizados, etc. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema.  Una Gestión de Cambios más eficiente. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas.  Reducción de costes. El conocimiento detallado de todos los elementos de configuración permite, por ejemplo, eliminar duplicidades innecesarias.  Control de licencias. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización.  Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades en la infraestructura.  Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible. Las principales dificultades con las que topa la Gestión de Configuraciones son:  Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones.  Estructura inadecuada de la CMDB: mantener actualizada una base de datos de configuraciones excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.  Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB.  Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto mantenimiento de la CMDB.  Falta de organización: es importante que haya una correcta asignación de recursos y responsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones sea llevada a cabo por personal independiente y especializado.  Falta de compromiso: los beneficios de la Gestión de Configuraciones no son inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los agentes implicados. Definiciones A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.
  37. 37. Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:  Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, ...  Software: sistemas operativos, aplicaciones, protocolos de red, ...  Documentación: manuales, acuerdos de niveles de servicio, ... En resumen, todos los componentes que han de ser gestionados por la organización TI. Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir:  Información detallada de cada elemento de configuración.  Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones "padre- hijo" o interdependencias tanto lógicas como físicas La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización. Proceso Las principales actividades de la Gestión de Configuraciones son: Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones. Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos. Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual. Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización. Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI. Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
  38. 38. Planificación La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es particularmente compleja. Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:  Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.  Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.  Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.  Establecer claramente: o El alcance y objetivos. o El nivel de detalle o El proceso de implementación: orden de importancia, cronograma, ...  Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los Departamentos de Compras y Suministros Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos. Clasificación y Registro La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:
  39. 39.  Los objetivossean realistas:una excesivaprofundidadodetalle puede sobrecargarde trabajoa la organizaciónyresultar,a lalarga, enuna dejaciónde responsabilidades.  La informaciónsea suficiente:debe existir,al menosunregistrode todoslossistemascríticosparala infraestructuraTI. Alcance En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:  Es esencial incluiral menostodoslossistemasde hardware ysoftware implicadosenlos servicioscríticos.  Se debe determinarque CIsdebenincluirsedependiendodelestadode suciclode vida.Porejemplo, puedenobviarse componentesque yahansidoretirados.  Es recomendable incorporar,al menos,ladocumentaciónasociadaaproyectos, SLAsy 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:  Determinarlosatributosque describenaundeterminado CI.  Tipode relacioneslógicasyfísicasregistradasentre losdiferentes CIs.  Subcomponentesregistradosindependientemente. Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:  Atributos: Fechade compra, fabricante,procesador,sistemaoperativo,propietario,estado,coste,etc.  Relaciones:conexiónenred,impresorasconectadas,etc.  Profundidad:tarjetasde red,discosduros,tarjetasgráficas,etc.
  40. 40. 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óndebe ser,porsupuesto,únicaysi esposible interpretable porlosusuarios.  Este códigodebe serutilizadoentodaslascomunicacionesreferentesacada CI y si es posible debeir físicamente unidoal mismo(medianteunaetiquetade difícil eliminación).  Los códigosnodebensersóloutilizadosparacomponentesde hardware sino tambiénparadocumentacióny 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:
  41. 41.  Asegurar que todos los componentes están registrados en la CMDB.  Monitorizar el estado de todos los componentes.  Actualizar las interrelaciones entre los CIs.  Informar sobre el estado de las licencias. Auditorías El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización. Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB. Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:  Tras la implementación de una nueva CMDB.  Antes y después de cambios mayores en la infraestructura.  Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta. Las auditorías deben dedicar especial atención a aspectos tales como:  Uso correcto de la nomenclatura en los registros de los CIs.  Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, ...  Estado de los CIs actualizado.  Cumplimiento de los niveles de alcance y detalle predeterminados.  Adecuación de la estructura de la CMDB con la de la estructura TI real. Control del Proceso Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada la información almacenada en la CMDB. Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Configuraciones, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la infraestructura TI. Entre la documentación generada cabría destacar:  Alcance y nivel de detalle de la CMDB.  Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.  Información sobre CIs que han estado involucrados en incidentes.  Costes asociados al proceso.  Sistemas de clasificación y nomenclatura utilizados.  Informes sobre configuraciones no autorizadas y/o sin licencias.  Calidad del proceso de registro y clasificación.  Información estadística y composición de la estructura TI. En pequeñas organizaciones es a veces conveniente combinar la Gestión de Configuraciones y Cambios para simplificar el proceso de control. La coordinación entre ambos procesos es un factor crítico para el
  42. 42. éxito y ésta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total separación de estos procesos. Caso Práctico La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "gran devoradora de recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "Cater Matters" ha decidido, en una primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:  Servidores de red local.  Servidores de Internet.  Infraestructura informática del Centro de Servicios.  SLAs Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de "configuraciones de referencia" aplicables a los CIs arriba descritos. Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:  Reducción a medio/largo plazo de los costes asociados.  Mejora y consistencia de los servicios prestados.  Simplificación de todos los procesos asociados al soporte al servicio: Incidencias, Problemas, Cambios, Versiones, etc. El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de realizar un esfuerzo desmedido por lo que se han registrado:  Configuraciones de software: o Sistemas operativos. o Aplicaciones instaladas. o Interdependencias: relaciones padre-hijo, propietarios,... o Documentación asociada.  Configuraciones de hardware: o Servidores y estaciones de trabajo. o Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,... o Documentación y controladores asociados.  SLAs e informes de seguimiento asociados. A su vez se han instalado herramientas de gestión que permiten la monitorización remota de todas esas configuraciones y la realización de auditorías periódicas automatizadas.
  43. 43. Gestión de Cambios Visión General Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio. Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados. Las principales razones para la realización de cambios en la infraestructura TI son:  Solución de errores conocidos.  Desarrollo de nuevos servicios.  Mejora de los servicios existentes.  Imperativo legal. El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI. Las interacciones y funcionalidades de la Gestión de Cambios se resumen sucintamente en el siguiente interactivo:

×