Fundamentos de La Gestión TI

Lic.
Jos Antonio Snchez Montero Data & Tecnologa
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:
Proporcionar una adecuada gestin de la calidad

Aumentar la eficiencia
Alinear los procesos de negocio y la infraestructura TI
Reducir los riesgos asociados a los Servicios TI
Generar negocio
ITIL nace como un cdigo de buenas prcticas dirigidas a alcanzar esas metas mediante:
Un enfoque sistemtico del servicio TI centrado en los procesos y procedimientos

El establecimiento de estrategias para la gestin operativa de la infraestructura TI
1
Lic. Jos Antonio Snchez Montero Data & Tecnologa
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.
3

El siguiente diagrama interactivo resume sucintamente los principales aspectos de la
metodologa de soporte al servicio segn los estndares ITIL:
Provisin del Servicio

La provisin del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de
los Niveles de servicio, su disponibilidad,su continuidad, su viabilidad financiera, la
capacidad necesaria de la infraestructura TI y los niveles de seguridad requeridos
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la
metodologa de provisin del servicio segn los estndares ITIL:
Forum ITSMF
El ITSMF es el nico Forum completamente indpendiente reconocido por el sector de la

Gestin de Servicios Informticos. Esta asociacin, con fines no lucrativos, juega un papel
predominante en el desarrollo y promocin de un cdigo de Mejores Prcticas para la
gestin de estos servicios.
En la actualidad, las empresas dependen cada vez en mayor medida de la tecnologa para la
promocin y distribucin de sus productos en el mercado, por lo que resulta imprescindible
adoptar unos estndares que permitan la correcta gestin de los procesos informticos
asociados.
El objetivo del ITSMF es organizar una red de expertos en Gestin de Servicios
Informticos, ofrecer completa informacin sobre los mismos y organizar seminarios y
conferencias para ayudar a las empresas a resolver los problemas que puedan encontrar en
este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos
servicios gracias a la utilizacin de un cdigo de Mejores Prcticas.
Ms de 1000 compaias, grandes corporaciones y empresas pblicas de todo el mundo
pertenecen al ITSMF. Osiatis es en la actualidad una de las empresa responsables de las
actividades del Forum en Espaa y Francia (Claude Durand, Director de Desarrollo de
Osiatis Francia, es tesorero de la asociacin en ese pas).
10
Certificaciones ITIL
EXIN e ISEB
La fundacin holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa
"Information Systems Examination Board" (ISEB) han desarrollado juntas un sistema de
certificacin profesional para ITIL. Fue realizado en estrecha cooperacin con la OGC y el
itSMF. EXIN e ISEB son organizaciones sin nimo de lucro que cooperan para ofrecer una
amplia gama de certificaciones en tres niveles:
Foundation Certificate en Gestin de Servicios TI

Practitioner Certificate en Gestin de Servicios TI
Manager Certificate en Gestin de Servicios TI
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:
http://www.itil.co.uk -El Sitio Oficial de ITIL

http://www.exin.nl -Organismo de Certificacin
http://www.itsmf.com -Forum Internacional de Gestin de Servicios TI
Gestin de Servicios TI: Caso Prctico

11

Para mejor ilustrar los contenidos de este "curso" cada captulo incluye un caso prctico
relacionado directamente con los contenidos del mismo.
Todos estos casos prcticos se refieren a una compaa (ficticia) dedicada al catering,
"Cater Matters", que ha optado por introducir la metodologa ITIL para la gestin de sus
servicios.
"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que
incluye:
Servicios de comedor de grandes empresas.

Servicios de catering para colegios.
Servicios de catering para eventos (congresos, actos institucionales, ...).
Servicios de restauracin para hoteles.
La logstica del servicio es compleja y los niveles de servicio muy exigentes en lo que
respecta a la calidad y los plazos de entrega.
Para mejorar sus estndares de servicio "Cater Matters" ha implementado un sofisticado
sistema informtico que le permite gestionar de una manera ms gil y eficiente sus
relaciones con los clientes as como sus procesos de produccin y distribucin.
La direccin de "Cater Matters", tras un concienzudo anlisis de la situacin, ha decidido
adoptar la metodologa ITIL como la base de todos sus procesos y servicios. Entre las
decisiones adoptadas consecuentemente caben destacar:
Creacin de un Service Desk o Centro de Servicios que centralice todas las

relaciones con los clientes y el resto de la infraestructura TI.
Organizacin de sus actividades en torno a los procesos.
Designacin de responsables o gestores para cada uno de los procesos crticos.
Establecimiento de estrictos protocolos de monitorizacin de la calidad del servicio.
Centro de servicios (Service Desk)
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:
Registrando y monitorizando incidentes.
12
Aplicando soluciones temporales a errores conocidos en colaboracin con la

Gestin de Problemas.
Colaborando con la Gestin de Configuraciones para asegurar la actualizacin de
las bases de datos correspondientes.
Gestionando cambios solicitados por los clientes mediante peticiones de servicio en
colaboracin con la Gestin de Cambios y Versiones
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
estan recibiendo una atencin personalizada y gil que les ayude a:
Resolver rpidamente las interrupciones del servicio.

Emitir peticiones de servicio.
Informarse sobre el cumplimiento de los SLAs.
Recibir informacin 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 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 Supervisin de los contratos de mantenimiento y niveles de servicio.
o Canalizacin de las Peticiones de Servicio de los clientes.
o Gestin de las licencias de software.
o Centralizacin de todos los procesos asociados a la Gestin TI.
13

Los principales beneficios de una correcta implementcin del Centro de Servicios se
resumen en:
Reduccin de costes mediante una eficiente asignacin de recursos.

Una mejor atencin al cliente que repercute en un mayor grado de satisfaccin y
fidelizacin del mismo.
Apertura de nuevas oportunidades de negocio.
Centralizacin de procesos que mejoran la gestin de la informacin y la
comunicacin.
Soporte al servicio proactivo.
Implementacin
La implementacin de un Service Desk requiere una meticulosa planificacin. En primera
instancia debe establecerse:
Cules son las necesidades.

Cules han de ser sus funciones.
Quines seran los responsables del mismo.
Qu cualificaciones profesionales poseeran sus integrantes.
Si se deben externalizar ciertos servicios, como, por ejemplo, el soporte tcnico del
hardware.
Qu estructura de Service Desk: distribuido, central o virtual, se adapta mejor a
nuestras necesidades y las de nuestros clientes.
Qu herramientas tecnolgicas necesitamos.
Qu mtricas determinarn el rendimiento del Centro de Servicios.
Adems de estas cuestiones de carcter tcnico, es imprescindible ponderar otros aspectos

ms directamente relacionados con el "factor humano" y que son tan importantes o ms que
los puramente tcnicos para el xito del Centro de Servicios:
Establecer estrictos protocolos de interaccin con el cliente.

Motivar al personal encargado de la relacin directa con el cliente.
Informar a los clientes de los beneficios de este nuevo servicio de atencin y
soporte.
Asegurar el compromiso de la direccin con la filosofa del Service Desk.
Sondear a los clientes para conocer mejor sus expectativas y necesidades.
El objetivo NO es implementar lo ms rpidamente posible un Centro de Servicios sino

implantar un Centro de Servicios cuyos objetivos se alineen con nuestros procesos de
negocio, mejoren la satisfaccin de nuestros clientes, optimicen la imagen externa de
14

nuestra organizacin y nos sirva de plataforma para identificar nuevas oportunidades de
negocio.
Estructura
Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto
de toda la organizacin TI con clientes y usuarios, es por lo tanto imprescindible que:
Sea fcilmente accesible.

Ofrezca un servicio de calidad consistente y homogneo.
Mantenga puntualmente informados a los usuarios y lleve un registro de toda la
interaccin con los mismos.
Sirva de soporte al negocio.
Para cumplir estos objetivos es necesario implementar la adecuada estructura fsica y

lgica.
Estructura lgica
Los integrantes del Centro de Servicios deben:
Conocer todos los protocolos de interaccin con el cliente: guiones, checklists,...

Disponer de herramientas de software que les permitan llevar un registro de la interaccin
con los usuarios.
Saber cundo se debe realizar un escalado a instancias superiores o entrar en discusiones
sobre cumplimiento de SLAs.
Tener rpido acceso a las bases de conocimiento para ofrecer un mejor servicio a los
usuarios.
Recibir formacin sobre los productos y servicios de la empresa.
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
Describimos a continuacin sus principales caractersticas:

15

Service Desk Centralizado
En este caso todo el contacto con los usuarios se canaliza a travs de una sola estructura
central.
Sus ventajas principales son:
Se reducen los costes.

Se optimizan los recursos.
Se simplifica la gestin.
Sin embargo surgen importantes inconvenientes cuando:
Los usuarios se encuentran en diversos emplazamientos geogrficos: diferentes idiomas,

productos y servicios.
Se necesita dar servicios de mantenimiento "on-site".
Service Desk Distribuido

Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en
diferentes emplazamientos geogrficos (ya sean ciudades, pases o continentes). Sus
16

ventajas son obvias en estos casos, sin embargo la deslocalizacin de los diferentes Centros
de Servicios conlleva grandes problemas:
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.
Service Desk Virtual

En la actualidad y gracias a las rpidas redes de comunicacin existentes la situacin
geogrfica 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 costes.
Se puede ofrecer un "servicio local" sin incurrir en costes adicionales.
17
La calidad del servicio es homognea y consistente.
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:
18

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:
Registro y monitorizacin de cada incidente.

Comprobacin de que el servicio de soporte requerido se incluye en el SLA asociado.
Seguimiento del proceso de escalado.
Identificacin de problemas.
Cierre del incidente y confirmacin con el cliente.
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.
Relaciones con los proveedores
El Centro de Servicios es asimismo responsable de la relacin con los proveedores de

servicios de mantenimiento externos.
Es imprescindible, para ofrecer un servicio de calidad, una estrecha relacin entre los
responsables externos del mantenimiento y la Gestin de Incidentes que debe ser
canalizada a travs del Service Desk.

19
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:
Compartir la filosofa de atencin al cliente de la organizacin.

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.
La formacin impartida debe referirse a todos estos aspectos y no limitarse a la

capacitacin tecnolgica.
Tambin es imprescindible el compromiso de la direccin con:
Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.

Un continuo apoyo al equipo en la siempre difcil tarea del trato directo con los
clientes.
El trabajo en equipo.
Y, por ltimo, recordar que slo tenemos una oportunidad de ofrecer una buena primera
impresin.
Control del proceso

20

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.
Centro de Servicios
Caso Practico
Como paso imprescindible para la implantacin de la metodologa ITIL en la empresa la
direccin de "Cater Matters" ha decidido implantar un Service Desk que centralice todos
los contactos con clientes, proveedores y la organizacin TI.
Para ello se han adoptado las siguientes decisiones:
Se ha nombrado un gestor responsable del Service Desk.

Se han definido, tras un cuidadoso anlisis de las necesidades de la organizacin y
los usuarios, las funciones principales del mismo:
o Gestionar la primera lnea de soporte de la Gestin de Incidentes.
o Supervisar la calidad del servicio ofrecido respecto a los SLAs.
o Ofrecer informacin de carcter comercial sobre los servicios ofrecidos.
o Realizar encuestas peridicas sobre el grado de satisfaccin del cliente.
o Elaboracin de informes peridicos con la informacin recopilada.
21
Realizar una pequea promocin para presentar los nuevos servicios a los clientes
existentes y potenciales.
Habilitar un espacio web para canalizar, en la medida de los posible, la interaccin
con los usuarios a travs de este medio:
o Formularios de consultas y alta de incidentes.
o Consulta remota, mediante los web services asociados, del estado de los
incidentes activos, histricos de incidencias y cumplimiento de los SLAs.
o FAQs actualizadas que permitan a los usuarios consultar directamente sobre
los servicios prestados, errores conocidos, etc.
Desarrollar un "Manual de Atencin al Cliente" en donde se detalle los diferentes
protocolos de interaccin con los usuarios dependiendo de la situacin en cuestin.
Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de
informacin del Service Desk.
Impartir formacin especfica:
o Al personal encargado del trato directo con usuarios y clientes sobre la
aplicacin del "Manual de Atencin al Cliente".
o Sobre las herramientas de software utilizadas.
Creacin de un detallado plan de implantacin progresiva del Service Desk .
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.
Las propiedades y funcionalidades de la Gestin de Incidentes se resumen sucintamente
en el siguiente interactivo:
22
Los objetivos principales de la Gestin de Incidentes son:
Detectar cualquiera alteracin en los servicios TI.

Registrar y clasificar estas alteraciones.
Asignar el personal encargado de restaurar el servicio segn se define en el SLA
correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de
Servicios (Service Desk) debe jugar una papel esencial en el mismo.
El siguiente diagrama resume el proceso de gestin de incidentes:
23
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento

de los sistemas de hardware y software segn el libro de Soporte del Servicio de ITIL un
incidente es:
Cualquier evento que no forma parte de la operacin estndar de un servicio y que causa,
o puede causar, una interrupcin o una reduccin 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 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:
Mejorar la productividad de los usuarios.

Cumplimiento de los niveles de servicio acordados en el SLA.
Mayor control de los procesos y monitorizacin del servicio.
Optimizacin de los recursos disponibles.
Una CMDB ms precisa pues se registran los incidentes en relacin con los
elementos de configuracin.
Y principalmente: mejora la satisfaccin general de clientes y usuarios.
Por otro lado una incorrecta Gestin de Incidentes puede acarrear efectos adversos tales
como:
Reduccin de los niveles de servicio.

Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado
trabajando concurrentemente en la resolucin del incidente.
24
Se pierde valiosa informacin 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 gestin de sus
incidentes.
Las principales dificultades a la hora de implementar la Gestin 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 operacin de los
protocolos de clasificacin y escalado.
No estn bien definidos los niveles de calidad de servicio ni los productos
soportados. Lo que puede provocar que se procesen peticiones que no se incluan en
los servicios previamente acordados con el cliente.
Clasificacin del Incidente

Es moneda frecuente que existan mltiples incidencias concurrentes por lo que es necesario
determinar un nivel de prioridad para la resolucin de las mismas.
El nivel de prioridad se basa esencialmente en dos parmetros:
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.
25

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:
Escalado funcional: Se requiere el apoyo de un especialista de ms alto nivel para

resolver el problema.
Escalado jerrquico: 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 ms recursos para la resolucin de un incidente especfico.
El proceso de escalado puede resumirse grficamente* como sigue:
26
* El escalado puede incluir ms niveles en grandes organizaciones, o por el contrario ,

integrar diferentes niveles en el caso de PYMES
Proceso
El siguiente diagrama muestra los procesos implicados en la correcta Gestin de
Incidentes:
Nota: los botones del grfico permiten acceder a informacin mas detallada sobre la
interrelacin con otros procesos TI
27
28
29
30
31
32
Registro y Clasificacin de Incidentes

Registro
La admisin y registro del incidente es el primer y necesario paso para una correcta gestin
del mismo.
Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestin de
aplicaciones, el mismo Centro de Servicios o el soporte tcnico, entre otros.
El proceso de registro debe realizarse inmediatamente pues resulta mucho ms costoso
hacerlo posteriormente y se corre el riesgo de que la aparicin de nuevas incidencias
demore indefinidamente el proceso.
La admisin 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.
33
Comprobacin de que ese incidente an no ha sido registrado: es moneda corriente que

ms de un usuario notifique la misma incidencia y por lo tanto han de evitarse
duplicaciones innecesarias.
Asignacin de referencia: al incidente se le asignar una referencia que le identificar
unvocamente 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 informacin bsica
necesaria para el procesamiento del incidente (hora, descripcin del incidente, sistemas
afectados...).
Informacin de apoyo: se incluir cualquier informacin relevante para la resolucin del
incidente que puede ser solicitada al cliente a travs de un formulario especfico, o que
pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.
Notificacin 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.
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.
Anlisis, Resolucin 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 resolucin del incidente se escapa de las posibilidades del Centro de Servicios ste
redirecciona el mismo a un nivel superior para su investigacin por los expertos asignados.
Si estos expertos no son capaces de resolver el incidente se seguirn los protocolos de
escalado predeterminados.
34

Durante todo el ciclo de vida del incidente se debe actualizar la informacin almacenada en
las correspondientes bases de datos para que los agentes implicados dispongan de cumplida
informacin sobre el estado del mismo.
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 haya solucionado el incidente se:
Confirma con los usuarios la solucin satisfactoria del mismo.

Incorpora el proceso de resolucin a la KB.
Reclasifica el incidente si fuera necesario.
Actualiza la informacin en la CMDB sobre los elementos de configuracin (CI)
implicados en el incidente.
Cierra el incidente.
Control del Proceso

La correcta elaboracin de informes forma parte esencial en el proceso de Gestin de
Incidentes.
Estos informes deben aportar informacin esencial para, por ejemplo:
La Gestin de Niveles de Servicio: es esencial que los clientes dispongan de

informacin 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
satisfaccin del cliente por el servicio prestado y supervisar el correcto
funcionamiento de la primera lnea de soporte y atencin al cliente.
Optimizar la asignacin de recursos: los gestores deben conocer si el proceso de
escalado ha sido fiel a los protocolos preestablecidos y si se han evitado
duplicidades en el proceso de gestin.
Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la
estructura de la organizacin o las necesidades del cliente por lo que se deban tomar
medidas correctivas.
Disponer de Informacin Estadstica: que puede ser utilizada para hacer
proyecciones futuras sobre asignacin de recursos, costes asociados al servicio, etc.
Por otro lado una correcta Gestin de Incidentes requiere de una infraestructura que
facilite su correcta implementacin. Entre ellos cabe destacar:
35
Un correcto sistema automatizado de registro de incidentes y relacin con los

clientes
Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con
incidentes ya registrados y resueltos. Una (KB) actualizada permite:
o Evitar escalados innecesarios.
o Convertir el know how de los tcnicos en un activo duradero de la
empresa.
o Poner directamente a disposicin 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 resolucin del incidente.
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:
Nmero de incidentes clasificados temporalmente y por prioridades.

Tiempos de resolucin clasificados en funcin del impacto y la urgencia de los
incidentes.
Nivel de cumplimiento del SLA.
Costes asociados.
Uso de los recursos disponibles en el Centro de Servicios.
Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia
por el Centro de Servicios.
Grado de satisfaccin del cliente.
Caso Prctico
El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros
del comedor de uno de sus clientes.
Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados
hace unos das a travs de la web sta an no se ha recibido y apenas quedan reservas en
sus frigorficos
El operador del Service Desk busca en la base de datos de pedidos y confirma que se
realizo el pedido hace varios das pero tambin observa que ste se ha guardado
defectuosamente.
El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.
36

El operador toma, basndose en los protocolos establecidos, las siguientes decisiones:
Evala la prioridad: aunque el impacto es bajo, el incidente es urgente pues el

cliente necesita rpidamente el suministro.
Registra los datos del incidente.
Consulta la Base de Conocimiento para investigar si el incidente es consecuencia
de un error conocido y cuales son las posibles soluciones temporales
Propone una solucin temporal al cliente: indica una zona reservada de la web
desde la que se pueden realizar pedidos "urgentes" va email.
Contacta con el departamento de sistemas previendo que el incidente pueda
repetirse a lo largo de la maana.
Consulta, mediante la aplicacin que monitoriza las existencias de almacn, la
disponibilidad de los helados solicitados.
Tranquiliza al cliente asegurndole que mediante su servicio express recibir los
helados solicitados antes del medioda.
Por otro lado el departamento de sistemas:
Realiza una serie de pruebas y comprueba que, de manera general, el sistema

