Itil

ITIL
Gestión de Servicios TI
Fuente de contenidos principal: http://itil.osiatis.es
ITIL – Gestión de Servicios TI Página 1 de 151

ITIL – Gestión de Servicios TI
Índice de Contenidos
Fundamentos de la Gestión TI 4
Visión General 4
ITIL 5
Soporte al Servicio 6
Provisión del Servicio 7
Forum ITSMF 8
Certificaciones ITIL 9
Caso Práctico 10
Centro de Servicios 11
Visión General 11
Introducción y Objetivos 12
Implementación 13
Estructura 14
Funciones 17
Equipo y Formación 18
Control Centro de Servicios 19
Caso Práctico 20
Gestión de Incidentes 21
Visión General 21
Clasificación y Registro 24
Escalado 25
Proceso 26
Registro y Clasificación 27
Análisis, Resolución y Cierre 28
Control del Proceso 29
Caso Práctico 30
Gestión de Problemas 31
Visión General 31
Proceso 34
Control de Problemas 35
Control de Errores 37
Caso Práctico 40
Gestión de Configuraciones 41
Visión General 41
Definiciones 43
Proceso 44
Planificación 45
Clasificación y Registro 46
Monitorización 48
Control 49
Auditorías 50
Caso Práctico 52
Gestión de Cambios 53
Visión General 53
Conceptos Básicos 56
Proceso 58
Registro 59
Aceptación y Clasificación 61
Aprobación y Planificación 62
Implementación 63
Evaluación 64
Emergencias 65
Caso Práctico 67
Gestión de Versiones 69
Visión General 69
Proceso 74
Planificación 75
Desarrollo 76

Validación 77
Implementación 78
Comunicación y Formación 79
Caso Práctico 81
Gestión de Niveles de Servicio 82
Visión General 82
Proceso 87
Planificación 88
Implementación 90
Monitorización 91
Revisión 92
Caso Práctico 94
Gestión Financiera 96
Visión General 96
Proceso 100
Presupuestos 102
Contabilidad 103
Política de Precios 104
Supervisión 105
Caso Práctico 107
Gestión de la Capacidad 108
Visión General 108
Proceso 111
Planificación 112
Recursos 113
Supervisión 114
Gestión de la Demanda 115
Caso Práctico 117
Gestión de la Continuidad del Servicio 118
Visión General 118
Proceso 120
Política y Alcance 121
Análisis de Impacto 122
Evaluación de Riesgos 123
Estrategias de Continuidad 124
Organización y Planificación 125
Supervisión 127
Caso Práctico 129
Gestión de la Disponibilidad 130
Visión General 130
Proceso 133
Requisitos 134
Planificación 135
Mantenimiento y Seguridad 136
Monitorización 137
Métodos y Técnicas 138
Caso Práctico 140
Gestión de la Seguridad 141
Visión General 141
Proceso 144
Política y Plan de Seguridad 145
Aplicación de las Medidas de Seguridad 146
Evaluación y mantenimiento 147
Caso Práctico 149

Fundamentos de la Gestión TI
Gestión de Servicios TI
Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la
misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido
en una herramienta imprescindible y clave para empresas e instituciones.
La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera
ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una
herramienta más entre muchas otras.
Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran
equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la
organización pero poco más.
Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los
procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de
ejemplo la Banca Electrónica.
Los objetivos de una buena gestión de servicios TI han de ser:
• Proporcionar una adecuada gestión de la calidad

• Aumentar la eficiencia
• Alinear los procesos de negocio y la infraestructura TI
• Reducir los riesgos asociados a los Servicios TI
• Generar negocio
ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:
• Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos

• El establecimiento de estrategias para la gestión operativa de la infraestructura TI

¿Qué es ITIL?
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido

en el estándar mundial de de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de
UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por
innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es
conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus
objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios
informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las
expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la
gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar
los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias,
es soportado por los procesos de mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del
coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes
de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a
cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados,
con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta
calidad, y de coste aceptable.
ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las dos principales áreas
de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros
complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del
negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado
para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han

agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y
mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.
Soporte al Servicio
El soporte al servicio se preocupa de de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del
servicio prestado al usuario.
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporte al servicio
según los estándares ITIL:

Provisión del Servicio
La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles de servicio, su
disponibilidad,su continuidad, su viabilidad financiera, la capacidad necesaria de la infraestructura TI y los niveles de
seguridad requeridos
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de provisión del
servicio según los estándares ITIL:

Forum ITSMF
El ITSMF es el único Forum completamente indpendiente reconocido por el sector

de la Gestión de Servicios Informáticos. Esta asociación, con fines no lucrativos,
juega un papel predominante en el desarrollo y promoción de un código de Mejores
Prácticas para la gestión de estos servicios.
En la actualidad, las empresas dependen cada vez en mayor medida de la tecnología para la promoción y distribución de
sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares que permitan la correcta gestión
de los procesos informáticos asociados.
El objetivo del ITSMF es organizar una red de expertos en Gestión de Servicios Informáticos, ofrecer completa
información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas
que puedan encontrar en este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos servicios
gracias a la utilización de un código de Mejores Prácticas.
Más de 1000 compañias, grandes corporaciones y empresas públicas de todo el mundo pertenecen al ITSMF. Osiatis es
en la actualidad una de las empresa responsables de las actividades del Forum en España y Francia (Claude Durand,
Director de Desarrollo de Osiatis Francia, es tesorero de la asociación en ese país).

Certificaciones ITIL
EXIN e ISEB
La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems Examination Board"
(ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fue realizado en estrecha cooperación
con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de
certificaciones en tres niveles:
• Foundation Certificate en Gestión de Servicios TI

• Practitioner Certificate en Gestión de Servicios TI
• Manager Certificate en Gestión de Servicios TI
El sistema de certificación está basado en los requisitos para representar eficazmente el papel pertinente dentro de una
organización TI. Hasta la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30
países.
Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI. El marco de mejores
prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones, herramientas, servicios de
educación y consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, se considera a ITIL como el
marco de trabajo y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad
de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como
un estándar de facto para la Gestión de Servicios TI.
Enlaces de interés
Podréis encontrar información adicional en:
• http://www.itil.co.uk -El Sitio Oficial de ITIL

• http://www.exin.nl -Organismo de Certificación
• http://www.itsmf.com -Forum Internacional de Gestión de Servicios TI
• http://www.extensionsa.cl – Compañía Chilena de administración de Servicios de Negocios

Gestión de Servicios TI: Caso Práctico
Para mejor ilustrar los contenidos de este "curso" cada capítulo incluye un caso práctico relacionado directamente con los
contenidos del mismo.
Todos estos casos prácticos se refieren a una compañía (ficticia) dedicada al catering, "Cater Matters", que ha optado por
introducir la metodología ITIL para la gestión de sus servicios.
"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:
• Servicios de comedor de grandes empresas.

• Servicios de catering para colegios.
• Servicios de catering para eventos (congresos, actos institucionales, ...).
• Servicios de restauración para hoteles.
La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de
entrega.
Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le
permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción
y distribución.
La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL
como la base de todos sus procesos y servicios. Entre las decisiones adoptadas consecuentemente caben destacar:
• Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes
y el resto de la infraestructura TI.
• Organización de sus actividades en torno a los procesos.
• Designación de responsables o gestores para cada uno de los procesos críticos.
• Establecimiento de estrictos protocolos de monitorización de la calidad del servicio.

Centro de servicios (Service Desk)
Visión General
El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los los usuarios y
la Gestión de Servicios TI.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos
de soporte al servicio:
• Registrando y monitorizando incidentes.

• Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.
• Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos
correspondientes.
• Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la
Gestión de Cambios y Versiones
Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus
contactos con usuarios y clientes.

Introducción y Objetivos
Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e
independiente de su localización geográfica.
Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que estan recibiendo una atención
personalizada y ágil que les ayude a:
• Resolver rápidamente las interrupciones del servicio.

• Emitir peticiones de servicio.
• Informarse sobre el cumplimiento de los SLAs.
• Recibir información comercial en primera instancia.
El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los
servicios ofrecidos:
• Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en
los casos más triviales, a otras instancias de soporte y/o comerciales.
• Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico
que permita resolver en el menor tiempo las interrupciones del servicio.
• Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los
servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de
ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia
organización TI tales como:
o Supervisión de los contratos de mantenimiento y niveles de servicio.
o Canalización de las Peticiones de Servicio de los clientes.
o Gestión de las licencias de software.
o Centralización de todos los procesos asociados a la Gestión TI.
Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:
• Reducción de costes mediante una eficiente asignación de recursos.

• Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo.
• Apertura de nuevas oportunidades de negocio.
• Centralización de procesos que mejoran la gestión de la información y la comunicación.
• Soporte al servicio proactivo.

Implementación
La implementación de un Service Desk requiere una meticulosa planificación. En primera instancia debe establecerse:
• Cuáles son las necesidades.

• Cuáles han de ser sus funciones.
• Quiénes serán los responsables del mismo.
• Qué cualificaciones profesionales poseerán sus integrantes.
• Si se deben externalizar ciertos servicios, como, por ejemplo, el soporte técnico del hardware.
• Qué estructura de Service Desk: distribuido, central o virtual, se adapta mejor a nuestras necesidades y
las de nuestros clientes.
• Qué herramientas tecnológicas necesitamos.
• Qué métricas determinarán el rendimiento del Centro de Servicios.
Además de estas cuestiones de carácter técnico, es imprescindible ponderar otros aspectos más directamente
relacionados con el "factor humano" y que son tan importantes o más que los puramente técnicos para el éxito del
Centro de Servicios:
• Establecer estrictos protocolos de interacción con el cliente.

• Motivar al personal encargado de la relación directa con el cliente.
• Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.
• Asegurar el compromiso de la dirección con la filosofía del Service Desk.
• Sondear a los clientes para conocer mejor sus expectativas y necesidades.
El objetivo NO es implementar lo más rápidamente posible un Centro de Servicios sino implantar un Centro de
Servicios cuyos objetivos se alineen con nuestros procesos de negocio, mejoren la satisfacción de nuestros clientes,
optimicen la imagen externa de nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de
negocio.

Estructura
Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda la organización TI con
clientes y usuarios, es por lo tanto imprescindible que:
• Sea fácilmente accesible.

• Ofrezca un servicio de calidad consistente y homogéneo.
• Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los
mismos.
• Sirva de soporte al negocio.
Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.
Estructura lógica
Los integrantes del Centro de Servicios deben:
• Conocer todos los protocolos de interacción con el cliente: guiones, checklists,...

• Disponer de herramientas de software que les permitan llevar un registro de la interacción con los
usuarios.
• Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre
cumplimiento de SLAs.
• Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios.
• Recibir formación sobre los productos y servicios de la empresa.
Estructura física
Dependiendo de las necesidades de servicio: locales, globales, 24/7,...se debe de optar por una estructura diferente para
el Centro de Servicios.
Existen tres formatos básicos:
• Centralizado
• Distribuido
• Virtual
Describimos a continuación sus principales características:
Service Desk Centralizado
En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura central.
Sus ventajas principales son:
• Se reducen los costes.

• Se optimizan los recursos.
• Se simplifica la gestión.
Sin embargo surgen importantes inconvenientes cuando:
• Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y

servicios.
• Se necesita dar servicios de mantenimiento "on-site".

Service Desk Distribuido
Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos
geográficos (ya sean ciudades, países o continentes). Sus ventajas son obvias en estos casos, sin embargo la
deslocalización de los diferentes Centros de Servicios conlleva grandes problemas:
• Es generalmente más caro.

• Se complica la gestión y monitorización del servicio.
• Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks.
Service Desk Virtual
En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de los Centros de
Servicios puede llegar a ser irrelevante.
El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos.
En un Service Desk virtual:
• El "conocimiento" está centralizado.

• Se evitan duplicidades innecesarias con el consiguiente ahorro de costes.
• Se puede ofrecer un "servicio local" sin incurrir en costes adicionales.
• La calidad del servicio es homogénea y consistente.

Actividades y Funciones
Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de
Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación con los clientes y usuarios
manteniéndoles puntualmente informado de todos aquellos procesos de su interés.
A continuación describimos algunas de las actividades que un Service Desk debería ofrecer para merecer ese nombre:
Gestión de Incidentes
Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y
personal, el Service Desk debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de
servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios.
Entre sus tareas específicas se incluyen:
• Registro y monitorización de cada incidente.

• Comprobación de que el servicio de soporte requerido se incluye en el SLA asociado.
• Seguimiento del proceso de escalado.
• Identificación de problemas.
• Cierre del incidente y confirmación con el cliente.
Centro de información
El Service Desk debe ser la principal fuente de información de los clientes y usuarios, informando sobre:
• Nuevos servicios.
• El lanzamiento de nuevas versiones para la corrección de errores.
• El cumplimiento de los SLAs.
• ...
Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las
necesidades de los clientes y su grado de satisfacción con el servicio prestado.
El Centro de Servicios se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos
los procesos de gestión de los servicios TI. Es para ello imprescindible que se lleve un adecuado registro de toda la
interacción con los usuarios y clientes.
Relaciones con los proveedores

El Centro de Servicios es asimismo responsable de la relación con los proveedores de servicios de mantenimiento
externos.
Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del
mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk.

Equipo y formación
La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service
Desk.
Todos hemos sufrido frustrantes experiencias con grandes empresas que prometen un soporte continuo y de alta calidad
y que a la hora de la verdad disponen de un centro de contacto con personal poco preparado, cuando no directamente
mal educado.
"El éxito de su Service Desk es el éxito de su empresa" y el mismo depende en gran medida de las personas que lo
integren. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante.
Idealmente, el personal del Service Desk debe:
• Compartir la filosofía de atención al cliente de la organización.

• Comunicarse con corrección y buena educación y de una manera que el cliente pueda comprender.
• Conocer en profundidad los servicios y productos ofrecidos.
• Comprender las necesidades de los clientes y redirigirlos, si fuera necesario, a los expertos en cuestión.
• Controlar todas las herramientas tecnológicas a su disposición para ofrecer un servicio de alta calidad.
• Ser capaz de trabajar en equipo.
La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica.
También es imprescindible el compromiso de la dirección con:
• Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.

• Un continuo apoyo al equipo en la siempre difícil tarea del trato directo con los clientes.
• El trabajo en equipo.
Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión.

Control del proceso
La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, no sea
responsabilidad exclusiva de éste.
Es importante que se intenten establecer métricas bien definidas para medir el rendimiento del Centro de Servicios y la
apreciación que los usuarios tienen de éste.
En los informes de control se deben considerar aspectos tales como:
• Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
• Porcentaje de incidentes que se cierran en primera línea de soporte.
• Porcentaje de consultas respondidas en primera instancia.
• Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.
• Cumplimiento de los SLAs.
• Número de llamadas gestionadas por cada miembro del personal del Service Desk.
Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el
uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.
Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del
cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser
recopilada y analizada periódicamente para mejorar la calidad del servicio.

Centro de Servicios
Caso Practico
Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha
decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI.
Para ello se han adoptado las siguientes decisiones:
• Se ha nombrado un gestor responsable del Service Desk.

• Se han definido, tras un cuidadoso análisis de las necesidades de la organización y los usuarios, las
funciones principales del mismo:
o Gestionar la primera línea de soporte de la Gestión de Incidentes.
o Supervisar la calidad del servicio ofrecido respecto a los SLAs.
o Ofrecer información de carácter comercial sobre los servicios ofrecidos.
o Realizar encuestas periódicas sobre el grado de satisfacción del cliente.
o Elaboración de informes periódicos con la información recopilada.
• Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y
potenciales.
• Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuarios a
través de este medio:
o Formularios de consultas y alta de incidentes.
o Consulta remota, mediante los web services asociados, del estado de los incidentes activos,
históricos de incidencias y cumplimiento de los SLAs.
o FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios
prestados, errores conocidos, etc.
• Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de
interacción con los usuarios dependiendo de la situación en cuestión.
• Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del
Service Desk.
• Impartir formación específica:
o Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de
Atención al Cliente".
o Sobre las herramientas de software utilizadas.
• Creación de un detallado plan de implantación progresiva del Service Desk .

Visión General
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de
la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se
preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el
servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.
Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo:

Los objetivos principales de la Gestión de Incidentes son:
• Detectar cualquiera alteración en los servicios TI.

• Registrar y clasificar estas alteraciones.
• Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe
jugar una papel esencial en el mismo.
El siguiente diagrama resume el proceso de gestión de incidentes:
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y
software según el libro de Soporte del Servicio de ITIL un incidente es:
“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una
interrupción o una reducción de calidad del mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las
Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que
estos servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el
inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.
Los principales beneficios de una correcta Gestión de Incidentes incluyen:
• Mejorar la productividad de los usuarios.

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

• Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando
concurrentemente en la resolución del incidente.

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

Clasificación del Incidente
Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de
prioridad para la resolución de las mismas.
El nivel de prioridad se basa esencialmente en dos parámetros:
• Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de
negocio y/o del número de usuarios afectados.
• Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente
y/o el nivel de servicio acordado en el SLA.
También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos
necesarios: los incidentes “sencillos” se tramitarán cuanto antes.
Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones
temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin
graves repercusiones.
Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente
diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:

Escalado y Soporte
Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba
recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este
proceso se le denomina escalado.
Básicamente hay dos tipos diferentes de escalado:
• Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el
problema.
• Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que
se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la
resolución de un incidente específico.
El proceso de escalado puede resumirse gráficamente* como sigue:
* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES

Proceso
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:

Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI

Registro y Clasificación de Incidentes
Registro
La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.
Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de
Servicios o el soporte técnico, entre otros.
El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre
el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.
• La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera
instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad
competente.
• Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un
usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.
• Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente
tanto en los procesos internos como en las comunicaciones con el cliente.
• Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para
el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).
• Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que
puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia
CMDB (hardware interrelacionado), etc.
• Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben
ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.
Clasificación
La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada
para la resolución del mismo.
El proceso de clasificación debe implementar, al menos, los siguientes pasos:
• Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles)
dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los
servicios afectados por el incidente.
• Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según
criterios preestablecidos, un nivel de prioridad.
• Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia
designara al personal de soporte técnico responsable de su resolución (segundo nivel).
• Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por
ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en
base al SLA correspondiente y la prioridad.

