ADMINISTRACIÓN DE

TECNOLOGÍAS DE
INFORMACIÓN
PREPARADO Y COMPILADO POR:
ING. CARLOS ALBERTO RODRIGUEZ RODRIGUEZ

VERANO DEL 2010.

UNIDAD 3:
Soporte del servicio de
tecnologías de información.
3.1 Introducción
3.2 El Centro de Servicios.
3.3 Gestión de los Incidentes
3.4 Gestión de los Problemas
3.5 Gestión de los Cambios
3.6 Gestión de las Versiones.
3.7 Gestión de las Configuraciones
3.1. INTRODUCCIÓN

El soporte al servicio se preocupa 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:
3.1. INTRODUCCIÓN
3.2. CENTRO DE SERVICIOS
(SERVICE DESK)
3.1. CENTRO DE SERVICIOS (SERVICE DESK)
El objetivo primordial, aunque no único, del Centro de Servicios
es servir de punto de contacto entre los usuarios y la Gestión de
Servicios TI.
Un Centro de Servicios, 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.
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 están
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:
•Supervisión de los contratos de mantenimiento
y niveles de servicio.
•Canalización de las Peticiones de Servicio de
los clientes.
•Gestión de las licencias de software.
•Centralización de todos los procesos asociados
a la Gestión TI.
Los principales beneficios de una correcta
implantación del Centro de Servicios se resumen
en:
•Reducción de costos mediante una eficiente
asignación de recursos.
•Una mejor atención al cliente que repercute en
un mayor grado de satisfacción y fidelización del
mismo.
•Apertura de nuevas oportunidades de negocio.
•Centralización de procesos que mejoran la
gestión de la información y la comunicación.
•Soporte al servicio proactivo.
Estructura del centro de servicios
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:
•Sea fácilmente accesible.
•Ofrezca un servicio de calidad consistente y
homogéneo.
•Mantenga puntualmente informados a los
usuarios y lleve un registro de toda la interacción
con los mismos.
•Sirva de soporte al negocio.
•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:
•Conocer todos los protocolos de interacción con
el cliente: guiones, checklists,...
•Disponer de herramientas de software que les
permitan llevar un registro de la interacción con
los usuarios.
•Saber cuándo se debe realizar un escalado a
instancias superiores o entrar en discusiones
sobre cumplimiento de SLAs.
•Tener rápido acceso a las bases de
conocimiento para ofrecer un mejor servicio a los
usuarios.
•Recibir formación sobre los productos y
servicios de la empresa.
Estructura física
Dependiendo de las necesidades de servicio:
locales, globales, 24/7,...se debe de optar por una
estructura diferente para el Centro de Servicios.

Existen tres formatos básicos:

•Centralizado

•Distribuido

•Virtual
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 reducen los costos.
•Se optimizan los recursos.
•Se simplifica la gestión.
•Sin embargo surgen importantes inconvenientes
cuando:
•Los usuarios se encuentran en diversos
emplazamientos geográficos: diferentes idiomas,
productos y servicios.
•Se necesita dar servicios de mantenimiento "on-
site".
Service Desk Centralizado
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 generalmente más caro.
•Se complica la gestión y monitorización del
servicio.
•Se dificulta el flujo de datos y conocimiento
entre los diferentes Service Desks.
Service Desk Distribuido
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 evitan duplicidades innecesarias con el
consiguiente ahorro de costos.
•Se puede ofrecer un "servicio local" sin incurrir
en costos adicionales.
•La calidad del servicio es homogénea y
consistente.
Service Desk Virtual
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.

La imagen de marca de una empresa puede

depender en gran medida de la calidad del servicio
prestado por su Service Desk.
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.
3.3. Gestión de los
incidentes
3.3. Gestión de los incidentes

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.
El siguiente diagrama resume el proceso de
gestión de incidentes:
Aunque el concepto de incidencia se asocia
naturalmente con cualquier malfuncionamiento de
los sistemas de hardware y software según el libro
de Soporte del Servicio de ITIL un incidente es:

“Cualquier evento que no forma parte de la