funciona correctamente.
No consigue identificar la causa del incidente.
Contacta con el Service Desk y propone que se eleve el problema a la Gestin de
Problemas pero pre-calificando su prioridad como baja.
El Service Desk recibe la informacin y determina que:
Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al

cliente una solucin temporal satisfactoria no se requiere un escalado superior.
Registra la solucin temporal del incidente junto a la informacin proporcionada
por el departamento de sistemas.
Da por cerrado el incidente.
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.
37

La Gestin 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 configuracin con el
objetivo de prevenir incidentes incluso antes de que estos ocurran.
Las interacciones y funcionalidades de la Gestin de Problemas se resumen sucintamente

en el siguiente interactivo:
38
39
40
41
42
Gestin de Problemas
Como se explic 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:
43
44
45
Entre la funciones principales de la Gestin de Problemas figuran:
Identificar, registrar y clasificar los problemas.

Dar soporte a la Gestin de Incidentes proporcionando informacin y soluciones
temporales o parches.
Analizar y determinar las causas de los problemas y proponer soluciones.
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.
46

Los principales beneficios de una correcta Gestin de Problemas:
Un aumento de la calidad general de los servicios TI.

Se minimiza el nmero de incidentes.
Los incidentes se solucionan ms rpidamente y, generalmente, en la primera lnea
de soporte TI ahorrando recursos e innecesarios escalados.
La documentacin desarrollada es de gran utilidad para la Gestin de la
Capacidad, Disponibilidad y Niveles de Servicio.
Las principales dificultades a la hora de implementar la Gestin de Problemas se resumen

en:
Establecer una estrecha colaboracin entre la Gestin de Incidentes y la de

Problemas. Sin sta la Gestin de Incidentes no dispondr de toda la informacin
necesaria para la rpida solucin de los incidentes y la Gestin de Problemas
carecer de la informacin necesaria para determinar, clasificar y resolver los
problemas.
Mantener actualizadas las bases de datos asociadas requiere un compromiso por
parte de todos los agentes implicados que frecuentemente requiere un seguimiento
cercano de los responsables de la infraestructura TI.
Aumento de los costes por la contratacin de personal especializado, aunque estos
se vean sobradamente compensados por los beneficios derivados.
Gestin de Problemas
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.
Problemas:
47

interrelacin con otros procesos TI
48
49
50
51
52
Gestin de Problemas
Proceso - Control de Problemas

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en
Errores Conocidos para que el Control de Errores pueda proponer las soluciones
correspondientes.
53
El Control de Problemas se compone en esencia de tres fases:

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:
Los CIs implicados.

54
Causas del problema.

Sntomas asociados.
Soluciones temporales.
Servicios involucrados.
Niveles de prioridad, urgencia e impacto.
Estado: activo, error conocido, cerrado.
2. Clasificacin y Asignacin de Recursos
La clasificacin del problema engloba desde las caractersticas 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 configuracin (CIs) involucrados en el mismo.
Un factor esencial es la determinacin 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
solucin del problema) como de su impacto (grado de deterioro de la calidad del servicio).
Al igual que en la Gestin de Incidentes la prioridad puede cambiar en el curso del ciclo
de vida del problema, por ejemplo, si se encuentra una solucin temporal al mismo que
reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios
para su solucin. Estos recursos deben ser suficientes para asegurar que los problemas
asociados son tratados eficazmente y as minimizar su impacto en la infraestructura TI.
3. Anlisis y Diagnstico: Error conocido
Los objetivos principales del proceso de anlisis son:
Determinar las causas del problema.

Proporcionar soluciones temporales a la Gestin 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 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.
55

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.
Gestin de Problemas
Proceso - Control de Errores

Una vez que el Control de Problemas ha determinado las causas de un problema es
responsabilidad del Control de Errores el registro del mismo como error conocido.
Identificacin y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestin de Incidentes

pues debe llevar asociado, siempre que esto sea posible, algn tipo de solucin temporal
que permita minimizar el impacto de los incidentes asociados.
Anlisis y Solucin
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
El posible impacto de las mismas en la infraestructura TI.

Los costes asociados.
Sus consecuencias sobre los SLAs.
56

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 conveniente demorar la solucin? Ya sea porque se prevn cambios significativos en la

infraestructura TI a corto plazo o por el escaso impacto del problema en cuestin.
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.
Revisin Post Implementacin y Cierre
Antes de dar el problema por resuelto y cambiar su estado a cerrado se debe analizar el
resultado de la implementacin de la RFC elevado a la Gestin 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.
Gestin de Problemas
Control del Proceso

El objetivo de la Gestin de Problemas no es otro que el de mejorar el funcionamiento de
la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo
seguimiento de los procesos relacionados y evaluar su rendimiento.
En particular una buena gestin de problemas debe traducirse en una:
Disminucin del nmero de incidentes y una ms rpida resolucin de los mismos.

Mayor eficacia en la resolucin de problemas.
Gestin proactiva que permita identificar problemas potenciales antes de que estos
se manifiesten o provoquen una seria degradacin de la calidad del servicio.
La correcta elaboracin de informes permite evaluar el rendimiento de la Gestin de

Problemas y aporta informacin de vital importancia a otras reas de la infraestructura TI.
57

Entre la documentacin generada cabra destacar:
Informes de Rendimiento de la Gestin de Problemas: donde se detalle el

nmero de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de
respuesta y el impacto en la Gestin de Incidentes.
Informes de Gestin Proactiva: donde se especifiquen las acciones ejercidas para
la prevencin de nuevos problemas y los resultados de los anlisis realizados sobre
la adecuacin de las estructuras TI a las necesidades de la empresa.
Informes de Calidad de Productos y Servicios: donde se evale el impacto en la
calidad del servicio de los productos y servicios contratados y que eventualmente
puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.
Una eficaz 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 Problemas
Caso Prctico
El Service Desk de "Cater Matters" ha informado a la Gestin de Problemas sobre una
incidencia a la que no se le pudo asociar un error conocido y que causo una interrupcin
de bajo impacto en el servicio.
La Gestin de Problemas decide analizar el problema utilizando el protocolo establecido,
que en este caso sigue el modelo de Kepner y Tregoe:
Identificacin del problema.

Clasificacin del problema.
Establecimiento de las posibles causas.
Comprobacin de la causa ms probable.
Verificacin de la causa verdadera.
Identificacin: En nuestro caso el problema es sencillo de definir:
La aplicacin de pedidos online muestra, de forma no previsible, errores en el

registro de ciertos pedidos, sin que este error parezca tener correlacin con otros
componentes de hardware / software.
Clasificacin: La clasificacin se adaptara a los siguientes parmetros:
Identificacin: Problemas en el registro de pedidos.

58
Origen: Mdulo de pedidos online.

Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
Impacto: leve. El incidente ha sido resuelto sin una interrupcin grave del servicio.
Posibles causas: Entre las causas ms probables figuran:
Errores en la programacin del lado cliente de la aplicacin.

Errores en los mdulos de registro del servidor web.
Errores de configuracin de la base de datos.
Los analistas deciden que el origen ms probable del problema est en los mdulos de
registro de la aplicacin.
Comprobacin de la causa ms probable: con la ayuda de la informacin registrada por
la Gestin de Incidentes:
Se intenta reproducir el problema.

Se comprueba que el error slo se reproduce con una determinada marca de helados.
Se comprueba que dicha marca de helados tiene un apstrofe en el nombre y que
eliminado ste se registra el pedido sin problemas.
Verificacin:
Se crea un entorno de pruebas que reproduce el mdulo de inters en el entorno de

produccin.
Se introducen las modificaciones necesarias en la programacin.
Se comprueba el correcto registro del pedido.
El problema se ha convertido en un error conocido, es ahora tarea del Control de

Errores:
Elevar una RFC con la solucin propuesta.

Llevar a cabo la revisin post-implementacin en el caso de que la Gestin de
Cambios considere oportuno implementar la RFC.
Gestin de Configuraciones
Visin General
Las cuatro principales funciones de la Gestin de Configuraciones pueden resumirse en:
Llevar el control de todos los elementos de configuracin de la infraestructura TI

con el adecuado nivel de detalle y gestionar dicha informacin a travs de la Base
de Datos de Configuracin (CMDB).
59
Proporcionar informacin precisa sobre la configuracin TI a todos los diferentes

procesos de gestin.
Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de
manera que estas puedan resolver ms eficientemente las incidencias, encontrar
rpidamente la causa de los problemas, realizar los cambios necesarios para su
resolucin y mantener actualizada en todo momento la CMDB.
Monitorizar peridicamente la configuracin de los sistemas en el entorno de
produccin y contrastarla con la almacenada en la CMDB para subsanar
discrepancias.
Las interacciones y funcionalidades de la Gestin de Configuraciones se resumen

sucintamente en el siguiente interactivo:
60
61
62
Es evidente que no se puede gestionar correctamente lo que se desconoce.
63

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.
Los beneficios de una correcta Gestin de Configuraciones incluyen, entre otros:
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:
Una incorrecta planificacin: es esencial programar correctamente las actividades

necesarias para evitar duplicaciones o incorrecciones.
64
Estructura inadecuada de la CMDB: mantener actualizada una base de datos de

configuraciones excesivamente detallada y completa puede ser una tarea engorrosa
y que consuma demasiados recursos.
Herramientas inadecuadas: es necesario disponer del software adecuado para
agilizar los procesos de registro y sacar el mximo provecho de la CMDB.
Falta de Coordinacin con la Gestin de Cambios y Versiones que imposibilita
el correcto mantenimiento de la CMDB.
Falta de organizacin: es importante que haya una correcta asignacin de recursos
y responsabilidades. Es preferible, cuando sea posible, que la Gestin de
Configuraciones sea llevada a cabo por personal independiente y especializado.
Falta de compromiso: los beneficios de la Gestin de Configuraciones no son
inmediatos y son casi siempre indirectos, lo que puede provocar el desinters de la
gestin de la empresa y consecuentemente de los agentes implicados.
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: todos, tanto los componentes de los servicios TI como los
servicios que stos 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.
Base de Datos de la Gestin de Configuraciones: esta base de datos debe incluir:
Informacin detallada de cada elemento de configuracin.

Interrelaciones entre los diferentes elemento de configuracin, como, por ejemplo,
relaciones "padre-hijo" o interdependencias tanto lgicas como fsicas
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.
65
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.
interrelacin con otros procesos TI.
66
67
68
69
70
71
72
73
74
75
76
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:
Designar un responsable: una descentralizacin excesiva puede generar

descoordinacin y llevar al traste todo el proceso.
Invertir en alguna herramienta de software adecuada a las actividades
requeridas: una organizacin manual es impracticable.
Realizar un cuidadoso anlisis de los recursos ya existentes: gestin de stocks,
activos, etc.
Establecer claramente:
o El alcance y objetivos.
77

El nivel de detalle
El proceso de implementacin: orden de importancia, cronograma, ...
Coordinar el proceso estrechamente con la Gestin de Cambios, Gestin de
Versiones y los Departamentos de Compras y Suministros
o
o
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.
Nivel de detalle y Profundidad
Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel de

detalle y profundidad deseados:
Determinar los atributos que describen a un determinado CI.

Tipo de relaciones lgicas y fsicas registradas entre los diferentes CIs.
Subcomponentes registrados independientemente.
78

Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:
Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario,

estado, coste, etc.
Relaciones: conexin en red, impresoras conectadas, etc.
Profundidad: tarjetas de red, discos duros, tarjetas grficas, etc.
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
79
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:
Asegurar que todos los componentes estn registrados en la CMDB.

Monitorizar el estado de todos los componentes.
Actualizar las interrelaciones entre los CIs.
80
Informar sobre el estado de las licencias.
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:
Tras la implementacin de una nueva CMDB.

Antes y despus de cambios mayores en la infraestructura.
Si existen fundadas sospechas de que la informacin almacenada en la CMDB es
incorrecta o incompleta.
Las auditoras deben dedicar especial atencin a aspectos tales como:
Uso correcto de la nomenclatura en los registros de los CIs.

Comunicacin con la Gestin de Cambios: informacin sobre RFCs , cambios
realizados, ...
Estado de los CIs actualizado.
Cumplimiento de los niveles de alcance y detalle predeterminados.
Adecuacin de la estructura de la CMDB con la de la estructura TI real.
Control del Proceso

Una correcta Gestin de Configuraciones necesita la colaboracin de toda la estructura TI
para mantener actualizada la informacin almacenada en la CMDB.
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestin de
Configuraciones, tanto para conocer la estructura y adecuacin de la CMDB como para
aportar informacin de vital importancia a otras reas de la infraestructura TI.
81
Alcance y nivel de detalle de la CMDB.

Desviaciones entre la informacin almacenada en la CMDB y la obtenida de las
auditorias de configuracin.
Informacin sobre CIs que han estado involucrados en incidentes.
Costes asociados al proceso.
Sistemas de clasificacin y nomenclatura utilizados.
Informes sobre configuraciones no autorizadas y/o sin licencias.
Calidad del proceso de registro y clasificacin.
Informacin estadstica y composicin de la estructura TI.
En pequeas organizaciones es a veces conveniente combinar la Gestin de

Configuraciones y Cambios para simplificar el proceso de control. La coordinacin entre
ambos procesos es un factor crtico para el xito y sta unificacin puede resultar
beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total
separacin de estos procesos.
Caso Prctico
La gestin de Configuraciones, aunque de vital importancia, puede convertirse fcilmente
en una "gran devoradora de recursos" si se establecen criterios excesivamente ambiciosos.
Por ello la direccin de "Cater Matters" ha decidido, en una primera fase, limitar el alcance
de la base de datos de configuraciones a los sistemas considerados crticos:
Servidores de red local.

Servidores de Internet.
Infraestructura informtica del Centro de Servicios.
SLAs
Para simplificar an ms la gestin se ha decido uniformizar las configuraciones en una

serie de "configuraciones de referencia" aplicables a los CIs arriba descritos.
Aunque esto ha supuesto una inversin inicial importante se ha considerado que sus
ventajas eran obvias:
Reduccin a medio/largo plazo de los costes asociados.

Mejora y consistencia de los servicios prestados.
Simplificacin de todos los procesos asociados al soporte al servicio: Incidencias,
Problemas, Cambios, Versiones, etc.
El haber optado por una serie de configuraciones estndar permite alcanzar un gran nivel de
detalle sin necesidad de realizar un esfuerzo desmedido por lo que se han registrado:
82
Configuraciones de software:
o Sistemas operativos.
o Aplicaciones instaladas.
o Interdependencias: relaciones padre-hijo, propietarios,...
o Documentacin asociada.
Configuraciones de hardware:
o Servidores y estaciones de trabajo.
o Subcomponentes
con sus interrelaciones: relaciones
interdependencias,...
o Documentacin y controladores asociados.
SLAs e informes de seguimiento asociados.
padre-hijo,
A su vez se han instalado herramientas de gestin que permiten la monitorizacin remota

de todas esas configuraciones y la realizacin de auditoras peridicas automatizadas.
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:
Solucin de errores conocidos.

Desarrollo de nuevos servicios.
Mejora de los servicios existentes.
Imperativo legal.
El principal objetivo de la Gestin de Cambios es la evaluacin y planificacin del

proceso de cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms
eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la
calidad y continuidad del servicio TI.
Las interacciones y funcionalidades de la Gestin de Cambios se resumen sucintamente en
el siguiente interactivo:
83
84
85
86
Gestin de Cambios
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.
Las actividades principales de la Gestin de Cambios se resumen sucintamente en el

siguiente diagrama:
87
Los principales beneficios derivados de una correcta gestin del cambio son:
Se reduce el nmero de incidentes y problemas potencialmente asociados a todo

cambio.
Se puede retornar a configuraciones estables de manera sencilla y rpida en caso de
que el cambio tenga un impacto negativo en la estructura TI.
Se reduce el nmero de "back-outs" necesarios.
Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
Se evalan los verdaderos costes asociados al cambio y por lo tanto es ms sencillo
valorar el retorno real a la inversin.
La CMDB est correctamente actualizada, algo imprescindible para la correcta
gestin del resto de procesos TI.
88
Se desarrollan procedimientos de cambio estndar que permiten la rpida

actualizacin de sistemas no crticos.
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.
Gestin de Cambios
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.
89
Alcance de la Gestin de Cambios
En principio, todo cambio no estndar debe considerarse tarea de la Gestin de Cambios.

Sin embargo es a veces impracticable gestionar todos los cambios mediante sta.
El alcance de la Gestin de Cambios debe ir en paralelo con el de la Gestin de
Configuraciones: todos los cambios de CIs inventariados en la CMDB deben ser
correctamente supervisados y registrados.
Al igual que a la hora de implementar la Gestin de Configuraciones se sugiri como
medida simplificadora la creacin de "configuraciones de referencia" o paquetes de
hardware y software estndar (por ejemplo, un PC de referencia con todas sus componentes
de hardware y software predefinidas), es importante crear procesos de cambio cuyos
protocolos estn previamente definidos y autorizados para, por ejemplo, realizar los
cambios asociados a las configuraciones de referencia antes citadas.
Estos protocolos de cambio estndar deben ser cuidadosamente elaborados pero una vez
definidos permiten una gestin ms rpida y eficiente de cambios menores o de bajo
impacto en la organizacin TI.
90

Gestin de Cambios
Proceso
Las principales actividades de la Gestin 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
aprobacin de las RFCs y la elaboracin del FSC.
Coordinar el desarrollo e implementacin del cambio.
Evaluar los resultados del cambio y proceder a su cierre en caso de xito.
91
92
93
94
95
96
97
98
Gestin de Cambios
Registro
El primer paso del proceso de cambio es registrar adecuadamente las RFCs.
El origen de una RFC puede ser de muy distinta ndole:
Gestin de Problemas: se encarga de proponer soluciones a errores conocidos. En

la mayora de los casos esta solucin acarrea un cambio en la infraestructura TI. En
este caso el RFC debe ser registrado con informacin del error conocido asociado
para que posteriormente pueda ser evaluada correctamente la pertinencia del
proceso.
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.
Estrategia empresarial: la direccin puede decidir una redireccin estratgica que
puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantacin de
99
un nuevo CRM, etc. y que por regla general requieren de cambios de hardware,
software y/o procedimientos.
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 actualizacin.
Imperativo legal: un cambio de legislacin (como, por ejemplo, la LOPD) 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.
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.
o Estimacin de recursos necesarios para la implementacin.
o Tiempo estimado.
Estatus: que inicialmente ser el de "registrado".
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:
Estatus actualizado: "aceptado", "rechazado", "implementado", ...

Fecha de aceptacin (denegacin) del RFC.
Evaluacin preliminar de la Gestin del Cambio.
Prioridad y categora.
Planes de "back out".
Recursos asignados.
Fecha de implementacin.
Plan de implementacin.
Cronograma.
Revisin post-implementacin.
Evaluacin final.
100
Fecha de cierre.
Gestin de Cambios
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.
101