Análisis, Resolución y Cierre de Incidentes
En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna
incidencia ya resuelta y aplicar el procedimiento asignado.
Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un
nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente
se seguirán los protocolos de escalado predeterminados.
Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de
datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.
Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra
una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de
las causas subyacentes.
Cuando se haya solucionado el incidente se:
• Confirma con los usuarios la solución satisfactoria del mismo.

• Incorpora el proceso de resolución a la KB.
• Reclasifica el incidente si fuera necesario.
• Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el
incidente.
• Cierra el incidente.

Control del Proceso
La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.
Estos informes deben aportar información esencial para, por ejemplo:
• La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual
sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de
incumplimiento.
• Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el
servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
• Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a
los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
• Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la
organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
• Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre
asignación de recursos, costes asociados al servicio, etc.
Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta
implementación. Entre ellos cabe destacar:
• Un correcto sistema automatizado de registro de incidentes y relación con los clientes

• Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y
resueltos. Una (KB) actualizada permite:
o Evitar escalados innecesarios.
o Convertir el “know how” de los técnicos en un activo duradero de la empresa.
o Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de
FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la
incidencia.
• Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener
en la resolución del incidente.
Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la
forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:
• Número de incidentes clasificados temporalmente y por prioridades.

• Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
• Nivel de cumplimiento del SLA.
• Costes asociados.
• Uso de los recursos disponibles en el Centro de Servicios.
• Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de
Servicios.
• Grado de satisfacción del cliente.

Caso Práctico
El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus
clientes.
Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la
web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos
El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días
pero también observa que éste se ha guardado defectuosamente.
El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.
El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:
• Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita
rápidamente el suministro.
• Registra los datos del incidente.
• Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error
conocido y cuales son las posibles soluciones temporales
• Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden
realizar pedidos "urgentes" vía email.
• Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la
mañana.
• Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los
helados solicitados.
• Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes
del mediodía.
Por otro lado el departamento de sistemas:
• Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.
• No consigue identificar la causa del incidente.
• Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero
pre-calificando su prioridad como baja.
El Service Desk recibe la información y determina que:
• Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución
temporal satisfactoria no se requiere un escalado superior.
• Registra la solución temporal del incidente junto a la información proporcionada por el departamento de
sistemas.
• Da por cerrado el incidente.

Gestión de Problemas
Visión General
Las funciones principales de la Gestión de Problemas son:
• Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
• Determinar posibles soluciones a las mismas.
• Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.
• Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos
buscados sin crear problemas de carácter secundario.
La Gestión de Problemas puede ser:
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes
incluso antes de que estos ocurran.
Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguiente interactivo:

Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más
rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo.
Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función
de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia
significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas.
Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de
Incidentes se resumen en el siguiente interactivo:
Entre la funciones principales de la Gestión de Problemas figuran:
• Identificar, registrar y clasificar los problemas.

• Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.
• Analizar y determinar las causas de los problemas y proponer soluciones.
• Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura
TI.
• Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto
funcionamiento.
• Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también
sirvan de soporte a la estructura TI en su conjunto.
• Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:
• Un aumento de la calidad general de los servicios TI.

• Se minimiza el número de incidentes.
• Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI
ahorrando recursos e innecesarios escalados.
• La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y
Niveles de Servicio.
Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:
• Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la
Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los
incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y
resolver los problemas.
• Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los
agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la
infraestructura TI.
• Aumento de los costes por la contratación de personal especializado, aunque estos se vean
sobradamente compensados por los beneficios derivados.

Proceso
Las principales actividades de la Gestión de Problemas son el:
Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en
errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas
a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha
colaboración con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a
detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI

Proceso - Control de Problemas
El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el
Control de Errores pueda proponer las soluciones correspondientes.
El Control de Problemas se compone en esencia de tres fases:
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información
utilizadas son:
• La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y
que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se
habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría
de problema.
• Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la
Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los
sistemas y estructuras TI para evitar futuros problemas.
• Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la
existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.
Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales
y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles
específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, información sobre:
• Los CIs implicados.

• Causas del problema.
• Síntomas asociados.
• Soluciones temporales.
• Servicios involucrados.
• Niveles de prioridad, urgencia e impacto.

• Estado: activo, error conocido, cerrado.
2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de
hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración
(CIs) involucrados en el mismo.
Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se
determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de
deterioro de la calidad del servicio).
Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por
ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos
recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su
impacto en la infraestructura TI.
3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis son:
• Determinar las causas del problema.

• Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema
hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda
frecuente que el problema este causado por:
• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.
• ...
Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo
tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en
la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.
Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de
Errores para su posterior procesamiento.

Proceso - Control de Errores
Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de
Errores el registro del mismo como error conocido.
Identificación y Registro de errores

El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado,
siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes
asociados.
Análisis y Solución
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
• El posible impacto de las mismas en la infraestructura TI.

• Los costes asociados.
• Sus consecuencias sobre los SLAs.
En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio,
pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de
tenerse en cuenta las siguientes consideraciones:
• ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la

infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.
• ¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios
aceptable?
• ¿Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas.
En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de

la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.
Revisión Post Implementación y Cierre

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación
de la RFC elevado a la Gestión de Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se
considera concluido el proceso y se emiten los informes correspondientes.

Control del Proceso
El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para

evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su
rendimiento.
En particular una buena gestión de problemas debe traducirse en una:
• Disminución del número de incidentes y una más rápida resolución de los mismos.
• Mayor eficacia en la resolución de problemas.
• Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o
provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información
de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
• Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores

resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de
Incidentes.
• Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de
nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las
necesidades de la empresa.
• Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio
de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas
sobre cambios de proveedores, etc.
Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada
proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para
evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al
proceso de identificación y solución de problemas.

Caso Práctico
El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le
pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el
modelo de Kepner y Tregoe:
• Identificación del problema.

• Clasificación del problema.
• Establecimiento de las posibles causas.
• Comprobación de la causa más probable.
• Verificación de la causa verdadera.
Identificación: En nuestro caso el problema es sencillo de definir:
• La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos,
sin que este error parezca tener correlación con otros componentes de hardware / software.
Clasificación: La clasificación se adaptaría a los siguientes parámetros:
• Identificación: Problemas en el registro de pedidos.

• Origen: Módulo de pedidos online.
• Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
• Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.
Posibles causas: Entre las causas más probables figuran:
• Errores en la programación del lado cliente de la aplicación.

• Errores en los módulos de registro del servidor web.
• Errores de configuración de la base de datos.
Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.
Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:
• Se intenta reproducir el problema.

• Se comprueba que el error sólo se reproduce con una determinada marca de helados.
• Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se
registra el pedido sin problemas.
Verificación:
• Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.

• Se introducen las modificaciones necesarias en la programación.
• Se comprueba el correcto registro del pedido.
El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:
• Elevar una RFC con la solución propuesta.

• Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere
oportuno implementar la RFC.

Gestión de Configuraciones
Visión General
Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:
• Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel
de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).
• Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.
• Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que
estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas,
realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.
• Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla
con la almacenada en la CMDB para subsanar discrepancias.
Las interacciones y funcionalidades de la Gestión de Configuraciones se resumen sucintamente en el siguiente interactivo:

Es evidente que no se puede gestionar correctamente lo que se desconoce.
Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la
misma. La principal tarea de la Gestión de Configuraciones es llevar un registro actualizado de todos los elementos de
configuración de la infraestructura TI junto con sus interrelaciones.
Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos, en particular, de la Gestión
de Cambios y Versiones.
Los objetivos principales de la Gestión de Configuraciones se resumen en:
• Proporcionar información precisa y fiable al resto de la organización de todos los elementos que
configuran la infraestructura TI.
• Mantener actualizada la Base de Datos de Configuraciones:
o Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,...
o Interrelación entre los CIs.
o Servicios que ofrecen los diferentes CIs.
• Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidentes, Problemas y

Cambios.
Los beneficios de una correcta Gestión de Configuraciones incluyen, entre otros:
• Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente
habitual de problemas es la incompatibilidad entre diferentes CIs, drivers desactualizados, etc. La detección de
estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema.
• Una Gestión de Cambios más eficiente. Es imprescindible conocer la estructura previa para diseñar
un cambio que no genere nuevas incompatibilidades y/o problemas.
• Reducción de costes. El conocimiento detallado de todos los elementos de configuración permite, por
ejemplo, eliminar duplicidades innecesarias.
• Control de licencias. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto
peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que
pueden repercutir negativamente en la organización.
• Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades
en la infraestructura.
• Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos de configuración y
sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve
posible.
Las principales dificultades con las que topa la Gestión de Configuraciones son:
• Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para
evitar duplicaciones o incorrecciones.
• Estructura inadecuada de la CMDB: mantener actualizada una base de datos de configuraciones
excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.
• Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de
registro y sacar el máximo provecho de la CMDB.
• Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto
mantenimiento de la CMDB.
• Falta de organización: es importante que haya una correcta asignación de recursos y
responsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones sea llevada a cabo
por personal independiente y especializado.

