Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:
¿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.
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.
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. Fue 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:
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:
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:
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.
Visión General
El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto
entre los usuarios y la Gestión de Servicios TI.
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:
El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y
profundidad de los servicios ofrecidos:
Los principales beneficios de una correcta implementción del Centro de Servicios se resumen
en:
Implementación
La implementación de un Service Desk requiere una meticulosa planificación. En primera
instancia debe establecerse:
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:
Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.
Estructura lógica
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.
• Centralizado
• Distribuido
• Virtual
En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura
central.
Sus ventajas principales son:
El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks
centralizados y distribuidos.
A continuación describimos algunas de las actividades que un Service Desk debería ofrecer
para merecer ese nombre:
Gestión de Incidentes
El Service Desk debe ser la principal fuente de información de los clientes y usuarios,
informando sobre:
• Nuevos servicios.
• El lanzamiento de nuevas versiones para la corrección de errores.
• El cumplimiento de los SLAs.
• ...
Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades
de negocio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio
prestado.
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.
Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera
impresión.
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. Esto se
puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente
respecto a los servicios prestados.
Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan
registrar la opinión del cliente respecto a la atención recibida, su satisfacción respecto a la
solución ofrecida, etc. Toda esta información debe ser recopilada y analizada periódicamente
para mejorar la calidad del servicio.
Caso Practico
Como paso imprescindible para la implantación de la metodología ITIL en la empresa la
dirección de "Cater Matters" ha decidido implantar un Service Desk que centralice todos los
contactos con clientes, proveedores y la organización TI.
Para ello se han adoptado las siguientes decisiones:
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.
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.
“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.
Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales
como:
• 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.
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.
* 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
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.
Clasificación
• Categorización: se asigna una categoría (que puede estar a su vez subdividida en más
niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su
resolución. Se identifican los servicios afectados por el incidente.
• Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se
determina, según criterios preestablecidos, un nivel de prioridad.
• Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en
primera instancia designara al personal de soporte técnico responsable de su resolución
(segundo nivel).
• Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al
incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el
tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.
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.
Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite
su correcta implementación. Entre ellos cabe destacar:
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.
• 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.
• Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente
una solución temporal satisfactoria no se requiere un escalado superior.
• Registra la solución temporal del incidente junto a la información proporcionada por el
departamento de sistemas.
• Da por cerrado el incidente.
Gestión de Problemas
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.
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los
mismos.
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.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la
interrelación con otros procesos TI
Proceso - Control de Problemas
El principal objetivo del Control de Problemas es conseguir que estos se conviertan en
Errores Conocidos para que el Control de Errores pueda proponer las soluciones
correspondientes.
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las
principales fuentes de información utilizadas son:
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.
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.
Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o
software. Es moneda frecuente que el problema este causado por:
• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.
• ...
Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las
aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno
de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet
información sobre errores conocidos aplicables al problema en cuestión.
Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se
remite al Control de Errores para su posterior procesamiento.
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
En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la
calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente
por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión
de Cambios han de tenerse en cuenta las siguientes consideraciones:
Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las
bases de datos asociadas. En el caso en el que se considere que el problema necesita ser
solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la
implementación de los cambios de infraestructura propuestos.
Revisión Post Implementación y Cierre
Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el
resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes
relacionados con este problema se considera concluido el proceso y se emiten los informes
correspondientes.
• 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.
Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los
responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable
no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco
eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de
identificación y solución de problemas.
Caso Práctico
El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una
incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de
bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que
en este caso sigue el modelo de Kepner y Tregoe:
Los analistas deciden que el origen más probable del problema esté en los módulos de registro
de la aplicación.
Verificación:
Visión General
Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:
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.
• 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:
Definiciones
A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como
elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por
lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.
Elementos de configuración: todos, tanto los componentes de los servicios TI como los
servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de
ejemplo citaremos:
• Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus
componentes: tarjetas de red, teclados, lectores de CDs, ...
• Software: sistemas operativos, aplicaciones, protocolos de red, ...
• Documentación: manuales, acuerdos de niveles de servicio, ...
En resumen, todos los componentes que han de ser gestionados por la organización TI.
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:
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.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la
interrelación con otros procesos TI.
Planificación
La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus
interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es
particularmente compleja.
Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones
defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos.
Clasificación y Registro
La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible,
para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:
• Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar
de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.
• La información sea suficiente: debe existir, al menos un registro de todos los sistemas
críticos para la infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en
la CMDB:
En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos
objetivos en exceso ambiciosos pueden resultar contraproducentes.
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.
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.
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:
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:
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.