La determinacin de la categora se basa en el impacto sobre la organizacin y el esfuerzo
requerido para su implementacin. El abanico de posibilidades incluye desde cambios que
apenas requieren la participacin del personal TI y que apenas modifican la calidad del
servicio hasta cambios que necesiten grandes recursos y requieran de la aprobacin directa
de la Direccin.
Los cambios menores pueden no necesitar la aprobacin del CAB y ser implementados
directamente. Cualquier otro cambio habr de ser discutido en el CAB y se habr de
solicitar la colaboracin de personal especializado para realizar tareas de asesoramiento.
Gestin de Cambios
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:
Cules son los beneficios esperados del cambio propuesto?

Justifican esos beneficios los costes asociados al proceso de cambio?
Cules son los riesgos asociados?
Disponemos de los recursos necesarios para llevar a cabo el cambio con garantas
de xito?
Puede demorarse el cambio?
Cul ser el impacto general sobre la infraestructura y la calidad de los servicios
TI?
Puede el cambio afectar los niveles establecidos de seguridad TI?
En el caso de cambios que tengan un alto impacto debe 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
102

de un "paquete de cambios" que formalmente equivaldran a un solo cambio. Esto tiene
algunas ventajas:
Se optimizan los recursos necesarios.

Se evitan posibles incompatibilidades entre diferentes cambios.
Slo se necesita un plan de back-out.
Se simplifica el proceso de actualizacin de la CMDB y la revisin postimplementacin.
Gestin de Cambios
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:
Tanto el software desarrollado como el hardware adquirido se ajustan a las

especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignacin de recursos es la adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de produccin.
Los planes de "back-out" permitirn la rpida recuperacin de la ltima
configuracin estable.
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:
Escuchando sus sugerencias.

Comunicando las ventajas asociadas.
103
Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepcin de
mejora debe ser compartida por usuarios y clientes.
Gestin de Cambios
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.
Los aspectos fundamentales a tener en cuenta son:
Se cumplieron los objetivos previstos?

En que medida se aparto el proceso de las previsiones realizadas por la Gestin de
Cambios.
Provoc el cambio problemas o interrupciones del servicio imprevistas?
Cul ha sido la percepcin de los usuarios respecto al cambio?
Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?Por
qu?
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.
Gestin de Cambios
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:
La reunin urgente del CAB y/o EC si esto fuera posible.
104
Una decisin del Gestor del Cambio si es imposible demorar la resolucin del
problema o ste sucede durante un fin de semana o periodo vacacional (lo que
puede dificultar la reunin del EC).
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.
Gestin de Cambios
Control del Proceso

Cambios.
Para que estos informes ofrezcan una informacin precisa y de sencilla evaluacin es
imprescindible elaborar mtricas de referencia que cubran aspectos tales como:
RFCs solicitados.
Porcentaje de RFCs aceptados y aprobados.
Nmero de cambios realizados clasificados por impacto y prioridad y filtrados
temporalmente.
Tiempo medio del cambio dependiendo del impacto y la prioridad
Nmero de cambios de emergencia realizados.
Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
Numero de back-outs con una detallada explicacin de los mismos.
Evaluaciones post-implementacin.
Porcentajes de cambios cerrados sin incidencias ulteriores.
Incidencias asociadas a cambios realizados.
Nmero de reuniones del CAB con informacin estadstica asociada: nmero de
asistentes, duracin, n de cambios aprobados por reunin, etc.
Gestin de Cambios
Caso Prctico
Los clientes y proveedores de "Cater Matters" estn utilizando cada vez ms los servicios
online de la empresa para gestionar tanto los pedidos como la cadena de suministro.
105

El sistema implantado en la actualidad, aunque cumple bsicamente con los objetivos de
negocio, no estaba diseado para soportar un nivel de actividad elevado. Tanto la Gestin
de Disponibilidad como la Gestin de la Capacidad han informado de deficiencias en el
proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
Por otro lado, la direccin de la empresa ha decidido reforzar su presencia online y ofrecer
a sus clientes unos ms elevados niveles de servicio para incrementar su cuota de mercado.
Todo ello requiere un cambio sustancial en la estructura de software y hardware de los
servicios de Internet y su interconexin con el software de gestin interna de la
organizacin (ERP).
Por todo ello ha sido la propia direccin de la empresa la que ha elevado una RFC a la
Gestin de Cambios que tiene por objetivos:
Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y

capacidad de respuesta.
Desarrollar una serie de WebServices que permitan:
o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Redisear el website para mejorar su usabilidad y optimizarlo para su indexacin en
buscadores.
Tras registrar adecuadamente la RFC:
Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad

normal y un alto impacto.
Se convoca una reunin del CAB para la cual se solicita la asistencia de los
responsables de e-commerce y programacin web.
Se solicita una evaluacin preliminar del proyecto a una consultora externa que
supervis todo el proceso de implementacin del sistema actual.
Previamente a la reunin del CAB el Gestor del Cambio elabora, en estrecha colaboracin
con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de
Servicio, as como con la direccin y Gestin de Proyectos:
Una evaluacin inicial de costes y recursos necesarios.

Una valoracin del impacto de los cambios en la infraestructura TI.
Un cronograma preliminar del proceso.
Una encuesta para que el Service Desk sondee la opinin de los clientes respecto a
los posibles cambios.
Sopesando la documentacin aportada y la estrategia de negocio de la organizacin el CAB

aprueba el cambio y:
106
Determina el calendario definitivo del cambio.

Asigna los recursos, internos y externos, necesarios.
Desarrolla un plan que permita la convivencia temporal de ambos sistemas online
para asegurar la continuidad del servicio:
o Duplicacin de toda la estructura web: se compraran nuevos servidores para
que los antiguos puedan prestar servicio permanentemente y estn
dispuestos inmediatamente para el "back-out".
o Se desarrollarn aplicaciones de "traduccin" que permitan mantener
actualizadas las bases de datos antiguas para evitar la perdida de datos en
caso de "back-out".
Informa a la Gestin de Configuraciones sobre todos los CIs afectados por el
cambio.
Solicita la colaboracin de la misma consultora que implanto el sistema actual para
que realice una auditoria externa de todo el proceso.
Elabora toda la informacin necesaria para que la Gestin de Versiones comience
todo el proceso de pruebas e implementacin.
Tras la implementacin del cambio y en colaboracin con el "Soporte al Servicio" y la

"Provisin del Servicio" la Gestin de Cambios:
Confirma el xito del cambio:

o El nuevo sistema dispone de la capacidad suficiente para proporcionar los
niveles de servicio y disponibilidad previstos.
o El nuevo sistema funciona sin errores aparentes.
o Los clientes y proveedores han percibido el cambio como una mejora en la
prestacin de servicios.
o Ha mejorado la productividad.
Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.
Evala el proceso.
Da por cerrado el cambio.
107
108
109
Gestin de Versiones
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:
Establecer una poltica de implementacin de nuevas versiones de hardware y

software.
Implementar las nuevas versiones de software y hardware en el entorno de
produccin tras su verificacin en un entorno realista de pruebas.
110
Garantizar que el proceso de cambio cumpla las especificaciones de la RFC

correspondiente.
Asegurar, en colaboracin con la Gestin de Cambios y Configuraciones, que
todos los cambios se ven correctamente reflejados en la CMDB.
Archivar copias idnticas del software en produccin, as como de toda su
documentacin asociada, en la Biblioteca de Software Definitivo (DSL).
Mantener actualizado el Depsito de Hardware Definitivo (DHS).
Los beneficios de una correcta Gestin 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 nmero de incidentes por incompatibilidades con otro software o
hardware instalado.
El proceso de pruebas asociado no slo permite asegurar la calidad del software y
hardware a instalar sino que tambin permite conocer la opinin 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 nmero de copias de software ilegales.
Control centralizado del software y hardware desplegado.
Proteccin contra virus y problemas asociados a versiones de software
incontroladas.
Las principales dificultades con las que topa la Gestin de Versiones son:
No existe una clara asignacin de responsabilidades y/o la organizacin TI no

acepta la figura dominante de la Gestin de Versiones en todo el proceso de
implementacin del cambio.
No se dispone de un entorno de pruebas adecuado en donde se puedan testear de
forma realista las nuevas versiones de software y hardware.
Hay resistencia en los diferentes departamentos a la centralizacin del proceso de
cambio. Es habitual que existan reticencias a adoptar sistemas estandarizados en
toda la organizacin, sobre todo cuando sta no ha sido la poltica tradicional de la
misma.
Se realizan cambios sin tener en cuenta a la Gestin de Versiones argumentado que
estos slo son responsabilidad de un determinado grupo de trabajo o que su
"urgencia" requera de ello.
Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de
produccin pueden elegir "ignorar" lo problemas que una nueva versin puede
provocar en otras reas y resistirse a volver a la ltima versin estable.
La implementacin sincronizada de versiones en entornos altamente distribuidos.
La solucin a estos problemas pasa por:
111
Un firme compromiso de la organizacin con la Gestin de Versiones y sus

responsables.
Un adecuado plan de comunicacin que informe a todos los responsables y usuarios
de la organizacin TI de las ventajas de una correcta gestin de todo el proceso de
cambio.
Gestin de Versiones
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:
Versiones mayores: que representan importantes despliegues de software y hardware y

que introducen modificaciones importantes en la funcionalidad, caractersticas tcnicas,
etc.
Versiones menores: que suelen implicar la correccin 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 rpida un error conocido.
Como pueden llegar a existir mltiples versiones es conveniente definir una referencia o
cdigo que los identifique unvocamente. 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
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:
112
El despliegue de nuevas versiones puede realizarse de diferentes maneras y es

responsabilidad de la Gestin de Cambios el determinar la forma ms conveniente de
hacerlo. Entre las opciones ms habituales cabe contar:
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 backout.
La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen backup peridicos.
113

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).
Gestin de Versiones
Proceso
Las principales actividades de la Gestin de Versiones se resumen en:
Establecer una poltica de planificacin para la implementacin 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
Validar las nuevas versiones.
Implementar las nuevas versiones en el entorno de produccin.
Llevar a cabo los planes de back-out o retirada de la nueva versin 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
versin.

Versiones:
114
115
116
117
118
119
Gestin de Versiones
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.
Qu CIs se vern directa o indirectamente implicados durante y tras el lanzamiento
de la nueva versin.
Cmo ha de construirse el entorno de pruebas para que ste sea fiel reflejo del
Qu planes de back-out son necesarios.
Cmo y cundo se deben implementar los planes de back-out para minimizar el
posible impacto negativo sobre el servicio y la integridad del sistema TI.
120
Cules son los recursos humanos y tcnicos necesarios para llevar a cabo la
implementacin de la nueva versin con garantas de xito.
Quines sern los responsables directos en las diferentes etapas del proceso
Qu planes de comunicacin y/o formacin deben desarrollarse para que los
usuarios estn puntualmente informados y puedan percibir la nueva versin como
una mejora.
Qu tipo de despliegue es el ms adecuado: completo, delta, sincronizado en todas
los emplazamientos, gradual, ...
Cul es la vida media til esperada de la nueva versin.
Qu impacto puede tener el proceso de lanzamiento de la nueva versin en la
calidad del servicio.
Si es posible establecer mtricas precisas que determinen el grado de xito del
lanzamiento de la nueva versin.
Gestin de Versiones
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:
Back-up automtico de datos.

Actualizaciones necesarias de las Bases de Datos asociadas.
Instalacin de las nuevas versiones en diferentes sistemas o emplazamientos
geogrficos.
Creacin de logs asociados al proceso de instalacin.
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.
Gestin de Versiones
121
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:
Pruebas del correcto funcionamiento de la versin en un entorno realista.

Pruebas de los procedimientos automticos o manuales de instalacin.
Listas de "bugs" o errores detectados, si se diera el caso.
Pruebas de los planes de back-out.
Documentacin para usuarios y personal de servicio.
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.
Gestin de Versiones
Implementacin
Llego el momento de la verdad: la distribucin de la nueva versin, tambin conocida como
rollout.
El rollout puede ser de varios tipos:
Completo y sincronizado: se realiza de manera integral y simultnea en todos los

emplazamientos.
Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la
nueva versin por grupos de trabajo o incrementando progresivamente la
funcionalidad ofrecida.
122

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 distribucin la Gestin de Versiones debe asegurarse de que:
Se incluya una copia de la versin en la DSL.

El DHS incorpore repuestos funcionales de los nuevos CIs.
La CMDB est correctamente actualizada.
Los usuarios estn debidamente informados de las nuevas funcionalidades y han
recibido la formacin necesaria para poder sacar el adecuado provecho de las
mismas.
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.
Gestin de Versiones
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:
123
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.
Gestin de Versiones
Control del Proceso

Versiones.
Para que estos informes ofrezcan una informacin precisa y de sencilla evaluacin es
necesario elaborar mtricas de referencia que cubran aspectos tales como:
Nmero de lanzamientos de nuevas versiones.

Nmero de back-outs y razones de los mismos.
Incidencias asociadas a nuevas versiones.
Cumplimientos de los plazos previstos para cada despliegue.
Asignacin de recursos en cada caso.
Correccin y alcance de la CMDB y la DHS.
Existencia de versiones ilegales de software.
Adecuado registro de las nuevas versiones en la CMDB.
Incidencias provocadas por uso incorrecto (formacin inadecuada) de la nueva
versin por parte de los usuarios.
Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva
versin.
Gestin de Versiones
Caso Prctico
124

La Gestin de Cambios ha aprobado (vase el caso prctico del captulo anterior) un RFC
que tiene como principales objetivos:
Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y

capacidad de respuesta.
Desarrollar una serie de WebServices que permitan:
o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Redisear el website para mejorar su usabilidad y optimizarlo para su indexacin en
buscadores.
La Gestin de Versiones es la encargada del proceso de desarrollo, compra, prueba y

distribucin de las nuevas versiones de hardware y software asociadas. Para ello:
En colaboracin con las Gestiones de Capacidad y Disponibilidad evala las

necesidades del nuevo hardware y se encarga de su compra y configuracin.
Contacta con sus proveedores habituales de desarrollo web para establecer de forma
precisa las especificaciones del nuevo software y establecer un calendario de
desarrollo.
Duplica la estructura web: se compran nuevos servidores para que los antiguos
puedan prestar servicio permanentemente y estn dispuestos inmediatamente para el
"back-out".
Se crean scripts de traduccin que permitan salvar los nuevos datos en la versin
anterior para evitar su perdida en caso de back-out.
Se establece un calendario de pruebas con usuarios reales para que estos puedan
probar y "aprobar" el nuevo servicio.
Se planifica un despliegue en dos fases:
I. Se implementa toda la estructura web pero los datos no se incorporan
directamente en el ERP de la empresa.
II. Se completa el proceso con la integracin mediante WebServices de los
pedidos web en el ERP.
Se desarrolla un manual de usuario para la nueva versin y se crea una pgina FAQs
en la web que incluyen las dudas ms frecuentes elevadas por los usuarios en la fase
de pruebas.
Se informa a los usuarios sobre la nueva versin y se avisa de posibles y cortas
interrupciones del servicio en la fecha de instalacin.
Se procede a la instalacin de la nueva versin.
Se guarda una copia maestra de todo el software en la DSL.
Se actualiza la CMDB.
Gestin de Niveles de Servicio
Visin General
125

El objetivo ltimo de la Gestin de Niveles de Servicio es poner la tecnologa al servicio
del cliente.
La tecnologa, al menos en lo que respecta a la gestin de servicios TI, no es un fin en s
misma sino un medio para aportar valor a los usuarios y clientes.
La Gestin de Niveles de Servicio debe velar por la calidad de los servicios TI alineando
tecnologa con procesos de negocio y todo ello a unos costes razonables.
Para cumplir sus objetivos es imprescindible que la Gestin de Niveles de Servicio:
Conozca las necesidades de sus clientes.

Defina correctamente los servicios ofrecidos.
Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs.
Las interacciones y funcionalidades de la Gestin de Niveles de Servicio se resumen

126
127

128
La Gestin de Niveles de Servicio es el proceso por el cual se definen, negocian y
supervisan la calidad de los servicios TI ofrecidos.
La Gestin de Niveles de Servicio es responsable de buscar un compromiso realista entre

las necesidades y expectativas del cliente y los costes de los servicios asociados, de forma
que estos sean asumibles tanto por el cliente como por la organizacin TI.
La Gestin de los Niveles de Servicio debe:
Documentar todos los servicios TI ofrecidos.

Presentar los servicios de forma comprensible para el cliente.
Centrarse en el cliente y su negocio y no en la tecnologa.
Colaborar estrechamente con el cliente para proponer servicios TI realistas y
ajustados a sus necesidades.
Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los
servicios requeridos.
Establecer los indicadores claves de rendimiento del servicio TI.
Monitorizar la calidad de los servicios acordados con el objetivo ltimo de
mejorarlos a un coste aceptable por el cliente.
Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del
Servicio (SIP).
Los principales beneficios de una correcta Gestin de Niveles de Servicio son:
Los servicios TI son diseados para cumplir sus autnticos objetivos: cubrir las
necesidades del cliente.
Se facilita la comunicacin con los clientes impidiendo los malentendidos sobre las
caractersticas y calidad de los servicios ofrecidos.
Se establecen objetivos claros y metrizables.
Se establecen claramente las responsabilidades respectivas de los clientes y
proveedores del servicio.
Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen
claros protocolos de actuacin en caso de deterioro del servicio.
La constante monitorizacin del servicio permite detectar los "eslabones ms
dbiles de la cadena" para su mejora.
129
La gestin TI conoce y comprende los servicios ofrecidos lo que facilita los

acuerdos con proveedores y subcontratistas.
El personal del Service Desk dispone de la documentacin necesaria (SLAs,
OLAs,etc.) para llevar una relacin fluida con clientes y proveedores.
Los SLAs ayudan a la Gestin TI tanto a calcular los clculos de costes como a
justificar su precio ante los clientes.
Lo que repercute a la larga en una mejora del servicio con la consecuente satisfaccin de
clientes y usuarios.
Las principales dificultades a la hora de implementar la Gestin de Niveles de Servicio se
resumen en:
No existe una buena comunicacin con clientes y usuarios por lo que los SLAs
acordados no recogen sus necesidades reales.
Los acuerdos de nivel de servicio estn basados ms en deseos y expectativas del
cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de
calidad suficiente.
No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.
Los SLAs son excesivamente prolijos y tcnicos incumpliendo as sus objetivos
primordiales.
No se dedican los recursos suficientes pues la direccin los considera como un gasto
aadido y no como parte integral del servicio ofrecido.
Problemas de comunicacin: no todos los usuarios conocen las caractersticas del
servicio y los niveles de calidad acordados.
No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs
dificultando as la mejora de la calidad del servicio.
No existe en la organizacin un verdadero compromiso con la calidad del servicio
TI ofrecido.
Conceptos bsicos
Proveedores, clientes y usuarios
Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos.

Usuarios: las personas que utilizan el servicio.
Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el
cliente.
130
Catlogo de Servicios
El Catlogo de Servicios no es slo una herramienta imprescindible a la hora de simplificar

la comunicacin con el cliente sino que tambin puede ser una gran ayuda tanto a la
organizacin interna como a la proyeccin exterior de la organizacin TI.
El Catlogo de Servicios debe:
Describir los servicios ofrecidos de manera no tcnica y comprensible para clientes y