• Falta de compromiso: los beneficios de la Gestión de Configuraciones no son inmediatos y son casi
siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los
agentes implicados.

Definiciones
A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración
(CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una
definición precisa de ambos.
Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos
ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:
• Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes:
tarjetas de red, teclados, lectores de CDs, ...
• Software: sistemas operativos, aplicaciones, protocolos de red, ...
• Documentación: manuales, acuerdos de niveles de servicio, ...
En resumen, todos los componentes que han de ser gestionados por la organización TI.
Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir:
• Información detallada de cada elemento de configuración.

• Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones "padre-
hijo" o interdependencias tanto lógicas como físicas
La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la
infraestructura TI de la organización.

Proceso
Las principales actividades de la Gestión de Configuraciones son:
Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones.
Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura
predefinidos.
Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén
correctamente registrados y se conoce su estado actual.
Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real
de la estructura TI de la organización.
Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de

vital importancia a otras áreas de la infraestructura TI.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.

Planificación
La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias
con el resto de procesos. Por ello su implantación es particularmente compleja.
Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que
aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:
• Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al

traste todo el proceso.
• Invertir en alguna herramienta de software adecuada a las actividades requeridas: una
organización manual es impracticable.
• Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.
• Establecer claramente:
o El alcance y objetivos.
o El nivel de detalle
o El proceso de implementación: orden de importancia, cronograma, ...
• Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los

Departamentos de Compras y Suministros
Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves
consecuencias que esto supondrá para el resto de los procesos.

Clasificación y Registro
La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor
con éxito, predeterminar la estructura del CMDB de manera que:
• Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la
organización y resultar, a la larga, en una dejación de responsabilidades.
• La información sea suficiente: debe existir, al menos un registro de todos los sistemas críticos para la
infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:
• Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios
críticos.
• 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 documentación 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 lógicas y físicas registradas entre los diferentes CIs.
• Subcomponentes registrados independientemente.
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: conexión en red, impresoras conectadas, etc.
• Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.

Nomenclatura
Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los CIs para
que el sistema sea funcional:
• La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.
• Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir
físicamente unido al mismo (mediante una etiqueta de difícil eliminación).
• Los códigos no deben ser sólo utilizados para componentes de hardware sino también para
documentación y software.

Monitorización
Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede
ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la
degradación de la calidad del servicio.
Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del
ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).
Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de , digamos, los
switches instalados a la hora de adoptar decisiones de compra de nuevo material:

Control
La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de
componentes para mantener actualizada la CMDB.
El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse
actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el
software "en producción".
Las tareas de control deben centrarse en:
• Asegurar que todos los componentes están registrados en la CMDB.

• Monitorizar el estado de todos los componentes.
• Actualizar las interrelaciones entre los CIs.
• Informar sobre el estado de las licencias.

Auditorías
El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la
estructura TI de la organización.
Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de
hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.
Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos
datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:
• Tras la implementación de una nueva CMDB.

• Antes y después de cambios mayores en la infraestructura.
• Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o
incompleta.
Las auditorías deben dedicar especial atención a aspectos tales como:
• Uso correcto de la nomenclatura en los registros de los CIs.

• Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, ...
• Estado de los CIs actualizado.
• Cumplimiento de los niveles de alcance y detalle predeterminados.
• Adecuación de la estructura de la CMDB con la de la estructura TI real.

Control del Proceso
Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada
la información almacenada en la CMDB.
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Configuraciones, tanto para
conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la
infraestructura TI.
• Alcance y nivel de detalle de la CMDB.

• Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de
configuración.
• Información sobre CIs que han estado involucrados en incidentes.
• Costes asociados al proceso.
• Sistemas de clasificación y nomenclatura utilizados.
• Informes sobre configuraciones no autorizadas y/o sin licencias.
• Calidad del proceso de registro y clasificación.
• Información estadística y composición de la estructura TI.
En pequeñas organizaciones es a veces conveniente combinar la Gestión de Configuraciones y Cambios para

simplificar el proceso de control. La coordinación entre ambos procesos es un factor crítico para el éxito y ésta unificación
puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total separación de
estos procesos.

Caso Práctico
La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "gran devoradora de
recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "Cater Matters" ha decidido, en una
primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:
• Servidores de red local.

• Servidores de Internet.
• Infraestructura informática del Centro de Servicios.
• SLAs
Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de "configuraciones de
referencia" aplicables a los CIs arriba descritos.
Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:
• Reducción a medio/largo plazo de los costes asociados.

• Mejora y consistencia de los servicios prestados.
• Simplificación de todos los procesos asociados al soporte al servicio: Incidencias, Problemas, Cambios,
Versiones, etc.
El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de
realizar un esfuerzo desmedido por lo que se han registrado:
• Configuraciones de software:
o Sistemas operativos.
o Aplicaciones instaladas.
o Interdependencias: relaciones padre-hijo, propietarios,...
o Documentación asociada.
• Configuraciones de hardware:
o Servidores y estaciones de trabajo.
o Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,...
o Documentación y controladores asociados.
• SLAs e informes de seguimiento asociados.
A su vez se han instalado herramientas de gestión que permiten la monitorización remota de todas esas configuraciones
y la realización de auditorías periódicas automatizadas.

Gestión de Cambios
Visión General
Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no
sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo
funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe
hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en
servicios y tecnologías desactualizados.
Las principales razones para la realización de cambios en la infraestructura TI son:
• Solución de errores conocidos.

• Desarrollo de nuevos servicios.
• Mejora de los servicios existentes.
• Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que,
si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en
todo momento la calidad y continuidad del servicio TI.
Las interacciones y funcionalidades de la Gestión de Cambios se resumen sucintamente en el siguiente interactivo:

Gestión de Cambios
El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios
necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
La Gestión de Cambios debe trabajar para asegurar que los cambios:
• Están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Están convenientemente registrados, clasificados y documentados.
• Han sido cuidadosamente testeados en un entorno de prueba.
• Se ven reflejados en la CMDB.
• Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto
funcionamiento tras su implementación.
Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama:

Los principales beneficios derivados de una correcta gestión del cambio son:
• Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio.

• Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga
un impacto negativo en la estructura TI.
• Se reduce el número de "back-outs" necesarios.
• Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
• Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno
real a la inversión.
• La CMDB está correctamente actualizada, algo imprescindible para la correcta gestión del resto de
procesos TI.
• Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no
críticos.
La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:
• Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo
que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un
servicio o adaptarse a requisitos legales.
• No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la
información sobre los CIs en la CMDB.
• Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y
estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
• Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y
documentar adecuadamente el proceso.
• No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos
asociados.
• Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el
proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.

Gestión de Cambios
Conceptos básicos
En el resto de este capítulo 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 Gestión de Cambios. En grandes organizaciones el Gestor de Cambios
puede disponer de un equipo de asesores específicos 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 gestión de servicios TI. Sin embargo,
en algunos casos también puede incorporar:
o Consultores externos.
o Representantes de los colectivos de usuarios.
o Representantes de los principales proveedores de software y hardware.
Alcance de la Gestión de Cambios

En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces
impracticable gestionar todos los cambios mediante ésta.
El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión 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 Gestión de Configuraciones se sugirió como medida simplificadora la creación

de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con
todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos
están previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de
referencia antes citadas.
Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión
más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.

Gestión de Cambios
Proceso
Las principales actividades de la Gestión de Cambios se resumen en:
• Monitorizar y dirigir todo el proceso de cambio.

• Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
• Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y
la elaboración del FSC.
• Coordinar el desarrollo e implementación del cambio.
• Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

Gestión 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:
• Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los

casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con
información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la
pertinencia del proceso.
• 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 dirección puede decidir una redirección estratégica que puede afectar, por
ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM, etc. y que por regla general
requieren de cambios de hardware, software y/o procedimientos.
• Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones
anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la
actualización.
• Imperativo legal: un cambio de legislación (como, por ejemplo, la LOPD) 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 periódicamente pueden
acordarse procedimientos estándar que no requiera la aprobación de la Gestión 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 recepción.
• Identificador único de la RFC.
• Identificador del error conocido asociado (dado el caso).
• Descripción del cambio propuesto:
o Motivación.
o Propósito.
o CIs involucrados.
o Estimación de recursos necesarios para la implementación.
o Tiempo estimado.
• Estatus: que inicialmente será el de "registrado".
Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado
seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.
La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:
• Estatus actualizado: "aceptado", "rechazado", "implementado", ...

• Fecha de aceptación (denegación) del RFC.
• Evaluación preliminar de la Gestión del Cambio.
• Prioridad y categoría.
• Planes de "back out".

• Recursos asignados.
• Fecha de implementación.
• Plan de implementación.
• Cronograma.
• Revisión post-implementación.
• Evaluación final.
• Fecha de cierre.

Gestión de Cambios
Aceptación y Clasificación
Aceptación
Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si
se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos
de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al
departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha
RFC o para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada
justificado su ulterior procesamiento.
Clasificación
Tras su aceptación se deben asignar a la RFC una prioridad y categoría 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 categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de
recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación 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 algún otro cambio de
más 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 próxima reunión y adoptar las
medidas pertinentes que permitan una pronta solución.
• Urgente: es necesario resolver un problema que esta provocando una interrupción o deterioro grave del
servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que
trataremos de forma independiente.
La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su

implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI
y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación
directa de la Dirección.
Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro
cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar
tareas de asesoramiento.

Gestión de Cambios
Aprobación y Planificación
La planificación es esencial para una buena gestión del cambio.
Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas
interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en
cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que
permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y
elaborar el FSC o calendario del cambio correspondiente.
Para su aprobación el cambio se debe evaluar minuciosamente:
• ¿Cuáles son los beneficios esperados del cambio propuesto?

• ¿Justifican esos beneficios los costes asociados al proceso de cambio?
• ¿Cuáles son los riesgos asociados?
• ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?
• ¿Puede demorarse el cambio?
• ¿Cuál 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 también consultarse a la dirección pues pueden entrar en
consideración aspectos de carácter estratégico y de política general de la organización.
Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe
evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente
equivaldrían a un solo cambio. Esto tiene algunas ventajas:
• Se optimizan los recursos necesarios.

• Se evitan posibles incompatibilidades entre diferentes cambios.
• Sólo se necesita un plan de back-out.
• Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.

Gestión de Cambios
Implementación
Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente
la Gestión 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 asignación de recursos es la adecuada.
• El entorno de pruebas es realista y simula adecuadamente el entorno de producción.
• Los planes de "back-out" permitirán la rápida recuperación de la última configuración estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración
preliminar de los nuevos sistemas en lo que respecta a su:
• Funcionalidad.
• Usabilidad.
• Accesibilidad.
La opinión 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 función tanto de la Gestión 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.
• Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser
compartida por usuarios y clientes.

Gestión de Cambios
Evaluación
Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del
mismo en la calidad del servicio y en la productividad de la organización.
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 Gestión de Cambios.
• ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
• ¿Cuál ha sido la percepción de los usuarios respecto al cambio?
• ¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?¿Por qué?
Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y
toda la información se incluirá en la PIR asociada.

Gestión de Cambios
Cambios de Emergencia
Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación
deficiente a veces resultan inevitables.
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto
involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que
la solución 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 validación de los cambios urgentes que pueden requerir:
• La reunión urgente del CAB y/o EC si esto fuera posible.

• Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede
durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión 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 documentación asociada al cambio se realicen a
posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que
dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros
incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.

Gestión de Cambios
Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de
referencia que cubran aspectos tales como:
• RFCs solicitados.
• Porcentaje de RFCs aceptados y aprobados.
• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
• Tiempo medio del cambio dependiendo del impacto y la prioridad
• Número de cambios de emergencia realizados.
• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
• Numero de back-outs con una detallada explicación de los mismos.
• Evaluaciones post-implementación.
• Porcentajes de cambios cerrados sin incidencias ulteriores.
• Incidencias asociadas a cambios realizados.
• Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº
de cambios aprobados por reunión, etc.

Gestión de Cambios
Caso Práctico
Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para
gestionar tanto los pedidos como la cadena de suministro.
El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado
para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión 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 dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más
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
interconexión con el software de gestión interna de la organización (ERP).
Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión 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.
• Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación 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 reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce
y programación web.
• Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso
de implementación del sistema actual.
Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la
Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de
Proyectos:
• Una evaluación inicial de costes y recursos necesarios.

• Una valoración del impacto de los cambios en la infraestructura TI.
• Un cronograma preliminar del proceso.
• Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles
cambios.
Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba el cambio y:
• 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 Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos
puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
o Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las bases de
datos antiguas para evitar la perdida de datos en caso de "back-out".

• Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.
• Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una
auditoria externa de todo el proceso.
• Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de
pruebas e implementación.
Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión
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 prestación de
servicios.
o Ha mejorado la productividad.
• Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.

• Evalúa el proceso.
• Da por cerrado el cambio.

