Académique Documents
Professionnel Documents
Culture Documents
Fundamentos de la Gestin TI
Gestin de Servicios TI
Las tecnologas de la informacin 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 automatizacin de
su gestin se han convertido en una herramienta imprescindible y clave para empresas e instituciones.
La informacin es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su
vez genera ingentes cantidades de informacin. Su correcta gestin es de importancia estratgica y no
debe considerarse como una herramienta ms entre muchas otras.
Hasta hace poco las infraestructuras informticas 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 organizacin pero poco ms.
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 informacin: sirva de ejemplo la Banca Electrnica.
Los objetivos de una buena gestin de servicios TI han de ser:
ITIL nace como un cdigo de buenas prcticas dirigidas a alcanzar esas metas mediante:
Qu es ITIL?
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologas de la Informacin
(ITIL) se ha convertido en el estndar mundial de de facto en la Gestin de Servicios Informticos.
Iniciado como una gua para el gobierno de UK, la estructura base ha demostrado ser til para las
organizaciones en todos los sectores a travs de su adopcin por innumerables compaas como base
para consulta, educacin y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado
mundialmente. Pertenece a la OGC, pero es de libre utilizacin.
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez ms de la Informtica
para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una
necesidad creciente de servicios informticos de calidad que se correspondan con los objetivos del
negocio, y que satisfagan los requisitos y las expectativas del cliente. A travs de los aos, el nfasis
pas de estar sobre el desarrollo de las aplicaciones TI a la gestin de servicios TI. La aplicacin TI (a
veces nombrada como un sistema de informacin) slo contribuye a realizar los objetivos corporativos
si el sistema est a disposicin 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 obtencin). De esta
manera, los procesos eficaces y eficientes de la Gestin de Servicios TI se convierten en esenciales
para el xito de los departamentos de TI. Esto se aplica a cualquier tipo de organizacin, grande o
pequea, pblica 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 Prestacin del Servicio. Estos libros centrales fueron ms
tarde soportados por 30 libros complementarios que cubran una numerosa variedad de temas, desde el
cableado hasta la gestin de la continuidad del negocio. A partir del ao 2000, se acometi una revisin
de la biblioteca. En esta revisin, ITIL ha sido reestructurado para hacer ms simple el acceder a la
informacin necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos,
cubriendo las reas de Soporte del Servicio y Prestacin del Servicio, en aras de eliminar la duplicidad
y mejorar la navegacin. El material ha sido tambin 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.
Forum ITSMF
Certificaciones ITIL
EXIN e ISEB
El sistema de certificacin est basado en los requisitos para representar eficazmente el papel pertinente
dentro de una organizacin TI. Hasta la fecha, se han entregado ms de 50.000 certificados Foundation
a profesionales de ms de 30 pases.
Hoy en da, ITIL representa mucho ms que una serie de libros tiles sobre Gestin de Servicios TI. El
marco de mejores prcticas en la Gestin de Servicios TI representa un conjunto completo de
organizaciones, herramientas, servicios de educacin y consultora, marcos de trabajo relacionados, y
publicaciones. Desde 1990, se considera a ITIL como el marco de trabajo y la filosofa compartida por
quienes utilizan las mejores prcticas ITIL en sus trabajos. Gran cantidad de organizaciones se
encuentran en la actualidad cooperando internacionalmente para promover el estndar ITIL como un
estndar de facto para la Gestin de Servicios TI.
Enlaces de inters
Podris encontrar informacin adicional en:
Visin General
El objetivo primordial, aunque no nico, del Centro de Servicios es servir de punto de contacto entre
los los usuarios y la Gestin de Servicios TI.
Un Centro de Servicios, en su concepcin ms moderna, debe funcionar como centro neurlgico de
todos los procesos de soporte al servicio:
Pero tambin debe jugar un papel importante dando soporte al negocio identificando nuevas
oportunidades en sus contactos con usuarios y clientes.
Introduccin y Objetivos
Los clientes cada vez ms frecuentemente demandan un soporte al servicio de alta calidad, eficiente y
continuo e independiente de su localizacin geogrfica.
Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que estn
recibiendo una atencin 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:
Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios,
excepto en los casos ms triviales, a otras instancias de soporte y/o comerciales.
Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera lnea de soporte
tcnico 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 organizacin 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 organizacin TI tales como:
o
o
o
o
Los principales beneficios de una correcta implementacin del Centro de Servicios se resumen en:
Implementacin
La implementacin de un Service Desk requiere una meticulosa planificacin. En primera instancia
debe establecerse:
Estructura
Para cumplir estos objetivos es necesario implementar la adecuada estructura fsica y lgica.
Estructura lgica
Los integrantes del Centro de Servicios deben:
Estructura fsica
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 bsicos:
Centralizado
Distribuido
Virtual
Es generalmente ms caro.
Se complica la gestin y monitorizacin del servicio.
Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks.
Actividades y Funciones
Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos
de la Gestin de Servicios TI. Sin embargo, no cabe duda, de que su funcin principal es gestionar la
relacin con los clientes y usuarios mantenindoles puntualmente informado de todos aquellos procesos
de su inters.
A continuacin describimos algunas de las actividades que un Service Desk debera ofrecer para
merecer ese nombre:
Gestin de Incidentes
Independientemente de que la completa gestin de las incidencias requiera la colaboracin de otros
departamentos y personal, el Service Desk debe ofrecer una primera lnea de soporte para la solucin
de todas las interrupciones de servicio y/o peticiones de servicio que puedan cursar los clientes y
usuarios.
Entre sus tareas especficas se incluyen:
Centro de informacin
El Service Desk debe ser la principal fuente de informacin de los clientes y usuarios, informando
sobre:
Nuevos servicios.
El lanzamiento de nuevas versiones para la correccin de errores.
El cumplimiento de los SLAs.
...
Este contacto directo con los clientes debe servir tambin para identificar nuevas oportunidades de
negocio, evaluar las necesidades de los clientes y su grado de satisfaccin con el servicio prestado.
El Centro de Servicios se encuentra en una situacin inmejorable para ofrecer tambin informacin
privilegiada a todos los procesos de gestin de los servicios TI. Es para ello imprescindible que se lleve
un adecuado registro de toda la interaccin con los usuarios y clientes.
Equipo y formacin
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 seleccin y
formacin de su personal integrante.
Idealmente, el personal del Service Desk debe:
Comunicarse con correccin y buena educacin 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
cuestin.
Controlar todas la herramientas tecnolgicas a su disposicin para ofrecer un servicio de alta
calidad.
Ser capaz de trabajar en equipo.
Y, por ltimo, recordar que slo tenemos una oportunidad de ofrecer una buena primera impresin.
Control de la funcin
La mejor medida del xito de un Centro de Servicios es la satisfaccin del cliente, aunque sta,
obviamente, no sea responsabilidad exclusiva de ste.
Es importante que se intenten establecer mtricas bien definidas para medir el rendimiento del Centro
de Servicios y la apreciacin 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 electrnico y telfono o fax.
Porcentaje de incidentes que se cierran en primera lnea de soporte.
Porcentaje de consultas respondidas en primera instancia.
Anlisis estadsticos de los tiempos de resolucin de incidentes organizados segn su urgencia e
impacto.
Cumplimiento de los SLAs.
Nmero de llamadas gestionadas por cada miembro del personal del Service Desk.
Otra importante tarea de control es supervisar el grado de satisfaccin del cliente. Esto se puede
conseguir mediante el uso de encuestas que permitan evaluar la percepcin 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
opinin del cliente respecto a la atencin recibida, su satisfaccin respecto a la solucin ofrecida, etc.
Toda esta informacin debe ser recopilada y analizada peridicamente para mejorar la calidad del
servicio.
Gestin de Incidentes
Visin General
La Gestin de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupcin
en el servicio de la manera ms rpida y eficaz posible.
La Gestin de Incidentes no debe confundirse con la Gestin 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 interrelacin entre
ambas.
Introduccin y Objetivos
Los objetivos principales de la Gestin de Incidentes son:
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 gestin de incidentes:
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 concesin de nuevas licencias, cambio de informacin
de acceso, etc. siempre que estos servicios se consideren estndar.
Cualquier cambio que requiera una modificacin de la infraestructura no se considera un servicio
estndar y requiere el inicio de una Peticin de Cambio (RFC) que debe ser tratada segn los principios
de la Gestin de Cambios.
Los principales beneficios de una correcta Gestin de Incidentes incluyen:
Por otro lado una incorrecta Gestin de Incidentes puede acarrear efectos adversos tales como:
Impacto: determina la importancia del incidente dependiendo de cmo ste afecta a los
procesos de negocio y/o del nmero de usuarios afectados.
Urgencia: depende del tiempo mximo de demora que acepte el cliente para la resolucin del
incidente y/o el nivel de servicio acordado en el SLA.
Tambin se deben tener en cuenta factores auxiliares tales como el tiempo de resolucin esperado y los
recursos necesarios: los incidentes sencillos se tramitarn cuanto antes.
Dependiendo de la prioridad se asignarn los recursos necesarios para la resolucin 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 funcin 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 algn superior que pueda tomar decisiones que se escapan
de su responsabilidad. A este proceso se le denomina escalado.
Bsicamente hay dos tipos diferentes de escalado:
La admisin a trmite del incidente: el Centro de Servicios debe de ser capaz de evaluar en
primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario
reenviarlo a una autoridad competente.
Clasificacin
La clasificacin de un incidente tiene como objetivo principal el recopilar toda la informacin que
pueda ser de utilizada para la resolucin del mismo.
El proceso de clasificacin debe implementar, al menos, los siguientes pasos:
Categorizacin: se asigna una categora (que puede estar a su vez subdividida en ms niveles)
dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolucin. Se
identifican los servicios afectados por el incidente.
Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina,
segn criterios preestablecidos, un nivel de prioridad.
Asignacin de recursos: si el Centro de Servicios no puede resolver el incidente en primera
instancia designara al personal de soporte tcnico responsable de su resolucin (segundo nivel).
Monitorizacin 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
resolucin del incidente en base al SLA correspondiente y la prioridad.
Si fuera necesario se puede emitir una Peticin de Cambio (RFC). Si la incidencia fuera recurrente y
no se encuentra una solucin definitiva al mismo se deber informar igualmente a la Gestin de
Problemas para el estudio detallado de las causas subyacentes.
Cuando se halla solucionado el incidente se:
Por otro lado una correcta Gestin de Incidentes requiere de una infraestructura que facilite su
correcta implementacin. Entre ellos cabe destacar:
Para el correcto seguimiento de todo el proceso es indispensable la utilizacin de mtricas que permitan
evaluar de la forma ms objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave
a considerar son:
Gestin de Problemas
Visin General
Las funciones principales de la Gestin de Problemas son:
Investigar las causas subyacentes a toda alteracin, 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 Implementacin (PIR) para asegurar que los cambios han surtido los
efectos buscados sin crear problemas de carcter secundario.
Introduccin y Objetivos
Como se explico en la seccin de Gestin de Incidentes, esta ltima tiene como exclusivo objetivo el
restablecer lo ms rpidamente la calidad del servicio y no el determinar cuales han sido los orgenes y
causas del mismo.
Cuando algn tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura
TI es la funcin de la Gestin de Problemas el determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, an 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 Gestin de Problemas y su relacin con la
Gestin de Incidentes se resumen en el siguiente interactivo:
Entre las funciones principales de la Gestin de Problemas figuran:
Elevar RFCs a la Gestin de Cambios para llevar a cabo los cambios necesarios en la
infraestructura TI.
Realizar un seguimiento post-implementacin de todos los cambios para asegurar su correcto
funcionamiento.
Realizar informes que documenten no slo los orgenes y soluciones a un problema sino que
tambin sirvan de soporte a la estructura TI en su conjunto.
Analizar tendencias para prevenir incidentes potenciales.
Proceso
Las principales actividades de la Gestin 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 Gestin de Cambios. Asimismo efecta la Revisin Post Implementacin de
los mismos en estrecha colaboracin con la Gestin de Cambios.
Y cuando la estructura de la organizacin lo permite, desarrollar una Gestin de Problemas Proactiva
que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la
calidad del servicio.
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. Identificacin y Registro
Una de las tareas principales de la Gestin de Problemas es identificar los mismos. Las principales
fuentes de informacin utilizadas son:
La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus
causas y que se ha cerrado mediante algn tipo de solucin temporal es potencialmente un
problema. Sin embargo, se habr de analizar si este incidente es aislado o su impacto en la
estructura TI antes de elevarlo a la categora de problema.
Anlisis de la infraestructura TI: en colaboracin con la Gestin de Disponibilidad y de
Capacidad, la Gestin de Problemas debe analizar los diferentes procesos y determinar en que
aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.
Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicacin de
la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como
incidentes.
Todas las reas de la infraestructura TI deben colaborar con la Gestin de Problemas para identificar
problemas reales y potenciales informando a sta de cualquier sntoma que pueda ser seal 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 especficos de los incidentes asociados sino ms bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, informacin sobre:
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.
Documentacin incorrecta.
Falta de coordinacin entre diferentes reas.
...
Es tambin 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 informacin sobre errores conocidos
aplicables al problema en cuestin.
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.
Anlisis y Solucin
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
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 Gestin de
Cambios.
Una vez determinada la solucin ptima al problema y antes de elevar una RFC a la Gestin de
Cambios han de tenerse en cuenta las siguientes consideraciones:
Es la solucin temporal aportada suficiente para mantener unos niveles de calidad de servicios
aceptable?
Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la informacin sobre el error y su solucin 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 Gestin de Cambios la implementacin de los cambios de
infraestructura propuestos.
Una eficaz Gestin de Problemas tambin requiere determinar claramente quienes son los
responsables de cada proceso. Sin embargo, en pequeas organizaciones es recomendable no segmentar
en exceso las responsabilidades para evitar los costes asociados: sera poco eficaz y contraproducente
asignar unos recursos humanos desproporcionados al proceso de identificacin y solucin de
problemas.
Gestin de Configuraciones
Visin General
Las cuatro principales funciones de la Gestin de Configuraciones pueden resumirse en:
Introduccin 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 Gestin de Configuraciones es llevar un registro
actualizado de todos los elementos de configuracin de la infraestructura TI junto con sus
interrelaciones.
Esto no es una labor sencilla y requiere la colaboracin de los Gestores de los otros procesos, en
particular, de la Gestin de Cambios y Versiones.
Los objetivos principales de la Gestin de Configuraciones se resumen en:
Proporcionar informacin precisa y fiable al resto de la organizacin de todos los elementos que
configuran la infraestructura TI.
Mantener actualizada la Base de Datos de Configuraciones:
o Registro actualizado de todos los CIs : identificacin, tipo, ubicacin, estado,...
o Interrelacin entre los CIs.
o Servicios que ofrecen los diferentes CIs.
Servir de apoyo a los otros procesos, en particular, a la Gestin de Incidentes, Problemas y
Cambios.
Resolucin ms rpida 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 deteccin de estos errores sin una CMDB actualizada alarga
considerablemente el ciclo de vida de un problema.
Una Gestin de Cambios ms eficiente. Es imprescindible conocer la estructura previa para
disear un cambio que no genere nuevas incompatibilidades y/o problemas.
Reduccin de costes. El conocimiento detallado de todos los elementos de configuracin
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 organizacin.
Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar
vulnerabilidades en la infraestructura.
Mayor rapidez en la restauracin del servicio. Si se conocen todos los elementos de
configuracin y sus interrelaciones ser mucho ms sencillo recuperar la configuracin de
produccin en el tiempo ms breve posible.
Las principales dificultades con las que topa la Gestin de Configuraciones son:
Definiciones
A lo largo de este captulo hemos utilizado y utilizaremos con profusin conceptos tales como
elementos de configuracin (CI) y base de datos de gestin de configuraciones (CMDB) es por lo tanto
conveniente que nos detengamos en dar una definicin precisa de ambos.
Elementos de configuracin: tanto todas las componentes de los servicios TI como los servicios que
estos nos ofrecen constituyen diferentes elementos de configuracin. 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, ...
Documentacin: manuales, acuerdos de niveles de servicio, ...
En resumen, todos los componentes que han de ser gestionados por la organizacin TI.
La CMDB no se limita a una mera enumeracin del stock de piezas sino que nos brinda una imagen
global de la infraestructura TI de la organizacin.
Proceso
Las principales actividades de la Gestin de Configuraciones son:
Planificacin: determinar los objetivos y estrategias de la Gestin de Configuraciones.
Clasificacin y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y
nomenclatura predefinidos.
Monitorizacin y Control: monitorizar la CMDB para asegurar que todos los componentes
autorizados estn correctamente registrados y se conoce su estado actual.
Realizacin de auditoras: para asegurar que la informacin registrada en la CMDB coincide con la
configuracin real de la estructura TI de la organizacin.
Elaboracin de informes: para evaluar el rendimiento de la Gestin de Configuraciones y aportar
informacin de vital importancia a otras reas de la infraestructura TI.
Planificacin
La Gestin de Configuraciones es uno de los pilares de la metodologa ITIL por sus interrelaciones e
interdependencias con el resto de procesos. Por ello su implantacin es particularmente compleja.
Aunque ofrecer un detallado plan de implementacin de la Gestin de Configuraciones va mucho ms
all de lo que aqu podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que
consideramos esenciales:
Una falta de planificacin conducir con total certeza a una Gestin de Configuraciones defectuosa
con las graves consecuencias que esto supondr para el resto de los procesos.
Clasificacin y Registro
La principal tarea de la Gestin 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 organizacin y resultar, a la larga, en una dejacin de responsabilidades.
La informacin sea suficiente: debe existir, al menos un registro de todos los sistemas crticos
para la infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la
CMDB:
Es esencial incluir al menos todos los sistemas de hardware y software implicados en los
servicios crticos.
Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por
ejemplo, pueden obviarse componentes que ya han sido retirados.
Es recomendable incorporar, al menos, la documentacin asociada a proyectos, SLAs y
licencias.
En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos
en exceso ambiciosos pueden resultar contraproducentes.
Nomenclatura
Aunque este sea un aspecto muy tcnico es de vital importancia predefinir los cdigos de clasificacin
de los CIs para que el sistema sea funcional:
La identificacin debe ser, por supuesto, nica y si es posible interpretable por los usuarios.
Este cdigo debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible
debe ir fsicamente unido al mismo (mediante una etiqueta de difcil eliminacin).
Los cdigos no deben ser slo utilizados para componentes de hardware sino tambin para
documentacin y software.
Monitorizacin
Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta
informacin puede ser de gran utilidad, por ejemplo, a la Gestin de Disponibilidad para conocer que
CIs han sido responsables de la degradacin de la calidad del servicio.
Puede ser de gran utilidad para el anlisis 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 Gestin Financiera la monitorizacin del ciclo de vida
de , digamos, los switches instalados a la hora de adoptar decisiones de compra de nuevo material:
Control
La Gestin 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 aprobacin 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 produccin".
Las tareas de control deben centrarse en:
Auditoras
El objetivo de las auditoras es asegurar que la informacin registrada en la CMDB coincide con la
configuracin real de la estructura TI de la organizacin.
Existen herramientas que permiten una gestin remota, centralizada y automtica de los elementos de
configuracin de hardware y software. La informacin recopilada puede ser utilizada para actualizar la
CMDB.
Si el alcance de la CMDB incluye aspectos como documentacin, SLAs, personal, etc. es necesario
complementar estos datos con auditoras manuales. stas deben realizarse con cierta frecuencia y al
menos:
Gestin de Cambios
Visin 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 "evolucin a mejor" requiere
necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que an 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 ms peligroso el estancamiento en servicios y tecnologas desactualizados.
Las principales razones para la realizacin de cambios en la infraestructura TI son:
Introduccin y Objetivos
El objetivo primordial de la Gestin de Cambios es que se realicen e implementen adecuadamente
todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de
procedimientos estndar.
La Gestin de Cambios debe trabajar para asegurar que los cambios:
Estn justificados.
Se llevan a cabo sin perjuicio de la calidad del servicio TI.
Estn convenientemente registrados, clasificados y documentados.
Han sido cuidadosamente testeados en un entorno de prueba.
Se ven reflejados en la CMDB.
Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un
incorrecto funcionamiento tras su implementacin.
Los principales beneficios derivados de una correcta gestin del cambio son:
La implementacin de una adecuada poltica de gestin de cambios tambin se encuentra con algunas
serias dificultades:
Los diferentes departamentos deben aceptar la autoridad de la Gestin de Cambios sobre todo
en lo que respecta al cambio, independientemente de que este se realice para solucionar un
problema, mejorar un servicio o adaptarse a requisitos legales.
No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la
informacin sobre los CIs en la CMDB.
Los encargados de la Gestin de Cambios no conocen a fondo las actividades, servicios,
necesidades y estructura TI de la organizacin incapacitndoles para desarrollar correctamente
su actividad.
Los Gestores del Cambio no disponen de las herramientas adecuadas de software para
monitorizar y documentar adecuadamente el proceso.
No existe el compromiso suficiente de la direccin por implementar rigurosamente los procesos
asociados.
Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el
contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para
la calidad del servicio.
Conceptos bsicos
En el resto de este captulo se utilizar con frecuencia el concepto de Gestor de Cambios y Consejo
Asesor del Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivas
atribuciones:
Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el ltimo
responsable de todas las tareas asignadas a la Gestin de Cambios. En grandes organizaciones
el Gestor de Cambios puede disponer de un equipo de asesores especficos para cada una de las
diferentes reas.
Consejo Asesor de Cambios (CAB): es un rgano interno, presidido por el Gestor de
Cambios, formado principalmente por representantes de las principales reas de la gestin de
servicios TI. Sin embargo, en algunos casos tambin puede incorporar:
o Consultores externos.
o Representantes de los colectivos de usuarios.
o Representantes de los principales proveedores de software y hardware.
Proceso
Registro
El primer paso del proceso de cambio es registrar adecuadamente las RFCs.
El origen de una RFC puede ser de muy distinta ndole:
No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten
peridicamente pueden acordarse procedimientos estndar que no requiera la aprobacin de la Gestin
de Cambios en cada caso.
Independientemente de su origen el correcto registro inicial de una RFC requerir, cuando menos, de
los siguientes datos:
Fecha de recepcin.
Identificador nico de la RFC.
Identificador del error conocido asociado (dado el caso).
Descripcin del cambio propuesto:
o Motivacin.
o Propsito.
o CIs involucrados.
Este registro deber ser actualizado con toda la informacin generada durante el proceso para permitir
un detallado seguimiento del mismo desde su aprobacin hasta la evaluacin final y cierre.
La informacin de registro debe ser actualizada durante todo el proceso y debe incluir al menos:
Aceptacin y Clasificacin
Aceptacin
Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser
simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su
modificacin si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor
definicin. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la
solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que
pueda ser consecuentemente modificada.
La aceptacin del cambio no implica su posterior aprobacin por el CAB y es slo indicacin de que se
ha encontrada justificado su ulterior procesamiento.
Clasificacin
Tras su aceptacin se deben asignar a la RFC una prioridad y categora dependiendo de la urgencia y el
impacto de la misma.
La prioridad determinar la importancia relativa de esta RFC respecto a otras RFCs pendientes y ser el
dato relevante para establecer el calendario de cambios a realizar.
La categora determina la dificultad e impacto de la RFC y ser el parmetro relevante para determinar
la asignacin de recursos necesarios, los plazos previstos y el nivel de autorizacin requerido para la
implementacin del cambio.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debera considerar una
clasificacin que incluyera, al menos, los siguientes niveles de prioridad:
Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan
actualizar ciertos paquetes de software o se compre nuevo hardware, etc.
Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algn otro
cambio de ms alta prioridad.
Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que
deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su
prxima reunin y adoptar las medidas pertinentes que permitan una pronta solucin.
Urgente: es necesario resolver un problema que esta provocando una interrupcin o deterioro
grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado
cambio de emergencia que trataremos de forma independiente.
Aprobacin y Planificacin
La planificacin es esencial para una buena gestin del cambio.
Los sistemas de gestin de la informacin son muy susceptibles a los cambios de configuracin por las
sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede
desencadenar una reaccin en cadena con resultados catastrficos. Es imprescindible, como mnimo,
disponer siempre de planes de "back out" que permitan la recuperacin de la ltima configuracin
estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse peridicamente para analizar y eventualmente aprobar los RFCs
pendientes y elaborar el FSC o calendario del cambio correspondiente.
Para su aprobacin el cambio se debe evaluar minuciosamente:
En el caso de cambios que tengan un alto impacto debe tambin consultarse a la direccin pues pueden
entrar en consideracin aspectos de carcter estratgico y de poltica general de la organizacin.
Una vez aprobado el cambio (en caso contrario se seguira el proceso ya descrito para el caso de no
aceptacin) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de
cambios" que formalmente equivaldran a un solo cambio. Esto tiene algunas ventajas:
Implementacin
Aunque la Gestin de Cambios NO es la encargada de implementar el cambio, algo de lo que se
encarga habitualmente la Gestin de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deber monitorizar el proceso para asegurar que:
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen
una valoracin preliminar de los nuevos sistemas en lo que respecta a su:
Funcionalidad.
Usabilidad.
Accesibilidad.
La opinin de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se
encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio
por parte de cierto tipo de usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es funcin tanto de la
Gestin de Cambios como del Service Desk mantener informados a los usuarios de los futuros
cambios y, dentro de lo posible, hacerles participes del mismo:
Evaluacin
Antes de proceder al cierre del cambio es necesario realizar una evaluacin que permita valorar
realmente el impacto del mismo en la calidad del servicio y en la productividad de la organizacin.
Si la evaluacin final determina que el proceso y los resultados han sido satisfactorios se proceder al
cierre de la RFC y toda la informacin se incluir en la PIR asociada.
Cambios de Emergencia
Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de
una planificacin deficiente a veces resultan inevitables.
Cualquier interrupcin del servicio de alto impacto, ya sea por el nmero de usuarios afectados o
porque se han visto involucrados sistemas o servicios crticos para la organizacin, debe encontrar una
respuesta inmediata. Es frecuente que la solucin al problema requiera un cambio y que ste haya de
realizarse siguiendo un procedimiento de urgencia.
El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben
establecer protocolos de validacin de los cambios urgentes que pueden requerir:
Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los
procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la
documentacin asociada al cambio se realicen a posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma informacin
de la que dispondramos tras un cambio normal. Si esto no fuera as se podran provocar situaciones de
cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que seran fuente de
nuevas incidencias y problemas.
RFCs solicitados.
Gestin de Versiones
Visin General
La Gestin de Versiones es la encargada de la implementacin y control de calidad de todo el software
y hardware instalado en el entorno de produccin.
La Gestin de Versiones debe colaborar estrechamente con la Gestin de Cambios y de
Configuraciones para asegurar que toda la informacin relativa a las nuevas versiones se integra
adecuadamente en la CMDB de forma que sta se halle correctamente actualizada y ofrezca una
imagen real de la configuracin de la infraestructura TI.
La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de Software Definitivo
(DSL), donde se guardan copias de todo el software en produccin, y el Depsito de Hardware
Definitivo (DHS), donde se almacenan piezas de repuesto y documentacin para la rpida reparacin
de problemas de hardware en el entorno de produccin.
Introduccin y Objetivos
Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI
convierten en tarea delicada la implementacin de cualquier cambio.
La Gestin de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea
especfica de la Gestin de Versiones el disear, poner a prueba e instalar en el entorno de produccin
los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificacin y coordinacin con el resto de procesos asociados a
la Gestin de Servicios TI.
Entre los principales objetivos de la Gestin de Versiones se incluyen:
Las principales dificultades con las que topa la Gestin de Versiones son:
Conceptos bsicos
Una versin es un grupo de CIs de nueva creacin o modificados que han sido validados para su
instalacin en el entorno de produccin. Las especificaciones funcionales y tcnicas de una versin
estn determinadas en la RFC correspondiente.
Las versiones pueden clasificarse, segn su impacto en la infraestructura TI, en:
Como pueden llegar a existir mltiples versiones es conveniente definir una referencia o cdigo que los
identifique unvocamente. El sistema universalmente aceptado es:
Aunque en algunos casos esta clasificacin se refina an ms (vea, por ejemplo, en la ayuda la versin
de su navegador).
En su ciclo de vida una versin puede encontrase en diversos estados: desarrollo, pruebas, produccin y
archivado.
El siguiente diagrama nos ilustra grficamente la evolucin temporal de una versin:
Versin delta: slo se testean e instalan los elementos modificados. Esta opcin tiene como
ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e
incompatibilidades en el entorno de produccin.
Versin completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o
no. Aunque esta opcin es obviamente ms trabajosa es ms improbable que se generen
incidentes tras la instalacin si se han realizado las pruebas pertinentes.
Paquete de Versiones: La Gestin de Cambios puede optar por distribuir de forma
sincronizada diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al
entorno TI. En algunos casos esta opcin es obligada por incompatibilidades entre una nueva
versin con software o hardware previamente instalado. Pensemos, por ejemplo, en la
migracin a un nuevo sistema operativo que requiere hardware ms avanzado y/o nuevos
versiones de los programas ofimticos.
DSL
La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el
entorno TI. Esto incluye no solo sistemas operativos y aplicaciones sino tambin controladores de
dispositivos y documentacin asociada.
La DSL debe contener el histrico completo de versiones de un mismo software para proporcionar la
versin necesaria en caso de que se deban implementar los planes de back-out.
La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up
peridicos.
DHS
El Depsito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de
produccin.
Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se
hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).
Proceso
Las principales actividades de la Gestin de Versiones se resumen en:
Planificacin
Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una
metodologa de trabajo. Esto es especialmente importante para los casos de versiones menores y de
emergencia pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes
especficos que tomen en cuenta las peculiaridades de cada caso.
A la hora de planificar correctamente el lanzamiento de una nueva versin se deben de tomar en cuenta
los siguientes factores:
Cmo puede afectar la nueva versin a otras reas del entramado TI.
Desarrollo
La Gestin de Versiones es la encargada del diseo y construccin de las nuevas versiones siguiendo
las pautas marcadas en las RFCs correspondientes.
A veces el desarrollo se realizara "en la casa" y muchas otras requerir la participacin de proveedores
externos. En este segundo caso, la tarea de la Gestin de Versiones ser la de asegurar que el paquete
o paquetes de software o hardware ofrecidos cumple las especificaciones detalladas en la RFC.
Asimismo, la Gestin de Versiones ser la responsable de todo el proceso de configuracin necesario.
El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de
instalacin necesarios para el despliegue de la versin. Estos scripts debern tener en cuenta aspectos
tales como:
Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrn que tomar
en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.
Validacin
Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de
produccin una nueva versin con razonables garantas de xito.
Las pruebas no deben limitarse a una validacin de carcter tcnico (ausencia de errores) sino que
tambin deben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versin
cumple los requisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia
al cambio en los usuarios que debe ser tenida en consideracin).
Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podr volver a
la ltima versin estable de una forma rpida, ordenada y sin perdidas de valiosa informacin.
Las principales actividades realizadas en el proceso de prueba deben incluir:
La Gestin de Cambios ser la encargada de dar la validacin final a la versin para que se proceda a
su instalacin. Si la versin no fuera aceptada se devolver a la Gestin de Cambios para su
reevaluacin.
Implementacin
Llego el momento de la verdad: la distribucin de la nueva versin, tambin conocida como rollout.
El rollout puede ser de varios tipos:
El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan
sus tareas y responsabilidades especficas. En particular los usuarios finales deben estar puntualmente
informados del calendario de lanzamiento y de cmo este puede afectar a sus actividades diarias.
Es imprescindible determinar claramente:
Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso.
Cundo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones
geogrficas.
Que mtricas determinan la puesta en marcha de los planes de back-out y si estos deben ser
completos o parciales.
Tras la implementacin, la Gestin de Versiones debe ser puntualmente informada por el Service
Desk de los comentarios, quejas, incidentes, etc. que la nueva versin haya podido suscitar. Toda esta
informacin deber ser analizada para asegurar que las prximas versiones incorporen las sugerencias
recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que
puedan tener futuros cambios.
Comunicacin y Formacin
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carcter tcnico se obvie
el factor humano.
Salvo contadas excepciones, es necesaria la interaccin usuario-aplicacin y sta suele representar el
eslabn ms dbil de la cadena.
Es intil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formacin,
no se encuentran en disposicin de aprovechar sus ventajas.
La (in)formacin debe estructurarse en distintos niveles:
Los usuarios deben conocer el prximo lanzamiento de una nueva versin y conocer con
anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para
participar, a su discrecin, en el proceso.
Siempre que sea posible las pruebas de carcter funcional deben ser realizadas por un selecto
grupo de usuarios finales. Durante este proceso de prueba se documentarn y analizarn:
o La experiencia subjetiva de usuario.
o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayan
surgido durante el uso de la nueva versin.
o La claridad de la documentacin que se pondr a disposicin del usuario final.
Cuando se considere oportuno se impartirn cursos presenciales o remotos mediante mdulos
de e-learning sobre el funcionamiento de la nueva versin.
Se desarrollar una pgina de FAQs donde los usuarios puedan aclarar las dudas ms habituales
y puedan solicitar ayuda o soporte tcnico en el uso de la nueva versin.