personal no especializado.
Utilizarse como gua para orientar y dirigir a los clientes.
Incluir, en lneas generales, los niveles de servicio asociados con cada uno de los servicios
ofrecidos.
Encontrarse a disposicin del Service Desk y todo el personal que se halle en contacto
directo con los clientes.
131

Requisitos de Nivel de Servicio (SLR)
El SLR debe incluir informacin detallada sobre las necesidades del cliente y sus
expectativas de rendimiento y nivel de servicios.
El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs
correspondientes.
Hojas de Especificacin
Las Hojas de Especificacin son, primordialmente, documentos tcnicos de mbito interno

que delimitan y precisan los servicios ofrecidos al cliente.
Las Hojas de Especificacin deben evaluar los recursos necesarios para ofrecer el servicio
requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de
determinados procesos, sirviendo de documento de base para la elaboracin de los OLAs y
UCs correspondientes.
Programa de Calidad del Servicio (SQP)
El SQP debe incorporar toda la informacin necesaria para posibilitar una gestin eficiente
de los niveles de calidad del servicio:
Objetivos de cada servicio.

Estimacin de recursos.
Indicadores clave de rendimiento.
Procedimientos de monitorizacin de proveedores.
En resumen, el SQP debe contener la informacin necesaria para que la organizacin TI

conozca los procesos y procedimientos involucrados en el suministro de los servicios
prestados, asegurando que estos se alineen con los procesos de negocio y mantengan unos
niveles de calidad adecuados.
Acuerdo de Nivel de Servicio (SLA)
El SLA debe recoger en un lenguaje no tcnico, o cuando menos comprensible para el

cliente, todos los detalles de los servicios brindados.
Tras su firma, el SLA debe considerarse el documento de referencia para la relacin con el
cliente en todo lo que respecta a la provisin de los servicios acordados, por tanto, es
imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales
como su descripcin, disponibilidad, niveles de calidad, tiempos de recuperacin, etc.
132

Acuerdo de Nivel de Operacin (OLA)
El OLA es un documento interno de la organizacin donde se especifican las

responsabilidades y compromisos de los diferentes departamentos de la organizacin TI en
la prestacin de un determinado servicio.
Contratos de Soporte (UC)
Un UC es un acuerdo con un proveedor externo para la prestacin de servicios no cubiertos

por la propia organizacin TI.
Programa de Mejora del Servicio (SIP)
El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio
como propuestas de mejora basadas en el avance de la tecnologa.
El SIP debe formar parte de la documentacin de base para la renovacin de los SLAs y
debe estar internamente a disposicin de los gestores de los otros procesos TI.
Proceso
Las principales actividades de la Gestin de Niveles de Servicio se resumen en:
Planificacin:
o Asignacin de recursos.
o Elaboracin de un catlogo de servicios.
o Desarrollo de SLAs tipo.
o Herramientas para la monitorizacin de la calidad del servicio.
o Anlisis e identificacin de las necesidades del cliente.
o Elaboracin del los Requisitos de Nivel de servicio(SLR), Hojas de
Especificacin del Servicio y Plan de Calidad del Servicio(SQP).
Implementacin de los Acuerdos de Nivel del Servicio:
o Negociacin.
o Acuerdos de Nivel de Operacin.
o Contratos de Soporte.
Supervisin y revisin de los Acuerdos de Nivel de Servicio:
o Elaboracin de informes de rendimiento.
o Control de los proveedores externos.
o Elaboracin de Programas de Mejora del Servicio (SIP).
133
134
135
136
137
138
139
140
141
142
143
144
Planificacin
La correcta planificacin de la Gestin de Niveles de Servicio requiere la implicacin de
prcticamente todos los estamentos de la organizacin TI. Y, si esto no fuera ya de por s
una labor lo suficientemente compleja, resulta imprescindible la colaboracin activa de los
clientes y usuarios de los servicios TI.
El objetivo primordial de la Gestin de Niveles de Servicio es definir, negociar y
monitorizar la calidad de los servicios TI ofrecidos. Si los servicios no se adecuan a las
necesidades del cliente, la calidad de los mismos es deficiente o sus costes son
desproporcionados, tendremos clientes insatisfechos y la organizacin TI ser responsable
de las consecuencias que se deriven de ello.
Todo el proceso de planificacin previo debe estar orientado a dar respuestas a las siguiente
preguntas:
Qu servicios debemos ofrecer a nuestros clientes?

145
Cules son las necesidades de nuestros clientes?

Cul es el nivel adecuado de calidad de servicio?
Quines y cmo se van a suministrar esos servicios?
Cules sern los indicadores clave de rendimiento para los servicios prestados?
Disponemos de los recursos necesarios para proveer los servicios propuestos con
los niveles de calidad acordados?
La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de
carcter interno y otros accesibles a los clientes, que pasamos a describir sucintamente a
continuacin.
En primer lugar la Gestin de Niveles de Servicio debe poner a disposicin de toda la
organizacin, pero en especial a disposicin del Service Desk y la fuerza de ventas un
Catlogo de Servicios.
Este catlogo de servicios debe describir, en un lenguaje comprensible para los no expertos,
los productos y servicios ofrecidos junto a indicaciones generales del nivel de servicio
ofrecido, tales como disponibilidad, tiempos de respuesta, etc.
La elaboracin de este Catlogo de Servicios puede resultar una tarea compleja pues es
necesario alinear aspectos tcnicos con polticas de negocio pero es un documento
imprescindible pues:
Sirve de gua a los clientes a la hora de seleccionar un servicio que se adapte a sus
necesidades.
Delimita las funciones y compromisos de la organizacin TI.
Puede ser utilizado como herramienta de venta.
Evita malentendidos entre los diferentes actores implicados en la prestacin de
servicios.
Sin embargo, en la mayora de los casos, por muy detallado y completo que sea el Catlogo
de Servicios, la complejidad de los servicios ofrecidos requiere un largo y extenso periodo
de negociacin con el cliente.
Los resultados de esta interaccin/negociacin deben ser incorporados al documento de
Requisitos de Nivel de Servicio (SLR) que debe reflejar las necesidades del cliente y sus
expectativas respecto a:
La funcionalidad y caractersticas del servicio.

La disponibilidad del servicio.
La interaccin del servicio con su infraestructura TI o de otro tipo.
La continuidad del servicio.
Los niveles de calidad del servicio.
Tiempo y procedimientos de implantacin del servicio.
La escalabilidad del servicio ofrecido.
Etc.
146

La informacin contenida en el SLR debe servir de base para elaborar la documentacin
interna que permita determinar "cmo" se prestara el servicio y "quin o quines" sern
responsables del mismo.
Las Hojas de Especificacin del Servicio deben contener:
Una descripcin detallada, con todos los detalles tcnicos necesarios, sobre como se
prestar el servicio.
Cules sern los indicadores internos de rendimiento y calidad del servicio.
Cmo se implementar el servicio.
Si la prestacin del servicio requiere la interaccin con los servicios TI del cliente o
presentas exigencias tcnicas a su infraestructura, est informacin deber reflejarse en una
Hoja de Especificaciones "externa" que habr de acordarse con el cliente y su responsables
tcnicos.
El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestin
interna de los servicios prestados y contener informacin detallada sobre todos los procesos
TI involucrados en la prestacin de los servicios.
En funcin de los requisitos plasmados en las Hojas de Especificacin del Servicio se
elabora un plan global que permita asignar los recursos a la organizacin TI, establecer
metas claras basadas en los indicadores de rendimiento elegidos y asegurar que los niveles
de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos
asumidos por la organizacin.
En caso de que se estimen insuficientes los recursos internos o sencillamente se considere
oportuno externalizar parte de los servicios el SQP servir de documento gua para el
establecimiento de los contratos con los proveedores externos.
Implementacin
La fase de planificacin debe concluir con la elaboracin y aceptacin de los acuerdos
necesarios para la prestacin del servicio.
Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operacin y
Contratos de Soporte.
Acuerdos de Nivel de Servicio
Los SLAs deben contener una descripcin del servicio que abarque desde los aspectos ms
generales hasta los detalles ms especficos del servicio.
147

Es conveniente estructurar los SLAs ms complejos en diversos documentos de forma que
cada grupo involucrado reciba exclusivamente la informacin correspondiente al nivel en
que se integra, ya sea en el lado del cliente como del proveedor.
La elaboracin de un SLA requiere tomar en cuenta aspectos no tecnolgicos entre los que
se encuentran:
La naturaleza del negocio del cliente.

Aspectos organizativos del proveedor y cliente.
Aspectos culturales locales.
Acuerdos de Nivel de Operacin
Los OLAs son documentos de carcter interno de la propia organizacin TI que determinan
los procesos y procedimiento necesarios para ofrecer los niveles de servicio acordados con
los clientes.
El OLA, por su naturaleza, involucra detalles sobre la prestacin del servicio que deben ser
opacos para el cliente pero que resultan imprescindibles a la organizacin TI para su
organizacin.
Contratos de Soporte
Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores

externos en el proceso de prestacin de servicios.
Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los
Contratos de Soporte deben representar compromisos claros y perfectamente delimitados.
A pesar de esta diferencia crucial, los UCs pueden considerarse como una extensin
"externa" de los OLAs en el sentido de que persiguen el mismo fin: organizar los procesos
y procedimientos necesarios para la correcta provisin del servicio.
Monitorizacin
El proceso de monitorizacin de los niveles de servicio es imprescindible si queremos
mejorar progresivamente la calidad del servicio ofrecido, su rentabilidad y la satisfaccin
de los clientes y usuarios.
La monitorizacin de la calidad del servicio requiere el seguimiento tanto de
procedimientos y parmetros internos de la organizacin como los relacionados con la
percepcin de los usuarios.
148

Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con
anterioridad unos baremos de calidad del servicio que han de servir de gua en la
elaboracin de los informes correspondientes.
Las principales fuentes principales de informacin las constituyen:
La documentacin disponible: SLAs, OLAs, UCs, etc.

La Gestin de Incidentes: que debe informar de las incidencias en el servicio y los
tiempos de recuperacin.
La Gestin de la Capacidad y la Disponibilidad: que debe proporcionar la
informacin sobre la infraestructura utilizada para satisfacer la calidad de servicios
acordada.
El Centro de Servicios (Service Desk): que mediante su trato diario con los
clientes, usuarios y organizacin TI supervisa la calidad de los servicios y conoce la
percepcin del cliente respecto a los mismos.
Los informes de rendimiento elaborados deben cubrir factores clave tales como:
Cumplimiento de los SLAs, con informacin sobre la frecuencia y el impacto de los

incidentes responsables de la degradacin del servicio.
Quejas, justificadas o no, de los clientes y usuarios.
Utilizacin de la capacidad predefinida.
Disponibilidad del servicio.
Tiempos de respuesta.
Costes reales del servicio ofrecido.
Problemas detectados y cambios realizados para restaurar la calidad del servicio.
Calidad del servicio de los proveedores externos: nivel de cumplimiento de los
OLAs.
Revisin
La correcta Gestin de Niveles de Servicio es un proceso continuo que requiere la
continua revisin de la calidad de los servicios ofrecidos.
Esta revisin debe realizarse en base a parmetros objetivos y metrizables resultado de la
experiencia previa, los SLAs en vigencia y la evolucin del Catlogo de Servicios.
Este proceso de revisin no debe limitarse a aquellos SLAs que por una razn u otra han
sido incumplidos, aunque, evidentemente, en estos casos sea inexcusable, sino que debe
tener como objetivo mejorar y homogeneizar la calidad del servicio.
149

El resultado de la revisin debe ser un Programa de Mejora del Servicio (SIP) que tome en
cuenta factores tales como:
Problemas relacionados con el servicio TI y sus posibles causas.

Nuevas necesidades del cliente.
Avances tecnolgicos.
Cumplimiento de los niveles de servicio.
Evaluacin de los costes reales del servicio.
Implicaciones de una degradacin de la calidad del servicio en la estructura
organizativa del cliente.
Evaluacin del rendimiento y capacitacin del personal involucrado.
Reasignacin de recursos.
Cumplimiento de los OLAs y UCs relacionados.
Percepcin del cliente y usuarios sobre la calidad de servicio.
Necesidades de formacin adicional a los usuarios de los servicios.
El SIP debe ser el documento base para negociar la renovacin del SLA con el cliente y
debe constituir un documento de referencia para la gestin de otros procesos TI como la
Gestin de Cambios, Gestin de Problemas, etc.
Control del Proceso

El objetivo de la Gestin de Niveles de Servicio no es otro que el de mejorar la calidad del
servicio y la satisfaccin del cliente pero esto no se puede llevar a cabo sin una buena
gestin de los procesos involucrados.
Es esencial disponer de:
Unos objetivos claros y contrastables.

Un equipo con experiencia liderado por un Gestor de Niveles de Servicio con la
cualificacin y experiencia necesarios.
Una asignacin clara de tareas y responsabilidades.
Indicadores especficos de rendimiento tales como:
o Porcentaje de servicios amparados bajo SLAs.
o Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la
o SIPs elaborados e impacto de los mismos en la calidad del servicio.
o Encuestas de satisfaccin del cliente.
La correcta elaboracin de informes internos de gestin permite evaluar el rendimiento de

la Gestin de Niveles de Servicio y aporta informacin de vital importancia a otras reas
involucradas en el soporte y la provisin de los servicios TI.
150

Informes Estadsticos de Rendimiento: donde se detallen los SLAs, OLAs y UCs

elaborados y el nivel de cumplimiento de los mismos, costes promedio asociados al
proceso, etc.
Informes de Seguimiento: donde se especifiquen las acciones de monitorizacin
realizadas, sus resultados y el grado de satisfaccin de los clientes con el servicio
prestado.
Planes de Mejora: donde se especifiquen las acciones propuestas para la mejora
del servicio TI y el impacto que estas han tenido en la calidad del servicio.
Caso Prctico
La direccin de "Cater Matters" ha decidido implementar una Gestin de Niveles de
Servicio que adapte a las necesidades de su organizacin los principios y recomendaciones
de ITIL.
Para llevar a cabo esta tarea de la forma ms eficiente posible se han determinado una serie
de acciones iniciales que se resumen en:
Designacin de un Gestor del proceso.

Elaboracin de un catlogo de servicios.
Desarrollo de un Plan Integral de Calidad del Servicio.
Creacin de "plantillas" para la creacin de SLAs asociados a sus principales servicios.
Gestor de Niveles de Servicio
La direccin ha encargado a uno de sus directivos con ms amplia experiencia en la

relacin con los clientes asumir el puesto de Gestor de Niveles de Servicio.
Su principal funcin es negociar y acordar, en representacin de "Cater Matters", la
provisin de servicios con los clientes.
Sus responsabilidades especficas incluyen:
Elaborar y mantener actualizado un catlogo de los servicios ofrecidos por "Cater

Matters".
Determinar la estructura general de los SLAs, OLAs y UCs.
Negociar los SLAs, OLAs y UCs con clientes y proveedores
Supervisar el cumplimiento de los acuerdos de provisin del servicio con clientes y
proveedores.
Mantener informados a la Direccin y la organizacin TI sobre el rendimiento de todo el
proceso.
151
Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en la calidad
de los servicios prestados y/o adapten estos servicios a las nuevas necesidades de los
clientes y a los ltimos avances tecnolgicos.
Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la
informacin necesaria para el ptimo funcionamiento de la organizacin.
Elaboracin del Catlogo de Servicios
Se ha decidido estructurar el Catlogo de Servicios en funcin de los diferentes tipos de

clientes que contratan los servicios de "Cater Matters":
Particulares.
Pequeas empresas.
Grandes corporaciones e instituciones y organismos pblicos.
El objetivo del catlogo no es slo dar a conocer los diferentes servicios sino mostrar
claramente al (potencial) cliente cuales son las diferencias entre las diferentes opciones de
un mismo "servicio base".
Para ello se elabora un catlogo online que permite comparar las diferentes "versiones" y
realizar una estimacin preliminar de los costes basndose en las diferentes opciones
seleccionadas.
La descripcin de cada servicio incluye informacin adicional sobre:
Plazos de entrega.
Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
Servicios auxiliares.
WebServices asociados.
Disposiciones legales aplicables.
Programas de fidelizacin.
Soporte online.
Plan de Calidad del Servicio
Para asegurar la calidad del servicio se desarrolla un SQP que determina:
La responsabilidad de cada uno de los departamentos en el proceso de provisin del

servicio.
Planes de contingencia en casos de deterioro grave de la calidad del servicio.
Indicadores clave de rendimiento y satisfaccin del cliente.
Mtodos de supervisin y seguimiento en tiempo real de los procesos involucrados en la
prestacin del servicio, como, por ejemplo, el reparto y la provisin de mercanca.
Protocolos de interaccin del Service Desk con los clientes y usuarios.
152
Los niveles de seguridad, disponibilidad, capacidad y redundancia necesarios para

asegurar la correcta provisin del servicio en colaboracin con los responsables de dichos
procesos.
SLAs prototipo
A fin de evitar que la elaboracin de los SLAs se convierta en una tarea excesivamente
compleja y tediosa se desarrollan plantillas para los diferentes tipos de servicios y clientes.
Cada SLA prototipo incluye:
Descripcin general y no tcnica de los servicios acordados.

Responsables del acuerdo tanto por el lado cliente como proveedor.
Plazos para la provisin del servicio.
Duracin del acuerdo y condiciones para su renovacin y/o rescisin.
Condiciones de disponibilidad del servicio.
Soporte y labores de mantenimiento asociadas.
Tiempos de respuesta.
Tiempos de recuperacin en casos de incidentes.
Planes de contingencia si son de aplicacin.
Mtodos de facturacin y cobro.
Criterios de evaluacin de la calidad del servicio.
Gestin Financiera de los Servicios TI
Visin General
Aunque casi todas las empresas y organizaciones utilizan las tecnologas de la informacin
en prcticamente todos sus procesos de negocio es moneda corriente que no exista una
conciencia real de los costes que esta tecnologa supone.
Esto conlleva serias desventajas:
Se desperdician recursos tecnolgicos.

No se presupuestan correctamente los gastos asociados.
Es prcticamente imposible establecer una poltica consistente de precios.
El principal objetivo de la Gestin Financiera es el de evaluar y controlar los costes

asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes
con un uso eficiente de los recursos TI necesarios.
Si la organizacin TI y/o sus clientes no son conscientes de los costes asociados a los
servicios no podrn evaluar el retorno a la inversin ni podrn establecer planes
consistentes de inversin tecnolgica.
153

Las propiedades y funcionalidades de la Gestin Financiera de los Servicios TI se
resumen sucintamente en el siguiente interactivo:
154
155
La Gestin Financiera de los Servicios Informticos tiene como objetivo principal
administrar de manera eficaz y rentable los servicios y la organizacin TI.
Por regla general, a mayor calidad de los servicios mayor es su coste, por lo que es
necesario evaluar cuidadosamente las necesidades del cliente para que el balance entre
ambos sea ptimo.
Para lograr este objetivo la Gestin Financiera debe:
Evaluar los costes reales asociados a la prestacin de servicios.
156
Proporcionar a la organizacin TI toda la informacin financiera precisa para la