Gestión de Versiones
Visión General
La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware

instalado en el entorno de producción.
La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para
asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se
guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.
Las interacciones y funcionalidades de la Gestión de Versiones se resumen sucintamente en el siguiente interactivo:

Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea
delicada la implementación de cualquier cambio.
La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión
de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de
Servicios TI.
Entre los principales objetivos de la Gestión de Versiones se incluyen:
• Establecer una política de implementación de nuevas versiones de hardware y software.

• Implementar las nuevas versiones de software y hardware en el entorno de producción tras su
verificación en un entorno realista de pruebas.
• Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente.
• Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se
ven correctamente reflejados en la CMDB.
• Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la
Biblioteca de Software Definitivo (DSL).
• Mantener actualizado el Depósito de Hardware Definitivo (DHS).
Los beneficios de una correcta Gestión de Versiones se resumen en:
• El proceso de cambio se realiza sin deterioro de la calidad de servicio.

• Las nuevas versiones cumplen los objetivos propuestos.
• Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado.
• El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar
sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas
versiones.
• El correcto mantenimiento de la DSL impide que se pierdan (valiosas) copias de los archivos fuente.
• Se reduce el número de copias de software ilegales.
• Control centralizado del software y hardware desplegado.
• Protección contra virus y problemas asociados a versiones de software incontroladas.
Las principales dificultades con las que topa la Gestión de Versiones son:
• No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante
de la Gestión de Versiones en todo el proceso de implementación 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 centralización del proceso de cambio. Es habitual
que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no
ha sido la política tradicional de la misma.
• Se realizan cambios sin tener en cuenta a la Gestión de Versiones argumentado que estos sólo son
responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.
• Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir
"ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última
versión estable.
• La implementación sincronizada de versiones en entornos altamente distribuidos.

La solución a estos problemas pasa por:
• Un firme compromiso de la organización con la Gestión de Versiones y sus responsables.

• Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI
de las ventajas de una correcta gestión de todo el proceso de cambio.

Conceptos básicos
Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno
de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.
Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:
• Versiones mayores: que representan importantes despliegues de software y hardware y que

introducen modificaciones importantes en la funcionalidad, características técnicas, etc.
• Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a
menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones
de emergencia.
• Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.
Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique
unívocamente. El sistema universalmente aceptado es:
• Versiones mayores: 1.0, 2.0, etc.

• Versiones menores: 1.1, 1.2, 1.3, etc.
• Versiones de emergencia: 1.1.1, 1.1.2, etc
Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).
En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.
El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión:
El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de

Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:
• Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su
mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el
entorno de producción.
• Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no.
Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la
instalación si se han realizado las pruebas pertinentes.

• Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada
diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos
casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware
previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere
hardware más avanzado y/o nuevos versiones de los programas ofimáticos.
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 también controladores de dispositivos y documentación asociada.
La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en
caso de que se deban implementar los planes de back-out.
La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.
DHS
El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción.
Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se hallen registrados
en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).

Proceso
Las principales actividades de la Gestión de Versiones se resumen en:
• Establecer una política de planificación para la implementación de nuevas versiones.

• Desarrollar o adquirir de terceros las nuevas versiones.
• Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.
• Validar las nuevas versiones.
• Implementar las nuevas versiones en el entorno de producción.
• Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.
• Actualizar la DSL, el DHS y la CMDB.
• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Versiones:

Planificación
Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología 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 específicos que tomen en cuenta las peculiaridades de cada caso.
A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes
factores:
• Cómo puede afectar la nueva versión a otras áreas del entramado TI.
• Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.
• Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.
• Qué planes de back-out son necesarios.
• Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo
sobre el servicio y la integridad del sistema TI.
• Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva
versión con garantías de éxito.
• Quiénes serán los responsables directos en las diferentes etapas del proceso
• Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén
puntualmente informados y puedan percibir la nueva versión como una mejora.
• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos,
gradual, ...
• Cuál es la vida media útil esperada de la nueva versión.
• Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.
• Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva
versión.

Desarrollo
La Gestión de Versiones es la encargada del diseño y construcción 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 participación de proveedores externos. En este
segundo caso, la tarea de la Gestión 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 Gestión de Versiones será la
responsable de todo el proceso de configuración necesario.
El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación necesarios
para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:
• Back-up automático de datos.

• Actualizaciones necesarias de las Bases de Datos asociadas.
• Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.
• Creación de logs asociados al proceso de instalación.
Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrán que tomar en cuenta la
disponibilidad acordada con los clientes en los SLAs correspondientes.

Validación
Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva
versión con razonables garantías de éxito.
Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben
realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y
es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en
consideración).
Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podrá volver a la última versión
estable de una forma rápida, ordenada y sin perdidas de valiosa información.
Las principales actividades realizadas en el proceso de prueba deben incluir:
• Pruebas del correcto funcionamiento de la versión en un entorno realista.

• Pruebas de los procedimientos automáticos o manuales de instalación.
• Listas de "bugs" o errores detectados, si se diera el caso.
• Pruebas de los planes de back-out.
• Documentación para usuarios y personal de servicio.
La Gestión de Cambios será la encargada de dar la validación final a la versión para que se proceda a su instalación. Si
la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación.

Implementación
Llego el momento de la verdad: la distribución de la nueva versión, también conocida como rollout.
El rollout puede ser de varios tipos:
• Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos.

• Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por
grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.
El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y
responsabilidades específicas. En particular los usuarios finales deben estar puntualmente informados del calendario de
lanzamiento y de cómo 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.
• Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.
• Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos
o parciales.
Tras la distribución la Gestión de Versiones debe asegurarse de que:
• Se incluya una copia de la versión en la DSL.

• El DHS incorpore repuestos funcionales de los nuevos CIs.
• La CMDB esté correctamente actualizada.
• Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación
necesaria para poder sacar el adecuado provecho de las mismas.
Tras la implementación, la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los
comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser
analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas
correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.

Comunicación y Formación
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.
Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil
de la cadena.
Es inútil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formación, no se encuentran
en disposición de aprovechar sus ventajas.
La (in)formación debe estructurarse en distintos niveles:
• Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la
nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el
proceso.
• Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de
usuarios finales. Durante este proceso de prueba se documentarán y analizarán:
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 versión.
o La claridad de la documentación que se pondrá a disposición del usuario final.
• Cuando se considere oportuno se impartirán cursos presenciales o remotos mediante módulos de e-

learning sobre el funcionamiento de la nueva versión.
• Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y
puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.

Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de
referencia que cubran aspectos tales como:
• Número de lanzamientos de nuevas versiones.

• Número de back-outs y razones de los mismos.
• Incidencias asociadas a nuevas versiones.
• Cumplimientos de los plazos previstos para cada despliegue.
• Asignación de recursos en cada caso.
• Corrección 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 (formación inadecuada) de la nueva versión por parte de los
usuarios.
• Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.