operación estándar de un servicio y que causa, o
puede causar, una interrupción o una reducción de
calidad del mismo”.
Por lo que casi cualquier llamada al Centro de
Servicios puede clasificarse como un incidente, lo
que incluye a las Peticiones de Servicio tales
como concesión de nuevas licencias, cambio de
información de acceso, etc. siempre que estos
servicios se consideren estándar.

Cualquier cambio que requiera una modificación

de la infraestructura no se considera un servicio
estándar y requiere el inicio de una Petición de
Cambio (RFC) que debe ser tratada según los
principios de la Gestión de Cambios.
Los principales beneficios de una correcta
Gestión de Incidentes incluyen:

•Mejorar la productividad de los usuarios.

•Cumplimiento de los niveles de servicio
acordados en el SLA.
•Mayor control de los procesos y monitorización
del servicio.
•Optimización de los recursos disponibles.
•Una CMDB más precisa pues se registran los
incidentes en relación con los elementos de
configuración.
•Y principalmente: mejora la satisfacción general
de clientes y usuarios.
Por otro lado una incorrecta Gestión de
Incidentes puede acarrear efectos adversos tales
como:

•Reducción de los niveles de servicio.

•Se dilapidan valiosos recursos: demasiada
gente o gente del nivel inadecuado trabajando
concurrentemente en la resolución del
incidente.
•Se pierde valiosa información sobre las causas
y efectos de los incidentes para futuras
reestructuraciones y evoluciones.
•Se crean clientes y usuarios insatisfechos por
la mala y/o lenta gestión de sus incidentes.
Las principales dificultades a la hora de
implementar la Gestión de Incidentes se
resumen en:
•No se siguen los procedimientos previstos y se
resuelven las incidencias sin registrarlas o se escalan
innecesariamente y/o omitiendo los protocolos
preestablecidos.
•No existe un margen operativo que permita gestionar
los “picos” de incidencias por lo que éstas no se
registran adecuadamente e impiden la correcta
operación de los protocolos de clasificación y escalado.
•No están bien definidos los niveles de calidad de
servicio ni los productos soportados. Lo que puede
provocar que se procesen peticiones que no se incluían
en los servicios previamente acordados con el cliente.
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.

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:

•
Es frecuente que el Centro de Servicios no se
vea capaz de resolver en primera instancia un
incidente y para ello deba recurrir a un
especialista o a algún superior que pueda tomar
decisiones que se escapan de su responsabilidad.
A este proceso se le denomina escalado.
Básicamente hay dos tipos diferentes de
escalado:
•Escalado funcional: Se requiere el apoyo de un
especialista de más alto nivel para resolver el problema.
•Escalado jerárquico: Debemos acudir a un responsable
de mayor autoridad para tomar decisiones que se escapen
de las atribuciones asignadas a ese nivel, como, por
ejemplo, asignar más recursos para la resolución de un
incidente específico.
El proceso de escalado puede resumirse
gráficamente como sigue:
El siguiente diagrama muestra los procesos
implicados en la correcta Gestión de Incidentes:
Registro
La admisión y registro del incidente es el primer y
necesario paso para una correcta gestión del
mismo.

Las incidencias pueden provenir de diversas

fuentes tales como usuarios, gestión de
aplicaciones, el mismo Centro de Servicios o el
soporte técnico, entre otros.

El proceso de registro debe realizarse