toma de decisiones y fijacin de precios.
Asesorar al cliente sobre el valor aadido que proporcionan los servicios TI
prestados.
Evaluar el retorno (ROI) de las inversiones TI.
Llevar la contabilidad de los gastos asociados a los servicios TI.
Los principales beneficios de una correcta Gestin Financiera de los Servicios

Informticos se resumen en:
Se reducen los costes y aumenta la rentabilidad del servicio.

Se ajustan, controlan, adecuan y justifican (si es de aplicacin) los precios del
servicio aumentando la satisfaccin del cliente.
Los clientes contratan servicios que le ofrecen una buena relacin
coste/rentabilidad.
La organizacin TI puede planificar mejor sus inversiones al conocer los costes
reales de los servicios TI.
Los servicios TI son usados ms eficazmente.
La organizacin TI funciona como una unidad de negocio y es posible evaluar
claramente su rendimiento global.
Las principales dificultades a la hora de implementar la Gestin Financiera de los

Servicios Informticos se resumen en:
Es difcil encontrar personal que est familiarizado tanto con los servicios TI como
con aspectos financieros y/o contables.
Existen mltiple costes ocultos difciles de evaluar por una deficiente organizacin
financiera.
No existe una estrategia clara que permita elaborar unos presupuestos ajustados a la
misma.
Un incremento de los costes.
No hay un compromiso de toda la organizacin con el proceso.
Conceptos Bsicos
Categoras de coste
La clasificacin de costes por servicio o producto puede realizarse en virtud de uno a ms

criterios:
157
Costes atribuibles, directa o indirectamente a la prestacin del servicio o elaboracin del

producto:
Costes Directos: son los costes relacionados especfica y exclusivamente con un producto
o servicio, como por ejemplo, los servidores web asociados a los servicios de Internet.
Costes indirectos: aquellos que nos son especficos y exclusivos de un servicio, como por
ejemplo, la "conectividad" de la organizacin TI de la que dependen tanto los servicios
web como la propia plataforma general de comunicaciones. Estos costes son ms difciles
de determinar y por lo general son prorrateados entre los diferentes servicios y productos.
Costes que dependen o no del "cunto":
Costes fijos: son independientes del volumen de produccin y estn normalmente

relacionados con gastos en inmovilizado material.
Costes variables: incluyen aquellos costes que dependen del volumen de produccin y
engloban, por ejemplo, los gastos de personal que presta los servicios, los fungibles, etc.
Costes que dependen del horizonte temporal:
Costes de capital: que proviene de la amortizacin del inmovilizado material o inversiones

a largo plazo.
Costes de Operacin: son los costes asociados al funcionamiento diario de la organizacin
TI.
158

Tipos de coste
Es imprescindible distinguir entre los diferentes tipos de coste para disear una poltica de
precios clara y consistente.
Los tipos de coste se subdividen a su vez en elementos de coste. El siguiente diagrama nos
muestra una tpica estructura de tipos y elementos de coste para una organizacin TI:
* Los costes de Transferencia se corresponden con los cargos internos por servicios
prestados por otros departamentos de la empresa o institucin.
Proceso
Las principales actividades de la Gestin Financiera se resumen se resumen en:
Presupuestos:
o Anlisis de la situacin financiera.
o Fijacin de polticas financieras.
159

Elaboracin de presupuestos.
Contabilidad:
o Identificacin de los costes.
o Definicin de elementos de coste.
o Monitorizacin de los costes.
Fijacin de precios:
o Elaboracin de una poltica de fijacin de precios.
o Establecimiento de tarifas por los servicios prestados o productos ofrecidos.
o
160
161
162
163
Presupuestos
La elaboracin de presupuestos TI tiene como objetivos principales:
Planificar el gasto e inversin TI a largo plazo.

Asegurar que los servicios TI estn suficientemente financiados.
Establecer objetivos claros que permitan evaluar el rendimiento de la organizacin
TI.
Los presupuestos realizados pueden tener diferentes horizontes temporales. Pueden ser a
corto plazo, incluyendo los costes de los servicios prestados en la actualidad, o resultar de
una proyeccin sobre la evolucin prevista del negocio en dos o ms aos.
Aunque no existe una nica manera de realizar un presupuesto TI son mtodos habituales:
Presupuesto incremental: el presupuesto se realiza en base al histrico de

presupuestos anteriores, adaptndolos a las modificaciones en los costes y el
164
desarrollo de nuevas tecnologas, y teniendo en consideracin la aparicin de

nuevas lneas de servicios.
Presupuesto "desde cero": se replantea toda la estructura de costes e inversiones a
partir de una "hoja en blanco" en base a los servicios prestados en la actualidad y las
expectativas de crecimiento en el periodo presupuestado.
Para que estos presupuestos sean realistas y sirvan realmente de referencia a la

organizacin TI es necesario identificar previamente todos los elementos de coste.
La estimacin de los costes asociados a esos elementos no es siempre una tarea sencilla y a
menudo influyen factores externos que no se hallan bajo el control directo de la
organizacin TI, como por ejemplo el aumento del precio de las licencias del software, etc.
Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se
muestren precavidos al respecto para evitar que se conviertan en papel mojado al menor
vaivn del mercado.
Contabilidad
En principio, la contabilidad asociada a los servicios TI sigue patrones similares a la
contabilidad asociada a otros servicios o departamentos. Sin embargo, la complejidad de las
interrelaciones TI dificulta el proceso cuando los responsables de su contabilidad
desconocen sus mecanismos bsicos y la tecnologa que los sustenta.
Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance
un excesivo nivel de detalle que lo encarezca ms all de lo razonable.
Las actividades contables deben permitir:
Una correcta evaluacin de los costes reales para su comparacin con los presupuestados.
Tomar decisiones de negocio basadas en los costes de los servicios.
Evaluar la eficiencia financiera de cada uno de los servicios TI prestados.
Facturar adecuadamente, si es de aplicacin, los servicios TI.
Si se desea considerar a la organizacin TI como otra unidad de negocio es necesario

conocer en detalle tanto sus costes como sus "ingresos" (aunque estos ltimos en muchos
casos slo sean nominales pues el cliente es la propia organizacin).
Es una de las actividades principales de la Gestin Financiera identificar los denominados
elementos de coste que se pueden clasificar de forma genrica en:
costes de hardware y software,

165
costes de Personal,
costes generales,
asignando a cada servicio/cliente su parte proporcional.
Poltica de Precios
No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia
organizacin, pero ste es un paso esencial si buscamos que se utilice eficientemente la
infraestructura TI.
Para que la organizacin TI pueda funcionar como una verdadera unidad de negocio es
imprescindible tanto conocer los costes reales de los servicios prestados como establecer
una poltica de precios que, cuando menos, permita recuperar los costes en los que se ha
incurrido.
En primer lugar debe establecerse una poltica de fijacin de precios. Existen mltiples
opciones, entre ellas:
Coste ms margen: se establecen los costes totales del servicio y se les aade un
margen de beneficios (que puede ser del 0% para "clientes internos").
Precio de mercado: se cobran los servicios en funcin de las tarifas vigentes en el
mercado para servicios de similar naturaleza.
Precio negociado: se negocia directamente con el cliente cul es el precio
estipulado por los servicios.
Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los
objetivos cumplidos.
Una vez determinada la poltica de fijacin de precios se deben determinar las tarifas de los
servicios en funcin de:
La poltica elegida.
Los servicios solicitados.
Factores de escala y necesidades de disponibilidad.
Los costes asociados.
Los precios vigentes en el mercado.
En algunas ocasiones estas tarifas sern usadas para una facturacin real mientras que en
otras slo se utilizarn de referencia para evaluar el rendimiento terico de la organizacin
TI.

166
Supervisin
No es tarea de la Gestin Financiera de los Servicios TI sino de la Gestin de Niveles de
Servicio negociar con los clientes y elaborar el catlogo de servicios. Sin embargo, es
recomendable que, en los aspectos econmicos, su actividad sea supervisada por la Gestin
Financiera.
Para ello es necesario que exista una comunicacin fluida y convenientemente estructurada
entre ambos procesos.
Por un lado la Gestin de Niveles de Servicio debe proveer informacin a la Gestin
Financiera sobre:
El tipo de servicios demandados por los clientes.

Los SLAs contratados.
Los contratos de soporte (UCs) en vigor.
Tendencias del mercado y Planes de Mejora del Servicio (SIP).
Mientras que la Gestin Financiera debe aportar informacin sobre:
Los costes reales de los servicios.

Previsiones de costes.
Desviaciones en las previsiones de costes respecto a los gastos reales.
Mtodos y condiciones de pago.
Sin una estrecha colaboracin entre ambos procesos ser imposible llegar a acuerdos que
sean rentables y a su vez satisfactorios para el cliente.
Control del Proceso

El responsable de el proceso de Gestin Financiera no ha de ser de manera imprescindible
un miembro de la organizacin TI, es, sin embrago, imprescindible que disponga de ciertos
conocimiento sobre los servicios TI y/o est correctamente asesorado por especialistas en
todo lo referente a la tecnologa.
Para poder evaluar la funcin de la Gestin Financiera es necesario establecer tanto unos
criterios claros para evaluar su xito como unos indicadores de rendimiento especficos.
Entre los primeros cabe destacar:
Conoce la organizacin los costes reales de los servicios TI?

167
Los clientes perciben la poltica de precios como coherente y ajustada al mercado?

Colaboran los responsables de los otros procesos TI con la Gestin Financiera?
Estn los gastos en servicios e infraestructuras TI realmente alineados con los
procesos de negocio?
Opera la organizacin TI como una verdadera unidad de negocio?
En lo que respecta a los indicadores de rendimiento, estos deben incluir mtricas que
permitan evaluar si:
Los gastos TI estn correctamente planificados y presupuestados.

Se cumplen los objetivos de costes e ingresos.
Se lleva a cabo una contabilidad precisa asociada a cada servicio.
Se conoce el ROI de las inversiones TI.
La organizacin TI funciona de manera "rentable".
La correcta elaboracin de informes internos de gestin permite evaluar el rendimiento de

la Gestin de Financiera segn los parmetros arriba descritos y aporta informacin de vital
importancia a la organizacin en su conjunto.
Resmenes contables.
Anlisis de eficiencia de cada uno de los servicios TI.
Planes de inversin TI basados en el histrico del negocio y en previsiones de
evolucin de la tecnologa.
Planes de reduccin de costes por servicio.
Caso Prctico
La organizacin TI de "Cater Matters" lleva prestando, desde hace aos, servicios
esenciales tanto a la propia organizacin de la empresa como a los clientes externos de sus
servicios de catering.
Sin embargo, hasta la fecha, los gastos TI no han sido contabilizados y presupuestados de
manera especfica y es, con los datos disponibles en la actualidad, imposible conocer el
impacto de los servicios TI en los costes de cada uno de los servicios de catering prestados.
La gestin de "Cater Matters" quiere desarrollar una poltica de fijacin de precios de los
servicios TI que le permita trasladar sus costes al usuario final del servicio de catering,en la
misma medida que ya se hace con los costes de transporte, materias primas, etc.
168

Para gestionar el proceso se ha nombrado a un senior manager del departamento TI y a un
miembro del departamento financiero de la empresa como responsables del mismo.
El plan de trabajo a corto plazo incluye:
En colaboracin con la Gestin de Configuraciones elaborar un listado de todos

los CIs que intervienen en la prestacin de servicios directos a los clientes.
Evaluar, prorrateando entre los diferentes servicios si esto fuera necesario, cuales
son los costes asociados al uso de los mismos: amortizacin, mantenimiento,
fungibles, etc.
Evaluar los costes de personal y los costes operativos.
Estimar los costes de difcil asignacin u ocultos asociados a los servicios TI.
Evaluar los costes indirectos: instalaciones, costes administrativos, etc.
Establecer estrictos criterios contables para la administracin de los costes TI.
Establecer una poltica de precios de coste adicional o "coste + margen".
Todas estas actividades buscan determinar con precisin los costes asociados a los servicios
TI ya prestados y proponer tarifas que sean trasladas a los clientes, ya sea directamente o
incluidas en otras partidas de carcter general.
Pero los objetivos de una Gestin Financiera proactiva van ms all e incluyen una
correcta planificacin de gastos e inversiones futuras. Para ello y en colaboracin con la
Gestin de Niveles de Servicio, Gestin de la Capacidad y Gestin de la Disponibilidad
se estudian:
Los requisitos de los clientes y las tendencias de mercado.

El impacto en los costes de los Planes de Mejora del Servicio (SIP).
Necesidades futuras y proyecciones de la capacidad TI.
La informacin recopilada servir de base para la elaboracin de los primeros

"presupuestos anuales TI" elaborados por la Gestin Financiera.
Gestin de la Capacidad
Visin General
La Gestin de la Capacidad es la encargada de que todos los servicios TI se vean
respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente
dimensionada.
Sin una correcta Gestin de la Capacidad los recursos no se aprovechan adecuadamente y
se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y
administracin. O an peor, los recursos son insuficientes con la consecuente degradacin
de la calidad del servicio.
169

Entre las responsabilidades de la Gestin de la Capacidad se encuentran:
Asegurar que se cubren las necesidades de capacidad TI tanto presentes como

futuras.
Controlar el rendimiento de la infraestructura TI.
Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
Gestionar y racionalizar la demanda de servicios TI.
170
171
El objetivo primordial de la Gestin de la Capacidad es poner a disposicin de clientes,
usuarios y el propio departamento TI los recursos informticos necesarios para desempear
de una manera eficiente sus tareas y todo ello sin incurrir en costes desproporcionados.
Para ello la Gestin de la Capacidad debe:
172
Conocer el estado actual de la tecnologa y previsibles futuros desarrollos.

Conocer los planes de negocio y acuerdos de nivel de servicio para prever la
capacidad necesaria.
Analizar el rendimiento de la infraestructura para monitorizar el uso de la capacidad
existente.
Realizar modelos y simulaciones de capacidad para diferentes escenarios futuros
previsibles.
Dimensionar adecuadamente los servicios y aplicaciones alinendolos a los
procesos de negocio y necesidades reales del cliente.
Gestionar la demanda de servicios informticos racionalizando su uso.
173

La Gestin de la Capacidad intenta evitar situaciones en las que se realizan inversiones
innecesarias en tecnologas que no estn adecuadas a las necesidades reales del negocio o
estn sobredimensionadas, o por el contrario, evitar situaciones en las que la productividad
se ve mermada por un insuficiente o deficiente uso de las tecnologas existentes.
Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una
misma organizacin: directivos, clientes e informticos deslumbrados por tecnologas que
realmente no necesitan y adquieren pero que obvian aplicaciones, equipos y servicios que
realmente aumentaran la productividad en sus respectivos entornos de trabajo.
Una de las principales tareas de la Gestin de la Capacidad es la de matizar la percepcin
de que la "capacidad es barata". Aunque el aumento de la capacidad puede requerir, en
primera instancia, de modestos desembolsos, debido a la reduccin de costes en los equipos
de hardware y aplicaciones informticas, la administracin y mantenimiento de
infraestructuras desproporcionadas puede resultar, a la larga, muy cara.
Los principales beneficios derivados de una correcta Gestin de la Capacidad son:
Se optimizan el rendimiento de los recursos informticos.

Se dispone de la capacidad necesaria en el momento oportuno, evitando as que se
pueda resentir la calidad del servicio.
Se evitan gastos innecesarios producidos por compras de "ltima hora".
Se planifica el crecimiento de la infraestructura adecundolo a las necesidades
reales de negocio.
Se reducen de los gastos de mantenimiento y administracin asociados a equipos y
aplicaciones obsoletos o innecesarios.
Se reducen posibles incompatibilidades y fallos en la infraestructura informtica.
En resumen: se racionaliza la gestin de las compras y mantenimiento de los servicios TI

con la consiguiente reduccin de costes e incremento en el rendimiento.
La implementacin de una adecuada poltica de Gestin de la Capacidad tambin se
encuentra con algunas serias dificultades:
Informacin insuficiente para una planificacin realista de la capacidad.

Expectativas injustificadas sobre el ahorro de costes y mejoras del rendimiento.
Insuficiencia de recursos para la correcta monitorizacin del rendimiento.
Infraestructuras informticas distribuidas y excesivamente complejas en las que es
difcil un correcto acceso a los datos.
No existe el compromiso suficiente de la direccin por implementar rigurosamente
los procesos asociados.
La rpida evolucin de las tecnologas puede obligar a una revisin permanente de
los planes y escenarios contemplados.
Un correcto dimensionamiento de la propia Gestin de la Capacidad: un excesivo
celo puede provocar costosos anlisis de capacidad que podran haber sido
innecesarios con la compra de nuevo hardware o software.
174

Proceso
Las principales actividades de la Gestin de la Capacidad se resumen en:
Desarrollo del Plan de Capacidad.

Modelado y simulacin de diferentes escenarios de capacidad.
Monitorizacin del uso y rendimiento de la infraestructura TI.
Gestin de la demanda.
Creacin y mantenimiento de la Base de Datos de Capacidad (CDB).
El proceso de Gestin de la Capacidad puede segmentarse en subprocesos que analizan

las necesidades de capacidad TI desde diferentes puntos de vista:
Gestin de la Capacidad del Negocio: que centra su objeto de atencin en las

necesidades futuras de usuarios y clientes.
Gestin de la Capacidad del Servicio: que analiza el rendimiento de los servicios
TI con el objetivo de garantizar los niveles de servicio acordados.
Gestin de la Capacidad de Recursos: que estudia tanto el uso de la
infraestructura TI como sus tendencias para asegurar que se dispone de los recursos
suficientes y que estos se utilizan eficazmente.
El siguiente diagrama muestra los procesos implicados en la correcta Gestin de la

Capacidad:
175
176
177
178
179
180
181
182
183
184
185
186
Planificacin
Plan de Capacidad
La elaboracin del Plan de Capacidad es la tarea principal de la Gestin de Capacidad.

El Plan de Capacidad recoge:
Toda la informacin relativa a la capacidad de la infraestructura TI.

Las previsiones sobre necesidades futuras basadas en tendencias, previsiones de negocio y
SLAs existentes.
Los cambios necesarios para adaptar la capacidad TI a las novedades tecnolgicas y las
necesidades emergentes de usuarios y cliente.
El Plan de Capacidad debe incluir informacin sobre los costes de la capacidad actual y
prevista. Esta informacin es indispensable para que la Gestin Financiera pueda elaborar
los presupuestos y previsiones financieras de manera realista.
187

Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es
importante que se monitorice su cumplimiento para adoptar medidas correctivas en cuanto
se detecten desviaciones importantes del mismo.
Modelado y Benchmarking
Cuanto ms compleja sea una infraestructura informtica ms difcil es prever las

necesidades de capacidad futura. En esos casos, es imprescindible realizar modelos y
simulaciones sobre posibles escenarios de desarrollo futuro que aseguren la correcta
escalabilidad de las aplicaciones y hardware.
El nivel de detalle al que se lleve este modelado depender de varios factores:
Costes asociados al incremento de la capacidad.

Costes inherentes al proceso mismo de modelado y simulacin.
Alcance de los incrementos de capacidad previstos.
La "criticalidad" de los sistemas implicados.
Sopesando los anteriores factores podemos optar por:
Un simple anlisis de tendencias que permita evaluar la carga de proceso esperada en la