Caso Práctico
La Gestión de Cambios ha aprobado (véase el caso práctico del capítulo 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.
• Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones
de hardware y software asociadas. Para ello:
• En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades del nuevo
hardware y se encarga de su compra y configuración.
• 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 estén dispuestos inmediatamente para el "back-out".
• Se crean scripts de traducción que permitan salvar los nuevos datos en la versión 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 integración mediante WebServices de los pedidos web en el ERP.
• Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQs en la web que
incluyen las dudas más frecuentes elevadas por los usuarios en la fase de pruebas.
• Se informa a los usuarios sobre la nueva versión y se avisa de posibles y cortas interrupciones del
servicio en la fecha de instalación.
• Se procede a la instalación de la nueva versión.
• Se guarda una copia maestra de todo el software en la DSL.
• Se actualiza la CMDB.

Gestión de Niveles de Servicio
Visión General
El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es un fin en sí misma sino un medio para
aportar valor a los usuarios y clientes.
La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de
negocio y todo ello a unos costes razonables.
Para cumplir sus objetivos es imprescindible que la Gestión 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 Gestión de Niveles de Servicio se resumen sucintamente en el siguiente

interactivo:

La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios
TI ofrecidos.
La Gestión 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 organización TI.
La Gestión 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 tecnología.
• 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 Gestión de Niveles de Servicio son:
• Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente.
• Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características 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
actuación en caso de deterioro del servicio.
• La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para
su mejora.
• La gestión TI conoce y comprende los servicios ofrecidos lo que facilita los acuerdos con proveedores y
subcontratistas.
• El personal del Service Desk dispone de la documentación necesaria (SLAs, OLAs,etc.) para llevar una
relación fluida con clientes y proveedores.
• Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante
los clientes.
Lo que repercute a la larga en una mejora del servicio con la consecuente satisfacción de clientes y usuarios.

Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:
• No existe una buena comunicación con clientes y usuarios por lo que los SLAs acordados no recogen sus
necesidades reales.
• Los acuerdos de nivel de servicio están basados más 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 técnicos incumpliendo así sus objetivos primordiales.
• No se dedican los recursos suficientes pues la dirección los considera como un gasto añadido y no como
parte integral del servicio ofrecido.
• Problemas de comunicación: no todos los usuarios conocen las características 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 organización un verdadero compromiso con la calidad del servicio TI ofrecido.

Conceptos básicos
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.
Catálogo de Servicios
El Catálogo de Servicios no es sólo una herramienta imprescindible a la hora de simplificar la comunicación con el cliente
sino que también puede ser una gran ayuda tanto a la organización interna como a la proyección exterior de la
organización TI.
El Catálogo de Servicios debe:
• Describir los servicios ofrecidos de manera no técnica y comprensible para clientes y personal no
especializado.

• Utilizarse como guía para orientar y dirigir a los clientes.
• Incluir, en líneas generales, los niveles de servicio asociados con cada uno de los servicios ofrecidos.
• Encontrarse a disposición del Service Desk y todo el personal que se halle en contacto directo con los
clientes.
Requisitos de Nivel de Servicio (SLR)

El SLR debe incluir información 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 Especificación
Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los
servicios ofrecidos al cliente.
Las Hojas de Especificación 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 elaboración de los OLAs y UCs correspondientes.
Programa de Calidad del Servicio (SQP)

El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del
servicio:
• Objetivos de cada servicio.

• Estimación de recursos.
• Indicadores clave de rendimiento.
• Procedimientos de monitorización de proveedores.
En resumen, el SQP debe contener la información necesaria para que la organización 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 técnico, 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 relación con el cliente en todo lo que respecta
a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos
esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.
Acuerdo de Nivel de Operación (OLA)

El OLA es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los
diferentes departamentos de la organización TI en la prestación de un determinado servicio.
Contratos de Soporte (UC)

Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización 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 tecnología.
El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a
disposición de los gestores de los otros procesos TI.

Proceso
Las principales actividades de la Gestión de Niveles de Servicio se resumen en:
• Planificación:
o Asignación de recursos.
o Elaboración de un catálogo de servicios.
o Desarrollo de SLAs tipo.
o Herramientas para la monitorización de la calidad del servicio.
o Análisis e identificación de las necesidades del cliente.
o Elaboración del los Requisitos de Nivel de servicio(SLR), Hojas de Especificación del Servicio y
Plan de Calidad del Servicio(SQP).
• Implementación de los Acuerdos de Nivel del Servicio:
o Negociación.
o Acuerdos de Nivel de Operación.
o Contratos de Soporte.
• Supervisión y revisión de los Acuerdos de Nivel de Servicio:

o Elaboración de informes de rendimiento.
o Control de los proveedores externos.
o Elaboración de Programas de Mejora del Servicio (SIP).

Planificación
La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los
estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientemente compleja, resulta
imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.
El objetivo primordial de la Gestión 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 organización TI será responsable de las
consecuencias que se deriven de ello.
Todo el proceso de planificación previo debe estar orientado a dar respuestas a las siguiente preguntas:
• ¿Qué servicios debemos ofrecer a nuestros clientes?

• ¿Cuáles son las necesidades de nuestros clientes?
• ¿Cuál es el nivel adecuado de calidad de servicio?
• ¿Quiénes y cómo se van a suministrar esos servicios?
• ¿Cuáles serán 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 carácter interno y otros
accesibles a los clientes, que pasamos a describir sucintamente a continuación.
En primer lugar la Gestión de Niveles de Servicio debe poner a disposición de toda la organización, pero en especial a
disposición del Service Desk y la fuerza de ventas un Catálogo de Servicios.
Este catálogo 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 elaboración de este Catálogo de Servicios puede resultar una tarea compleja pues es necesario alinear aspectos
técnicos con políticas de negocio pero es un documento imprescindible pues:
• Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.
• Delimita las funciones y compromisos de la organización TI.
• Puede ser utilizado como herramienta de venta.
• Evita malentendidos entre los diferentes actores implicados en la prestación de servicios.
Sin embargo, en la mayoría de los casos, por muy detallado y completo que sea el Catálogo de Servicios, la complejidad
de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente.
Los resultados de esta interacción/negociación 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 características del servicio.

• La disponibilidad del servicio.
• La interacción del servicio con su infraestructura TI o de otro tipo.
• La continuidad del servicio.
• Los niveles de calidad del servicio.
• Tiempo y procedimientos de implantación del servicio.
• La escalabilidad del servicio ofrecido.
• Etc.

La información contenida en el SLR debe servir de base para elaborar la documentación interna que permita determinar
"cómo" se prestara el servicio y "quién o quiénes" serán responsables del mismo.
Las Hojas de Especificación del Servicio deben contener:
• Una descripción detallada, con todos los detalles técnicos necesarios, sobre como se prestará el servicio.
• Cuáles serán los indicadores internos de rendimiento y calidad del servicio.
• Cómo se implementará el servicio.
Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su
infraestructura, está información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con
el cliente y su responsables técnicos.
El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y
contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios.
En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan global que permita
asignar los recursos a la organización 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 organización.
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 guía para el establecimiento de los contratos con los proveedores externos.

Implementación
La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del
servicio.
Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operación y Contratos de Soporte.
Acuerdos de Nivel de Servicio

Los SLAs deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles
más específicos del servicio.
Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupo involucrado reciba
exclusivamente la información correspondiente al nivel en que se integra, ya sea en el lado del cliente como del
proveedor.
La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran:
• La naturaleza del negocio del cliente.

• Aspectos organizativos del proveedor y cliente.
• Aspectos culturales locales.
Acuerdos de Nivel de Operación

Los OLAs son documentos de carácter interno de la propia organización 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 prestación del servicio que deben ser opacos para el cliente pero
que resultan imprescindibles a la organización TI para su organización.
Contratos de Soporte
Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de
prestación 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 extensión "externa" de los OLAs en el sentido de que persiguen el mismo fin: organizar los
procesos y procedimientos necesarios para la correcta provisión del servicio.

Monitorización
El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorar progresivamente la calidad
del servicio ofrecido, su rentabilidad y la satisfacción de los clientes y usuarios.
La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la
organización como los relacionados con la percepción de los usuarios.
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 guía en la elaboración de los informes correspondientes.
Las principales fuentes principales de información las constituyen:
• La documentación disponible: SLAs, OLAs, UCs, etc.

• La Gestión de Incidentes: que debe informar de las incidencias en el servicio y los tiempos de
recuperación.
• La Gestión de la Capacidad y la Disponibilidad: que debe proporcionar la información 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
organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos.
Los informes de rendimiento elaborados deben cubrir factores clave tales como:
• Cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes
responsables de la degradación del servicio.
• Quejas, justificadas o no, de los clientes y usuarios.
• Utilización 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.

Revisión
La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de
los servicios ofrecidos.
Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experiencia previa, los SLAs
en vigencia y la evolución del Catálogo de Servicios.
Este proceso de revisión no debe limitarse a aquellos SLAs que por una razón 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.
El resultado de la revisión 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 tecnológicos.
• Cumplimiento de los niveles de servicio.
• Evaluación de los costes reales del servicio.
• Implicaciones de una degradación de la calidad del servicio en la estructura organizativa del cliente.
• Evaluación del rendimiento y capacitación del personal involucrado.
• Reasignación de recursos.
• Cumplimiento de los OLAs y UCs relacionados.
• Percepción del cliente y usuarios sobre la calidad de servicio.
• Necesidades de formación adicional a los usuarios de los servicios.
El SIP debe ser el documento base para negociar la renovación del SLA con el cliente y debe constituir un documento de
referencia para la gestión de otros procesos TI como la Gestión de Cambios, Gestión de Problemas, etc.

Control del Proceso
El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del
cliente pero esto no se puede llevar a cabo sin una buena gestión 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 cualificación y experiencia
necesarios.
• Una asignación clara de tareas y responsabilidades.
• Indicadores específicos de rendimiento tales como:
o Porcentaje de servicios amparados bajo SLAs.
o Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad del servicio.
o SIPs elaborados e impacto de los mismos en la calidad del servicio.
o Encuestas de satisfacción del cliente.
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Niveles de
Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y la provisión de los servicios
TI.
• Informes Estadísticos 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 monitorización realizadas, sus
resultados y el grado de satisfacción 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 Práctico
La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicio que adapte a las
necesidades de su organización los principios y recomendaciones de ITIL.
Para llevar a cabo esta tarea de la forma más eficiente posible se han determinado una serie de acciones iniciales que se
resumen en:
• Designación de un Gestor del proceso.

• Elaboración de un catálogo de servicios.
• Desarrollo de un Plan Integral de Calidad del Servicio.
• Creación de "plantillas" para la creación de SLAs asociados a sus principales servicios.
Gestor de Niveles de Servicio

La dirección ha encargado a uno de sus directivos con más amplia experiencia en la relación con los clientes asumir el
puesto de Gestor de Niveles de Servicio.
Su principal función es negociar y acordar, en representación de "Cater Matters", la provisión de servicios con los
clientes.
Sus responsabilidades específicas incluyen:
• Elaborar y mantener actualizado un catálogo 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 provisión del servicio con clientes y proveedores.
• Mantener informados a la Dirección y la organización TI sobre el rendimiento de todo el proceso.
• 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
tecnológicos.
• Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la información
necesaria para el óptimo funcionamiento de la organización.
Elaboración del Catálogo de Servicios

Se ha decidido estructurar el Catálogo de Servicios en función de los diferentes tipos de clientes que contratan los
servicios de "Cater Matters":
• Particulares.
• Pequeñas empresas.
• Grandes corporaciones e instituciones y organismos públicos.
El objetivo del catálogo no es sólo 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 catálogo online que permite comparar las diferentes "versiones" y realizar una estimación
preliminar de los costes basándose en las diferentes opciones seleccionadas.
La descripción de cada servicio incluye información adicional sobre:
• Plazos de entrega.
• Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
• Servicios auxiliares.

• WebServices asociados.
• Disposiciones legales aplicables.
• Programas de fidelización.
• 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 provisión del servicio.

• Planes de contingencia en casos de deterioro grave de la calidad del servicio.
• Indicadores clave de rendimiento y satisfacción del cliente.
• Métodos de supervisión y seguimiento en tiempo real de los procesos involucrados en la prestación del
servicio, como, por ejemplo, el reparto y la provisión de mercancía.
• Protocolos de interacción del Service Desk con los clientes y usuarios.
• Los niveles de seguridad, disponibilidad, capacidad y redundancia necesarios para asegurar la correcta
provisión del servicio en colaboración con los responsables de dichos procesos.
SLAs prototipo
A fin de evitar que la elaboración 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:
• Descripción general y no técnica de los servicios acordados.

• Responsables del acuerdo tanto por el lado cliente como proveedor.
• Plazos para la provisión del servicio.
• Duración del acuerdo y condiciones para su renovación y/o rescisión.
• Condiciones de disponibilidad del servicio.
• Soporte y labores de mantenimiento asociadas.
• Tiempos de respuesta.
• Tiempos de recuperación en casos de incidentes.
• Planes de contingencia si son de aplicación.
• Métodos de facturación y cobro.
• Criterios de evaluación de la calidad del servicio.

Gestión Financiera de los Servicios TI
Visión General
Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus
procesos de negocio es moneda corriente que no exista una conciencia real de los costes que esta tecnología supone.
Esto conlleva serias desventajas:
• Se desperdician recursos tecnológicos.

• No se presupuestan correctamente los gastos asociados.
• Es prácticamente imposible establecer una política consistente de precios.
El principal objetivo de la Gestión 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 organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podrán evaluar el
retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica.
Las propiedades y funcionalidades de la Gestión Financiera de los Servicios TI se resumen sucintamente en el

siguiente interactivo:

La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar de manera eficaz y
rentable los servicios y la organización 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 Gestión Financiera debe:
• Evaluar los costes reales asociados a la prestación de servicios.

• Proporcionar a la organización TI toda la información financiera precisa para la toma de decisiones y
fijación de precios.
• Asesorar al cliente sobre el valor añadido 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 Gestión Financiera de los Servicios Informáticos se resumen en:
• Se reducen los costes y aumenta la rentabilidad del servicio.

• Se ajustan, controlan, adecuan y justifican (si es de aplicación) los precios del servicio aumentando la
satisfacción del cliente.
• Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad.
• La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI.
• Los servicios TI son usados más eficazmente.
• La organización TI funciona como una unidad de negocio y es posible evaluar claramente su rendimiento
global.
Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen
en:
• Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos

financieros y/o contables.
• Existen múltiple costes ocultos difíciles de evaluar por una deficiente organización 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 organización con el proceso.

Conceptos Básicos
Categorías de coste
La clasificación de costes por servicio o producto puede realizarse en
virtud de uno a más criterios:
Costes atribuibles, directa o indirectamente a la prestación del

servicio o elaboración del producto:
• Costes Directos: son los costes relacionados

específica 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
específicos y exclusivos de un servicio, como por
ejemplo, la "conectividad" de la organización TI de la que
dependen tanto los servicios web como la propia
plataforma general de comunicaciones. Estos costes son
más difíciles de determinar y por lo general son
prorrateados entre los diferentes servicios y productos.
Costes que dependen o no del "cuánto":
• Costes fijos: son independientes del volumen de

producción y están normalmente relacionados con gastos en
inmovilizado material.
• Costes variables: incluyen aquellos costes que
dependen del volumen de producción 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 amortización del inmovilizado material o inversiones a largo
plazo.
• Costes de Operación: son los costes asociados al funcionamiento diario de la organización TI.
Tipos de coste
Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente.
Los tipos de coste se subdividen a su vez en elementos de coste. El siguiente diagrama nos muestra una típica estructura
de tipos y elementos de coste para una organización TI:

* Los costes de Transferencia se corresponden con los cargos internos por servicios prestados por otros departamentos
de la empresa o institución.

Proceso
Las principales actividades de la Gestión Financiera se resumen se resumen en:
• Presupuestos:
o Análisis de la situación financiera.
o Fijación de políticas financieras.
o Elaboración de presupuestos.
• Contabilidad:
o Identificación de los costes.
o Definición de elementos de coste.
o Monitorización de los costes.
• Fijación de precios:
o Elaboración de una política de fijación de precios.
o Establecimiento de tarifas por los servicios prestados o productos ofrecidos.
Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Presupuestos
La elaboración de presupuestos TI tiene como objetivos principales:
• Planificar el gasto e inversión TI a largo plazo.

• Asegurar que los servicios TI están suficientemente financiados.
• Establecer objetivos claros que permitan evaluar el rendimiento de la organización 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 proyección sobre la evolución prevista del negocio en
dos o más años.
Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:
• Presupuesto incremental: el presupuesto se realiza en base al histórico de presupuestos anteriores,

adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías, y teniendo en
consideración la aparición de nuevas líneas 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 organización TI es necesario identificar
previamente todos los elementos de coste.
La estimación 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 organización 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 vaivén 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 básicos y la tecnología 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 más allá de lo razonable.
Las actividades contables deben permitir:
• Una correcta evaluación de los costes reales para su comparación 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 aplicación, los servicios TI.
Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes
como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia
organización).
Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se
pueden clasificar de forma genérica en:
• costes de hardware y software,

• costes de Personal,
• costes generales,
Asignando a cada servicio/cliente su parte proporcional.

Política de Precios
No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización, pero éste es un paso
esencial si buscamos que se utilice eficientemente la infraestructura TI.
Para que la organización TI pueda funcionar como una verdadera unidad de negocio es imprescindible tanto conocer los
costes reales de los servicios prestados como establecer una política de precios que, cuando menos, permita recuperar
los costes en los que se ha incurrido.
En primer lugar debe establecerse una política de fijación de precios. Existen múltiples opciones, entre ellas:
• Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios
(que puede ser del 0% para "clientes internos").
• Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para
servicios de similar naturaleza.
• Precio negociado: se negocia directamente con el cliente cuál 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 política de fijación de precios se deben determinar las tarifas de los servicios en función de:
• La política 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 serán usadas para una facturación real mientras que en otras sólo se utilizarán de
referencia para evaluar el rendimiento teórico de la organización TI.

Supervisión
No es tarea de la Gestión Financiera de los Servicios TI sino de la Gestión de Niveles de Servicio negociar con los
clientes y elaborar el catálogo de servicios. Sin embargo, es recomendable que, en los aspectos económicos, su actividad
sea supervisada por la Gestión Financiera.
Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos.
Por un lado la Gestión de Niveles de Servicio debe proveer información a la Gestión 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 Gestión Financiera debe aportar información sobre:
• Los costes reales de los servicios.

• Previsiones de costes.
• Desviaciones en las previsiones de costes respecto a los gastos reales.
• Métodos y condiciones de pago.
Sin una estrecha colaboración entre ambos procesos será imposible llegar a acuerdos que sean rentables y a su vez
satisfactorios para el cliente.

Control del Proceso
El responsable del proceso de Gestión Financiera no ha de ser de manera imprescindible un miembro de la organización
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 tecnología.
Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar
su éxito como unos indicadores de rendimiento específicos.
Entre los primeros cabe destacar:
• ¿Conoce la organización los costes reales de los servicios TI?

• ¿Los clientes perciben la política de precios como coherente y ajustada al mercado?
• ¿Colaboran los responsables de los otros procesos TI con la Gestión Financiera?
• ¿Están los gastos en servicios e infraestructuras TI realmente alineados con los procesos de negocio?
• ¿Opera la organización TI como una verdadera unidad de negocio?
En lo que respecta a los indicadores de rendimiento, estos deben incluir métricas que permitan evaluar si:
• Los gastos TI están 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 organización TI funciona de manera "rentable".
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según
los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto.
• Resúmenes contables.
• Análisis de eficiencia de cada uno de los servicios TI.
• Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.
• Planes de reducción de costes por servicio.