inmediatamente pues resulta mucho más costoso
hacerlo posteriormente y se corre el riesgo de que
la aparición de nuevas incidencias demore
indefinidamente el proceso.
La admisión a tramite del incidente:
•El Centro de Servicios debe de ser capaz de evaluar en primera
instancia si el servicio requerido se incluye en el SLA del cliente y en
caso contrario reenviarlo a una autoridad competente.
•Comprobación de que ese incidente aún no ha sido registrado: es
frecuente que más de un usuario notifique la misma incidencia y por lo
tanto han de evitarse duplicaciones innecesarias.
•Asignación de referencia: al incidente se le asignará una referencia
que le identificará unívocamente tanto en los procesos internos como
en las comunicaciones con el cliente.
•Registro inicial: se han de introducir en la base de datos asociada la
información básica necesaria para el procesamiento del incidente
(hora, descripción del incidente, sistemas afectados...).
•Información de apoyo: se incluirá cualquier información relevante
para la resolución del incidente que puede ser solicitada al cliente a
través de un formulario específico, o que pueda ser obtenida de la
propia CMDB (hardware interrelacionado), etc.
•Notificación del incidente: en los casos en que el incidente pueda
afectar a otros usuarios estos deben ser notificados para que
conozcan como esta incidencia puede afectar su flujo habitual de
trabajo.
Análisis, Resolución y Cierre de Incidentes

En primera instancia se examina el incidente con

ayuda de la KB para determinar si se puede
identificar con alguna incidencia ya resuelta y
aplicar el procedimiento asignado.

Si la resolución del incidente se escapa de las

posibilidades del Centro de Servicios éste
redirecciona el mismo a un nivel superior para su
investigación por los expertos asignados. Si estos
expertos no son capaces de resolver el incidente
se seguirán los protocolos de escalado
predeterminados.
Durante todo el ciclo de vida del incidente se debe
actualizar la información almacenada en las
correspondientes bases de datos para que los
agentes implicados dispongan de cumplida
información sobre el estado del mismo.

Si fuera necesario se puede emitir una Petición

de Cambio (RFC). Si la incidencia fuera
recurrente y no se encuentra una solución
definitiva al mismo se deberá informar igualmente
a la Gestión de Problemas para el estudio
detallado de las causas subyacentes.
Cuando se haya solucionado el incidente se:
Confirma con los usuarios la solución satisfactoria
del mismo.

•Incorpora el proceso de resolución a la KB.

•Reclasifica el incidente si fuera necesario.
•Actualiza la información en la CMDB sobre los
elementos de configuración (CI) implicados en
el incidente.
•Cierra el incidente.
CONTROL DEL PROCESO

La correcta elaboración de informes forma parte

esencial en el proceso de Gestión de Incidentes.
Estos informes deben aportar información esencial
para, por ejemplo:
•La Gestión de Niveles de Servicio: es esencial que
los clientes dispongan de información puntual sobre
los niveles de cumplimiento de los SLAs y que se
adopten medidas correctivas en caso de
incumplimiento.
•Monitorizar el rendimiento del Centro de Servicios:
conocer el grado de satisfacción del cliente por el
servicio prestado y supervisar el correcto
funcionamiento de la primera línea de soporte y
atención al cliente.
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:
1. Evitar escalados innecesarios.
2. Convertir el “know how” de los técnicos en un activo
duradero de la empresa.
3. 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.
3.4. Gestión de los
problemas
3.4. Gestión de los problemas

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.
La Gestión de Incidentes, tiene como objetivo el
restablecer lo más rápidamente la calidad del
servicio y no el determinar las 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:
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.
El principal objetivo del Control de Problemas es
conseguir que estos se conviertan en Errores
Conocidos para que el Control de Errores
pueda proponer las soluciones correspondientes.
El Control de Problemas se compone en esencia
de tres fases:
1. Identificación y Registro
Una de las tareas principales de la Gestión de
Problemas es identificar los mismos. Las
principales fuentes de información utilizadas son:

La base de datos de Incidentes: en principio

cualquier incidente del que no se conocen sus
causas y que se ha cerrado mediante algún tipo
de solución temporal es potencialmente un
problema. Sin embargo, se habrá de analizar si
este incidente es aislado o su impacto en la
estructura TI antes de elevarlo a la categoría de
problema.
Análisis de la infraestructura TI: en
colaboración con la Gestión de Disponibilidad y de
Capacidad, la Gestión de Problemas debe
analizar los diferentes procesos y determinar en
que aspectos se debe reforzar los sistemas y
estructuras TI para evitar futuros problemas.

Deterioro de los Niveles de Servicio: el