infraestructura informtica y escalar consecuentemente su capacidad actual.
Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones
de carga y repuesta de la infraestructura informtica.
Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de
la futura infraestructura.
Recursos
Un aspecto esencial de la Gestin de la Capacidad es el de asignar recursos adecuados de
hardware, software y personal a cada servicio y aplicacin.
El correcto dimensionamiento requiere que la Gestin de la Capacidad disponga de
informacin fiable sobre:
Los niveles de servicio acordados y/o previstos.

Niveles de rendimiento esperados.
Impacto de la aplicacin o servicio en los procesos de negocio del cliente.
Mrgenes de seguridad y disponibilidad.
Costes asociados a los equipos de hardware y otros recursos TI necesarios.
188

Es importante que la Gestin de la Capacidad participe en las primeras etapas de
desarrollo de un producto, servicio o definicin de un SLA para asegurar que se dispondr
de la capacidad necesaria para llevar el proyecto a buen trmino.
Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento
de una aplicacin debido a expectativas injustificadas sobre la tecnologa. Se puede caer en
el equivoco de que los costes asociados a la capacidad se limitan a la compra de mas
servidores, o ms espacio de almacenamiento, etctera, olvidando que sistemas ms
complejos implican uno mayores gastos de mantenimiento y administracin, o ignorando
los problemas que pueden conllevar dichos cambios.
Supervisin del Proceso

La Gestin de la Capacidad es un proceso continuo e iterativo que monitoriza, analiza y
evala el rendimiento y capacidad de la infraestructura TI y con los datos obtenidos
optimiza los servicios o eleva una RFC a la Gestin de Cambios.
Tanto la informacin obtenida en estas actividades como la generada a partir de ella por la
Gestin de la Capacidad se almacena y registra en la Base de Datos de la Capacidad
(CDB).
189

Monitorizacin
Su objetivo principal es asegurar que el rendimiento de la infraestructura informtica se

adecua a los requisitos de los SLAs.
La monitorizacin debe incluir, adems de aspectos tcnicos todos aquellos relativos a
licencias y otros aspectos de carcter administrativo.
Anlisis y Evaluacin
Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones
correctivas tales como peticin de aumento de la capacidad o una mejor Gestin de la
Demanda.
Optimizacin y cambios
Si se ha optado por solicitar un aumento de la capacidad se elevar una RFC a la Gestin

de Cambios para que se desencadene todo el proceso necesario para la implementacin del
cambio. La Gestin de la Capacidad prestar su apoyo en todo el proceso y ser
corresponsable, junto a la Gestin de Cambios y Versiones de asegurar que el cambio
solicitado cumpla los objetivos previstos.
En el caso de que una simple racionalizacin de la demanda sea suficiente para solventar
las posibles deficiencias o incumplimientos de los SLAs ser la propia Gestin de la
Capacidad la responsable de gestionar ese subproceso.
Base de Datos de la Capacidad
La CDB debe cubrir toda la informacin de negocio, financiera, tcnica y de servicio que
reciba y genere la Gestin de la Capacidad relativas a la capacidad de la infraestructura y
sus elementos.
Idealmente la CDB debe estar interrelacionada con la CMDB para que esta ltima ofrezca
una imagen integral de los sistemas y aplicaciones con informacin relativa a su capacidad.
Esto no es bice para que ambas bases de datos puedan ser "fsicamente independientes".
Gestin de la Demanda
El objetivo de la Gestin de la Demanda es el de optimizar y racionalizar el uso de los
recursos TI.
190

Aunque la Gestin de la Demanda debe formar parte de las actividades rutinarias de la
Gestin de la Capacidad sta cobra especial relevancia cuando existen problemas de
capacidad en la infraestructura TI.
El origen de los problemas que la Gestin de la Demanda debe subsanar a corto plazo
incluyen:
Degradacin del servicio por aumentos no previstos de la demanda.

Interrupciones parciales del servicio por errores de hardware o software.
La Gestin de la Demanda es la encargada en estos casos de redistribuir la capacidad para

asegurar que los servicios crticos no se ven afectados o, cuando menos, lo sean en la menor
medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la
Gestin de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en
consecuencia.
Pero una tarea no menos importante es la Gestin de la Demanda a medio y largo plazo.
Un aumento de la capacidad siempre conlleva costes que muchas veces resultan
innecesarios. Una correcta monitorizacin de la capacidad permite reconocer puntos dbiles
de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribucin a largo
plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la
capacidad.
Por ejemplo, una incorrecta distribucin de tareas puede provocar que el ancho de banda
contratado por la organizacin se muestre insuficiente en horas punta porque se estn
enviando miles de correos electrnicos asociados a procesos automticos (tales como
campaas de marketing promocional, informes de rendimiento para clientes, etctera). En
la mayora de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar
la calidad del servicio, ahorrando a la organizacin una gravosa ampliacin del ancho de
banda.
Ahora bien, si el coste aadido por aumentar el ancho de banda es marginal, puede resultar
ms eficiente su contratacin directa que invertir el precioso (y costoso) tiempo de personal
altamente especializado en la optimizacin del sistema.
La Gestin de la Capacidad debe evaluar a priori, basandose en la experiencia y las
tendencias del mercado, cundo la solucin "ms potente, ms grande" es econmicamente
ms rentable (teniendo en cuenta los costes indirectos) que un anlisis pormenorizado de la
situacin.
Control del Proceso

191

la Capacidad.
La documentacin elaborada debe incluir informacin sobre:
El uso de recursos.
Desviaciones de la capacidad real sobre la planificada.
Anlisis de tendencias en el uso de la capacidad.
Mtricas establecidas para el anlisis de la capacidad y monitorizacin del
rendimiento.
Impacto en la calidad del servicio, disponibilidad y otros procesos TI.
El xito de la Gestin de la Capacidad depende algunos indicadores clave entre los que se
encuentran:
Correcta previsin de las necesidades de capacidad.

Reduccin de los costes asociados a la capacidad.
Ms altos niveles de disponibilidad y seguridad.
Mayor satisfaccin de los usuarios y clientes.
Cumplimiento de los SLAs.
Caso Prctico
Hasta la fecha, la Gestin de las Capacidad de "Cater Matters" haba sido reactiva, o en
otras palabras el incremento o redistribucin de la capacidad se realizaba exclusivamente
cuando aparecan los problemas.
Con el incremento de la importancia de los servicios TI, tanto para la organizacin de
"Cater Matters" como para sus clientes, la direccin de la empresa ha decidido implementar
las mejores prcticas ITIL para la Gestin de la Capacidad.
Para ello se ha nombrado un Gestor de la Capacidad que tiene como principales
responsabilidades:
Monitorizar el rendimiento de la infraestructura TI prestando especial atencin al de

los servicios online, especialmente importantes a la hora de prestar un buen servicio
a sus clientes.
Analizar en colaboracin con la Gestin de Configuraciones el impacto de los
diferentes CIs en la capacidad del sistema.
Evaluar, en colaboracin con la Gestin de Niveles de Servicio, la carga de
proceso, almacenamiento y ancho de banda que suponen los SLAs vigentes y
previstos.
192
Evaluar, en colaboracin con la Gestin Financiera, los costes reales de cada

servicio.
Realizar informes peridicos sobre el estado de la tecnologa relevante a los
servicios ofrecidos.
Analizar tendencias y estadsticas de uso y carga sobre el sistema.
Los resultados de dicho trabajo deben permitir:
Elaborar un Plan de Capacidad anual que se revisara trimestralmente frente a datos

reales extrados de la monitorizacin del sistema y de las previsiones de negocio.
Poblar la Base de Datos de la Capacidad (CDB) para que contenga toda la
informacin relevante a la capacidad.
Proponer mejoras del servicio.
Con el objetivo de:
Minimizar el nmero e impacto de futuros incidentes que degraden la calidad del

servicio.
Racionalizar el uso de la capacidad de la infraestructura TI.
Disminuir los costes en infraestructura TI.
Aumentar la productividad y satisfaccin del cliente.
Gestin de la Continuidad del Servicio
Visin General
La Gestin de la Continuidad del Servicio se preocupa de impedir que una imprevista y
grave interrupcin de los servicios TI, debido a desastres naturales u otras fuerzas de causa
mayor, tenga consecuencias catastrficas para el negocio.
La estrategia de la Gestin de la Continuidad del Servicio (ITSCM) debe combinar
equilibradamente procedimientos:
Proactivos: que buscan impedir o minimizar las consecuencias de una grave

interrupcin del servicio.
Reactivos: cuyo propsito es reanudar el servicio tan pronto como sea posible (y
recomendable) tras el desastre.
La ITSCM requiere una implicacin especial de los agentes involucrados pues sus
beneficios slo se perciben a largo plazo, es costosa y carece de rentabilidad directa.
Implementar la ITSCM es como contratar un seguro mdico: cuesta dinero, parece intil
mientras uno est sano y desearamos nunca tener que utilizarlo, pero tarde o temprano nos
alegramos de haber sido previsores.
193
194
195
Los objetivos principales de la Gestin de la Continuidad de los Servicios TI (ITSCM) se
resumen en:
Garantizar la pronta recuperacin de los servicios (crticos) TI tras un desastre.

Establecer polticas y procedimientos que eviten, en la medida de lo posible, las
perniciosas consecuencias de un desastre o causa de fuerza mayor.
Aunque, a priori, las polticas proactivas que prevean y limiten los efectos de un desastre
sobre los servicios TI son preferibles a las exclusivamente reactivas, es importante valorar
los costes relativos y la incidencia real en la continuidad del negocio para decantarse por
una de ellas o por una sabia combinacin de ambas.
Una correcta ITSCM debe formar parte integrante de la Gestin de Continuidad del
Negocio (BCM) y debe estar a su servicio. Los servicios TI no son sino una parte, aunque a
menudo muy importante, del negocio en su conjunto y no tiene mayor sentido que, por
ejemplo, un sistema de pedidos online siga funcionando a la perfeccin tras un desastre si
nos resulta imposible suministrar la mercanca a nuestros clientes.
Es importante diferenciar entre desastres "de toda la vida", tales como incendios,
inundaciones, etctera, y desastres "puramente informticos", tales como los producidos
por ataques distribuidos de denegacin de servicio (DDOS), virus informticos, etctera.
Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y
restaurar el servicio TI con prontitud, es evidente que recae sobre la ITSCM una
responsabilidad especial en el ltimo caso pues:
Slo afectan directamente a los servicios TI pero paralizan a toda la organizacin.

Son ms previsibles y ms habituales.
La percepcin del cliente es diferente: los desastres naturales son ms asumibles y no se
asocian a actitudes negligentes, aunque esto no sea siempre cierto.
196

Los principales beneficios de una correcta Gestin de la Continuidad del Servicio se
resumen en:
Se gestionan adecuadamente los riesgos.

Se reduce el periodo de interrupcin del servicio por causas de fuerza mayor.
Se mejora la confianza en la calidad del servicio entre clientes y usuarios.
Sirve de apoyo al proceso de Gestin de la Continuidad del Negocio.
Las principales dificultades a la hora de implementar la Gestin de la Continuidad del

Servicio se resumen en:
Puede haber resistencia a realizar inversiones cuya rentabilidad no es inmediata.

No se presupuestan correctamente los costes asociados.
No se asignan los recursos suficientes.
No existe el compromiso suficiente con el proceso dentro de la organizacin y las tareas y
actividades correspondientes se demoran perpetuamente para hacer frente a "actividades
ms urgentes".
No se realiza un correcto anlisis de riesgos y se obvian amenazas y vulnerabilidades
reales.
El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de
interrupcin grave de los servicios.
Falta de coordinacin con la BCM.
Proceso
Las principales actividades de la Gestin de la Continuidad del Servicio se resumen en:
Establecer las polticas y alcance de la ITSCM.

Evaluar el impacto en el negocio de una interrupcin de los servicios TI.
Analizar y prever los riesgos a los que esta expuesto la infraestructura TI.
Establecer las estrategias de continuidad del servicio TI.
Adoptar medidas proactivas de prevencin del riesgo.
Desarrollar los planes de contingencia.
Poner a prueba dichos planes.
Formar al personal sobre los procedimientos necesarios para la pronta recuperacin
del servicio.
Revisar peridicamente los planes para adaptarlos a las necesidades reales del
negocio.
197
198
199
200
201
Poltica y Alcance
El primer paso necesario para desarrollar una Gestin de la Continuidad del Servicio
coherente es establecer claramente sus objetivos generales, su alcance y el compromiso de
la organizacin TI: su poltica.
La gestin de la empresa debe demostrar su implicacin con el proceso desde un primer
momento pues la implantacin de la ITSCM puede resultar compleja y costosa sin la
contrapartida de un retorno obvio a la inversin.
Es imprescindible establecer el alcance de la ITSCM en funcin de:
Los planes generales de Continuidad del Negocio.

Los servicios TI estratgicos.
Los estndares de calidad adoptados.
El histrico de interrupciones graves de los servicios TI.
Las expectativas de negocio.
La disponibilidad de recursos.
202

La Gestin de la Continuidad del Servicio est abocada al fracaso sino se destina una
cantidad de recursos suficientes, tanto en el plano humano como de equipamiento (software
y hardware). Su dimensin depende de su alcance y sera absurdo y contraproducente
instaurar una poltica demasiado ambiciosa que no dispusiera de los recursos
correspondientes.
Una importante parte del esfuerzo debe destinarse a la formacin del personal. ste debe
interiorizar su papel en momentos de crisis y conocer perfectamente las tareas que se espera
desempee: una emergencia no es el mejor momento para estudiar documentacin y
manuales.
Anlisis de Impacto
Una correcta Gestin de la Continuidad del Servicio requiere en primer lugar determinar
el impacto que una interrupcin de los servicios TI pueden tener en el negocio.
En la actualidad casi todas las empresas, grandes y pequeas, dependen en mayor o menor
medida de los servicios informticos, por lo que cabe esperar que un "apagn" de los
servicios TI afecte a prcticamente todos los aspectos del negocio. Sin embargo, es
evidente que hay servicios TI estratgicos de cuya continuidad puede depender la
supervivencia del negocio y otros que "simplemente" aumentan la productividad de la
fuerza comercial y de trabajo.
Cuanto mayor sea el impacto asociado a la interrupcin de un determinado servicio mayor
habr de ser el esfuerzo realizado en actividades de prevencin. En aquellos casos en que la
"solucin puede esperar" se puede optar exclusivamente por planes de recuperacin.
Los servicios TI han de ser analizados por la ITSCM en funcin de diversos parmetros:
Consecuencias de la interrupcin del servicio en el negocio:

o Prdida de rentabilidad.
o Prdida de cuota de mercado.
o Mala imagen de marca.
o Otros efectos secundarios.
Cunto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los
procesos de negocio.
Compromisos adquiridos a travs de los SLAs.
Dependiendo de estos factores se buscar un balance entre las actividades de prevencin y

recuperacin teniendo en cuenta sus respectivos costes financieros.

203
Evaluacin de Riesgos
Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es
imposible realizar una poltica de prevencin y recuperacin ante desastre mnimamente
eficaz.
La Gestin de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su
probabilidad e impacto, los diferentes riesgos factores de riesgo. Para ello la ITSCM debe:
Conocer en profundidad la infraestructura TI y cuales son los elementos de

configuracin (CIs) involucrados en la prestacin de cada servicio, especialmente
los servicios TI crticos y estratgicos.
Analizar las posibles amenazas y estimar su probabilidad.
Detectar los puntos ms vulnerables de la infraestructura TI.
Gracias a los resultados de este detallado anlisis se dispondr de informacin suficiente

para proponer diferentes medidas de prevencin y recuperacin que se adapten a las
necesidades reales del negocio.
La prevencin frente a riesgos genricos y poco probables puede ser muy cara y no estar
siempre justificada, sin embargo, las medidas preventivas o de recuperacin frente a riesgos
especficos pueden resultar sencillas, de rpida implementacin y relativamente baratas.
Por ejemplo, si el riesgo de perdida de alimentacin elctrica es elevado debido, por
ejemplo, a la localizacin geogrfica se puede optar por deslocalizar ciertos servicios TI a
travs de ISPs que dispongan de sistemas de generadores redundantes o adquirir
generadores que proporcionen la energa mnima necesaria para alimentar los CIs de los
que dependen los servicios ms crticos, etctera.
204

Estrategias
La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas,
que eviten la interrupcin de los servicios, o medidas reactivas, que recuperen unos niveles
aceptables de servicio en el menor tiempo posible.
Es responsabilidad de la Gestin de la Continuidad del Servicio disear actividades de
prevencin y recuperacin que ofrezcan las garantas necesarias a unos costes razonables.
Actividades preventivas
Las medidas preventivas requieren un detallado anlisis previo de riesgos y

vulnerabilidades. Algunos de ellos sern de carcter general: incendios, desastres naturales,
etctera, mientras que otros tendrn un carcter estrictamente informtico: fallo de sistemas
de almacenamiento, ataques de hackers, virus informticos, etctera.
La adecuada prevencin de los riesgos de carcter general dependen de una estrecha
colaboracin con la Gestin de la Continuidad del Negocio (BCM) y requieren medidas
que implican a la infraestructura "fsica" de la organizacin.
La prevencin de riesgos y vulnerabilidades "lgicas" o de hardware requieren especial
atencin de la ITSCM. En este aspecto es esencial la estrecha colaboracin con la Gestin
de la Seguridad.
Los sistemas de proteccin habituales son los de "Fortaleza" que ofrecen proteccin
perimetral a la infraestructura TI. Aunque imprescindibles no se hallan exentos de sus
propias dificultades pues aumentan la complejidad de la infraestructura TI y pueden ser a su
vez fuente de nuevas vulnerabilidades.
Actividades de recuperacin
Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevencin,
ser necesario poner en marcha procedimientos de recuperacin.
En lneas generales existen tres opciones de recuperacin del servicio:
"Cold standby": que requiere un emplazamiento alternativo en el que podamos

reproducir en pocos das nuestro entorno de produccin y servicio. Esta opcin es la
adecuada si los planes de recuperacin estiman que la organizacin puede mantener sus
niveles de servicio durante este periodo sin el apoyo de la infraestructura TI.
"Warm standby": que requiere un emplazamiento alternativo con sistemas activos
diseados para recuperar los servicios crticos en un plazo de entre 24 y 72 horas.
205
"Hot standby": que requiere un emplazamiento alternativo con una replicacin continua
de datos y con todos los sistemas activos preparados para la inmediata sustitucin de la
estructura de produccin. sta es evidentemente la opcin mas costosa y debe emplearse
slo en el caso de que la interrupcin del servicio TI tuviera inmediatas repercusiones
comerciales.
Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y esperar que las
aguas vuelvan naturalmente a su cauce: una alternativa poco recomendable para alguien
que est hojeando este curso sobre ITIL y del que suponemos que los servicios TI jugarn
un papel importante en su organizacin
Organizacin y Planificacin
Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y
definidas unas estrategias de prevencin y recuperacin es necesario asignar y organizar los
recursos necesarios. Con ese objetivo la Gestin de la Continuidad del Servicio debe
elaborar una serie de documentos entre los que se incluyen:
Plan de prevencin de riesgos.

Plan de gestin de emergencias.
Plan de recuperacin.
Plan de prevencin de riesgos
Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la