Caso Práctico
La organización TI de "Cater Matters" lleva prestando, desde hace años, servicios esenciales tanto a la propia
organización 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 específica 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 gestión de "Cater Matters" quiere desarrollar una política de fijación 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.
Para gestionar el proceso se ha nombrado a un sénior 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 colaboración con la Gestión de Configuraciones elaborar un listado de todos los CIs que intervienen
en la prestación 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: amortización, mantenimiento, fungibles, etc.
• Evaluar los costes de personal y los costes operativos.
• Estimar los costes de difícil asignación u ocultos asociados a los servicios TI.
• Evaluar los costes indirectos: instalaciones, costes administrativos, etc.
• Establecer estrictos criterios contables para la administración de los costes TI.
• Establecer una política de precios de coste adicional o "coste + margen".
Todas estas actividades buscan determinar con precisión 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 carácter general.
Pero los objetivos de una Gestión Financiera proactiva van más allá e incluyen una correcta planificación de gastos e
inversiones futuras. Para ello y en colaboración con la Gestión de Niveles de Servicio, Gestión de la Capacidad y
Gestión 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).
La información recopilada servirá de base para la elaboración de los primeros "presupuestos anuales TI" elaborados por la
Gestión Financiera.

Gestión de la Capacidad
Visión General
La Gestión 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 Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones
innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son
insuficientes con la consecuente degradación de la calidad del servicio.
Entre las responsabilidades de la Gestión 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.

El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y el propio

departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin
incurrir en costes desproporcionados.
Para ello la Gestión de la Capacidad debe:
• Conocer el estado actual de la tecnología 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 alineándolos a los procesos de negocio y
necesidades reales del cliente.
• Gestionar la demanda de servicios informáticos racionalizando su uso.

La Gestión de la Capacidad intenta evitar situaciones en las que se realizan inversiones innecesarias en tecnologías que
no están adecuadas a las necesidades reales del negocio o están sobredimensionadas, o por el contrario, evitar
situaciones en las que la productividad se ve mermada por un insuficiente o deficiente uso de las tecnologías existentes.
Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una misma organización: directivos,
clientes e informáticos deslumbrados por tecnologías que realmente no necesitan y adquieren pero que obvian
aplicaciones, equipos y servicios que realmente aumentarían la productividad en sus respectivos entornos de trabajo.
Una de las principales tareas de la Gestión de la Capacidad es la de matizar la percepción de que la "capacidad es
barata". Aunque el aumento de la capacidad puede requerir, en primera instancia, de modestos desembolsos, debido a la
reducción de costes en los equipos de hardware y aplicaciones informáticas, la administración y mantenimiento de
infraestructuras desproporcionadas puede resultar, a la larga, muy cara.
Los principales beneficios derivados de una correcta Gestión de la Capacidad son:
• Se optimizan el rendimiento de los recursos informáticos.

• 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 adecuándolo a las necesidades reales de negocio.
• Se reducen de los gastos de mantenimiento y administración asociados a equipos y aplicaciones
obsoletos o innecesarios.
• Se reducen posibles incompatibilidades y fallos en la infraestructura informática.
En resumen: se racionaliza la gestión de las compras y mantenimiento de los servicios TI con la consiguiente reducción
de costes e incremento en el rendimiento.
La implementación de una adecuada política de Gestión de la Capacidad también se encuentra con algunas serias
dificultades:
• Información insuficiente para una planificación realista de la capacidad.

• Expectativas injustificadas sobre el ahorro de costes y mejoras del rendimiento.
• Insuficiencia de recursos para la correcta monitorización del rendimiento.
• Infraestructuras informáticas distribuidas y excesivamente complejas en las que es difícil un correcto
acceso a los datos.
• No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos
asociados.
• La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes y
escenarios contemplados.
• Un correcto dimensionamiento de la propia Gestión de la Capacidad: un excesivo celo puede provocar
costosos análisis de capacidad que podrían haber sido innecesarios con la compra de nuevo hardware o
software.

Proceso
Las principales actividades de la Gestión de la Capacidad se resumen en:
• Desarrollo del Plan de Capacidad.

• Modelado y simulación de diferentes escenarios de capacidad.
• Monitorización del uso y rendimiento de la infraestructura TI.
• Gestión de la demanda.
• Creación y mantenimiento de la Base de Datos de Capacidad (CDB).
El proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad
TI desde diferentes puntos de vista:
• Gestión de la Capacidad del Negocio: que centra su objeto de atención en las necesidades futuras de
usuarios y clientes.
• Gestión de la Capacidad del Servicio: que analiza el rendimiento de los servicios TI con el objetivo de
garantizar los niveles de servicio acordados.
• Gestión 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 Gestión de la Capacidad:

Planificación
Plan de Capacidad
La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad.
El Plan de Capacidad recoge:
• Toda la información 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 tecnológicas y las necesidades
emergentes de usuarios y cliente.
El Plan de Capacidad debe incluir información sobre los costes de la capacidad actual y prevista. Esta información es
indispensable para que la Gestión Financiera pueda elaborar los presupuestos y previsiones financieras de manera
realista.
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 más compleja sea una infraestructura informática más difícil 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 simulación.
• Alcance de los incrementos de capacidad previstos.
• La "criticalidad" de los sistemas implicados.
Sopesando los anteriores factores podemos optar por:
• Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura
informática 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 informática.
• Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de la futura
infraestructura.

Recursos
Un aspecto esencial de la Gestión de la Capacidad es el de asignar recursos adecuados de hardware, software y

personal a cada servicio y aplicación.
El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:
• Los niveles de servicio acordados y/o previstos.

• Niveles de rendimiento esperados.
• Impacto de la aplicación o servicio en los procesos de negocio del cliente.
• Márgenes de seguridad y disponibilidad.
• Costes asociados a los equipos de hardware y otros recursos TI necesarios.
Es importante que la Gestión de la Capacidad participe en las primeras etapas de desarrollo de un producto, servicio o
definición de un SLA para asegurar que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término.
Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a
expectativas injustificadas sobre la tecnología. Se puede caer en el equivoco de que los costes asociados a la capacidad
se limitan a la compra de mas servidores, o más espacio de almacenamiento, etcétera, olvidando que sistemas más
complejos implican uno mayores gastos de mantenimiento y administración, o ignorando los problemas que pueden
conllevar dichos cambios.

Supervisión del Proceso
La Gestión de la Capacidad es un proceso

continuo e iterativo que monitoriza, analiza y
evalúa el rendimiento y capacidad de la
infraestructura TI y con los datos obtenidos
optimiza los servicios o eleva una RFC a la
Gestión de Cambios.
Tanto la información obtenida en estas

actividades como la generada a partir de ella por
la Gestión de la Capacidad se almacena y
registra en la Base de Datos de la Capacidad
(CDB).
Monitorización
Su objetivo principal es asegurar que el
rendimiento de la infraestructura informática se
adecua a los requisitos de los SLAs.
La monitorización debe incluir, además de

aspectos técnicos todos aquellos relativos a
licencias y otros aspectos de carácter administrativo.
Análisis y Evaluación
Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como
petición de aumento de la capacidad o una mejor Gestión de la Demanda.
Optimización y cambios
Si se ha optado por solicitar un aumento de la capacidad se elevará una RFC a la Gestión de Cambios para que se
desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su
apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones de asegurar que el cambio
solicitado cumpla los objetivos previstos.
En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o
incumplimientos de los SLAs será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso.
Base de Datos de la Capacidad

La CDB debe cubrir toda la información de negocio, financiera, técnica y de servicio que reciba y genere la Gestión 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 información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan
ser "físicamente independientes".

Gestión de la Demanda
El objetivo de la Gestión de la Demanda es el de optimizar y racionalizar el uso de los recursos TI.
Aunque la Gestión de la Demanda debe formar parte de las actividades rutinarias de la Gestión de la Capacidad ésta
cobra especial relevancia cuando existen problemas de capacidad en la infraestructura TI.
El origen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo incluyen:
• Degradación del servicio por aumentos no previstos de la demanda.

• Interrupciones parciales del servicio por errores de hardware o software.
La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios
críticos 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 Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda
actuar en consecuencia.
Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad
siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite
reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo
plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad.
Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización
se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos
automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la
mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio,
ahorrando a la organización una gravosa ampliación del ancho de banda.
Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente su contratación
directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema.
La Gestión de la Capacidad debe evaluar a priori, basandose en la experiencia y las tendencias del mercado, cuándo la
solución "más potente, más grande" es económicamente más rentable (teniendo en cuenta los costes indirectos) que un
análisis pormenorizado de la situación.

Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Capacidad.
La documentación elaborada debe incluir información sobre:
• El uso de recursos.
• Desviaciones de la capacidad real sobre la planificada.
• Análisis de tendencias en el uso de la capacidad.
• Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento.
• Impacto en la calidad del servicio, disponibilidad y otros procesos TI.
El éxito de la Gestión de la Capacidad depende algunos indicadores clave entre los que se encuentran:
• Correcta previsión de las necesidades de capacidad.

• Reducción de los costes asociados a la capacidad.
• Más altos niveles de disponibilidad y seguridad.
• Mayor satisfacción de los usuarios y clientes.
• Cumplimiento de los SLAs.

Caso Práctico
Hasta la fecha, la Gestión de las Capacidad de "Cater Matters" había sido reactiva, o en otras palabras el incremento o
redistribución de la capacidad se realizaba exclusivamente cuando aparecían los problemas.
Con el incremento de la importancia de los servicios TI, tanto para la organización de "Cater Matters" como para sus
clientes, la dirección de la empresa ha decidido implementar las mejores prácticas ITIL para la Gestión 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 atención al de los servicios online,

especialmente importantes a la hora de prestar un buen servicio a sus clientes.
• Analizar en colaboración con la Gestión de Configuraciones el impacto de los diferentes CIs en la
capacidad del sistema.
• Evaluar, en colaboración con la Gestión de Niveles de Servicio, la carga de proceso, almacenamiento
y ancho de banda que suponen los SLAs vigentes y previstos.
• Evaluar, en colaboración con la Gestión Financiera, los costes reales de cada servicio.
• Realizar informes periódicos sobre el estado de la tecnología relevante a los servicios ofrecidos.
• Analizar tendencias y estadísticas 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 extraídos de
la monitorización del sistema y de las previsiones de negocio.
• Poblar la Base de Datos de la Capacidad (CDB) para que contenga toda la información relevante a la
capacidad.
• Proponer mejoras del servicio.
Con el objetivo de:
• Minimizar el número 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 satisfacción del cliente.

Gestión de la Continuidad del Servicio
Visión General
La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y grave interrupción de los
servicios TI, debido a desastres naturales u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el
negocio.
La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:
• Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción del servicio.
• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el
desastre.
La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo
plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar un seguro médico: cuesta
dinero, parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo, pero tarde o temprano nos
alegramos de haber sido previsores.

Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:
• Garantizar la pronta recuperación de los servicios (críticos) TI tras un desastre.

• Establecer políticas 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 políticas 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 combinación de ambas.
Una correcta ITSCM debe formar parte integrante de la Gestión 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 perfección tras un desastre si nos
resulta imposible suministrar la mercancía a nuestros clientes.
Es importante diferenciar entre desastres "de toda la vida", tales como incendios, inundaciones, etcétera, y desastres
"puramente informáticos", tales como los producidos por ataques distribuidos de denegación de servicio (DDOS), virus
informáticos, etcétera. 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:
• Sólo afectan directamente a los servicios TI pero paralizan a toda la organización.

• Son más previsibles y más habituales.
• La percepción del cliente es diferente: los desastres naturales son más asumibles y no se asocian a
actitudes negligentes, aunque esto no sea siempre cierto.
Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:
• Se gestionan adecuadamente los riesgos.

• Se reduce el periodo de interrupción 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 Gestión de la Continuidad del Negocio.
Las principales dificultades a la hora de implementar la Gestión 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 organización y las tareas y actividades
correspondientes se demoran perpetuamente para hacer frente a "actividades más urgentes".
• No se realiza un correcto análisis de riesgos y se obvian amenazas y vulnerabilidades reales.
• El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de interrupción
grave de los servicios.
• Falta de coordinación con la BCM.

Proceso
Las principales actividades de la Gestión de la Continuidad del Servicio se resumen en:
• Establecer las políticas y alcance de la ITSCM.

• Evaluar el impacto en el negocio de una interrupción 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 prevención del riesgo.
• Desarrollar los planes de contingencia.
• Poner a prueba dichos planes.
• Formar al personal sobre los procedimientos necesarios para la pronta recuperación del servicio.
• Revisar periódicamente los planes para adaptarlos a las necesidades reales del negocio.

Política y Alcance
El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente es establecer
claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.
La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación
de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.
Es imprescindible establecer el alcance de la ITSCM en función de:
• Los planes generales de Continuidad del Negocio.

• Los servicios TI estratégicos.
• Los estándares de calidad adoptados.
• El histórico de interrupciones graves de los servicios TI.
• Las expectativas de negocio.
• La disponibilidad de recursos.
La Gestión 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 dimensión depende de su
alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos
correspondientes.
Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar su papel en
momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor
momento para estudiar documentación y manuales.