descenso del rendimiento puede ser una
indicación de la existencia de problemas
subyacentes que no se hayan manifestado de
forma explicita como incidentes.
El registro debe incorporar, entre otra, información
sobre:

•Los CIs implicados.

•Causas del problema.
•Síntomas asociados.
•Soluciones temporales.
•Servicios involucrados.
•Niveles de prioridad, urgencia e impacto.
•Estado: activo, error conocido, cerrado.
2. Clasificación y Asignación de Recursos
La clasificación del problema engloba desde las
características generales de éste, tales como si es
un problema de hardware o software, que áreas
funcionales se ven afectadas y detalles sobre los
diferentes elementos de configuración (CIs)
involucrados en el mismo.
Un factor esencial es la determinación de la
prioridad del problema, que al igual que en el caso
de los incidentes, se determina tanto a partir de la
urgencia (demora aceptable para la solución del
problema) como de su impacto (grado de deterioro
de la calidad del servicio).
3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis

son:

•Determinar las causas del problema.

•Proporcionar soluciones temporales a la

Gestión de Incidentes para minimizar el
impacto del problema hasta que se implemente
los cambios necesarios que lo resuelvan
definitivamente.
Es esencial tener en cuenta que no siempre el
origen del problema es un error de hardware o
software. Es 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.
Una vez que el Control de Problemas ha
determinado las causas de un problema es
responsabilidad del Control de Errores el registro
del mismo como error conocido.
Identificación y Registro de errores
El registro de los errores conocidos es de vital
importancia para la Gestión de Incidentes pues
debe llevar asociado, siempre que esto sea
posible, algún tipo de solución temporal que
permita minimizar el impacto de los incidentes
asociados.
Análisis y Solución
Se deben investigar diferentes soluciones para el
error evaluando en cada momento:
•El posible impacto de las mismas en la
infraestructura TI.
•Los costos asociados.
•Sus consecuencias sobre los SLAs.
Una vez determinada la solución óptima al
problema y antes de elevar una RFC a la Gestión
de Cambios han de tenerse en cuenta las
siguientes consideraciones:

•¿Es conveniente demorar la solución? Ya sea

porque se prevén cambios significativos en la
infraestructura TI a corto plazo o por el escaso
impacto del problema en cuestión.
•¿Es la solución temporal aportada suficiente
para mantener unos niveles de calidad de
servicios aceptable?
•¿Los beneficios justifican los costos
asociados?
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.
3.5. GESTION DE LOS
CAMBIOS
3.5. Gestión de los cambios
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 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.
La Gestión de Cambios debe trabajar para
asegurar que los cambios:
•Están justificados.
•Se llevan a cabo sin perjuicio de la calidad del
servicio TI.
•Están convenientemente registrados, clasificados
y documentados.
•Han sido cuidadosamente testeados en un
entorno de prueba.
•Se ven reflejados en la CMDB.
•Pueden deshacerse mediante planes de "retirada
del cambio" (back-outs) en caso de un incorrecto
funcionamiento tras su implementación.
Las actividades principales de la Gestión de
Cambios se resumen en el siguiente diagrama:
Los principales beneficios derivados de una
correcta gestión del cambio son:
•Se reducen los incidentes y problemas potencialmente
asociados a todo cambio.
•Se puede retornar a configuraciones estables de manera
sencilla y rápida en caso de que el cambio tenga un
impacto negativo en la estructura TI.
•Se reduce el número de "back-outs" necesarios.
•Los cambios son mejor aceptados y se evitan "tendencias
inmovilistas".
•Se evalúan los verdaderos costos asociados al cambio y
por lo tanto es más sencillo valorar el retorno real a la
inversión.
•La CMDB está correctamente actualizada, algo
imprescindible para la correcta gestión del resto de
procesos TI.
•Se desarrollan procedimientos de cambio estándar que
permiten la rápida actualización de sistemas no críticos.
La implementación de una adecuada política de
gestión de cambios también se encuentra con algunas
serias dificultades:
•Los diferentes departamentos deben aceptar la
autoridad de la Gestión de Cambios sobre todo en lo
que respecta al cambio, independientemente de que
este se realice para solucionar un problema, mejorar
un servicio o adaptarse a requisitos legales.
•No se siguen los procedimientos establecidos y, en
particular, no se actualiza correctamente la
información sobre los CIs en la CMDB.
•Los encargados de la Gestión de Cambios no
conocen a fondo las actividades, servicios,
necesidades y estructura TI de la organización
incapacitándoles para desarrollar correctamente su
actividad.
•Los Gestores del Cambio no disponen de las
herramientas adecuadas de software para monitorizar
y documentar adecuadamente el proceso.
•No existe el compromiso suficiente de la dirección por
implementar rigurosamente los procesos asociados.
•Se adoptan procedimientos excesivamente
restrictivos que dificultan la mejora o por el contrario el
proceso de cambio se trivializa provocando una falta
de estabilidad necesaria para la calidad del servicio.
Las principales actividades de la Gestión de
Cambios se resumen en:
•Monitorizar y dirigir todo el proceso de cambio.
•Registrar, evaluar y aceptar o rechazar las
RFCs recibidas.
•Convocar reuniones del CAB, excepto en el
caso de cambios menores, para la aprobación
de las RFCs y la elaboración del FSC.
•Coordinar el desarrollo e implementación del
cambio.
•Evaluar los resultados del cambio y proceder a
su cierre en caso de éxito.
El primer paso del proceso de cambio es registrar
adecuadamente las RFCs.