infraestructura TI.
Entre las medidas habituales se encuentran:
Almacenamiento de datos distribuidos.

Sistemas de alimentacin elctrica de soporte.
Polticas de back-ups.
Duplicacin de sistemas crticos.
Sistemas de seguridad pasivos.
Plan de gestin de emergencias
Las crisis suelen provocar "reacciones de pnico" que pueden ser contraproducentes y a
veces incluso ms dainas que las provocadas por el incidente que las causo. Por ello es
imprescindible que en caso de situacin de emergencia estn claramente determinadas las
responsabilidades y funciones del personal as como los protocolos de accin
correspondientes.
206

En principio los planes de gestin de emergencias deben tomar en cuenta aspectos tales
como:
Evaluacin del impacto de la contingencia en la infraestructura TI.

Asignacin de funciones de emergencia al personal de servicio TI.
Comunicacin a los usuarios y clientes de una grave interrupcin o degradacin del
servicio.
Procedimientos de contacto y colaboracin con los proveedores involucrados.
Protocolos para la puesta en marcha del plan de recuperacin correspondiente.
Plan de recuperacin
Cuando la interrupcin del servicio es inevitable llego el momento de poner en marcha los
procedimientos de recuperacin.
El plan de recuperacin debe incluir todo lo necesario para:
Reorganizar al personal involucrado.

Reestablecer los sistemas de hardware y software necesarios.
Recuperar los datos y reiniciar el servicio TI.
Los procedimientos de recuperacin pueden depender de la importancia de la contingencia

y de la opcin de recuperacin asociada ("cold o hot stand-by"), pero en general
involucran:
Asignacin de personal y recursos.

Instalaciones y hardware alternativos.
Planes de seguridad que garanticen la integridad de los datos.
Procedimientos de recuperacin de datos.
Contratos de colaboracin con otras organizaciones.
Protocolos de comunicacin con los clientes.
Cuando se pone en marcha un plan de recuperacin no hay espacio para la improvisacin,

cualquier decisin puede tener graves consecuencias tanto en la percepcin que de nosotros
tengan nuestros clientes como en los costes asociados al proceso.
Aunque pueda resultar paradjico, un "desastre" puede ser una buena oportunidad para
demostrar a nuestros clientes la solidez de nuestra organizacin TI y por tanto incrementar
la confianza que tiene depositada en nosotros. Ya conocen el dicho: "No hay mal que por
bien no venga".
Supervisin
207

Una vez establecidas las polticas, estrategias y planes de prevencin y recuperacin es
indispensable que estos no queden en papel mojado y que la organizacin TI est preparada
para su correcta implementacin.
Ello depende de dos factores clave: la correcta formacin del personal involucrado y la
continua monitorizacin y evaluacin de los planes para su adecuacin a las necesidades
reales del negocio.
Formacin
Es intil disponer de unos completos planes de prevencin y recuperacin si las personas

que eventualmente deben llevarlos a cabo no estn familiarizados con los mismos.
Es indispensable que la ITSCM:
De a conocer al conjunto de la organizacin TI los planes de prevencin y recuperacin.

Ofrezca formacin especfica sobre los diferentes procedimientos de prevencin y
recuperacin.
Realice peridicamente simulacros para diferentes tipos de desastres con el fin de
asegurar la capacitacin del personal involucrado.
Facilite el acceso permanente a toda la informacin necesaria, por ejemplo, a travs de la
Intranet o portal B2E de la empresa.
Actualizacin y auditoras
Tanto las polticas, estrategias y planes han de ser actualizados peridicamente para
asegurar que responden a los requisitos de la organizacin en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una
profunda revisin de los planes en vigor y una consecuente auditora que evale su
adecuacin a la nueva situacin.
En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable,
estos procesos de actualizacin y auditoria pueden establecerse de forma peridica.
La Gestin de Cambios juega un papel esencial en asegurar que los planes de recuperacin
y prevencin estn actualizados manteniendo informada a la ITSCM de los cambios
realizados o previstos.
Control del Proceso

208

La Gestin de la Continuidad del Servicio debe elaborar peridicamente informes sobre
su gestin que incluyan informacin relevante para el resto de la organizacin TI.
Estos informes deben incluir:
Anlisis sobre nuevos riesgos y evaluacin de su impacto.

Evaluacin de los simulacros de desastre realizados.
Actividades de prevencin y recuperacin realizadas.
Costes asociados a los planes de prevencin y recuperacin.
Preparacin y capacitacin del personal TI respecto a los planes y procedimientos
de prevencin y recuperacin.
Uno de los factores clave para el xito de la Gestin de la Continuidad del Servicio es
mantener la "concentracin". Tras largos periodos en los que la prevencin o, simple y
llanamente, la suerte han impedido la existencia de graves interrupciones del servicio se
puede caer en un relajamiento que puede acarrear graves consecuencias.
Por esto es imprescindible llevar controles rigurosos que impidan que la inversin y
compromiso inicial se diluyan y la ITSCM no est a la altura de la situacin cuando sus
servicios sean vitales para evitar que "un desastre se convierta en una catstrofe".
Pero si el control del proceso es importante en condiciones normales ste se vuelve crtico
durante las situaciones de crisis. La ITSCM debe garantizar:
La puesta en marcha de los planes preestablecidos.

La supervisin de los mismos.
La coordinacin con la Gestin de Continuidad del Negocio.
La asignacin de recursos necesarios.
Caso Prctico
La organizacin TI de "Cater Matters" carece de una Gestin de la Continuidad del
Servicio que merezca ese nombre.
La gestin de "Cater Matters" es consciente de la importancia que tienen en la actualidad
los servicios TI en toda su cadena de produccin y distribucin y pretende corregir esa
situacin.
De entre todos los servicios TI, los asociados a la gestin de existencias, por estar
compuestas de productos perecederos, y los servicios online de pedidos son considerados
de importancia estratgica por la direccin de la empresa. Por ello se decide que en primera
instancia la ITSCM debe garantizar la continuidad de dichos servicios en un plazo nunca
209

superior a las 8 horas mientras que se establecen objetivos menos ambiciosos para otros
servicios.
Se asigna a un ejecutivo senior del departamento TI el papel de gestor del proceso y se le
encarga coordinar todas las actividades con la Gestin de la Continuidad del Negocio.
La Gestin de la Continuidad del Negocio ha firmado acuerdos de colaboracin con otras
empresas de catering para suministros de emergencia que cubran los clientes ms
importantes:
Servicios de catering de colegios y hospitales.

Congresos y eventos multitudinarios de todo tipo.
La coordinacin en estos casos requiere el desarrollo de mdulos especiales que permitan

exportar las bases de datos de pedidos a formatos estndar de intercambio de datos para que
estos puedan ser procesados por las otras organizaciones.
Por otro lado, se desarrolla una aplicacin de gestin de emergencia de las existencias que
permite administrar los pedidos a los proveedores y preservar la integridad de las
existencias dependiendo de su informacin de caducidad y del impacto de la interrupcin
del negocio en las mismas.
Se establece asimismo:
Un calendario peridico de pruebas de los planes de recuperacin.

Un calendario de cursos de formacin sobre los protocolos de actuacin en situacin
de emergencia.
Pero la Gestin de la Continuidad del Servicio no slo debe aplicar medidas reactivas
que mitiguen el impacto de una eventual interrupcin del servicio, entre sus obligaciones se
encuentran la elaboracin de unos planes de prevencin que eviten dichas situaciones.
Para evitar interrupciones de sus servicios online la ITSCM:
Contrata servicios de "housing" con un proveedor que dispone de conexiones con

varios operadores al "backbone de Internet" y asegura alimentacin elctrica
interrumpida.
Replica los sistemas crticos en diferentes localizaciones geogrficas.
Supervisa la poltica de back-ups de los servidores de datos.
Instala sistemas de proteccin perimetral.
Gestin de la Disponibilidad
Visin General
210
Nuestras vidas, tanto personales como profesionales, dependen cada vez ms de la

tecnologa. sta nos permite acceder a la informacin y a los servicios a una
velocidad que ni siquiera podramos haber soado hace unos pocos aos.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad
absoluta de nuestros proveedores tecnolgicos. Con frecuencia una oferta diferente
slo se encuentra a un par de clics de distancia.
Por otro lado, el rpido desarrollo tecnolgico implica una constante renovacin de
equipos y servicios. Como proveedores nos enfrentamos al reto de evolucionar sin
apenas margen para el error pues nuestros sistemas han de encontrarse a disposicin
del cliente prcticamente 24/7.
La Gestin de la Disponibilidad es responsable de optimizar y monitorizar los
servicios TI para que estos funcionen ininterrumpidamente y de manera fiable,
cumpliendo los SLAs y todo ello a un coste razonable. La satisfaccin del cliente y
la rentabilidad de los servicios TI dependen en gran medida de su xito.
Las interacciones y funciones de la Gestin de la Disponibilidad se resumen
211
212
El objetivo primordial de la Gestin de la Disponibilidad es asegurar que los servicios TI
estn disponibles y funcionen correctamente siempre que los clientes y usuarios deseen
hacer uso de ellos en el marco de los SLAs en vigor.
Las responsabilidades de la Gestin de la Disponibilidad incluyen:
213
Determinar los requisitos de disponibilidad en estrecha colaboracin con los

clientes.
Garantizar el nivel de disponibilidad establecido para los servicios TI.
Monitorizar la disponibilidad de los sistemas TI.
Proponer mejoras en la infraestructura y servicios TI con el objetivo de aumentar
los niveles de disponibilidad.
Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos
y externos.
Los indicadores clave sobre los que se sustenta el proceso de Gestin de la Disponibilidad
se resumen en:
Disponibilidad: porcentaje de tiempo sobre el total acordado en que los servicios

TI han sido accesibles al usuario y han funcionado correctamente.
Fiabilidad: medida del tiempo durante el cual los servicios han funcionado
correctamente de forma ininterrumpida.
Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo en caso
de interrupcin.
Capacidad de Servicio: determina la disponibilidad de los servicios internos y
externos contratados y su adecuacin a los OLAs y UCs en vigor. Cuando un
servicio TI es subcontratado en su totalidad la disponibilidad y la capacidad de
servicio son trminos equivalentes.
214

La disponibilidad depende del correcto diseo de los servicios TI, la fiabilidad de los CIs
involucrados, su correcto mantenimiento y la calidad de los servicios internos y externos
acordados.
Los principales beneficios de una correcta Gestin de la Disponibilidad son:
Cumplimiento de los niveles de disponibilidad acordados.

Se reducen los costes asociados a un alto nivel de disponibilidad.
El cliente percibe una mayor calidad de servicio.
Se aumentan progresivamente los niveles de disponibilidad.
Se reduce el nmero de incidentes.
Las principales dificultades con las que topa la Gestin de la Disponibilidad son:
No se monitoriza correctamente la disponibilidad real del servicio.

No existe compromiso con el proceso dentro de la organizacin TI.
No se dispone de las herramientas de software y personal adecuado.
Los objetivos de disponibilidad no estn alineados con las necesidades del cliente.
Falta de coordinacin con los otros procesos.
Los proveedores internos y externos no reconocen la autoridad del Gestor de la
Disponibilidad por falta de apoyo de la direccin.
Proceso
Entre las actividades que la Gestin de la Disponibilidad se encuentran:
Determinar cuales son los requisitos de disponibilidad reales del negocio.

Desarrollar un plan de disponibilidad donde se estimen las necesidades de
disponibilidad futura a corto y medio plazo.
Mantenimiento del servicio en operacin y recuperacin del mismo en caso de fallo.
Realizar diagnsticos peridicos sobre la disponibilidad de los sistemas y servicios.
Evaluar la capacidad de servicio de los proveedores internos y externos.
Monitorizar la disponibilidad de los servicios TI.
Elaborar informes de seguimiento con la informacin recopilada sobre
disponibilidad, fiabilidad, matenibilidad y cumplimiento de OLAs y UCs.
Evaluar el impacto de las polticas de seguridad en la disponibilidad.
Asesorar a la Gestin del Cambio sobre el posible impacto de un cambio en la
disponibilidad.
215
216
217
218
219
220
221
Requisitos de Disponibilidad
Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboracin de
los SLAs.
La disponibilidad propuesta debe encontrase en lnea tanto con los necesidades reales del
negocio como con las posibilidades de la organizacin TI.
Aunque en principio todos los clientes estarn de acuerdo con unas elevadas cotas de
disponibilidad es importante hacerles ver que una alta disponibilidad puede generar unos
costes injustificados dadas sus necesidades reales. Quiz unas pocas horas sin un
determinado servicio pueden representar poco ms all de una pequea inconveniencia
mientras que la certeza de un servicio prcticamente continuo y sin interrupciones puede
requerir la replicacin de sistemas u otras medidas igualmente costosas que no van a tener
una repercusin real en la rentabilidad del negocio.
222

Para llevar a cabo eficientemente est tarea es necesario que la Gestin de la
Disponibilidad:
Identifique las actividades clave del negocio.

Cuantifique los intervalos razonables de interrupcin de los diferentes servicios
dependiendo de sus respectivos impactos.
Establezca los protocolos de mantenimiento y revisin de los servicios TI.
Determine las franjas horaria de disponibilidad de los servicios TI (24/7, 12/5, ...).
Planificacin
La correcta planificacin de la disponibilidad permite establecer unos niveles de
disponibilidad adecuados tanto en lo que respecta a las necesidades reales del negocio
como a las posibilidades de la organizacin TI.
El documento que debe recoger los objetivos de disponibilidad presentes y futuros y que
medidas son necesarias para su cumplimiento es el Plan de Disponibilidad.
Este plan debe recoger:
La situacin actual de disponibilidad de los servicios TI. Obviamente esta informacin debe
ser actualizada peridicamente.
Herramientas para la monitorizacin de la disponibilidad.
Mtodos y tcnicas de anlisis a utilizar.
Definiciones relevantes y precisas de las mtricas a utilizar.
Planes de mejora de la disponibilidad.
Expectativas futuras de disponibilidad.
Es imprescindible que este plan proponga los cambios necesarios para que se cumplan los
estndares previstos y colabore con la Gestin de Cambios y la Gestin de Versiones en
su implementacin (en caso de ser aprobados, claro est).
Para que este plan sea realista debe contar con la colaboracin de los otros procesos TI
involucrados.
Diseo para la Disponibilidad
Es crucial para una correcta Gestin de la Disponibilidad participar desde el inicio en el

desarrollo de los nuevos servicios TI de forma que estos cumplan los estndares plasmados
en el Plan de Disponibilidad.
223

Un diferente nivel de disponibilidad puede requerir cambios drsticos en los recursos
utilizados o en las actividades necesarias para suministrar un determinado servicio TI. Si
ste se disea sin tener en cuenta futuras necesidades de disponibilidad puede ser necesario
un completo rediseo al cabo de poco tiempo, incurriendo en costes adicionales
innecesarios.
Mantenimiento y Seguridad
Aunque hayamos realizado un correcto diseo de los servicios segn el Plan de
Disponibilidad y se hayan tomado todas las medidas preventivas necesarias, tarde o
temprano, nos habremos de enfrentar a interrupciones del servicio.
En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto
indeseado sobre los niveles de disponibilidad acordados.
Aunque la responsabilidad de restaurar el servicio corresponde a la Gestin de Incidentes
y las actividades de recuperacin han de ser coordinadas por el Service Desk, la Gestin
de la Disponibilidad debe prestar su asesoramiento mediante planes de recuperacin que
tengan en cuenta:
Las necesidades de disponibilidad del negocio.

Las implicaciones del incidente en la infraestructura TI y los procesos necesarios para
restaurar el servicio.
Gestin de las Interrupciones de Mantenimiento
Independientemente de las interrupciones del servicio causadas por incidencias es

habitualmente necesario interrumpir el servicio para realizar labores de mantenimiento y/o
actualizacin.
Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo
tanto han de ser cuidadosamente planificadas para minimizar su impacto.
En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea
posible, deben aprovecharse las franjas horarias de inactividad para realizar las tareas que
implican una degradacin o interrupcin del servicio.
Si el servicio es 24/7 y la interrupcin es necesaria se debe:
Consultar con el cliente en que franja horaria la interrupcin del servicio afectar menos a
sus actividades de negocio.
Informar con la antelacin suficiente a todos los agentes implicados.
224
Incorporar dicha informacin a los SLAs.
Seguridad
Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es
una correcta Gestin de la Seguridad.
Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del
proceso.
Es tan importante determinar cundo el servicio estar disponible como el "quin y cmo"
va a utilizarlo. La disponibilidad y seguridad son interdependientes y cualquier fallo en
una de ellas afectar gravemente a la otra.
Monitorizacin de la Disponibilidad
La monitorizacin de la disponibilidad del servicio y la elaboracin de los informes
correspondientes son dos de las principales actividades de la Gestin de la Disponibilidad.
Desde el momento de la interrupcin del servicio hasta su restitucin o "tiempo de parada"
el incidente pasa por distintas fases que deben ser individualizadamente analizadas:
Tiempo de deteccin: es el tiempo que transcurre desde que ocurre el fallo hasta
que la organizacin TI tiene constancia del mismo.
Tiempo de respuesta: es el tiempo que transcurre desde la deteccin del problema
hasta que se realiza un registro y diagnstico del incidente.
Tiempo de reparacin/recuperacin: periodo de tiempo utilizado para reparar el
fallo o encontrar un "workaround" o solucin temporal al mismo y devolver el
sistema a la situacin anterior a la interrupcin del servicio.
Es importante determinar mtricas que permitan medir con precisin las diferentes fases del
ciclo de vida de la interrupcin del servicio. El cliente debe conocer estas mtricas y dar su
225

conformidad a las mismas para evitar malentendidos. En algunos casos es difcil determinar
si el sistema est "cado o en funcionamiento" y la interpretacin puede diferir entre
proveedores y clientes, por lo tanto, ests mtricas deben de poder expresarse en trminos
que el cliente pueda entender.
Algunos de los parmetros que suele utilizar la Gestin de la Disponibilidad y que debe
poner a disposicin del cliente en los informes de disponibilidad correspondientes incluyen:
Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duracin de

una interrupcin de servicio, e incluye el tiempo de deteccin, respuesta y
resolucin.
Tiempo Medio entre Fallos (Uptime): es el tiempo medio durante el cual el
servicio esta disponible sin interrupciones.
Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre incidentes
que es igual a la suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos.
El Tiempo Medio entre Incidentes es una medida de la fiabilidad del sistema.
Mtodos y Tcnicas
Aunque llevamos hablando ya un buen rato de disponibilidad an no hemos aportado un
mtodo para cuantificarla.
Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera:
donde:
AST se corresponde con el tiempo acordado de servicio, DT es el tiempo de interrupcin
del servicio durante las franjas horarias de disponibilidad acordadas.
Por ejemplo, si el servicio es 24/7 y en el ltimo mes el sistema ha estado cado durante 4
horas por tareas de mantenimiento la disponibilidad real del servicio fue:
226