Análisis de Impacto
Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto que una
interrupción de los servicios TI pueden tener en el negocio.
En la actualidad casi todas las empresas, grandes y pequeñas, dependen en mayor o menor medida de los servicios
informáticos, por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del
negocio. Sin embargo, es evidente que hay servicios TI estratégicos 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 interrupción de un determinado servicio mayor habrá de ser el esfuerzo
realizado en actividades de prevención. En aquellos casos en que la "solución puede esperar" se puede optar
exclusivamente por planes de recuperación.
Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:
• Consecuencias de la interrupción del servicio en el negocio:

o Pérdida de rentabilidad.
o Pérdida de cuota de mercado.
o Mala imagen de marca.
o Otros efectos secundarios.
• Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de
negocio.
• Compromisos adquiridos a través de los SLAs.
Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperación teniendo en
cuenta sus respectivos costes financieros.

Evaluación de Riesgos
Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de
prevención y recuperación ante desastre mínimamente eficaz.
La Gestión 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 configuración (CIs)

involucrados en la prestación de cada servicio, especialmente los servicios TI críticos y estratégicos.
• Analizar las posibles amenazas y estimar su probabilidad.
• Detectar los puntos más vulnerables de la infraestructura TI.
Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes
medidas de prevención y recuperación que se adapten a las necesidades reales del negocio.
La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada, sin
embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida
implementación y relativamente baratas.
Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado debido, por ejemplo, a la localización geográfica
se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de generadores
redundantes o adquirir generadores que proporcionen la energía mínima necesaria para alimentar los CIs de los que
dependen los servicios más críticos, etcétera.

Estrategias
La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten la interrupción de los
servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en el menor tiempo posible.
Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que
ofrezcan las garantías necesarias a unos costes razonables.
Actividades preventivas
Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Algunos de ellos serán de
carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán un carácter estrictamente
informático: fallo de sistemas de almacenamiento, ataques de hackers, virus informáticos, etcétera.
La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la
Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura "física" de la organización.
La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren especial atención de la ITSCM. En este
aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad.
Los sistemas de protección habituales son los de "Fortaleza" que ofrecen protección 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 recuperación
Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevención, será necesario poner en
marcha procedimientos de recuperación.
En líneas generales existen tres opciones de recuperación del servicio:
• "Cold standby": que requiere un emplazamiento alternativo en el que podamos reproducir en pocos
días nuestro entorno de producción y servicio. Esta opción es la adecuada si los planes de recuperación
estiman que la organización 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 diseñados para
recuperar los servicios críticos en un plazo de entre 24 y 72 horas.
• "Hot standby": que requiere un emplazamiento alternativo con una replicación continua de datos y con
todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Ésta es
evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción 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 jugarán un papel importante en su organización :-)

Organización y Planificación
Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unas estrategias de
prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la Gestión de la
Continuidad del Servicio debe elaborar una serie de documentos entre los que se incluyen:
• Plan de prevención de riesgos.

• Plan de gestión de emergencias.
• Plan de recuperación.
Plan de prevención 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 alimentación eléctrica de soporte.
• Políticas de back-ups.
• Duplicación de sistemas críticos.
• Sistemas de seguridad pasivos.
Plan de gestión de emergencias

Las crisis suelen provocar "reacciones de pánico" que pueden ser contraproducentes y a veces incluso más dañinas que
las provocadas por el incidente que las causo. Por ello es imprescindible que en caso de situación de emergencia estén
claramente determinadas las responsabilidades y funciones del personal así como los protocolos de acción
correspondientes.
En principio los planes de gestión de emergencias deben tomar en cuenta aspectos tales como:
• Evaluación del impacto de la contingencia en la infraestructura TI.

• Asignación de funciones de emergencia al personal de servicio TI.
• Comunicación a los usuarios y clientes de una grave interrupción o degradación del servicio.
• Procedimientos de contacto y colaboración con los proveedores involucrados.
• Protocolos para la puesta en marcha del plan de recuperación correspondiente.
Plan de recuperación
Cuando la interrupción del servicio es inevitable llego el momento de poner en marcha los procedimientos de
recuperación.
El plan de recuperación 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 recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación

asociada ("cold o hot stand-by"), pero en general involucran:
• Asignación de personal y recursos.

• Instalaciones y hardware alternativos.

• Planes de seguridad que garanticen la integridad de los datos.
• Procedimientos de recuperación de datos.
• Contratos de colaboración con otras organizaciones.
• Protocolos de comunicación con los clientes.
Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación, cualquier decisión puede tener
graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al
proceso.
Aunque pueda resultar paradójico, un "desastre" puede ser una buena oportunidad para demostrar a nuestros clientes la
solidez de nuestra organización TI y por tanto incrementar la confianza que tiene depositada en nosotros. Ya conocen el
dicho: "No hay mal que por bien no venga".

Supervisión
Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable que estos no
queden en papel mojado y que la organización TI esté preparada para su correcta implementación.
Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y
evaluación de los planes para su adecuación a las necesidades reales del negocio.
Formación
Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben
llevarlos a cabo no están familiarizados con los mismos.
Es indispensable que la ITSCM:
• De a conocer al conjunto de la organización TI los planes de prevención y recuperación.

• Ofrezca formación específica sobre los diferentes procedimientos de prevención y recuperación.
• Realice periódicamente simulacros para diferentes tipos de desastres con el fin de asegurar la
capacitación del personal involucrado.
• Facilite el acceso permanente a toda la información necesaria, por ejemplo, a través de la Intranet o
portal B2E de la empresa.
Actualización y auditorías
Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los
requisitos de la organización en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los
planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación.
En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y
auditoria pueden establecerse de forma periódica.
La Gestión de Cambios juega un papel esencial en asegurar que los planes de recuperación y prevención estén
actualizados manteniendo informada a la ITSCM de los cambios realizados o previstos.

Control del Proceso
La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan
información relevante para el resto de la organización TI.
Estos informes deben incluir:
• Análisis sobre nuevos riesgos y evaluación de su impacto.

• Evaluación de los simulacros de desastre realizados.
• Actividades de prevención y recuperación realizadas.
• Costes asociados a los planes de prevención y recuperación.
• Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y
recuperación.
Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la "concentración".
Tras largos periodos en los que la prevención 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 inversión y compromiso inicial se diluyan y la
ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "un desastre se convierta en
una catástrofe".
Pero si el control del proceso es importante en condiciones normales éste se vuelve crítico durante las situaciones de
crisis. La ITSCM debe garantizar:
• La puesta en marcha de los planes preestablecidos.

• La supervisión de los mismos.
• La coordinación con la Gestión de Continuidad del Negocio.
• La asignación de recursos necesarios.

Caso Práctico
La organización TI de "Cater Matters" carece de una Gestión de la Continuidad del Servicio que merezca ese nombre.
La gestión de "Cater Matters" es consciente de la importancia que tienen en la actualidad los servicios TI en toda su
cadena de producción y distribución y pretende corregir esa situación.
De entre todos los servicios TI, los asociados a la gestión de existencias, por estar compuestas de productos perecederos,
y los servicios online de pedidos son considerados de importancia estratégica por la dirección de la empresa. Por ello se
decide que en primera instancia la ITSCM debe garantizar la continuidad de dichos servicios en un plazo nunca 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 Gestión de la Continuidad del Negocio.
La Gestión de la Continuidad del Negocio ha firmado acuerdos de colaboración con otras empresas de catering para
suministros de emergencia que cubran los clientes más importantes:
• Servicios de catering de colegios y hospitales.

• Congresos y eventos multitudinarios de todo tipo.
La coordinación en estos casos requiere el desarrollo de módulos especiales que permitan exportar las bases de datos de
pedidos a formatos estándar de intercambio de datos para que estos puedan ser procesados por las otras organizaciones.
Por otro lado, se desarrolla una aplicación de gestión de emergencia de las existencias que permite administrar los
pedidos a los proveedores y preservar la integridad de las existencias dependiendo de su información de caducidad y del
impacto de la interrupción del negocio en las mismas.
Se establece asimismo:
• Un calendario periódico de pruebas de los planes de recuperación.

• Un calendario de cursos de formación sobre los protocolos de actuación en situación de emergencia.
Pero la Gestión de la Continuidad del Servicio no sólo debe aplicar medidas reactivas que mitiguen el impacto de una
eventual interrupción del servicio, entre sus obligaciones se encuentran la elaboración de unos planes de prevención 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 alimentación eléctrica interrumpida.
• Replica los sistemas críticos en diferentes localizaciones geográficas.
• Supervisa la política de back-ups de los servidores de datos.
• Instala sistemas de protección perimetral.

Gestión de la Disponibilidad
Visión General
Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nos permite acceder
a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores
tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación 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
disposición del cliente prácticamente 24/7.
La Gestión 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 satisfacción del cliente
y la rentabilidad de los servicios TI dependen en gran medida de su éxito.
Las interacciones y funciones de la Gestión de la Disponibilidad se resumen sucintamente en el siguiente interactivo:

El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén 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 Gestión de la Disponibilidad incluyen:
• Determinar los requisitos de disponibilidad en estrecha colaboración 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 Gestión 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 interrupción.
• Capacidad de Servicio: determina la disponibilidad de los servicios internos y externos contratados y
su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es subcontratado en su totalidad la
disponibilidad y la capacidad de servicio son términos equivalentes.
La disponibilidad depende del correcto diseño 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 Gestión 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 número de incidentes.
Las principales dificultades con las que topa la Gestión de la Disponibilidad son:
• No se monitoriza correctamente la disponibilidad real del servicio.

• No existe compromiso con el proceso dentro de la organización TI.
• No se dispone de las herramientas de software y personal adecuado.
• Los objetivos de disponibilidad no están alineados con las necesidades del cliente.
• Falta de coordinación con los otros procesos.
• Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por
falta de apoyo de la dirección.

Proceso
Entre las actividades que la Gestión 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 operación y recuperación del mismo en caso de fallo.
• Realizar diagnósticos periódicos 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 información recopilada sobre disponibilidad, fiabilidad,
matenibilidad y cumplimiento de OLAs y UCs.
• Evaluar el impacto de las políticas de seguridad en la disponibilidad.
• Asesorar a la Gestión del Cambio sobre el posible impacto de un cambio en la disponibilidad.

Requisitos de Disponibilidad
Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de los SLAs.
La disponibilidad propuesta debe encontrase en línea tanto con los necesidades reales del negocio como con las
posibilidades de la organización TI.
Aunque en principio todos los clientes estarán 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 más allá de una pequeña inconveniencia mientras
que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u
otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio.
Para llevar a cabo eficientemente está tarea es necesario que la Gestión de la Disponibilidad:
• Identifique las actividades clave del negocio.

• Cuantifique los intervalos razonables de interrupción de los diferentes servicios dependiendo de sus
respectivos impactos.
• Establezca los protocolos de mantenimiento y revisión de los servicios TI.
• Determine las franjas horaria de disponibilidad de los servicios TI (24/7, 12/5, ...).

Planificación
La correcta planificación 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 organización 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 situación actual de disponibilidad de los servicios TI. Obviamente esta información debe ser
actualizada periódicamente.
• Herramientas para la monitorización de la disponibilidad.
• Métodos y técnicas de análisis a utilizar.
• Definiciones relevantes y precisas de las métricas 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 estándares previstos y
colabore con la Gestión de Cambios y la Gestión de Versiones en su implementación (en caso de ser aprobados, claro
está).
Para que este plan sea realista debe contar con la colaboración de los otros procesos TI involucrados.
Diseño para la Disponibilidad

Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio en el desarrollo de los nuevos
servicios TI de forma que estos cumplan los estándares plasmados en el Plan de Disponibilidad.
Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades
necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuenta futuras necesidades de
disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costes adicionales
innecesarios.

Mantenimiento y Seguridad
Aunque hayamos realizado un correcto diseño de los servicios según 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 Gestión de Incidentes y las actividades de

recuperación han de ser coordinadas por el Service Desk, la Gestión de la Disponibilidad debe prestar su
asesoramiento mediante planes de recuperación 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.
Gestión 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 actualización.
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 degradación o interrupción del servicio.
Si el servicio es 24/7 y la interrupción es necesaria se debe:
• Consultar con el cliente en que franja horaria la interrupción del servicio afectará menos a sus
actividades de negocio.
• Informar con la antelación suficiente a todos los agentes implicados.
• Incorporar dicha información a los SLAs.
Seguridad
Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la
Seguridad.
Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso.
Es tan importante determinar cuándo el servicio estará disponible como el "quién y cómo" va a utilizarlo. La
disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.

Monitorización de la Disponibilidad
La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las
principales actividades de la Gestión de la Disponibilidad.
Desde el momento de la interrupción del servicio hasta su restitución o "tiempo de parada" el incidente pasa por distintas
fases que deben ser individualizadamente analizadas:
• Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que la organización
TI tiene constancia del mismo.
• Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que se
realiza un registro y diagnóstico del incidente.
• Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar el fallo o encontrar un
"workaround" o solución temporal al mismo y devolver el sistema a la situación anterior a la interrupción del
servicio.
Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la
interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar
malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y la interpretación
puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben de poder expresarse en términos que el
cliente pueda entender.
Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente
en los informes de disponibilidad correspondientes incluyen:
• Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duración de una interrupción
de servicio, e incluye el tiempo de detección, respuesta y resolución.
• 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.