El origen de una RFC puede ser de muy distinta

índole:

Gestión de Problemas: se encarga de proponer

soluciones a errores conocidos. En la mayoría de
los casos esta solución acarrea un cambio en la
infraestructura TI. En este caso el RFC debe ser
registrado con información del error conocido
asociado para que posteriormente pueda ser
evaluada correctamente la pertinencia del
proceso.
El origen de una RFC puede ser de muy distinta
índole:

Nuevos Servicios: el desarrollo de nuevos

servicios usualmente requiere cambios de la
infraestructura TI. En este caso es importante
coordinar todo el proceso con las Gestiones de
Capacidad, Disponibilidad y Niveles de Servicio
para asegurar que estos cambios cumplen las
expectativas previstas y no deterioran la calidad
de los otros servicios prestados.
El origen de una RFC puede ser de muy distinta
índole:

Estrategia empresarial: la dirección puede

decidir una redirección estratégica que puede
afectar, por ejemplo, a los niveles de servicio
ofrecidos o a la implantación de un nuevo CRM,
etc. y que por regla general requieren de cambios
de hardware, software y/o procedimientos.
El origen de una RFC puede ser de muy distinta
índole:
Actualizaciones de software de terceros: los
proveedores pueden dejar de soportar versiones
anteriores de paquetes de software o introducir
nuevas versiones con grandes mejoras que
recomienden la actualización.
Imperativo legal: un cambio de legislación (como,
por ejemplo, la LOPD (Ley orgánica de protección
de datos para España), la obligación de emitir
comprobantes digitales en México, entre otros,
puede exigir cambios en la infraestructura TI.
Otro: en principio cualquier empleado, cliente o
proveedor puede sugerir mejoras en los servicios
que pueden requerir cambios en la infraestructura.
Independientemente de su origen el correcto registro
inicial de una RFC requerirá, cuando menos, de los
siguientes datos:
•Fecha de recepción.
•Identificador único de la RFC.
•Identificador del error conocido asociado (dado el
caso).
•Descripción del cambio propuesto:
1. Motivación.
2. Propósito.
3. CIs involucrados.
4. Estimación de recursos necesarios para la
implementación.
5. Tiempo estimado.
•Estatus: que inicialmente será el de "registrado".
Este registro deberá ser actualizado con toda la información
generada durante el proceso para permitir un detallado
seguimiento del mismo desde su aprobación hasta la
evaluación final y cierre.
La información de registro debe ser actualizada durante todo
el proceso y debe incluir al menos:
•Estatus actualizado: "aceptado", "rechazado", "implementado"
•Fecha de aceptación (denegación) del RFC.
•Evaluación preliminar de la Gestión del Cambio.
•Prioridad y categoría.
•Planes de "back out".
•Recursos asignados.
•Fecha de implementación.
•Plan de implementación.
•Cronograma.
•Revisión post-implementación.
•Evaluación final.
•Fecha de cierre.
Aceptación

Tras el registro del RFC se debe evaluar preliminarmente su

pertinencia. Una RFC puede ser simplemente rechazada si se
considera que el cambio no esta justificado o se puede
solicitar su modificación si se considera que algunos aspectos
de la misma son susceptibles de mejora o mayor definición. En
cualquiera de los casos la RFC debe ser devuelta al
departamento o persona que la solicito con el objetivo de que
se puedan realizar nuevas alegaciones a favor de dicha RFC o
para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación
por el CAB (Consejo Asesor del Cambio) y es sólo indicación
de que se ha encontrada justificado su ulterior procesamiento.
3.6. GESTION DE LAS
VERSIONES
3.6. Gestión de las versiones

La Gestión de Versiones es la encargada de la

implementación y control de calidad de todo el
software y hardware instalado en el entorno de
producción.
La Gestión de Versiones debe colaborar
estrechamente con la Gestión de Cambios y de
Configuraciones para asegurar que toda la
información relativa a las nuevas versiones se
integra adecuadamente en la CMDB de forma que
ésta se halle correctamente actualizada y ofrezca
una imagen real de la configuración de la
infraestructura TI.
La Gestión de Versiones también debe mantener
actualizada la Biblioteca de Software Definitivo
(DSL), donde se guardan copias de todo el
software en producción, y el Depósito de
Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentación para la
rápida reparación de problemas de hardware en el
entorno de producción.
Las complejas interrelaciones entre todos los
elementos que componen una infraestructura TI
convierten en tarea delicada la implementación de
cualquier cambio.

La Gestión de Cambios es la encargada de

aprobar y supervisar todo el proceso pero es tarea
específica de la Gestión de Versiones el diseñar,
poner a prueba e instalar en el entorno de
producción los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificación
y coordinación con el resto de procesos asociados
a la Gestión de Servicios TI.
Entre los principales objetivos de la Gestión de
Versiones se incluyen:
•Establecer una política de implementación de nuevas versiones
de hardware y software.
•Implementar las nuevas versiones de software y hardware en el
entorno de producción tras su verificación en un entorno realista
de pruebas.
•Garantizar que el proceso de cambio cumpla las
especificaciones de la RFC correspondiente.
•Asegurar, en colaboración con la Gestión de Cambios y
Configuraciones, que todos los cambios se ven correctamente
reflejados en la CMDB.
•Archivar copias idénticas del software en producción, así como
de toda su documentación asociada, en la Biblioteca de
Software Definitivo (DSL).
•Mantener actualizado el Depósito de Hardware Definitivo
(DHS).
Los beneficios de una correcta Gestión de
Versiones se resumen en:
•El proceso de cambio se realiza sin deterioro de la calidad de
servicio.
•Las nuevas versiones cumplen los objetivos propuestos.
•Se reduce el número de incidentes por incompatibilidades con
otro software o hardware instalado.
•El proceso de pruebas asociado no sólo permite asegurar la
calidad del software y hardware a instalar sino que también
permite conocer la opinión de los usuarios sobre la
funcionalidad y usabilidad de las nuevas versiones.
•El correcto mantenimiento de la DSL impide que se pierdan
(valiosas) copias de los archivos fuente.
•Se reduce el número de copias de software ilegales.
•Control centralizado del software y hardware desplegado.
•Protección contra virus y problemas asociados a versiones de
software incontroladas.
Una versión es un grupo de CIs de nueva creación
o modificados que han sido validados para su
instalación en el entorno de producción. Las
especificaciones funcionales y técnicas de una
versión están determinadas en la RFC
correspondiente.
Las versiones pueden clasificarse, según su
impacto en la infraestructura TI, en:

•Versiones mayores: que representan importantes

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

•Versiones menores: que suelen implicar la corrección de

varios errores conocidos puntuales y que a menudo son
modificaciones que vienen a implementar de una manera
correctamente documentada soluciones de emergencia.

•Versiones de emergencia: modificaciones que reparan

de forma rápida un error conocido.
Como pueden llegar a existir múltiples versiones
es conveniente definir una referencia o código que
los identifique unívocamente.

El sistema universalmente aceptado es:

Versiones mayores: 1.0, 2.0, etc.

Versiones menores: 1.1, 1.2, 1.3, etc.

Versiones de emergencia: 1.1.1, 1.1.2, etc.

En su ciclo de vida una versión puede encontrase
en diversos estados: desarrollo, pruebas,
producción y archivado.
El siguiente diagrama nos ilustra gráficamente la
evolución temporal de una versión:
El despliegue de nuevas versiones puede
realizarse de diferentes maneras y es
responsabilidad de la Gestión de Cambios el
determinar la forma más conveniente de hacerlo.
Entre las opciones más habituales cabe contar:
Versión delta: sólo se testean e instalan los
elementos modificados. Esta opción tiene como
ventaja su mayor simplicidad pero conlleva el
peligro de que puedan aparecer problemas e
incompatibilidades en el entorno de producción.
Versión completa: Se distribuyen todos los
elementos afectados ya hayan sido modificados o
no. Aunque esta opción es obviamente más
trabajosa es más improbable que se generen
incidentes tras la instalación si se han realizado
las pruebas pertinentes.
Paquete de Versiones: La Gestión de Cambios
puede optar por distribuir de forma sincronizada
diferentes paquetes de versiones, de esta forma
se ofrece una mayor estabilidad al entorno TI. En
algunos casos esta opción es obligada por
incompatibilidades entre una nueva versión con
software o hardware previamente instalado.
Pensemos, por ejemplo, en la migración a un
nuevo sistema operativo que requiere hardware
más avanzado y/o nuevos versiones de los
programas ofimáticos.
Las principales actividades de la Gestión de
Versiones se resumen en:

•Establecer una política de planificación para la

implementación de nuevas versiones.
•Desarrollar o adquirir de terceros las nuevas versiones.
•Poner a prueba las nuevas versiones en un entorno que
simule lo mejor posible el entorno de producción.
•Validar las nuevas versiones.
•Implementar las nuevas versiones en el entorno de
producción.
•Llevar a cabo los planes de back-out o retirada de la
nueva versión si esto fuera necesario.
•Actualizar la DSL, el DHS y la CMDB.
•Comunicar y formar a los clientes y usuarios sobre las
funcionalidades de la nueva versión.
La distribución de la nueva versión es también
conocida como rollout.

El rollout puede ser de varios tipos:

Completo y sincronizado: se realiza de manera

integral y simultánea en todos los
emplazamientos.

Fragmentado: ya sea bien espacial o

temporalmente. Por ejemplo, introduciendo la
nueva versión por grupos de trabajo o
incrementando progresivamente la funcionalidad
ofrecida.
Tras la implementación, la Gestión de Versiones
debe ser puntualmente informada por el Service
Desk de los comentarios, quejas, incidentes, etc.
que la nueva versión haya podido suscitar. Toda
esta información deberá ser analizada para
asegurar que las próximas versiones incorporen
las sugerencias recibidas y que se tomen las
medidas correctivas necesarias para minimizar el
impacto negativo que puedan tener futuros
cambios.
3.7. GESTION DE LAS
CONFIGURACIONES
3.7. Gestión de las configuraciones

Las cuatro principales funciones de la Gestión de

Configuraciones pueden resumirse en:

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

2. Proporcionar información precisa sobre la

configuración TI a todos los diferentes
procesos de gestión.
3. 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.

4. 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 en el siguiente
esquema:
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:
1. Registro actualizado de todos los CIs :
identificación, tipo, ubicación, estado,...
2. Interrelación entre los CIs.
3. 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 costos. 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.
Elementos de configuración (CI): 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 (CMDB): 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.
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.