La Gestin de la Disponibilidad tiene a su disposicin un buen nmero de mtodos y
tcnicas que le permiten determinar que factores intervienen en la disponibilidad del
servicio y que le permiten consecuentemente prever que tipo de recursos se deben asignar
para las labores de prevencin, mantenimiento y recuperacin, as como elaborar planes de
mejora a partir de dichos anlisis.
Entre dichas tcnicas se cuentan:
CFIA
Que son las siglas de Component Failure Impact Analysis (Anlisis del Impacto de Fallo
de Componentes).
Mediante est metodo se identifica el impacto que tiene en la disponibilidad de los servicios
TI el fallo de cada elemento de configuracin involucrado. Es evidente que este mtodo
requiere una CMDB correctamente actualizada.
FTA
Que son las siglas de Failure Tree Analysis (Anlisis del rbol de Fallos).
Su objetivo es estudiar como se "propagan" los fallos a traves de la infraestructura TI para
comprender mejor su impacto en la disponibilidad del servicio.
CRAMM
Que son las siglas de CCTA Risk Analysis and Management Method (Mtodo de Gestin
y Anlisis de Riesgos de la CCTA).
Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta la
infraestructura TI con el objetivo de adoptar contramedidas que los reduzcan o que
permitan recuperar rpidamente el servicio en caso de interrupcin del mismo.
SOA
Que son las siglas de Service Outage Analysis (Anlisis de Interrupcin del Servicio).
sta tcnica tiene como objetivo analizar las causas de los fallos detectados y proponer
soluciones a los mismos.
Se diferencia de los anteriores mtodos en que realiza el anlisis desde el punto de vista del
cliente haciendo especial nfasis en aspectos no exclusivamente tcnicos ligados
directamente a la infraestructura TI.
227
Control del Proceso

La Gestin de la Disponibilidad debe elaborar peridicamente informes sobre su gestin
que incluyan informacin relevante tanto para los clientes como para el resto de la
organizacin TI.
Estos informes deben incluir:
Tcnicas y mtodos utilizados para la prevencin y el anlisis de fallos.

Informacin estadstica sobre:
o Tiempos de deteccin y respuesta a los fallos.
o Tiempos de reparacin y recuperacin del servicio.
o Tiempo medio de servicio entre fallos.
Disponibilidad real de los diferentes servicios.
Cumplimiento de los SLAs en todo lo referente a la disponibilidad y fiabilidad del
servicio.
Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de servicio
prestada por los proveedores internos y externos.
Para que toda esta informacin sea fcil y correctamente analizada es imprescindible el
establecimiento de mtricas precisas que permitan determinar de forma inequvoca
parmetros tales como tiempos de parada y funcionamiento. Por ejemplo, en el caso de un
servicio online de comercio electrnico se puede considerar que tiempos de respuesta
superiores a 10 segundos son equivalentes a que el sistema esta cado, aunque estrictamente
hablando el sistema termine respondiendo.
Caso Prctico
La disponibilidad 12/7 es algo a lo que los clientes de "Cater Matters" otorgan una gran
importancia.
Los servicios TI slo juegan una pequea, aunque importante, parte en los servicios
prestados por la organizacin a sus clientes y los problemas de disponibilidad suelen
proceder de procesos no directamente ligados con la tecnologa. Sin embargo, una
interrupcin de los servicios online pueden presuponer un grave problema dado el alto
volumen de pedidos que se reciben por dicho canal, la prctica totalidad, as como su
importancia en el apartado de la gestin de stocks de materia prima.
La Gestin de la Disponibilidad, en colaboracin con los responsables de otros procesos
TI ha sido encargada de elaborar nuevos planes de disponibilidad que tengan en cuenta un
228

rpido crecimiento del negocio que puede implicar una disponibilidad 24/7 para diferentes
lneas de negocio.
La elaboracin de este nuevo plan requiere:
La revisin de los UCs en vigor con los proveedores de servicios de Internet.

Definicin de niveles de disponibilidad para los nuevos servicios.
Diseo para la disponibilidad 24/7 de los servicios TI ofrecidos.
Nuevos planes de gestin del mantenimiento que ahora requerirn una interrupcin
real del servicio.
Por otro lado, la gestin de "Cater Matters" ha decidido informar peridicamente a sus
clientes sobre los niveles de rendimiento y disponibilidad de los diferentes servicios
prestados. Para ello ha encargado a la Gestin de la Disponibilidad que implante los
procedimientos necesarios para la medicin del:
Tiempo transcurrido entre incidentes.

Tiempo de parada del servicio.
Tiempo de respuesta para cada incidente.
Retraso en el la entrega del servicio.
Que se complementarn con un mdulo de clculo estadstico y de generacin automtica

de informes sobre el cumplimiento de los niveles de disponibilidad acordados para cada
cliente.
De esta forma "Cater Matters" busca entablar una relacin de confianza con sus clientes y
mantener a la organizacin TI alerta sobre posibles degradaciones de los niveles de calidad
del servicio.
Gestin de la Seguridad
Visin General
La Gestin de la Seguridad de la Informacin se remonta al albor de los tiempos. La
criptologa o la ciencia de la confidencialidad de la informacin se remonta al inicio de
nuestra civilizacin y ha ocupado algunas de las mentes matemticas ms brillantes de la
historia, especialmente (y desafortunadamente) en tiempos de guerra.
Sin embargo, desde el advenimiento de la ubicuas redes de comunicacin y en especial
Internet los problemas asociados a la seguridad de la informacin se han agravado
considerablemente y nos afectan prcticamente a todos. Que levante la mano el que no haya
sido victima de algn virus informtico en su ordenador, del spam (ya sea por correo
electrnico o telfono) por una deficiente proteccin de sus datos personales o, an peor,
del robo del nmero de su tarjeta de crdito.
229

La informacin es consustancial al negocio y su correcta gestin debe apoyarse en tres
pilares fundamentales:
Confidencialidad: la informacin debe ser slo accesible a sus destinatarios

predeterminados.
Integridad: la informacin debe ser correcta y completa.
Disponibilidad: debemos de tener acceso a la informacin cuando la necesitamos.
La Gestin de la Seguridad debe, por tanto, velar por que la informacin sea correcta y
completa, est siempre a disposicin del negocio y sea utilizada slo por aquellos que
tienen autorizacin para hacerlo.
Las interacciones y funciones de la Gestin de la Seguridad se resumen sucintamente en
el siguiente interactivo:
230
231
Los principales objetivos de la Gestin de la Seguridad se resumen en:
Disear una poltica de seguridad, en colaboracin con clientes y proveedores

correctamente alineada con las necesidades del negocio.
Asegurar el cumplimiento de los estndares de seguridad acordados.
Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.
232

La correcta Gestin de la Seguridad no es responsabilidad (exclusiva) de "expertos en
seguridad" que desconocen los otros procesos de negocio. Si caemos en la tentacin de
establecer la seguridad como una prioridad en s misma limitaremos las oportunidades de
negocio que nos ofrece el flujo de informacin entre los diferentes agentes implicados y la
apertura de nuevas redes y canales de comunicacin.
La Gestin de la Seguridad debe conocer en profundidad el negocio y los servicios que
presta la organizacin TI para establecer protocolos de seguridad que aseguren que la
informacin est accesible cuando se necesita por aquellos que tengan autorizacin para
utilizarla.
Una vez comprendidos cuales son los requisitos de seguridad del negocio, la Gestin de la
Seguridad debe supervisar que estos se hallen convenientemente plasmados en los SLAs
correspondientes para, a rengln seguido, garantizar su cumplimiento.
La Gestin de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que
est expuesta la infraestructura TI, y que no necesariamente tienen porque figurar en un
SLA, para asegurar, en la medida de lo posible, que no representan un peligro para la
continuidad del servicio.
Es importante que la Gestin de la Seguridad sea proactiva y evale a priori los riesgos de
seguridad que pueden suponer los cambios realizados en la infraestructura, nuevas lneas de
negocio, etctera.
233
Los principales beneficios de una correcta Gestin de la Seguridad:
Se evitan interrupciones del servicio causadas por virus, ataques informticos,

etctera.
Se minimiza el nmero de incidentes.
Se tiene acceso a la informacin cuando se necesita y se preserva la integridad de
los datos.
Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios.
Se cumplen los reglamentos sobre proteccin de datos.
Mejora la percepcin y confianza de clientes y usuarios en lo que respecta a la
Las principales dificultades a la hora de implementar la Gestin de la Seguridad se

resumen en:
234
No existe el suficiente compromiso de todos los miembros de la organizacin TI

con el proceso.
Se establecen polticas de seguridad excesivamente restrictivas que afectan
negativamente al negocio.
No se dispone de las herramientas necesarias para monitorizar y garantizar la
seguridad del servicio (firewalls, antivirus, ...).
El personal no recibe una formacin adecuada para la aplicacin de los protocolos
de seguridad.
Falta de coordinacin entre los diferentes procesos lo que impide una correcta
evaluacin de los riesgos.
Proceso
La Gestin de la Seguridad esta estrechamente relacionada con prcticamente todos los
otros procesos TI y necesita para su xito la colaboracin de toda la organizacin.
Para que esa colaboracin sea eficaz es necesario que la Gestin de la Seguridad:
Establezca una clara y definida poltica de seguridad que sirva de gua a todos los
otros procesos.
Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados
tanto en los servicios prestados a los clientes como en los acuerdos de servicio
firmados con proveedores internos y externos.
Implemente el Plan de Seguridad.
Monitorice y evale el cumplimiento de dicho plan.
Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos
riesgos y vulnerabilidades.
Realice peridicamente auditoras de seguridad.
235
236
237
238
239
240
241
242
243
244
245
Poltica de Seguridad
Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos
asociados a la Gestin de la Seguridad. Su complejidad e intricadas interrelaciones
necesitan de una poltica global clara en donde se fijen aspectos tales como los objetivos,
responsabilidades y recursos.
En particular la Poltica de Seguridad debe determinar:
La relacin con la poltica general del negocio.

La coordinacin con los otros procesos TI.
Los protocolos de acceso a la informacin.
Los procedimientos de anlisis de riesgos.
Los programas de formacin.
El nivel de monitorizacin de la seguridad.
Qu informes deben ser emitidos peridicamente.
El alcance del Plan de Seguridad.
246
La estructura y responsables del proceso de Gestin de la Seguridad.

Los procesos y procedimientos empleados.
Los responsables de cada subproceso.
Los auditores externos e internos de seguridad.
Los recursos necesarios: software, hardware y personal.
Plan de Seguridad
El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos
como parte de los SLAs, OLAs y UCs.
Este plan ha de ser desarrollado en colaboracin con la Gestin de Niveles de Servicio que
es la responsable en ltima instancia tanto de la calidad del servicio prestado a los clientes
como la del servicio recibido por la propia organizacin TI y los proveedores externos.
El Plan de Seguridad debe disearse para ofrecer un mejor y ms seguro servicio al cliente
y nunca como un obstculo para el desarrollo de sus actividades de negocio.
Siempre que sea posible deben definirse mtricas e indicadores clave que permitan evaluar
los niveles de seguridad acordados.
Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad
coherentes en todas las fases del servicio y para todos los estamentos implicados. "Una
cadena es tan resistente como el ms dbil de sus eslabones", por lo que carece de sentido,
por ejemplo, establecer una estrictas normas de acceso si una aplicacin tiene
vulnerabilidades frente a inyecciones de SQL. Quiz con ello podamos engaar a algn
cliente durante algn tiempo ofreciendo la imagen de "fortaleza" pero esto valdr de poco si
alguien descubre que la "puerta de atrs est abierta".
Aplicacin de las Medidas de Seguridad

Por muy buena que sea la planificacin de la seguridad resultar intil si las medidas
previstas no se ponen en prctica.
Es responsabilidad de la Gestin de Seguridad coordinar la implementacin de los
protocolos y medidas de seguridad establecidas en la Poltica y el Plan de Seguridad.
En primer lugar la Gestin de la Seguridad debe verificar que:
El personal conoce y acepta las medidas de seguridad establecidas as como sus

responsabilidades al respecto.
247
Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo

y responsabilidad.
Se imparte la formacin pertinente.
Es tambin responsabilidad directa de la Gestin de la Seguridad:
Asignar los recursos necesarios.

Generar la documentacin de referencia necesaria.
Colaborar con el Service Desk y la Gestin de Incidentes en el tratamiento y
resolucin de incidentes relacionados con la seguridad.
Instalar y mantener las herramientas de hardware y software necesarias para
garantizar la seguridad.
Colaborar con la Gestin de Cambios y Versiones para asegurar que no se
introducen nuevas vulnerabilidades en los sistemas en produccin o entornos de
pruebas.
Proponer RFCs a la Gestin de Cambios que aumenten los niveles de seguridad.
Colaborar con la Gestin de la Continuidad del Servicio para asegurar que no
peligra la integridad y confidencialidad de los datos en caso de desastre.
Establecer las polticas y protocolos de acceso a la informacin.
Monitorizar las redes y servicios en red para detectar intrusiones y ataques.
Es necesario que la gestin de la empresa reconozca la autoridad de la Gestin de la

Seguridad respecto a todas estas cuestiones y que incluso permita que sta proponga
medidas disciplinarias vinculantes cuando los empleados u otro personal relacionado con la
seguridad de los servicios incumpla con sus responsabilidades.
Evaluacin y Mantenimiento
Evaluacin
No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el

cumplimiento de las medidas de seguridad, sus resultados y el cumplimiento de los SLAs.
Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen
con auditoras de seguridad externas y/o internas realizadas por personal independiente de
la Gestin de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras
que se plasmaran en RFCs que habrn de ser evaluados por la Gestin de Cambios.
Independientemente de estas evaluaciones de carcter peridico se debern generar
informes independientes cada vez que ocurra algn incidente grave relacionado con la
248

seguridad. De nuevo, si la Gestin de la Seguridad lo considera oportuno, estos informes se
acompaaran de las RFCs correspondientes.
Mantenimiento
La Gestin de la Seguridad es un proceso continuo y se han de mantener al da el Plan de

Seguridad y las secciones de seguridad de los SLAs.
Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluacin
arriba citada o de cambios implementados en la infraestructura o servicios TI.
No hay nada ms peligroso que la falsa sensacin de seguridad que ofrecen medidas de
seguridad obsoletas.
Es asimismo importante que la Gestin de la Seguridad est al da en lo que respecta a
nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de denegacin de
servicio, etctera, y que adopte las medidas necesarias de actualizacin de equipos de
hardware y software, sin olvidar el apartado de formacin: el factor humano es
normalmente el eslabn ms dbil de la cadena.
Control del Proceso

Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso
para asegurar que la Gestin de la Seguridad cumple sus objetivos.
Una buena Gestin de la Seguridad debe traducirse en una:
Disminucin del nmero de incidentes relacionados con la seguridad.

Un acceso eficiente a la informacin por el personal autorizado.
Gestin proactiva que permita identificar vulnerabilidades potenciales antes de que
estas se manifiesten y provoquen una seria degradacin de la calidad del servicio.
La correcta elaboracin de informes permite evaluar el rendimiento de la Gestin de

Seguridad y aporta informacin de vital importancia a otras reas de la infraestructura TI.
Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de

los SLAs, OLAs y UCs en vigor.
Relacin de incidentes relacionados con la seguridad calificados por su impacto
sobre la calidad del servicio.
Evaluacin de los programas de formacin impartidos y sus resultados.
249
Identificacin de nuevos peligros y vulnerabilidades a las que se enfrenta la

infraestructura TI.
Auditoras de seguridad.
Informes sobre el grado de implementacin y cumplimiento de los planes de
seguridad establecidos.
Caso Prctico
La gestin de "Cater Matters" es consciente que un enfoque sobre la seguridad basado
exclusivamente en el concepto de "fortificacin frente a ataques" no se corresponde con las
necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a informacin actualizada
sobre sus pedidos, pagos pendientes, etctera y eso requiere la interaccin con el ERP de la
empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse
canales al exterior desde el ncleo TI de la organizacin.
La direccin de "Cater Matters" ha decidido crear una serie de Web Services que permitan
el acceso a dicha informacin preservando su confidencialidad e integridad. Esto requiere
la revisin del Plan de Seguridad y las secciones de seguridad de los SLAs en vigor.
Como medidas de seguridad bsicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Slo IPs autorizadas de
clientes podrn disponer del servicio.
Se implementan protocolos de encriptacin de los archivos XML intercambiados.
Se requiere autenticacin para el acceso al servicio.
Se monitoriza la interaccin con la aplicacin para detectar posibles ataques
externos.
Se guarda un registro de uso: quin, cundo y cmo utiliz la aplicacin.
Se autoriza un solo canal de entrada a los servidores locales a travs de los
servidores web de la empresa.
Se propone una evaluacin peridica del servicio con el objetivo de detectar

vulnerabilidades y adoptar medidas correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los
clientes en un tiempo de rpido desarrollo en el que la competencia se encuentra a un "solo
clic de distancia".
250

Fundamentos de La Gestión TI

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Fundamentos de La Gestión TI

Загружено:

Авторское право:

Доступные форматы

Lic.

Jos Antonio Snchez Montero Data & Tecnologa

Proporcionar una adecuada gestin de la calidad

Un enfoque sistemtico del servicio TI centrado en los procesos y procedimientos

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologas de la

Lic. Jos Antonio Snchez Montero Data & Tecnologa

ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Provisin del Servicio

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Lic. Jos Antonio Snchez Montero Data & Tecnologa

El ITSMF es el nico Forum completamente indpendiente reconocido por el sector de la

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Foundation Certificate en Gestin de Servicios TI

El sistema de certificacin est basado en los requisitos para representar eficazmente el

http://www.itil.co.uk -El Sitio Oficial de ITIL

Gestin de Servicios TI: Caso Prctico

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Servicios de comedor de grandes empresas.

Creacin de un Service Desk o Centro de Servicios que centralice todas las

Centro de servicios (Service Desk)

Registrando y monitorizando incidentes.

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Aplicando soluciones temporales a errores conocidos en colaboracin con la

Centro de servicios (Service Desk)

Resolver rpidamente las interrupciones del servicio.

El punto de contacto con el cliente puede tomar diversas formas dependiendo de la

Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Reduccin de costes mediante una eficiente asignacin de recursos.

Centro de servicios (Service Desk)

Cules son las necesidades.

Adems de estas cuestiones de carcter tcnico, es imprescindible ponderar otros aspectos

Establecer estrictos protocolos de interaccin con el cliente.

El objetivo NO es implementar lo ms rpidamente posible un Centro de Servicios sino

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Centro de servicios (Service Desk)

Sea fcilmente accesible.

Para cumplir estos objetivos es necesario implementar la adecuada estructura fsica y

Los integrantes del Centro de Servicios deben:

Conocer todos los protocolos de interaccin con el cliente: guiones, checklists,...

Describimos a continuacin sus principales caractersticas:

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Se reducen los costes.

Sin embargo surgen importantes inconvenientes cuando:

Los usuarios se encuentran en diversos emplazamientos geogrficos: diferentes idiomas,

Service Desk Distribuido

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Service Desk Virtual

El "conocimiento" est centralizado.

Lic. Jos Antonio Snchez Montero Data & Tecnologa

La calidad del servicio es homognea y consistente.

Centro de servicios (Service Desk)

Lic. Jos Antonio Snchez Montero Data & Tecnologa

Independientemente de que la completa gestin de las incidencias requiera la colaboracin

Registro y monitorizacin de cada incidente.

El Centro de Servicios es asimismo responsable de la relacin con los proveedores de

Centro de servicios (Service Desk)

Lic. Jos Antonio Snchez Montero Data & Tecnologa