Métodos y Técnicas
Aunque llevamos hablando ya un buen rato de disponibilidad aún no hemos aportado un método 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 interrupción 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 caído durante 4 horas por tareas de
mantenimiento la disponibilidad real del servicio fue:
La Gestión de la Disponibilidad tiene a su disposición un buen número de métodos y técnicas 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 prevención, mantenimiento y recuperación, así como elaborar planes de
mejora a partir de dichos análisis.
Entre dichas técnicas se cuentan:
CFIA
Que son las siglas de Component Failure Impact Analysis (Análisis del Impacto de Fallo de Componentes).
Mediante esté método se identifica el impacto que tiene en la disponibilidad de los servicios TI el fallo de cada elemento
de configuración involucrado. Es evidente que este método requiere una CMDB correctamente actualizada.
FTA
Que son las siglas de Failure Tree Analysis (Análisis del Árbol de Fallos).
Su objetivo es estudiar cómo se "propagan" los fallos a través 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 (Método de Gestión y Análisis 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 rápidamente el servicio en caso de interrupción del
mismo.
SOA
Que son las siglas de Service Outage Analysis (Análisis de Interrupción del Servicio).
Ésta técnica tiene como objetivo analizar las causas de los fallos detectados y proponer soluciones a los mismos.
Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente haciendo especial

énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI.
Control del Proceso
La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyan información
relevante tanto para los clientes como para el resto de la organización TI.
Estos informes deben incluir:
• Técnicas y métodos utilizados para la prevención y el análisis de fallos.

• Información estadística sobre:
o Tiempos de detección y respuesta a los fallos.
o Tiempos de reparación y recuperación 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 información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas
precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. Por
ejemplo, en el caso de un servicio online de comercio electrónico se puede considerar que tiempos de respuesta
superiores a 10 segundos son equivalentes a que el sistema esta caído, aunque estrictamente hablando el sistema
termine respondiendo.

Caso Práctico
La disponibilidad 12/7 es algo a lo que los clientes de "Cater Matters" otorgan una gran importancia.
Los servicios TI sólo juegan una pequeña, aunque importante, parte en los servicios prestados por la organización a sus
clientes y los problemas de disponibilidad suelen proceder de procesos no directamente ligados con la tecnología. Sin
embargo, una interrupción de los servicios online pueden presuponer un grave problema dado el alto volumen de pedidos
que se reciben por dicho canal, la práctica totalidad, así como su importancia en el apartado de la gestión de stocks de
materia prima.
La Gestión de la Disponibilidad, en colaboración con los responsables de otros procesos TI ha sido encargada de
elaborar nuevos planes de disponibilidad que tengan en cuenta un rápido crecimiento del negocio que puede implicar una
disponibilidad 24/7 para diferentes líneas de negocio.
La elaboración de este nuevo plan requiere:
• La revisión de los UCs en vigor con los proveedores de servicios de Internet.

• Definición de niveles de disponibilidad para los nuevos servicios.
• Diseño para la disponibilidad 24/7 de los servicios TI ofrecidos.
• Nuevos planes de gestión del mantenimiento que ahora requerirán una interrupción real del servicio.
Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a sus clientes sobre los niveles de
rendimiento y disponibilidad de los diferentes servicios prestados. Para ello ha encargado a la Gestión de la
Disponibilidad que implante los procedimientos necesarios para la medición 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 complementarán con un módulo de cálculo estadístico y de generación automática de informes sobre el
cumplimiento de los niveles de disponibilidad acordados para cada cliente.
De esta forma "Cater Matters" busca entablar una relación de confianza con sus clientes y mantener a la organización TI
alerta sobre posibles degradaciones de los niveles de calidad del servicio.

Gestión de la Seguridad
Visión General
La Gestión de la Seguridad de la Información se remonta al albor de los tiempos. La criptología o la ciencia de la

confidencialidad de la información se remontan al inicio de nuestra civilización y ha ocupado algunas de las mentes
matemáticas más brillantes de la historia, especialmente (y desafortunadamente) en tiempos de guerra.
Sin embargo, desde el advenimiento de las ubicuas redes de comunicación y en especial Internet los problemas asociados
a la seguridad de la información se han agravado considerablemente y nos afectan prácticamente a todos. Que levante la
mano el que no haya sido víctima de algún virus informático en su ordenador, del spam (ya sea por correo electrónico o
teléfono) por una deficiente protección de sus datos personales o, aún peor, del robo del número de su tarjeta de crédito.
La información es consustancial al negocio y su correcta gestión debe apoyarse en tres pilares fundamentales:
• Confidencialidad: la información debe ser sólo accesible a sus destinatarios predeterminados.

• Integridad: la información debe ser correcta y completa.
• Disponibilidad: debemos de tener acceso a la información cuando la necesitamos.
La Gestión de la Seguridad debe, por tanto, velar por que la información sea correcta y completa, esté siempre a
disposición del negocio y sea utilizada sólo por aquellos que tienen autorización para hacerlo.
Las interacciones y funciones de la Gestión de la Seguridad se resumen sucintamente en el siguiente interactivo:

Los principales objetivos de la Gestión de la Seguridad se resumen en:
• Diseñar una política de seguridad, en colaboración con clientes y proveedores correctamente alineada
con las necesidades del negocio.
• Asegurar el cumplimiento de los estándares de seguridad acordados.
• Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.
La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de "expertos en seguridad" que desconocen los
otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma
limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y
la apertura de nuevas redes y canales de comunicación.
La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para
establecer protocolos de seguridad que aseguren que la información esté accesible cuando se necesita por aquellos que
tengan autorización para utilizarla.
Una vez comprendidos cuales son los requisitos de seguridad del negocio, la Gestión de la Seguridad debe supervisar
que estos se hallen convenientemente plasmados en los SLAs correspondientes para, a renglón seguido, garantizar su
cumplimiento.
La Gestión 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 Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden
suponer los cambios realizados en la infraestructura, nuevas líneas de negocio, etcétera.

Los principales beneficios de una correcta Gestión de la Seguridad:
• Se evitan interrupciones del servicio causadas por virus, ataques informáticos, etcétera.
• Se minimiza el número de incidentes.
• Se tiene acceso a la información 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 protección de datos.
• Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.
Las principales dificultades a la hora de implementar la Gestión de la Seguridad se resumen en:
• No existe el suficiente compromiso de todos los miembros de la organización TI con el proceso.

• Se establecen políticas 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 formación adecuada para la aplicación de los protocolos de seguridad.
• Falta de coordinación entre los diferentes procesos lo que impide una correcta evaluación de los riesgos.

Proceso
La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TI y necesita
para su éxito la colaboración de toda la organización.
Para que esa colaboración sea eficaz es necesario que la Gestión de la Seguridad:
• Establezca una clara y definida política de seguridad que sirva de guía 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 evalúe el cumplimiento de dicho plan.
• Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y
vulnerabilidades.
• Realice periódicamente auditorías de seguridad.

Política de Seguridad
Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la
Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos
tales como los objetivos, responsabilidades y recursos.
En particular la Política de Seguridad debe determinar:
• La relación con la política general del negocio.

• La coordinación con los otros procesos TI.
• Los protocolos de acceso a la información.
• Los procedimientos de análisis de riesgos.
• Los programas de formación.
• El nivel de monitorización de la seguridad.
• Qué informes deben ser emitidos periódicamente.
• El alcance del Plan de Seguridad.
• La estructura y responsables del proceso de Gestión 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 colaboración con la Gestión 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 organización TI
y los proveedores externos.
El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo
para el desarrollo de sus actividades de negocio.
Siempre que sea posible deben definirse métricas 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 más débil de sus
eslabones", por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene
vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo
ofreciendo la imagen de "fortaleza" pero esto valdrá de poco si alguien descubre que la "puerta de atrás está abierta".

Aplicación de las Medidas de Seguridad
Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.
Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad

establecidas en la Política y el Plan de Seguridad.
En primer lugar la Gestión de la Seguridad debe verificar que:
• El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al
respecto.
• Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
• Se imparte la formación pertinente.
Es también responsabilidad directa de la Gestión de la Seguridad:
• Asignar los recursos necesarios.

• Generar la documentación de referencia necesaria.
• Colaborar con el Service Desk y la Gestión de Incidentes en el tratamiento y resolución de incidentes
relacionados con la seguridad.
• Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad.
• Colaborar con la Gestión de Cambios y Versiones para asegurar que no se introducen nuevas
vulnerabilidades en los sistemas en producción o entornos de pruebas.
• Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad.
• Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y
confidencialidad de los datos en caso de desastre.
• Establecer las políticas y protocolos de acceso a la información.
• Monitorizar las redes y servicios en red para detectar intrusiones y ataques.
Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión 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.

Evaluación y Mantenimiento
Evaluación
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 auditorías de seguridad
externas y/o internas realizadas por personal independiente de la Gestión de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmaran en RFCs
que habrán de ser evaluados por la Gestión de Cambios.
Independientemente de estas evaluaciones de carácter periódico se deberán generar informes independientes cada vez
que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera
oportuno, estos informes se acompañaran de las RFCs correspondientes.
Mantenimiento
La Gestión de la Seguridad es un proceso continuo y se han de mantener al día 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 evaluación arriba citada o de cambios
implementados en la infraestructura o servicios TI.
No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas.
Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y
vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas
necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es
normalmente el eslabón más débil 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 Gestión
de la Seguridad cumple sus objetivos.
Una buena Gestión de la Seguridad debe traducirse en una:
• Disminución del número de incidentes relacionados con la seguridad.

• Un acceso eficiente a la información por el personal autorizado.
• Gestión proactiva que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten
y provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información 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.
• Relación de incidentes relacionados con la seguridad calificados por su impacto sobre la calidad del
servicio.
• Evaluación de los programas de formación impartidos y sus resultados.
• Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.
• Auditorías de seguridad.
• Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.

Caso Práctico
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de
"fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos
pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el
núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información
preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de
seguridad de los SLAs en vigor.
Como medidas de seguridad básicas:
• Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán
disponer del servicio.
• Se implementan protocolos de encriptación de los archivos XML intercambiados.
• Se requiere autenticación para el acceso al servicio.
• Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
• Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
• Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la
empresa.
Se propone una evaluación periódica 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 rápido
desarrollo en el que la competencia se encuentra a un "solo clic de distancia".


Itil

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Itil

Încărcat de

Drepturi de autor:

Formate disponibile

ITIL

Fuente de contenidos principal: http://itil.osiatis.es

ITIL – Gestión de Servicios TI Página 1 de 151

ITIL – Gestión de Servicios TI Página 2 de 151

ITIL – Gestión de Servicios TI Página 3 de 151

Los objetivos de una buena gestión de servicios TI han de ser:

• Proporcionar una adecuada gestión de la calidad

• Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos

ITIL – Gestión de Servicios TI Página 4 de 151

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido

ITIL – Gestión de Servicios TI Página 5 de 151

ITIL – Gestión de Servicios TI Página 6 de 151

ITIL – Gestión de Servicios TI Página 7 de 151

El ITSMF es el único Forum completamente indpendiente reconocido por el sector

ITIL – Gestión de Servicios TI Página 8 de 151

• Foundation Certificate en Gestión de Servicios TI

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

ITIL – Gestión de Servicios TI Página 9 de 151

• Servicios de comedor de grandes empresas.

ITIL – Gestión de Servicios TI Página 10 de 151

• Registrando y monitorizando incidentes.

ITIL – Gestión de Servicios TI Página 11 de 151

• Resolver rápidamente las interrupciones del servicio.

• Reducción de costes mediante una eficiente asignación de recursos.

ITIL – Gestión de Servicios TI Página 12 de 151

• Cuáles son las necesidades.

• Establecer estrictos protocolos de interacción con el cliente.

ITIL – Gestión de Servicios TI Página 13 de 151

• Sea fácilmente accesible.

• Conocer todos los protocolos de interacción con el cliente: guiones, checklists,...

Existen tres formatos básicos:

Describimos a continuación sus principales características:

Service Desk Centralizado

Sus ventajas principales son:

• Se reducen los costes.

Sin embargo surgen importantes inconvenientes cuando:

• Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y

ITIL – Gestión de Servicios TI Página 14 de 151

• Es generalmente más caro.

Service Desk Virtual

En un Service Desk virtual:

• El "conocimiento" está centralizado.

ITIL – Gestión de Servicios TI Página 15 de 151

Entre sus tareas específicas se incluyen:

• Registro y monitorización de cada incidente.

Relaciones con los proveedores

ITIL – Gestión de Servicios TI Página 17 de 151

Idealmente, el personal del Service Desk debe:

• Compartir la filosofía de atención al cliente de la organización.

También es imprescindible el compromiso de la dirección con:

• Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.

ITIL – Gestión de Servicios TI Página 18 de 151

En los informes de control se deben considerar aspectos tales como:

ITIL – Gestión de Servicios TI Página 19 de 151

Para ello se han adoptado las siguientes decisiones:

• Se ha nombrado un gestor responsable del Service Desk.

• Creación de un detallado plan de implantación progresiva del Service Desk .

ITIL – Gestión de Servicios TI Página 20 de 151

Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo:

ITIL – Gestión de Servicios TI Página 21 de 151

Los objetivos principales de la Gestión de Incidentes son:

• Detectar cualquiera alteración en los servicios TI.

El siguiente diagrama resume el proceso de gestión de incidentes:

Los principales beneficios de una correcta Gestión de Incidentes incluyen: