ISO20000 GuiaCompletadeAplicacion LuisMoran

ISO/IEC 20000.
Gua completa de aplicacin

para la gestin de los servicios
de tecnologas de la informacin
Ttulo: ISO/IEC 20000. Gua completa de aplicacin para la gestin de los servicios de tecnologas de la informacin
Telefnica, S.A.
Coordinador: Luis Morn Abad
AENOR (Asociacin Espaola de Normalizacin y Certificacin), 2009

Todos los derechos reservados. Queda prohibida la reproduccin total o parcial en cualquier soporte,
sin la previa autorizacin escrita de AENOR.
Crown copyright 2007 All rights reserved. Material is reproduced with the permission of the Office of
Government Commerce under delegated authority from the Controller of HMSO.
Licensed Product
ITIL is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
The Swirl logo is a Trade Mark of the Office of Government Commerce.
The OGC logo is Registered Trade Mark of the Office of Government Commerce in the United Kingdom.
PRINCE is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
IT Infrastructure Library is Registered Trade Mark of the Office of Government Commerce in the United
Kingdom and other countries.
M_o_R is Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
ISBN: 978-84-8143-662-4
Depsito Legal: M-47292-2009
Impreso en Espaa - Printed in Spain
Edita: AENOR
Maqueta y diseo de cubierta: AENOR
Imprime: Xxxxxx
Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.
Gnova, 6. 28004 Madrid Tel.: 902 102 201 Fax: 913 103 695
comercial@aenor.es www.aenor.es
Este libro est dedicado a todos los
profesionales de tecnologas de la
informacin y las comunicaciones que
abnegadamente han aportado sus
conocimientos y experiencia para la definicin
y difusin de las normas y las mejores
prcticas que marcan el camino
de evolucin de este sector.
Agradecimientos
Este libro recopila las experiencias de profesionales que estn fuertemente involu-
crados en el impulso de las normas y las buenas prcticas internacionales relativas a
la gestin de las tecnologas de la informacin y las comunicaciones.
En la creacin de esta primera edicin del libro han participado:
Direccin de la obra (Telefnica):
Luis Morn Abad Direccin tcnica y contenido final.
Alejandro Prez Snchez Contenido intermedio.
Autores principales (Telefnica):

Luis Morn Abad
Alejandro Prez Snchez
Juan Trujillo Gaona
David Bathiely Fernndez
Miguel Jos Gonzlez-Simancas Sanz
Colaboradores:
Paloma Garca Lpez (AENOR)
Carlos Manuel Fernndez Snchez (AENOR)
Eduardo Mndez Polo (Telefnica)
Jaime Pastor Pastor (Telefnica)
8 ISO/IEC 20000. Gua completa de aplicacin para la gestin de los servicios de tecnologas de la informacin
Toms Hernndez Lpez (Telefnica)

Carmen Fernndez Prieto (Telefnica)
Mara Luisa Lpez de Castro (Telefnica)
Julio Morilla Padial (Telefnica)
Andrs Leiva Araos (Telefnica)
Ronaldo Gonalves Tiago (Telefnica)
Julio Jos Ballesteros Garca (Quint Group)
Luis Miguel Rosa Nieto (EXIN Espaa)
Pablo Castro Montero
(Entre parntesis se indica la empresa en la que trabajaban a fecha 01.01.2009.)
El control independiente de idoneidad tcnica de los contenidos est avalado

por profesionales de itSMF Espaa y de AENOR, junto con otros profesio-
nales independientes:
Carlos Lpez Alonso (Hewlett-Packard) por itSMF Espaa
Antonio Jos Rodrguez (Quint Group) por itSMF Espaa
Ana Ramos (British Telecom) por itSMF Espaa
Leopoldo Martnez-Osorio del Ro (INDRA) por itSMF Espaa
Carmen Caballero (INDRA) por itSMF Espaa
Manuel Fernando Juan Martnez (Banco de Santander)
Julio Gonzlez Sanz
Boris Delgado Riss (AENOR)
Agradecer tambin a la direccin de Sistemas de Informacin de Telefnica que de

forma directa ha hecho posible esta publicacin:
Mara Fernanda Torquati (Telefnica)
Jos Mara Tavera Ms (Telefnica)
Fabriciano Gangoso Alonso (Telefnica)
Isidro Abad Gosalvez (Telefnica)
ndice
Presentacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Captulo 1. El camino a la excelencia ya existe . . . . . . . . . . . . . . . . . . . . . 21

1.1. Las Normas ISO/IEC 20000 son parte del camino a la excelencia . . . . . 23
1.2. Normas, estndares, marcos de referencia y metodologas reconocidas
en el mbito de las TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3. Entender los entornos de normalizacin y certificacin . . . . . . . . . . . . . . 27
1.4. Las principales normas y buenas prcticas en TI . . . . . . . . . . . . . . . . . . . 37
Captulo 2. Entender las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . 51

2.1. Introduccin a las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . . 53
2.2. Objeto y campo de aplicacin de ISO/IEC 20000 . . . . . . . . . . . . . . . . . 65
2.3. La estructura de las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . 70
2.4. Relacin entre ISO/IEC 20000 e ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Captulo 3. El Sistema de Gestin del Servicio de TI (SGSTI) . . . . . . . . . . . . 79

3.1. El sistema de gestin de tecnologas de la informacin . . . . . . . . . . . . . . 83
Captulo 4. Planificacin e implementacin de la gestin del servicio . . . . . 107

4.1. Cmo planificar e implementar la gestin del servicio . . . . . . . . . . . . . . 111
Captulo 5. Planificacin e implementacin de nuevos servicios o de

servicios modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.1. El proceso de planificacin e implementacin de nuevos servicios o de
servicios modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Captulo 6. Procesos de provisin de servicio . . . . . . . . . . . . . . . . . . . . . . . 191

6.1. Gestin de nivel de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.2. Generacin de informes del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.3. Gestin de la continuidad y disponibilidad del servicio . . . . . . . . . . . . . . 279
6.4. Elaboracin de presupuestos y contabilidad de los servicios de TI . . . . . . 331
6.5. Gestin de la capacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
6.6. Gestin de la seguridad de la informacin . . . . . . . . . . . . . . . . . . . . . . 403
Captulo 7. Procesos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

7.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
7.2. Gestin de las relaciones con el negocio . . . . . . . . . . . . . . . . . . . . . . . . 457
7.3. Gestin de suministradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Captulo 8. Procesos de resolucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

8.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
8.2. Gestin del incidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
8.3. Gestin del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Captulo 9. Procesos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

9.1. Gestin de la configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
9.2. Gestin del cambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Captulo 10. Procesos de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

10.1. Gestin de la entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Captulo 11. La certificacin conforme a ISO/IEC 20000 de la gestin

del servicio de TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
11.1. La primera certificacin conforme a ISO/IEC 20000 . . . . . . . . . . . . . . 737
11.2. Evidencias y registros importantes en una certificacin . . . . . . . . . . . . . 751
ndice 11
Bibliografa y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Trminos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Presentacin
Las tecnologas de la informacin son cada da ms necesarias en la gestin de las

empresas.
Este sector, en su evolucin hacia la madurez, ha ido generando diversos conjuntos
de mejores prcticas que ayudan a las organizaciones a gestionar estos entornos tec-
nolgicos cada vez ms complicados y, por otra parte, ms esenciales.
Este libro nace con la intencin de ayudar a todo tipo de empresas en la gestin
de la actividad de sus departamentos informticos. Profesionales de Telefnica y de
AENOR han puesto su mejor empeo en explicar y aportar sus aos de experien-
cia en este mbito. Para ello, se ha utilizado como eje vertebrador las Normas
UNE-ISO/IEC 20000, que se enriquecen con las buenas prcticas de otros marcos
como ITIL.
Los autores han desarrollado una buena gua sobre la forma de incorporar estas
mejores prcticas de la industria en la gestin diaria de las tecnologas. Esta publi-
cacin ayudar a las empresas a adoptar los ltimos avances en la forma de organizar
las actividades que contribuyen a que el mundo tecnolgico sea operativo y rentable
para las organizaciones y para la sociedad.
Esperamos que todo su contenido sea de gran utilidad en la mejora de los servicios
de tecnologas de la informacin prestados en su organizacin.
Telefnica
Introduccin
Durante la dcada de los aos 50, algunas predicciones futuristas imaginaron que,
para el ao 2000, los coches seran capaces de volar, se ira de vacaciones a Marte, y
que Estados Unidos podra llegar a contar con nada menos que trescientos mil
ordenadores. En 1947 el director de una famosa multinacional del sector predijo
que en el mundo slo habra mercado para 5 ordenadores. Estas predicciones hoy
en da nos parecen ridculas, unas por lo exageradas, y otras por que se han que-
dado muy cortas.
Las tecnologas de la informacin y las comunicaciones han avanzado mucho ms
de lo esperado, pero despus de poblar el mundo de dispositivos de silicio, con
unas capacidades de proceso inimaginables, nos encontramos con un panorama
desalentador:
Equipos que se bloquean.
Sistemas que se caen.
Servicios que se interrumpen.
Atencin al usuario deficiente.
Prdidas de tiempo y de productividad de los usuarios.
Personal tcnico desbordado por llamadas y peticiones de asistencia.
Directores de sistemas de informacin que ven cmo, a pesar del esfuerzo con-
tinuo de su equipo, el roce y el malestar con el resto de la empresa no cesan.
Por ello, no es de extraar que encontremos frecuentemente que los departamentos

de las tecnologas de la informacin (TI) se consideren ms una carga que una
ayuda para el negocio.
La dinmica industria de tecnologas de la informacin y las comunicaciones

(TIC), que es capaz de duplicar la capacidad de proceso y de almacenamiento cada
ao y medio, lleva desarrollando, en paralelo al avance tecnolgico, metodologas
de trabajo que van ofreciendo soluciones de gestin a estos retos planteados. El sec-
tor de las TIC ha ido creando distintas disciplinas para cubrir algunas de las facetas
que necesita la gestin global de las TIC en la empresa. Soluciones que no siempre
se han aplicado con el ahnco y el rigor necesarios.
Parece lgico que los organismos de normalizacin internacionales, como ISO (Inter-
national Organization for Standardization, Organizacin Internacional de Normaliza-
cin) e IEC (International Electrotechnical Commission, Comisin Electrotcnica
Internacional), propicien la elaboracin de normas que van consolidando las prcti-
cas establecidas relativas a la organizacin del trabajo en las reas de TI. Adems,
estos organismos de normalizacin disponen de mecanismos de trabajo asentados
que garantizan una amplia participacin de los agentes del sector de las TIC. Este es
el caso de las Normas ISO/IEC 20000, partes 1 y 2, y sus traducciones oficiales al
castellano, publicadas por AENOR como Normas UNE-ISO/IEC 20000 1 en junio
de 2007. El presente libro se centra en explicar la aplicacin de estas dos normas.
Las Normas ISO/IEC 20000 definen los procesos y las actividades esenciales para
que las reas de TI puedan prestar un servicio eficiente y alineado con las necesida-
des de la empresa u organizacin. Estas normas, construidas sobre la base del
modelo ITIL, se centran principalmente en la ordenacin de las disciplinas de
soporte y provisin de servicios de TI. Son normas especficas para la gestin de los
servicios que ofrecen las reas o los proveedores de tecnologas de la informacin.
Las Normas ISO/IEC 20000 no son de ndole tcnico, ni tecnolgico. En ellas se
describen los principales flujos de actividades (agrupados en forma de procesos) cuyo
fin es lograr una entrega efectiva y con la calidad requerida de los servicios a los clien-
tes y usuarios. Adems, definen un sistema reconocido y probado de gestin que per-
mite a los proveedores de TI (ya sean reas internas u organizaciones externas) plani-
ficar, gestionar, entregar, monitorizar, informar, revisar y mejorar sus servicios.
Objeto del libro

Este libro se centra en explicar y facilitar la comprensin de las Normas ISO/IEC
20000 con un enfoque prctico, para que su implantacin resulte efectiva en
1 Para facilitar la lectura, en el resto del libro se ha optado por utilizar el mismo trmino
ISO/IEC 20000 para referirse a estas normas, tanto para la serie UNE, como para la serie
ISO/IEC.
Introduccin 17
cualquier tipo de organizacin que provea servicios de tecnologa, tanto interna-

mente a su organizacin como externamente al mercado, tanto en grandes orga-
nizaciones como en pequeas o medianas empresas.
Este libro va dirigido a todos los profesionales del mbito de las tecnologas de la
informacin y las comunicaciones que estn involucrados en la provisin de servi-
cios. Resultar imprescindible tanto a los responsables de su gestin, como a cual-
quier otro profesional de TI: direccin, gestores, responsables de procesos, consul-
tores, tcnicos, personal de soporte, etc.
Al avanzar en este libro, el lector constatar que la industria ya ha normalizado
gran parte del conjunto de actividades necesarias para que los servicios propor-
cionados por las TI sean fiables y eficientes. Cubren desde las actividades del da
a da inmediato, como es la atencin a los incidentes y peticiones, hasta la defi-
nicin de una estrategia que permita continuar prestando los servicios en caso
de catstrofe, todo ello, sin olvidar conceptos como la planificacin o la mejora
continua.
Persiguiendo este fin ltimo de utilidad, los contenidos de cada apartado, adems
de incluir ntegramente la norma, se han enriquecido con otras buenas prcticas
ITIL y con la amplia experiencia profesional de los autores.
Por tanto, este libro pretende ser una gua completa de aplicacin, una ayuda y una
razonable interpretacin de estas normas. No pretende sentar jurisprudencia al
respecto. Los autores dan por hecho que puede haber otras formas de aplicar o
interpretar las directrices de las normas, ya que las particularidades de cada negocio
y organizacin tienen gran influencia.
Estructura del libro

Se ha puesto nfasis en que los contenidos ayuden a la transformacin real y per-
ceptible de la gestin de las TI en toda empresa que se inicie en el camino de la apli-
cacin de ISO/IEC 20000.
El captulo 1 El camino a la excelencia ya existe, introduce al lector en las nue-
vas tendencias de gestin de las TI, como son: la orientacin a procesos, la cali-
dad, las normas y las mejores prcticas. La intencin del captulo es presentar el
amplio, y cada vez ms complejo, entorno normativo y de mejores prcticas. Se
conocer quines son los principales actores en estos mbitos y se tendr una
primera aproximacin de cmo se posiciona cada norma o iniciativa. Este cap-
tulo es un paso previo, que proporciona una visin general de todo este escena-
rio internacional, antes de zambullirse en las especificidades de las Normas
ISO/IEC 20000.
El captulo 2 Entender las Normas ISO/IEC 20000 las posiciona en el mbito

global de las TIC, para pasar despus a explicar su alcance, su estructura, sus coin-
cidencias y las principales diferencias frente a ITIL. Este captulo resulta esencial
para entender adecuadamente los siguientes.
Para facilitar la comprensin, el ncleo central del libro, desde el captulo 3 al 10,
se organiza siguiendo una estructura de captulos y numeracin de apartados para-
lela a las normas de referencia. En la figura I.1 se muestra este paralelismo inten-
cionado.
El captulo 3 El Sistema de Gestin del servicio de TI (SGSTI), explica este con-
cepto que suele resultar nuevo para los profesionales de las TIC no acostumbrados
a los sistemas de gestin definidos en la normativa de calidad ISO. Explica con
detalle la creacin de un sistema de gestin aplicado a la provisin y soporte del
servicio de tecnologas de la informacin. Este sistema de gestin constituye en s
mismo el diseo de las nuevas formas de hacer que transformarn el servicio de TI.
Su utilizacin ofrece un valor aadido y permitir alcanzar una posicin diferencial
a las organizaciones que lo implementen.
En el captulo 4 Planificacin e implementacin de la gestin del servicio, se trata
la implantacin de las Normas ISO/IEC 20000. Explica la forma de organizar y lle-
var a cabo esta transformacin que suponen las nuevas formas de hacer, acordes con
estas normas y definidas en el sistema de gestin. Se explican los aspectos que hay
que tener en cuenta previos a la implantacin, para entrar posteriormente en el ciclo
de mejora continua. Se sigue el enfoque a las cuatro etapas del ciclo de mejora con-
tinua (PDCA, de Deming o de Shewhart), que tambin se explica en este captulo.
Los captulos del 5 al 10 se corresponden con los principales procesos identificados
en la gestin del servicio relativos a: creacin, provisin, relaciones, resolucin,
control y entrega del servicio.
En el libro, tambin se ha considerado que las empresas, adems de mejorar sus ser-
vicios de TI, quieren obtener una certificacin que les acredite ante su Direccin o
ante sus clientes de la conformidad de su gestin frente a los requisitos de estas nor-
mas de referencia. A este respecto, el captulo 11 es una gua que explica el proceso
habitual para obtenerla.
El libro se ha preparado para que se pueda leer en tres recorridos diferentes:
Recorrido 1: lectura rpida. Paso rpido por los conceptos del libro, sin
profundizar en los procesos. Este recorrido pasa por la lectura de los captu-
los 1, 2 y 3 en detalle, pues contienen conceptos y posicionamientos que
nadie debera descartar. A partir de este punto, el resto de los captulos y pro-
cesos tienen su introduccin y grficos que resumen los principales concep-
tos que todo involucrado en las TI debera conocer.
Introduccin 19
ndice de las Normas ISO/IEC 20000 ndice del libro ISO 20000
1 Objeto y campo de aplicacin 0 Introduccin
2 Trminos y definiciones 1 El camino de la excelencia ya exite
2 Entender las normas ISO/IEC 20000
3 Requisitos de un sistema de gestin 3 El Sistema de Gestin del Servicio de TI (SGSTI)
4 Planificacin e implementacin de la gestin del servicio
5 Planificacin e implementacin de nuevos servicios o de servicios modificados
6 Procesos de la provisin del servicio

6.1 Gestin de nivel de servicio
6.2 Generacin de informes del servicio
6.3 Gestin de la continuidad y disponibilidad del servicio
6.4 Elaboracin de presupuesto y contabilidad de los servicios de TI (gestin financiera de TI)
6.5 Gestin de la capacidad
6.6 Gestin de la seguridad de la informacin
7 Procesos de relaciones
7.1 Generalidades
7.2 Gestin de las relaciones con el negocio
7.3 Gestin de suministradores
8 Procesos de resolucin
8.1 Antecedentes
8.2 Gestin del incidente
8.3 Gestin del problema
9 Procesos de control
9.1 Gestin de la configuracin
9.2 Gestin del cambio
10 Proceso de entrega
10.1 Proceso de gestin de la entrega
11 La certificacin conforme a ISO/IEC 20000

de la gestin del servicio de TI
11.1 La primera certificacin conforme
a ISO/IEC 20000
11.2 Evidencia y registros importantes en una
certificacin
Bibliografa 12 Bibliografa y referencias
13 Trminos y definiciones
Figura I.1. La estructura del libro transcurre paralela

a las Normas ISO/IEC 20000
Recorrido 2: lectura secuencial y a fondo. De principio a fin, que es la

recomendada por los autores.
Recorrido 3: manual de consulta. La estructura del libro con temtica
independiente permite utilizarlo tambin como manual de consulta, acce-
diendo directamente a cada proceso.
1 El camino a la excelencia
ya existe
Captulo 1
1.1. Las Normas ISO/IEC 20000 son parte del camino a la excelencia
1.2. Normas, estndares, marcos de referencia y metodologas reconocidas
en el mbito de las TI
1.3. Entender los entornos de normalizacin y certificacin
1.4. Las principales normas y buenas prcticas en TI
0
50
38
BIT
MI CO
CM
0 1
ITIL 2 70
0 00 000
9 20
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
1. El camino a la excelencia ya existe 23
1.1. Las Normas ISO/IEC 20000 son parte del

camino a la excelencia
Comparando la gestin habitual de las tecnologas de la informacin con otras
reas de la empresa, podremos encontrar que, en las ms avanzadas, existen mode-
los de gestin firmemente establecidos que las hacen parecerse al modelo de una
orquesta sinfnica en la que, si bien cada msico es un excelente especialista en su
instrumento, es en la interpretacin del concierto cuando la orquesta demuestra su
autntico valor actuando como un todo.
En cambio, las reas que gestionan sistemas tecnolgicos han puesto tradicional-
mente el foco en el conocimiento y dominio de la tecnologa. Es esencial y obvio
que se necesitan buenos tcnicos para el diseo, la construccin y el mantenimiento
del hardware y del software. Sin embargo, la situacin actual refleja que el control
de la tcnica, aunque totalmente imprescindible, no es suficiente para satisfacer
todo lo que la empresa demanda de las reas de TI. Queda una importante asigna-
tura pendiente que, por ms que se invierta en tecnologa y en tcnicos, no se con-
sigue resolver: actuar perfectamente engranados, todos juntos y bien coordinados
para conseguir un fin comn: ser cada vez ms eficientes en costes y capaces
de evolucionar con la agilidad tpica del ecosistema Internet (objeto de deseo de
todos los negocios para sus reas de TI).
Los responsables de los departamentos de TI deben responder a importantes des-
afos: la eficiencia en costes, la calidad, el cumplimiento de plazos, la agilidad y la
satisfaccin de los clientes y usuarios estn entre ellos. La gestin de las TI debe
evolucionar desde los modelos artesanales hacia formas de hacer ms industrializa-
das. Implementar formas de trabajo repetibles, mejorando la calidad de lo cons-
truido, la fiabilidad de los servicios o aumentando la capacidad de produccin de
la organizacin, todo ello, dentro de un nuevo entorno ms fluido en las relaciones
y que genere menos estrs en las personas. En esta evolucin, las buenas prcticas
sectoriales recogidas en las Normas ISO/IEC 20000, en los libros ITIL, en otras
normas y marcos de referencia, marcan el camino a recorrer para alcanzar la exce-
lencia en la gestin de las TI.
Del mismo modo que un abogado debe conocer las leyes para ejercer su profesin,
o un arquitecto la legislacin y reglamentacin sobre urbanismo y edificacin; la
direccin y los profesionales de los departamentos de TI deben conocer con detalle
el conjunto de buenas prcticas, normas o estndares que se estn consolidando en
su propio sector. La actividad de los directivos y profesionales de las TI, debe pasar
por conocer con detalle la normativa y marcos de las mejores prcticas aceptados
por el mercado, para aplicarlas posteriormente en su organizacin. Este es un buen
camino para la mejora de las actividades.
1.2. Normas, estndares, marcos de referencia

y metodologas reconocidas en el mbito
de las TI
El mundo de la ciencia est empeado en la bsqueda de una ley universal que sea
vlida tanto para el mundo del tomo como para las grandes galaxias. De manera
anloga, en el mbito de las TI todava no se ha conseguido definir un modelo for-
mal universal de toda su actividad que contemple desde la ms detallada tarea tc-
nica, hasta la definicin al ms alto nivel de la estrategia alineada con el negocio.
El inters por mejorar las actividades de las TI ha hecho que se hayan ido desarro-
llando varios marcos o modelos que cubren las principales parcelas de la gestin y
del conocimiento. A veces son complementarios entre s, en otros aspectos se sola-
pan y, con frecuencia, presentan enfoques distintos sin ofrecer una integracin clara
con otros modelos o aproximaciones. A pesar de ello, es indudable la utilidad de
trabajar con stos modelos de referencia ya definidos y los beneficios que aportan a
las organizaciones que los utilizan como base para avanzar.
Una buena representacin que permite realizar una primera aproximacin a este
mundo en ebullicin de normas, modelos y marcos de referencia, es la realizada por
la consultora Gartner Group, presentada en la figura 1.1. En ella, se posicionan las
normas en funcin de dos conceptos: el mbito de aplicacin y el tipo de uso de la
normativa. El mbito de aplicacin de las normas ocupa las columnas de la tabla y
se divide en dos alcances: el general de la empresa y las disciplinas especficas de TI
(gobierno de TI, gestin del servicio de TI, funciones de TI y tecnologa). El tipo
de uso de la normativa se representa en tres filas: normativa con foco en la evalua-
cin de la actividad, directrices y mejores prcticas, y la normativa de carcter ms
prescriptivo. La tabla original de Gartner se ha actualizado con la contribucin de
los autores, incorporando nuevas normas y marcos de referencia, como: ITIL v3,
CMMI for Services, ISO/IEC15504, ISO/IEC 38500, ISO 9004, ISO14001, ISO
90003, ISO/IEC 27001, PRINCE2, ISPL, ASL y DSDM). La dinmica de este
sector har que en breve aparezcan nuevas normas y estndares para incorporar a
ste grfico.
Entre estos modelos o recomendaciones destacan las Normas ISO/IEC 20000,
que compiten por un reconocimiento en este campo. El hecho de llegar con el res-
paldo de los organismos de normalizacin internacionales, es un claro empuje para
que se asiente como un referente en la sociedad. Como adems, se han publicado
tambin como norma nacional en muchos pases, cumplen todo lo necesario para
que los gobiernos puedan incluirlas en sus legislaciones o regulaciones (pudiendo
llegar a convertirse en obligatorias).
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
mbito de la empresa
p mbito especfico
p de TI
Calidad
Gestin del Funciones de TI
y medio Empresa Gobierno TI Tecnologa
servicio de TI ((desarrollo,, seg.,
g , etc.))
ambiente
Ticket SPICE
Evaluacin
SAS
ISO/IEC 15504
8000
TQM PPeople
l ISO/IEC
King CMMI for
CMMI 17799 o
COBIT Services
ACC 27002 FEAF
CMMI ISO
ITIL v3
ISO ISO/IEC
CoCo ASL 90003
Tipo de usso
9001 ISO ITIL v2 ISO TOGAF

es
SO 27001
Directrice
DSDM 12207
EFQM 9004 COSO ISO/IEC
ISO ISO/IEC ISPL BS 25999
eTOM 20000 Zachman
14001 (Telcos) 38500 PAS 77
MOF
SAS 70 PMBOK
Lean
CORBA
Prrescriptivo
6 RUP PRINCE2
Sigma XML
TL 9000 SOX
SOA
Fuente: Gartner y e.p.
Figura 1.1. Mapa de las diferentes normas y marcos de referencia

relacionados con las TI
El veterano marco ITIL destaca como el gran compendio de referencia, que aspira
a convertirse en ese modelo universal que estructura y organiza toda la actividad de
las TI. Si bien la versin 2, publicada en el ao 2000, ha tenido una aceptacin
excepcional, hay que esperar a ver cmo el sector va adoptando la nueva versin 3,
publicada en el ao 2007, y que presenta una visin ms amplia y coherente de la
gestin de las TI, agrupada en torno al ciclo de vida del servicio.
El marco para el desarrollo de software CMMI (Capability Maturity Model Integra-
tion) aparece como el modelo ms aceptado para la medicin de la madurez de los
procesos de gestin en la construccin de aplicaciones. Para complicar ms el pano-
rama, en su ltima versin se crea un nuevo modelo CMMI for Services, que se
superpone en gran medida con el mbito central de ITIL; y por tanto, tambin con
las Normas ISO/IEC 20000. Adems, para los procesos y medicin de la madurez
del desarrollo, tambin la normativa internacional inici desde 1993 su andadura.
ISO e IEC han desarrollado un modelo para la evaluacin de los procesos de desa-
rrollo de software bajo la iniciativa SPICE que ha desembocado en la publicacin
de la serie ISO/IEC 15504. En paralelo, han ido evolucionando otro conjunto de
normas relativas a la ingeniera del software (ISO/IEC 15288, ISO/IEC 12207,
ISO/IEC 25001, ISO/IEC 25030, ISO/IEC 16085, etc.).
La gestin de la seguridad de los sistemas de informacin ha sido una de las reas

ms difundidas en el entorno normativo de las TI, con las normas UNE-ISO/
IEC 27001 (sistema de gestin de seguridad) y UNE-ISO/IEC 17799 (un
cdigo de buenas prcticas para la gestin de la seguridad de la informacin),
que se ha renumerado como UNE-ISO/IEC 27002. Recientemente han apare-
cido unas normas britnicas sobre la gestin de la continuidad de negocio, deno-
minadas BS 25999.
En el mbito de la auditora, medicin y gobierno de TI el modelo COBIT (Con-
trol Objectives for Information and Related Technology) est reconocido como una
excelente referencia. En relacin al gobierno de las TI, la normativa internacional
de ISO ha tomado posiciones con la nueva Norma ISO/IEC 38500 Corporate
Governance of Information Technology (tambin denominada en sus etapas de borra-
dor como 29382), inspirada en la Norma australiana AS 8015. Como un hijo
menor del modelo COBIT, para la medicin del valor que aportan las TI al negocio,
se ha definido un nuevo sub-marco denominado ValIT.
En relacin a la gestin de proyectos de desarrollo de software, el marco lder es
PMBOK (Project Management Body of Knowledge), una metodologa reconocida
por el organismo norteamericano de normalizacin ANSI. Tambin hay que tener
en cuenta el modelo PRINCE2 (Projects In Controlled Environments) que, reali-
zado por los impulsores de ITIL, es ms sencillo que el anterior, y resulta de utili-
dad para proyectos de mejora y de implantacin de ITIL o de ISO/IEC 20000.
Otros modelos que se complementan o solapan con los anteriores, aunque con
poca aceptacin en el sector de las TI son: en el mbito de la gestin de proveedo-
res ISPL (Information Services Procurement Library), para disponer de un mapa
completo en la construccin de aplicaciones: ASL (Application Services Library) o
DSDM (Dynamic Systems Development Method).
Por su importancia y universalidad, tambin hay que tener en cuenta la serie de
normas internacionales ISO 9000, familia de normas y directrices que contienen
los requisitos para la gestin de la calidad general de una organizacin. Dentro de
esta serie destaca la Norma UNE-EN ISO 9001, que contiene los requisitos del
sistema de gestin de la calidad, tambin esencial para la implantacin de las Nor-
mas ISO/IEC 20000. La Norma UNE-EN ISO 9004 contiene recomendaciones
prcticas para aquellas empresas que quieran ir ms all de los requisitos mnimos
establecidos en UNE-EN ISO 9001.
En el mbito de la calidad aplicada al desarrollo de software, tambin hay que consi-
derar la Norma UNE-ISO/IEC 9003 que versa sobre las directrices para la apli-
cacin de la Norma UNE-EN ISO 9001 al desarrollo de software. Por otra parte, la
Norma ISO/IEC 12207 proporciona un marco para los procesos, actividades y
tareas relacionadas con el ciclo de vida del software.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Por otra parte, los temas medioambientales tambin tienen su impacto en la ges-
tin de TI. Deben tenerse en cuenta: la legislacin nacional, local y la normativa
sobre retirada y gestin del equipamiento y residuos informticos; la serie de Nor-
mas ISO-EN 14000 relativa a la gestin medioambiental; en Espaa existe tam-
bin la Norma UNE 150002 Sistemas de gestin medioambiental. Gua para la apli-
cacin de la norma UNE-EN ISO 14001:1996 en las empresas de servicios y la gua para
la aplicacin de los sistemas de gestin medioambiental a las relaciones con sumi-
nistradores y clientes, denominada UNE 150004 EX; o el Cdigo de Conducta
para la Eficiencia Energtica en Centros de Datos publicado por la Unin Europea.
Tanta abundancia de informacin y recomendaciones resulta confusa para las orga-
nizaciones que slo desean soluciones prcticas y directas para mejorar su gestin
de las TI.
De todo el mapa anterior, se recomienda centrarse inicialmente en las normas y
marcos de mayor relevancia y ms aceptados para la mejora de TI, como son:
ISO/IEC 20000 partes 1 y 2, e ITIL (en sus versiones 2 y 3) para mejorar la
gestin de los servicios de TI.
COBIT para la auditora y la medicin de las TI.
ISO/IEC 27001 para la gestin de la seguridad de la informacin.
ISO/IEC 15504 y CMMI for Development para la gestin del desarrollo de
software.
ISO/IEC 38500 y COBIT como referencias para el gobierno de las
tecnologas de la informacin.
1.3. Entender los entornos de normalizacin y

certificacin
Tiene gran inters conocer quin es quin en el mbito de la normalizacin y la
definicin de las buenas prcticas relacionadas con la provisin de servicios de TI.
Concurren en este espacio: organizaciones internacionales y europeas de carcter
multisectorial que producen normas (como ISO, IEC, CEN, CENELEC, ETSI,
UIT), organismos de normalizacin nacionales (AENOR en Espaa, BSI en UK,
etc.), administraciones pblicas e instituciones gubernamentales (como OGC en
UK, DoD en los EEUU), organizaciones privadas (itSMF, ITGI), universidades
(Carnegie Mellon), junto a otros organismos del mundo de la certificacin y acre-
ditacin de empresas. La figura 1.2 presenta en forma de tabla los principales acto-
res. En las columnas se muestran las instituciones generadoras de normativas y
marcos de mejores prcticas (organismos de normalizacin internacional, organis-

mos de normalizacin en cada pas y las principales iniciativas de organizaciones
privadas aunque algunas con el respaldo indirecto gubernamental). Las filas enu-
meran algunos organismos e instituciones. Bajo el concepto de promotor se inclu-
yen quin est principalmente detrs de las iniciativas respaldando a las institucio-
nes. Finalmente se presentan algunas normas y marcos de cada mbito.
Normalizacin y acreditacin
Normalizacin internacional Principales iniciativas privadas
segn el pas
Espaa: AENOR - ENAC
ISO CEN OGC Carnegie ITGI PMI
UK: BSI - UKAS
e
USA: ANSI Mellon

instituciones
IEC CENELEC
Organismos
Alemania: DIN - TV
UIT ETSI Argentina: IRAM
Chile: INN
Mxico: DGN
O
Per: INDECOPI
Australia: SA
Gobiernos Gobierno del pas OGC DoD ISACA PMI

es
(UK) (USA) (USA) (USA)

Promotore
Participan comits Participa industria local Participan los lderes y gurs de la industria TI
normalizacin pases itSMF Espaa y GT-25
(en UNE-ISO
UNE ISO 20000) itSMF SEI y ESI
ISO/IEC ISO/IEC
ISO 9001 ISO 27001 ITIL CMMI COBIT PMBOK
20000 20000
ormas
ISO/IEC ISO 17799-

ISO 20000 27001 BS 15000 27002
No
ISO/IEC ISO/IEC BS 25999 Prince2

38500 17799 AS 8015 PAS 77
Fuente: Telefnica
Figura 1.2. Actores en el mbito de la normalizacin relacionados con las TI
En el mbito de la normalizacin internacional, los organismos de normalizacin

internacionales (ISO, IEC, UIT) y los europeos (CEN, CENELEC, ETSI) dispo-
nen de procedimientos estables que garantizan la participacin de los pases miem-
bros y de la industria local. Aunque cada organismo tiene procedimientos especfi-
cos para la realizacin de la normativa, en todos est garantizada la participacin de
los pases y de sus representantes. Para garantizar la representacin se utilizan estruc-
turas de comits, subcomits y grupos de trabajo internacionales, que frecuente-
mente se reflejan en estructuras similares en los pases. Por tanto, no hay un ciclo
nico para la creacin de las normas, aunque todos se basan en la representacin de
los organismos de normalizacin de los pases a travs de sus miembros nacionales
(AENOR, BSI, DIN, etc.) como instrumento para garantizar la participacin
nacional.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Por otra parte, el mbito de las denominadas iniciativas privadas (ITIL, CMMI,
COBIT, etc.) se centra principalmente en el desarrollo de marcos de mejores prc-
ticas y no de normativa. Los procedimientos y la gestin de la representacin del
sector quedan a la libre eleccin de la institucin u organismo que impulsa la ini-
ciativa (OGC, Carnellie Mellon, ITG, etc.). Con frecuencia se basa en una llamada
pblica de participacin para trabajar en la siguiente edicin de estos marcos a la
que suelen responder los principales actores internacionales y gurs en la materia.
El proceso de seleccin del equipo de revisin es especfico de cada institucin, as
como el procedimiento de edicin de la nueva versin del marco de referencia.
Como se puede intuir hay que ser un autentico especialista en la materia para com-
prender los diversos esquemas y estructuras que se han ido creando alrededor de la
normalizacin y marcos de mejores prcticas. Por la vinculacin con la temtica de
este libro se explican los procesos de creacin de las normas ISO/IEC y de las nor-
mas UNE espaolas:
Ciclo de creacin de las normas ISO/IEC. Una norma internacional se desarro-
lla en el mbito de los comits tcnicos y de los subcomits tcnicos de ISO y de
IEC. El proceso sigue seis etapas: propuesta, preparatoria, comit, consulta, apro-
bacin y publicacin. En este proceso, el documento propuesta de norma pasa por
tres estados que indican el grado de aceptacin y apoyo que se va alcanzando de los
diversos borradores:
CD (Committee Draft): es un borrador generado por un grupo de trabajo,
que ha recibido la aprobacin del grupo y se remite al comit correspon-
diente para su aprobacin.
DIS (Draft of International Standard): es el borrador de norma internacio-
nal que el comit de normalizacin ha aprobado y somete a comentarios y
votacin por parte de los pases.
FDIS (Final Draft of International Standard): es el borrador final de la
norma internacional, que el comit enva para su aprobacin final a todos los
miembros para su publicacin final como norma internacional.
En la etapa 2, o preparatoria, se emite el borrador de la norma en fase CD. En la

etapa 3 se aprueba el borrador para pasar al estado de borrador de comit (DIS)
que ser sometido a aprobacin en la etapa 4 o de consulta. As, el borrador apro-
bado pasa al estado de borrador final de norma internacional (FDIS) que ser
sometido para su aprobacin definitiva en la etapa 5.
Adems, existe el procedimiento rpido de aprobacin, o fast-track, para documen-
tos con un grado alto de madurez, como es el caso de normas locales que se quie-
ran elevar a internacionales. En este caso, primero se somete a una votacin para
aceptar que la nueva norma se cree por el procedimiento de fast-track, para pasar
directamente como DIS a la etapa 4. Normalmente el procedimiento rpido puede
durar un ao, mientras que el normal suele durar entre 2 y 3 aos, dependiendo de
la dificultad de alcanzar el consenso en las diversas etapas.
Ciclo de creacin de las normas UNE espaolas. El proceso de elaboracin de
una norma UNE est sometido a una serie de fases que permiten asegurar que el
documento final es fruto del consenso, y que cualquier persona, aunque no perte-
nezca al comit de AENOR, productor de la norma, pueda emitir sus opiniones o
comentarios. Tras la aprobacin del proyecto final de norma por un Comit Tc-
nico de Normalizacin, el Boletn Oficial del Estado (BOE) publica la relacin
mensual de proyectos UNE sometidos a un perodo de Informacin Pblica,
durante el cual cualquier persona o entidad interesada podr presentar observacio-
nes. Las observaciones deben realizarse a AENOR. Una vez analizados los comen-
tarios recibidos en esta fase, el comit redactar el texto final, que ser aprobado y
publicado como norma UNE por AENOR.
En la figura 1.3 se representan las etapas de estos dos ciclos, internacional y nacional.
Proceso de elaboracin de una Proceso de elaboracin de una

norma ISO/IEC internacional norma UNE espaola
1. Etapa de propuesta 1. Trabajos preliminares

Se elabora la propuesta de norma
2. Elaboracin del proyecto de
2. Etapa preparatoria norma en el seno de un Comit
Se consensa el borrador CD Tcnico de Normalizacin (CTN)
3. Etapa de comit 3. Envo de la norma al BOE
El comit aprueba CD DIS para informacin pblica
4. Etapa de consulta 4. Elaboracin y aprobacin por el
DIS se somete a consulta CTN de la propuesta final de norma
5. Etapa de aprobacin 5. Aprobacin de la propuesta final
Se aprueba DIS FDIS por AENOR
6. Etapa de publicacin 6. Publicacin de la nueva
FDIS se edita como norma ISO norma UNE
Fuente: ISO y e.p. Fuente: AENOR
Figura 1.3. Procedimientos de creacin de normas internacionales y nacionales
A continuacin, se presenta una visin general de los principales actores en este

mbito normativo que tienen cierta relevancia en la gestin de las TI, aunque no
pretende ser un tratado exhaustivo.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Organismos de normalizacin internacionales

ISO (International Organization for Standardization, Organizacin Internacional
de Normalizacin). Es el organismo de normalizacin oficial reconocido a nivel
internacional. Su objetivo es poner a disposicin de la industria un catlogo de nor-
mas sobre productos y servicios que se puedan utilizar para dar garanta de unos
niveles de calidad preestablecidos. Fue creado en febrero de 1947 y tiene su sede en
Ginebra. Cuenta en la actualidad con la representacin de 153 pases. Tiene como
objetivo lograr la coordinacin internacional y la unificacin de las normas de la
industria. Coopera estrechamente con la IEC.
IEC (International Electrotechnical Commission, Comisin Electrotcnica Interna-
cional). Es la organizacin internacional centrada en la normalizacin de los mbi-
tos elctrico, electrnico y de tecnologas relacionadas. ISO e IEC cooperan estre-
chamente en campos de inters mutuo, especialmente en el mbito de las TI en el
que desarrollan normas de forma conjunta, las denominadas ISO/IEC.
UIT (International Telecommunication Union, Unin Internacional de Telecomuni-
caciones). Organismo internacional encargado de la elaboracin de recomendacio-
nes para el sector de las telecomunicaciones.
Organismos de normalizacin europeos

CEN (European Committee for Standardization, Comit Europeo de Normaliza-
cin). Es el organismo espejo de ISO a nivel europeo. Est centrado en la normali-
zacin en todos los campos excepto en el elctrico y en el de telecomunicaciones.
CENELEC (European Committee for Electrotechnical Standardization, Comit
Europeo de Normalizacin Electrotcnica). Es el organismo espejo de IEC a nivel
europeo. Est dedicado a la normalizacin en el mbito elctrico y electrnico.
ETSI (European Telecommunications Standards Institute, Instituto Europeo de
Normas de Telecomunicacin). Organismo equivalente a la UIT para Europa,
cuyo campo de actividad se centra en las telecomunicaciones y comunicaciones
electrnicas.
Organismos de normalizacin nacionales

AENOR (Asociacin Espaola de Normalizacin y Certificacin). Es el orga-
nismo que desarrolla la actividad de normalizacin en Espaa. Es una organizacin
privada, independiente y sin nimo de lucro, reconocida en los mbitos nacional,
europeo e internacional para el desarrollo de actividades de normalizacin y certifi-

cacin (N+C) en un mbito multisectorial. Cuenta en la actualidad con ms de 20
centros operativos repartidos en: Espaa, Mxico, Chile, El Salvador, Italia, Portu-
gal, Brasil, Bulgaria, China, etc. Tiene como objetivo contribuir, mediante el des-
arrollo de las actividades de N+C, a mejorar la gestin de la calidad en las empre-
sas, sus productos y servicios, proteger el medio ambiente y, con ello, lograr el
bienestar de la sociedad en su conjunto.
BSI (British Standards Institute). Organismo de normalizacin del Reino Unido.
Es destacable su actividad en la elaboracin de nuevas normas en el mbito de la
gestin de las TI. Creador de la serie de normas BS 15000, base sobre la que se han
definido las actuales Normas ISO/IEC 20000.
En general, cada pas tiene su propio organismo de normalizacin, entre otros
podemos destacar: DIN en Alemania, AFNOR en Francia, UNI en Italia, SA en
Australia, etc.
Otros organismos de habla hispana, con los que AENOR mantiene una estrecha
colaboracin motivada, entre otras cosas, por la traduccin conjunta de normas
internacionales al espaol, son: IRAM en Argentina, INN en Chile, DGN en
Mxico, INDECOPI en Per, etc.
Los gobiernos
Es importante destacar el papel activo de los gobiernos, instituciones gubernamen-
tales y administraciones pblicas en el campo de la normalizacin, pues desempe-
an un triple papel: como sustento de la actividad de normalizacin mediante sub-
venciones a los organismos de normalizacin, como impulsores de algunas
iniciativas destacadas, y en su papel de exigir el cumplimiento de la normativa, bien
estableciendo una regulacin o bien en su papel de cliente contratante de servicios
al sector de las TIC.
Entre estos organismos destacan el Ministerio de Comercio Britnico (OGC, Office
of Government Commerce) en su papel de creador, impulsor y propietario de ITIL y
el Departamento de Defensa de Estados Unidos (DoD, Departament of Defense)
como impulsor de CMMI.
Organismos de acreditacin
Las entidades nacionales de acreditacin son entidades independientes cuya fun-
cin es la acreditacin de entidades certificadoras y laboratorios de ensayo. Es decir,
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
el reconocimiento formal de que una organizacin es competente para la realiza-

cin de una determinada actividad de evaluacin de la conformidad o la realizacin
de un ensayo determinado.
Las organizaciones que podemos destacar son:
Internacionalmente: IAF (International Accreditation Forum).
En Europa: EA (European Cooperation for Accreditation).
En Espaa: ENAC (Entidad Nacional de Acreditacin en Espaa).
En el Reino Unido: UKAS (United Kingdom Accreditation System).
IQNet. Un papel parecido a la acreditacin lo realiza la Red Internacional de Cer-

tificacin (IQNet, International Certification Network), asociacin formada por las
entidades de certificacin lderes en la certificacin de empresas en sus respectivos
pases. Entre sus objetivos estn:
El reconocimiento y promocin de los certificados expedidos por sus miem-
bros en todos los sectores industriales y de servicios.
La coordinacin de los procesos de certificacin de empresas que operan en
distintos pases.
Normalmente, los certificados locales emitidos por las entidades certificadoras van
acompaados de el reconocimiento internacional de IQNet.
Entidades certificadoras
Para que las empresas puedan demostrar a nivel nacional e internacional que cum-
plen las normas, necesitan un certificado. Se trata de un instrumento para verificar
la correcta implantacin de las normas.
La obtencin del certificado se realiza mediante un proceso de evaluacin indepen-
diente por parte de una entidad certificadora o de certificacin. Un requisito
importante que asegura la solvencia para que una entidad pueda conceder una
marca de certificacin es que dicha entidad sea competente para certificar los
productos, los servicios, los sistemas de gestin o las personas, a los que se aplica la
marca de certificacin.
Los organismos de acreditacin son los encargados de acreditar a las entidades de
certificacin. Las entidades de certificacin utilizan los servicios profesionales
de los auditores.
Marcas de certificacin
Las marcas de certificacin las conceden las entidades correspondientes a los pro-
ductos, sistemas y servicios que cumplen con los requisitos definidos.
La certificacin, en base a normas, tiene su reflejo en los distintivos de certifica-
cin, cuya concesin significa que el producto o servicio ha pasado por el adecuado
proceso de certificacin de forma satisfactoria. Cuando, por ejemplo, se trata de
una marca de seguridad, la concesin de la marca significar que cumple los requi-
sitos de seguridad, segn la norma de referencia.
En un producto con certificado de calidad, la etiqueta puede contener distintos
logotipos (vase la figura 1.4) dependiendo de la entidad que otorgue el certificado.
Figura 1.4. Ejemplos de marcas de certificacin de sistema y de producto

en el caso de AENOR
En el Reino Unido se ha desarrollado una marca de certificacin especfica para

ISO/IEC 20000, segn un acuerdo interno entre UKAS (organismo de acreditacin
de ese pas) e itSMF-UK (captulo ingls del itSMF, Information Technology Service
Management Forum), con un reglamento especfico (esquema de certificacin). Por
el contrario, en la mayora de los pases, la certificacin ISO/IEC 20000 transcurre
por los caminos habituales de la certificacin del pas, con marcas especficas de cada
entidad certificadora, y regulado por el organismo de acreditacin del pas.
Auditores
Los auditores son los nicos profesionales acreditados para realizar la auditora del
cumplimiento de los requisitos de una norma por una organizacin. La calificacin
de auditor se concede nicamente a los candidatos que demuestren experiencia
suficiente y hayan pasado los exmenes exigidos para ello.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En el caso de la Norma ISO/IEC 20000-1, existe una acreditacin especfica de

auditor otorgada por UKAS e itSMF-UK a profesionales con amplia experiencia,
tras superar un curso en entidades de formacin acreditadas y superar el examen al
respecto. Esta acreditacin de auditor est vinculada al esquema de certificacin
conjunto de UKAS e itSMF-UK.
Consultores
Los consultores asesoran, bien a las organizaciones o entidades que quieren
implantar las normas, o bien, una vez implantadas, que desean certificarse. Para
esta funcin existe una acreditacin profesional especfica. La formacin que reci-
ben les permite adquirir un nivel suficiente de conocimiento de la normas, del
esquema de certificacin y de su aplicacin.
Los consultores asisten a las organizaciones en la interpretacin y aplicacin de la
normas, as como, para la aplicacin efectiva de ISO/IEC 20000 en la gestin del
servicio. Asimismo, el consultor externo puede efectuar una evaluacin de los nive-
les de gestin del servicio y establecer el nivel de preparacin necesario para una
solicitud de certificacin y su posterior consecucin.
Actualmente, existe una acreditacin de consultor ISO/IEC 20000 otorgada por enti-
dades de formacin acreditadas por UKAS e itSMF-UK. Otros organismos que regu-
lan la formacin profesional (EXIN, APMG) tambin estn entrando en este campo.
Las organizaciones alrededor de ITIL

ITIL (Information Technology Infrastructure Library, Biblioteca de Infraestructuras
de Tecnologas de la Informacin) es el compendio de las mejores prcticas en la
gestin de TI ms extendido y ampliamente aceptado por la industria.
La estrecha relacin entre los contenidos de las Normas ISO/IEC 20000 y los
libros ITIL, hace relevante conocer cules son los principales miembros de este
ecosistema creado para la difusin y evolucin de estas prcticas:
OGC (Office of Government Commerce, Oficina de Comercio del Gobierno). Ofi-
cina dependiente del Ministerio de Economa y Hacienda britnico, responsable de
un amplio programa para mejorar la eficiencia de las empresas. Este organismo
(antes denominado CCTA) fue el creador de ITIL a finales de los aos 80.
TSO. Editorial inicialmente vinculada al entorno gubernamental britnico, centrada
en la publicacin de libros y documentacin producida en este mbito. Fue privati-
zada en 1996 y ha sido comprada por el grupo Williams Lea en enero de 2007.
TSO se encarga de la publicacin impresa y online de los libros ITIL, gestionando

sus derechos de propiedad intelectual.
itSMF International (Information Technology Service Management Forum, Foro
internacional para la Gestin del Servicio de TI). Creado en el Reino Unido en
1991, es una red mundial de grupos de usuarios de TI que ofrecen mejores prc-
ticas y guas basadas en normas para la provisin de servicios de TI. La organiza-
cin internacional coordina las actividades de los captulos locales y apoya al desa-
rrollo y difusin de las evoluciones de ITIL.
itSMF est presente en pases como: Francia, Blgica, Alemania, Portugal, Nor-
uega, Japn, Brasil, Dinamarca, Austria, Finlandia, Canad, EEUU, Singapur,
Australia, Italia, Hungra, Rumania, Suecia, Argentina, Espaa, etc.
itSMF Espaa. Captulo espaol de itSMF. Constituido como una asociacin sin
nimo de lucro, acta como una comunidad de usuarios. Centra sus intereses en las
prcticas y metodologas de gestin y gobierno de las TI. Tiene como objetivo ayu-
dar a las organizaciones a adoptar soluciones de gestin de servicios TI e impulsar
la adopcin de las mejores prcticas.
Certificacin profesional privada en el mbito de la

gestin del servicio
Alrededor de la difusin de las mejores prcticas de gestin del servicio de TI se
ha ido creando una oferta de servicios de formacin para los profesionales, deno-
minadas privadas por no tener asociadas un reconocimiento oficial del Estado,
pero muy apreciadas en el mundo empresarial. No se debe confundir esta certifi-
cacin individual de profesionales con la certificacin de organizaciones o provee-
dores de TI.
En el mbito de ITIL, las certificaciones profesionales tienen gran tradicin. Se ha
evolucionado del esquema anterior de certificaciones de ITIL v2 en tres niveles
(Foundation, Clusters y Service Manager) a uno nuevo en ITIL v3 basado en una
estructura ms flexible de cuatro capas: Foundation para los conocimientos gene-
rales iniciales, Intermediate para el conocimiento en ms detalle de uno o varios de
los libros del ciclo de vida o de agrupaciones de procesos, ITIL Expert que capacita
para la gestin integral de los servicios que requiere haber realizado un conjunto de
cursos Intermediate e ITIL Master, mximo grado de certificacin que ratifica la
capacidad de analizar y aplicar los conceptos ITIL a nuevas reas. La calidad de las
empresas de formacin y el control de los exmenes los gestiona APM Group, a
quin la OGC ha otorgado en 2006 la gestin de la acreditacin de la formacin
relacionada con la marca ITIL.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En el mbito de ISO/IEC 20000, la aparicin de estos esquemas de certificacin

profesional garantizados es ms reciente, destaca la iniciativa de EXIN (Examination
Institute for Information Science), pero posiblemente aparecern otros, ya que el
entorno de normativa internacional no ejerce el concepto de propietario de marca.
1.4. Las principales normas y buenas prcticas

en TI
Las Normas ISO/IEC 20000
Dado que estas normas se tratan en profundidad en el resto del libro, nica-
mente se presenta en la figura 1.5 un esquema general de su estructuracin en
14 procesos (los 13 procesos descritos en los captulos 6 al 10 de las normas,
Sistema de Gestin del Servicio de TI (SGSTI)
Planificacin e implementacin de la gestin del servicio (PDCA)
Planificacin e implementacin de nuevos servicios o de servicios modificados
Procesos de la provisin del servicio

Gestin de la capacidad Gestin de nivel de servicio Gestin de la seguridad
Gestin de la Generacin de de la informacin
continuidad y informes del servicio Elaboracin de
disponibilidad presupuesto y contabilidad
del servicio Procesos de control de los servicios de TI
Gestin de la configuracin
Gestin del cambio
Proceso Procesos
de entrega Procesos de relaciones
Proceso de gestin de resolucin Gestin de las relaciones
de la entrega Gestin del incidente con el negocio
Gestin del problema Gestin de suministradores
Fuente: UNE-ISO/IEC y e.p.
Figura 1.5. Esquema general de los procesos de ISO/IEC 20000

junto al proceso del captulo 5 Planificacin e implementacin de nuevos servi-

cios o de servicios modificados). Adems, las normas incluyen dos aspectos
muy importantes: el sistema de gestin y la planificacin e implementacin de
la gestin del servicio.
En el mbito de los servicios de TI, resulta esencial que los servicios se provean
en un marco de gestin eficaz y de calidad, para entender claramente los requisi-
tos y gestionar su cumplimiento. Las Normas ISO/IEC 20000 articulan el pro-
ceso de prestacin de los servicios engranados sobre un sistema de gestin del
servicio (vase el captulo 3). El proceso de mejora continua establecido por la
Norma ISO 9001 para la fabricacin de productos o prestacin de servicios
(siguiendo el ciclo PDCA: planificar, hacer, verificar y actuar Plan, Do, Check,
Act), tambin se incorpora en esta norma como un motor de la mejora continua
de los servicios de TI (vase el captulo 4).
La serie ISO 9000, normas de calidad

Segn el diccionario de la Real Academia Espaola, la calidad se define como la pro-
piedad o conjunto de propiedades inherentes a algo que permiten juzgar su valor.
El aseguramiento de la calidad nace como una evolucin natural del control de cali-
dad, que resultaba limitado y poco eficaz para prevenir la aparicin de defectos.
Para ello, se hizo necesario crear sistemas de calidad que incorporasen la preven-
cin como forma de funcionamiento y gestin, y que, en todo caso, sirvieran para
anticiparse a los errores antes de que estos se produjeran.
Un sistema de gestin de la calidad se centra en garantizar que el producto o el
servicio ofrecido por una organizacin cumple con las especificaciones establecidas
previamente por la empresa y el cliente, y as, asegurar unos niveles de calidad pre-
decibles y su mejora continua a lo largo del tiempo.
El sistema de gestin de la calidad general es el conjunto de elementos interrelacio-
nados de una empresa u organizacin por los cuales se organiza y planifica el tra-
bajo de la misma en la bsqueda de la satisfaccin de sus clientes. Sus elementos
principales son:
La estructura de la organizacin.
Sus procesos.
Sus documentos.
Sus recursos.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
ITIL (Information Technology Infrastructure Library)

Es un conjunto de publicaciones que recogen las buenas prcticas en la gestin de
servicios de las TI. Define un modelo de procesos bastante amplio que abarca
desde la definicin de la estrategia hasta la gestin de las infraestructuras. El xito y
la fama de ITIL se han fundamentado en la calidad de sus buenas prcticas y en la
flexibilidad para que las empresas pudieran adaptarlas a sus necesidades.
Entre 1989 y 1992, la versin 1 de ITIL se centraba en la gestin de la tecnologa
y estaba claramente orientado al entorno mainframe. Paulatinamente, las prcticas
fueron evolucionando hacia procesos y servicios. ITIL, en su versin 2 (de princi-
pios del ao 2000), se estructuraba en 7 libros bsicos (adems, hay uno nuevo de
dedicado al inventariado o a la gestin de activos software y otro enfocado a imple-
mentaciones en organizaciones de TI de menor escala como en pymes). En la
figura 1.6 se muestra la evolucin histrica de ITIL y la aparicin de ISO/IEC
20000 en los ltimos aos.
ISO/IEC UNE-ISO/ Evolucin

BS 15000 20000 IEC 20000 ISO/IEC 20000
1986 1989 2000 2005 2007
IBM,s itSMF ITIL v1: ITIL v2: Creacin ITIL v3:

ISMA 42 libros 7 libros itSMF Espaa 5 libros
ITIL v0:
Service Level
Management
Figura 1.6. Historia de la evolucin de la normativa de gestin del servicio de TI

ITIL v2 se ha utilizado como base para la creacin de las Normas ISO/IEC 20000.
En la figura 1.7, se muestra una representacin tpica de ITIL v2. En ella se puede
apreciar el negocio a la izquierda del todo, en el extremo derecho se sita la tecno-
loga, y, en medio, haciendo que la tecnologa sea til para el negocio estn los pro-
cesos ITIL. De ellos, los dos libros ms valiosos por su contenido y ms aceptados
por el mercado son los relativos a la gestin de servicio (libros Soporte de Servicio y
Provisin de Servicio publicados por OGC).
Planificacin de la implantacin de gestin del servicio
Perspectiva Gestin de servicio Gestin de

de negocio infraestructuras TIC
Soporte de servicio
Gestin relacin Diseo y
con negocio Centro atencin usr. planificacin
Gestin relacin Incidente Despliegue L
proveedores A
E Problema Operacin
L Planificacin Configuracin Soporte tcnico T
y desarrollo Financiero Cambio E
N arquitectura TI Continuidad Entrega C
E Relacin Disponibilidad N
G formacin y
Gestin O
O comunicacin Capacidad
de activos L
C de TI con el G. nivel de servicio O
I negocio
Provisin de servicio Gestin de G
O
la seguridad
A
Gestin de aplicaciones Planificar
Implementar
Requerimientos
Evaluar
Disear y construir
Mantener
Despliegue
Controlar
Operar
Optimizar
Fuente: Libro ITIL Soporte de Servicio publicado por OGC y e.p.
Figura 1.7. Procesos definidos en los libros ITIL v2

0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
La versin 3 de ITIL, que apareci a mediados de 2007, respeta los principales

procesos del soporte y de la provisin del servicio ya definidos en la versin ante-
rior. Tambin saca a la luz mucha de las actividades de gestin de TI no reflejadas
anteriormente, ampliando su alcance a ms de 20 procesos. Esta versin pone
mayor nfasis en la integracin de TI con el negocio. Se estructura en torno al ciclo
completo de creacin de servicios: estrategia, diseo, transicin, operacin y
mejora continua (vase la figura 1.8).
Diseo
del servicio
Estrategia
del servicio
del servicio
Operacin
ITIL v3
n
s ici icio
an rv
Tr l se
de
Mejora
del servicio
Fuente: Libro ITIL Estrategia del Servicio publicado por OGC y e.p.
Figura 1.8. La estructura de los libros ITIL v3 se articula

segn el ciclo de vida de los servicios
El conjunto de temtica y procesos tratados en ITIL v3 se muestra en la figura 1.9.
MEJORA
ESTRATEGIA DISEO TRANSICIN OPERACIN
CONTINUA
Estrategia del servicio Diseo del servicio Transicin del servicio

Generacin de la estrategia Diseo de servicios nuevos o Planificacin y soporte de la
Gestin financiera de TI modificados transicin
Gestin de la demanda Gestin del catlogo de servicios Gestin de cambios
Gestin del porfolio de servicios Gestin de nivel de servicio Gestin de la configuracin y
Gestin de la capacidad de activos del servicio
Gestin de la disponibilidad Gestin de versiones y
despliegues
Gestin de la continuidad del
servicio TI Validacin y pruebas del servicio
Gestin de la seguridad de la Evaluacin
informacin Gestin del conocimiento
Gestin de suministradores
Mejora continua del servicio Operacin del servicio
El proceso de mejora Procesos:
en 7 etapas Gestin de eventos
Informes del servicio Gestin de incidencias
Medicin del servicio Gestin de peticiones
Retorno de inversin para la Gestin de problemas
mejora
Preguntas al negocio para
la mejora
ITIL v3 Gestin de accesos
Funciones:
Gestin de nivel de servicio Centro de servicio al usuario
Gestin tcnica
Gestin de operaciones TI
Gestin de aplicaciones
Fuente: Libros ITIL v3 publicados por OGC y e.p.
Figura 1.9. Contenido de las cinco etapas del ciclo de vida

de los servicios en ITIL v3
Otras normas y metodologas relacionadas son: COBIT para la auditora y

gobierno de TI, ISO/IEC 27001 para la seguridad, CMMI e ISO/IEC 15504
(SPICE) como modelos de madurez del desarrollo del software. En los apartados
siguientes se presenta una introduccin a ellas.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
COBIT (Control objectives for information and related

technology)
Es un conjunto de mejores prcticas e indicadores para el control y auditora de los
sistemas de informacin. Fue creado por ISACA (Information Systems Audit and
Control Association) y el ITGI (IT Governance Institute) y ha ido extendiendo su
alcance hacia las mtricas de TI y las disciplinas de gobierno de las TI.
La primera edicin fue publicada en 1996, la segunda en 1998, la tercera en 2000
y la cuarta en Diciembre de 2005.
COBIT 4 se estructura en cuatro dominios que cubren un total de 34 objetivos
principales de control (denominados tambin procesos), que permiten garantizar
un adecuado sistema de gobierno para el entorno de las TI. En la figura 1.10 se
muestran estos dominios.
Monitorizar y evaluar Planear y organizar
ME1 Monitorizar y evaluar el desempeo PO1 Definir el plan estratgico de TI

de TI PO2 Definir la arquitectura de la informacin
ME2 Monitorizar y evaluar el control interno PO3 Determinar la direccin tecnolgica
ME3 Garantizar cumplimiento regulatorio PO4 Definir procesos, organizacin y
ME4 Proporcionar gobierno de TI relaciones de TI
PO5 Administrar la inversin en TI
PO6 Comunicar las aspiraciones y la
direccin de la gerencia
Entregar y dar soporte
in En PO7 Administrar recursos humanos de TI
ac ca de treg
DS1 Definir y administrar niveles de servicio l ine tgi va a PO8 Administrar calidad
A ra lor
t
DS2 Administrar servicios de terceros es PO9 Evaluar y administrar riesgos de TI
de r tracin
Med mpeo
DS3 Administrar desempeo y capacidad Gobierno PO10 Administrar proyectos

dese
os
DS4 Garantizar la continuidad del servicio de TI

icin
iesg
inis
DS5 Garantizar la seguridad de los sistemas

Adm
del
DS6 Identificar y asignar costos Adquirir e implantar

Administracin
DS7 Educar y entrenar a los usuarios AI1 Identificar soluciones automatizadas
de recursos
DS8 Administrar la mesa de servicio y los AI2 Adquirir y mantener el software aplicativo
incidentes
AI3 Adquirir y mantener la infraestructura
DS9 Administrar la configuracin tecnolgica
DS10 Administrar los problemas AI4 Facilitar la operacin y el uso
DS11 Administrar los datos AI5 Adquirir recursos de TI
DS12 Administrar el ambiente fsico AI6 Administrar cambios
DS13 Administrar las operaciones AI7 Instalar y acreditar soluciones y cambios
Fuente: ISACA.
Figura 1.10. Los 4 dominios de COBIT para el gobierno de TI

En el mbito de la certificacin de los profesionales, en 2008 ISACA ha puesto en

marcha la certificacin en el gobierno de las TI (CGEIT, Certified in the Governance
of Enterprise IT). Adems, existe la acreditacin a ttulo profesional para auditor de
las TI (CISA, Certified Information Systems Auditor) y la relativa a la seguridad
de las TI (CISM, Certified Information Security Manager).
Vinculado a COBIT, y con el fin de desarrollar las prcticas para la medicin de del
valor de la contribucin de TI al negocio, ISACA ha creado el marco Val IT.
ISO/IEC 27001 e ISO/IEC 17799 para la seguridad

de las TI
El objetivo de la gestin de la seguridad de la informacin es asegurar la continui-
dad de las operaciones de la organizacin y reducir al mnimo los daos causados
por una contingencia, as como, optimizar la inversin en tecnologas de seguridad.
ISO/IEC 27001 establece los principios de: integridad, disponibilidad y continui-
dad de la informacin. Proporciona un modelo para la creacin, implementacin,
operacin, supervisin, revisin, mantenimiento y mejora de un sistema de gestin
de la seguridad de la informacin (SGSI). Esta norma establece un conjunto de 30
actividades para la gestin de la seguridad, define 11 reas principales de control,
para cada una establece 39 objetivos de control y 133 controles (o medidas de sal-
vaguarda) de seguridad. Las reas de control son:
rea: 5. Poltica de seguridad.
rea: 6. Aspectos organizativos de la seguridad de la informacin.
rea: 7. Gestin de activos.
rea: 8. Seguridad ligada a los recursos humanos.
rea: 9. Seguridad fsica y ambiental.
rea: 10. Gestin de comunicaciones y operaciones.
rea: 11. Control de acceso.
rea: 12. Adquisicin, desarrollo y mantenimiento de los sistemas de infor-
macin.
rea: 13. Gestin de incidentes de seguridad de la informacin.
rea: 14. Gestin de la continuidad del negocio.
rea: 15. Cumplimiento.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En la figura 1.11 se muestra la estructura de actividades propuesta en la norma.
Plan Ciclo PDCA Modelo en ISO/IEC 27001

Planificar
Planificar 4.2.1 Creacin del SGSI
Do Act
Hacer Actuar Hacer 4.2.2 Implementacin y operacin del SGSI
Verificar 4.2.3 Supervisin y revisin del SGSI
Check
Verificar Actuar 4.2.4 Mantenimiento y mejora del SGSI
Figura 1.11. Estructura de actividades de ISO/IEC 27001
ISO/IEC 17799 (que pasar a ser denominada ISO/IEC 27002) recoge un cdigo
de buenas prcticas para la gestin de la seguridad de la informacin. Se centra en
desarrollar los objetivos de control de la seguridad, y para cada uno de ellos, se
indica una gua para su implantacin. Cada organizacin debe considerar cuntos
sern realmente los aplicables segn sus propias necesidades.
CMMI (Capability Maturity Model Integration)

CMMI es una evolucin de estndar inicial CMM, que fue desarrollado por el SEI
(Software Engineering Institute) de la universidad Carnegie Mellon, en 1986. Fue
iniciado en respuesta a la peticin del Gobierno de los EEUU (Departamento de
Defensa, DoD) de proporcionar un mtodo para controlar la capacidad de desarro-
llo de software de sus contratistas.
Originalmente, fue diseado para su uso por los desarrolladores de software, pero
hoy se ha ampliado, proporcionando un modelo completo de evaluacin de la
madurez de las actividades de desarrollo de aplicaciones de una organizacin. Este
modelo est estructurado y repleto de prcticas de gran utilidad para la mejora de
las actividades de una organizacin de TI.
En la figura 1.12 se muestra la estructura de las prcticas de CMMI en cuatro reas
denominadas constelaciones. Cada una de estas constelaciones se pueden conside-
rar equivalentes a un libro de ITIL. En el modelo CMMI a los procesos se les deno-
mina rea de proceso (PA, Process Area). Se establece una constelacin comn
(CMMI Fountation) que contiene los procesos que son comunes, una especfica
CMMI
for Services
CMMI
Foundation
16 reas
de proceso
CMMI for CMMI for
comunes
Development Acquisition
Figura 1.12. Constelaciones (reas o libros) de CMMI
para el desarrollo de aplicaciones (CMMI for Development), otra para las adquisi-
ciones (CMMI for Adquisition) y una nueva para la prestacin de servicios (CMMI
for Services).
CMMI describe cinco etapas evolutivas (niveles) en las cuales una organizacin se
sita segn la madurez de sus procesos:
1. Inicial (Initial). Los procesos son caticos; pocos procesos estn realmente
definidos.
2. Repetible (Repeatable). Se establecen los procesos bsicos y se observa cierto
nivel de disciplina respecto a ellos.
3. Definido (Defined). Todos los procesos estn definidos, documentados, nor-
malizados e integrados.
4. Gestionado (Managed). Los procesos se miden recogiendo datos detallados
de los mismos.
5. En optimizacin (Optimizing). La mejora de los procesos es continua y pro-
porciona nuevas ideas y oportunidades.
Con la publicacin en Marzo del 2009 de CMMI for Services, el SEI tambin entra
en el mbito de la gestin del servicio, con bastante solape con ITIL e ISO/IEC
20000. En la figura 1.13 se muestran los procesos de este nuevo modelo.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Las 24 reas de proceso (PA) en CMMI-SVC
Support Service Establishment and Delivery

Causal Analysis and Resolution (CAR) Incident Resolution and Prevention (IRP)
Configuration Management (CM) Service Delivery (SD)
Decision Analysis and Resolution (DAR) Service System Development (SSD)
Measurement and Analysis (MA) Service System Transition (ST)
Process and Product Quality Assurance (PPQA) Strategic Service Management (STSM)
Process Management Project Management

Organizational Innovation and Deployment (OID) Capacity and Availability Management (CAM)
Organizational Process Definition (OPD) Integrated Project Management (IPM)
Organizational Process Focus (OPF) Project Monitoring and Control (PMC)
Organizational Process Performance (OPP) Project Planning (PP)
Organizational Training (OT) Requirements Management (REQM)
Risk Management (RSKM)
Quantitative Project Management (QPM)
Service Continuity (SCON)
Supplier Agreement Management (SAM)
Fuente: SEI.
Figura 1.13. Los procesos definidos en CMMI para servicios (CMMI-SVC)

en su versin 1.2
ISO/IEC 15504 (SPICE, Software Process Improvement

and Capability dEtermination)
En el mbito del desarrollo del software en enero de 1993 en el seno del comit con-
junto de ISO e IEC, surge el proyecto SPICE para el desarrollo de un estndar
internacional para la evaluacin de los procesos de construccin del software. El
resultado de este trabajo se plasm en la serie de normas ISO/IEC 15504, que pre-
sentan un modelo de referencia que describe los procesos de una organizacin para
ejecutar, adquirir, desarrollar, operar, evolucionar y proporcionar soporte al soft-
ware. Este marco es la respuesta de la normativa internacional al modelo de madu-
rez CMMI for Development y en muchos aspectos se solapa.
La arquitectura del modelo organiza las prcticas en nmeros de categoras utili-
zando diferentes tipos de aproximaciones. La arquitectura distingue entre:
Prcticas base. Actividades esenciales de un proceso especfico, agrupado

por categoras de procedimientos y procesos de acuerdo al tipo de actividad.
Prcticas genricas. Aplicables a cualquier proceso, que representa las
actividades necesarias para administrar el proceso y mejorar su potencia-
lidad.
El modelo agrupa a los procesos en cinco categoras:

Procesos cliente-proveedor (customer-supplier). Esta categora consta de los
procesos que directamente impactan al cliente, al soporte de desarrollo y a la
transicin del software al cliente.
Procesos de ingeniera (engineering). Esta categora consta de los procesos
que directamente especifican, implementan, y mantienen un sistema, un pro-
ducto de software y la documentacin del usuario.
Procesos de proyecto (project). Esta categora consta de los procesos esta-
blecidos dentro del proyecto, coordinacin y administracin de los recursos
para producir un producto o proveer un servicio para satisfacer al cliente.
Procesos de soporte (support). Esta categora consta de los procedimientos
que establecen y soportan el desempeo de los otros procesos del proyecto.
Procesos de la organizacin (organization). Esta categora consta de los
procesos que establecen las metas de negocio de la organizacin, los proce-
sos de desarrollo y los recursos que ayudan a la organizacin alcanzar dichas
metas.
En la figura 1.14 siguiente se muestra un esquema con estos procesos:
Procesos cliente-proveedor
Procesos de ingeniera
Procesos
Procesos de proyecto
de soporte
Procesos de organizacin
Fuente: SPICE.
Figura 1.14. Las cinco categoras de procesos definidas en SPICE

0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Existen seis niveles de capacidad en el modelo:

Nivel 0: Incompleto. Sera un fracaso general tratar de aplicar las prcticas
base a los procesos, ya que no es fcil identificar las salidas de los procesos o
el funcionamiento de los productos.
Nivel 1: Realizado. Generalmente se ejecutan las prcticas base de los pro-
cesos. La ejecucin de dichas prcticas puede no ser planificada rigurosa-
mente y ni seguida, y depender del conocimiento y esfuerzo personal. Se
identifican algunos procesos.
Nivel 2: Gestionado. Se planifica y se sigue la ejecucin de las prcticas
base en los procesos. El desempeo estar acorde con los procedimientos
especificados. La primera distincin entre el nivel 1 y el 2 es que la ejecucin
de los procesos est planificada y administrada y progresan hacia un modelo
bien definido.
Nivel 3: Establecido. Las prcticas bases se ejecutan de acuerdo a una ver-
sin adaptada del estndar. Los procesos estn aprobados, bien definidos y
documentados.
Nivel 4: Predecible. Se recaban y evalan las mediciones detalladas del ren-
dimiento o ejecucin. Se conoce de forma cuantitativa el rendimiento de los
procesos y es posible su prediccin. Las prcticas se administran objetiva-
mente. La calidad de las mismas se conoce cuantitativamente.
Nivel 5: Optimizado. Se establecen en forma cuantitativa procesos y metas
eficientes, basados en los objetivos de la organizacin. Los procesos se van
mejorando de forma continua, mediante la retroalimentacin (feedback)
obtenida por los resultados de procesos definidos, por ideas, por pilotos y
por nuevas tecnologas.
2
Captulo 2
Entender las
Normas ISO/IEC 20000
2.1. Introduccin a las Normas ISO/IEC 20000

2.2. Objeto y campo de aplicacin de ISO/IEC 20000
2.3. La estructura de las Normas ISO/IEC 20000
2.4. Relacin entre ISO/IEC 20000 e ITIL
3. Sistema de Gestin del Servicio de TI (SGSTI)
4. Planificacin e implementacin de la gestin del servicio (PDCA)
5. Planificacin e implementacin de nuevos servicios o de servicios modificados
6. Procesos de la provisin del servicio

6.5 Gestin de la capacidad 6.1 Gestin de 6.6 Gestin de la seguridad
6.3 Gestin de la nivel de servicio de la informacin
continuidad y 6.2 Generacin de 6.4 Elaboracin de
disponibilidad informes del servicio presupuesto y contabilidad
del servicio de los servicios de TI
9. Procesos de control
10. Proceso 9.2 Gestin del cambio 7. Procesos
de entrega de relaciones
10.1 Proceso de gestin 8. Procesos 7.2 Gestin de las
de la entrega de resolucin relaciones con el negocio
8.2 Gestin del incidente 7.3 Gestin de
8.3 Gestin del problema suministradores


Gestin del cambio
Proceso Procesos
2. Entender las Normas ISO/IEC 20000 53
2.1. Introduccin a las Normas ISO/IEC 20000

La serie de Normas ISO/IEC 20000 (UNE-ISO/IEC 20000 en la versin espa-
ola) es el primer conjunto de normativa internacional especfica para la gestin de
los servicios basados en las Tecnologas de la Informacin (TI). Presentan una
organizacin cabal de las principales actividades necesarias para gestionar estos servi-
cios, agrupadas en un conjunto de procesos considerados esenciales para la creacin,
prestacin y evolucin de los servicios de las TI. Al aplicar sus requisitos y reco-
mendaciones, las organizaciones de TI emprendern un camino indudable de
mejora en el control y la calidad de su actividad. Es el primer gran salto hacia la
excelencia demandada por la sociedad a las TI.
Se pueden considerar como normas troncales en la gestin de las TI, pues estruc-
turan en torno a procesos las actividades ms esenciales. Alrededor del eje vertebra-
dor que crean las Normas ISO/IEC 20000 se irn construyendo y transformando
el resto de las funciones de la organizacin de las TI. Sobre este ncleo central,
creado para la gestin de las TI, se irn incorporando otras mejores formas de hacer
proporcionadas por otras normas, otros marcos de mejores prcticas, por la expe-
riencia propia de la empresa o por las aportaciones de consultores externos.
Las Normas ISO/IEC 20000 introducen en la organizacin de las TI una forma de
trabajo metdica, integrada y orientada a los procesos, haciendo especial nfasis en
garantizar la calidad del servicio a los distintos clientes de las TI. Adems, articulan
su implantacin con un sistema de gestin especfico, que incorpora la disciplina y
el rigor de ISO 90000 en la implantacin del modelo de trabajo en las TI.
Las Normas ISO/IEC 20000 forman parte del conjunto de normas producidas por
la Organizacin Internacional de Normalizacin (ISO) y la Comisin Electrotc-
nica Internacional (IEC). Su adopcin como normas internacionales surge a raz
de la iniciativa de elevar a ISO e IEC las normas britnicas BS 15000 relativas a la
gestin del servicio de las TI. Las Normas ISO/IEC 20000 hoy vigentes se trami-
taron en ISO a travs del procedimiento rpido denominado procedimiento fast-
track. Esto quiere decir, que estas normas tienen muchas similitudes con la origi-
nal, que la duracin del proceso es de aproximadamente un ao, y que ha contado
con la participacin y voto de los representantes nacionales en ISO/IEC.
Las Normas ISO/IEC 20000 se componen de dos partes: la primera es la especifi-
cacin para la gestin del servicio y tiene un carcter preceptivo, y la segunda se
establece como un cdigo de buenas prcticas o recomendaciones. Ambas partes
forman un marco para definir las caractersticas de los procesos implicados en la
gestin del servicio, que son esenciales para la prestacin de los mismos con la cali-
dad requerida.
Las Normas UNE-ISO/IEC 20000 son las traducciones al castellano de las ante-
riores ISO/IEC, estn formadas por dos partes publicadas como documentos inde-
pendientes:
UNE-ISO/IEC 20000-1:2007 Tecnologa de la informacin. Gestin del
servicio. Parte 1: Especificaciones. Contiene los requisitos exigibles para cum-
plir con la norma. Por ello, el verbo de sus frases suele contener un debe,
indicando que el requisito tiene que ser satisfecho para ser acorde con la
norma.
UNE-ISO/IEC 20000-2:2007 Tecnologa de la informacin. Gestin del
servicio. Parte 2: Cdigo de buenas prcticas. Esta parte contiene a veces una
extensin o detalle de los requisitos de la parte 1, mientras que en otras oca-
siones se desarrollan los requisitos con ms profundidad. La parte 2, utiliza
el condicional debera, que se interpreta como una recomendacin para
satisfacer el requisito de la parte 1, pero quizs no la nica.
Dada la equivalencia entre estas normas ISO/IEC (en ingls) y las normas UNE
(en castellano), a partir de ahora en el libro se utilizar nicamente el trmino
ISO/IEC 20000 para ambas normas.
En la figura 2.1 se muestran los objetivos de cada una de las partes de estas normas
frente al alcance ms amplio del presente libro.
Norma UNE-ISO/IEC 20000-1 Norma UNE-ISO/IEC 20000-2 Este libro

Especificaciones Cdigo de buenas prcticas
+ ISO/IEC 20000-1
Requisitos de cumplimiento Detalle de los requisitos. + ISO/IEC 20000-2
obligatorio para certificarse Necesaria para concretar + ITIL
el alcance de los requisitos
+ Experiencia de los autores
de la parte 1
+ Directrices de implantacin
Debe Debera
Figura 2.1. Las dos partes de las Normas ISO/IEC 20000 y su reflejo en
el presente libro
Conviene tener siempre presente que el objetivo de estas normas, y el sentido de su

aplicacin, es mejorar los servicios prestados por las TI. Por ello, hay que entender que
ambas partes contribuyen a ello, y las dos debern ser tenidas en cuenta en este
camino. Adicionalmente, para alcanzar un buen servicio de TI hacen falta bastantes
temas ms, complementarios a las normas, relativos a: el liderazgo y la estrategia, a las
personas y su organizacin, al resto de actividad y de procesos que se deben realizar,

Gestin del cambio
Proceso Procesos
a la tecnologa y su adecuado dominio, el cambio cultural, a la disposicin de herra-

mientas, etc.
Si ambas partes deben tenerse en cuenta para la mejora del servicio, al abordar un
proceso de certificacin, es cuando habr que discernir entre los requisitos impres-
cindibles y obligatorios de estas normas y cules de ellos son opcionales. A este res-
pecto, los requisitos que se deben cumplir son los especificados en la parte 1 de la
norma, mientras que la parte 2, unas veces aclara o explica la parte primera, y otras
desarrolla una de las formas posibles de implantar dichos requisitos. Tambin habr
que determinar cul es el criterio de alcance que se debe aplicar a un requisito en
el caso particular de una organizacin (por ejemplo, qu se exigir para cumplir el
requisito de tener una base de datos de la configuracin o CMDB). En el proceso
de implantacin ser el experto el que determine el alcance ms adecuado a la orga-
nizacin. Durante el proceso de certificacin ser el auditor quin dar por vlida o
no una evidencia de cumplimiento en funcin de su propio criterio y experiencia.
Diferencia entre norma y regulacin

Una norma, segn define la legislacin espaola (Ley 21/1992), es una especifica-
cin tcnica de aplicacin repetitiva o continuada, cuya observancia no es obligato-
ria, establecida con la participacin de todas las partes interesadas, que aprueba un
organismo reconocido a nivel nacional o internacional. Mientras que un regla-
mento tcnico, se refiere a una especificacin tcnica, relativa a productos, procesos
o instalaciones industriales, establecidas con carcter obligatorio a travs de una dis-
posicin de la Administracin, para su fabricacin, comercializacin o utilizacin.
Por tanto, la norma en s misma constituye una recomendacin y no es de obligado
cumplimiento por las organizaciones; su implantacin y cumplimiento es volunta-
rio. La regulacin o reglamentacin pueden exigir el cumplimiento de los requisi-
tos definidos en una norma. Es en este caso cuando la norma pasa a ser de obligado
cumplimiento para las organizaciones afectadas. Hay que recalcar que en el caso de
las Normas ISO/IEC 20000, los requisitos que contienen son exigibles slo al
efecto de certificar la conformidad de una organizacin con ellas de manera volun-
taria, no porque exista una ley o regulacin lo exija.
ISO/IEC 20000 se centran en el mbito de gestin de

los servicios de TI
Es importante posicionar adecuadamente las Normas ISO/IEC 20000 dentro de
todo el mbito de la actividad de TI, pues estas normas se centran en un conjunto
esencial de la actividad de gestin de los servicios, pero no abarcan la totalidad de

la actividad de TI.
No son unas normas sobre la tecnologa en s misma, sino que se centran en las
actividades de las personas para gestionarlas (procesos) y en identificar los roles
necesarios para llevarlas a cabo. En la figura 2.2 se muestra que el mbito de estas
normas es la gestin de las TI, por debajo del gobierno de las TI y por encima de
la gestin de equipos de trabajo, las herramientas (aunque influye en ellas y las uti-
liza) y las capas tecnolgicas.
Fuente: Telefnica.
Figura 2.2. Las Normas ISO/IEC 20000 se centran en las

actividades de gestin de las TI

Gestin del cambio
Proceso Procesos
El hecho de que estas normas especifiquen los detalles de un total de 14 procesos

(estos 14 procesos sealados, son los recogidos en los apartados 5 a 10 de las nor-
mas), no significa que sean estos los nicos a tener en cuenta. Hay que verlos como
actividades fundamentales, pues la industria est en plena efervescencia definiendo
estndares y marcos de mejores prcticas en torno a la gestin de las TI.
Adems de los procesos contemplados en la norma, hay otras disciplinas que hay
que tener en cuenta para lograr la excelencia del proveedor de TI, como son:
La alineacin de TI con las necesidades del negocio.
La gestin de la demanda de las necesidades del negocio.
La planificacin de la cartera anual de proyectos.
La madurez de los procesos de desarrollo y sus metodologas.
El imprescindible conocimiento tcnico.
La arquitectura de las aplicaciones y de la infraestructura.
La renovacin de las infraestructuras.
La calidad de los proveedores y de los servicios contratados.
El liderazgo de la direccin, la motivacin del personal, etc.
Si realizsemos un esquema que reflejara toda la actividad llevada a cabo en TI, las
funciones y los recursos tecnolgicos, tendramos:
Para coronar el esquema, en la parte ms alta, se definiran las actividades de
gobierno de TI: estrategia, alineacin con el negocio, etc.
Por debajo de ellas estaran los procesos de gestin del servicio de TI.
En el siguiente nivel se situaran los equipos que constituyen las fuerzas de
trabajo de TI: con la operacin, funciones tcnicas, el desarrollo de software,
y el resto de especialidades y conocimientos tecnolgicos
A continuacin, aparecera la capa de herramientas: de soporte a la gestin,
de administracin tcnica, de monitorizacin, etc., es decir, las herramientas
que hacen que la actividad sea ms fluida y controlada.
Por ltimo la capa en la base del esquema, que alojara la tecnologa: siste-
mas, aplicaciones e infraestructura de TI (tecnologa suministrada por los
fabricantes, comunicaciones, edificios para alojarlos, etc.)
En este esquema las normas se posicionaran sobre el rea de la gestin del servicio,
debido a su carcter organizacional y de gestin. En la figura 2.3 se muestra el
esquema con todo su detalle.
Fuente: Telefnica.
Figura 2.3. En el mapa de disciplinas de TI, las Normas ISO/IEC 20000

contribuyen a la parte troncal de la gestin del servicio
Principios bsicos de ISO/IEC 20000

Cuando ISO, IEC y las empresas del sector se plantearon la forma de organizar las
actividades en las reas de TI se dieron cuenta que, adems de la omnipresente tec-
nologa, tenan que poner foco en cuatro principios tradicionalmente relegados
(vase la figura 2.4):
El servicio. Es fundamental orientar las TI hacia el objetivo de prestar servicio
a sus reas de negocio. La actividad de TI se debe estructurar completamente
bajo el concepto de servicio y no centrarse exclusivamente en el dominio de
tecnologas aisladas.

Gestin del cambio
Proceso Procesos
La orientacin al cliente. De forma complementaria a la anterior, los depar-

tamentos de TI tienen que desarrollar la capacidad de orientarse al cliente.
Cambiar las formas de trabajar para que los objetivos del negocio sean asu-
midos como propios. Se pone foco en las relaciones con el negocio y con los
usuarios de los servicios.
La comunicacin interna. Potenciar la comunicacin interna entre las
diversas reas y entre las personas.
Los procesos internos. Organizar la actividad y el trabajo de todo el equipo
para que fluya sin fricciones y al ritmo demandado por el negocio. Todo ello,
dentro de un entorno de calidad y mejora continua.
El servicio
La orientacin al cliente
ISO/IEC 20000
La comunicacin interna
Los procesos internos
Proveedor del servicio TI

u organizacin TI
Figura 2.4. ISO/IEC 20000 introduce en TI cuatro principios
La importancia de los procesos en la provisin de

servicios de TI
En muchas disciplinas de la sociedad, para conseguir que un conjunto de activida-
des complejas engranen a la perfeccin, se ha desarrollado el enfoque basado en
procesos. Conocer brevemente el concepto de proceso nos ayudar a entender la
forma de actuar para mejorar la organizacin de TI. Tanto las Normas ISO/IEC
20000, como ITIL y otros marcos de referencia estructuran la actividad de TI
entorno a los procesos que cada uno de ellos considera esenciales.
En trminos generales, un proceso se define como conjunto de actividades mutua-
mente relacionadas o que interactan, las cuales transforman elementos de entrada
en resultados (UNE-EN ISO 9000). Tambin se entiende como una serie de activi-
dades con valor aadido, acciones o tomas de decisin interrelacionadas, orientadas
a obtener un resultado especfico. Todo proceso debe poder representarse mediante

un diagrama de flujo y poder medirse su rendimiento.
Al hablar de procesos nos estamos refiriendo a las diferentes etapas que contribu-
yen, de una manera ordenada, a la consecucin de un objetivo definido. Por ejem-
plo, un proceso de fabricacin est constituido por las fases consecutivas necesarias
para la elaboracin de un producto. La disciplina de los procesos se lleva aplicando
desde hace aos en las organizaciones que pretenden que un conjunto de personas
trabaje en equipo; sincronizadas, de una forma repetible y con eficiencia.
La Norma UNE-EN ISO 9001 tambin propone en su introduccin un enfoque
basado en procesos para la mejora de la calidad, que se traduce en la aplicacin de
un modelo de procesos dentro de la organizacin. As, para que una organizacin
funcione de manera eficaz, tiene que identificar y gestionar numerosas actividades
relacionadas entre s. Indica que: una actividad que utiliza recursos y que se ges-
tiona con el fin de permitir que los elementos de entrada se transformen en resulta-
dos, se puede considerar como un proceso. Frecuentemente, el resultado de un
proceso constituye directamente el elemento de entrada del siguiente proceso. En
la figura 2.5 se presenta un esquema de ejemplo de un proceso.
Actividades (de valor aadido)
Entradas Actividad Actividad Actividad Salidas

Tarea 1
Tarea 2 SUBPROCESO
Tarea n Actividad Actividad Actividad
Tarea 1
Tarea 2
Control Mecanismos
(actividades de evaluacin)
Indicadores Recursos
y KPI
Roles
Propietario Objetivos
Herramientas
del proceso del proceso
Figura 2.5. Elementos principales que componen un proceso


Gestin del cambio
Proceso Procesos
Segn indica la Norma UNE-EN ISO 9001, una ventaja del enfoque basado en
procesos es el control continuo que proporciona sobre los vnculos entre los proce-
sos individuales dentro del sistema de procesos, as como sobre su combinacin e
interaccin. Un enfoque de este tipo, cuando se utiliza dentro de un sistema de ges-
tin de la calidad, enfatiza la importancia de:
a) La comprensin y el cumplimiento de los requisitos.
b) La necesidad de considerar los procesos en trminos que aporten valor.
c) La obtencin de resultados del desempeo y eficacia del proceso.
d) La mejora continua de los procesos con base en mediciones objetivas.
Introduciendo los procesos en la forma de trabajar, no slo se mejorar el servicio

prestado, sino que adems, se incrementar la satisfaccin del equipo al realizar un
trabajo ms eficaz y organizado.
Normalmente, un proceso est formado por unas entradas, unas actividades y unos
resultados o salidas. Las actividades estn formadas por tareas y controladas
mediante indicadores, que se correspondern a los objetivos definidos del proceso y
ser el rol del propietario del proceso quien asuma las responsabilidades del control.
De forma complementaria, existen unos mecanismos que posibilitan que las activi-
dades se realicen (recursos, roles participantes y herramientas necesarias). Por otra
parte, las actividades pueden agruparse en una serie de subprocesos, para hacer ms
entendible el proceso principal. Un proceso puede necesitar instrumentos, herra-
mientas, formularios o mecanismos para llevarse a cabo, as como, una descripcin
detallada de cada actividad (procedimientos e instrucciones de trabajo).
En el mundo de los procesos, y por lo tanto en ISO/IEC 20000, es muy impor-
tante tener presente los principios bsicos que se deben respetar en la definicin y
ejecucin de un proceso para que ste sea efectivo:
Un proceso tiene clientes (internos o externos).
Un proceso tiene un objetivo comprometido.
Un proceso tiene un responsable nico.
Sus actividades cruzan fronteras entre las diferentes unidades de la organi-
zacin.
Un proceso utiliza recursos, su actividad la realizan unos roles y suelen
requerir herramientas que los soporten.
Las Normas ISO/IEC 20000 definen una capa de procesos de TI que aglutina las
principales actividades para que los servicios se provean y presten segn las exigencias
del negocio. Esta capa de procesos se utiliza por la organizacin tradicional de TI,
garantizado que estas actividades esenciales se ejecuten de la forma definida. Para
facilitar el trabajo es necesario implantar un conjunto de herramientas de soporte a
la ejecucin de los procesos (capa de herramientas). Por tanto, la implantacin de
las normas no requiere necesariamente cambiar la estructura organizativa. Aunque
s ser necesaria la definicin detallada de los procesos y de los roles o funciones
especficos, que garanticen que son efectivos. En la figura 2.6 se representan la capa
de procesos ISO/IEC 20000 y la capa de herramientas como instrumentos al servi-
cio de la organizacin de TI y de sus equipos de trabajo.
Fuente: Telefnica.
Figura 2.6. Las Normas ISO/IEC 20000 definen las actividades

principales (procesos) a realizar por la organizacin de TI (equipos de trabajo)
Implantando y haciendo eficientes estos procesos bsicos se conseguir una mejor

organizacin de la sobrecargada actividad de las reas de soporte y una mejora en
la calidad de los servicios prestados.
En las grandes organizaciones, su implantacin suele llevar implcitamente asociada
la creacin de una organizacin matricial en TI, la estructura jerrquica se ve cruzada
por los flujos de los procesos ISO/IEC 20000, que dependen del gerente, gestor o

Gestin del cambio
Proceso Procesos
responsable de cada proceso. En la figura 2.7 se aprecia un esquema tpico de una

organizacin matricial, en columnas se representan las funciones, los departamentos
o unidades jerrquicas de la empresa, mientras que horizontalmente cruzan a estos
los procesos.
CIO
F1 F2 F3
P1
P2
P3
F: funciones o departamentos
P: procesos
Fuente: Gartner.
Figura 2.7. La implantacin de procesos implica una organizacin matricial
Estas organizaciones matriciales generadas al implantar los procesos, se inician con

un fuerte peso y dominancia de las funciones verticales, para ir evolucionando
segn maduran a dar ms importancia a los procesos, que en su estado final de evo-
lucin acaban dominando la organizacin. De hecho, en ITIL v3, los cinco libros
que lo estructuran invitan a transformar las funciones o departamentos tradiciona-
les en las cinco etapas del ciclo de vida del servicio (estrategia, diseo, transicin,
operacin y mejora continua), al que habra que aadir la construccin (apenas tra-
tada en ITIL v3).
Procedimientos e instrucciones de trabajo

Una vez definido el proceso, puede ser necesario realizar uno o varios procedimien-
tos que permitan su aplicacin en la organizacin. Un procedimiento es el detalle
de cmo aplicar una parte de un proceso. Desarrolla las actividades y tareas que for-
man un proceso, e incluye una descripcin detallada de cada una de ellas.
Un proceso describe qu hay que hacer y un procedimiento cmo hay que
hacerlo en una situacin concreta. Por ejemplo, un proceso puede establecer que
hay que registrar el incidente en la herramienta de gestin de incidentes, y el proce-
dimiento indicar los pasos a dar en la herramienta concreta de gestin de inciden-
tes, qu hay que poner en cada campo, etc.
La mayor parte de las organizaciones suele completar sus procedimientos con ins-
trucciones de trabajo complementarias, ms detalladas que los procedimientos,
cuyo objetivo es describir, hasta los ltimos detalles necesarios, las tareas descritas
en los procedimientos. Una instruccin de trabajo puede elaborarse en el caso de
que haga falta ms detalle en un procedimiento, por ejemplo, cuando roles distin-
tos tienen instrucciones de trabajo distintas dentro del mismo procedimiento.
Por tanto, procesos, procedimientos e instrucciones de trabajo tienen como finali-
dad primordial ser utilizadas por el personal en la realizacin diaria de su trabajo.
En el caso concreto de los procesos de gestin de TI, todos los procesos se deben
formalizar, pero la experiencia demuestra que no en todos ellos es productivo bajar
al nivel de detalle de procedimiento o de instruccin de trabajo. En general, ser
til poner nfasis en detallar aquellos procesos en los que:
Se ve involucrado mucho personal.
Se deben engranar un conjunto de actividades, subprocesos y tareas com-
plejos.
Es necesaria una automatizacin minuciosa.
Tpicamente, los procesos que tienen un flujo extenso, y que convendr detallar,
son: la gestin del incidente (y la gestin de la peticin del usuario), la gestin del
cambio, la gestin de la entrega y la gestin de suministradores. Ms all del
alcance de estas normas, ser necesario bajar a nivel del procedimiento en: la ope-
racin, la gestin del evento o la gestin del acceso. En el resto de procesos, para la
mayora de las organizaciones, detallarlos no aportar un valor adicional.

Gestin del cambio
Proceso Procesos
2.2. Objeto y campo de aplicacin de

ISO/IEC 20000
ISO/IEC 20000-1 establece su objeto y campo de aplicacin como:
UNE-ISO/IEC 20000-1
Esta parte de la Norma ISO/IEC 20000 define los requisitos para que un proveedor
del servicio proporcione servicios gestionados de una aceptable calidad a sus clientes.
Puede ser usada:
a) para negocios que solicitan ofertas para sus servicios;
Nota 1: El trmino negocio en esta norma internacional debera interpretarse en un sentido
amplio, abarcando aquellas actividades que son esenciales para alcanzar los fines que
persigue la organizacin.
b) para negocios que requieren de un enfoque consistente por parte de todos sus
proveedores del servicio en la cadena de suministro;
c) por proveedores del servicio para medir y comparar su gestin del servicio
de TI;
d) como base de una evaluacin independiente;
e) por una organizacin que necesite demostrar su capacidad para proveer
servicios que cumplan con los requisitos de los clientes; y
f) por una organizacin que busque mejorar los servicios, mediante la aplica-
cin efectiva de los procesos para monitorizar y mejorar la calidad de los
servicios.
En relacin a la estructura y tamao del proveedor de TI, debemos indicar que los
requisitos de la norma son totalmente independientes de la estructura de la organi-
zacin o tamao de la misma. Aunque, cuanto mayor sea el tamao del proveedor
o la complejidad de los servicios, mayores beneficios se podrn obtener de la apli-
cacin de la norma. Un proveedor de servicio debe utilizar la organizacin que le
sea ms apropiada, segn su negocio, su cultura y su estrategia.
Para entender claramente el alcance de estas normas se debe comprender el signifi-
cado que se otorga a dos conceptos: servicio de TI y proveedor de TI.
Comprender el concepto de servicio de TI

Servicio, del latn servitium, se define en el diccionario de la Real Academia Espa-
ola como la: organizacin y personal destinados a cuidar intereses o satisfacer
necesidades del pblico o de alguna entidad oficial o privada, como; servicio de
correos, de incendios, de reparaciones, etc..
En ITIL v3, un servicio se define como un medio de entregar valor a los clientes faci-
litando los resultados que los clientes quieren lograr sin la necesidad de que tengan la
propiedad de los activos necesarios, ni la responsabilidad de los riesgos asociados.
El trmino servicio ya se da por conocido en estas normas y, por tanto, no se define
en ellas, pero para las reas de TI internas de las empresas no les es fcil encajarlo
en su actividad. Resulta importante profundizar sobre su alcance para poder enten-
der el mbito de aplicacin de estas normas, ya que se centran en establecer los
requisitos necesarios para prestar estos servicios. Con frecuencia se contamina el
concepto de servicio que el negocio o cliente quiere recibir de TI, con los compo-
nentes tecnolgicos que lo soportan. En cambio, cuando los servicios se ofrecen al
exterior, es el propio mercado y la competencia los que van perfilando su alcance y
correcta definicin. As, podramos definir servicio como toda contraprestacin por
la que el cliente paga. Pero en el caso de prestacin de servicios internos, su alcance
no est tan claro y hay que hacer un cierto esfuerzo por conceptualizarlo.
En el mbito interno de TI se podra definir servicio como una funcionalidad
necesaria para los usuarios, semejante al concepto utilizado en las relaciones
comerciales del mercado. Se entiende que un servicio de TI es una solucin infor-
mtica completa que cubre unas necesidades especficas del negocio, que TI entrega
y mantiene de forma autocontenida y empaquetada, liberando al cliente y a los
usuarios de las complejidades internas de su tecnologa. De esta forma, los servicios
de TI se deben convertir en una parte esencial en la cadena de valor del negocio.
La distincin entre lo que es un servicio de TI y lo que no lo es depende de la agru-
pacin conceptual que se quiera hacer. Normalmente se sigue el criterio de conside-
rar servicio aquello que claramente el cliente lo percibe como una unidad auto-conte-
nida y le aporta un cierto valor o utilidad. Pero an as, la diferenciacin es subjetiva.
En unos casos, el servicio est directamente vinculado a una aplicacin (como la apli-
cacin de facturacin ligada al servicio de facturacin). En otros, un servicio puede
utilizar varias aplicaciones (el de atencin comercial se puede componer de las aplica-
ciones de: atencin al cliente, ficha de cliente, registro de llamadas, etc.).
Ejemplos de servicios bajo el alcance de estas normas son lo los siguientes:
La provisin del puesto de trabajo: el ordenador del puesto de trabajo conec-
tado, operativo y soportado.

Gestin del cambio
Proceso Procesos
El correo electrnico.
El sitio web de la empresa.
El portal web interno de la empresa (la intranet).
El servicio de ERP (Enterprise Resource Planning) de una empresa.
El servicio de alojamiento de aplicaciones o portales web.
El servicio de alojamiento de servidores ofrecido por un Internet Center.
El servicio de facturacin.
El servicio de gestin del conocimiento.
El servicio de colaboracin.
En la figura 2.8 se muestra la visin de TI como un proveedor de servicios al ne-

gocio.
Servicios de TI
Negocio
Gestin Acceso en
de clientes teletrabajo
Gestin Provisin y
de ventas soporte del
Gestin de Correo
Gestin de puesto de trabajo
facturacin electrnico
actuaciones
Figura 2.8. El concepto de TI como proveedor de servicios al negocio
En el fondo, la estructuracin en servicios depende mucho de cada organizacin.

Estos se agrupan y explican en un catlogo de servicios de TI.
Adems, el conocimiento de la definicin de servicio es importante para compren-
der el alcance de las Normas ISO/IEC 20000, que estn claramente orientadas a
mejorar los servicios operativos de TI, es decir, a aquellos que deben estar funcio-
nando regularmente. Normalmente un servicio se construye sobre equipamiento
informtico (hardware), un software base, aplicaciones, comunicaciones, y requiere
una arquitectura, un soporte tcnico y gestin para que se mantenga activo.
De forma clara, estas normas se refieren a los servicios que se prestan utilizando
como base los sistemas informticos. Esta concepcin de servicio no quiere decir
que no se puedan aplicar las directrices y recomendaciones a otro tipo, pero su apli-
cacin habr que matizarla e interpretarla, como es el caso de los servicios de las
operadoras de telecomunicaciones. Pero hay otros casos que no estn en el alcance,
aunque tambin se denominan servicios, como por ejemplo: la prestacin de servi-
cios de consultora, la venta de equipamiento informtico, etc. En la figura 2.9 se
muestra la simbologa utilizada en el libro para estos dos omnipresentes conceptos.
Servicio de TI Proveedor de TI
Figura 2.9. Simbologa utilizada en el libro

para representar el servicio de TI y el proveedor de TI
Por otra parte, es importante tener en cuenta el punto en el que se est situado en
la cadena de provisin para determinar si tal o cual actividad es un servicio ofre-
cido, o bien, es un servicio contratado. Un rea interna de una empresa ofrece ser-
vicios a los usuarios de la misma, pero a su vez, contrata servicios al mercado (el
centro de tele-atencin, el alojamiento de sus equipos en un centro de proceso de
datos de un tercero, los servicios de telecomunicaciones, etc.). As, en la posicin
del rea interna de TI, sta ofrece servicios a sus usuarios y clientes, y contrata otros
servicios a los proveedores externos o internos.
Bajo la perspectiva de estas normas, el trmino servicio se utiliza para referirse al
prestado por la organizacin a la que se aplica la norma.
El concepto de proveedor del servicio de TI

El trmino proveedor del servicio de TI est omnipresente en las normas, es la
organizacin a la que se aplican las normas y para la que se establecen las directri-
ces y recomendaciones. Se utiliza para referirse a: el rea, la empresa, el departa-
mento o la organizacin que presta el servicio de tecnologas de la informacin y
comunicaciones; y tiene clientes o reas de negocio que contratan o solicitan los
servicios y usuarios de los utilizan.

Gestin del cambio
Proceso Procesos
En este mbito, el trmino proveedor del servicio de TI se puede aplicar a cual-

quier unidad, departamento, organizacin o empresa que preste servicios de TI,
con independencia de que haya o no transaccin econmica, o del tamao de la
organizacin. Algunos ejemplos de proveedor de TI pueden ser:
Los departamentos de sistemas de informacin o departamentos de infor-
mtica internos de las empresas.
Empresas que ofrezcan servicios de TI al mercado.
A partir de este punto, a lo largo del libro se utilizar el trmino proveedor de TI

como sinnimo de organizacin de TI o departamento informtico, dotndole del
mismo alcance que en las normas.
El papel del proveedor de TI aparece levemente descrito en las generalidades del
apartado 7.1 de la norma, cuando tratan las relaciones con el negocio.
UNE-ISO/IEC 20000-2
Esta norma se dirige hacia el rol de un proporcionan bienes o servicios a dicho

proveedor del servicio, el cual cumple proveedor del servicio, y los clientes, que
un papel entre los suministradores, que reciben los servicios.
La figura 2.10 muestra una representacin simplificada de la posicin de la organiza-

cin o proveedor de servicios de TI entre el suministrador y el negocio. Tambin se
aprecia la diferencia entre los clientes de TI y los clientes del negocio en el mercado.
Servicio de TI
Cliente del
Cliente de TI negocio
Grandes
clientes
Relacin Relacin Pymes Consumo

Suministrador Proveedor de TI Negocio
(organizacin TI)
Figura 2.10. La organizacin o proveedor de TI presta servicios de TI al negocio

Conviene destacar que, para evitar la confusin terminolgica, en las Normas

ISO/IEC20000 se ha adoptado el trmino de suministrador para designar a toda
organizacin a la que se le contrata algn tipo de prestacin, quedando el trmino
proveedor para aquellas organizaciones o departamentos de TI que quiere cumplir
con lo especificado por la norma (a efectos de certificacin). Se distingue, as, entre
suministrador de TI y proveedor de TI (rea o departamento de TI). Esta conside-
racin es muy importante en el mbito de estas normas, y hay que afinar el len-
guaje, utilizando siempre suministrador para estas prestaciones contratadas exter-
namente.
A partir de ahora en este libro, al igual que en las Normas ISO/IEC 20000, a la
organizacin de TI, bien sea departamento interno o unidad que presta servicios
externos al mercado, va a ser denominada como proveedor de TI. Concepto
que comprende tanto a las reas o departamentos informticos internos de las
empresas, como a cualquier tipo de servicio de tecnologas de la informacin
proporcionado.
2.3. La estructura de las Normas ISO/IEC 20000

Las actividades que se realizan para la prestacin de un servicio de TI son mlti-
ples. La industria ya ha iniciado el camino para la definicin de las ms relevantes,
aqullas que hay que definir y optimizar para que la organizacin de TI vaya mejo-
rando su funcionamiento. Las principales, consideradas ms esenciales para el ser-
vicio, se definen tanto en estas normas, cmo en otros marcos de referencia. Algu-
nos de estos procesos esenciales ayudan a:
Resolver de forma rpida los incidentes ocurridos en el servicio.
Ir mejorando paulatinamente las taras ocultas en las tecnologas (hardware y
software) que soportan los servicios.
Conocer con precisin la configuracin de los servicios y sus componentes.
Realizar cambios de una forma segura y eficiente.
Entender con claridad las necesidades del cliente, establecer acuerdos preci-
sos con l y organizarse para ser capaces de cumplirlos.
Identificar y controlar los costes para optimizar la eficiencia de la organizacin.
Mejorar el tiempo de provisin de servicios nuevos.
Garantizar la robustez de los servicios crticos para el negocio.
Controlar el desempeo de los suministradores contratados.

Gestin del cambio
Proceso Procesos
Parece que los autores de ISO/IEC 20000 e ITIL (v2 y v3) suelen coincidir en
cules son los procesos bsicos para la gestin de las TI. As, estos diferentes
marcos de referencia tienen un ncleo con procesos bastante similares (inci-
dente, problema, configuracin, cambio, entrega, nivel de servicio, disponibili-
dad, continuidad, capacidad y financiero). En cambio, a la hora de realizar la
agrupacin conceptual de estos procesos, es donde los autores han dejado volar
su creatividad, proponiendo en sus modelos agrupaciones dispares. Por suerte,
estas diferentes agrupaciones son conceptuales y no tienen reflejo en el conte-
nido de los procesos que se han de aplicar. En el caso de las Normas ISO/IEC
20000, la agrupacin tiene su lgica y es razonable (agrupaciones: provisin del
servicio, control, entrega, resolucin y relaciones), pero distinta a lo establecido
en ITIL v2 (libros: soporte de servicio, provisin de servicio, gestin infraes-
tructuras, etc.) y distinto ITIL v3 (libros: estrategia, diseo, transicin, opera-
cin y mejora continua). As, se agrupan bajo la provisin de servicio procesos
distintos a los contemplados en ITIL v2 en su libro de provisin de servicio. En
ITIL v3 la agrupacin se hace en funcin del ciclo de vida del servicio. Con
independencia de la agrupacin de procesos que se realice, individualmente hay
un ncleo comn (gestin del incidente, gestin del problema, gestin de la
configuracin, etc.).
Los primeros apartados en estas normas estn centrados en inculcar en TI las ense-
anzas aprendidas implantando y mejorando sistemas de gestin en todo tipo de
organizaciones. Por ello, los captulos 3 y 4 se centran en: el sistema de gestin TI
y en la planificacin e implementacin de la gestin del servicio.
Prcticamente, el resto de estas normas se dedica a la definicin de los procesos,
agrupados en: Planificacin e implementacin de servicios, nuevos o modificados;
Procesos de provisin de servicio; Procesos de relacin; Procesos de resolucin;
Procesos de control y Proceso de entrega.
En el esquema de la figura 2.11 se muestra el modelo bsico utilizado en este
libro y en las normas para representar todo el alcance de la gestin del servicio de
TI. En el rectngulo exterior se sita el sistema de gestin del servicio de TI (que
se explica en el captulo 3). Hacia el interior del rectngulo aparece de forma
inmediata las actividades de implantacin del sistema de gestin (tratadas en el
captulo 4). Una vez establecido el sistema que gestionar el servicio, su implan-
tacin y mejora, se incorporan los 14 procesos establecidos en ISO/IEC 20000
(tratados en los captulos de 5 al 10). Esta figura se utilizar de ndice grfico en
todo el libro.
Las Normas ISO/IEC 20000 se componen de un conjunto de procesos que inter-
actan entre s y que son necesarios para la prestacin de un servicio con el obje-
tivo de normalizar la gestin de los sistemas de informacin mediante procesos
Captulo 3 3. Sistema de Gestin del Servicio de TI (SGSTI)
Captulo 4 4. Planificacin e implementacin de la gestin del servicio (PDCA)
Captulo 5 5. Planificacin e implementacin de nuevos servicios o de servicios modificados
Captulo 6 6. Procesos de la provisin del servicio

Captulo 9 9. Procesos de control
Captulo 10 Captulo 8 Captulo 7

Figura 2.11. Estructura de los procesos en las Normas ISO/IEC 20000

y los captulos del libro
eficaces que articulen todas las actividades de la organizacin de TI hacia un claro

enfoque al servicio y al cliente. Las normas estn divididas en las siguientes reas:
El sistema de gestin de TI. Cuyo objetivo es proveer una gestin de TI que
incluya polticas y un marco de trabajo para hacer posible una efectiva gestin e
implementacin de todos los servicios de TI. Estas normas siguen la estructura y
filosofa establecida por las normas ISO para la gestin con calidad de las organiza-
ciones, de la que ISO 9001 es la piedra angular. Para conseguir la transformacin
de la actividad en TI, ISO/IEC 20000 establece que la gestin de TI se organice y
regule alineada con el modelo de gestin del resto de la empresa. Define un modelo
o sistema de gestin de TI que se integra sin fisuras en el mismo sistema de gestin
de calidad segn el modelo ISO 9001 de la empresa.
Planificacin e implementacin de la gestin del servicio. Apartado destinado a

definir el proceso de implantacin de estas normas, es decir, de la propia gestin

Gestin del cambio
Proceso Procesos
del servicio de TI (procesos, roles, relaciones, recursos, herramientas, cambio cul-

tural, etc.). Tambin incorpora el ciclo de mejora continua, basado en el modelo
PDCA, internacionalmente reconocido y aceptado por ser, entre otros, el modelo
de gestin aplicado para calidad y para la gestin ambiental. La metodologa cono-
cida como PDCA puede describirse brevemente como:
P Planificar: establecer los objetivos y procesos necesarios para conseguir
resultados de acuerdo con los requisitos del cliente y las polticas de la orga-
nizacin.
D Hacer: implementar los procesos.
C Verificar: realizar el seguimiento y la medicin de los procesos y los pro-
ductos respecto a las polticas, los objetivos y los requisitos para el producto,
e informar sobre los resultados.
A Actuar: tomar acciones para mejorar continuamente el desempeo de
los procesos. Sirve de entrada a planificar.
En las normas, para cada fase del ciclo PDCA se establecen los requisitos y reco-
mendaciones a seguir por todo proveedor de TI.
Planificacin e implementacin de nuevos servicios o de servicios modifica-

dos. Describe el proceso de creacin de un servicio nuevo o de realizar modifica-
ciones a los servicios existentes, para que se puedan gestionar y entregar con los
costes, calidad y plazos acordados con los clientes.
Procesos de provisin de servicio. Regulan las actividades necesarias para que los
servicios cumplan los cometidos pactados con el negocio. Cobran especial relevan-
cia frente a la necesidad de prestar servicios de TI de calidad, alineados a los objeti-
vos del negocio, que cubran las necesidades actuales y que deben ser capaces de
evolucionar rpidamente para cubrir las necesidades futuras. En estas normas, la
provisin de servicio aglutina 6 procesos:
Proceso de gestin de nivel de servicio.
Proceso de generacin de informes del servicio.
Proceso de gestin de la continuidad y disponibilidad del servicio.
Proceso de elaboracin de presupuesto y contabilidad de los servicios de TI.
Proceso de gestin de la capacidad.
Proceso de gestin de seguridad de la informacin.
Procesos de relaciones. Especifican las actividades de TI con su mundo exterior. Se

centran en dos apartados clave: por un lado establece y mantiene una buena relacin
entre el proveedor del servicio y el cliente, comprendiendo la realidad del cliente
y los fundamentos de su negocio; por otro lado, haciendo foco en la gestin de los
suministradores o proveedores, para garantizar la provisin sin interrupciones de
los servicios de TI con calidad. Los procesos de relaciones en estas normas son:
Proceso de gestin de relaciones con el negocio, que especifica las activida-
des para llevar a cabo el dilogo entre el proveedor de TI y sus clientes.
Proceso de gestin de suministradores, define las actividades a tener en
cuenta en la gestin de los suministradores del proveedor de TI.
Procesos de resolucin. Se centran en la resolucin de incidentes nuevos o reinci-

dentes ocurridos sobre los servicios, que dificultan o impiden que estos cumplan su
cometido. Por un lado, trata de restaurar el servicio para cumplir el nivel de servi-
cio acordado con el negocio y los clientes tan pronto como sea posible o resolver
las peticiones de servicio. Por otro lado intenta minimizar los efectos negativos de
las interrupciones de servicio efectuando actividades tendentes a analizar la causa
de los incidentes y la gestin de los problemas, para lograr su cierre definitivo. Los
procesos de resolucin en estas normas son:
Proceso de gestin del incidente, entendiendo como tal la degradacin par-
cial o total del servicio.
Proceso de gestin del problema, centrado en la resolucin definitiva de
defectos que causan incidentes repetidamente.
Procesos de control. Aseguran a los gestores la calidad de la informacin sobre

los servicios, as como, que todo cambio se realiza de una forma controlada. Con-
templan dos apartados clave: por un lado el control de todos los componentes del
servicio y la infraestructura, manteniendo la informacin precisa sobre la configu-
racin de dichos componentes, y por otro lado, asegurando que todos los cambios
que se produzcan sobre dichos componentes sean valorados, aprobados, implanta-
dos y revisados de una manera controlada. Los procesos de control en estas nor-
mas son:
Proceso de gestin de la configuracin, que mantiene al da la informacin
definida como esencial del proveedor de TI, los servicios y sus componentes.
Proceso de gestin del cambio, que garantiza que todo cambio que se deba
realizar sigue las reglas marcadas. Aprueba y controla todos los cambios que se
producen en los servicios. Es muy importante no confundirlo con otro con-
cepto muy distinto que es la gestin del cambio cultural en la organizacin.

Gestin del cambio
Proceso Procesos
Proceso de entrega. Se centra definir las actividades a realizar durante la etapa de

trnsito de los cambios, desde la etapa de desarrollo hasta su paso a produccin.
Asegura que todos los componentes necesarios para la puesta en produccin real
de un servicio estn correctamente definidos y probados, proporcionando al pro-
ceso de gestin del cambio la informacin necesaria para la aprobacin, o no, de
la implantacin de un servicio en produccin real. Est formado por un nico
proceso:
Proceso de gestin de la entrega. Una vez aprobado el cambio, gestiona la
implantacin, distribucin y el seguimiento de uno o ms cambios a realizar
en el entorno de produccin real.
2.4. Relacin entre ISO/IEC 20000 e ITIL

Las empresas y organizaciones, en general, agradecern que los creadores de estas
normas intentaran respetar y asemejarse a otro marco o modelo extendido en el
mercado, como es ITIL. Esto permitira a las organizaciones, con procesos ITIL ya
implantados, tener un buen camino recorrido para cumplir con ellas. No obstante,
hay diferencias entre ambos mundos: unas veces son evidentes ya desde el mismo
nombre del proceso, pero otras, son ms sutiles y difciles de detectar en una pri-
mera lectura. Este libro trata de exponer con claridad estas diferencias, tanto en el
resumen realizado en este apartado, como en la descripcin detallada de los proce-
sos. La similitud con ITIL, permite aprovechar las buenas prcticas de ste para
tomarlas como una forma, aunque no la nica, de cumplir los requisitos de
ISO/IEC 20000.
Estos dos marcos tienen mucho en comn. Ambos cubren la gestin del servicio
de TI, se utilizan internacionalmente y cuentan con una oferta de formacin
reglada por instituciones sectoriales.
A pesar del acoplamiento que existe entre ISO/IEC 20000 e ITIL, no se alinean
completamente. Esto es en parte debido a la diferencia fundamental existente entre
una norma y un marco de mejores prcticas.
Como consecuencia de la diferencia de enfoque entre ambos mundos, hay algunos
contenidos definidos en ITIL que no tienen presencia en estas normas, por estar
fuera de su alcance. Las principales diferencias se describen a continuacin (vase la
figura 2.12):
Quizs la ms importante es relativa al tratamiento de la gestin de nivel de
servicio entre ISO/IEC 20000 e ITIL v2/v3. Aunque ambas comparten el
mismo nombre, en el caso de ITIL el alcance es mucho ms amplio.
ISO/IEC 20000 divide de una forma ms racional las funciones de la ges-

tin de nivel de servicio en 4 o 5 procesos:
1. La gestin de nivel de servicio, que en estas normas trata todo lo relativo
a los servicios desde la perspectiva interna de TI, como por ejemplo la
definicin, el cumplimiento y seguimiento de los acuerdos de nivel de
servicio (SLA), la gestin del catlogo de servicios y el plan de mejora
de los servicios.
2. La generacin de informes de servicio aparece como un proceso nuevo.
En ITIL se hace referencia a los informes del servicio pero como parte de
cada proceso (por ejemplo la gestin de la disponibilidad) y no se trata
de un proceso separado.
3. El proceso de relaciones con el negocio (el definido en estas normas se
corresponde nicamente a las relaciones con el cliente, que se llevan a
cabo en la gestin de nivel de servicio de ITIL).
4. El proceso de planificacin e implementacin de nuevos servicios o de
servicios modificados.
5. Incluso en la v2 se llega a asignar la gestin de los contratos con los sumi-
nistradores a este proceso en lo relativo al respaldo de los niveles de servi-
cio pactados con el cliente. En la v3 como en ISO 20000 aparece un pro-
ceso nuevo especfico para la gestin de suministradores.
En ISO/IEC 20000 los procesos de la continuidad del servicio y la gestin

de la disponibilidad se unifican, pues los requisitos entre ambos estn bas-
tante relacionados. En ITIL, la continuidad del servicio y la gestin de la dis-
ponibilidad son procesos separados.
En relacin a la gestin econmica, ISO/IEC 20000 trata nicamente la rea-
lizacin de presupuestos y contabilidad analtica de costes en TI. El cobro
por el servicio (charging), incluido en ITIL, no es aplicable para algunas
organizaciones y por ello no se contempla en estas normas.
Las Normas ISO/IEC 20000 incluyen los requisitos para la gestin de la segu-
ridad de la informacin, haciendo referencia a los requisitos de la Norma
ISO/IEC 27001 sobre gestin de la seguridad de la informacin. ITIL v2
incluye un libro sobre la de gestin de la seguridad, con una alineacin relativa
con la Norma ISO/IEC 27001. ITIL v3 se trata la seguridad como un proceso.
La gestin de la capacidad en ISO/IEC 20000 no hace ninguna distincin
entre diversos tipos de capacidad. ITIL establece una distincin entre la
capacidad del recurso, la del servicio y la del negocio.

Gestin del cambio
Proceso Procesos
rea / Proceso 20000 v2 v3

Estrategia del servicio S
Diseo del servicio 88% 75% S
Libros ITIL v3
Construccin del servicio

Transicin del servicio 36% 36% S
Operacin del servicio 33% 33% S
Mejora continua del servicio S S S
Sistema de gestin del servicio de TI S
Planificacin e implementacin de la
S S
gestin del servicio
Planificacin e implementacin de nuevos
S S (1)
servicios o de servicios modificados
Gestin de nivel de servicio S S S
Generacin de informes del servicio S Por cada proceso
Gestin de la continuidad y disponibilidad del
Estructura ISO 20000
S S S
servicio
Elaboracin de presupuestos y contabilidad
S S S
de los servicios de TI
Gestin de la capacidad S S S
Gestin de la seguridad de la informacin S S S
Gestin de las relaciones con el negocio S En gest. nivel servicio
Gestin de suministradores S (2) S
Gestin del incidente S S S
Gestin del problema S S S
Gestin de la configuracin S S S
Gestin del cambio S S S
Proceso de gestin de la entrega S S S
(1)
En ITIL v3 la creacin de nuevos servicios est embebida en el concepto de ciclo de vida del servicio.
(2) En ITIL v2 la gestin de suministradores se trata en el libro ITIL Business Perspective publicado por OGC.
Figura 2.12. Comparativa ente los procesos ISO/IEC 20000 e ITIL v2 y v3

(en porcentaje se indica el grado aproximado de cobertura)
En ISO/IEC 20000 la gestin de los activos est cubierta por disposiciones

en la gestin de la configuracin, alinendose con los libros Soporte del Servicio
y Provisin de Servicio de ITIL v2, que adems trata la gestin de los activos
software en una publicacin separada. Mientras que la v3 une la gestin de
activos al proceso de gestin de la configuracin.
En ISO/IEC 20000 la gestin de la Biblioteca de Software Definitivo (DSL)
se le asigna al proceso de gestin de la configuracin, en ITIL v2 es gestio-
nada por la entrega.
En ISO/IEC 20000 no se describen funciones o unidades tpicas en TI. En
v2 slo se describi en la funcin del service desk, mientras que en v3 en el
libro Operacin del Servicio se ampla la lista identificando 4 reas: centro de
servicio al usuario, gestin tcnica, gestin de operaciones de TI y gestin
de aplicaciones.
En ISO/IEC 20000 se define el proceso planificacin e implementacin de
nuevos servicios o de servicios modificados. En ITIL v2 no existe este
importante proceso, mientras que en ITIL v3 hay que indagar entre los
libros Diseo del Servicio y Transicin del Servicio (versiones y despliegues)
para encontrar una secuencia parecida.
Otra diferencia est en el alcance de los contenidos, pues en ITIL se incluyen
ejemplos de flujos de los procesos, entradas, actividades y salidas de los mis-
mos. Ejemplos de roles, factores crticos de xito y mtricas e indicadores.
3 El Sistema de Gestin
del Servicio de TI (SGSTI)
Captulo 3


SGSTI
3. El Sistema de Gestin del Servicio de TI (SGSTI) 81
El sistema de gestin es el conjunto de polticas, procesos, procedimientos, instruc-

ciones de trabajo y recursos (humanos y materiales) necesarios para la correcta ges-
tin del servicio de TI. Se podra decir que el sistema de gestin es la ley hasta su
mnimo detalle a implantar.
El objetivo de este sistema de gestin es conseguir que la provisin y prestacin de
los servicios de TI se realicen de una manera eficaz. Para ello se dota de unas polti-
cas y un conjunto procesos, procedimientos y normas de trabajo que fijan el marco
de trabajo para toda la organizacin del proveedor de servicios de TI. Todo ello
segn lo establecido por las Normas ISO/IEC 20000.
A la hora de disear e implantar un sistema de gestin de servicios de TI, estas nor-
mas estructuran las directrices entorno a tres ejes bsicos:
Responsabilidades de la direccin. Su finalidad es conseguir el compro-
miso y la participacin activa de todos los miembros de la direccin de la
organizacin durante toda la vida del sistema de gestin.
Requisitos de la documentacin. Establece los criterios que deben seguirse
para ejecutar los procesos y evidenciar que los trabajos se realizan siguiendo
dichos criterios.
Competencia, concienciacin y formacin. Se centra en la adecuada ges-
tin de los recursos humanos, necesaria para la implantacin de los proce-
sos. Para ello se elabora la definicin de los perfiles, la asignacin de respon-
sabilidades y la gestin de la formacin. Todas estas actividades se realizan
siempre teniendo en cuenta el principio de comunicacin/motivacin.
SGSTI
3.1. El sistema de gestin de tecnologas de

la informacin
Figura 3.1. Aspectos bsicos del sistema de gestin de TI
En este captulo se presenta una descripcin sobre qu es un sistema de gestin de

TI, qu elementos lo conforman, qu temas clave estn especificados en las normas
y un resumen de los puntos ms relevantes de cara a su implantacin (vase la
figura 3.1). Se descubrir la necesidad imperiosa de llevar a cabo la transformacin
y gestin de las TI, utilizando un modelo de gestin probado con xito en otros
mbitos que han seguido las directrices de la normativa internacional definida en la
Norma UNE-EN ISO 9001.
Si alguien es ajeno o no estuviera familiarizado con el mundo de la calidad y la
Norma UNE-EN ISO 9001 Sistemas de gestin de la calidad. Requisitos, le ser dif-
cil entender qu es un sistema de gestin. Para el profesional de TI es importante
entender claramente el significado de este trmino, pues aporta una sistemtica
para organizar las actividades y obliga a formalizar, de extremo a extremo, todas las
tareas de TI, e incorpora un proceso de mejora continua. Entender su necesidad,
permitir a los gestores de TI apoyarse y aprovechar la experiencia de los profesio-
nales de la calidad para mejorar sus servicios.
El trmino sistema de gestin proviene del ingls management system que repre-
senta un modo o forma de gestionar, o una manera formalizada de realizar las
cosas. As, IT management system o el sistema de gestin de TI correspondera
a una forma normalizada para gestionar los trabajos que se realizan en TI, se
corresponde a la forma de hacer, trabajar y gestionar. La abreviatura que se ha acu-
ado para el sistema de gestin de TI es SGSTI (Sistema de Gestin del Servicio
de TI). Es frecuente encontrar otras siglas relacionadas con este concepto, como
son: SGC (Sistema de Gestin de la Calidad), SGS (Sistema de Gestin de Servi-
cios) o SMS (Service Management System).
Se entiende el sistema de gestin de TI como el propio modelo de hacer o trabajar
en TI. Lo que cotidianamente se expresa como vamos a implantar ITIL, vamos a
implantar ISO/IEC 20000, hay que hacer un proyecto para mejorar los servicios
de TI, esta es nuestra forma de trabajar en esta casa, el departamento de infor-
mtica se gestiona en base a estos procedimientos, etc. todas ellas son maneras de
expresarse en TI y expresan de alguna forma el concepto de sistema de gestin
de TI utilizado en los mbitos de calidad. Por tanto, siendo como es la esencia de
ISO/IEC 20000 o ITIL, este sistema se define, se implanta y se mejora.
Quiz lo que ms despista a los profanos es el trmino sistema pues, inconscien-
temente, parece que induce a pensar en una herramienta o algo parecido, pero no
es slo esto. El sistema de gestin recoge la nueva forma de trabajar, de relacionarse
y de prestar servicios en TI. Si este sistema se ha creado siguiendo los principios,
los procesos y los requerimientos especficos para TI establecidos en las Normas
ISO/IEC 20000, habremos constituido el sistema de gestin de TI o SGSTI.
Desde la perspectiva de los elementos que lo componen, el sistema de gestin se
definira como: el conjunto de polticas, procesos, procedimientos e instrucciones
de trabajo, necesarios para la correcta gestin del servicio de TI.
Desde una perspectiva integral del proveedor de TI, el sistema de gestin se vera
como: el conjunto de elementos interrelacionados de una organizacin de tecno-
logas de la informacin por los cuales se lleva a cabo de forma normalizada su acti-
vidad de servicio en la bsqueda de la satisfaccin de sus clientes. Adems, el con-
cepto de sistema de gestin conlleva que las actividades se normalicen en procesos
y que todos los procesos trabajen conjuntamente de una manera coordinada y con
un objetivo comn, evitndose pasar de una estructura de departamentos estancos
a otra de procesos inconexos.
Con independencia de la definicin utilizada, el objetivo y alcance del sistema de
gestin es el mismo.
A partir de ahora, el mundo tcnico debe asumir como parte de su da a da este nuevo
concepto de sistema de gestin de TI o SGSTI, que equivale a gestionar el servicio
SGSTI
de TI siguiendo los procesos y formas de hacer formalizadas en la organizacin

del proveedor de servicios de TI. Es un sistema vivo en constante evolucin, pues
establece lo que hay que implantar y recoge evidencias de la actividad realizada.
La figura 3.2 muestra la estrecha correlacin que existe entre el SGSTI y la ejecu-
cin del trabajo diario del proveedor de TI. Nos encontramos ante un sistema de
gestin que establece los procesos de funcionamiento de TI. Estos procesos deben
estar lo suficientemente soportados por herramientas que permitan su gestin efi-
caz y su incorporacin al da a da.
Fuente: Telefnica.
Figura 3.2. El sistema de gestin define el modelo de trabajo a seguir

por el proveedor de TI
Tambin hay que entender que estas normas y marcos de referencia del mercado
(ISO/IEC 20000, ITIL, etc.) aportan directrices y recomendaciones; pero no son
utilizables, como tal, directamente en la empresa. Requieren concretarse en proce-
sos y procedimientos, que son los instrumentos sobre los que se articula la gestin
de la actividad. Adems, para que sean de verdad tiles, la aplicacin de todos estos
estndares debe adaptarse a las particularidades de cada empresa (tamao, negocio,
cultura, estrategia, etc.).
Por ello, todo proveedor u organizacin de TI debe crear su propio sistema de ges-
tin que tenga en cuenta cmo adaptar las normas a todas las particularidades pro-
pias de cada empresa.
Si se quiere mejorar seriamente la calidad de los servicios de TI, es imprescindible

que se defina e implemente un sistema de gestin especfico. Por ello, las Normas
ISO/IEC 20000 establecen que la transformacin de TI hacia una mayor calidad
en sus servicios, se articule en torno a un sistema de gestin. En la figura 3.3 se
muestra un resumen introductorio al sistema.
Sistema de Gestin del Qu aporta:

Servicio de TI (SGSTI) Formaliza en la organizacin la
implantacin de la gestin del servicio.
Implantacin de lo general
Definicin: (estrategia y polticas) a lo particular
(procedimientos).
Gestin del servicio de TI siguiendo
los procesos y formas de hacer Medio para alcanzar la eficiencia
formalizadas en la organizacin del y la calidad deseadas.
proveedor de TI, buscando la Permite la alineacin con los sistemas
eciencia y calidad deseadas. de gestin de la calidad (ISO 9001)
de la empresa.
Objetivo: Genera un sistema documental en el
que se recoge formalmente toda la
Proveer un sistema de gestin que informacin necesaria para soportar
incluye las polticas y el marco el modelo de gestin.
de trabajo para hacer posible una
efectiva gestin e implementacin Impone rigor en la definicin, en
el seguimiento y en la captura de
de todos los servicios de TI.
registros y evidencias.
Imprescindible para la certificacin
ISO/IEC 20000.
Figura 3.3. Introduccin al sistema de gestin de TI
El sistema de gestin es un medio para la transformacin de la organizacin. Ade-

ms de las estrategias y polticas de mejora, recoge y formaliza todos los documen-
tos y registros necesarios. Los requisitos para los sistemas de gestin generales de
la empresa se definen en la Norma UNE-EN ISO 9001. Tener implantado un sis-
tema de gestin, segn esta norma, ayudara enormemente en la implantacin de
ISO/IEC 20000. Aunque las Normas ISO/IEC 20000 contienen todos los reque-
rimientos para montar un sistema de gestin propio, sin tener que apoyarse en otra
norma, el Sistema de Gestin del Servicio de TI (SGSTI) debera estar integrado
en el modelo general de gestin de la empresa acorde con ISO 9001, si existiera
(vase la figura 3.4).
SGSTI
Cultura de Buenas prcticas Objetivos del Capacidad

la empresa de la empresa negocio y de TI y recursos
Sistema de gestin general de la empresa (SGC segn ISO 9001)
Tecnologas de la informacin
Gestin y operacin
SG de otras reas
del servicio de TI
de la empresa
SGSTI
Gestin servicio
Calidad y y su prestacin
mejora continua
ITIL
ISO 9001
ISO 20000
Figura 3.4. El sistema de gestin de TI debe estar integrado con el sistema

de gestin general de la empresa
Al definir las formas de hacer en el sistema de gestin se deben tener en cuenta

tambin las particularidades de la empresa, como por ejemplo:
La cultura de la empresa.
Las buenas prcticas existentes en la empresa.
Los objetivos del negocio y los objetivos de TI.
Las capacidades, conocimientos y disponibilidad de recursos del propio pro-
veedor de TI.
El sistema de gestin es un elemento esencial para obtener la certificacin ISO/IEC

20000 en una organizacin de prestacin de servicios de TI, pues registra toda la
documentacin y evidencias que el auditor exigir en el proceso de certificacin.
Como caba esperar, las directrices de las Normas ISO/IEC 20000, no slo especi-
fican los requisitos de la documentacin, sino que adems exigen otros aspectos
esenciales para que la mejora de los servicios se produzca en realidad, como son,
por una parte, la implicacin y compromiso de la direccin, y por otra, la concien-
ciacin y formacin de las personas. A continuacin se detallan los tres aspectos
clave requeridos en estas normas (vase la figura 3.5):
Implicacin y compromiso de la direccin en el proceso de cambio (apar-

tado de responsabilidades de la direccin).
Definicin de la documentacin del sistema de gestin (apartado de requisi-
tos de la documentacin).
La importancia de la gestin de los recursos humanos para que se produzca
el cambio (apartado de competencia, concienciacin y formacin).
Implicacin
de la direccin
AR PARA
S LDERES
SGSTI
Documentacin Cambio cultural
Figura 3.5. Aspectos esenciales en la implementacin del

sistema de gestin de TI
Responsabilidades de la direccin
La mejora de los servicios de TI pasa por implantar los procesos que forman el sis-
tema de gestin de TI en todo su detalle. Este enfoque en torno a los procesos va a
suponer la introduccin de cambios sustanciales, tanto desde el punto de vista cul-
tural en la forma de trabajar de las personas como, en algunos casos, profundos
cambios organizativos. Ante esta transformacin de TI (o del proveedor de servi-
cio de TI en terminologa de la norma) resulta imprescindible contar con el apoyo,
compromiso y participacin de la alta direccin de la empresa y de TI, como dina-
mizadora esencial de todo este proceso.
En lneas generales, las empresas tienen sus grupos internos (calidad, procesos, de
mejora, explotacin, etc.) que frecuentemente inician por si mismas las actividades
SGSTI
de transformacin de TI hacia una organizacin centrada en el cliente, que presta

servicios y se estructura en base a procesos. Tanto las directrices de las Normas
ISO/IEC 20000, como las mejores prcticas del mercado, dejan muy claro que este
comienzo es loable, pero insuficiente; debe ser la direccin de TI y de la empresa
los que lideren la transformacin del rea de TI. Por ello, en la norma aparece este
apartado especfico dedicado a las responsabilidades de la direccin en todo el pro-
ceso de transformacin.
Las Normas ISO/IEC 20000 establecen de manera general las responsabilidades
que debe ejercer la direccin, de cara a permitir la implantacin y el adecuado
mantenimiento del sistema de gestin y, a la vez, las convierte en requisitos clave
para la obtencin de la certificacin. Este es un requisito clave que se debe cum-
plir si se desea obtener la certificacin. En los casos en que ya exista un sistema de
gestin (por ejemplo, el sistema de gestin de la calidad) que establezca las res-
ponsabilidades de la direccin, habr que verificar que lo establecido es consis-
tente y coherente con lo requerido en ISO/IEC 20000. Garantizar este alinea-
miento permitir ir construyendo un sistema integrado o unificado de gestin en
la empresa.
El papel de la direccin para asegurar que las mejores prcticas se adoptan y man-
tienen en los procesos es fundamental para cualquier proveedor de servicio que
quiera cumplir con los requisitos de ISO/IEC 20000-1:
UNE-ISO/IEC 20000-1
La alta direccin debe proveer, a travs del liderazgo y de acciones, evidencias de

su compromiso para desarrollar, implementar y mejorar sus capacidades de gestin
del servicio dentro del contexto de los requisitos de negocio de la organizacin y de
los requisitos de los clientes.
La direccin debe:
a) establecer la poltica de la gestin del servicio, sus objetivos y planes;
b) comunicar la importancia de cumplir con los objetivos de gestin del servicio
y la necesidad de la mejora continua;
c) asegurar que los requisitos del cliente se determinan y se cumplen con el obje-
tivo de mejorar la satisfaccin del cliente;
d) designar un miembro de la direccin como responsable para la coordinacin
y gestin de todos los servicios;
e) determinar y proveer recursos para planificar, implementar, monitorizar, revisar
y mejorar la provisin y la gestin de los servicios, por ejemplo, contratando el
personal apropiado o gestionando la rotacin de personal;
f) gestionar los riesgos para la organizacin de la gestin del servicio y para los
servicios; y
g) llevar a cabo revisiones de la gestin del servicio, a intervalos planificados,
para asegurar la continuidad de su idoneidad, su adecuacin y su efectividad.
UNE-ISO/IEC 20000-2
El papel de la direccin para asegurar todos los niveles del plan de gestin del
que las mejores prcticas son adoptadas servicio.
y mantenidas en los procesos es funda- El rol de responsable senior debera
mental para cualquier proveedor del estar al frente de los recursos designa-
servicio que quiera cumplir con los requi- dos para las actividades de mejora del
sitos de la Norma ISO/IEC 20000-1. servicio, bien sean actividades conti-
Para asegurar el compromiso de la nuas o con un enfoque de proyecto.
direccin se debera identificar un res- El responsable senior debera estar apo-
ponsable a nivel de alta direccin como yado por un grupo encargado de la
responsable de los planes de gestin del toma de decisiones que tenga la sufi-
servicio. Este responsable senior debe- ciente autoridad para definir la poltica
ra responsabilizarse de la entrega a y para hacer cumplir sus decisiones.
Como indican estas normas, para asegurar el compromiso se debera identificar un

responsable senior (a nivel de alta direccin) de la implantacin de la gestin del
servicio. Este patrocinador del sistema de gestin debe responsabilizarse de la
ejecucin y xito de esta transformacin. Debe estar al frente de los recursos desig-
nados, bien sean actividades continuas o con un enfoque de proyecto. Tambin
debe estar apoyado por un grupo de toma de decisiones con suficiente autoridad
para definir la poltica y para hacer cumplir sus decisiones.
El papel de la direccin, por tanto, es ser protagonista desde el primer momento
en que se decide acometer el diseo e implantacin de un sistema de gestin de ser-
vicios de TI. De todas y cada una de estas actividades habr que dejar evidencia
documental, que se registrar en el propio sistema de gestin, para las auditorias
posteriores. Por ejemplo: actas de reuniones en las que se traten asuntos anterior-
mente mencionados, documentos de polticas firmados y comunicados a todos los
niveles, etc.
SGSTI
Requisitos de la documentacin
Para que el sistema de gestin sea eficaz es necesario dar respuesta a dos aspectos
clave. El primero de ellos es definir y documentar adecuadamente las actividades,
funciones y responsabilidades que deben desempearse. El segundo es contar con
la participacin activa y efectiva del personal implicado en el servicio.
El primer paso de cara a implantar un sistema de gestin es crear una estructura
documental. Permite llevar registro y control de todas las actividades realizadas,
evaluar la eficiencia del sistema y servir para la toma de decisiones sobre acciones
correctivas o preventivas. Todas las actividades desarrolladas deben documentarse.
A este respecto estas normas establecen:
UNE-ISO/IEC 20000-1
Los proveedores del servicio deben facilitar documentos y registros para asegurar
una planificacin, operacin y control de la gestin del servicio efectivas. Esto debe
incluir:
a) polticas y planes de la gestin del servicio documentados;
b) acuerdos del nivel de servicio documentados;
c) procesos y procedimientos documentados requeridos por esta norma; y
d) registros requeridos por esta norma.
Deben establecerse los procedimientos y las responsabilidades para la creacin,

revisin, aprobacin, mantenimiento, eliminacin y control de los diferentes tipos de
documentos y registros.
Nota: La documentacin puede estar en cualquier forma o tipo de soporte.
Los soportes en los que est recogida la documentacin deben ser los adecuados
para permitir un normal funcionamiento del sistema. Por ejemplo, si nuestra orga-
nizacin recibe mensualmente 1.000 incidentes, no pueden quedar registrados ni-
camente en un cuaderno. Debern registrarse en una herramienta informtica
dimensionada de acuerdo a las necesidades del proceso y de la organizacin.
La documentacin del sistema contribuye a:
Lograr la conformidad con los requisitos del cliente y la mejora de la calidad.
Proveer la formacin adecuada.
La repetibilidad y la trazabilidad.
Proporcionar evidencias objetivas.
Evaluar la eficacia y la adecuacin continua del sistema de gestin de servi-
cios de TI.
Para gestionar de una forma eficaz la documentacin del sistema es necesario ela-
borar un procedimiento que diga cmo y quin crea los documentos, los revisa,
aprueba, mantiene y elimina.
Estructura del sistema de gestin

En cuanto a su contenido, un sistema de gestin de servicios de TI aloja el conjunto
de documentacin que integra y gestiona toda la informacin necesaria para el fun-
cionamiento eficaz de los procesos, as como para la mejora continua. Esto abarca
desde la estrategia definida por la direccin hasta los aspectos ms detallados como,
por ejemplo, planes de actuacin, la definicin de los procesos, procedimientos,
instrucciones de trabajo, los registros, las mtricas, etc. Todo ello se debe incorpo-
rar en una o varias herramientas de soporte del sistema de gestin. Adems, se
deben establecer los procedimientos de cmo se gestionar y actualizar este sis-
tema (manual del sistema de gestin). En la figura 3.6 se muestra un ejemplo del
contenido de un sistema de gestin para TI.
El sistema de gestin debera contemplar los siguientes contenidos:
Manual del SGSTI, que incluye:
Declaraciones documentadas de una poltica de gestin de servicios: man-
dato de la alta direccin, estrategia, polticas y objetivos.
El plan de accin.
La asignacin de recursos para su definicin y evolucin. Constitucin de
un equipo de trabajo para definir y evolucionar el SGSTI.
El modelo de los procesos de TI.
Estructura organizativa de TI.
Manual de procesos y procedimientos del SGSTI:

Los procesos completamente documentados.
SGSTI
Fuente: Telefnica.
Figura 3.6. Componentes y contenidos habituales

en un sistema de gestin de TI (SGSTI)
Roles, competencias y desarrollo de la estructura organizativa.

Los procedimientos detallados, documentos requeridos por la organiza-
cin para asegurarse de la eficaz planificacin, operacin y control de sus
procesos.
Instrucciones de trabajo.
Registros de los procesos:

Las evidencias o registros requeridos por la Norma ISO/IEC 20000-1
para la certificacin de la conformidad (vase apartado 11.2).
Las mtricas de los procesos y de los servicios.

Las evaluaciones de madurez de la actividad y auditoras.
La gestin del propio SGSTI:

El manual sobre la propia organizacin del sistema de gestin.
Como es lgico, los contenidos del sistema de gestin se deben alojar en una herra-
mienta de soporte documental que permita una gestin de versiones y un control
de los cambios a los contenidos.
El manual del SGSTI es el documento principal que recoge la estrategia de la
empresa, la estructura, responsabilidades, actividades, recursos, modelo de proce-
sos, etc., que una organizacin establece para llevar a cabo la gestin de los servi-
cios de TI. Fsicamente puede ser un nico documento o una estructura documen-
tal basada en versiones.
El manual de procesos y procedimientos del SGSTI contiene la definicin espec-
fica de todos los procesos, procedimientos e instrucciones de trabajo que aseguren
la adecuada gestin de servicios de TI. Nuevamente, la denominacin de manual
no quiere decir que sea un documento nico, pues estar formado por un conjunto
completo de documentos. Pero, eso s, con un adecuado control de versiones. El
manual del SGSTI nos dice: qu? y quin?; mientras que el manual de procedi-
mientos indica: cmo? y cundo?
La definicin de los procesos es una de las principales actividades para el cambio
en el proveedor de TI. Para la definicin de procesos se recomienda la utilizacin
de una herramienta especfica de diagramacin con soporte para poder describir su
contenido. En la figura 3.7 se muestra un ejemplo de la estructura documental para
definir un proceso.
Cuando sea necesario especificar en detalle una actividad o una tarea se utiliza el
documento denominado instruccin de trabajo, que describe la forma en la que
se debe realizar un trabajo. En la figura 3.8 se muestra el ejemplo del contenido de
una de ellas.
SGSTI
ndice del documento de definicin

de un proceso
1. Introduccin
Objetivo del documento. Documentos
de referencia.
2. Definicin del proceso

Misin. Objetivos. Alcance.
Ubicacin del proceso (en el mapa general).
Conceptos clave del proceso.
3. El proceso en detalle
Diagrama de flujo del proceso.
Diagrama de flujo de los subprocesos.
Diagrama de flujo de las actividades.
Detalle de cada actividad y E/S.
Relaciones con otros procesos.
4. Roles y responsabilidades
Roles y sus responsabilidades.
Matriz RACI.
5. Documentos de soporte y formularios

6. Elementos de control del proceso
Mtricas de gestin, mtricas de actividad.
7. Cmo implantar el proceso

Factores crticos de xito. Requisitos para
herramientas.
8. Anexos
Fuente: Telefnica.
Figura 3.7. Ejemplo del ndice del documento para la definicin de un proceso
Instruccin de trabajo para la

clasificacin y priorizacin del incidente
1. Introduccin.
2. Objeto.
3. Campo de aplicacin.
4. Documentos relacionados.
5. Definiciones.
6. Pautas de implantacin.
7. Prioridad de los incidentes.
8. Tabla de prioridades.
9. Lista de umbrales basada en prioridades.
10. Categora de un incidente.
Figura 3.8. Ejemplo del ndice de una instruccin de trabajo
Registros de la actividad diaria y evidencias del

cumplimiento
Un registro es el resultado tangible de la actividad de TI y de los procesos. Por
ejemplo, el incidente registrado en la herramienta de gestin del incidente, una
encuesta de satisfaccin del cliente, una peticin de cambio RFC, unas medidas,
un informe del servicio, un SLA, un elemento en la base de datos de configuracin,
etc. Tambin son registros la documentacin del sistema y sus evoluciones. No hay
un almacenamiento especfico o dedicado de registros. stos quedan guardados en
las propias herramientas o mecanismos de soporten la gestin de TI. Adems,
como premisa bsica, los registros deben estar disponibles, fcilmente identifica-
bles y recuperables.
Los registros, al ser el resultado de la actividad, retienen el conocimiento de la
organizacin de TI.
Una aplicacin importante de los registros es la de proporcionar evidencias de la
conformidad del proveedor de TI con los requisitos de las normas.
SGSTI
Las evidencias son cualquier documento o prueba que proporcione una demostra-
cin objetiva del cumplimiento de las normas por el proveedor de TI. Las eviden-
cias se obtienen de los registros y de cualquier otra forma que permita probar que
se cumplen los requisitos (por ejemplo, un documento, una comprobacin, etc.).
En relacin a las evidencias, ISO/IEC 20000-2 indica:
UNE-ISO/IEC 20000-2
El responsable senior debera asegurar a) polticas y planes;

que las evidencias necesarias estn dis- b) documentacin del servicio;
ponibles para una auditoria de las pol-
ticas, planificaciones y procedimientos c) procedimientos;
de la gestin del servicio y de cualquier d) procesos;
actividad relacionada con ellos.
e) registros de control de procesos.
Gran parte de las evidencias de los planes
y operaciones de la gestin del servicio se Debera existir un proceso para la crea-
deberan encontrar en forma de docu- cin y gestin de los documentos para
mentos, los cuales pueden ser de cual- ayudar a asegurar que se satisfacen las
quier tipo y estar en cualquier formato o caractersticas descritas.
soporte que sea adecuado para su fin.
La documentacin se debera proteger
Los siguientes documentos son conside- de daos, debidos, por ejemplo, a
rados normalmente como vlidos para escasas condiciones del entorno donde
servir de evidencias de la planificacin se encuentran y a desastres en los siste-
de la gestin del servicio: mas informticos.
Los registros estn ligados al control de la actividad de TI, mientras que las eviden-
cias se utilizan directamente para la certificacin y las auditoras.
Competencia, concienciacin y formacin

En este apartado sobre el sistema de gestin, en estas normas se concentran las
directrices y recomendaciones estratgicas para que la evolucin de los servicios
tenga xito. Al principio de este captulo se hace hincapi en que el cambio debe se
liderado por la direccin de la empresa. En la segunda parte del mismo se definen
la gestin documental que da rigor a todo el proceso, para centrarse, en este ltimo
apartado, en las personas que forman el rea de TI.
Tanto estas normas como ITIL, conllevan la transformacin de las formas de hacer
de un conjunto o equipo, ms o menos numeroso, de personas. Se pretende cambiar
la forma de trabajar de las personas que componen TI y la forma en que estas sienten
cul es su misin en la organizacin. El cambio se orienta hacia una sistemtica de
trabajo estructurada, centrada en los clientes, basada en procesos y articulada en
torno a servicios.
Para que esta transformacin se pueda llevar a cabo, hay que poner la mxima aten-
cin y esfuerzo en el equipo humano que est involucrado en los servicios. Pues es
este conjunto de personas el que debe evolucionar sus formas de hacer hacia los
esquemas estandarizados por el mercado.
Por lo tanto, para conseguir una eficaz implantacin del sistema de gestin, es
necesario llevar a cabo la adecuada gestin de los recursos humanos. Para ello,
debemos responder a tres preguntas:
Cules son las necesidades en cuanto a roles y funciones que requiere el sis-
tema de gestin?
Qu perfiles existen dentro la organizacin?
Cmo se va a cubrir el posible desfase entre ambos aspectos?
Para responder a estas preguntas ISO/IEC 20000-1 establece los siguientes requi-
sitos:
UNE-ISO/IEC 20000-1
Se deben definir y mantener todos los roles y responsabilidades de la gestin del

servicio, junto con las competencias que sean requeridas para su ejecucin efec-
tiva.
Las competencias y necesidades de formacin del personal deben revisarse y gestio-
narse para permitir al personal llevar a cabo sus roles de forma efectiva.
La alta direccin debe asegurar que sus empleados son conscientes de la relevancia
e importancia de sus actividades y de cmo deben contribuir a la consecucin de
los objetivos de la gestin del servicio.
El desfase entre roles y responsabilidades que son necesarios desempear se debe

cubrir mediante la realizacin de acciones de formacin e informacin.
El personal que realiza el trabajo en el mbito de la gestin del servicio debera ser
competente gracias a la formacin recibida, a las habilidades y a las experiencias
adecuadas.
SGSTI
UNE-ISO/IEC 20000-2
El personal que realiza el trabajo relativo del ms amplio contexto de nego-

a la gestin del servicio debera ser com- cio y de cmo contribuyen a la
petente para esta funcin gracias a la consecucin de los objetivos de
educacin recibida, a la formacin, las calidad;
habilidades y la experiencia adecuadas.
c) mantener registros apropiados de
El proveedor del servicio debera: la educacin, formacin, habili-
dades y experiencia;
a) determinar las aptitudes necesa-
rias para cada rol en la gestin d) proveer formacin o llevar a cabo
del servicio; otras acciones para satisfacer
estas necesidades;
b) asegurar que el personal es cons-
ciente de la relevancia e impor- e) evaluar la efectividad de las ac-
tancia de sus actividades dentro ciones realizadas.
Como no poda ser de otra forma, ISO/IEC 20000-2 hace especial hincapi en
el desarrollo profesional y de las competencias de las personas que forman parte
de TI:
UNE-ISO/IEC 20000-2
Desarrollo profesional. El proveedor y frente al conjunto de objetivos

del servicio debera desarrollar y mejo- de la calidad del servicio;
rar las competencias profesionales de b) planificacin: con el objetivo de
su fuerza de trabajo. Entre las medidas dotar de personal a los servicios
tomadas para conseguir esto, el prove- nuevos o a aquellos que se hayan
edor del servicio debera incluir lo ampliado (tambin contratando
siguiente: servicios), usando tecnologa
a) contratacin: con el objetivo de nueva, asignando personal de
comprobar la validez de los deta- gestin del servicio a los equipos
lles de los candidatos al puesto de desarrollo de proyecto, planifi-
de trabajo (incluyendo su cualifi- cando la sucesin y rellenando
cacin profesional) y de identificar los vacos que se generen debido
la fortalezas, debilidades y habili- a rotacin anticipada del personal;
dades potenciales de los candida- c) formacin y desarrollo: con el
tos frente a una descripcin/perfil objetivo de identificar los requisi-
del puesto de trabajo, frente a los tos de formacin y desarrollo
objetivos de la gestin del servicio dentro de un plan de formacin y
desarrollo y proveer su imparti- formacin, auto estudio, tutoras y forma-

cin en el momento oportuno y cin en el trabajo) y se debera desarrollar
de forma efectiva. el trabajo en equipo y las habilidades de
liderazgo. Se debera mantener un regis-
Se debera formar al personal en los astro cronolgico de la formacin para
pectos relevantes de la gestin del servi- cada persona, junto con las descripciones
cio (por ejemplo, a travs de cursos de de la formacin proporcionada.
En relacin a la estrategia de contratacin de personal propio de plantilla frente a la

contratacin temporal, ISO/IEC 20000-2 hace unas reflexiones sobre los diferen-
tes enfoques a considerar:
UNE-ISO/IEC 20000-2
Enfoques a considerar. Para que los a) el carcter de las competencias

equipos de personal alcancen unos nuevas o modificadas: si son a
niveles apropiados de competencia, el corto o a largo plazo;
proveedor del servicio debera decidir b) la tasa de cambio en las habilida-
cul es la proporcin ptima entre las des y competencias;
contrataciones a corto plazo y de forma
indefinida. El proveedor del servicio c) los picos y los descensos espera-
debera decidir tambin la proporcin a dos en la carga de trabajo y
alcanzar entre la contratacin de nuevo la combinacin de habilidades
personal con las habilidades requeridas requeridas, datos basados en la
y el reciclaje de personal ya existente. gestin del servicio y en la planifi-
cacin de las mejoras del servicio;
Nota: El equilibrio ptimo entre las contratacio-
nes a corto plazo y de forma indefinida es d) disponibilidad de personal com-
particularmente importante cuando el pro- petente;
veedor del servicio est planificando como
e) tasas de rotacin de personal;
proveer un servicio durante y despus de
cambios a gran escala en el nmero y f) planes de formacin.
habilidades del personal de apoyo.
Para todo el personal, el proveedor del
Los factores que se deberan considerar servicio debera revisar el desempeo a
para establecer la combinacin ms nivel individual al menos anualmente y
adecuada de estos enfoques incluyen: tomar las acciones oportunas.
SGSTI
Presente y futuro del Sistema de Gestin del

Servicio de TI (SGSTI)
Actualmente las empresas no son capaces de digerir e implementar toda la nor-
mativa y buenas prcticas ya definidas por el mercado. La progresiva maduracin
del sector de las TI y de los profesionales que lo forman permitir ir aprovechando
paulatinamente toda la normativa que est definida o se vaya definiendo.
Para ello, el sistema de gestin se debera convertir en un mecanismo intermedio
que traspase y adapte, de forma eficiente, los avances normativos de la industria a
la actividad del proveedor de TI. Este sistema intermedio, entre la normativa
externa y las formas de trabajo internas, permitir al proveedor de TI ir incorpo-
rando paulatinamente en la organizacin las nuevas prcticas que de forma conti-
nua se producen en el mercado. De esta forma, el personal de TI seguir trabajando
con su sistema de gestin y sus evoluciones, independizndose de la vorgine de
produccin y revisin de mejores prcticas en las que el mercado est inmerso.
Pero para mantener actualizado el sistema de gestin, se debera contar con un
equipo especfico de expertos en el anlisis de la evolucin de los entornos norma-
tivos que influyen en TI, para dejar que el resto de la organizacin se concentre en
su trabajo cotidiano. As, la mayora de los profesionales de TI tendran nicamente
que conocer y aplicar el sistema de gestin de TI de su empresa, que ser evolucio-
nado por este grupo de expertos en el SGSTI.
El camino a la excelencia de la gestin de las TI en la empresa pasa por construir
este nico modelo, en el que se vaya incorporando toda la normativa y buenas
prcticas existentes a las formas de hacer internas. As, el sistema de gestin de TI
debe ser un modelo ms amplio, se necesita que vaya ms all de lo establecido en
ISO/IEC 20000 para poder cubrir las necesidades.
Adems, en el mbito ms general de la gestin de la empresa aparece el concepto
de sistema de gestin integrado. En concreto, la Norma UNE 66177 Sistemas de
gestin. Gua para la integracin de los sistemas de gestin hace referencia a la integra-
cin de los sistemas de gestin de calidad, medio ambiente y seguridad laboral
(ISO 9001, ISO 14001 y OHSAS 18001) y define a nivel prctico una metodolo-
ga de integracin de los distintos sistemas de gestin a desarrollar por la organiza-
cin. De forma parecida, la norma britnica BS-PAS 66 Specification of common
management system requirements as a framework for integration especifica los requisi-
tos para un sistema de gestin unificado marco. E incluso existe la Gua ISO 72
que es una gua de referencia para redactar normas que definen los sistemas de ges-
tin, esta gua fue adaptada como informe UNE 66172 IN.
El SGSTI se debera construir sobre el modelo de gestin de la calidad existente en la
empresa, para acabar convirtindose en un modelo integrado que aglutine las formas
en que la empresa gestionar sus TI (denominado aqu para clarificar como:

SGSTI+). Por ello, el SGSTI+ se afrontara con esta visin integradora constituyn-
dose en el nico sistema de gestin de TI e incorporando:
El sistema de gestin general de las TI en base a ISO/IEC 20000, para la
gestin y operacin de los servicios, contemplando las mejores prcticas
de ITIL.
La gestin de la calidad para la construccin o desarrollo de software segn
ISO 9001, UNE 71044 e ISO 90003, junto a CMMI y metodologas de
gestin de proyectos (por ejemplo, PMBOK o PRINCE2).
El sistema de gestin de la seguridad SGSI segn ISO 27001.
La estrategia y gobierno de las TI segn ISO/IEC 38500 y COBIT.
Integrndose el SGSTI+, a su vez, en el sistema de gestin de la calidad
(SGC) general de la empresa segn ISO 9001.
Y el resto de mejores prcticas relacionadas con TI que vayan saliendo.
En la figura 3.9 se muestra una situacin que es frecuente encontrar en las empre-
sas ms avanzadas. En esta primera etapa de evolucin en las formas de gestin de
las TI, se incorporan las normas ms relevantes: para la gestin de sistemas, para el
desarrollo, para la seguridad y para el gobierno de las TI.
El SGSTI debe unificar, incorporndolos, los sistemas de gestin en el mbito de
TI que posiblemente se estn implantando o ya se hayan implantado.
Dado que el entorno normativo est en frentica ebullicin, el sistema de gestin
de TI se debera ir enriqueciendo con aquellos avances normativos que contribu-
yan a la mejora del proveedor de TI, con el fin de implantar en el quehacer coti-
diano de TI la riqueza de las formas de hacer de todos estos estndares. As, la gestin
de todo proveedor de TI se construir tomando en cuenta todos los estndares de
mayor relevancia para tener una gestin de las TI completamente madura (denomi-
nado aqu como: SGSTI++), como se muestra en la figura 3.10.
Despus de esta visin al futuro, conviene dejar claro que en el caso de las Normas
ISO/IEC 20000 slo se exige que se cumpla con los requisitos especificados en
ellas y no se requiere que se incorporen todos los otros estndares mencionados
anteriormente.
En los captulos siguientes del libro se profundiza en los 14 procesos definidos en
estas normas, que son la base para la trasformacin de las actividades ms esencia-
les del proveedor de TI.
SGSTI

Tecnologas de la informacin Sistema de gestin integrado

Gestin y operacin Desarrollo de SW
SG de otras reas Gobierno Seguridad
del servicio de TI Madurez +
de la empresa SG GOB SGSI
SGSTI SG DES.
Calidad y Gobierno Gestin servicio

Seguridad Desarrollo SW
mejora continua TI y su prestacin
SPICE ISO
ISO 9001 COBIT ITIL ISO 17799
15504
CMMI for
ISO 9004 ISO 38500 ISO/IEC 20000 ISO 27001
DEV
ISO 90003
Figura 3.9. Escenario maduro con la incorporacin de normativa

a la gestin de las TI (SGSTI+)

Sistema integrado de gestin del servicio de TI (SGSTI++)

SG de otras reas Incorpora la normativa del mercado relacionada con TI
de la empresa (gobierno, gestin del servicio, desarrollo de SW, proyectos, seguridad, etc.)
Calidad y Procesos propios Medio Gobierno Gestin servicio Desarrollo Getin de

Seguridad
mejora continua del negocio ambiente TI y su prestacin SW proyectos
ISO 9001 Industria CMMI SPICE ISO 17799

Services
ISO 9004 Banca ISO 14001 COBIT ISO 9003 PMBOK ISO 27001
ITIL v3
EFQM Telcos: UNE ISO 38500 ISO 12007 Prince 2 ISO 29382
eTOM ITIL v2
150004 EX PAS 77
6 Sigma Lean ISO/IEC People CMMI
20000
CMMI
Figura 3.10. Escenario previsto 2014 de uso de normativa

para la gestin de las TI (SGSTI++)
Resumen
La aportacin principal de un sistema de gestin es el orden y la estandarizacin.
As, toda la organizacin trabaja de la misma forma y con el mismo idioma. Todo
ello contribuye en la consecucin del objetivo que tiene este sistema de gestin:
hacer posible una efectiva gestin e implantacin de todos los servicios de TI.
El objetivo de este sistema de gestin es conseguir que la provisin y prestacin de
los servicios de TI se realice de una manera eficaz y eficiente.
En la figura 3.11 se recoge una visin completa del SGSTI y su relacin con el da
a da del proveedor de TI.
Fuente: Telefnica.
Figura 3.11. Visin completa del SGSTI y su relacin con el da a da

del proveedor de TI
SGSTI
En la figura 3.12 se muestra a modo de resumen un ejemplo de la estructura docu-

mental de un sistema de gestin de TI.
Estructura documental del SGSTI
1. Manual del SGSTI

El mandato de la alta direccin.
Estrategia, poltica y objetivos de la
gestin de servicios TI.
Plan de accin.
Recursos para su definicin y ejecucin.
Modelo de procesos.
Estructura organizativa.
2. Manual de procesos y procedimientos
del SGSTI
Manual de procesos.
Roles y competencias.
Manual de procedimientos.
Instrucciones de trabajo.
3. Registros de los procesos
Registros.
Mediciones.
Resultados de auditoras y evaluaciones.
4. Gestin y soporte del SGSTI
Manual de gestin del SGSTI.
Herramienta de soporte documental
al sistema.
Fuente: Telefnica.
Figura 3.12. Ejemplo de la estructura documental de un SGSTI

Beneficios
Implantar la gestin de los servicios de TI, utilizando los conceptos y rigor impues-
tos por el sistema de gestin, aporta importantes ventajas a la organizacin de TI:
Formaliza en la organizacin la implantacin de la gestin del servicio.
Propone una aproximacin estructurada de lo general (estrategia y polticas)
a lo particular (procedimientos).
Da soporte a una implantacin por etapas, extendida en el tiempo.
Impone rigor en la definicin, en el seguimiento y en la captura de registros
y evidencias.
Permite la alineacin con los sistemas de gestin de la calidad (ISO 9001)
de la empresa.
Genera un sistema documental en el que se recoge formalmente toda la
informacin necesaria para soportar el modelo de gestin.
La gestin documental que lo soporta es una pieza imprescindible para obte-
ner la certificacin ISO/IEC 20000.
? Aplique lo aprendido
Para afianzar la comprensin del captulo, se sugiere que responda a las
siguientes preguntas 1:
Sabe qu sistemas de gestin hay implantados en su empresa u
organizacin?
Qu aporta un sistema de gestin a las organizaciones de TI?
Cul es la diferencia entre el Sistema de Gestin del Servicio de TI
(SGSTI) y el modelo de procesos ISO/IEC 20000?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
4
Captulo 4
Planificacin e
implementacin de
la gestin del servicio


PDCA
4. Planificacin e implementacin de la gestin del servicio 109
La transformacin del proveedor de TI hacia un modelo orientado a servicios y

ajustado a las necesidades del negocio pasa por la implantacin de formas ms
organizadas y eficientes de gestionar la tecnologa. El reto de las organizaciones se
centra en ser capaces de cambiar evolucionando hacia modelos ms industrializa-
dos de trabajo en TI, alejndose de los individualismos y de las incertidumbres
habituales. Como se ha tratado en captulos anteriores, la adopcin de las prcticas
de ISO/IEC 20000 junto con otras buenas prcticas del mercado (como ITIL) es
el camino ms acertado para el avance.
El problema surge cuando un proveedor de TI se plantea la forma de abordar esta
transformacin interna de su organizacin. La experiencia demuestra que la trans-
formacin con base a ITIL y a las Normas ISO/IEC 20000 puede llevar varios
aos de trabajo continuo, aunque la certificacin se pueda conseguir antes. Ade-
ms, conviene ser conscientes de que se est empezando un camino de mejora con-
tinua en la organizacin. Antes de terminar esta implementacin seguramente
habr que abordar en paralelo otros proyectos de mejora, por ejemplo: la seguri-
dad (en base a ISO/IEC 27001), el gobierno de las TI (ISO/IEC 38500 y
COBIT), el desarrollo de aplicaciones (ISO/IEC 15504 CMMI for Develop-
ment), etc.
Los requisitos y gua del apartado 4 de las Normas ISO/IEC 20000 y este captulo
del libro, estn centrados en ayudar a que la planificacin e implementacin de la
gestin del servicio se alcance con xito. Adems, se enriquece con experiencias
basadas en otras organizaciones pioneras que abordaron o estn abordando esta
transformacin.
Para entenderlo mejor, el ttulo del captulo 4 de las normas, Planificacin e imple-
mentacin de la gestin del servicio, se podra tambin entender como implanta-
cin de las Normas ISO/IEC 20000 o bien implantacin del sistema de gestin
(SGSTI). Es decir, la implantacin de las normas pasa por planificar su implanta-
cin, hacer la implantacin (que incluye la definicin completa del SGSTI), verifi-
car si se han alcanzado los objetivos para establecer las medidas correctoras necesa-
rias, y actuar iniciando un plan de mejora continua.
El apartado 4 de las normas es bastante autoexplicativo y no necesita aclaraciones
especiales, por lo que en este captulo del libro se ha decidido complementar lo
indicado en las normas con la experiencia de los autores en las implementaciones y
parte de lo recogido en ITIL.
PDCA
4.1. Cmo planificar e implementar la gestin

del servicio
Figura 4.1. Planificacin e implementacin de la gestin del servicio

siguiendo el ciclo PDCA
Las Normas ISO/IEC 20000, al igual que muchas otras normas internacionales,
establecen que la implantacin de los procesos para la gestin del servicio se estruc-
ture en las cuatro etapas identificadas por las siglas PDCA, muy utilizadas en gestin
de la calidad (vase la figura 4.1). Estas normas se centran en definir los requisitos y
recomendaciones a tener en cuenta para la implantacin de los procesos establecidos
en los sistemas de gestin, ordenados en cada una de estas 4 etapas del PDCA.
El ciclo PDCA representa una forma de organizar los cambios o las acciones de
mejora en las organizaciones. Es una estructuracin sencilla en 4 pasos y viene a
recordar que, adems de planificar e implementar los cambios, hay que comprobar
el xito de las acciones, y si hay algo que corregir o prevenir (que siempre lo habr)
hay que actuar para subsanarlo. La gran importancia de este ciclo sencillo radica en
que se utiliza mucho en la normativa internacional de ISO y de otras instituciones
como la forma de implantar una actividad de mejora continua de cualquier aspecto
en cualquier organizacin. En la figura 4.2 se muestra este ciclo aplicado a la ges-
tin del servicio de TI.
P
Planificar: planificar la
implementacin y la entrega
de la gestin del servicio.
Plan
Planificar
D A
Hacer: implementar el plan
Do Act Actuar: mejorar la eficacia y
de gestin del servicio. Hacer Actuar la eficiencia de la entrega
y la gestin de los servicios.
Check
Verificar
C
Verificar: monitorizar, medir
y revisar que los objetivos y
el plan de gestin del servicio
se estn alcanzando.
Figura 4.2. Ciclo PDCA aplicado a la implantacin del sistema de gestin de TI
El concepto original del ciclo PDCA fue desarrollado por Walter Shewhart, estads-
tico pionero en el desarrollo de procesos de control estadstico en los Laborarios Bell
de EEUU durante la dcada de 1930. El ciclo de Shewhart fue adoptado y promo-
cionado posteriormente por un discpulo suyo W. Edwards Deming en la dcada de
1950, difundindose como ciclo o rueda de Deming, quien propuso que los procesos
se deben analizar y medir para identificar las causas de las variaciones que originan
que los productos se desven de los requisitos de los clientes. Deming recomienda
que los procesos de negocio deben estar en un bucle realimentado de mejora conti-
nua para poder identificar y cambiar las partes del proceso que necesitan mejora.
Unos aos despus, en su carrera profesional, Deming modifica el concepto origi-
nal de PDCA, cambiando check por study, pues segn l, estudiar describe
mejor la intencin inicial, apareciendo el nuevo ciclo Plan-Do-Study-Act (PDSA),
que ha tenido escasa aceptacin.
Posteriormente la metodologa de mejora continua Seis Sigma define un ciclo de
cinco etapas: Define-Measure-Analyze-Improve-Control (DMAIC) basado en el ciclo
de Deming.
Otros autores proponen anteponer al PDCA una etapa de anlisis y de decisin.
Para ello, utilizan la metodologa FOCUS (Find-Organize-Clarify-Understand-Start);
crendose un ciclo de nueve etapas denominado: FOCUS-PDCA.
PDCA
ITIL v2, en su libro Planning to Implement Service Management, propone para la

implantacin de ITIL un ciclo de seis etapas derivado del PDCA pero que no
encaja exactamente con l. Las etapas de implementacin de la gestin del servicio
en ITIL expresadas en modo de pregunta son:
1. Cul es la visin?: en la que se determinan los objetivos de negocio a alto nivel.
2. Dnde estamos ahora?: realiza una evaluacin o assessment de la situacin
actual.
3. Dnde queremos estar?: fija unos objetivos medibles.
4. Cmo hacemos para llegar?: que establece el plan de accin de implanta-
cin o mejora de los procesos.
5. Cmo comprobamos que hemos alcanzado los objetivos?: comprobacin
de los resultados mediante mtricas.
6. Cmo mantenemos lo alcanzado?: en la que se consolidan los logros alcan-
zados previamente.
En la figura 4.3 se muestran estas 6 etapas en las que ITIL v2 estructura la activi-
dad de implementacin.
Cul es la visin?
Dnde estamos
ahora?
Cmo mantenemos Dnde queremos

lo alcanzado? estar?
Cmo hacemos
para llegar?
Cmo comprobamos
que hemos alcanzado
los objetivos?
Fuente: Libro ITIL Planning to Implement Service Management publicado por OGC.
Figura 4.3. Ciclo de implantacin de ITIL de 6 etapas,

propuesto en su libro Planning to Implement Service Management
Como se aprecia, la interpretacin del ciclo de Deming no es tan uniforme como

parece a primera vista, pues hay varias formas de interpretar el objetivo de cada una
de estas etapas del ciclo:
a) Siguiendo estrictamente las directrices de Deming, despus de la planifica-
cin viene una fase piloto o de test a corta escala del cambio, que se corres-
ponde con la fase de realizar (Do). La fase Check realizara la comprobacin
de que el piloto arroja los resultados esperados, para despus proceder a su
implantacin en la etapa act. Esta interpretacin difiere a la adoptada por la
normativa internacional.
b) Otra interpretacin del ciclo de mejora continua PDCA es la siguiente. se
planifica el cambio (Plan), se ejecuta el cambio (Do), se comprueba su
correcto funcionamiento, se identifican acciones de mejora (Check) y se eje-
cutan las acciones correctivas del cambio (Act). Adems, en la etapa Act se
identifican y deciden las nuevas mejoras que se deberan llevar a cabo, que
se ejecutaran con otro nuevo ciclo PDCA. En esta interpretacin las fases
Check y Act, adems de comprobar los logros alcanzados, proporcionan las
entradas a la nueva fase de planificacin.
c) En las Normas ISO/IEC 20000, la interpretacin realizada del ciclo de
Deming es ms parecida al punto anterior, aunque de la lectura de las nor-
mas se aprecia que en la fase Act se incluye el proceso de mejora continua.
Por tanto, en el texto de las normas no se deduce que se deba iniciar un
nuevo ciclo PDCA de mejora, sino que, es la propia fase de Act la que acoge
la mejora continua de la implantacin realizada.
En este libro se adopta la interpretacin del ciclo de Deming realizada en el punto

b anterior, con un ciclo nuevo de PDCA para cada etapa iniciada de mejora conti-
nua, en el que las fases Check y Act preparan adems las actividades que se debern
planificar en la fase Plan. As, la primera vez se empezara por la fase Check. En la
figura 4.4 se muestra este planteamiento.
PDCA es una espiral o proceso repetitivo de implantacin de mejoras, suele estar
asociado a programas de mejora de la calidad. Se utiliza mucho en la normativa
internacional. Introduce el ciclo de mejora continua, pues una vez finalizadas las
mejoras, vuelve a empezar con otras nuevas.
En el caso de las Normas ISO/IEC 20000, el ciclo PDCA se utiliza para la imple-
mentacin de lo establecido en el sistema de gestin de TI (SGSTI). Al igual que
las mquinas apisonadoras convierten un camino irregular en una autopista de
trnsito rpido, el sistema de gestin de TI permite que las actividades en la orga-
nizacin fluyan con mayor eficiencia. En la figura 4.5 se muestra una representa-
cin de este smil, que compara el SGSTI con la autopista y el ciclo de implantacin
PDCA con la apisonadora que allana el pavimento.
PDCA
Plan
Planificar
Do Act
Ciclo PDCA Hacer Actuar
Fase inicial de evaluacin
habitual
y seleccin de acciones Check
Verificar
C A P D C A
Verificar: Actuar: Planificar: Hacer: Verificar: Actuar:
realizar un identificar planificar la implementar monitorizar, medir mejorar la eficacia
anlisis o las acciones implementacin el plan de y revisar que los y la eficiencia
evaluacin que se deben y la entrega de gestin del objetivos y el plan de la entrega
inicial de la realizar. la gestin servicio. de gestin del y la gestin de
organizacin del servicio. servicio se estn los servicios.
de TI alcanzando.
Figura 4.4. Inicio habitual en TI del ciclo PDCA por una fase inicial de Check y Act
Figura 4.5. El sistema de gestin de TI se implementa con un ciclo PDCA

para alcanzar la excelencia objetivo
UNE-ISO/IEC 20000-1
Nota: La metodologa conocida como Planificar-Hacer-Verificar-Actuar (PDCA, del ingls Plan-Do-

Check-Act) puede aplicarse a todos los procesos. La metodologa PDCA puede describirse del
modo siguiente:
a) Planificar: Establecer los objetivos y los procesos necesarios para proporcio-

nar resultados de acuerdo con las necesidades del cliente y con las polticas
de la empresa.
b) Hacer: Implementar los procesos.
c) Verificar: Monitorizar y medir los procesos y los servicios contrastndolos con
las polticas, los objetivos y los requisitos, e informar sobre los resultados.
d) Actuar: Emprender las acciones necesarias para mejorar continuamente el
rendimiento y comportamiento del proceso.
La Norma ISO/IEC 20000-1 presenta un esquema del PDCA como motor para la
implementacin y mejora de la gestin del servicio. En la figura 4.6, en la parte
izquierda se muestran las entradas a tener en cuenta en la gestin del servicio (requi-
sitos del negocio, requisitos del cliente, solicitudes de servicios nuevos o modifica-
ciones, interfaces con otros procesos, el centro de servicio al usuario, otros grupos o
reas, etc.). En la parte derecha se muestran las salidas de la actividad de gestin del
servicio (entrega de resultados al negocio, satisfaccin de las reas cliente, los servi-
cios nuevos o renovados disponibles, satisfaccin del equipo de TI, etc.). En la parte
central se sita la propia gestin de TI, destacndose la necesaria implicacin de la
direccin y el motor PDCA para implantar y evolucionar la gestin de TI.
Procesos, herramientas y personas son los ejes de la

implementacin
El apartado 4 de las Norma ISO/IEC 20000-1 especifica mientras que la Norma
ISO/IEC 20000-2 recomienda y detalla los temas que se deben tener en cuenta
para la implantacin de estas normas en el proveedor de TI. Como se ha visto en el
captulo 3 de este libro, la implantacin de ISO/IEC 20000 se realiza siempre a tra-
vs del sistema de gestin (SGSTI). Es decir, el captulo 4 recomienda una disci-
plina de trabajo a tener en cuenta para la implantacin del SGSTI especfico del
proveedor de TI.
Las claves para alcanzar el xito en una implementacin de la gestin de los servi-
cios de TI es tener siempre en cuenta las tres reas bsicas necesarias para el cambio
PDCA
Fuente: UNE-ISO/IEC 20000.
Figura 4.6. La metodologa planificar-hacer-verificar-actuar

para los procesos de gestin del servicio
cultural y organizacional: los procesos, las herramientas que los soportan y las per-
sonas. reas que, aunque no resultan nuevas en absoluto, no por ello dejan de ser
importantes para estructurar las actividades que se deben realizar. En la figura 4.7
se muestran estas tres reas alrededor del SGSTI y del ciclo PDCA utilizado para
implementarlo y mejorarlo.
Los procesos marcan las formas de hacer

La definicin de nuevas formas de hacer ms eficaces, estructurando los trabajos pri-
mero en procesos, estos en subprocesos, en actividades y en procedimientos detalla-
dos, formar parte del conocimiento y cultura de la empresa y se incorporar con
rigor al sistema de gestin (SGSTI). La planificacin de la definicin de los proce-
sos se realiza en la fase plan y su propia definicin se realiza en la fase do. Gran parte
del texto de las Normas ISO/IEC 20000, de los libros ITIL y tambin el resto de
este libro, estn dedicados a especificar y explicar los procesos y las actividades de TI
con gran cantidad de detalles, por lo que no es necesario tratarlo en este captulo.
Figura 4.7. Las 3 reas que se deben considerar siempre

para la implantacin con xito de ISO/IEC 20000
La experiencia muestra que estos marcos de mejores prcticas utilizan una visin
bastante homognea de los procesos y de su contenido, por lo que las diferencias
en la definicin de los mismos son pequeas. Es en los detalles de quin y con qu
se realizan (contenidas en los procedimientos) cuando empiezan a aparecer diferen-
cias entre las organizaciones. Por este motivo se recomienda realizar con rapidez la
definicin de procesos y procedimientos, y tambin contar con el apoyo de una
consultora externa para ello.
La definicin de los procesos es una actividad importante en la implantacin y, ade-
ms, se suele concluir con bastante xito. Pero hay que recordar que no es la nica
faceta: los procesos hay que implantarlos para que el personal trabaje de acuerdo a
ellos; el apoyo de las herramientas de gestin es esencial para dar eficiencia y con-
ducir el trabajo diario; y el cambio cultural de la organizacin es el factor ms dif-
cil de llevar a cabo.
Las herramientas son necesarias para la productividad y

el control
Las Normas ISO/IEC 20000 no establecen ningn requisito ni recomendacin
sobre las herramientas de soporte a la gestin de TI y la actividad de los procesos.
Pero, en las instalaciones medianas, y especialmente en las grandes, las herramientas
PDCA
de gestin de TI son esenciales para proporcionar la agilidad necesaria en la organi-

zacin, para garantizar que se siguen las formas de hacer definidas, y para almace-
nar y retener el conocimiento. Adems, las herramientas permiten el seguimiento
de los procesos, su medicin y su mejora.
Las herramientas son uno de los factores crticos de xito en la implantacin de la
norma. Pero las herramientas tienen un coste nada despreciable: en licencias (aun-
que hay algunas gratuitas), en plataforma, en parametrizacin, en soporte, en for-
macin y en su evolucin. Dependiendo del tamao del proveedor de TI, de la
diversidad de los servicios y del volumen de su actividad, variar la complejidad de
las herramientas. La seleccin de las herramientas vendr marcada por los requisi-
tos que impongan los procesos ya definidos. Tambin hay que considerar el apro-
vechamiento de las que estn en uso (siempre que cumplan las exigencias de los
procesos).
La seleccin y compra de un conjunto de herramientas de gestin no es una labor
trivial y, con frecuencia constituye un proyecto en s mismo. Hay que establecer: el
mbito que se debe cubrir, una extensa lista de requisitos que se deben exigir a las
herramientas, analizar la oferta del mercado, etc. Tambin, la propia implantacin
de las herramientas en s, constituye uno o varios proyectos, dependiendo del
tamao de la instalacin y la diversidad de productos seleccionados.
Hay un primer grupo de herramientas que posibilitan la actividad de implantacin
de las normas, por lo que deben ser las primeras que se seleccionen e implementen,
por ejemplo:
El soporte documental del sistema de gestin. Es recomendable disponer
de un gestor documental con control de versiones y acceso web. Aunque en
los inicios, cualquier herramienta colaborativa con interfaz web de la
empresa podr demorar la inversin en el gestor documental, e incluso, con
un sistema de archivos organizado y controlado puede ser suficiente en
estos inicios.
La herramienta de diseo de procesos. En el mercado hay varias herramien-
tas de diseo de procesos que se pueden utilizar a estos fines. Hay que deter-
minar que informacin ir volcada en la herramienta de procesos y cual se
mantendr externamente en archivos de texto. En cualquier caso, TI debera
utilizar la herramienta y metodologas utilizadas en la empresa para definir
sus procesos de negocio, y no trabajar por su cuenta; situacin bastante
frecuente. Si la empresa no tiene una slida implantacin de la cultura de
calidad y procesos, es habitual que se empiece con una solucin de diagra-
macin de flujos ofimtica (como Microsoft Visio o Microsoft PowerPoint)
y la descripcin de los procesos en texto (Microsoft Word). Este escenario
no se recomienda, pues cualquier evolucin obligar a revisar las referencias

cruzadas en los textos y redibujar todos los grficos.
Una herramienta de gestin de proyectos que implemente la metodologa
que se vaya a seguir. La implementacin de la gestin del servicio es com-
pleja, lleva mucho tiempo y puede estar formada por varios proyectos que
transcurrirn en paralelo. Por ello, se debe contar desde el principio con una
herramienta que permita realizar una planificacin tanto de alto nivel, como
de detalle. Siempre que sean adecuadas, se recomienda utilizar las herramien-
tas y metodologas existentes en la empresa, pues la implementacin de las
normas debe apoyarse y aliarse con toda la organizacin. En un escenario
bsico para la gestin de proyectos la herramienta ofimtica Microsoft
Project puede ser vlida. En relacin a las metodologas, el mundo ITIL
recomienda el uso de Prince2. Tambin PMBOK est muy extendido para
proyectos de desarrollo de software.
Un cuaderno de bitcora. En l se registrarn da a da las acciones que se
estn ejecutando y las actas de las reuniones. Este diario podr acabar con-
virtindose en un blog interno de soporte a la comunicacin del proyecto.
En la estrategia de implantacin se definirn los procesos a implantar, normal-

mente en una aproximacin por fases. Lgicamente, segn sea el orden de implan-
tacin de los procesos, se debern incorporar las herramientas que los soporten,
por lo que las herramientas se irn aadiendo paulatinamente, acompaando a la
implantacin de los procesos, pero siempre dentro de una estrategia previamente
definida.
A continuacin se presenta una relacin de herramientas de gestin de TI tpica-
mente utilizadas en las empresas ms avanzadas, cada organizacin deber adaptar
esta relacin a sus caractersticas particulares:
Herramienta para la gestin de contactos en el centro de atencin del usuario.
Herramienta para la gestin de incidentes o herramienta de ticketing.
Herramienta para el autorregistro web de incidentes y peticiones de usuarios.
Herramienta para la autorresolucin de incidentes por los usuarios.
Herramienta para la gestin de la configuracin, incluyendo la base de datos
de configuracin (CMDB).
Herramienta para a gestin de inventarios y activos.
Herramientas para el autodescubrimiento de activos: de ordenadores perso-
nales, de elementos de red, de servidores, de usuarios, etc.
PDCA
Herramienta para la gestin del cambio.

Soporte a la biblioteca definitiva de software (DSL).
Herramienta para la gestin de nivel de servicio. Herramientas para una
visin dinmica del estado de cada servicio y de sus componentes.
Portal para la publicacin de informes web, estticos o dinmicos.
Soporte a la base de datos de la capacidad (CDB).
Herramienta para el control y registro de costes.
Herramienta para el anlisis de tendencias.
Gestor documental del sistema de gestin SGSTI.
Herramienta de diseo de procesos.
Herramienta de gestin de proyectos.
Cuaderno de bitcora y un boletn de comunicacin.
Herramienta de gestin de perfiles profesionales y RRHH de TI.
Plataforma de monitorizacin y una consola central de eventos.
Adems, tambin ser necesario un conjunto de herramientas tcnicas de admi-

nistracin y gestin de: servidores, bases de datos, discos de almacenamiento, equi-
pos de comunicaciones, planificacin de trabajos batch, seguridad, etc.
Con la intencin de simplificar para los que se inician en el camino (y siempre pen-
sando en las instalaciones medianas o grandes), el conjunto mnimo de herramien-
tas que un proveedor de TI tipo debera tener en las etapas iniciales sera: la ges-
tin documental para alojar el SGSTI, la herramienta para la gestin de incidentes,
la CMDB, la DSL y un portal para la publicacin web de informes. El resto de las
necesidades de herramientas se podra cubrir inicialmente con soluciones ya exis-
tentes en la empresa o soluciones provisionales basadas en herramientas ofimticas.
En la figura 4.8 se muestra un conjunto bsico de herramientas sealando los pro-
cesos que cubren sobre el esquema de ISO/IEC 20000.
Si analizamos el desglose de los costes de un proyecto de implantacin de herra-
mientas, se aprecia que, normalmente, la partida de licencias software suele suponer
el 30% del presupuesto del proyecto. El 70% restante se repartira entre los servi-
cios de implantacin, la formacin, cambio cultural y el hardware de los servidores.
Tambin hay que considerar, para los presupuestos futuros, el coste del manteni-
miento evolutivo y correctivo de las mismas, as como, el coste de operacin y de
mantenimiento.
Figura 4.8. Herramientas mnimas e imprescindibles

en la gestin del servicio y los procesos a los que dan soporte
Cuidar al personal de TI es clave para el xito

No hay que olvidar que una excelente definicin de procesos que engranen todas
las actividades a la perfeccin no es suficiente. Ni siquiera con las mejores herra-
mientas de soporte, pues gran parte del trabajo requiere de la intervencin de las
personas que forman el equipo de TI. Por lo que el frecuentemente olvidado factor
humano resulta ser clave para el xito de la implantacin y, por ende, clave para la
supervivencia de la empresa.
No hay un directivo en el elenco de TI que no predique y derroche halagos sobre la
importancia de las personas que forman su equipo de trabajo, pero con frecuencia
todo se queda solamente en palabras. Todo directivo que se precie deber apostar
claramente por el factor humano, con acciones tangibles y concretas ya que para el
xito de la implementacin de las nuevas formas de trabajo las palabras no bastan.
El personal de TI, muy machacado por la presin diaria, no se deja influir fcil-
mente por declaraciones de principios relativas a la importancia de las personas. Lo
que necesita son hechos visibles que les demuestren que la alta direccin apuesta de
PDCA
verdad por el cambio y que ellos son importantes para conseguirlo. Sin cumplir
este requisito el fracaso est garantizado.
La importancia de las personas en este camino de transformacin se debe manifes-
tar ntidamente en:
Planes paulatinos, constantes e intensivos de formacin sobre las nuevas for-
mas de trabajo y las nuevas herramientas de gestin.
Entrenamiento individual en las funciones de su puesto, hasta que cada uno
llegue a desempearlas a la perfeccin.
Comunicacin, nimo y estmulo constante. Mediante conferencias, reunio-
nes, boletines internos, etc. Transmitiendo tranquilidad ante la incertidum-
bre del cambio y entusiasmo.
Motivacin permanente a los que se implican y una gestin pertinaz de quie-
nes se muestran reticentes al cambio.
Evolucin organizativa gil. Los nuevos roles necesarios se deben definir y
nombrar con rapidez.
Autoridad y disciplina. Es necesario mantener el principio de autoridad, pues
el servicio de TI no es un juguete tecnolgico, y s es o ser la pieza esencial
para la supervivencia de la empresa.
Foco en el dominio de la tecnologa. No se debe olvidar la necesidad del
dominio absoluto de la tecnologa, sin el cual, todo esfuerzo de establecer
procedimientos y organizar ser en vano. As, por muy detallados que se ten-
gan los procedimientos, por muy alineados que se est con el negocio, si los
programadores no saben construir cdigo de calidad o si el tcnico de
soporte al intentar resolver una incidencia destroza el equipo por desconoci-
miento tcnico, no hay transformacin posible.
Fase preliminar a la implementacin: evaluacin o

assessment inicial
Cuando el proveedor de TI se sita por primera vez ante el dilema de cmo
abordar la implementacin, en las Normas ISO/IEC 20000 aprecia la falta de
una etapa previa que analice la situacin actual de la organizacin de TI, y deter-
mine las acciones y permita establecer fases. En implantaciones de estas normas
es frecuente y recomendado empezar por una evaluacin de la situacin actual de
partida (o assessment), en el mercado hay varios modelos aplicados especficamente
a ISO/IEC 20000 o a ITIL. El informe resultante de la evaluacin debera tratar

los aspectos siguientes:
La evaluacin debera comenzar con la descripcin de la problemtica prin-
cipal actual de la organizacin que se quiere resolver, si es que estuviera iden-
tificada.
Una descripcin de la organizacin: misin, servicios, infraestructuras, tec-
nologa, personal, estrategia de contratacin, contratos con suministradores,
volmenes de actividad (nmero de incidentes, solicitudes, cambios, etc.),
herramientas de gestin y tcnicas utilizadas, tendencias del negocio, tenden-
cias tecnolgicas, etc.
Un anlisis de la madurez inicial de la actividad de la organizacin, siguiendo
la estructura de procesos de la norma. Este anlisis se suele realizar mediante
un cuestionario que suelen contener entre 8 y 20 preguntas por proceso,
segn el grado de profundidad que se quiera alcanzar. El cuestionario se cen-
tra tanto en la identificacin de prcticas o actividades frente al marco de refe-
rencia, como en el grado de formalizacin de los procesos en la organizacin.
Un anlisis de ratios o indicadores generales de la organizacin y su compa-
racin con el mercado (benchmarking).
Una matriz de debilidades y fortalezas, que en ocasiones se extiende a la
matriz de debilidades-amenazas-fortalezas-oportunidades (DAFO).
Las conclusiones, con las recomendaciones y acciones a emprender, estable-
ciendo fases para ellas.
La evaluacin inicial se puede realizar de forma interna o contando con el apoyo de

una consultora externa. Las consultoras tienen sus propios modelos de evaluacin,
pero tambin se pueden encontrar otros en el mercado (as itSMF-UK tiene uno vin-
culado a ITIL, itSMF-Espaa dispone de otro similar, etc.). El resultado de la evalua-
cin se suele representar en formato de grfico circular, tipo araa o de Kiviat, en el
que se representa en una silueta la madurez obtenida proceso a proceso. En el grfico
de la figura 4.9 se ilustran a modo de ejemplo los resultados de una evaluacin.
La evaluacin de los procesos, que se suele medir en una escala de cinco niveles de
madurez de 1 a 5, normalmente se inspira en el modelo utilizado por CMMI, (en
el mbito de estas normas todava no hay un modelo consensuado o estandari-
zado). A continuacin se detallan los niveles definidos en ITIL v2 (consltese Plan-
ning to Implement Service Management. Anexo J Process Maturity Framework):
1: Inicial. Las organizaciones en este nivel no disponen de un entorno estable.
Aunque se utilicen tcnicas correctas, los esfuerzos se ven minados por falta
PDCA
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creacin
Configuracin
2 servicios
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
Figura 4.9. Ejemplo de resultados en un grfico tipo araa o de Kiviat

de una evaluacin de madurez de procesos ISO/IEC 20000
de planificacin. El xito se basa la mayora de las veces en el esfuerzo perso-

nal aunque, a menudo, se producen fracasos y casi siempre retrasos y sobre-
costes. El resultado es impredecible.
2: Repetible. En este nivel las organizaciones disponen de unas prcticas insti-
tucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un
razonable seguimiento de la calidad. La relacin con suministradores y clien-
tes est gestionada sistemticamente.
3: Definido. Adems de una buena gestin de proyectos, a este nivel las orga-
nizaciones disponen de correctos procedimientos de coordinacin entre gru-
pos, formacin del personal, tcnicas de procesos ms detalladas y un nivel
ms avanzado de mtricas en los procesos.
4: Gestionado. Se caracteriza porque las organizaciones disponen de un con-

junto de mtricas significativas de calidad y productividad que se utilizan de
modo sistemtico para la toma de decisiones y la gestin de riesgos. Los ser-
vicios resultantes son de calidad.
5: Optimizado. La organizacin completa est volcada en la mejora continua
de los procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de
innovacin.
El comportamiento de las organizaciones sigue patrones

similares
La experiencia demuestra que las organizaciones, a la hora de abordar la implemen-
tacin de la gestin del servicio de TI, siguen patrones de comportamiento bas-
tante similares segn sea la situacin y motivacin del proveedor que le impulsa a
adentrarse en la transformacin hacia procesos eficientes. Gracias a este ejercicio de
sntesis, conociendo cul es la motivacin inicial que impulsa la adopcin, se puede
predecir cul ser el patrn de comportamiento de la organizacin a lo largo del
proceso de implementacin.
Los patrones de comportamiento de las organizaciones ante la implementacin de
la gestin del servicio se han dividido en 5 perfiles:
1. Saturados. Por la actividad diaria que prcticamente no tienen capacidad de
moverse debido a la saturacin.
2. Econmicos. Organizaciones en una situacin de fuerte contencin econ-
mica que fuerza a la utilizacin de los recursos internos y al uso de las herra-
mientas existentes.
3. Obligados. La obtencin del certificado de conformidad con las normas es
el principal impulsor del proceso, limitando las oportunidades de mejora.
4. Condicionados. Normalmente por movimientos derivados de consolidacio-
nes organizativas o externalizaciones parciales, hacen que sea necesario uni-
formizar las formas de hacer. Por suerte, en estos escenarios dentro de los
planes y presupuestos de la consolidacin caben las partidas para la transfor-
macin de la organizacin, con lo que los resultados llegan a ser similares a
los visionarios.
5. Visionarios. La alta direccin de TI ve con una nitidez meridiana la necesi-
dad de transformacin, liderando todo el proceso.
PDCA
La figura 4.10 muestra el detalle de estos 5 patrones de comportamiento.
+
SATURADOS ECONMICOS OBLIGADOS CONDICIONADOS VISIONARIOS
(Por actividad diaria) (En reduccin (Por necesidad (Por consolidaciones o (Negocios en alza)
de costes) de certificado) por outsourcing)
Patrones de comportamiento durante la implementacin de la gestin del servicio
Formacin reducida. Charlas introductorias. Foco en aprobar el Formacin global: Formacin global:
Creen en ITIL pero Formacin examen que supone amplia. extensiva.
no practican. especializada: puntual. la obtencin de la Formacin Formacin
certificacin. especializada: amplia. especializada:
Desarrollo de Desarrollo de
proyectos puntuales proyectos tcticos. Una o dos personas Desarrollo de proyectos abundante.
y por necesidad encargadas de estratgicos y Desarrollo de
Equipos de proyecto preparar un sistema
operativa formado por personal completos. proyectos estratgicos
(por ejemplo, de documentacin (y tcticos alineados
interno. que justifique el Equipos de trabajo con
catlogo de personal interno y fuerte con la estrategia).
servicios, etc.). Reutilizacin de cumplimiento de
herramientas existentes. las normas. apoyo de especialistas Equipos de trabajo
externos. con personal interno
Compra herramientas Foco en los papeles y fuerte apoyo de
de forma puntual. y en la formalizacin Foco en normalizacin
integrada y herramientas especialistas externos.
documental.
que lo soporten. Foco en normalizacin
Poco inters por mejorar. e integracin de
Mejoras de rebote. procesos y las
Cambios puntuales. herramientas que
lo soporten.
Charlas introductorias.
Formacin especializada
puntual.
Fuente: Telefnica.
Figura 4.10. La situacin de partida permite prever el comportamiento

en la implementacin
Planificacin de la gestin del servicio (Planificar)
UNE-ISO/IEC 20000-1
Objetivo: Planificar la implementacin y la provisin de la gestin del servicio.

Se debe planificar la gestin del servicio. Como mnimo, el plan debe definir lo
siguiente:
a) el alcance de la gestin del servicio del proveedor del servicio;
b) los objetivos y los requisitos que se tienen que alcanzar por la gestin del servicio;
c) los procesos que se van a ejecutar;
d) el marco de los roles y responsabilidades de la direccin, incluyendo al direc-
tivo de alto nivel responsable directo, al propietario del proceso, a la direccin
de la gestin y a la direccin de los suministradores;
e) las interfaces entre los procesos de gestin del servicio y el modo en que
tienen que coordinarse las actividades;
f) el enfoque que hay que dar a la identificacin, la evaluacin y la gestin de
actividades y de los riesgos para la consecucin de los objetivos definidos;
g) el enfoque para la relacin con proyectos que estn creando o modificando
los servicios;
h) los recursos, el equipamiento y los presupuestos necesarios para alcanzar los
objetivos definidos;
i) las herramientas adecuadas para dar soporte a los procesos; y
j) cmo se va gestionar, auditar y mejorar la calidad del servicio.
Deben estar claramente definidas tanto la orientacin de la gestin como las res-
ponsabilidades documentadas para revisar, autorizar, comunicar, implementar y
mantener los planes.
Cualquier plan especfico de un proceso que se elabore debe ser compatible con
este plan de gestin del servicio.
Adems, ISO/IEC 20000-2 aade dos aspectos ms que se deberan considerar en

la planificacin:
UNE-ISO/IEC 20000-2
g) una planificacin de los recursos h) el enfoque para la modificacin
expresada en trminos de las fechas del plan y de los servicios defini-
en las que deberan estar disponi- dos por el plan;
bles las fuentes de financiacin, las
habilidades y los recursos;
PDCA
El plan de implantacin debe contemplar todos los aspectos relativos a los tres blo-
ques principales: los procesos, las herramientas de gestin necesarias y las perso-
nas. En la figura 4.11 se aprecia un ejemplo de las actividades que se deben con-
templar en un plan de implantacin de estas normas.
Definicin de los primeros estndares:

Catlogo de servicios y diseo CMDB.
Definicin de los procesos.
PRELIMINAR PROCESOS
Definicin de los procedimientos.
Definicin de los roles y puestos.
Formacin a lderes. Definicin de indicadores e informes.
Creacin equipo
implementacin.
Evaluacin o assessment. Requisitos herramientas.
Objetivos. Seleccin y compra SW/HW.

HERRAMIENTAS
Plan implementacin. Parametrizacin herramientas.
DE GESTIN TI
Presentaciones internas. Implantacin herramientas.
Comunicacin inicial. Carga de datos.
Formacin de profesionales.
Plan de comunicacin.
Cambio organizativo.
PERSONAS
Entrenamiento personal.
Despliegue de herramientas.
Cambio de formas trabajo.
Fuente: Telefnica.
Figura 4.11. Toda implementacin debe contemplar los tres aspectos

fundamentales: los procesos, las herramientas y las personas
En la figura 4.12 se muestra una aproximacin sencilla en 5 pasos a la implementa-

cin de la gestin del servicio, con el fin de demostrar que es posible iniciar el
camino sin excesiva complejidad. En este ejemplo, la implementacin se inicia con
una evaluacin (interna o externa) de madurez, para pasar a constituir un pequeo
equipo de trabajo que se responsabilizar de todo el proceso. El tercer paso sera
formalizar el plan de implementacin, para iniciar un proceso de formacin y certi-
ficacin de los profesionales de TI que acompaar prcticamente a todo el pro-
ceso de realizacin.
1.o Realizar una evaluacin de la madurez inicial
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creacin
2.o Crear un equipo de trabajo

Configuracin
2 servicios
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
3.o Definir la estrategia de implementacin

Mandato de la direccin
Definir el plan de implantacin
4.o Formacin y certificacin de profesio- Otras etapas de PDCA: ejecucin del plan
nales clave en ITIL e ISO/IEC 20000 de implementacin, comprobacin y mejora
Figura 4.12. Ejemplo de una aproximacin sencilla a la implementacin
Alcance de la gestin del servicio
UNE-ISO/IEC 20000-2
El alcance de la gestin del servicio se La direccin debera definir el alcance

debera definir como parte del plan de como parte de sus responsabilidades de
gestin del servicio. Por ejemplo, puede gestin (y como parte del plan de ges-
definirse segn: tin del servicio). Luego se debera com-
probar si el alcance resulta adecuado
a) la organizacin;
para la Norma ISO/IEC 20000-1.
b) la ubicacin;
Nota: La planificacin de los cambios operativos
c) el servicio. se describe en el apartado 9.2.
PDCA
ISO/IEC 20000 requiere de un compromiso expreso de la direccin de la empresa.

ste es un requisito general que se aplica en toda la parte 1 de estas normas, y muy
especialmente en los apartados que necesitan de un mayor empuje como es la
implementacin del SGSTI.
Enfoques de la planificacin
UNE-ISO/IEC 20000-2
Se pueden utilizar varios planes de ges- Un plan de gestin del servicio debera
tin del servicio en lugar de un plan o incluir:
programa de gran magnitud. En este a) la implementacin de la gestin
caso, los procesos subyacentes a la ges- del servicio (o de parte de la ges-
tin del servicio deberan ser coherentes tin del servicio);
entre ellos. Tambin se debera poder
b) la entrega de los procesos de la
demostrar cmo se gestiona cada
gestin del servicio;
requisito de planificacin vinculndolo
a sus correspondientes funciones, res- c) los cambios de los procesos de la
ponsabilidades y procedimientos. gestin del servicio;
La planificacin de la gestin del servi- d) las mejoras de los procesos de la
cio debera formar parte del proceso gestin del servicio;
para convertir las necesidades de los e) los nuevos servicios (hasta el punto
clientes y las intenciones de los directi- que afecten a los procesos inclui-
vos en servicios y para proporcionar dos en el alcance acordado de la
una gua para dirigir el progreso. gestin del servicio).
Orden de implementacin de los procesos

En el momento de seleccionar los procesos que se van a implementar se plantean
varias tcticas posibles. Se presentan dos aproximaciones generales:
Implantar los procesos uno a uno para todos los servicios y toda la organiza-
cin de TI. Permite ir extendiendo las mejoras paulatinamente de una forma
ms uniforme.
Seleccionar uno o varios servicios y, sobre este ncleo ms reducido, implantar
todos los procesos. Esta es la implantacin es ms rpida y permite aprender
de los errores cometidos, pero plantea en TI una dicotoma, pues las mismas
personas tendrn que trabajar de una forma o de otra segn del servicio de
que se trate. Debemos destacar que este segundo caso es el ms eficaz para la
obtencin de un certificado.
En la figura 4.13 se muestra la implementacin del sistema de gestin en varias eta-

pas que pueden corresponder a la implementacin progresiva de procesos o a la
incorporacin paulatina de servicios por fases al SGSTI.
Figura 4.13. La transformacin de la organizacin se realiza

normalmente en etapas paulatinas
Es conveniente comentar diversas estrategias de planificacin de la implantacin

para seleccionar los procesos por los que empezar la implementacin, segn sea la
situacin o problemtica de partida de cada organizacin. Hay que tener en cuenta
que todos los procesos estn relacionados, por lo que el beneficio completo no se
PDCA
consigue hasta que no estn todos ellos implantados. Como las combinaciones son
muchas, a continuacin se presentan las ms frecuentes:
Escenario 1: Inestabilidad. Una organizacin con inestabilidad y con con-
tinuos cortes del servicio estar sumida en una crisis permanente restaurando
los servicios. En esta situacin, lo primero que hay que hacer es poner foco
inmediato en controlar la situacin. Para ello ser necesario trabajar con la
gestin del incidente para minimizar los tiempos de no disponibilidad. De
forma casi paralela, parece razonable implementar tambin la gestin del
cambio, que pone orden en todo paso al entorno productivo y reduce el
nmero de incidentes que se producen derivados de los cambios. Adems,
ser conveniente iniciar la gestin del problema, para eliminar los fallos y
defectos ocultos. Tambin se debera abordar soluciones de monitorizacin
para tener un mejor control del entorno productivo.
Escenario 2: Garantizar. Es este caso, la organizacin de TI necesita dar
garantas al negocio de que las prdidas de informacin y del servicio son
mnimas. Lgicamente, es una situacin ms avanzada que el escenario 1 de
crisis, aunque no se debe poner en riesgo el negocio por que TI no pueda
recuperar los datos o los sistemas. El foco se debe poner en los procesos que
garantizan que los servicios se puedan restaurar en cualquier situacin, bien
sea por fallos locales o por el impacto de desastres mayores. Antes de comen-
zar con los procesos ISO/IEC 20000, habr que revisar o implantar una
solucin slida de copias de seguridad (backup). Despus, deber centrarse
en el registro de las versiones de las aplicaciones instaladas y de la parametri-
zacin realizada. Para ello ser tratar la gestin de la configuracin y la ges-
tin de la entrega. Posteriormente, se implementar la gestin de la conti-
nuidad para garantizar la recuperacin en caso de desastre.
Escenario 3: Relaciones. Si el servicio es estable pero la opinin de las
reas negocio clientes sobre el servicio de TI es mala y las relaciones son
tensas y difciles, la estrategia debe ser distinta. Hay que ponerse de inme-
diato a regular y mejorar la comunicacin, a tranquilizar al negocio y a ges-
tionar las expectativas. En este escenario lo razonable sera comenzar con la
gestin de las relaciones con el negocio y definir un catlogo de servicios
que regule las expectativas sobre TI, para pasar inmediatamente a la defini-
cin de acuerdos de nivel de servicio (SLA) y a implementar la gestin de
nivel de servicio que se encargue de seguir su cumplimiento. La gestin
de informes y su disponibilidad online al negocio mejorar enormemente la
percepcin sobre TI.
En la figura 4.14 se muestra un esquema de los escenarios 1 al 3.

Escenario 1 Escenario 2 Escenario 3

Inestabilidad! Garantizar! Relaciones!
Copias de Gestin de las

Gestin del
backup relaciones con
incidente
robustas el negocio
Gestin de la
Gestin Catlogo
configuracin
del cambio de servicios
CMDB y DSL
Gestin del Gestin de Gestin de nivel

problema la entrega de servicio
Plataforma de Gestin de la Gestin

monitorizacin continuidad de informes
Figura 4.14. Ejemplos de estrategias de implantacin de procesos

segn la situacin a resolver
Adems de los ejemplos anteriores, se pueden dar otras situaciones a partir de las
cuales se decide implementar ISO/IEC 20000:
Escenario 4: Un problema. Foco en resolver un problema inmediato que
existe en la organizacin. En este caso, TI no se puede detener a realizar eva-
luaciones sobre la madurez actual. Se deben identificar los principales pro-
blemas acuciantes del proveedor de TI para buscar soluciones inmediatas.
Cada problema tendr su propia aproximacin. El problema puede ser de
ndole tcnico, organizativo, de motivacin, de capacitacin, de gestin, etc.
Las Normas ISO/IEC 200000, junto con ITIL y el sentido comn, aporta-
rn alguna va de solucin.
Escenario 5: Foco en los servicios crticos. La empresa tiene claramente
identificados cules son sus servicios crticos con gran impacto en la actividad
PDCA
del negocio. En este caso, la estrategia recomendada es implementar el

SGSTI circunscrito inicialmente a este ncleo de servicios crticos, que por
otra parte sern los ms cuidados, y con los que se justificarn ante la direc-
cin mejor las inversiones para el inicio de la transformacin.
Escenario 6: Obtener la certificacin. El mercado, la legislacin o la
direccin exige al proveedor de TI la obtencin inmediata de la certifica-
cin ISO/IEC 20000. En esta situacin no hay alternativa posible. Para
obtener la certificacin ser necesario implantar los 14 procesos de estas
normas. Adems, se deber formalizar todo en el sistema de gestin
SGSTI. La nica variable en este escenario sera intentar acotar el alcance
de la certificacin a los servicios con ms repercusin en el mercado o afec-
tados por la legislacin, con el fin de agilizar al mximo la obtencin del
citado certificado.
Escenario 7: Crisis econmica. Situacin marcada por la necesidad de fuer-
tes restricciones presupuestarias, en las que la organizacin de TI debe aqui-
latar al mximo sus costes recurrentes. En este escenario, TI tambin es un
excelente instrumento para proponer soluciones que ayuden a la reduccin
de los costes operativos de la empresa. Dada la necesidad imperiosa de con-
trol de los costes, ser necesario comenzar por el proceso de elaboracin de
presupuestos y contabilizar, seguido del proceso de gestin de la capacidad
que permitir ajustar los recursos sin comprometer el servicio. Las relaciones
con el negocio permitirn a TI proponer nuevas soluciones.
Eventos a considerar
UNE-ISO/IEC 20000-2
El plan de gestin del servicio debera d) los cambios de la legislacin;

estar enfocado a los procesos de ges-
e) las modificaciones de normativas
tin del servicio y a los cambios en los
como, por ejemplo, modificaciones
servicios desencadenados por eventos
de las tasas impositivas locales;
como los siguientes:
f) la liberalizacin o la regulacin
a) la mejora del servicio;
de los sectores industriales;
b) los cambios en el servicio;
g) las fusiones y las adquisiciones.
c) la normalizacin de infraestruc-
turas;
Bsqueda de xitos rpidos (quick-wins)

En la planificacin de la implementacin hay que tener en cuenta la bsqueda de
xitos rpidos, conocidos como quick-wins. Dado que el proceso de transformacin
es prolongado, resulta esencial acompaar todo el camino con xitos rpidos que
infundan moral y confianza en el proyecto, tanto a la direccin, como al resto del
personal.
Un xito rpido es una actuacin sencilla de implementar que aporta resultados
tangibles de forma inmediata. Lo que se percibe como un xito rpido vara de una
a otra organizacin. A continuacin se enumeran algunos ejemplos posibles:
1. Creacin del comit de cambios que de forma inmediata ponga orden en las
implantaciones. Definir un documento de peticin de cambio.
2. Mejorar la atencin de incidencias centrndose en un sistema crtico.
3. Documentar la configuracin de los sistemas crticos.
4. Crear un catlogo de servicios que permita empezar a hablar en trminos de
servicio.
5. Resolver algunos de los problemas que generan muchos incidentes.
6. Si no existe, establecer un punto nico de contacto para los usuarios con TI.
7. Implementar un formulario web de registro de peticiones e incidentes de
usuario para reducir las llamadas telefnicas al centro de atencin al usuario.
8. Aadir a la anterior una pgina web para la autorresolucin por parte del
usuario de las peticiones ms frecuentes (por ejemplo, la restauracin de con-
traseas).
9. Consolidar la informacin de incidentes en una nica base de datos.
10. Con el fin de involucrar a todas las partes, definir un ciclo completo para la
creacin de nuevos servicios, involucrando al personal de desarrollo y al de
planificacin y control.
11. Empezar a publicar mtricas semanales de la actividad de TI. Implemen-
tar una monitorizacin desde el punto de vista del usuario (al efecto exis-
ten soluciones sencillas de navegacin que simulan el comportamiento
del usuario). Publicar va web la monitorizacin para el acceso de las
reas cliente.
12. Realizacin de un informe sobre el estado de TI que permita involucrar la
direccin en el proyecto.
PDCA
13. Establecer acciones de formacin para los principales actores en TI. Se

puede optar por un da de introduccin a ITIL con ejercicios de simulacin,
o directamente impartir cursos de tres das de introduccin a ITIL (denomi-
nado Foundation).
Conviene tener en cuenta que los xitos rpidos hay que publicitarlos en la organi-
zacin.
Implementacin de la gestin del servicio y provisin de

los servicios (Hacer)
UNE-ISO/IEC 20000-1
Objetivo: Implementar los objetivos y el plan de gestin del servicio.

El proveedor del servicio debe implementar el plan de gestin del servicio para pro-
veer y gestionar los servicios, incluyendo:
a) la asignacin de presupuestos y fondos;
b) la asignacin de roles y responsabilidades;
c) la documentacin y el mantenimiento de polticas, planes, procedimientos y
definiciones para cada proceso o conjunto de procesos;
d) la identificacin y la gestin de riesgos para el servicio;
e) la gestin de los equipos de trabajo, por ejemplo, la contratacin y el desarrollo
del personal adecuado y la gestin de continuidad del personal;
f) la gestin del equipamiento y el presupuesto;
g) la gestin de los equipos o grupos de personas, incluidos los del centro de ser-
vicio al usuario y los de operaciones;
h) informar del progreso en comparacin con los planes; y
i) la coordinacin de los procesos de gestin del servicio.
ISO/IEC 20000-1 comienza sus requisitos de la fase de implementacin con la

asignacin de presupuestos y fondos, as como la asignacin de roles y responsabi-
lidades. Estas son las primeras actividades de la fase de realizar.
En el punto c del recuadro anterior de la norma se recoge toda la actividad de

documentacin, incluyendo las polticas, los planes, definiciones de los procesos,
los procedimientos, etc. En el captulo 3 de este libro, relativo al SGSTI, se reflej
la necesidad de crear un sistema documental, que es esencial para todo el proceso
de implementacin.
Los siguientes requisitos son relativos a la gestin necesaria durante todo el pro-
ceso de implementacin, comprendiendo riesgos, equipamiento, presupuestos,
equipos o grupos de soporte, etc.
Tambin es esencial la comunicacin con toda la organizacin para mantener infor-
mado tanto a la direccin como al resto del personal de todo el proceso de imple-
mentacin.
Por supuesto, todo cambio debe ser coordinado con los procesos de gestin del ser-
vicio que ya existan, o con los que actualmente realicen sus funciones.
Grupo de implementacin o de procesos de TI

Como ya se ha visto, en el captulo 3, se necesita la fuerte implicacin de la alta
direccin, la necesidad de un responsable de alto nivel en la organizacin de TI
denominado patrocinador o responsable del SGSTI y, que este responsable debe
contar con personal de apoyo en su labor. Para la etapa de planificacin e implanta-
cin de estas normas se debe constituir un equipo de trabajo especfico o grupo de
implantacin, que estar activo desde las primeras fases de definicin hasta concluir
la implantacin final.
El grupo de implantacin depender directamente del patrocinador y se debera
situar jerrquicamente en el organigrama como un grupo de apoyo al director de TI
(habitualmente denominado CIO, del ingls: Chief Information Officer). Aunque es
menos recomendable, a veces en grandes organizaciones este equipo depende del
director de explotacin, de produccin o de operaciones (vase la figura 4.15).
Otras veces, este equipo de procesos de TI est vinculado al mbito de gobierno o
de planificacin y control de TI. En otros casos, los procesos de TI estn asociados
con las arquitecturas de TI (de datos, de aplicaciones y de plataformas).
A la hora de definir los procesos, el grupo de implantacin debe involucrar a las
personas clave de la organizacin de TI que conocen el funcionamiento interno y
las actividades que se realizan. Tambin debera trabajar estrechamente con las reas
de calidad o procesos de la empresa. El equipo de implantacin deber dedicar un
tiempo inicial a preparar el entorno de trabajo y el control de todos los proyectos
que surjan para la implementacin del sistema de gestin.
PDCA
UNE-ISO/IEC 20000-2
Nota: Es posible que la persona que sea ade- mentacin inicial no sea la apropiada para la
cuada para realizar la planificacin y la imple- operacin continua.
Con frecuencia, en las implantaciones de la gestin del servicio, el equipo que

implanta no es el mismo que el responsable de la produccin o explotacin de los
servicios. Pero, en cualquier caso, la definicin de las formas de hacer se debe implicar
directamente a estos responsables, pues luego tendrn que aplicarlas a sus equipos.
Es complicado abordar la transformacin interna contando nicamente con el per-
sonal de la empresa, pues con frecuencia se carece de los conocimientos, los perfiles
o la experiencia adecuados. Lo recomendable es contar con apoyo externo, en
forma de consultora, para los tres aspectos: definicin de procesos y procedimien-
tos, implantacin de herramientas y formacin y cambio cultural. Entre estos con-
sultores externos es conveniente asegurarse que siempre hay un perfil evangeliza-
dor, alguien que ayude a movilizar y motivar a los directores todava reacios al
cambio, e insufle dinamismo y entusiasmo entre el personal.
Opcin ideal: dependencia directa del Director de TI
Director de TI
Patrocinador SGSTI
CIO
Grupo implementacin y
Planificacin Direccin de Direccin de procesos TI
y control desarrollo produccin
Opcin frecuente: dependencia directa del Director de produccin
Director de TI
CIO
Planificacin Direccin de Direccin de

y control desarrollo produccin
Patrocinador SGSTI
La propia direccin de produccin es
consciente de la necesidad de mejora Grupo implementacin y
e impulsa la implantacin de procesos. procesos ISO/IEC 20000
Figura 4.15. Dos escenarios ejemplo de ubicacin del grupo

de implementacin del SGSTI
Dado que la transformacin es un proceso continuo, este equipo creado ad-hoc para
el proyecto o los proyectos de implantacin, suele constituirse en una estructura
estable en el tiempo. Este equipo muy centrado inicialmente en la implantacin,
va evolucionado su actividad hacia la mejora continua de los servicios y de la activi-
dad de TI.
En las grandes organizaciones habra que tener en cuenta la necesidad de diversos tipos
de apoyo externo a lo largo del tiempo. A este respecto, en las ms avanzadas, suelen
contratar una evaluacin anual o bianual para identificar las fortalezas adquiridas y los
nuevos puntos de mejora. A veces, adems de esta evaluacin se suele realizar un
benchmarking comparativo con el mercado de los ratios ms destacados de TI.
La aparicin continua de normativa, que por una parte aporta ayuda a las empresas
pero que por otra acaba convirtindose en una nueva demanda del mercado, hace
que este equipo de implantacin o de procesos de TI tenga garantizada una intensa
actividad para los prximos 10 aos.
Las empresas debern tener en cuenta, en sus estrategias y sus porfolios de proyec-
tos anuales, destinar una partida al proyecto de transformacin continua de las for-
mas de hacer.
Monitorizacin, medicin y revisin (Verificar)

Con el fin de determinar el grado de efectividad de la implementacin del plan de
gestin del servicio se debe monitorizar, medir y revisar el grado de consecucin
de los objetivos alcanzados. Tanto la parte 1 como la 2 de estas normas establecen
claramente los criterios a seguir:
UNE-ISO/IEC 20000-1
Objetivo: Monitorizar, medir y revisar que los objetivos y el plan de gestin del ser-
vicio se estn cumpliendo.
El proveedor del servicio debe aplicar mtodos adecuados para la monitorizacin y,
cuando sea necesario, la medicin de los procesos de gestin del servicio. Estos
mtodos deben demostrar la capacidad de los procesos para alcanzar los resulta-
dos planificados.
La direccin debe realizar revisiones a intervalos planificados para determinar si los
requisitos de gestin del servicio:
a) son conformes con el plan de gestin del servicio y los requisitos de esta
norma, y
b) se implementan y se mantienen de manera eficaz.
PDCA
Se debe planificar un programa de auditoras, teniendo en cuenta el estado y la

importancia de los procesos y las reas que auditar, as como, los resultados de
las auditoras anteriores. Se deben definir en un procedimiento los criterios, el
alcance, la frecuencia y los mtodos de la auditora. La seleccin de los audito-
res y la realizacin de las auditoras deben garantizar la objetividad y la impar-
cialidad del proceso de auditora. Los auditores no deben auditar su propio tra-
bajo.
El objetivo de las revisiones, evaluaciones y auditoras de la gestin del servicio se
debe registrar junto con las conclusiones de dichas auditoras, sus revisiones y las
acciones correctivas que se hayan identificado. Se debe comunicar a las partes
correspondientes la existencia de cualquier rea significativa con alguna no confor-
midad u otra discrepancia.
UNE-ISO/IEC 20000-2
El proveedor del servicio debera plani- Los resultados del anlisis deberan pro-
ficar e implementar la monitorizacin, porcionar una entrada a un plan para
la medicin, el anlisis y la revisin de la mejora del servicio.
los servicios, los procesos de gestin
Adems de las actividades de gestin
del servicio y los sistemas asociados.
del servicio relativas a la medicin y el
Entre los elementos que se deberan
anlisis, es posible que la alta direccin
monitorizar, medir y revisar estn los
necesite recurrir a auditoras internas y a
siguientes:
otros tipos de verificaciones. Al decidir
a) los logros respecto a los objetivos la frecuencia de dichas auditoras inter-
de servicio definidos; nas y verificaciones, se deberan tener
en cuenta, entre otros, factores como el
b) la satisfaccin del cliente;
nivel de riesgo implicado en un pro-
c) la utilizacin de los recursos; ceso, su frecuencia de realizacin y su
historial de problemas pasados. Las
d) las tendencias;
auditoras internas y las verificaciones se
e) las no conformidades de mayor deberan planificar, registrar y llevarse a
consideracin; cabo de una manera competente.
Mejora continua (Actuar)

Estas normas establecen claramente la necesidad de la realizacin de una mejora
continua, tanto en lo relativo a la mejora de los procesos implementados de gestin
del servicio, como en la mejora de los servicios prestados en s mismos.
UNE-ISO/IEC 20000-1
Objetivo: Mejorar la eficacia y la eficiencia de la entrega y de la gestin del servicio.
Poltica:
Debe haber una poltica publicada sobre la mejora del servicio. Se debe corregir
cualquier no conformidad con la norma o con los planes de gestin del servicio.
Se deben definir claramente los roles y las responsabilidades para las actividades de
mejora del servicio.
Gestin de las mejoras del servicio:

Se deben evaluar, registrar, priorizar y autorizar todas las propuestas de mejora del
servicio. Se debe utilizar un plan para controlar la actividad.
El proveedor del servicio debe disponer de un proceso para identificar, medir y ges-
tionar las actividades de mejora e informar de dichas actividades de manera conti-
nua. Este proceso debe incluir:
a) las mejoras de un proceso aislado que el propietario del proceso pueda
implementar con los recursos de personal habituales, por ejemplo, la realiza-
cin de acciones correctivas y preventivas; y
b) las mejoras en toda la organizacin o en ms de un proceso.
Actividades:
El proveedor del servicio debe realizar actividades para:
a) recopilar y analizar los datos para delimitar y medir la capacidad del provee-
dor del servicio para gestionar y proveer el servicio junto con los procesos de
gestin del mismo;
b) identificar, planificar e implementar mejoras;
c) consultar a todas las partes implicadas;
d) establecer objetivos de mejora en cuanto a la calidad, los costes y la utiliza-
cin de recursos;
e) tener en cuenta las aportaciones importantes, referentes a mejoras, que se
realicen desde todos los procesos de gestin del servicio;
f) medir, informar y comunicar las mejoras en el servicio;
g) revisar las polticas, los planes y los procedimientos de gestin del servicio,
siempre que sea necesario; y
h) asegurar que todas las acciones aprobadas se llevan a cabo y que se alcan-
zan los objetivos deseados.
PDCA
UNE-ISO/IEC 20000-2
Poltica: nado para cumplir con los requisitos de

la poltica desde su propia perspectiva y
Los proveedores del servicio deberan
desde la perspectiva del cliente.
reconocer que siempre existe la posibili-
dad de conseguir que la provisin del Antes de implementar un plan de
servicio sea ms eficaz y ms eficiente. mejora del servicio, se deberan regis-
Debera hacerse pblica una poltica de trar los niveles de servicio y la calidad
la calidad y de mejora del servicio. del servicio como lnea de referencia
Todas las personas implicadas en la sobre la que se puedan comparar las
gestin del servicio y la mejora del ser- mejoras reales. Para evaluar la eficacia
vicio deberan ser conscientes de la pol- del cambio se debera comparar la
tica de calidad del servicio y de cul mejora real con la mejora prevista.
debera ser su contribucin personal a la Nota 1: Los requisitos para la mejora del servicio
consecucin de los objetivos estableci- pueden venir de todos los procesos.
dos en esta poltica.
En particular, todo el personal del pro- animar a su personal y a sus clientes a
veedor del servicio implicado en la ges- proponer alternativas para mejorar los
tin del servicio debera tener un cono-
servicios.
cimiento detallado de las repercusiones
de estos factores sobre los procesos de Nota 2: Esto se puede conseguir utilizando es-
gestin del servicio. quemas de sugerencias, crculos de cali-
dad, grupos de usuarios y reuniones de
Debera existir una coordinacin eficaz coordinacin.
entre la estructura de gestin propia del
proveedor del servicio, los clientes y los Los objetivos de la mejora del servicio
suministradores del proveedor del servi- deberan ser medibles, estar vinculados
cio a la hora de tratar cuestiones que con los objetivos de negocio y estar
afecten a la calidad del servicio y a los documentados en un plan.
requisitos del cliente. La mejora del servicio se debera gestio-
nar de una manera activa y se debera
Planificacin de mejoras del servicio:
supervisar el progreso tomando como
Los proveedores del servicio deberan referencia los objetivos formalmente
adoptar un enfoque metdico y coordi- acordados.
En la mejora continua hay que distinguir dos tipos de mejoras: la mejora de los
procesos de gestin del servicio y la mejora propia de los servicios. Ambos tipos de
mejora redundarn en que la organizacin de TI funcione con ms eficiencia, y en
que los servicios prestados sean de mayor calidad.
En el caso de la mejora de los procesos, las acciones de mejora de cada uno de ellos
las identifica y propone el propietario o el responsable del proceso. En relacin a
las mejoras en cada uno de los servicios, las detecta, recopila de otras partes y pro-
pone cada uno de los gestores de nivel de servicio (vase el apartado 6.1). En ITIL,
para el conjunto de mejoras de uno o varios servicios agrupados en un plan se ha
acuado el trmino de plan de mejora del servicio (SIP, Service Improvement Pro-
gram). Las acciones de mejora pueden abarcar todo tipo de actividad necesaria:
mejoras tecnolgicas en los servicios, incorporacin de herramientas, formacin a
los involucrados, comunicacin, mejora en la documentacin, etc.
A la luz de lo establecido y recomendado por estas normas, parece razonable que
todas las acciones de mejora (de los procesos y de los servicios) se consoliden en una
planificacin o un plan de mejora unificado, formado en base de los planes de
mejora de cada proceso y de cada servicio. De esta forma se tendr una visin unifi-
cada de todas las acciones de mejora y las interrelaciones entre ellas. Este plan de
mejora unificado se puede ejecutar por fases y aplicando nuevamente el ciclo PDCA.
Las propuestas de mejora, que emanan de diversas fuentes (mejoras detectadas en
cada proceso, plan de mejora del servicio, iniciativas de calidad como Seis Sigma o
Lean, etc.), recopiladas por los gestores de los procesos, se agrupan para organizar-
las en un plan consolidado. As, la mejora continua de la gestin del servicio se rea-
liza de una forma coordinada por un responsable nico de esta actividad. En la
figura 4.16 se muestra la agrupacin de las propuestas de mejora en un plan unifi-
cado comn a toda la organizacin de TI.
Figura 4.16. La mejora de los procesos y de los servicios

se consolida en un plan unificado
PDCA
Resumen
La implementacin de sistema de gestin del servicio de TI (SGSTI) est bien
especificada en las Normas ISO/IEC 20000 y debe seguir las 4 etapas del ciclo de
mejora continua de Deming (PDCA). En la figura 4.17 se muestra de nuevo la
aplicacin de estas 4 etapas al SGSTI.
Plan Do Check Act

PLANIFICAR HACER VERIFICAR ACTUAR
Planificar Implementar Monitorizar, Mejora
la gestin la gestin medir y revisar continua
del servicio del servicio
Figura 4.17. Resumen de las 4 etapas del ciclo PDCA aplicadas

a la gestin del servicio
En la figura 4.18 se presenta un ejemplo de actividades y tcnicas asociadas a cada una

de las etapas del PDCA. La etapa Plan lleva incluida el anlisis de la situacin actual.
Beneficios
La implantacin de la gestin del servicio de TI siguiendo el ciclo PDCA y los
requisitos especificados y recomendados en las Normas ISO/IEC 20000, aportarn
entre otros, los beneficios siguientes:
Permitir que todas las actividades de transformacin de la organizacin se
lleven a cabo de una forma controlada y organizada.
Los objetivos se fijan en funcin de la situacin de partida, obtenida
mediante una evaluacin inicial.
Los proyectos de implementacin tienen unos objetivos fijados.
Se monitorizan y miden los resultados de los proyectos.
Se establece un plan de mejora continua.
Se aprovecha la experiencia de otras organizaciones que iniciaron antes el
camino.
Tcnicas asociadas al PDCA En la etapa Do se puede realizar:

Ejecucin de las acciones planificadas
en la fase de plan.
En la parte Plan se puede estructurar en:
Ejecucin de las mediciones oportunas
Descripcin del problema: para establecer una lnea base.
Diagramas de afinidad. Ejercer un seguimiento de la ejecucin
del plan.
Recopilacin de datos:
Recopilacin de la informacin
Matrices. necesaria para la toma de decisiones
Diagramas de control. entes de la fase check.
Anlisis de datos: En la etapa Check :
Histogramas. Ejercer un seguimiento de las acciones
implementadas.
Formulacin de las causas:
Analizar los resultados.
Diagramas de raspa.
Evaluacin de las mejoras.
Diagramas de relaciones.
Planificar la estandarizacin de las
Diagramas de flujo.
mejoras si procede.
Elaboracin de hiptesis y Tener en cuenta la posible resistencia
comprobacin de hiptesis: de la organizacin al cambio.
Histogramas. Recopilar la informacin necesaria para
Nubes de puntos. tomar la decisin de estandarizar o no.
Identificar las causas raz: En la etapa Act :

Diagramas de raspa. Supone establecer la nueva forma de
Paretos. hacer las cosas que elimina las causas
de los problemas que se quera resolver.
Propuesta de acciones: Documentar la nueva manera de hacer
Diagramas de rbol. las cosas.
Evaluacin y seleccin de acciones: Informar a todas las partes implicadas
de los nuevos mtodos de trabajo.
Matrices.
Proporcionar formacin sobre la nueva
Identificacin de mtricas: forma de hacer las cosas.
Diagramas de tendencias. Establecer los nuevos mecanismos de
Histogramas. control para asegurar que la nueva
forma de hacer las cosas subsiste
Planificacin de las acciones: en la organizacin.
Diagramas de flechas.
Diagramas de Gantt.
Figura 4.18. Ejemplo de actividades y tcnicas asociadas a cada etapa del PDCA
PDCA
Cmo se aplica el ciclo PDCA en su organizacin?
Cul es la secuencia de implantacin de los procesos que ms se
adecua a su caso particular?
En funcin de su experiencia, qu otras recomendaciones de imple-
mentacin aadira a este captulo?
1
5
Captulo 5
Planificacin e implementacin
de nuevos servicios o de
servicios modificados


5. Planificacin e implementacin de nuevos servicios o de servicios modificados 151
Las organizaciones de TI, y las actividades que desarrollan, han sido tradicional-
mente vistas como un soporte interno al negocio, descuidando en general el uso de
criterios apropiados para medir su rentabilidad, eficacia y la calidad del servicio
ofrecido a toda la organizacin. Actualmente el entorno donde nos movemos, en el
que los horarios de disponibilidad de los servicios son cada vez ms amplios, donde
las exigencias del cliente son cada vez ms elevadas, y donde los cambios en el
negocio son cada vez ms rpidos, es muy importante que los sistemas de informa-
cin estn adecuadamente organizados y alineados con la estrategia de la empresa.
La planificacin e implementacin de nuevos servicios o de servicios modifica-
dos, tiene la misin de garantizar que los servicios se puedan crear y entregar con
la funcionalidad, costes, calidad y plazos acordados con los clientes. Para ello hay
que gestionar el ciclo completo de la provisin y entrega de los servicios, realizando
una planificacin unificada e integrada, asegurando que todas las partes implicadas
conocen y cumplen con el plan y los compromisos acordados.
En este captulo se presenta una visin de este proceso, con un alcance ms all de
lo establecido en estas normas, definiendo el marco de un proceso nuevo que est
presente a lo largo de todo el ciclo de vida de la provisin de un servicio: desde la
elaboracin de la propuesta de servicio, hasta la revisin despus de su implanta-
cin, en el entorno de produccin real. El proceso recorre y organiza con eficiencia
a toda la organizacin de TI, sirviendo como integracin entre la estrategia del
negocio, el desarrollo de aplicaciones, el departamento de explotacin o produc-
cin, y el rea de planificacin y control econmico de TI.
Para las empresas que ya tengan implementada una metodologa o un proceso de
gestin de los proyectos para el desarrollo de aplicaciones, este captulo les apor-
tar nuevos puntos de mejora para incorporar y con ello enriquecer y complemen-
tar la metodologa ya implementada, facilitando as la integracin con los nuevos
procesos de gestin del servicio. Por tanto, este proceso utiliza las metodologas y
procesos existentes en la organizacin para cubrir parte de sus etapas. En este cap-
tulo no se aborda la descripcin de la etapa de construccin (software y hardware)
del servicio, ni en las metodologas gestin de proyectos TI (PMBOK, PRINCE2,
etc.), aunque stas sern necesarias para gestionar los proyectos de creacin de los
servicios. Tambin sera necesaria la utilizacin de otros estndares y mejores prc-
ticas relacionados con el desarrollo de software (SPICE o CMMI).
El lector comprender mejor los detalles de este proceso cuando haya profundizado
en el resto de procesos de gestin del servicio, pues utiliza gran parte de ellos. En
realidad, el captulo se debera haber ubicado de los ltimos del libro, pero se ha
decidido mantener la posicin que tiene en las normas para conseguir una numera-
cin de captulos similar.
Dada la extensin del ttulo proceso de planificacin e implementacin de nuevos

servicios o de servicios modificados, en numerosas ocasiones a lo largo del cap-
tulo se hace referencia al mismo como creacin y evolucin de los servicios.
5.1. El proceso de planificacin e implementacin

de nuevos servicios o de servicios modificados
Figura 5.1. Esquema general del proceso de planificacin e implementacin

de nuevos servicios o de servicios modificados
Actualmente no basta con ser rpidos. Es necesario que el proceso de creacin y

entrega de servicios TI se realice de forma eficiente y que el producto resultante
rena los requisitos demandados por el cliente (vase la figura 5.1). Plazos, eficien-
cia y calidad son tres exigencias para el xito empresarial.
Para conseguir el objetivo de gestionar y entregar tanto los nuevos servicios como
las modificaciones a los existentes con la calidad y costes adecuados, ISO/IEC
20000 esboza un proceso que se encarga de gestionar el ciclo completo de creacin
de los servicios. Su mbito de actuacin abarca tanto los nuevos servicios como las
evoluciones de los que ya estn en su fase de operacin habitual.
En este captulo se presenta el marco de un proceso completamente nuevo inspirado
a partir de los requisitos de ISO/IEC 20000. El proceso de creacin de servicios, o
similar, no est contemplado explcitamente en ITIL. Aunque la v3 estructure sus
libros alrededor del ciclo de vida del servicio y proporcione gran cantidad de detalles
y buenas prcticas articuladas en diferentes procesos, no tiene un nico proceso que
aglutine todas las actividades de las diferentes reas de TI para una creacin eficiente
de los mismos. La mayor semejanza a este proceso se encuentra en las metodologas

de desarrollo de software, que este proceso enriquecer. Este nuevo proceso es impor-
tante para las organizaciones de TI, ya que incorpora las prcticas avanzadas de las
unidades que han tenido que responder de forma muy dinmica creando y evolucio-
nando servicios para poder atender al ritmo competitivo que les impone su negocio.
Los servicios no slo se componen de cdigo, adems utilizan otros componentes
de infraestructura. Tambin necesitan personal tcnico que los administre y
soporte. As, se debe analizar, desde el inicio del proyecto, la integracin en la
arquitectura de TI, la disponibilidad, la capacidad, su continuidad, las necesidades
para su operacin, etc. Tambin, hay que formalizar con los clientes los acuerdos
de nivel de servicio a cumplir.
Este proceso tiene como punto de partida la estrategia de TI ya definida. A partir de
aqu, desde el momento en que se empieza a concebir la primera propuesta del servi-
cio, toma el control para no cederlo hasta el final, en la entrega a operacin para su
explotacin. Al superponer este proceso sobre el ciclo de vida del servicio planteado
en ITIL v3, se aprecia que recorrera las etapas de diseo y de transicin (vase la figu-
ra 5.2). Pero las importantes disciplinas necesarias para la construccin o el desarrollo
de los servicios apenas se tratan: en el libro Diseo del Servicio se menciona la activi-
dad de desarrollo de la solucin de servicio, mientras que en el libro de Transicin del
Servicio se habla de la actividad de construccin y prueba del cambio y de la versin.
Alcance de la planificacin e implementacin de

nuevos servicios o de servicios modificados
en ISO/IEC 20000
Ciclo de vida del servicio en ITIL v3
ESTRATEGIA DISEO TRANSICIN
OPERACIN
MEJORA
CONSTRUCCIN
CONTINUA
(ntese que la construccin en ITIL v3 apenas se trata)
Figura 5.2. Alcance del proceso comparado con el ciclo de vida

del servicio de ITIL v3
El proceso de creacin o evolucin de servicios acta como un proceso director,

que va encadenando y coordinando la participacin de los otros procesos o funcio-
nes de TI. Comienza en el cliente para terminar con el servicio entregado y opera-
tivo. Para evitar duplicar funciones, utiliza los otros procesos de gestin del servicio,
como las relaciones con el negocio, la gestin de nivel de servicio, la generacin de

informes del servicio, etc. Tal y como se aprecia en la figura 5.3.
Fuente: Telefnica.
Figura 5.3. El ciclo de creacin de los servicios comienza en el cliente, termina

con los servicios operativos y utiliza el resto de procesos y actividades de TI
En el mbito de TI, este proceso es el responsable de confeccionar una planifica-

cin integrada de todas las actividades necesarias para la creacin de los servicios.
Garantiza que los nuevos servicios cumplirn con lo acordado con el cliente (pla-
zos, coste, funcionalidad y calidad) y que se construyen con las polticas y las nor-
mativas vigentes en la organizacin. Con la colaboracin continua de todos los
procesos, funciones y departamentos involucrados, tratar de encontrar el equili-
brio correcto entre la demanda, la satisfaccin del cliente y el coste de crearlos.
Gran parte de este proceso gestiona tambin las funciones habituales de la gestin de
proyectos de desarrollo de software en TI. Para cubrir estas funciones, posiblemente
ya se hayan implementado procesos y metodologas propios de la organizacin
o basados en estndares del mercado (SPICE, CMMI, PMBOK, PRINCE2, etc.).
En este escenario, el proceso de creacin de servicios aporta una visin completa
de las actividades que se deben realizar para que el servicio que se va a construir
quede perfectamente operativo, incluyendo el diseo, la arquitectura, el desarrollo
de las aplicaciones, la creacin de la plataforma tecnolgica, los procedimientos de

operacin, etc. Este proceso pone especial foco en la integracin con los requisitos
ISO/IEC 20000. Se superpone sobre los procesos y metodologas de desarrollo
existentes para enriquecerlos e integrarlos con la gestin del servicio de TI. Por
tanto, no las debera reemplazar, sino enriquecer y coordinar para que los engrana-
jes de la creacin de servicios funcionen sin fricciones en la organizacin. En la
figura 5.4 se muestra un ejemplo del alcance del proceso sobre las etapas tpicas de
un proyecto de desarrollo de software.
Figura 5.4. El proceso de creacin de servicios integra en su flujo a los procesos

de desarrollo de software y las metodologas de gestin de proyectos
Por tanto, este proceso es idneo para la integracin de las dos reas de TI, tradi-
cionalmente separadas y mal engranadas: el desarrollo y la produccin.
En la figura 5.5 se muestra un esquema global que integra el ciclo de vida ITIL v3,
con las etapas tpicas de las metodologas de gestin de proyectos, los procesos de
desarrollo de software y la relacin con el resto de los procesos de gestin del servi-
cio de TI contemplados en ISO/IEC 20000.
La creacin y evolucin de servicios orquesta una cadena de fabricacin en TI,
que comienza con los requisitos del negocio y termina con los servicios operativos.
En un extremo de la cadena de fabricacin est la necesidad del cliente de nuevas
funcionalidades de negocio y, en el otro extremo, se obtiene el servicio entregado y
operativo. El cliente, tras el tiempo acordado, espera recibir el servicio pactado que
cumpla con la funcionalidad, los costes y los acuerdos de servicio establecidos al
inicio del proceso. Justo entre estos dos extremos, es necesario desarrollar toda una
Fuente: Telefnica.
Figura 5.5. Ciclo tipo de creacin de servicios en el marco de las actividades de TI
labor de fabricacin que identifique todas las reas y procesos de la organizacin

TI intervinientes y las coordine bajo un nico plan de proyecto, hacia la consecu-
cin de las necesidades de los clientes, bajo criterios de calidad y eficiencia.
En la figura 5.6 se representa un smil de la cadena de fabricacin que organiza
este proceso. En la parte superior, podemos ver los diferentes intervinientes que
participan en el proceso de creacin y evolucin de servicios, y cmo, a modo de
tolva, aaden su contribucin a la creacin de un nuevo servicio. Entre los intervi-
nientes se han incluido adicionalmente algunos procesos y funciones no contem-
plados en ISO/IEC 20000 (desarrollo de aplicaciones, construccin de la infraes-
tructura de TI y operacin del servicio), que son fundamentales para poder realizar
una correcta planificacin e implantacin de los servicios. En la parte inferior se
representa este proceso que, a modo de cinta transportadora, va desplazando inexo-
rablemente al servicio a construir de una fase a otra en la lnea de fabricacin hasta
que, tras la entrega, se obtiene un servicio operativo y listo para ser utilizado por el
cliente.
Figura 5.6. El presente proceso orquesta la actividad de fabricacin del servicio
Cada uno de los otros procesos que participan en la cadena tiene unos objetivos
especficos y su propio aporte a la construccin del servicio final. Aunque estos
procesos no se han tratado todava en este libro, es conveniente tener una visin
general de su participacin en este proceso. A continuacin, se detallan los prin-
cipales:
Relaciones con el negocio. Su objetivo es establecer y mantener una buena rela-
cin entre el proveedor del servicio y el cliente, basndose en el entendimiento del
cliente y de los fundamentos de su negocio (vase el captulo 7 para obtener ms
detalles de este proceso).
El proceso de creacin de servicios engrana con este proceso de relaciones para que
gestione todo el contacto necesario con las reas de negocio. Su contribucin se
centra en la toma de requisitos de las necesidades del cliente, la posterior negocia-
cin de la propuesta de servicio, la gestin del nuevo acuerdo de nivel de servicio y
el consenso con el cliente de la planificacin para la creacin del servicio realizada
por el proceso de creacin. En su funcin comercial, durante el proceso de crea-
cin, se encarga de mantener informado al cliente y estar presente en las reuniones
de seguimiento, acompaando al jefe de proyecto. En la entrega, gestiona la parti-
cipacin del cliente en las validaciones funcionales y en las reuniones para el cierre
del proyecto de creacin.
Gestin de nivel de servicio. Su objetivo es definir, acordar, registrar y gestionar

los niveles de servicio que TI deber cumplir y las relaciones con los clientes. Adi-
cionalmente mantiene el catlogo de servicios (vase el captulo 6).
Su misin incluye la definicin de los acuerdos de servicio de explotacin (SLA,
Service Level Agreement) con todas las partes internas de TI implicadas. El cumpli-
miento del SLA lo asegura mediante una cadena de valor formalizada de otros
acuerdos internos de nivel operativo (OLA, Operacional Level Agreement), o con-
tratos de soporte (UC, Underpinning Contract) con los suministradores externos.
Elaboracin de presupuestos y contabilidad de los servicios de TI. El objetivo

de este proceso es presupuestar y contabilizar los costes de la provisin del servicio.
En algunas organizaciones su actividad tambin incluye la facturacin de los servi-
cios a los clientes.
Su contribucin al presente proceso se centra en cmo se presupuestan los costes
de la creacin del servicio con el suficiente detalle para que permita la toma de deci-
siones y el control econmico efectivo. Tambin realiza todo el seguimiento econ-
mico durante el proceso de creacin del servicio.
Gestin de la capacidad. Su objetivo es asegurar que el proveedor del servicio TI

tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada,
actual y futura de las necesidades del negocio del cliente.
En esta cadena de fabricacin participa en la etapa de diseo del servicio para deter-
minar los requisitos de capacidad, rendimiento y prestaciones de los nuevos servi-
cios o de sus evoluciones. Establece el plan necesario para darles cobertura contem-
plando los recursos, los plazos, los costes y los umbrales de gestin necesarios.
Gestin de la disponibilidad y continuidad. Su objetivo es asegurar que los

compromisos de continuidad y disponibilidad acordados con los clientes pueden
cumplirse bajo todas las circunstancias, ya sean por sucesos domsticos (como la
rotura de una unidad de almacenamiento), o por sucesos extraordinarios (como
una catstrofe natural, terremotos, incendios, etc.)
Su misin es la de identificar, para los nuevos servicios, los requisitos de disponibi-
lidad y de continuidad de los mismos sobre la base de los planes de negocio, los
SLA y las evaluaciones del riesgo. Los requisitos deben incluir los derechos de
acceso y los tiempos de respuesta, as como la disponibilidad extremo a extremo
de los componentes del sistema.
Gestin de la seguridad. Su objetivo es contemplar las necesidades seguridad de

la informacin de manera efectiva para todas las actividades del servicio.
Su responsabilidad es la identificacin de los riesgos de seguridad del servicio en

base a la poltica de seguridad de la informacin de la compaa estableciendo las
medidas y controles necesarios para su eliminacin o mitigacin
Desarrollo de aplicaciones. Su objetivo es obtener, mediante construccin propia o

adecuacin de una solucin de mercado, la funcionalidad software adecuada que satis-
faga las necesidades demandadas por el cliente para cubrir sus funciones de negocio.
Su responsabilidad es la planificacin, desarrollo y aseguramiento de la funcionali-
dad demandada de la forma ms eficiente. Este rea de TI es una de las ms madu-
ras desde el punto de vista de normalizacin y utilizacin de metodologas
(PMBOK, PRINCE2, etc.), y buenas prcticas de mercado (SPICE, CMMI, etc.).
Gestin de la infraestructura TI. Su objetivo es implantar la infraestructura TI

necesaria y su gestin tcnica, que alojar a los servicios en explotacin.
En relacin a este proceso, su contribucin es la de proveer la infraestructura nece-
saria para alojar los nuevos servicios. Con mayor frecuencia es necesario realizar
proyectos complejos en los que intervienen diferentes tecnologas. Adems este
rea tiene un doble reto, ya que no slo tiene que cumplir en sus compromisos de
cobertura a los requisitos de los nuevos servicios, sino que tambin debe controlar
y evitar el impacto negativo que estos proyectos podran ocasionar en la prestacin
habitual de los servicios existentes.
Gestin de suministradores. Su objetivo es garantizar la provisin sin interrupciones

de servicios de calidad cumpliendo con los contratos de soporte establecidos (UC).
En la construccin de servicios, realiza o revisa los contratos de soporte con los
suministradores para que los servicios estn acordes con los SLA que se estn nego-
ciando con los clientes.
Gestin del cambio. Su objetivo es asegurar que todo cambio en TI se realiza

siguiendo las polticas de control y eficiencia definidas.
Su contribucin se centra en controlar que el plan de proyecto de creacin del
servicio est claramente definido y documentado, de forma que pueda ser valorado,
aprobado, implementado y revisado de una manera controlada.
Gestin de la entrega. Su objetivo es gestionar la implantacin, distribucin y el

seguimiento de uno o ms cambios a realizar en el entorno de produccin real.
Para este proceso, realiza la implantacin y despliegue del servicio nuevo o modifi-
cado en el entono de produccin de la forma ms fiable y eficiente posible. Mini-
miza el impacto negativo que pudiera tener en el servicio operativo habitual.
Operacin y soporte del servicio. Se encarga de todas las actividades necesarias

para que un servicio est operativo y disponible a los usuarios. La operacin es una
de las grandes olvidadas en el proceso de creacin de servicios, pero si no se dis-
pone de una operacin diaria acorde a las necesidades del cliente, este nuevo servi-
cio, aunque se haya construido por TI en plazo y forma, para el cliente es como si
no existiera.
Su contribucin es la de establecer los requisitos que permitan que el servicio se
pueda explotar adecuadamente. Adems, realiza la definicin y preparacin del
soporte, de la planificacin y de la operacin diaria de los servicios, garantizando el
cumplimiento de los requisitos de ejecucin establecidos en los SLA.
Hasta este punto se han podido observar los objetivos y mbito de actuacin de
este proceso de creacin y modificacin de servicios de TI. La figura 5.7 propor-
ciona un resumen de este proceso: una definicin, el objetivo formalizado en las
Normas ISO/IEC 20000 y las principales aportaciones del proceso.
Planificacin e implementacin Qu aporta:

de nuevos servicios o de Implementa un ciclo completo de
servicios modificados creacin y entrega de servicios,
desde las necesidades y acuerdos
con el cliente hasta su entrega y
puesta en funcionamiento operativo.
Definicin: Los servicios se crean de una forma
eficiente.
Proceso que se responsabiliza de la
fabricacin de servicios utilizando Los servicios se crean en los
plazos acordados, velando por las
el resto de procesos y funciones
necesidades del negocio en el
de la organizacin TI.
time-to-market.
Los servicios TI se disean para
Objetivo: satisfacer las necesidades reales
del cliente y cumpliendo con la
Asegurar que, tanto los servicios arquitectura y polticas de
nuevos, como las modicaciones la organizacin.
a los existentes, se pueden gestionar Los servicios se crean con la
y entregar con los costes y la participacin de todas las reas
calidad acordados. de la organizacin de TI: gobierno,
arquitectura, desarrollo y explotacin.
La organizacin TI y sus clientes
tienen unas expectativas claras
y formalizadas del servicio
solicitado a TI.
Figura 5.7. Introduccin general al proceso

Los principales factores clave en torno a los que se articula este proceso se resumen en:
Cumplimiento de los plazos, atendiendo a la agilidad y tiempo de respuesta
de la organizacin de TI ante necesidades del negocio.
Cumplimiento de la funcionalidad demandada.
Gestin eficiente de los costes.
Cumplimiento de las polticas establecidas en TI, tanto para la construccin
del servicio y de sus componentes, como para la articulacin de su puesta en
produccin.
Velar por la calidad necesaria demandada por el negocio.
Integracin de las soluciones en las arquitecturas TI existentes, tanto de:
datos, de aplicaciones, de componentes, tecnolgica de hardware-software, de
seguridad, etc.
En la figura 5.8 se resumen estos factores clave que estructuran y rigen la actividad
de este proceso en las relaciones intensas y constantes con los intervinientes en la
creacin o evolucin de un servicio TI.
Figura 5.8. Los factores clave del proceso

El conocimiento y correcto manejo de estos factores permitir a este proceso ges-

tionar adecuadamente la creacin de nuevos servicios, o las modificaciones a los
existentes, con los costes y calidad acordados con el cliente. Adems, el gestor de
este proceso debe conseguir estos objetivos dentro de un marco estratgico, tc-
nico y humano del proveedor de servicios TI.
El proceso de planificacin e implantacin de nuevos servicios o de servicios modi-
ficados utiliza las funciones del proceso de relaciones con el negocio, que gestiona
las necesidades del cliente, y articula al resto de la organizacin de TI, con el obje-
tivo de asegurar que, tanto los servicios nuevos, como las modificaciones a los exis-
tentes, se puedan gestionar y entregar con los costes, plazos y la calidad acordados.
En la figura 5.9 se puede muestran los componentes ms destacados que utiliza
este proceso para realizar su actividad. Se estructuran en dos ciclos, uno centrado
en acordar con el cliente y disear los servicios, y el otro, en construirlos y entre-
garlos.
COMPONENTES DEL PROCESO
DISEO CONSTRUCCIN TRANSICIN
Cliente
Servicio
Requisitos
del servicio Planificacin Informe
del proyecto de pruebas
Polticas, procesos desarrollo de software,
metodologa gestin de proyectos
Especificaciones
tcnicas
y arquitecturas
de servicio
OLA y UC
Acuerdos internos con reas,
procesos, funciones
Propuesta
y suminstradores
de servicio
Lista de
cambios
Solicitud
RFC planificados
SLA de cambio
(FSC)
Figura 5.9. Componentes principales de las etapas de diseo y transicin del proceso
A continuacin, se describen los componentes relacionados con este proceso:

Cliente. Es el representante de una organizacin que est autorizado a cerrar acuer-
dos en nombre del negocio sobre la adquisicin de servicios TI. Es decir, el cliente
es la persona fsica o representante de una entidad jurdica que paga por los servi-
cios TI. Por esta razn, los clientes representan a las reas de negocio de la empresa
y, por tanto, no coinciden con los usuarios finales, ya que estos ltimos son aque-
llos que utilizan los servicios TI.
Servicio TI. Se puede definir como un conjunto de funciones relacionadas, pro-

porcionadas por sistemas de TI que dan soporte a una o ms reas de negocio
(departamentos, agencias, etc.). Un servicio puede estar compuesto de diversas
piezas de software, de hardware y de elementos de comunicacin, pero el cliente y el
usuario final que lo utiliza, lo perciben como una funcionalidad autocontenida y
coherente.
Cultura de servicio. Implica que la satisfaccin del cliente es la prioridad principal

para todos los miembros de la organizacin TI que ofrece servicios. Se controla que
las actividades llevadas a cabo en la provisin de los servicios contribuyen a los
objetivos de negocio.
Gestin de la demanda. Es la actividad realizada por las relaciones con el negocio

para manejar la demanda de nuevos servicios, o de la evolucin de los existentes,
de las reas clientes de TI. La gestin de la demanda trata de acoplar la demanda
del da a da, con las previsiones (anuales) reflejadas en los presupuestos y desarro-
lladas en el porfolio de servicios.
Requisitos de nivel de servicio (SLR, Service Level Requirements). Es un docu-

mento que describe de forma detallada las necesidades del cliente. La descripcin
se realiza en el lenguaje del cliente para facilitar su entendimiento y validacin. Este
documento contiene la informacin de la funcionalidad a proveer por el servicio.
Se debe formalizar con el cliente, pues, sobre esta base, se desencadena todo el pro-
ceso de creacin.
Anlisis de viabilidad o caso de negocio. Estudio de los beneficios obtenidos del

proyecto frente a los costes, para asesorar a la direccin y a la gestin del cambio
sobre la idoneidad o no de abordar el proyecto. Normalmente slo se realiza para
grandes proyectos. Suele incluir el clculo del coste total de propiedad del nuevo
servicio (TCO, Total Cost of Ownership) y el clculo de retorno de la inversin
(ROI, Return Of Investment).
Especificaciones tcnicas del servicio. Documento que describe la relacin entre la

funcionalidad requerida por el cliente y la tecnologa empleada para implementarla.
Este documento describe los requerimientos tcnicos que son necesarios para la
provisin y entrega del servicio.
Acuerdo de nivel de servicio (SLA, Service Level Agreement). Documento que

recoge los compromisos acordados entre el cliente y el proveedor de servicios de
TI para la provisin del servicio requerido. En este documento se detallan por
escrito los objetivos de los servicios y las responsabilidades de ambas partes. El SLA
se describe en el apartado 6.1 de este libro.
Acuerdo de nivel operativo (OLA, Operational Level Agreement). Documento

que formaliza los compromisos entre departamentos internos de la organizacin
de TI relativos a su contribucin en la provisin, la entrega y la prestacin de un
servicio.
Este acuerdo interno establece responsabilidades, actividades, recursos, esfuerzo,
plazos y costes del mismo. Tambin contempla los compromisos internos para la
prestacin y operacin habitual del servicio. El OLA se describe en el apartado 6.1
de este libro.
Contrato de soporte (UC, Underpinning Contract). Documento contractual

entre la organizacin de TI y un suministrador de servicios externo. Este contrato
define los objetivos, alcance y caractersticas del servicio a prestar, as como los pla-
zos y costes asociados.
Al igual que el acuerdo de nivel operativo, el contrato de soporte interviene en la
confeccin del SLA y del plan de proyecto para la creacin del servicio. El UC se
describe en el apartado 6.1 de este libro.
Propuesta de servicio. La propuesta de servicio cubre la informacin necesaria

para establecer el acuerdo con el cliente (funcionalidad, plazos, costes y calidad)
relativo a la creacin y entrega del servicio.
Tambin se contempla, aunque no se muestra al cliente, la parte interna necesaria
de TI. Se detalla las unidades que van a intervenir en la creacin del servicio, los
plazos de elaboracin y entrega de sus actividades. Establece los mecanismos de
gestin y seguimiento necesarios para analizar la evolucin de los trabajos compro-
metidos con el cliente.
Planificacin del proyecto. Planificacin detallada de todo el proceso de cons-

truccin y transicin del servicio. Integra los compromisos de todas las reas,
internas (OLA) y externas (UC) intervinientes, sobre la aportacin que cada uno
va a realizar a la provisin e implantacin del servicio. Esta planificacin del pro-
yecto esta sujeta al control del cambio.
Solicitud de cambio (RFC, Request For Change). Formulario utilizado para pro-
poner un cambio en cualquier componente de la infraestructura de TI o en cual-
quier aspecto de un servicio de TI. En este caso contempla la creacin de un servi-
cio o la modificacin de uno existente.
En la RFC se reflejan la naturaleza, los detalles, la justificacin y la autorizacin del
cambio propuesto. La RFC va actualizndose a lo largo de la vida de la creacin
del servicio. La RFC se describe en el apartado 9.2 de este libro.
Lista de cambios planificados (FSC, Forward Schedule of Change). Es una pro-

gramacin unificada de todos los cambios en curso que recoge los detalles de los
cambios cuya implantacin haya sido aprobada, as como las fechas propuestas para
las aprobaciones intermedias que permitan la implantacin segura de los servicios.
En ITIL v2 se denomina FSC, mientras que en la v3 se ha cambiado el trmino por
lista de cambios o change schedule. La lista de cambios planificados se describe en
el apartado 9.2 de este libro.
Entradas, actividades y salidas del proceso

Cuando sobre el modelo de procesos ITIL se intenta representar el flujo que debe-
ra seguir la creacin de un nuevo servicio, se obtiene una autntica maraa de
lneas de flujo que entran y salen prcticamente de todos los procesos. Esto
se debe a que la creacin de servicios es un flujo que se superpone a todos los
otros procesos.
Este proceso acta como el director de la orquesta de TI, que hace que toda la
organizacin trabaje sincronizada en la creacin y evolucin de servicios. Se alinea
con las necesidades demandadas por cliente, velando por los elementos crticos de
su demanda: plazo, funcionalidad, costes y calidad. Para realizar esta labor, las rela-
ciones con los otros procesos y los diferentes departamentos de TI son intensas y
constantes.
En la figura 5.10 se muestra un esquema con las principales entradas, actividades
y salidas de este proceso.
Las entradas que desencadenan el inicio del proceso de creacin de servicios son la
solicitud del cliente (en una reunin o mediante una peticin expresa), la puesta en
Entradas Actividades Salidas
Desencadenantes 3 Gestin de la demanda. Salidas principales:

del proceso: Necesidades. Servicio operativo.
Solicitud del cliente. 3 Requisitos del servicio (SLR).
Documentacin del
Porfolio de proyectos. 3 Anlisis de viabilidad servicio: de usuario,
(TCO y ROI). tcnica y para el SD.
Mandato de la direccin
3 Especificaciones tcnicas del
de TI. Servicio cargado
servicio.
en herramientas de
Entradas de soporte: 3 Propuesta del servicio y
autorresolucin.
del SLA.
Catlogo de servicios. Contrataciones
3 Plan de proyecto para la
Polticas. creacin del servicio. necesarias.
Metodologas proyectos. 3 Revisin y formalizacin Salidas secundarias:
Arquitecturas TI. de acuerdos internos y
SLA cerrado.
contratos (OLA y UC).
SLA existentes.
3 Solicitud de cambio (RFC) y OLA y UC actualizados.
OLA y UC existentes. aprobacin de la creacin Catlogo de servicios
CMDB. del servicio. actualizado.
3 Seguimiento del proceso de FSC actualizado.
construccin.
DSL actualizada.
3 Integracin y pruebas del
servicio construido. CMDB actualizada.
3 Aprobacin de la implantacin. Informes de errores en
3 Implantacin y despliegue. las pruebas a desarrollo.
3 Revisin posimplantacin. Propuesta de actividades

para la mejora del
3 Comunicacin de resultados y
cierre. servicio.
3 Supervisin funcionamiento del

proceso.
3 Informes, anlisis y acciones de
gestin del cambio.
Mejora del proceso.
Fuente: e.p. y Telefnica.
Figura 5.10. Entradas, actividades y salidas del proceso
marcha de un proyecto definido en el porfolio o cartera de proyectos de TI, o bien

por actuacin expresa de la direccin de TI.
Hay otras entradas que se utilizan en el proceso de apoyo a la realizacin de una
actividad. Las principales entradas de soporte son: el catlogo de servicios, para
determinar si la necesidad del cliente est cubierta por el catlogo; las polticas,
metodologas de gestin de proyectos y las arquitecturas TI con el fin de que la cre-
acin del nuevo servicio sea acorde con todo lo dictado en la organizacin; los
SLA, OLA y UC existentes; y la CMDB para proveer todo tipo de informacin
sobre TI y sus elementos de configuracin.
Las actividades principales que realiza este proceso son:
Gestin de la demanda, realizada por relaciones con el negocio (cliente) para
profundizar en sus necesidades, determinacin de si stas estn en el catlogo
de servicios, y su encaje en las previsiones presupuestarias y en el porfolio de
servicios.
Establecimiento de los requisitos del servicio por parte del cliente (SLR).
Realizacin, si procede, del anlisis de viabilidad (TCO y ROI).
Elaboracin de las especificaciones tcnicas del servicio, que incluye su arqui-
tectura y el diseo funcional y tcnico.
Elaboracin de la propuesta del servicio y del SLA.
Realizacin del plan de proyecto para la creacin del servicio.
Revisin y formalizacin de acuerdos internos y contratos (OLA y UC).
Confeccin de la solicitud de cambio (RFC) y aprobacin de la creacin del
servicio. Dar la orden del inicio de la construccin del servicio.
Seguimiento del proceso de construccin.
Realizacin de la integracin y pruebas del servicio construido, en el entorno
de pruebas-integracin.
Aprobacin de la implantacin del servicio por gestin del cambio.
Realizacin de la implantacin y despliegue del servicio.
Revisin post-implantacin.
Comunicacin de los resultados a todas las partes interesadas.
Cierre de la implantacin y de la solicitud de servicio.
Las salidas principales del proceso son: el servicio operativo y listo para que pro-
vea las funcionalidades al negocio especificadas; todo tipo de documentacin aso-
ciada necesaria (de usuario, para las reas tcnicas, de soporte para la atencin de
incidentes y peticiones del usuario, etc.); el servicio cargado en las herramientas
de autorresolucin al usuario; y las contrataciones necesarias realizadas (para la
construccin, para el soporte tcnico de los fabricantes, para el mantenimiento de

licencias).
Las salidas secundarias del proceso son: el SLA de explotacin del servicio, los
OLA y UC revisados, el catlogo de servicios actualizado con el nuevo servicio o
nuevas funcionalidades, la lista de cambios planificados actualizada (FSC), la
biblioteca de software definitivo (DSL) y la base de datos de gestin de la configu-
racin (CMDB) actualizadas con el nuevo servicio, los informes en los errores en
las pruebas y la propuesta de actividades para la mejora del servicio y del proceso
que se incorporar en el plan de mejora general.
En la figura 5.11 se muestra una secuencia de actividades del proceso, con foco en
la relacin con otros procesos de gestin del servicio de TI. Estas actividades se
deberan integrar tambin en la metodologa de desarrollo de proyectos de la orga-
nizacin de TI.
Planificacin e implementacin de servicios nuevos o de servicios modificados
Relaciones Actividades especficas Gestin Gestin de

con el negocio del proceso del cambio la entrega
Gestin demanda.
Necesidades frente a
catlogo de servicios Anlisis de viabilidad
Requisitos de servicio Especificaciones tcnicas Aprobacin preliminar
del cliente (SLR) del servicio (SS)
Negociacin propuesta Propuesta del servicio y SLA
servicio y SLA
Acuerdo con el cliente Plan de proyecto del servicio
Revisin y formalizacin de Aprobacin del RFC de
acuerdos y contratos (OLA, UC) creacin/evolucin
del servicio
Confeccin solicitud Aprobacin planificacin
de cambio (RFC) Inclusin en FSC
Orden de construccin Gestin del cambio
Construccin del servicio. Pruebas del servicio (por otros procesos y departamentos TI)
Aprobacin implantacin Integracin y pruebas

por cambios
Implantacin y despliegue
Comprobacin
posimplantacin Revisin posimplantacin
Comunicacin
entrega del servicio. Comunicacin
CIERRE SOLICITUD resultados implantacin. SERVICIO OPERATIVO
SERVICIO CIERRE IMPLANTACIN
Fuente: Telefnica.
Figura 5.11. Secuencia de actividades principales del proceso con foco

en la integracin con otros procesos de gestin del servicio
A continuacin, se detallan las principales actividades para el ciclo de creacin de

servicios.
El proceso se inicia con las relaciones con el negocio

La gestin de la relacin con el negocio se encarga de todo lo relativo a la relacin
entre el proveedor de servicio TI y el cliente. Se podra decir que lleva las relaciones
comerciales de TI para la fbrica.
En ITIL v3, en el mbito de la estrategia del servicio, se establece una completa
serie de actividades en torno a los procesos de la gestin de la estrategia, la gestin
financiera, la gestin de la demanda y la gestin del porfolio de servicios (no
cubiertos por ISO/IEC 20000). El proceso de creacin de servicios se desencadena
por una solicitud del cliente, por la ejecucin del porfolio de servicios o por man-
dato de la direccin de TI, pero siempre dentro del contexto definido en la estrate-
gia y manteniendo la implicacin directa del cliente.
El ciclo de la creacin debe comenzar con el proceso de gestin de las relaciones
con el negocio, que se encarga de dilogo con el cliente. Para intentar dar cober-
tura a sus necesidades utilizar la oferta estndar de servicios de TI, basndose en el
catlogo de servicios existente. Si la necesidad del cliente se satisface con un servi-
cio del catlogo, se ejecuta una solicitud de servicio, que se proveer por el medio
de provisin predefinido. Si no se pueden resolver con un servicio preexistente, se
desencadenara la creacin de uno nuevo o a la evolucin de uno existente, dando
paso al resto del proceso.
En todo caso se debe encajar la necesidad del cliente con las previsiones presupues-
tarias y con las previsiones de proyectos o servicios a realizar, definidas normal-
mente el porfolio o cartera de proyectos o servicios.
Requisitos de servicio del cliente (SLR, Service Level

Requirements)
Este gestor de relaciones con el negocio debe escuchar al cliente, analizar sus
necesidades y formalizarlas en un documento de requisitos de servicio del cliente
(SLR) y si estas no se ajustan a la oferta estndar de servicios, se analizara la
posibilidad de poder proveerlas (para un mayor detalle vase el apartado 7.2).
En esta actividad es necesario aplicar las disciplinas de formalizacin de los requi-
sitos de los clientes (para lo que se recomienda seguir lo especificado en CMMI
al respecto).
Anlisis de viabilidad (TCO y ROI) o caso de negocio

Con frecuencia, en las organizaciones TI se toman decisiones de inversin impor-
tantes sin un anlisis adecuado de las mismas. Aunque por otra parte, hay que evi-
tar la parlisis de la organizacin por el anlisis.
En el caso de los proyectos o servicios que requieran altas inversiones, es conve-
niente realizar un estudio de los costes totales del nuevo servicio, en todo su ciclo de
vida, para contrastarlo con los beneficios que se aportar al negocio. En el anlisis
se suele calcular el coste total de propiedad del nuevo servicio (TCO) y el clculo del
perodo de tiempo necesario para el retorno de la inversin (ROI).
Con estos datos, se toma la decisin de abordar o no el proyecto, o reorientarlo
hacia otro tipo de solucin ms adecuada. Esta decisin se recomienda que la tome
el comit de cambios, o si no, la propia direccin de TI.
Especificaciones tcnicas del servicio

En el caso que sea necesario construir un nuevo servicio o evolucionar uno exis-
tente este proceso toma el control e inicia su primera actividad propiamente dicha:
convertir los requisitos del cliente en especificaciones tcnicas internas. Su objetivo
es detallar las especificaciones tcnicas del servicio partiendo del documento de
requisitos del cliente (SLR).
Con la colaboracin y trabajo conjunto de gestin de nivel de servicio y el resto de
procesos y funciones implicadas, se elabora un documento que describe la relacin
entre la funcionalidad requerida por el cliente y la tecnologa empleada para
implantarla. Este documento describe los requisitos tcnicos que son necesarios
para la provisin y entrega del servicio, contemplando la siguiente informacin:
Descripcin tcnica detallada e inequvoca de los servicios demandados por
el cliente y sus componentes TI.
Especificacin del modo en el que el servicio va a ser aprovisionado e implan-
tado por TI (utilizacin de arquitecturas ya definidas, plataformas de pro-
duccin existentes, etc.).
Especificacin de los requisitos de control de calidad necesarios.
Estas especificaciones describen con detalle lo que el cliente desea y cual es el impacto
que tiene en la organizacin TI, su provisin, implantacin y operacin. Este docu-
mento de uso interno no necesita ser firmado por el cliente, pero si est sujeto al con-
trol documental establecido por el sistema de gestin del servicio de TI (SGSTI).
El contenido recomendado del documento de especificaciones tcnicas del servicio

debera contener, como mnimo, los conceptos indicados en la figura 5.12.
Especificaciones tcnicas del servicio
1. Introduccin
Objetivo y alcance.
Nombre del cliente/SLR de referencia.
2. Descripcin del servicio
Nombre del servicio, objetivos y alcance.
Requerimientos de alto nivel:
Funcionalidad.
Horario de servicio y soporte.
Disponibilidad, fiabilidad y continuidad.
Rendimiento y volmenes.
Interfaces, etc.
3. Estructura y propuesta de nivel de servicio
4. Planificacin
Fecha requerida de disponibilidad del servicio.
Duracin del servicio.
5. Relaciones con otros elementos de configuracin
Servicios, componentes hardware y software.
6. Unidades involucradas la creacin del servicio
Nombre del departamento, responsable, datos
de contacto y requerimientos tcnicos, humanos
y econmicos asociados.
7. Servicios impactados
Nombre del servicio y descripcin del impacto.
Figura 5.12. Contenido del documento de especificaciones tcnicas del servicio
Propuesta de servicio y acuerdo de nivel de servicio

(SLA, Service Level Agreement)
Una vez realizadas las especificaciones de servicio, que describen la solucin tcnica a
los requisitos del cliente y que proporciona las definiciones tcnicas necesarias para
proveer e implantar el servicio, se est en disposicin de confeccionar la propuesta de
servicio y, realizado por el proceso de gestin de nivel de servicio, el acuerdo de nivel
de servicio (SLA) preliminar. Esta propuesta se presentar al cliente como respuesta a

su demanda para su revisin negociacin y acuerdo. Al respecto, ISO/IEC 20000-1
establece:
UNE-ISO/IEC 20000-1
En las propuestas de nuevos servicios o modificaciones en los existentes, se deben

considerar los costes y el impacto a nivel organizativo, tcnico y comercial que
pudiera derivar de su entrega y gestin.
En esta etapa TI formaliza dos tipos de acuerdo con el cliente:

La propuesta de servicio, que es el acuerdo de creacin del servicio (aplica-
cin, infraestructura, etc.), a veces conocido como SLA de desarrollo o
SLA de construccin.
El SLA del servicio, centrado exclusivamente en las condiciones de presta-
cin operativa del servicio que recibir el cliente, en ocasiones denominado
slo como SLA o como SLA de explotacin (vase el apartado 6.1).
La propuesta de servicio cubre el acuerdo con el cliente (en funcionalidad, plazos,

costes y calidad), para la creacin y entrega de los servicios. La responsabilidad de
su confeccin directa es del proceso de planificacin e implementacin de servicios
nuevos o modificados (es el primer documento que genera de forma especfica este
proceso, pues los otros son generados por los procesos o reas que coordina).
En la propuesta de servicio tambin se contempla, aunque no se muestre al cliente,
la parte interna de TI asociada. Se detallan: quin interviene en su realizacin, los
plazos de elaboracin y entrega de las actividades, y los mecanismos de gestin y
seguimiento necesarios para analizar la evolucin de los trabajos comprometidos
con el cliente. Para poder realizar esta ltima parte es necesario acordar y formali-
zar, con todos los intervinientes de TI, su participacin, sus necesidades en cuanto
a los plazos, los recursos y los costes.
Tambin se debe contemplar en la propuesta los indicadores y mtricas de gestin,
as como los mecanismos necesarios para la revisin del servicio y para el control,
el seguimiento y la evaluacin interna del cumplimiento de los niveles de servicio
acordados. En este punto, es importante resaltar que antes de proponer estos meca-
nismos es necesario verificar previamente, con las reas y procesos involucrados,
que la organizacin TI cuenta con los medios de monitorizacin necesarios para
obtener las mtricas acordadas ya que, a menudo, se olvida este aspecto y luego no
es posible conocer si se estn cumpliendo los SLA firmados. En la figura 5.13 se
muestra el contenido habitual de una propuesta de servicio.
Propuesta de servicio para negociar

con el cliente
1. Objetivos y alcance.
2. Descripcin del servicio:
Funcionalidad.
Seguridad y continuidad.
3. Estimacin de recursos necesarios del cliente.
4. Estimacin de plazos de creacin y entrega.
5. Estimacin de costes asociados.
6. Impacto y modificaciones a contratos y acuerdos
existentes.
7. Propuesta SLA:
Compromisos de prestacin regular del servicio en
trminos medibles.
Indicadores y mtricas de gestin del
cumplimiento.
Mecanismos de control y seguimiento de la
evolucin de los niveles de servicio acordados.
8. Criterios de aceptacin del servicio.
9. Participantes y sus responsabilidades en las
actividades de creacin, implantacin, operacin
y evolucin de los nuevos servicios. Contemplar
las actividades a llevar a cabo por los clientes y
el proveedor de servicio TI.
Figura 5.13. Propuesta servicio a negociar con el cliente
El SLA del servicio describe las condiciones de la prestacin regular del mismo
durante el tiempo que dure el acuerdo. Contiene los compromisos de TI y del cliente
para prestacin del servicio y ser la referencia que se utilizar por las dos partes para
medir la prestacin del servicio. En el mbito de este proceso se formaliza el SLA,
pero su realizacin corresponde al proceso de gestin de nivel de servicio (SLM),
trabajando para este proceso. Este punto se trata detalladamente en el apartado 6.1.
La propuesta de servicio describe en trminos de negocio qu se entregar al
cliente y cundo; y el SLA contiene los compromisos de ambas partes para la
prestacin habitual del servicio. Estos documentos constituyen el medio por el que
las dos partes, cliente y proveedor de servicios TI, pueden medir los compromisos
tanto del cumplimiento de la creacin del servicio como los de su prestacin regu-
lar durante su vida til.
Negociacin de la propuesta de servicio, de la

planificacin y del SLA
La propuesta de servicio, que incluye una planificacin preliminar del proyecto de
construccin, y el SLA de explotacin, se revisan y negocian con el cliente para
ajustar los objetivos, calidades, plazos y costes, entre lo demandado por el cliente y
lo que la organizacin de TI razonablemente puede aportar. Una vez llegado a un
acuerdo, se firman estos dos documentos por ambas partes. Esta actividad la rea-
liza el proceso de relaciones con el negocio bajo el paraguas de este proceso.
Destacar la recomendacin realizada en ITIL v3 en el libro Transicin del Servicio
relativa a que el SLA (de explotacin) se cierre definitivamente despus de una fase
piloto o al principio de la vida del servicio (early life support) antes de que la transi-
cin se haya terminado.
Plan de proyecto para la creacin del servicio

Una vez formalizada la propuesta de servicio, se realiza el plan de proyecto, desde
la perspectiva pura de TI, para la creacin del servicio. En esta actividad se realiza
el anlisis detallado de las tareas a realizar por cada uno de los intervinientes, con-
feccionando una planificacin detallada de creacin del servicio.
UNE-ISO/IEC 20000-1
La planificacin e implementacin deben incluir los fondos y recursos adecuados

para llevar a cabo los cambios necesarios para la provisin y la gestin del servicio.
Los planes deben incluir:
a) los roles y responsabilidades para implementar, operar y mantener los nuevos
servicios o modificaciones en los existentes, incluyendo las actividades a llevar
a cabo por clientes y suministradores;
b) los cambios en el marco de trabajo existente de gestin del servicio y en los
propios servicios;
c) la comunicacin a las partes afectadas;
d) los nuevos contratos y acuerdos, o modificaciones a los contratos y acuerdos
existentes, para estar alineados con las necesidades del negocio;
e) los requisitos de mano de obra y contratacin;

f) los requisitos de perfiles y formacin, por ejemplo usuarios, soporte tcnico;
g) los procesos, medidas, mtodos y herramientas que han de usarse con rela-
cin a los nuevos servicios o modificaciones en los existentes, por ejemplo ges-
tin de la capacidad, gestin financiera;
h) los presupuestos y plazos de tiempo;
i) los criterios de aceptacin del servicio; y
j) los resultados esperados al operar con el nuevo servicio, expresados en trminos
medibles.
La planificacin se debe confeccionar en trminos de objetivos, alcance, funcionali-

dad, estimacin de plazos para que est disponible, esfuerzo y costes asociados.
Este documento integra toda la informacin necesaria para los proveedores inter-
nos y externos sobre la aportacin que cada uno debe realizar a la provisin e
implantacin del servicio. Tambin define los parmetros necesarios para los proce-
sos de gestin de servicio, la administracin y la operacin.
Para realizar la planificacin del proyecto y la gestin de todas sus etapas se utilizan
metodologas como PMBOK o PRINCE2.
Durante la elaboracin del plan de proyecto es necesario revisar y formalizar los
acuerdos internos y los externos a la organizacin de TI, que involucran a todas las
reas y departamentos del proveedor de servicios.
Se puede definir el plan de proyecto de servicio como el documento donde el pro-
veedor de TI especifica el proceso de fabricacin con el que se elaborar y entre-
gar un servicio. Es decir, describe el plan de trabajo que se habr de realizar por
cada rea y proceso TI para la construccin, pruebas, despliegue y puesta en mar-
cha del servicio. Este documento establece, por tanto, las fases, actividades, hitos,
planificacin, responsabilidades, plazos de disponibilidad, costes e indicadores aso-
ciados al servicio, los cambios en la Infraestructura TI necesarios, as como las
caractersticas de los acuerdos que habr que establecer, tanto en el mbito interno
de la Organizacin TI como de los suministradores externos.
Este plan de proyecto, al igual que el resto de documentos, estar sometido al con-
trol de la gestin documental del sistema de gestin de servicios de TI (SGSTI).
El contenido base de este documento se presenta en la figura 5.14.
La participacin de cada rea o suministrador de TI en el plan de proyecto se debe-
ra formalizar mediante acuerdos de nivel operativo (OLA, Operational Level
Agreement) cuando se trata de reas internas a la organizacin de TI y para el caso
Plan de proyecto de creacin del servicio
1. Introduccin:
Objetivo y alcance.
Clientes, SLR y SLA de referencia.
Fecha de inicio servicio.
2. Procesos y departamentos involucrados:
Nombre del departamento.
Persona y datos de contacto.
Participacin requerida.
3. Descripcin de los niveles de soporte necesarios:
Niveles de soporte requeridos de los procesos
(incidentes, disponibilidad, capacidad, gestin
del cambio, gestin de presupuestos y costes de
servicios TI, etc.).
Niveles de soporte requeridos a los
suministradores externos y a otros departamentos
de TI.
4. Planificaciones de trabajo:
Objetivos y alcance.
Planificacin de trabajo de cada departamento,
y/o proceso, de TI (desarrollo de aplicaciones,
operacin de servicio, etc.).
Descripcin de actividades.
Cambios necesarios (descripcin y justificacin).
Recursos necesarios.
Estimacin de esfuerzo y costes asociados.
Figura 5.14. Contenido tipo del plan de proyecto de creacin del servicio
de las unidades externas a TI se realiza mediante los denominados contratos de

soporte (UC, Underpinning Contract).
Una vez confeccionada la propuesta de servicio, el SLA y el plan de proyecto del
servicio, la gestin de relaciones con el negocio tratar con el cliente los trminos
finales para la provisin e implantacin del servicio, dado que posiblemente el
cliente tenga que participar a lo largo de la creacin del servicio (validaciones, prue-
bas, etc.).
Revisar y formalizar acuerdos internos (OLA)

El objetivo de esta actividad es formalizar los acuerdos de nivel operativo (vase el
apartado 6.1). Entre las distintas reas y departamentos internos del proveedor de
TI involucrados en el soporte y operacin del servicio una vez construido, y cuyas
caractersticas fueron acordadas e incluidas previamente en el SLA (de explota-
cin).
Esta formalizacin, que realiza el proceso de gestin de nivel de servicio, se plasma
en un documento en el que se recogen las caractersticas y condiciones del servicio
que se va a proveer por cada rea.
Revisar y formalizar contratos externos (UC)

Esta actividad tiene como objetivo formalizar los contratos de servicio (UC) con
los diferentes suministradores externos a la organizacin de TI.
Su finalidad es la contratacin de servicios a suministradores externos. Las caracte-
rsticas que de deben cumplir por los contratos de soporte se derivan del SLA, del
plan de proyecto del servicio y de los contratos ya existentes con los suministrado-
res. Estos acuerdos se formalizan en un contrato que recoge las caractersticas y
condiciones del servicio a prestar por cada suministrador.
Para la realizacin de esta actividad se debern mantener reuniones con los distin-
tos suministradores con el fin de aclarar los requisitos, as como negociar las condi-
ciones para la realizacin de las actividades asociadas. Esta actividad la lleva a cabo
el proceso de gestin de suministradores con los requisitos establecidos por la ges-
tin de nivel de servicio (vase el apartado 6.1).
Confeccin de la solicitud de cambio (RFC) y aprobacin

de creacin del servicio
En este punto, el proceso de planificacin e implementacin de servicios confec-
ciona y tramita la solicitud de cambio (RFC, Request For Change) con la documen-
tacin correspondiente para su revisin y aprobacin formal por el proceso de ges-
tin del cambio (para profundizar en estos conceptos consulte el apartado 9.2),
que se realizar mediante el comit de cambios (CAB, Change Advisory Board), que
representa al proveedor de servicios de TI, y en el que tienen presencia todas las
partes implicadas. Cualquier cambio que afecte o pueda afectar a este proyecto ser
analizado por este proceso para determinar si supone un impacto potencial en los
compromisos adquiridos con los clientes.
UNE-ISO/IEC 20000-1
La implementacin de nuevos servicios o modificaciones en los existentes, inclu-

yendo la eliminacin de un servicio, debe ser planificada y aprobada a travs de un
proceso formal de gestin del cambio.
UNE-ISO/IEC 20000-2
Todas las modificaciones al servicio se c) la formacin al usuario;

deberan reflejar en los registros de ges-
d) las comunicaciones sobre los cam-
tin del cambio:
bios;
Esto incluye a los planes para:
e) los cambios en la naturaleza de
a) la contratacin y formacin del la tecnologa a la que se da
personal; soporte;
b) la reubicacin; f) el cierre formal de los servicios.
A partir de este momento la peticin de cambio aprobada se integra en la lista de cam-

bios planificados (FSC, Forward Schedule of Change). Este listado es una pieza funda-
mental en la actividad del proceso de gestin del cambio, ya que en l se controla toda
la actividad relevante de cambios en TI. Adems, se genera un informe de disponibili-
dad prevista del servicio (PSA, Projected Service Availability). Las versiones actualizadas
de estos documentos deben estar a disposicin de cualquier miembro de la organiza-
cin, por lo que, generalmente, se almacenan en la intranet de la compaa.
Construccin del servicio o de las modificaciones

Una vez aprobada la solicitud de cambio e introducido el proyecto en el listado
de cambios planificados (FSC), a travs de la gestin del cambio, se da la orden de
comienzo de la construccin del servicio. Se inicia la ejecucin de la planificacin
del plan de proyecto por cada una de las reas TI involucradas (desarrollo, infraes-
tructuras, proveedores externos, etc.) bajo la supervisin del proceso de planifica-
cin e implantacin de servicios nuevos o modificados.
Tambin, durante esta actividad, cualquier cambio al servicio y su plan de proyecto,

ya sea a peticin del cliente o por necesidades internas de TI, deber ser sometido
al anlisis y aprobacin a travs del proceso de gestin del cambio.
En el transcurso de la construccin del servicio o de sus modificaciones, este pro-
ceso realizar el seguimiento y control de la etapa de construccin. As, tambin se
responsabiliza del cumplimiento de plazos, calidad y costes, en esta etapa de cons-
truccin. Para realizarlo no se necesita duplicar funciones y se utilizarn las atribu-
ciones del equipo de gestin de proyectos o de desarrollo de la organizacin.
Como ya se ha mencionado, en la construccin se debera aplicar otro tipo de nor-
mativa o marcos de mejores prcticas (por ejemplo, SPICE, CMMI, PMBOK o
PRINCE2), que se integraran con el proceso actual.
Integracin y pruebas del servicio construido

Finalizada la etapa de construccin, se hace la recepcin del desarrollo realizado,
verificando nuevamente el cumplimiento de todo lo especificado y se solicita apro-
bacin al proceso de gestin del cambio para proceder a la implantacin en los
entornos de integracin y pruebas (previos al entorno productivo real).
En esta actividad es el proceso de gestin de la entrega quin es el responsable del
control y realizacin de las actividades (vase el captulo 10). Como en otros casos,
se produce una doble responsabilidad y control, una derivada del proceso de crea-
cin de servicios, con foco en el ciclo completo de creacin, y otra por parte de la
gestin de la entrega, cuya misin es realizar las actividades para la puesta en pro-
duccin de los cambios.
El resultado de esta etapa es un informe de pruebas del servicio, con los defectos
encontrados y su resolucin.
En ITIL v3 hay dedicado un libro de buenas prcticas a la Transicin del Servicio,
que arranca una vez finalizado el diseo del servicio (en este caso se considera el
servicio ya construido) y finaliza con el paso a produccin. Este libro contiene acti-
vidades y directrices que se estructuran en cinco procesos: soporte y planificacin
de la transicin, gestin del cambio, activos y configuracin del servicio, gestin de
la versin y del despliegue, validacin y pruebas del servicio, y evaluacin y la ges-
tin del conocimiento. Mientras que en ISO/IEC 20000 y en ITIL v2 todas las
actividades equivalentes a esta transicin de ITIL v3 se agrupan en tres procesos:
gestin del cambio, gestin de la entrega y gestin de la configuracin.
Aprobacin de la implantacin del servicio
UNE-ISO/IEC 20000-1
Los nuevos servicios, o las modificaciones en los existentes, deben ser aceptados por el
proveedor del servicio antes de ser implementados en el entorno de produccin real.
Una vez finalizado el desarrollo y las pruebas del servicio, el proceso de gestin del
cambio toma el control para comprobar si se han cubierto todos los compromisos
reflejados en la RFC y someter a la aprobacin del comit de cambios la implanta-
cin del servicio en el entorno de produccin real.
La implantacin del servicio en el entorno de produccin real, la realiza el proceso
de gestin de la entrega (vase el apartado 10.1) bajo la supervisin de gestin del
cambio (vase el apartado 9.2).
Realizacin de la implantacin y despliegue del servicio

Aprobada la implantacin del servicio por la gestin del cambio, se procede a la
implantacin en el entorno productivo real y despliegue del servicio. El despliegue
debe incluir tambin la formacin a los usuarios, al service desk y al resto de los tc-
nicos de soporte. En esta actividad el proceso de gestin de la entrega es el respon-
sable del control y realizacin de estas actividades (vase el captulo 10).
Comprobacin resultados: revisin postimplantacin
UNE-ISO/IEC 20000-1
Tras la implementacin, el proveedor del servicio debe informar de los resultados

alcanzados por el servicio nuevo, o por el servicio modificado, comparndolos con los
previstos. Se debe realizar una revisin posterior a la implementacin, que compare
los resultados reales con los planificados a travs del proceso de gestin del cambio.
En la actividad de implantacin la ltima actividad del proceso de gestin del cam-

bio es realizar una revisin postimplantacin (PIR, Post Implementation Review)
para analizar los resultados reales obtenidos con la implantacin realizada, compa-
rndolos con los resultados esperados. En esta actividad el proceso de gestin de la
entrega es quin se responsabiliza del control y realizacin de estas tareas (vase el

captulo 10).
Esta revisin se debe realizar como mnimo en todos los cambios importantes de
TI y, por tanto, en la implantacin de servicios nuevos o modificados. Si en esta
revisin se concluye que el cambio no tiene el efecto deseado, se decidir si se da
marcha atrs para restaurar el estado inicial. Asimismo se revisarn y documenta-
rn las causas para evitar que vuelva a ocurrir otra vez.
El responsable de la planificacin de nuevos servicios o de servicios modificados
debe tener una participacin activa en la revisin postimplantacin, ya que es el res-
ponsable final del resultado obtenido frente a relaciones con el negocio.
Tras esta actividad se cierra formalmente la RFC, comunicndolo al comit de cam-
bios, al responsable de gestin de niveles de servicio y al promotor de la RFC,
quien realizar las comprobaciones necesarias junto con el responsable de relacio-
nes con el negocio.
En este punto, y si las comprobaciones realizadas han resultado satisfactorias, el res-
ponsable de las relaciones con el negocio realizar las comunicaciones formales de
entrega del servicio al cliente.
Comunicacin de los resultados a todas las partes

interesadas
Gestionado por el proceso de gestin de la entrega, se comunican los resultados y
la disponibilidad del servicio a las partes implicadas. El service desk centralizar la
comunicacin a los usuarios, mientras que la gestin de relaciones con el negocio
lo har con los clientes.
Cierre de la implantacin y de la solicitud de servicio

Se procede al cierre de la implantacin (cierre que ejecuta el proceso de gestin de
la entrega) y al cierre de la solicitud de servicio del cliente realizada por el proceso
de relaciones con el negocio.
Mtricas del proceso

Es necesario elaborar informacin que permita evaluar si este proceso est cum-
pliendo con los objetivos previstos. Lo habitual es elaborar un conjunto de mtricas
que permitan conocer los aspectos ms importantes para cada organizacin. Muchas
de las mtricas de este proceso son similares a la de los procesos que utiliza, por lo
que no se repiten aqu. nicamente se enumeran aqullas que tienen un carcter
ms global al proceso:
Nmero de proyectos realizados.
El Time to market de los proyectos o plazo medio desde el primer contacto
con el usuario hasta que el servicio se ha entregado y se est utilizando.
Cumplimiento de los plazos acordados o porcentaje de cumplimiento de los
plazos previstos en cada proyecto.
Alineacin con el cliente, medida como el nmero de inconformidades (o
modificaciones) del cliente por proyecto y del usuario final con los nuevos
servicios.
Calidad tcnica, medida como el nmero de defectos encontrados en las
pruebas del servicio.
Nmero de incidentes causados por los nuevos servicios o las modificaciones.
Cumplimiento de los costes acordados en los proyectos.
Volumen medio de recursos utilizados. Nmero medio de horas/hombre
dedicados por proyecto.
Calidad de las previsiones, medida como el nmero o coste de los nuevos
servicios no previstos en los planes anuales (porfolio de servicios, presu-
puestos, etc.).
Figura 5.15. Mtricas relevantes para el proceso de creacin de servicios

Siguiendo los principios de COBIT, las mtricas se estructuran en tres capas: una
primera capa con las mtricas que aportan una visin al negocio de cmo est TI,
denominadas KGI de TI (KGI, Key Global Indicador); una segunda capa destinada
a la visin que el director de sistemas de informacin debera tener sobre el pro-
ceso, denominadas KGI del proceso. Por ltimo, para mostrar los detalles internos
del proceso al responsable del proceso estara la tercera capa, los KPI del proceso
(KPI, Key Performance Indicador).
En el grfico de la figura 5.15 se muestra un resumen de los indicadores ms rele-
vantes de este proceso.
Roles participantes en el proceso

Los roles involucrados en el proceso se estructuran en: los roles propios del pro-
ceso y los roles ajenos al proceso.
Los roles propios del proceso son:
El gestor de la creacin de servicios (gestor del proceso o process mana-
ger), que es el responsable del da a da de la actividad del proceso, en este
caso supervisa cada proyecto desde su concepcin hasta su entrega defini-
tiva, supervisa a los responsables de proyectos en el cumplimiento de lo
establecido en el proceso, detecta y propone mejoras en su proceso y en
otras reas de TI relacionadas, etc.
Los administradores o personal de soporte al proceso, es el personal que
ayuda al gestor en el control de toda la actividad.
Los responsables o jefes de proyecto, que se responsabilizan de un proyecto
desde su inicio hasta su fin.
Los especialistas en tecnologas, aplicaciones y formacin, que realizan el
diseo tcnico y funcional, realizan las pruebas tcnicas y funcionales, reali-
zan la implantacin y despliegue y realizan la formacin a los usuarios sobre
los nuevos servicios.
Los roles tpicos del desarrollo de aplicaciones (analistas funcionales, progra-
madores, etc.).
Los roles ajenos relevantes en este proceso son:

El responsable de relaciones con el negocio, que es la cara visible de la orga-
nizacin de TI con el cliente, tiene como cometido la gestin de las relacio-
nes del cliente con el proveedor de servicios TI.
El responsable de la gestin del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
El propietario del modelo SGSTI, que acta como propietario del proceso
(process owner), define el proceso y se encarga de la mejora continua del
mismo. Todo ello de una forma integrada con el modelo de gestin de TI
incorporado en el SGSTI.
El responsable de la gestin del cambio, ya que debe autorizar el inicio de las
pruebas e integracin, la implantacin en produccin y el cierre de la entrega.
Los roles de mayor relevancia que participan en el proceso se representan en el gr-

fico de la figura 5.16.
Roles del proceso
Responsable de la
gestin del servicio
SGSTI
Gestor de la
creacin de servicios
Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Especialistas en el Especialistas Especialistas

Gestor del cambio
diseo del servicio de desarrollo tcnicos
Figura 5.16. Roles del proceso de creacin de servicios

Resumen
La creacin de servicios se ha convertido en un factor clave para lograr el xito
empresarial. El proveedor de TI debe posibilitar un tiempo de entrega de servicios
(time-to-market) acorde a las necesidades del cliente, pero tambin debe contemplar
que los costes, la funcionalidad y calidad de los servicios estn ajustados a sus nece-
sidades reales.
Las principales responsabilidades que tiene a su cargo el proceso se indican en la
figura 5.17.
Figura 5.17. Principales responsabilidades del proceso
Adems, el proceso realiza dos aportaciones fundamentales a la gestin de servicios

de TI:
Organiza todo el ciclo de creacin de servicios para que se fabriquen en los
plazos acordados, con la calidad, costes y funcionalidad pactados.
Asume la responsabilidad de coordinar a todos los procesos y departamentos
de TI para lograr sus objetivos.
Para ello, articula un ciclo de la provisin de servicios que involucra y gestiona

todos los procesos, funciones y reas de TI implicados. Elabora un plan de trabajo
integrado para proveer e implantar el servicio a partir del cual se negocia con el
cliente. Una vez que se ha logrado un consenso y acuerdo con el cliente, se aprueba
formalmente el plan de proyecto mediante el proceso de gestin del cambio y su
rgano de gestin interno, el comit de cambios, en el que estn representadas
todas las partes implicadas.
En la figura 5.18 se muestra un resumen general de las actividades de este proceso.
Resumen del ciclo de fabricacin de un servicio de TI
1. Identificar las necesidades del cliente y proponer servicios TI que

satisfagan dichas necesidades.
2. Documentar los requisitos que debe cumplir el servicio solicitado por el
cliente. El resultado de esta actividad: Requisitos de nivel de servicio (SLR).
3. Realizar un anlisis de viabilidad (si procede).
4. Elaborar las especificaciones tcnicas del servicio.
5. Elaborar la propuesta de servicio incluyendo la propuesta de SLA para ser
presentado y negociado con el cliente.
6. Negociar y acordar con el cliente la propuesta de servicio y SLA final.
Solo se tratan los aspectos de cliente y en trminos de negocio.
7. Elaborar el plan de proyecto del servicio con todos los procesos y
departamentos TI implicados.
8. Revisin de acuerdos internos (OLA) y externos (UC).
9. Crear RFC y presentar a gestin de cambio para su aprobacin,
formalizacin y compromiso de realizacin de todas las partes implicadas.
10. Inclusin del proyecto en la planificacin de cambios (FSC), a partir de la
cual se gestiona cualquier cambio, propio o provocado por otros motivos,
de forma integrada y normalizada.
11. Control del proceso de fabricacin del servicio realizado por cada uno de
los intervinientes.
12. Aprobacin de la implantacin del servicio.
13. Gestin de la entrega del servicio al cliente y revisin posimplantacin.
14. Comprobacin resultados de la implantacin del servicio comparando los
resultados reales obtenidos con los planificados.
15. Comunicacin de resultados.
16. Cierre de la peticin.
Figura 5.18. Resumen del ciclo de fabricacin de un servicio de TI
Este proceso de planificacin e implementacin es el punto central sobre el que se

sustenta la coordinacin dentro del proveedor de servicios TI para la creacin y evo-
lucin de los servicios a los clientes. Esta actividad la realiza con la colaboracin de
mltiples intervinientes coordinndolos en la bsqueda de encontrar el equilibrio
correcto entre la demanda del cliente, la provisin del servicio, el coste de los mis-
mos y la satisfaccin del cliente.
Para finalizar este captulo, es importante destacar que este proceso es complejo y
soporta mltiples relaciones, por lo que el uso de las herramientas adecuadas es un
punto que no se debe descuidar. La disponibilidad de herramientas especficas (cat-
logo de servicios actualizado, formularios de recogida de requerimientos y especifi-
caciones SLR, SS, modelos de SLA/OLA/UC, un sistema de gestin documental,
etc.) pueden ser el elemento clave para el xito de este proceso y, por tanto, para el
xito de TI en la provisin de servicios nuevos o modificados.
Beneficios
La planificacin e implementacin de servicios nuevos o de servicios modificados
posibilita una mayor confianza en la relacin TI-Negocio, y un incremento de
la satisfaccin de los clientes, gracias a la transparencia y claridad de las propuestas
de los servicios que se van a proveer e implantar, ya que estn realizadas con el
compromiso de todas las partes implicadas y alineadas con las necesidades de nego-
cio planteadas por el cliente.
Tambin contribuye a mejorar esta relacin la fiabilidad que proporciona la planifi-
cacin integrada de todas las reas y procesos TI intervinientes que permite asegu-
rar que una peticin es viable, que la relacin calidad-precio es adecuada, que est
alineada con la estrategia de negocio y tcnica. Tambin contribuye a agilizar y ase-
gurar el time to market de provisin de soluciones, minimizando los riesgos relacio-
nados con el cumplimiento de plazos y costes asociados.
Los principales beneficios que se obtienen al implementar este proceso son:
Los servicios TI se disean para satisfacer las necesidades reales del cliente.
La relacin con el cliente se basa en servicios que TI proporciona, y en el
lenguaje y trminos del negocio.
Se atienden las demandas del negocio convirtindolas en servicios, de acuerdo
con la estrategia y los presupuestos.
La organizacin de TI y sus clientes tienen unas expectativas claras y consis-
tentes del servicio solicitado a TI.
Gestin formalizada de los requisitos del cliente, en su propio lenguaje.
Control del ciclo completo, e integrado, de creacin y modificacin de los
servicios, desde la perspectiva de las necesidades y acuerdos con el cliente,
hasta su entrega y puesta en funcionamiento operativo.
La organizacin del proveedor de TI tiene una visin integrada de lo que el

cliente espera de ellos y dirige sus esfuerzos a las reas y compromisos clave
para el negocio.
Aseguramiento de calidad del servicio acorde a lo estipulado con el cliente.
Mejora del cumplimiento de los plazos de entrega de servicios, nuevos o evo-
lucionados, al cliente.
Gestin de los costes del proyecto acordes a lo estipulado con del cliente.
Controla que el servicio se ha realizado siguiendo las polticas y estndares
de la organizacin TI, lo que facilita su posterior evolucin de forma efi-
ciente.
Cul es la operativa habitual para la creacin de servicios TI en su
organizacin?
Cmo se validan las propuestas de nuevos servicios?
Qu mejoras incorporara al proceso propuesto en este captulo?
1
6 Procesos de
provisin de servicio
Captulo 6
6.4. Elaboracin de presupuestos

6.1. Gestin de nivel de servicio y contabilidad de los
servicios de TI
6.2. Generacin de informes

6.5. Gestin de la capacidad
del servicio
99,99%
6.3. Gestin de la continuidad y 6.6. Gestin de la seguridad
disponibilidad del servicio de la informacin


6. Procesos de provisin de servicio 193
Una vez creado el servicio y puesto con xito en explotacin regular, es necesario
desencadenar una serie de actividades que ayuden a garantizar que los servicios cum-
plen los cometidos pactados con el negocio en trminos de: los niveles de servicio,
la continuidad, la disponibilidad, los presupuestos, la capacidad y la seguridad.
Adems de velar por la consecucin de lo comprometido, tambin se debe estar
involucrado en asegurarse que los nuevos servicios o la evolucin de los mismos se
realiza cumpliendo con lo que la organizacin ha predefinido.
Para garantizar que se cumplen estos objetivos se han definido los procesos de
provisin del servicio, seis procesos especializados que engranan con las relacio-
nes con el negocio y con la creacin de servicios. En la figura 6.1 se muestran
estas relaciones.
Planificacin e implementacin de nuevos servicios

o de servicios modificados
Procesos de provisin del servicio

Relaciones
con el
negocio Presupuesto y contabilidad
Gestin de la capacidad
Gestin
de nivel de
servicio
Gestin de la continuidad y
disponibilidad de servicios TI
Generacin Gestin de la seguridad

de informes de la informacin
del servicio
Figura 6.1. Procesos de provisin del servicio y su mbito de relacin
En este escenario de servicios de alta calidad, alineados con los objetivos del nego-
cio, que cubren las necesidades actuales y que deben ser capaces de evolucionar
rpidamente para cubrir las necesidades futuras, los procesos de la provisin del
servicio toman una especial importancia.
Los procesos de provisin del servicio en ISO/IEC 20000 contienen una impor-
tante diferencia frente a lo definido en ITIL v2, pues incorpora la generacin de
informes de servicio como un proceso independiente e incluye tambin el proceso
de seguridad de la informacin. Adems, agrupa en uno slo los procesos de conti-
nuidad y de disponibilidad (que en ITIL v2 estn separados).
6. Procesos de provisin de servicio
6.1. Gestin de nivel de servicio 195
6.1. Gestin de nivel de servicio
Figura 6.1.1. Esquema general del proceso de la gestin de nivel de servicio
En el captulo anterior se ha podido apreciar que la gestin de nivel de servicio

desempea uno de los papeles clave en la creacin y evolucin de los servicios de
TI, definiendo y acordando los niveles de servicio que se deben cumplir. Pero este
proceso tambin desempea funciones importantes durante la prestacin habitual
de los servicios de TI, registrando y gestionando el cumplimiento de los niveles de
servicio comprometidos. Por ello, este proceso est considerado como una pieza
esencial para garantizar la orientacin al cliente de los servicios.
As, la misin principal de la gestin de nivel de servicio es establecer los niveles
de servicio a los que TI se puede comprometer, para posteriormente velar por su
consecucin. Adems, contribuye a la mejora de la calidad de los servicios apli-
cando un ciclo continuo de seguimiento, medicin, generacin de informes y an-
lisis de los resultados. Tambin propone acciones de mejora que permitan erradicar
las deficiencias en la prestacin de los servicios, mejoras siempre alineadas con las
necesidades del negocio y con un coste asociado justificado.
Por tanto, este proceso es la mdula espinal que distribuye a todas las reas de TI
las necesidades de los clientes en formato de niveles de servicio. Participa activa-
mente en el ciclo de creacin de los servicios, y es el responsable de controlar el
cumplimiento de estas necesidades a lo largo de la vida productiva de los mismos.

Supervisa si se est consiguiendo el nivel de servicio acordado y, en caso contrario,
determina el motivo y promueve las acciones de mejora adecuadas.
El seguimiento continuo de los niveles de servicio permite mejorar la calidad del
servicio de TI y eliminar las deficiencias en los mismos, reduciendo el impacto
negativo en el negocio.
Pero, el beneficio ms significativo de una efectiva gestin de nivel de servicio es
la mejora de la relacin y la confianza de los clientes con su proveedor de servicios
de TI.
En ITIL v2 hay definido un proceso con el mismo nombre, pero en realidad las
funciones asignadas en ITIL a este proceso le convierten en un megaproceso, el
gestor del nivel de servicio debe ser un superhombre. As, ITIL v2 agrupa en la
gestin de nivel de servicio actividades que en ISO/IEC 20000 se han distribuido
en 5 procesos, en:
El presente proceso de gestin de nivel de servicio (vase el apartado 6.1 de
las normas).
El proceso de generacin de informes del servicio (vase el apartado 6.2
de las normas).
El proceso de relaciones con el negocio, el definido en estas normas se
corresponde nicamente a las relaciones con el cliente, que se llevan a
cabo en la gestin de nivel de servicio de ITIL (vase el apartado 7.2 de
las normas).
El proceso de gestin de suministradores, pues la gestin de nivel de servicio
de ITIL v2 tambin se responsabiliza de la definicin de los niveles de servi-
cio a contratar a terceros (UC, Underpinning Contract) y del seguimiento
posterior de su cumplimiento (vase el apartado 7.3 de las normas).
El proceso de planificacin e implementacin de nuevos servicios o de servi-
cios modificados (vase el captulo 5 de las normas).
Analizando ITIL v3, se aprecia que aparecen la gestin del catlogo de servicios y
la gestin de suministradores como procesos nuevos que restan peso a la gestin
de nivel de servicio definida esta nueva versin de ITIL.
Por tanto, el panorama entre estos tres modelos queda algo intrincado. En la figura
6.1.2 se muestra una comparativa entre los alcances asignados a este proceso en los
diferentes marcos.
Proceso en ITIL v2 Proceso en ITIL v3 Procesos en ISO/IEC 20000
Gestin de nivel de Gestin de nivel de servicio (SLA)

servicio ITIL v3
Generacin de informes del servicio
Gestin del catlogo
Gestin relacin con el negocio
Gestin de nivel de servicio
de servicio ITIL v2 Planificacin e implementacin de
Gestin de
servicios nuevos o modificados
suministradores
(slo niveles de servicio Gestin de suministradores (slo niveles
contratados) de servicio contratados)
Figura 6.1.2. Comparativa del alcance de la gestin de nivel de servicio

entre los diferentes marcos
En la figura 6.1.3 se presenta una introduccin al proceso.
Proceso de gestin de Qu aporta:

nivel de servicio Fijacin de los objetivos de los
servicios mediante parmetros
medibles.
Definicin: Confianza de que los niveles de
Proceso que se encarga de mantener y servicio acordados se pueden cumplir.
mejorar la calidad de los servicios TI Conocimiento preciso del esfuerzo
mediante una gestin eficiente de los que le supone a TI alcanzar unos
acuerdos de nivel de servicio firmados determinados niveles de servicio.
con los clientes. Los servicios de TI se conciben para
alcanzar las expectativas del cliente.
El desempeo del servicio se puede
Objetivo: medir, por lo tanto se puede gestionar
Denir, acordar, registrar y gestionar y mejorar.
los niveles de servicio. Se mejora la relacin interna entre
unidades de TI y con los proveedores,
en base a acuerdos medibles.
Contribuye a la mejora de la
satisfaccin de los clientes.
Figura 6.1.3. Introduccin al proceso de gestin de nivel de servicio
El proceso debe ser capaz de comprender las demandas del negocio, aunque en
ISO/IEC 20000 no lleva propiamente las relaciones con el negocio (vase el apar-
tado 7.2). Se relaciona internamente con el resto de unidades de TI para negociar y
fijar los acuerdos operativos. Tambin establece los requisitos para que los contra-
tos de soporte con los suministradores estn alineados con los compromisos del
servicio, contratos que negociar y seguir el proceso de gestin de suministrado-
res (vase el apartado 7.3).
En la figura 6.1.4 se muestran los principios bsicos en los que se sustenta la activi-
dad de este proceso.
Figura 6.1.4. Principios bsicos del proceso
La implementacin de las Normas ISO/IEC 20000 requiere un cambio en la cul-

tura de la organizacin, con una orientacin al servicio y al cliente. La gestin de
nivel de servicio es el instrumento principal para inculcar la cultura de servicios en
la organizacin de TI. As, la misin de la organizacin de TI va ms all de la pura
tecnologa, para ofrecer soluciones al negocio empaquetadas bajo el concepto de
servicio. Para ello, el catlogo de servicios y los acuerdos de nivel de servicio (SLA)
son las principales palancas para esta transformacin cultural. Los servicios que se
ofrecen a los clientes se recogen en un catlogo de servicios de TI, alineado con el
negocio, que gestiona y mantiene este proceso. Adems, los servicios llevan asocia-
dos un compromiso de prestacin negociado con los clientes, incluidos en los
acuerdos de nivel de servicio o SLA. Este compromiso lo expande internamente

hacia toda la organizacin de TI y externamente hacia los suministradores que par-
ticipan en el soporte de los servicios.
Otra de las misiones del proceso es inculcar el rigor en toda la organizacin en rela-
cin al cumplimiento de los acuerdos firmados, para lo cual realiza una monitori-
zacin y seguimiento permanente.
El proceso de gestin de nivel de servicio debe establecer e implantar un sistema de
seguimiento y medicin para identificar si se estn logrando los niveles de servicio
acordados con los clientes. En caso contrario, debe determinar y analizar, con los
procesos y reas relacionadas, el motivo de esta ineficiencia para promover las accio-
nes de mejora necesarias. Adems, establece un plan de mejora continua de los
servicios que se incorporar al plan de mejora unificado (vase el apartado 4.1), en
todos sus aspectos: tcnicos, organizativos, de formacin, de documentacin, etc.
Como en el resto de los procesos en ISO/IEC 20000, la gestin de nivel de servi-
cio mantiene tambin una actividad de mejora continua de su propia actividad
como proceso.
La misin principal de la gestin de nivel de servicio es mantener y mejorar la cali-
dad de los servicios de TI. En la figura 6.1.5 se muestran los principales conceptos
que se desarrollan en este proceso.
Acuerdo de nivel de servicio (SLA, Service Level Agreement). Es un documento

que recoge los compromisos acordados entre el cliente y el proveedor de servicios
de TI relativos a las condiciones de prestacin o explotacin del servicio requerido.
Este documento es un acuerdo por escrito que define el alcance concreto del servi-
cio, los objetivos que se deben cumplir y las responsabilidades de ambas partes. Por
tanto, el SLA es el contrato de prestacin de uno o varios servicios del catlogo a
los clientes y sus usuarios. El SLA detalla la particularizacin en la prestacin de un
servicio del catlogo a un cliente.
El proveedor de servicios y el cliente deberan desarrollar una asociacin transpa-
rente, a fin de poder alcanzar unos acuerdos beneficiosos para ambas partes; de
otro modo, el SLA perdera rpidamente su reputacin y se podra caer en el tpico
intercambio permanente de acusaciones que no es un buen medio para conseguir
ninguna mejora de la calidad del servicio.
Acuerdo de nivel operativo (OLA, Operacional Level Agreement). Documento

que formaliza un acuerdo de colaboracin entre departamentos internos de la orga-
nizacin de TI para la prestacin y operacin regular de los servicios. Se trata, por
tanto, de un contrato interno en TI.
Catlogo
de servicios Supervisin
Cultura del servicio
de servicio y de los SLA
Mejoras
Acuerdos de nivel
de servicio (SLA)
Programa de
mejora del
Acuerdos de nivel Gestin de nivel servicio (SIP)
de operativo (OLA) de servicio
Cultura de
compromiso
Requisitos para PDCA

los contratos Mejoras SGSTI
de soporte (UC)
Mejora
del proceso
Figura 6.1.5. Principales componentes del proceso de gestin

de nivel de servicio
Catlogo de servicios (service catalog). Documento o base de datos que elabora

la organizacin de TI para informar a clientes, usuarios y personal de TI de los
servicios ofrecidos. Proporciona una visin sencilla, en terminologa entendible por
el negocio, de todos los servicios de TI y las alternativas u opciones de prestacin.
Es recomendable que refleje los precios de los servicios en el caso de que se impu-
ten, o por lo menos de los costes en los que incurre la empresa al proveerlos. El
catlogo tiene una informacin visible por el negocio y otra parte destinada al uso
interno de TI, en la que se describen en ms detalle los elementos tcnicos que son
necesarios para la prestacin del servicio.
Contrato de soporte (UC, Underpinning Contract). Documento contractual

(contrato legal) entre el proveedor de TI y un suministrador de servicios externo.
Este contrato define los objetivos, alcance y caractersticas del servicio que se va a
prestar, as como los plazos y costes asociados.
Cultura de compromiso. La organizacin de TI y sus miembros articulan sus

objetivos y su actividad encaminada principalmente al cumplimiento de los acuerdos.
Cultura de servicio. Implica que la satisfaccin del cliente es la prioridad principal

para todos los miembros de la organizacin de TI que ofrece los servicios. Adems,
se controla que las actividades llevadas a cabo en la provisin de los servicios con-
tribuyen a los objetivos de negocio del cliente.
Programa de mejora del servicio (SIP, Service Improvement Program). Docu-

mento que describe las reas de mejora de un servicio y define el plan de proyecto
a realizar por cada rea o proceso de la organizacin de TI para llevar a cabo las
mejoras propuestas. Este documento, por tanto, establece el objetivo y alcance de
las mejoras, su justificacin en trminos de coste/beneficio, las fases, actividades,
planificacin y responsabilidades, as como, las mtricas necesarias para el segui-
miento del proyecto y validacin de las mejoras.
Servicio de TI. Se puede definir como un conjunto de funciones relacionadas, pro-

porcionadas por sistemas de TI que dan soporte a una o ms reas de negocio
(departamentos, sucursales, etc.). Un servicio suele estar compuesto de partes: soft-
ware, hardware, elementos de comunicacin soporte, etc., pero el cliente y el usua-
rio final que lo utiliza, lo perciben como algo autocontenido y coherente.
Otra posible definicin podra ser un conjunto integrado por una serie de elemen-
tos incluyendo procesos de gestin, hardware, software, facilidades y recursos huma-
nos, que constituyen una capacidad que permite satisfacer una necesidad o alcanzar
un determinado objetivo.
En ITIL v3, un servicio se define como un medio de entregar valor a los clientes
facilitando los resultados que los clientes quieren lograr sin la necesidad de que
tengan la propiedad de los activos necesarios, ni la responsabilidad de los riesgos
asociados.

La gestin de nivel de servicio se organiza en torno a tres reas de actividad: una
enfocada al establecimiento de los acuerdos de nivel de servicio con los clientes,
otra enfocada a que TI cumpla los compromisos adquiridos en los SLA y, la
ltima, destinada a la mejora de los servicios. La primera de ellas est desencade-
nada por el proceso de gestin de las relaciones con el negocio a raz de una solici-
tud de un cliente de un nuevo servicio, una modificacin a uno existente o una
propuesta de cambio a un SLA ya establecido. En este caso, la responsabilidad del
presente proceso es todo lo relativo a los niveles de servicio, a definir o ya defini-

dos. Las otras dos reas restantes se desempean de forma continua y velan por la
calidad de los servicios prestados y por el cumplimiento de los SLA firmados.
Las actividades el proceso junto con sus entradas y salidas se resumen en la figu-
ra 6.1.6.
Desencadenantes 3 Gestin del catlogo de Salidas principales:

del proceso: servicios: creacin y Catalogo de servicios.
Necesidades negocio y mantenimiento.
Acuerdos de nivel de
clientes. 3 Gestin de los SLA: creacin, servicio (SLA).
Sistema de acuerdo, difusin,
Programa de mejora del
monitorizacin de mantenimiento.
servicio (SIP).
servicios. 3 Gestin de OLA y respaldo
Encuestas de mediante UC. Salidas secundarias:
satisfaccin del cliente. 3 Supervisin y monitorizacin Acuerdos nivel operativo
de los servicios y de (OLA).
Entradas de soporte: los SLA.
Requisitos para
Catlogo de servicios 3 Mejorar los servicios y SIP, los contratos de
existente. a travs de los programas soporte (UC).
Acuerdos de nivel de de mejora del servicio.
Especificaciones para los
servicio existentes. 3 Supervisin y mejora del informes de cumplimiento
Acuerdos nivel operativo proceso. de nivel de servicio.
y contratos de soporte 3 Generacin de peticiones de Plan de mejora del
existentes. cambio (RFC): del catlogo, proceso.
Informacin del nivel de de SLA, de UC, de los
Peticiones de cambio
servicio procedente servicios o del propio proceso.
(RFC) por SLA o SIP.
de otros procesos.
CMDB actualizada.
Polticas negocio y TI.
Arquitecturas TI.
CMDB.
Figura 6.1.6. Entradas, actividades y salidas del proceso de gestin

Las entradas que desencadenan la activacin del proceso de creacin de servicios

son la resolucin de las necesidades del cliente (tratada por el proceso de gestin de
las relaciones con el negocio); la informacin sobre el desempeo de los servicios
recibida de los sistemas de monitorizacin, especialmente en relacin al cumpli-

miento de los SLA; los resultados negativos de las encuestas de satisfaccin del
cliente o del usuario que impulsen a los gestores de nivel de servicio al impulso de
acciones de mejora.
El proceso utiliza otras entradas de apoyo a la realizacin de sus actividades. Las
principales entradas de soporte son el catlogo de servicios existente para determi-
nar si la necesidad del cliente est cubierta por el catlogo o para realizar modifica-
ciones en l; los SLA, OLA y UC existentes como base para la definicin de los
nuevos o para modificarlos; la informacin sobre el nivel de servicio y propuestas
de mejora provenientes de otros procesos o reas; las polticas relativas a la presta-
cin de servicios; las arquitecturas de TI existentes con el fin de conocer los niveles
de servicio a los que se puede comprometer; y la CMDB para proveer todo tipo de
informacin sobre TI y sus elementos de configuracin.
El proceso de gestin de nivel de servicio agrupa las actividades de coordinacin,
diseo, negociacin, monitorizacin y reporte de los acuerdos del nivel de servicio
establecidos con el cliente, as como la revisin continua de los resultados del servi-
cio para asegurarse de mantener y mejorar gradualmente la calidad del servicio, que
necesita el negocio, de forma justificable en trminos de coste. Las actividades prin-
cipales que realiza este proceso son:
Gestin del catlogo de servicios. Se encarga de la creacin y manteni-
miento del catlogo de servicios de TI. Ayuda al proceso de relaciones con el
negocio a determinar si las necesidades del cliente pueden ser provistas por
servicios del catlogo.
Gestin de SLA. Creacin de los acuerdos de nivel de servicio (SLA), rea-
lizada en coordinacin o bajo peticin de relaciones con el negocio. Difu-
sin de los SLA entre toda la organizacin de TI. Mantenimiento de los
SLA, actualizando sus contenidos en coordinacin con relaciones con el
negocio.
Gestin de OLA y respaldo con UC. Revisin de los acuerdos internos y
contratos con suministradores (OLA y UC) para garantizar que respaldan lo
comprometido en los SLA. En relacin a los UC, pasa los requisitos que se
deben cumplir al proceso de gestin de suministradores para la realizacin
de un nuevo contrato o la modificacin a los existentes.
Supervisin y monitorizacin de los servicios y de los SLA. Para verificar
el cumplimiento de los niveles de servicio y emprender acciones de mejora
en caso de necesidad.
Mejora de los servicios y SIP. Creando un programa de mejora del servi-
cio para cada uno de ellos, o bien, uno conjunto.
Supervisin y mejora del funcionamiento del proceso de gestin de

nivel de servicio.
Generacin de las solicitudes de cambio (RFC). Necesarias para la modi-
ficacin o ampliacin del catlogo de servicios, para los nuevos o modifica-
ciones a los SLA y los OLA, y para la aprobacin y ejecucin del programa
de mejora del servicio (SIP) o el plan de mejora del proceso.
Las salidas principales del proceso son el catlogo de servicios creado, actualizado y
publicado a los usuarios (va web); los acuerdos de nivel de servicio nuevos o
actualizados firmados; el o los programas de mejora del servicio, que se remitirn
al comit de cambios (CAB) y al plan de mejora unificado de los procesos y de los
servicios (vase el captulo 4).
Las salidas secundarias del proceso son los acuerdos de nivel operativo internos
nuevos o actualizados; la definicin de requisitos para los contratos de soporte para
la gestin de suministradores; las especificaciones sobre los contenidos necesarios
sobre los informes de los servicios, tanto para el uso interno del proceso, como para
su publicacin al resto de TI y al cliente; las peticiones de cambio necesarias para la
aprobacin de las modificaciones a realizar; y por ltimo, la CMDB actualizada con
los cambios en el catlogo, en los SLA, etc.
El catlogo de servicios de TI
El catlogo de servicios es el instrumento de relacin ms importante de TI con sus
clientes, ya que en l se recoge el conjunto total de los servicios que la organizacin
de TI provee a sus clientes. El catlogo es una excelente herramienta para ayudar
en el cambio cultural del proveedor de servicios de TI hacia objetivos como:
Alineamiento con el negocio. Aportando valor aadido al conocer de
forma clara y precisa los servicios de TI que soportan su negocio.
Orientacin al cliente. Estructurando la misin y el trabajo de TI en torno
a la satisfaccin de las necesidades del cliente en forma de prestacin de
servicios.
Calidad de servicio. Contemplando los indicadores y mtricas que consti-
tuyen la base de los acuerdos de nivel de servicio (SLA).
Gestin de los servicios. Facilita la gestin y control de los niveles de servi-
cio comprometidos con los clientes, posibilitando medir en trminos que el
cliente entiende. Estas medidas permiten pasar de medir percepciones a
tener mtricas entendidas y acordadas por las dos partes.
UNE-ISO/IEC 20000-1
Se deben acordar por las partes, y registrar, el conjunto total de los servicios a ser
provistos, junto a los correspondientes objetivos de nivel de servicio y las caractersti-
cas de la carga de trabajo que deben soportar.
UNE-ISO/IEC 20000-2
Catlogo de servicios a) el nombre del servicio,
Todos los servicios deberan estar defini- b) los objetivos (por ejemplo tiempo de res-
puesta o de instalacin de una impre-
dos en un catlogo de servicios. Este sora, tiempo para reiniciar un servicio
catlogo puede ser referenciado desde tras un fallo importante),
el SLA y debera utilizarse para recoger c) datos de contacto,
aquellos aspectos considerados como d) horario del servicio y excepciones,
demasiado cambiantes para ser intro- e) disposiciones de seguridad.
ducidos en el SLA.
El catlogo de servicios es un docu-
El catlogo de servicios debera ser mento clave para establecer las expec-
mantenido y estar actualizado en todo tativas del cliente y debera ser fcil-
momento. mente accesible y estar ampliamente
Nota: El catlogo de servicios puede incluir infor- disponible tanto para los clientes como
macin genrica como: para el personal de apoyo.
La caracterstica ms importante del catlogo es que constituye el nico punto de

informacin sobre la oferta de servicios, de inters tanto para el cliente, como para
la propia organizacin de TI. En el catlogo se deja bien claro lo que TI ofrece a la
comunidad de clientes y usuarios.
El catlogo de servicios se construye con los siguientes propsitos:
Presentar a los clientes y usuarios los servicios existentes de una forma orga-
nizada que permita conocer las funcionalidades y requisitos de los servicios,
as como, servir de base para futuras negociaciones de acuerdos del nivel de
servicio.
Definir y organizar los servicios internos de infraestructura, que TI presta a
un nivel interno no perceptible por el cliente, pero que son necesarios para
sustentar los servicios prestados a los clientes.
El catlogo de servicios est dirigido a cualquier cliente y usuario que soli-
cite informacin de los servicios que presta el proveedor de servicios de TI.
Facilitar que la organizacin de TI gestione los servicios de una forma efi-

ciente, ya que el catlogo est elaborado por y para los clientes y contiene los
niveles de servicio acordados.
Para cumplir su funcin, se debera acceder a l fcilmente y estar disponible tanto

para los clientes como para el personal de TI. La publicacin va web en un portal
de TI en la intranet de la empresa es uno de los mejores medios para conseguirlo.
Adems se deben preparar sesiones de presentacin del catlogo, tanto con los
clientes, como internamente en TI.
El catlogo debe contener todos los servicios que proporciona TI, sus caractersti-
cas, y los clientes y usuarios a los que van destinados.
En la actividad de definicin de un catlogo de servicios TI se suelen utilizar los
siguientes elementos:
Definicin de servicio. Explicacin precisa de lo que es un servicio.
Clasificacin en categoras y subcategoras de servicio. Agrupacin lgica de
servicios. Los servicios se pueden organizar realizando agrupaciones con dis-
tintos grupos de servicios.
Lista de servicios. Enumeracin de todos los servicios agrupados por cate-
gora/subcategora.
Estructura del catlogo. ndice general del contenido que tendr el catlogo.
Plantilla de la ficha de un servicio. Estructura del documento que describir
cada servicio.
Fichas descriptivas de los servicios. Documentos elaborados para cada uno
de los servicios que reflejan la oferta comn de TI. Contienen la descripcin,
atributos, parmetros y componentes de cada servicio ofertado. Una defini-
cin estndar de un servicio, puede adaptarse a las necesidades de un cliente
a travs de la firma de un SLA especfico con este cliente.
Relacin de reas cliente. Clasificacin de los clientes de TI a los que se ofre-
cen servicios. Pueden ser clientes internos (de la misma empresa) o externos.
Mapa de cliente/categoras de servicio. Esquema grfico de las categoras de
servicios y sus reas cliente.
Matriz cliente/servicio. Tabla que relaciona cada servicio con sus reas
cliente.
La estructura habitual de un catlogo de servicios se muestra en la figura 6.1.7.

Estructura de catlogo de servicios.

Plan de proyecto de creacin del servicio
1. Definicin y objetivos del catlogo de servicios:

2. Introduccin. Contiene una breve descripcin de la
organizacin de TI. Incluir nmero de empleados,
cunto tiempo lleva en la empresa, misin y visin,
y persona de contacto del catlogo (suele ser un
gestor de clientes).
3. Categorizacin de servicios y mapa de servicios.
Explica la clasificacin de los servicios definida.
4. Lista y descripcin de servicios. Incluir links a las
fichas de servicios que contengan la descripcin de
los servicios.
5. Glosario. Definicin de los conceptos generales ms
importantes (SLA, etc.).
6. Anexos. Incluir la informacin necesaria que no est
recogida en los captulos anteriores y links a los
siguientes documentos: matriz cliente/servicio,
plantilla de la ficha de servicio, ejemplo de SLA, etc.
Figura 6.1.7. Estructura tipo de un catlogo de servicios
Con el fin de describir de forma detallada y homognea todos los servicios que
oferta TI, se debe establecer una plantilla documental que servir de base para defi-
nir todos los servicios. Esta ficha tipo suele estructurarse en dos partes: una que
contiene los aspectos de inters para los clientes y usuarios, y otra que incorpora
detalles sobre los servicios internos de TI, que no se muestra a los usuarios. En la
figura 6.1.8 se presenta un ejemplo de la estructura de una ficha de servicio.
Es recomendable que el servicio se d de alta en el catlogo tan pronto como se
conozcan los datos bsicos del mismo, sin esperar a que est operativo. De esta
forma, toda la comunidad de usuarios y los profesionales de la organizacin de TI
conocern de primera mano los servicios que estn en fase de definicin y acuerdo.
Para gestionar correctamente las expectativas y no crear conflictos o malos entendi-
dos, se utiliza la informacin de estado del servicio (vase la figura 6.1.9). Esta
informacin debe contener las etapas del ciclo de vida de los servicios, desde su
peticin hasta su retirada de la operacin.
Definicin.
Funcionalidades del servicio.
Ficha de un servicio de TI Opciones de contratacin.
Condiciones de uso.
Informacin externa del servicio: mbito del servicio.

Valor para el negocio.
1. Descripcin del servicio para el usuario. Entregables principales.
Condiciones de la prestacin.
2. Informacin complementaria del servicio Prerrequisitos.
para el cliente. Parmetros del servicio: horarios,
plazos, costes.
3. Solicitud de acceso, modificacin y baja.
Procedimiento de solicitud.
4. Preguntas frecuentes.
Autorizaciones requeridas.
Informacin interna del servicio: Componentes del servicio.

Entornos tecnolgicos.
5. Indicadores del servicio. Instrucciones tcnicas y manuales.
reas internas y OLA.
6. Informacin tcnica del servicio.
Suministradores y UC.
7. Informacin del coste del servicio.
Enlace al SLA estndar (ofertado)
8. SLA del servicio. del servicio.
Enlaces a los SLA firmados para
9. Varios. este servicio con diversos clientes.
Fuente: Telefnica.
Figura 6.1.8. Plantilla de una ficha descriptiva de un servicio
Estados de un servicio
Requerimientos
Definido
Analizado
Aprobado
Dotado
Diseado
Desarrollado
Construido
Probado
Desplegado
Operativo
Retirado
Fuente: Libro ITIL Diseo del Servicio publicado por OGC.
Figura 6.1.9. Secuencia de estados de un servicio en el catlogo en ITIL v3

Una vez que se define o se actualiza el catlogo, se debe generar una nueva versin
del mismo. Esta nueva versin se debe publicar en la organizacin TI, distribuida a
los gestores de las relaciones con el negocio y clientes para publicitar y dar a cono-
cer todos los servicios disponibles, ponindolo accesible a los usuarios (va web).
El catlogo de servicios requiere un mantenimiento y una actualizacin peridica,
incorporando los nuevos servicios o las modificaciones a los existentes. Todo cam-
bio en el catlogo debe realizarse bajo el control del proceso de gestin del cambio.
El acuerdo de nivel de servicio (SLA, Service Level

Agreement)
Los proveedores de servicio TI orientados al cliente y al servicio necesitan formali-
zar por escrito los servicios que ofrecen al cliente y los niveles de prestacin de los
mismos. De esta forma, queda muy claro lo que el cliente va a recibir y los com-
promisos que asume TI, fomentndose una mayor profesionalidad y una mejora de
la confianza del negocio hacia TI.
Si bien el catlogo pone claridad en la oferta de TI, el acuerdo de nivel de servicio es el
contrato de prestacin, y concreta los compromisos de forma especfica y medible.
Como se trata en el captulo 5 de este libro, el proceso de gestin de nivel de servi-
cio colabora con planificacin e implantacin de servicios en la elaboracin de las
especificaciones tcnicas de los servicios, que describen la solucin tcnica que
soporta los requisitos del cliente.
Estas especificaciones proporcionan las definiciones tcnicas necesarias para pro-
veer e implantar el servicio, y sirven de partida para elaborar la primera propuesta
de acuerdo de nivel de servicio (SLA) para presentar al cliente como respuesta a su
demanda, para su revisin, negociacin y acuerdo.
El SLA es pieza esencial, por ello, ISO/IEC 20000 pone un especial foco en este
punto, exigiendo expresamente que los servicios se formalicen a travs de los SLA.
UNE-ISO/IEC 20000-1
Cada servicio ofrecido se debe definir, acordar y documentar en uno o ms acuer-

dos de nivel de servicio (SLAs).
Se deben acordar y registrar por todas las partes relevantes los SLAs, junto con los
acuerdos de servicios de soporte, los contratos con suministradores y los correspon-
dientes procedimientos.
Los SLAs deben estar bajo el control de la gestin del cambio.
Es importante destacar que, tanto el proveedor de servicios TI como el cliente,

deben ser conscientes que se est proporcionando y recibiendo un servicio, y el
SLA es el documento que formaliza esta relacin.
La Norma ISO/IEC 20000-2 pone un especial nfasis en establecer recomendacio-
nes sobre el SLA, especialmente en lo relativo a su formalizacin y a que debe esta-
blecerse un equilibrio entre las necesidades de los clientes y los costes.
UNE-ISO/IEC 20000-2
Acuerdos de nivel de servicio (SLAs) c) detalles sobre la autorizacin;
Todo servicio debera estar formalmente d) descripcin breve de las comuni-

documentado en un acuerdo de nivel caciones, incluida la generacin
de servicio (SLA). El SLA debera ser de informes;
autorizado formalmente por la direccin e) datos de contacto de las personas
del cliente y los representantes del pro- autorizadas a actuar ante emer-
veedor del servicio. El SLA debera estar gencias, participar en la resolu-
sujeto a la gestin del cambio, as como cin de incidentes y problemas,
el servicio que describe. as como en la recuperacin del
El presupuesto y las necesidades del servicio o en la aplicacin de
cliente deberan ser los elementos en soluciones temporales;
que se base el contenido, la estructura y f) horario de servicio, por ejemplo de
los objetivos del SLA. Los objetivos, res- 9:00 h a 17:00 h, y excepciones
pecto de los cuales debera medirse el al mismo (por ejemplo fines de
servicio prestado, se deberan definir semana o periodos vacacionales),
desde la perspectiva del cliente. periodos crticos para el negocio y
Los SLAs deberan incluir nicamente un cobertura fuera del horario;
conjunto adecuado de objetivos para g) interrupciones planificadas y acor-
centrar la atencin en los aspectos ms dadas, incluido el aviso que se
importantes del servicio. debe dar y el nmero por periodo;
Nota 1: Demasiados objetivos pueden gene- h) responsabilidades del cliente, por
rar confusin y conllevar un exceso de ejemplo seguridad;
gastos.
i) responsabilidades y obligaciones
El contenido mnimo que debera tener del proveedor del servicio, por
un SLA, o que se debera referenciar ejemplo seguridad;
desde l, es el siguiente:
j) directrices sobre impactos y prio-
a) descripcin breve del servicio; ridades;
b) periodo de validez y/o mecanismo k) procesos de escalado y de notifi-
de control de cambios del SLA; cacin;
l) procedimientos de reclamacin; r) glosario de trminos;

m)objetivos del servicio; s) servicios de soporte y otros rela-
cionados con el propio servicio;
n) lmites de la carga de trabajo
(superior e inferior), por ejemplo la t) las excepciones a las clusulas
capacidad del servicio de soportar incluidas en el SLA.
un nmero acordado de clientes
o un volumen de trabajo o la ca- Nota 2: La informacin voltil o comn a varios
SLAs (como datos de contacto) se pueden
pacidad de procesamiento del sis- referenciar desde el SLA sin que esto
tema; suponga un impacto en la calidad de los
procesos de SLM siempre que los docu-
o) detalles de alto nivel de la gestin mentos de referencia estn tambin bajo el
financiera, por ejemplo cdigos control del proceso de gestin del cambio.
de imputacin, etc.;
Nota 3: En el SLA se suele hacer referencia al
p) acciones a llevar a cabo en caso plan de continuidad y a los detalles de la
contabilidad y del presupuesto.
de interrupcin del servicio;
Nota 4: El glosario de trminos normalmente suele
q) procedimientos de mantenimiento ser nico y comn a todos los documen-
interno; tos, incluyendo el catlogo de servicios.
El contenido del SLA debe identificar claramente a todos los intervinientes del
acuerdo de servicio: el cliente, los usuarios, las distintas reas de la organizacin TI
involucradas en la prestacin del servicio; as como las caractersticas del servicio a
prestar: los horarios de disponibilidad del servicio, los tiempos de respuesta, los
plazos de resolucin en caso de incidente, etc.
En relacin a los horarios de disponibilidad del servicio se deben definir los tramos
horarios en los que habitualmente se utiliza el servicio, por ejemplo: 7 x 24 horas,
de lunes a viernes de 8:00 a 18:00 h, etc. Adems, es importante incluir directrices
para posibles ampliaciones del mismo, que contemplen el tiempo de preaviso nece-
sario (por ejemplo, esta solicitud se debe realizar al servicio de asistencia tcnica
antes de las 12 AM para una ampliacin del servicio por la tarde, antes de las 12 del
jueves para una ampliacin el fin de semana). Tambin se incluyen horarios espe-
ciales como en perodos de vacaciones, etc., y un calendario anual del servicio en el
caso de variaciones de las condiciones del servicio, como en campaas de Navidad,
en verano, etc.
La disponibilidad del servicio es uno de los parmetros que ms impacta en el nego-
cio y uno de los ms famosos en el SLA. Se definen los objetivos de disponibilidad
de los servicios dentro del horario acordado, normalmente expresados en trminos de
porcentajes (99%, 99,8%, 99,99%, etc.); se incluye tambin el perodo y el mtodo
de medida.
Sin embargo, resulta difcil relacionar los porcentajes de disponibilidad de los

servicios con las actividades de negocio. En situaciones de excelencia, se intenta
reemplazar la medida de indisponibilidad por la incapacidad del cliente para lle-
var a cabo sus actividades, por ejemplo: el volumen de ventas que resultan afec-
tadas, como consecuencia de un fallo de TI en la provisin de un servicio de
soporte a los puntos de venta.
Como parte de la disponibilidad, en ocasiones se pacta tambin la fiabilidad de los
servicios. Este elemento se expresa habitualmente mediante el nmero de interrup-
ciones del servicio, para ello, se utilizan indicadores como el tiempo medio entre
fallos (MTBF, Mean Time Between Failures), o el tiempo medio entre incidencias
del sistema (MTBSI, Mean Time Between System Incidents).
ITIL v3 en el libro Transicin del Servicio recomienda que el SLA se cierre definiti-
vamente despus de una fase piloto o al principio de la vida del servicio (early life
support), antes de que la transicin se haya terminado.
El acuerdo de nivel de servicio describe en terminologa del negocio qu se
entrega al cliente. Para complementar este documento se crea el plan de proyecto
del servicio, que detalla cmo TI va a entregar este servicio al cliente.
Este documento es muy importante ya que contiene toda la informacin adminis-
trativa necesaria para gestionar a la organizacin de TI en la consecucin de los
objetivos comprometidos con el cliente para la prestacin del servicio.
Las condiciones de asistencia y soporte para resolver incidencias, consultas o peti-
ciones, tambin se deben incluir en el SLA. Habitualmente se incorporan:
Horario de asistencia.
Provisiones para posibles ampliaciones de la asistencia, que incluyan el
tiempo de preaviso necesario.
Horarios especiales (por ejemplo, das de fiesta, vacaciones, etc.).
Plazo objetivo de atencin a las incidencias, bien presencialmente o por otros
medios (por ejemplo, por telfono, e-mail, etc.).
Plazo objetivo para resolver las incidencias. Los objetivos variarn depen-
diendo de la prioridad de las incidencias.
El tiempo de respuesta del servicio, tratado en ITIL bajo el proceso de disponi-

bilidad, es otro de los factores importantes que hay que considerar. En el caso de
los servicios online, es el principal indicador utilizado para medir las transacciones.
Se deben establecer los tiempos objetivo de respuesta, medios o mximos, medidos
desde los puestos de trabajo. El tiempo de respuesta se expresa en porcentaje, por
ejemplo, el 95% de las transacciones en menos de 2 segundos.
En el caso del procesado por lotes, se establece la ventana de tiempo para la ejecu-
cin de trabajos batch (normalmente en horario nocturno), se acuerda el porcen-
taje de finalizacin correcta de los trabajos, el lugar para obtener y entregar los
resultados, los interlocutores por ambas partes, etc.
Tambin se debe contemplar las condiciones relativas a la capacidad soportada por
el servicio, como son los lmites de la carga de trabajo, el nmero de usuarios, capa-
cidad de procesamiento del sistema, los volmenes de trfico de comunicaciones,
el nmero pico de transacciones que ser necesario procesar y el nmero mximo
de usuarios en concurrencia. Esto es importante para poder identificar las deficien-
cias en el rendimiento o el incremento de costes debido a la necesidad de ampliar la
capacidad del servicio o del nmero de licencias de software.
En relacin a los cambios al SLA, es importante identificar los criterios para reali-
zarlos y los interlocutores necesarios para aprobar, gestionar e implementar las peti-
ciones de cambio (RFC) relacionadas con el servicio. Normalmente los criterios se
basan en la categorizacin y urgencia, o impacto del cambio.
Los aspectos de la continuidad ante desastres y seguridad del servicio tambin son
temas para analizar e incorporar al SLA:
Se debe contemplar si el servicio est sujeto a planes para la continuidad de
los servicios TI, describiendo brevemente las condiciones que marcan la acti-
vacin del plan y cmo ponerlo en marcha.
Detalles de los objetivos de servicio reducidos o modificados en caso de
desastre (si no existe un SLA especfico para tales situaciones).
Informacin relacionada con la seguridad, especialmente aquellos aspectos
que sean responsabilidad del cliente (por ejemplo, copias de seguridad, cam-
bios de contrasea, etc.).
En el acuerdo de servicio es importante recoger los detalles sobre los costes, pero-
dos y frmulas de facturacin (si se factura).
Se deben detallar los contenidos, frecuencia y distribucin de los informes, as
como, la frecuencia de las reuniones para la revisin del servicio.
En la figura 6.1.10 se muestran los conceptos que se deben incluir en un SLA, ali-
neados con las recomendaciones de la Norma ISO/IEC 20000-2.
El acuerdo de nivel de servicio es el contrato que TI firma con sus clientes, en torno
a este acuerdo todas las reas y procesos de la organizacin deben enfocar su activi-
dad para velar por su cumplimiento.
Contenido de un SLA Asistencia:

Horario de asistencia (cuando no sea
el mismo que el horario de servicio).
Ttulo y breve descripcin del
servicio. Horarios especiales.
Objetivos del servicio. Tiempo objetivo de respuesta a las
incidencias.
Las partes implicadas en el acuerdo.
Tiempo objetivo para resolver las
Titular del servicio. Firmantes.
incidencias.
Fechas: comienzo, trmino, revisin.
Procedimientos de escalado y de
mbito del acuerdo, lo que cubre y lo
notificacin.
que se excluye.
Procedimientos de reclamacin.
Responsabilidades del proveedor del
servicio y del cliente. Acciones a llevar a cabo en caso de
interrupcin del servicio.
Descripcin de los servicios cubiertos.
Interrupciones planificadas y
Horario de prestacin, excepciones
acordadas, incluido el aviso que se
al mismo y perodos crticos para el
debe dar y el nmero por perodo.
negocio y cobertura fuera del horario.
Responsabilidades del cliente.
Disponibilidad del servicio y capacidad
soportada por el mismo. Responsabilidades y obligaciones del
proveedor del servicio.
Procesado por lotes (batch).
Detalles de alto nivel de la gestin
Autorizaciones.
financiera.
Comunicacin, reuniones e informes.
Mecanismo de control de cambios
Datos de contacto. del SLA. Procedimientos de
OLA y UC de soporte con el propio mantenimiento interno.
servicio. Glosario de trminos.
Continuidad y seguridad de los Excepciones a las clusulas incluidas
servicios TI. en el SLA.
Directrices sobre impactos y
prioridades.
Fuente: UNE-ISO/IEC 20000 y e.p.
Figura 6.1.10. Contenido ejemplo de un SLA
Alternativas para la estructuracin del SLA

La definicin del contenido de los SLA es muy importante en una organizacin de
provisin de servicios TI. No olvidemos que regula la relacin de la prestacin con-
tinua del servicio que TI proporciona a sus clientes.
Segn ITIL, hay diversas formas de establecer los SLA: basado en el servicio,
basado en el cliente y multinivel.
SLA basado en el servicio. Cuando un SLA cubre un servicio y es el mismo para

todos sus clientes. Por ejemplo, se puede establecer un nico SLA para el servicio de
correo electrnico de una organizacin que cubra a todos los clientes de ese servicio.
Aunque puede parecer bastante sencillo, sin embargo pueden surgir dificultades si
los requisitos especficos de clientes varan para un mismo servicio, o si las caracte-
rsticas de la infraestructura TI implican que sean inevitables distintos niveles
de servicio (por ejemplo, la central puede estar conectada por medio de una LAN de
alta velocidad, mientras que las oficinas locales utilizan una lnea de menor veloci-
dad). En tales casos, sern necesarios distintos objetivos en un mismo acuerdo.
Tambin pueden surgir dificultades al determinar quin debera firmar tales acuer-
dos.
SLA basado en el cliente. Soporta un acuerdo con una rea cliente especfica, que
cubra todos los servicios que utilizan. Por ejemplo, se puede llegar a acuerdos con
el departamento de finanzas de una organizacin para cubrir, por ejemplo, el sis-
tema financiero, el de contabilidad, el de nminas, la facturacin y otros servicios
que utilicen.
A menudo, los clientes prefieren este acuerdo, ya que cubren todos sus requisitos
con un solo documento. Slo se requiere una firma, lo que simplifica su gestin y
evolucin posterior.
SLA multinivel. Algunas organizaciones, principalmente multinacionales, han

decidido adoptar una estructura de acuerdos de nivel de servicio de nivel mltiple.
Por ejemplo, una estructura de tres niveles como la siguiente:
1. Nivel corporativo. Cubre todos los aspectos genricos sobre la prestacin
de servicios para los clientes en toda la organizacin. Generalmente estos
aspectos son menos voltiles, por lo que ser necesario realizar menos actua-
lizaciones.
2. Nivel del cliente. Cubre todos los aspectos sobre la prestacin de servicios
que resultan relevantes para un grupo de clientes particular, sin que importe
el servicio utilizado.
3. Nivel del servicio. Cubre todos los aspectos sobre la prestacin de servicios
aplicado a un servicio concreto y a este grupo de clientes especfico (para
cada servicio recogido en los SLA). En la figura 6.1.11 se muestra una
estructura de este tipo.
Nivel corporativo
Nivel del cliente
Nivel del servicio
Fuente: Libro ITIL Provisin de Servicio publicado por OGC.
Figura 6.1.11. Acuerdos de nivel de servicio multinivel
Buenas prcticas relativas al proceso y al SLA

Realmente el proceso de gestin de nivel de servicio se puede llevar a cabo de ml-
tiples formas, ya que no hay una secuencia de actividades precisa que conforme
flujo o un conjunto de pasos que se deben seguir. Pero si hay un conjunto de bue-
nas prcticas que conviene tener en consideracin para tener xito, en este apartado
se detallan algunas consideraciones al respecto.
UNE-ISO/IEC 20000-2
El proceso de gestin de nivel de

suspensin temporal. El proceso de ges-
servicio
tin de nivel de servicio (SLM) debera ser
Los cambios importantes en el negocio, flexible para adecuarse a estos cambios.
debidos, por ejemplo, al crecimiento, El proceso de SLM debera asegurar que
fusiones y reorganizaciones del negocio, el proveedor del servicio continua focali-
y los cambios en los requisitos del cliente, zado en el cliente durante la planifica-
pueden implicar el ajuste de los niveles cin, implantacin y la gestin continua
de servicio, su redefinicin o incluso su del servicio prestado.
Se le debera dar al proveedor del servi- e) entrada al programa de mejora

cio la informacin adecuada para per- del servicio.
mitirle que comprenda las motivaciones
y requisitos del negocio del cliente. El proceso debera animar tanto al pro-
veedor del servicio como al cliente a
El proceso de SLM debera gestionar y
desarrollar una actitud proactiva con
coordinar a quienes contribuyen al nivel
de servicio, para incluir: objeto de garantizar que ambos tienen
una responsabilidad compartida sobre
a) acuerdo en los requisitos del ser- el servicio.
vicio y en las caractersticas de la
carga de trabajo esperada del La satisfaccin del cliente es una parte
servicio; importante de la gestin de nivel de
servicio pero debera reconocerse que
b) acuerdo en los objetivos de servicio;
es una medida subjetiva, mientras que
c) medicin e informe de los niveles los objetivos de servicio incluidos en el
de servicio conseguidos, cargas de SLA deberan ser medidas objetivas. El
trabajo y explicaciones cuando proceso de SLM debera trabajar con-
no se alcanzan los objetivos acor- juntamente con los procesos de gestin
dados; de relaciones con el negocio y gestin de
d) inicio de la accin correctiva; suministradores.
En relacin a la gestin del SLA los principales temas a tener en cuenta son:
Involucrar al cliente. Siempre que sea posible es necesario involucrar al cliente

desde el comienzo de la actividad. En la relacin con el cliente es conveniente crear
un borrador con las lneas maestras del SLA que sirva como punto de partida, para
posteriormente ir ampliando y profundizando en sus contenidos. Es fundamental
que el cliente participe y sienta el SLA como suyo. Si TI profundiza demasiado en
su definicin hasta el punto de presentar el SLA como un hecho consumado
puede provocar el rechazo en el cliente.
En muchas organizaciones se utilizan documentos proforma, creados a partir de
definiciones de SLA pilotos, como punto de partida para todos los acuerdos
de nivel de servicio.
Redaccin de los acuerdos. La redaccin de los SLA deber ser clara y concisa,
sin dejar lugar a la ambigedad. Generalmente no es necesario que los acuerdos
estn redactados utilizando una terminologa legal; en realidad la utilizacin de
un lenguaje claro ayudar a una mejor comprensin. Como comprobacin resulta
muy til que una persona independiente, que no est implicada en la redaccin
del documento, realice una lectura final del mismo. Esta revisin suele poner de
manifiesto las posibles ambigedades y dificultades, lo que nos permite tomas las
medidas oportunas de revisin y aclaracin.
Tambin merece la pena recordar que los acuerdos de nivel de servicio pueden dar
cobertura a los servicios ofrecidos a diferentes comunidades lingsticas, por lo que
es necesario contemplar la disponibilidad de los SLA en los diferentes idiomas. En
este aspecto hay que dedicar un especial cuidado a la terminologa, ya que un SLA
puede revisarse en diferentes pases y, por tanto, puede ser necesario considerar los
aspectos de terminologa, estilos y diferencias culturales.
Negociacin y acuerdo. Una vez definido y redactado un documento base del

acuerdo, se deben mantener negociaciones con el cliente, o con sus representantes,
para concretar los contenidos del SLA y los objetivos finales del nivel de servicio.
En este proceso tambin es necesario establecer reuniones previas con las reas
internas de TI y con los proveedores para asegurarse de que estos niveles son alcan-
zables y cerrar los acuerdos de nivel operativo (OLA) y los contratos de soporte
(UC) correspondientes.
Para realizar esta labor, el gestor del nivel de servicio deber realizar su propio pro-
grama de reuniones y negociaciones con los clientes (a travs de relaciones con el
negocio) para asegurar que se identifican los requisitos reales, y con las reas inter-
nas y los suministradores (a travs de gestin de suministradores) para garantizar
que se cubren adecuadamente los compromisos establecidos en el SLA.
En este punto es importante formalizar con el cliente los mecanismos de revisin y
notificacin, los intervalos y los formatos de los informes de los SLA.
La frecuencia y el formato de las reuniones de revisin del servicio tambin deben
acordarse con los clientes. Es muy recomendable utilizar intervalos regulares, y en
cuanto a los informes peridicos, al menos se deberan alinear con los ciclos de las
revisiones. Es conveniente la realizacin de reuniones presenciales para facilitar la
comunicacin personal, pero en el caso de dispersin geogrfica ser recomendable
la utilizacin de otros formatos de reunin.
Firma del acuerdo. Este aspecto es esencial para que el SLA acordado tenga la
suficiente credibilidad por las dos partes, por lo que hay que garantizar que al tr-
mino del proceso de redaccin y negociacin, el acuerdo de nivel de servicio sea
firmado por los cargos apropiados, tanto del lado del cliente como del proveedor
de TI.
Esto garantizar el compromiso de que ambas partes intentarn hacer todo lo que
sea posible para cumplir los SLA firmados. De forma general, cuanto ms alta sea
la jerarqua de los firmantes, mayor ser esta garanta.
Una vez firmado y cerrado el acuerdo de nivel de servicio se debe formalizar den-
tro de la organizacin TI como un activo ms, y por tanto estar sujeto al control
de gestin del cambio, mediante la correspondiente formalizacin de una peticin
de cambio. A partir de este punto, cualquier modificacin estar sujeta a la gestin
y aprobacin del proceso de gestin del cambio.
Difusin de los SLA. Una vez cerrado el SLA, es fundamental utilizar una buena
promocin y difusin que permita asegurar que los clientes y las diferentes reas del
proveedor de servicios TI estn enterados de su existencia y de los objetivos clave.
En este punto es clave que el centro de servicio al usuario tenga conocimiento de
los contenidos de los SLA, ya que es el primer punto de contacto de los incidentes,
consultas y quejas de los clientes. Si el personal del centro de servicio al usuario no
est bien informado de los SLA en vigor y no acta en consecuencia, los clientes
perdern rpidamente su confianza en estos acuerdos.
Mantenimiento de los SLA. El SLA es un elemento de informacin ms dentro

de la organizacin de TI y, una vez operativo, est sujeto al mismo control y admi-
nistracin que el resto de los elementos de configuracin (CI, Configuration Item).
Por tanto, cualquier propuesta de modificacin est sujeta al control y aprobacin
del proceso de gestin del cambio.
Revisin de los SLA. Los acuerdos del nivel de servicio deben revisarse peridica-
mente con los clientes para garantizar si an son validos y adecuados a las necesida-
des del negocio y las capacidades de la organizacin TI, por ejemplo, anualmente
en lnea con el ciclo financiero.
UNE-ISO/IEC 20000-1
Los SLAs se deben revisar peridicamente por las partes, para asegurar que se
encuentran actualizados y continan siendo eficaces con el transcurso del tiempo.
Para cubrir este objetivo es necesario mantener reuniones peridicas de revisin

con los clientes (o sus representantes) para examinar los logros del servicio en el
ltimo periodo y para prever cualquier aspecto del siguiente periodo. Suele ser fre-
cuente mantener estas reuniones con una periodicidad mensual o, como mnimo,
trimestral.
Del resultado de estas reuniones, y si es necesario, se debe emplazar al cliente y al
proveedor a llevar a cabo acciones apropiadas para mejorar reas en las que no se
estn consiguiendo los objetivos. Todas las medidas acordadas se deberan registrar
en las actas, y se debera revisar el progreso y los resultados obtenidos en la
siguiente reunin.
Acuerdos de servicio de soporte (OLA y UC)

El proceso de gestin de nivel de servicio establece una cadena de acuerdos que le
permita asegurar que los compromisos establecidos en el SLA son alcanzables
y que, en el caso que se produzca cualquier impacto negativo o rotura de SLA,
le facilitar la localizacin del punto de fallo y su resolucin. As, para garantizar la
cobertura de los SLA este proceso establece acuerdos que implican a la organiza-
cin interna del proveedor de TI y a los suministradores externos que le proporcio-
nan bienes o servicios.
Con las unidades internas se formalizan acuerdos de nivel operativo (OLA, Opera-
tional Level Agreement) en los que se recogen todos los compromisos necesarios de
cada una de las reas intervinientes relacionadas con su aportacin al cumplimiento
del SLA.
Para los suministradores externos establecen los contratos de soporte (UC, Under-
pinning Contract) en los que se recogen los compromisos de los suministradores en
el cumplimiento de los SLA que soportan. El contrato de soporte con terceros se
gestiona entre dos procesos: la gestin de nivel de servicio establece los requisitos
de servicio que se deben exigir al suministrador, mientras que la gestin de sumi-
nistradores se encarga de la negociacin y su firma.
ISO/IEC 20000-2 establece la base para el desarrollo de esta cadena de acuerdos.
UNE-ISO/IEC 20000-2
Los servicios de soporte de los cuales trador de servicios. Esto incluye los grupos
depende el servicio prestado se deberan internos que proveen parte del servicio
documentar y acordar con cada suminis- ofrecido por el proveedor del servicio.
Es habitual que las organizaciones tengan contratos con suministradores para la

prestacin de los servicios. Pero habitualmente, estos contratos no estn alineados
completamente con lo comprometido en los SLA. Se debe trasladar a estos contra-
tos los principales requerimientos que el suministrador debe cumplir para que la
organizacin de TI pueda garantizar los niveles de servicio comprometidos.
En el caso de los OLA, el cambio que se produce en la organizacin de TI es

mucho ms drstico. La firma de acuerdos internos requiere la estructuracin de
TI en unidades o grupos de soporte, y que cada grupo de soporte tenga claramente
definidas sus fronteras de actuacin. Estos grupos de soporte deben transformar su
mentalidad y ser conscientes de que estn prestando un servicio interno (por ejem-
plo, almacenamiento, bases de datos, frontales web, comunicaciones, etc.). Desde
este momento, la comunicacin entre las unidades estar basada en tickets de tra-
bajo, provenientes de incidentes, peticiones o de partes de trabajos mayores. La
implantacin de los OLA en el proveedor de TI supone una fuerte transformacin
cultural y organizativa.
Por ello, no es frecuente encontrar una organizacin que se relacione internamente
basndose en compromisos internos de nivel de servicio (OLA).
En su mayora, los contratos de soporte dan servicio directamente a los grupos
internos y son stos los que soportan el servicio final. Por tanto, suelen ser los gru-
pos internos de especialistas los que tratan a nivel tcnico con el soporte de los
suministradores. Excepto en el caso de externalizacin completa de un servicio (por
ejemplo, el correo electrnico), en el que el suministrador es controlado directa-
mente por los gestores del servicio.
Lo habitual es que un OLA y un UC den soporte a mltiples servicios, por ejem-
plo el equipo de tcnica de sistemas interno y el soporte de los diferentes fabrican-
tes de servidores midrange darn soporte a todos los SLA de los servicios.
En la figura 6.1.12 se muestra un ejemplo de una cadena de aseguramiento de los
SLA para un departamento de administracin en base a una cascada de OLA y UC.
Como se puede observar en la figura 6.1.12, si esta cadena se realiza con rigor y
compromiso, el nivel de riesgo de incumplimiento de los acuerdos con los clientes
es bajo. Si a esto le aadimos la monitorizacin y seguimiento de los acuerdos, con
el objetivo de identificar y proponer acciones de mejora, nos encontramos con una
herramienta muy poderosa, que nos posibilita la mejora de la satisfaccin de los
clientes y, desde el punto de vista interno, nos permite optimizar y mejorar la efi-
ciencia en la prestacin de los servicios TI.
Los SLA, OLA y UC se deben mantener actualizados, y es necesario revisar peridi-
camente, y por lo menos una vez al ao, que an tienen la cobertura adecuada, estn
actualizados y continan alineados con las necesidades y estrategia del negocio.
Estas revisiones deberan garantizar que tanto los servicios cubiertos como los obje-
tivos de cada uno son todava relevantes y que no se ha realizado ningn cambio sig-
nificativo que invalide el acuerdo de algn modo, como por ejemplo cambios en la
infraestructura TI, el negocio, el proveedor, etc.
Figura 6.1.12. Ejemplo de la cadena de aseguramiento de los SLA

para un departamento de administracin de la empresa
En el caso que se detecte un cambio se deberan actualizar los acuerdos, bajo el

control de gestin del cambio y de las unidades internas involucradas para que
reflejen la nueva situacin.
A modo de ejemplo, en la figura 6.1.13 se muestra la informacin recogida habi-
tualmente en un acuerdo de nivel operativo.
El contrato de soporte es un documento contractual entre la organizacin de TI y
un suministrador externo, por tanto utiliza el formato de contrato habitual de la
empresa o del suministrador. El UC debera tratar los conceptos enunciados en
la figura 6.1.14.
Un contrato de soporte (UC) es el documento contractual entre la organizacin TI
y un suministrador de servicios externo. Este contrato define el objetivo, alcance y
caractersticas del servicio que se va a prestar.
Estructura de un acuerdo de
nivel operativo (OLA)
Introduccin:
Objetivo y alcance.
SLA de referencia.
Unidad TI que lo soporta.
Requerimientos:
Acuerdos del servicio.
Descripcin del nivel de servicio (SLA).
Plan de proyecto del servicio interno.
Objetivo y alcance del servicio.
mbito de aplicacin.
Funcionalidades proporcionadas.
Caractersticas del servicio interno:

Niveles internos de servicio y niveles SLA de
referencia.
Horario de servicio y soporte, disponibilidad y
fiabilidad, continuidad y seguridad, rendimiento.
Otros OLA y UC que utiliza.
Explotacin y operacin, tcnicas, etc.
Responsables involucrados:
Responsable de planificacin e implantacin de
servicios nuevos o modificados.
Responsable de gestin de nivel de servicio.
Responsables de procesos/departamentos
afectados.
Responsables de otros procesos/departamentos
involucrados.
Fuente: Telefnica.
Figura 6.1.13. Contenido tipo de un acuerdo de nivel operativo (OLA)

Contenidos de un contrato de soporte (UC)
Introduccin:
Objetivo y alcance.
SLA y OLA de referencia.
Nombre del suministrador. Unidad TI que lo soporta.
Requerimientos:
Acuerdos de nivel de servicio (SLA) y
operativos (OLA).
Plan de proyecto del servicio.
Descripcin del servicio:

Objetivo y alcance del servicio.
mbito de aplicacin y relaciones con otros servicios.
Funcionalidades proporcionadas.
Caractersticas del servicio interno:

Funcionales.
Horario de servicio y soporte, disponibilidad y
fiabilidad.
Niveles internos de servicio. Continuidad y seguridad,
rendimiento.
Interfaces.
Explotacin y operacin, etc.
Condiciones comerciales:
Coste del servicio y forma de pago.
Mecanismos de control y seguimiento:

Indicadores y mtricas, informes de gestin.
Responsables involucrados:
Responsable de planificacin e implantacin de
servicios nuevos o modificados.
Responsable de nivel de servicio.
Proveedores de servicios externos.
Fuente: Telefnica.
Figura 6.1.14. Contenido tipo de los contratos de soporte (UC)

Supervisin y monitorizacin del servicio y de los SLA

Una vez activado el servicio, con su SLA correspondiente, se inicia su explotacin.
Desde este momento se debe poner en marcha la actividad de supervisin del servi-
cio y de monitorizacin de los niveles alcanzados, para determinar su calidad, fiabi-
lidad y disponibilidad. Se generan los informes sobre el nivel de servicio para anali-
zar y demostrar su cumplimiento.
UNE-ISO/IEC 20000-1
Los niveles de servicio se deben monitorizar y se deben generar informes de dichos

niveles con relacin a los objetivos, mostrando tanto la informacin actual como las
tendencias. Las razones para las no conformidades se deben comunicar y revisar.
Durante la actividad de redaccin y negociacin del acuerdo es cuando se anali-

zan y determinan las mtricas para medir el servicio, y es justo en este punto en
el que hay que comprobar que existen los medios necesarios para poder monito-
rizar su cumplimiento. No se debera incluir ninguna mtrica en un SLA a menos
que pueda medirse y monitorizarse de una manera efectiva y segn acuerdo
mutuo. Esto es importante, ya que incluir elementos que no puedan monitori-
zarse de forma eficaz provocar conflictos y la eventual prdida de confianza en
los SLA.
En la actividad de monitorizacin se debe prestar una atencin especial a cada
incumplimiento (denominado ruptura o violacin) de los niveles de servicio acor-
dados, con el fin de determinar qu fue exactamente lo que caus la prdida del
servicio y qu se puede hacer para evitar que vuelva a ocurrir. Si se determina que
el nivel de servicio es ahora inalcanzable, es aconsejable revisar y volver a acordar
unos objetivos diferentes. Si la ruptura del servicio ha sido causada por un fallo de
una tercera parte o de un grupo de soporte interno, puede que tambin sea necesa-
rio revisar el contrato de soporte o el OLA correspondiente.
En los informes se deber realizar la comparacin entre los valores de los indicado-
res obtenidos y los valores objetivo o umbrales de referencia.
Los informes generados y la informacin que contienen tienen como objetivo la
comprobacin del cumplimiento de los SLA y el anlisis de su evolucin, para
detectar posibles acciones de mejora a los SLA y los componentes de la propia
organizacin TI. Es decir, estos informes estn destinados tanto a la gestin de
nivel de servicio como a la propia gestin interna, por tanto, el contenido y natura-
leza de estos informes deber ajustarse a cada destinatario.
Para realizar los informes el proceso de generacin de informes de servicio necesita

la definicin y recopilacin de toda la informacin necesaria en forma de indicado-
res y mtricas. Estos indicadores y mtricas son acordados y suministrados por
otros procesos de gestin del servicio, tales como gestin de la disponibilidad, ges-
tin del incidente, etc.
La naturaleza de estos indicadores estar relacionada con informacin de disponi-
bilidad y fiabilidad del servicio. Tambin es muy interesante disponer de informa-
cin relacionada con la opinin del cliente respecto a la calidad percibida en la pres-
tacin del servicio.
Para poder realizar esta actividad de monitorizacin de SLA y emisin de informes
es necesario tener el soporte de las herramientas que permita realizar la captura y
anlisis de los indicadores y mtricas de calidad del servicio, as como la evaluacin
del grado de cumplimiento de los acuerdos del nivel de servicio establecidos con
los clientes.
Las caractersticas bsicas que deben reunir las herramientas que constituyan el sis-
tema de monitorizacin de los servicios son las siguientes:
Facilidad de interconexin con sistemas y herramientas de monitorizacin
de los sistemas, as como herramientas de gestin con otros procesos con el
fin de recopilar las mtricas e indicadores establecidos.
Posibilidad de definicin y parametrizacin de indicadores y mtricas.
Posibilidad de definicin y parametrizacin de valores umbrales de las mtricas.
Generacin de alarmas de incumplimiento de los acuerdos de nivel de servi-
cio activos y alarmas de proximidad al incumplimiento.
Generacin online de informes del nivel de servicio.
Mejora de los servicios y programa de mejora del

servicio (SIP, Service Improvement Program)
Como consecuencia de la actividad de supervisin y monitorizacin de los servi-
cios, de las reuniones con el cliente (relaciones con el negocio), etc., se identifica
un conjunto de posibles mejoras que se pueden realizar. Las mejoras se recogen en
un documento denominado programa de mejora del servicio (SIP). Como todo
plan de proyecto, establece los objetivos y alcance de las mejoras, la descripcin de
las actividades que se deben realizar, las responsabilidades de las distintas reas par-
ticipantes, la planificacin de las actividades, as como, los mecanismos para su con-
trol y seguimiento. Este programa, por tanto, establece el objetivo y alcance de las
mejoras, su justificacin en trminos de coste/beneficio, las fases, actividades, pla-

nificacin y responsabilidades, as como las mtricas necesarias para el seguimiento
del proyecto y validacin de las mejoras.
UNE-ISO/IEC 20000-1
Las acciones de mejora definidas durante este proceso se deben registrar y constitu-
yen una entrada al plan de mejora del servicio.
En el momento que se identifique una dificultad subyacente que est impactando

negativamente sobre la calidad del servicio, gestin de nivel de servicio debe, en cola-
boracin con el resto de procesos (especialmente con la gestin del problema y la ges-
tin de la disponibilidad), promover un programa de mejora del servicio (SIP).
Las iniciativas incluidas en los SIP tambin pueden centrarse en aspectos como la
formacin de los usuarios, la documentacin y las pruebas de los sistemas. Cuando
para la mejora de un servicio sea necesario modificar un proceso, la actividad se
coordinar con el responsable del propio proceso para que la implemente.
Todo SIP debe ser aprobado por la gestin del cambio antes del inicio de su ejecu-
cin.
Los SIP generados, que estn destinados a la mejora de los servicios, se incorpora-
rn en el Plan de mejora unificado de los procesos y de los servicios (vase el
captulo 4), con el fin de coordinar desde un nico punto todas las acciones de
mejora en TI, de los servicios y de los procesos.
El contenido habitual de un SIP se muestra en la figura 6.1.15.
Una buena prctica a tener en cuenta es la dotacin de un presupuesto anual para
financiar las mejoras (plan de mejora unificado de los procesos y los programas de
mejora de los servicios). De esta forma, las acciones se pueden llevar a cabo ms
rpidamente. Esta prctica es muy til, ya que hace que tanto la gestin de nivel de
servicio como la mejora de los procesos sea cada vez ms proactiva y previsora.
Mejora del proceso de gestin de nivel de servicio

Al igual que en el resto de los procesos, el responsable de gestin de nivel de servi-
cio, tambin debe velar por la mejora continua de su propio proceso. Las acciones
identificadas se incluirn y coordinarn con el Plan de mejora unificado de los pro-
cesos y de los servicios descrito en el captulo 4.
Programa de mejora del Descripcin modificaciones OLA y UC

servicio (SIP)
Detalles acciones de mejora
propuestas Clientes actuales: para
cada rea/proceso:
Introduccin
Gestin del incidente.
Objetivo y alcance.
Gestin de la seguridad.
Clientes actuales: Gestin de la disponibilidad.
Cliente. Gestin de la capacidad.
SLA referencia.
Fecha de inicio. Plan de proyecto para la mejora
Servicio. Descripcin de la mejora
Plan de trabajo. Actividades y
reas de mejora
responsables.
Descripcin de las debilidades y
Planificacin de actividades. Fases,
reas de servicio.
actividades, hitos.
Acciones de mejora Impacto.
Descripcin a alto nivel de las Estimacin de esfuerzo.

acciones de mejora del servicio. Estimacin de costes.
Justificacin coste/beneficio. Cambios asociados:
Descripcin.
reas TI involucradas Justificacin.
rea. Beneficios esperados.
Justificacin.
Participacin.
Fuente: Libro ITIL Provisin de Servicio publicado por OGC y Telefnica.
Figura 6.1.15. Contenido tipo de un SIP

Relaciones con otros procesos y reas

Dado que este proceso tiene una interrelacin amplia con los otros procesos es
necesario revisar las relaciones con el resto de ellos y con otras reas de TI. En la
figura 6.1.16 se presentan las principales relaciones de gestin de nivel de servicio
en el ciclo de creacin y modificacin de servicios.
Seguidamente se incluye una breve descripcin de la relacin de cada uno de los pro-
cesos reflejados en la figura 6.1.16 con el proceso de gestin de nivel de servicio.
Figura 6.1.16. Principales relaciones del proceso de gestin de nivel de servicio

con otros procesos y reas de TI
El proceso de relaciones con el negocio, podemos decir que se encarga de mante-

ner las relaciones pblicas para la gestin de nivel de servicio. Relaciones con el
negocio entiende ms de las funcionalidades que necesita el negocio y establece
y mantiene la relacin con el cliente, mientras que la gestin de nivel de servicio
tiene un conocimiento ms preciso de lo que TI es capaz de aportar. El proceso de
relaciones con el negocio requiere la participacin de la gestin de nivel de servicio
en todos los aspectos relacionados con la satisfaccin de las necesidades del cliente
mediante servicios ya disponibles en el catlogo o mediante la confeccin o revi-
sin de los acuerdos del nivel de servicio. Una vez puesto en marcha el servicio, ges-
tin de nivel de servicio rinde cuentas al cliente sobre los niveles de servicio
alcanzados y analiza conjuntamente las opciones de mejora.
En el caso del proceso de planificacin e implantacin de servicios nuevos o modi-
ficados, la interrelacin sigue un esquema similar: las relaciones con el negocio se
encargan de entender al cliente y el establecimiento de los requisitos, mientras que
la gestin de nivel de servicio proporciona un catlogo de servicios actualizado y la
definicin del acuerdo de nivel de servicio (SLA).
El proceso de generacin de informes del servicio produce los informes que nece-
sita la gestin de nivel de servicio para informar a los clientes y a TI sobre los nive-
les de servicio. Los informes deben contemplar informacin relevante de forma
que permita analizar aspectos clave del servicio, como su rendimiento, cargas
de trabajo, cumplimiento de los compromisos con los clientes (SLA), incidentes
graves, etc. Los informes deben servir para la gestin de los servicios y la defini-
cin de acciones correctoras y de mejora de los servicios.
El proceso de elaboracin de presupuestos y contabilidad de los servicios de TI
proporciona la informacin econmica necesaria para la toma de decisiones en
cuanto a los niveles de servicio y para que los compromisos se asuman con un
conocimiento preciso de los costes.
Con el resto de procesos, la gestin de nivel de servicio establece el valor de los
parmetros en SLA que se pueden cumplir por TI, para posteriormente realizar el
seguimiento de los mismos. As, con la gestin de la continuidad y disponibilidad
se establecern los umbrales de los SLA de emergencia y los valores de disponibili-
dad y de rendimiento de los servicios; con la gestin de la seguridad los temas rela-
tivos al nivel de seguridad a comprometer; con la gestin de la capacidad se defi-
nen las necesidades de proceso, almacenamiento, etc.
La relacin con la gestin del cambio es de las ms fundamentales, pues gestin de
nivel de servicio (como todos los otros procesos) no puede cambiar nada que no
est validado por la gestin del cambio. Por ello, se deben generar peticiones de
cambio antes de crear un nuevo SLA o de modificar uno existente, as como para
ejecutar las modificaciones derivadas de los planes de mejora del servicio.
En relacin con el rea de desarrollo de aplicaciones, el proceso de planificacin y
diseo de infraestructuras y el de operacin del servicio, se tratan los requisitos a
cumplir por cada una para la satisfaccin de los niveles de servicio. Los compromisos
con cada una de estas partes se formalizarn en un acuerdo de nivel operativo (OLA).
El proceso de gestin de suministradores recibe los requisitos a cumplir, para que

los contratos de soporte (UC) permitan a TI cumplir con los SLA.
La relacin con todos los procesos y funciones de TI anteriormente descritos per-
mitir al proceso de gestin de nivel de servicio desarrollar su labor de definir y
acordar los SLA necesarios para dar cobertura a las demandas del negocio. Esta
relacin tambin es clave en la faceta proactiva de este proceso, para analizar y esta-
blecer planes de mejora de los servicios.
Mtricas del proceso

Para poder gestionar el proceso y sus objetivos, es necesario establecer las medidas
que permitirn evaluar el funcionamiento y los resultados del proceso de gestin
de nivel de servicio.
La medicin del proceso ser necesaria para su control, redundando en una gestin
ms adecuada.
Mediante el control del proceso se podr evaluar su funcionamiento y se estar en
disposicin de tomar acciones correctivas y proactivas de mejora, al objeto de
hacerlo ms eficiente, eficaz y adaptable (optimizacin).
Para llevar a cabo el control del proceso se establecern indicadores que ayuden a
medir objetivamente el funcionamiento y la evolucin del proceso. A continuacin
se incluye una seleccin de indicadores que facilitan esta labor:
Nmero o porcentaje de los servicios cubiertos con SLA, til en etapas de
transformacin.
Nmero o porcentaje de SLA sin contratos de soporte UC y sin acuerdos
de nivel operativo OLA, que los respalden.
Nmero o porcentaje de SLA monitorizados y de los cuales se emiten infor-
mes peridicos.
Nmero o porcentaje de acuerdos de nivel de servicio revisados en los plazos
planificados y con su correspondiente documentacin actualizada.
Nmero o porcentaje de SLA, OLA o UC que estn fuera de su fecha de
cobertura.
Nmero y gravedad de las interrupciones de servicio.
Porcentaje de las interrupciones de servicio tratadas y analizadas.
Porcentaje de cumplimiento de los acuerdos de nivel de servicio y su evolu-

cin durante un periodo.
Tendencia de la reduccin de roturas de SLA causadas por contratos de
soporte UC (mejorando o renegociando contratos).
Tendencia de la reduccin de roturas de SLA causadas por acuerdos de nivel
operativo OLA.
En el grfico de la figura 6.1.17 se muestra un resumen de los indicadores ms rele-

vantes para este proceso seleccionados por un grupo de trabajo de itSMF Espaa.
Mtricas principales del proceso
Fuente: itSMF Espaa.
Figura 6.1.17. Mtricas para este proceso del Modelo Abreviado de Mtricas
de itSMF Espaa
Roles participantes en la gestin del proceso

Como en el resto de los procesos, los roles intervinientes en la gestin de nivel de
servicio se estructuran en los roles propios del proceso y los roles ajenos al proceso
(el gestor del nivel de servicio).
Responsable del proceso de gestin de nivel de servicio. Es el responsable
ltimo del funcionamiento del proceso y de los cumplimientos de los niveles
de servicio. Coordina a todos los gestores de nivel de servicio. Reporta al res-
ponsable de la gestin del servicio.
Gestores de nivel de servicio. Son los responsables de la creacin y gestin
de los acuerdos de nivel de servicio, coordinan a las distintas reas y procesos
de la organizacin de TI para asegurar la disponibilidad y calidad de los SLA
firmados con los clientes. Asimismo, es el responsable de que el catlogo de
servicios est en todo momento actualizado y disponible.
Administrador y soporte del proceso de gestin de nivel de servicio. Es res-
ponsable de la administracin tcnica (sistemas y herramientas) del proceso.
Se ocupa de proporcionar y mantener los medios tcnicos necesarios para
una gestin eficiente del proceso ayudando al gestor del nivel de servicio en
el control de toda la actividad.
Administrador del catlogo de servicios. Es el responsable del manteni-
miento del catlogo asegurando la definicin, mantenimiento, publicacin y
divulgacin de los servicios.
Los roles ajenos que son relevantes en este proceso son:

Los gestores del resto de procesos que se interrelacionan con la gestin de
nivel de servicio para acordar los niveles de servicio a comprometer en la pre-
paracin el SLA y, una vez operativo el servicio, para velar por su cumpli-
miento.
(process owner), define el proceso y se encarga de la mejora continua del
mismo. Todo ello, de una forma integrada con el modelo de gestin de TI
incorporado en el SGSTI.
En la figura 6.1.18 se muestra un esquema con los roles para este proceso.
Roles del proceso
Responsable de la
gestin del servicio
Responsable del
proceso SLM
Gestores del
nivel de servicio
Gestores de otros
procesos y reas TI
SGSTI
Administrador
catlogo de servicios Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Figura 6.1.18. Roles para el proceso de gestin de nivel de servicio
Resumen
El proceso de gestin de nivel de servicio es clave para cumplir con las expectativas
de los clientes de TI, manteniendo y mejorando la estabilidad de los servicios ya
que regula y controla toda la cadena de aseguramiento de los acuerdos de nivel de
servicio firmados con los clientes.
El proceso mantiene la calidad y fiabilidad de los servicios, velando, tanto por la
creacin de SLA fiables y acordes con las necesidades del negocio, como por el con-
trol y mejora reactiva/proactiva que permiten mejorar la calidad de la prestacin de
los servicios de TI. Este proceso trabaja en estrecha colaboracin con los procesos
y con las reas tcnicas.
Los principales elementos que componen el proceso son: el responsable del pro-
ceso, el catlogo de servicios, los SLA, los OLA, los UC y los programas de mejora
del servicio (SIP).
Beneficios
La mejora en la calidad y la reduccin de las interrupciones del servicio, que aporta
una efectiva gestin de nivel de servicio, permite la obtencin de ahorros econmi-
cos significativos. Por un lado, el cliente puede realizar sus funciones de negocio de
forma predecible y minimizar el impacto negativo en sus actividades mediante el
cumplimiento de los acuerdos de servicio establecidos y la planificacin de paradas
de mantenimiento del servicio, y por otro, la organizacin TI gastar mucho menos
tiempo y esfuerzo al tener menos incumplimientos de SLA que resolver.
Entre los beneficios de la gestin de nivel de servicio se pueden destacar:
La prestacin del servicio TI se disea para satisfacer los requisitos del servi-
cio de los clientes.
Permite mejorar las relaciones con los clientes.
Las dos partes firmantes del SLA tienen una visin clara de sus funciones y
responsabilidades, evitando posibles omisiones o malentendidos.
Se tienen objetivos especficos y acordados, con los que se puede comparar y
medir la calidad del servicio; si no aspira a nada, probablemente eso sea lo
que consiga.
Permite centrar el esfuerzo en TI en los servicios clave para el negocio.
La monitorizacin de los servicios facilita la identificacin de reas de debili-
dad, permitiendo emprender las acciones resolutivas que sean necesarias,
mejorando as la calidad de los futuros servicios.
El seguimiento realizado por este proceso permite identificar fallos en los
servicios motivados por acciones de los usuarios, pudiendo definir acciones
de mejora, como por ejemplo, la formacin.
La actividad de gestin de nivel de servicio refuerza la gestin y relacin con
las reas internas de TI y con los suministradores externos gracias a su inte-
gracin en la cadena de aseguramiento de los SLA de los clientes, todos tie-
nen un objetivo comn.
Los SLA constituyen el elemento bsico para poder realizar la facturacin de
los servicios TI a los clientes segn los niveles de servicio requeridos.
Cul es la estructura del catlogo de servicios de su organizacin
deTI?
Cul es la estructura de los SLA de su organizacin?
Cmo estn estructuradas internamente las unidades o grupos de su
departamento de TI de cara a la realizacin de OLA?
1
6.2. Generacin de informes del servicio 237
6.2. Generacin de informes del servicio
Figura 6.2.1. Esquema general del proceso de generacin de informes de servicio
Cadas de los servicios, cambios en los servidores, compras de equipamiento nuevo,

miles de peticiones de los usuarios, etc. La vida cotidiana en las calderas de la ges-
tin de las tecnologas de la informacin est llena, quizs demasiado, de actividad.
La sobreocupacin de la organizacin de TI atendiendo el da a da lleva a pensar
que nicamente con aguantar el ritmo de trabajo es suficiente, pero no es as, es
necesario, adems, mantener un flujo constante de comunicacin e informacin
con toda la organizacin sobre los logros que se consiguen y el funcionamiento de
los servicios. Sin esta comunicacin, la insatisfaccin de las reas de negocio con TI
est garantizada (vase la figura 6.2.1).
Una buena disciplina en la generacin de informes y el mantenimiento de una
comunicacin constante, ayudar a la comprensin mutua. La primera frase que
se escucha al acercarse al mundo de las mtricas y de la calidad es todo lo que no se
puede medir no existe y aunque es un poco drstica, pone claramente el foco en la
necesidad de medir los mltiples componentes y resultados de la actividad de TI.
El mundo tcnico tiende a ningunear la actividad de generacin de mtricas e
informes, viendo esta tarea como una sobrecarga burocrtica a su trabajo diario.
En el mbito de las Normas ISO/IEC 20000 se aporta una solucin prctica para
intentar atajar este mal endmico, centralizando toda la actividad de generacin de

informes en un proceso. ste recopila las necesidades de los clientes del resto
de procesos y, en general, de toda la organizacin de TI, para impulsar la definicin y
creacin de todos los informes necesarios.
Por si fuera poco, las carencias no slo provienen de las capas tcnicas. Con fre-
cuencia es la propia direccin la que primeramente solicita los informes para poste-
riormente no utilizarlos en la gestin diaria y en la toma de decisiones. A nivel
directivo, las decisiones muchas veces se toman por intuicin, derivadas de una cri-
sis o por visin estratgica, ignorndose reiteradamente la valiosa informacin
aportada por los informes.
Si bien la informacin es til para la toma de decisiones, tambin debe notarse cla-
ramente su uso y toda la organizacin lo debe percibir. De esta forma, los comits
regulares de direccin de TI deberan comenzar con un anlisis de los principales
indicadores, para continuar con el estado de los principales proyectos y el avance
de las iniciativas estratgicas de transformacin. A partir de este momento, conti-
nuar con los incidentes ms graves y con el resto de la agenda. En este escenario, la
informacin aporta valor y es rentable el esfuerzo de producirla.
En las empresas que han alcanzado la excelencia en su gestin, las decisiones se
toman con base en las mtricas y los informes, respaldando la visin y la intuicin
de la direccin. As, unas decisiones basadas en indicadores podran ser:
Se desencadena una iniciativa de reduccin de costes porque el ratio de coste
de TI por usuario es ms alto que el benchmarking realizado contra el mer-
cado. Tambin se respalda esta iniciativa porque el ratio de coste global de
TI en relacin a la facturacin de la empresa (ITR, IT Spending per unit of
Revenue) es mayor que el de empresas equivalentes o del mismo segmento.
Se lanza un proyecto de transformacin de arquitectura y plataforma tecno-
lgica, porque la tasa de incidentes por usuario es alta como consecuencia de
una infraestructura demasiado inestable.
Se refuerza el equipo de gestin del problema debido a que, en el ltimo
semestre, el 30% de las incidencias producidas son repetitivas y originadas
por las mismas causas.
Se crea una dotacin presupuestaria para una iniciativa de renovacin de la
planta de ordenadores PC, porque el indicador de obsolescencia del parque
de ordenadores personales es alto y, como consecuencia, la productividad del
empleado habr ido disminuyendo.
Se lanza una campaa de comunicacin al ver que ha descendido el indica-
dor que mide la satisfaccin de los clientes y usuarios con TI.
Se implanta una poltica de teletrabajo para flexibilizar los horarios, al resul-

tar muy baja la satisfaccin del empleado de TI en la ltima encuesta anual.
En la figura 6.2.2 se presenta una visin introductoria al proceso de generacin de

informes del servicio.
Proceso de generacin de Qu aporta:

informes del servicio Al centralizar en un proceso la
generacin de informes, se obtiene
una visin homognea sobre TI.
Definicin: Se asegura que todos los informes se
Proceso que centraliza la generacin adecuen a las necesidades de TI.
de todos los informes de TI con el Se cubren todas las necesidades
fin de que sean homogneos, tiles y de informar y comunicar.
entendibles por los destinatarios. La informacin es fiable.
La informacin es claramente
entendible por los destinatarios.
Objetivo:
Centraliza todos los indicadores y
Generar en plazo los informes mediciones de TI.
acordados, ables y precisos, para Aumenta la productividad en la
informar a la toma de decisiones y generacin de informes.
para una comunicacin ecaz.
Hay un responsable que vela por la
generacin de informes en plazo,
forma y calidad.
Figura 6.2.2. Introduccin al proceso de generacin de informes del servicio
Para que la gestin del servicio aporte valor real a la organizacin de TI y al nego-
cio, debe disponer en tiempo y con calidad de la informacin que permita la
correcta toma de decisiones. La centralizacin de todos los informes en un nico
punto aporta grandes ventajas en la realizacin de esta labor incomprendida, pues
responsabiliza a un proceso de la definicin general de las polticas de informes y
de su generacin. Los informes deben ser fiables, precisos y entregados a tiempo.
Los informes de TI destinados al negocio deben contener medidas significativas y
entendibles por l que permitan ayudarle a alcanzar sus objetivos estratgicos. La
precisin y fiabilidad de los valores aportados son clave en la relacin con el cliente.
Asimismo, la puntualidad en la entrega de los informes de nivel de servicio, segn
lo comprometido en los SLA, junto con los aspectos reseados anteriormente,
aportan confianza al cliente en la relacin.
Los indicadores de disponibilidad, rendimiento y capacidad son, sin lugar a dudas,

los ms importantes para la operativa de TI, y sus valores permiten una monitori-
zacin de la calidad del servicio. Pero no son los nicos. Tambin hay otros muy
importantes: la alineacin con los estndares, el cumplimiento de la legislacin, la
seguridad, la eficiencia operativa, etc.
Los datos recogidos deben permitir la generacin de informes reactivos, proactivos
y el anlisis de las tendencias principales.
La frecuencia en la obtencin de la informacin tambin debe adecuarse a su utili-
zacin, en unos casos se tiene que proporcionar en el rabioso tiempo real (instant-
neo o inmediato), mientras que en otros slo se necesitar con periodicidad men-
sual o anual.
Es recomendable que el contenido de los informes refleje el resultado de la compa-
racin entre los valores de los indicadores obtenidos y los valores objetivo o umbra-
les de referencia comprometidos. Aunque, en la etapa de implementacin de un
indicador, lo habitual es realizar unas mediciones para conocer lo que est pasando
sin tener predefinido un valor objetivo de referencia.
Los informes pueden estar destinados al negocio o bien a la propia gestin interna.
En el primer caso se cuidar de mantener el idioma y visin del negocio. En los
informes internos, primar la informacin tcnica y las tendencias evolutivas.
Los informes forman parte del conocimiento de la organizacin. Por ello se debe-
rn incorporar el sistema de informacin y documentacin estructurado en TI, sis-
tema que se convertir en el instrumento online de trabajo para toda la organiza-
cin.
La disciplina de generacin de informes debe tener en cuenta cuatro principios
bsicos, mostrados en la figura 6.2.3.
La fiabilidad de la informacin contenida en los informes es uno de los factores
ms esenciales, en su generacin se debe velar especialmente por la calidad de los
datos mostrados. Sin una informacin fiable, no tendr utilidad alguna la actividad
de generarlos.
Por otra parte, es importante que los informes sean claros y fcilmente entendibles
por sus destinatarios. La estructura a contemplar en los informes muy tcnicos es
diferente a los informes orientados al negocio o la direccin. Cada uno de ellos
debe adaptarse a la cultura y los hbitos de los destinatarios.
En todos los informes se debe mantener una lnea de estilo o lnea editorial que
facilite su comprensin por los lectores. Los grficos, escalas, tamaos, colores,
etc., deben mantener una coherencia entre unos informes y otros, para que se pue-
dan interpretar ms fcilmente.
Figura 6.2.3. Principios bsicos de la generacin de informes
Los informes deben mantener una continuidad a lo largo del tiempo, represen-
tando conceptos similares y su evolucin histrica. Para ello, disponer de un repo-
sitorio con todos los indicadores y sus mediciones ser una de las primeras activi-
dades que se deben realizar. Para la creacin de este repositorio o base de datos hay
varias alternativas, como utilizar la solucin que habitualmente incorporan las
herramientas de gestin del servicio o como crear uno nuevo utilizando las herra-
mientas habituales de anlisis de datos e inteligencia de negocio (data warehouse,
data mart, extraccin de datos, etc.). En organizaciones pequeas se puede empe-
zar con una simple hoja de clculo.
Es importante que los informes reflejen la evolucin histrica de los indicadores
que contienen, pues en la gestin del servicio de TI son tan esenciales las tenden-
cias como los valores puntuales de un perodo.
Los informes deben entregarse a tiempo, en el momento en que se necesiten, para
conocer la situacin o para tomar decisiones. Para conseguirlo es necesario dispo-
ner de las herramientas adecuadas que faciliten la laboriosa tarea de su confeccin.
El cumplimiento sistemtico en las fechas de entrega de los informes permitir que
las decisiones se tomen a tiempo y marcar una pauta rtmica de trabajo en toda la
organizacin.
En la figura 6.2.4 se muestran los componentes principales del proceso.
COMPONENTES DE GENERACIN DE INFORMES
Hechos
ocurridos Niveles
de servicio
Cuadros
de mando
Poltica Diseo de
de informes informes Realizacin Informes
de informes
KGI
Panel de
control
KPI
Indicadores
Arquitectura
de mtricas
Monitorizacin
Base de datos de
indicadores y mediciones
Figura 6.2.4. Componentes principales del proceso de generacin de informes
Arquitectura de mtricas. Es un documento que analiza y estructura por niveles todos

los indicadores necesarios para la gestin de TI. Para cada indicador se define una ficha
de detalle. En organizaciones maduras suele contener ms de 200 indicadores.
Base de datos de indicadores y mediciones. Es una base de datos que contiene la

definicin de cada uno de los indicadores (fichas) y el histrico de las mediciones de
cada uno de los indicadores. Es la base fundamental para la generacin de informes.
Cuadro de mando integral (BSC, Balanced Score Card). Trmino difundido por
Kaplan y Norton para mostrar el estado de una empresa en base a objetivos e indi-
cadores agrupados en cuatro perspectivas: econmica, cliente, interna y crecimiento.
Cuadro de mando de TI. Conjunto de indicadores que muestran una visin glo-
bal del estado de TI. Contiene indicadores globales. Resume en un informe los
indicadores ms relevantes sin respetar las cuatro perspectivas clsicas de Kaplan y
Norton.
Dato, informacin y conocimiento. Un dato es un conjunto discreto, de valores

objetivos sobre un hecho real. Un dato no dice nada sobre el porqu de las cosas y,
por s mismo, tiene poca o ninguna relevancia o propsito.
La informacin es un mensaje, normalmente bajo la forma de un documento o
algn tipo de comunicacin audible o visible. A diferencia de los datos, la informa-
cin tiene significado (relevancia y propsito). No slo puede formar potencial-
mente al que la recibe, sino que est organizada para algn propsito. Los datos se
convierten en informacin cuando su creador les aade significado. Transforma-
mos datos en informacin aadindoles valor en varios sentidos.
El conocimiento es una mezcla de experiencia, valores, informacin y saber hacer
que sirve como marco para la incorporacin de nuevas experiencias e informacin,
y es til para la accin. Se origina y aplica en la mente de los conocedores. En las
organizaciones, con frecuencia no slo se encuentra dentro de documentos o alma-
cenes de datos, sino que tambin esta en rutinas organizativas, procesos, prcticas,
y normas.
Factor crtico de xito (CSF, Critical Success Factor). Trmino utilizado en el

mbito de ITIL para definir un aspecto crtico o esencial a tener en cuenta para
el xito en un proceso.
Hechos ocurridos en el perodo. Sucesos ocurridos, actividades realizadas y

hechos relevantes a tener en cuenta en los informes.
Histrico del servicio. Representacin de los valores de los indicadores de un

servicio y comprende generalmente uno o ms aos si bien el perodo de retencin
depender de la naturaleza del indicador o mtrica considerada.
Indicador o mtrica. Son datos. Los trminos de indicador y mtrica se utilizan

normalmente como sinnimos y representan un tipo de dato utilizado para medir
una caracterstica de TI. Los indicadores se definen en una ficha y se miden.
Indicador objetivo (KGI, Key Goal Indicator). Indicador que muestra una caracte-
rstica clave o general. Trmino utilizado en COBIT. Se utiliza para determinar los
indicadores ms importantes de TI (por ejemplo, el tiempo que se tarda en crear
un nuevo servicio de TI o time-to-market). Dado que la organizacin de TI suele
estar dividida por lo menos en tres reas (desarrollo, sistemas o centro de proceso
de datos y microinformtica o puesto de trabajo), los KGI se agrupan a su vez en:
KGI-TI. Indicador objetivo general o comn a todo el rea de TI o indica-
dor de gobierno de las TI.
KGI-CPD. Indicador objetivo del rea de explotacin de sistemas o del cen-
tro de proceso de datos (CPD).
KGI-PT. Indicador objetivo del rea del puesto de trabajo (PT) formado por
microinformtica ms las redes.
KGI-DES. Indicador objetivo del rea de desarrollo de aplicaciones.
Indicador de rendimiento (KPI, Key Performance Indicator). Indicador que mide

el desempeo o rendimiento de un proceso, de un proyecto, etc. (por ejemplo, el
nmero de problemas abiertos). Es un indicador ms de detalle que el KGI.
Informe. Es un documento impreso o electrnico que contiene indicadores, anli-

sis e informacin sobre un mbito determinado de TI.
Informe del servicio. Es un informe sobre los servicios que presta TI indicando
el grado de cumplimiento de los niveles de servicio, los hechos ms relevantes en el
perodo con relacin al servicio (incidentes, problemas, evolucin, etc.).
Medida. Es el valor medido en un instante determinado de un indicador o mtrica.

Las medidas de un indicador se deben almacenar en un histrico para su trata-
miento posterior. En este proceso medida y medicin se utilizan como sinnimos.
Niveles de servicio. Son los valores mnimos o mximos de los indicadores pacta-
dos con el cliente que deben cumplir los servicios de TI prestados.
Polticas de informes. Documento que establece los principios que deben cumplir
los informes de una organizacin.

En ISO/IEC 20000 se centralizan en este proceso las actividades de generacin de
todo tipo de informes con el fin de aportar una visin conjunta de la informacin y
de controlar su calidad y su generacin a tiempo. Esta centralizacin tiene todo su
sentido, ya que los informes se sustentan en gran parte en los indicadores, que
deben definirse y recopilarse bajo una visin comn.
En este apartado se desarrollan ampliamente los algo escuetos requisitos plantea-

dos en las Normas ISO/IEC 20000, recomendndose un conjunto de actividades
necesarias para el xito del proceso. Por tanto, estas actividades y su desarrollo van
ms all de los requisitos contenidos en estas normas.
La gestin de informes debe trabajar completamente coordinada con los responsa-
bles de los procesos y de las grandes reas de TI, pues necesita de su participacin
para conocer la actividad diaria que realizan y conseguir que stas realicen un anli-
sis adecuado de los valores obtenidos. Las interacciones y funcionalidades de gene-
racin de informes de servicio se resumen en la figura 6.2.5.
Desencadenantes 3 Definicin de la poltica de Salidas principales:

del proceso: informes. Cuadros de mando.
Llegada de la fecha 3 Definicin de la arquitectura Informes del servicio.
preparacin del de mtricas.
Panel de control.
informe. 3 Diseo de los informes tipo.
Otro tipo de informes.
Peticin expresa de la 3 Implementacin de
direccin. Polticas de informes.
herramientas: monitorizacin,
recogida y reporting.
Entradas de soporte: Salidas secundarias:
3 Captura de indicadores.
Acuerdos de nivel de Base de datos de
servicio existentes. 3 Generacin de informes. indicadores y mediciones
3 Distribucin de informes. actualizada.
Estrategias del negocio y
de TI. 3 Supervisin funcionamiento Arquitectura de
del proceso. Mejora del mtricas.
Datos de benchmarking
del mercado. propio proceso. Informes tipo o
plantillas.
Alarmas de umbrales
sobrepasados.
Figura 6.2.5. Entradas, actividades y salidas del proceso
Las principales entradas que desencadenan el proceso son la proximidad de la fecha

en la que en informe debe estar publicado (semanal, mensual, trimestral o anual)
que activa las acciones para la confeccin del informe; y una peticin expresa de
la direccin de TI sobre la necesidad de disponer de un informe determinado
(previsto o nuevo).
Las entradas de soporte que utiliza el proceso son los acuerdos de nivel de servicio,
que informan sobre los umbrales que se utilizarn en los informes; las estrategias
del negocio y de TI, para la confeccin de la arquitectura de mtricas y el diseo de
los informes tipo; datos externos de benchmarking del mercado con ratios compara-
tivos, con el fin de comparar los valores de los indicadores internos con los externos.
Las salidas principales del proceso son: los cuadros de mando actualizados necesa-
rios (global de TI, del CPD, del Puesto, de Desarrollo, etc.); los informes del servi-
cio prestado; el panel de control de TI; otros tipos de informes sobre acciones, pro-
yectos, iniciativas, etc.; las polticas de informes generadas que marcan las
directrices del proceso.
Como salidas secundarias del proceso destacan: la base de datos de indicadores y
mediciones actualizada, el repositorio generado por el proceso que almacena los
datos necesarios para la confeccin de los informes; la propia arquitectura de mtri-
cas creada y actualizada; las diversas plantillas que conforman los informes tipo; las
alertas generadas por haberse sobrepasado los umbrales de nivel de servicio, etc.
Las actividades del proceso son:
Definicin de la poltica de informes. En la que se define el alcance del proceso,
las responsabilidades sobre los datos y los informes, su difusin, etc.
Definicin de la arquitectura de mtricas. Realizada partiendo de la estrategia

del negocio y de la estrategia de TI, que define un conjunto de indicadores estruc-
turados que son la base para los informes.
Diseo de los informes tipo. En una organizacin de TI eficiente, los informes se

deben predefinir de tal forma que se diseen una vez y se ejecuten en serie. La
informacin contenida en todos los informes debe mantener un estilo homogneo
para que sean ms sencillos de entender. Como resultado de esta actividad se obtie-
nen las plantillas de los diversos tipos de informes a utilizar, adaptados al destinata-
rio, el medio de difusin y la frecuencia.
Implementacin de las herramientas. La generacin de informes se inicia con la

monitorizacin que realiza la captura de los indicadores y los almacenan en sus
archivos especficos (por ejemplo, archivos de log), que luego hay que recoger e
importar en la base de datos de mediciones. Por ltimo, existe un conjunto de fun-
cionalidades de reporting que permiten generar informes bajo demanda. Se deben
definir y desarrollar los sistemas para la captura de informacin y su correspon-
diente correlacin para obtener las medias adecuadas para la generacin de infor-
mes. En este escenario las herramientas juegan un papel fundamental para facilitar
el trabajo y evitar errores. Las herramientas comprenden:
Las consolas de monitorizacin.

La captura de informacin en la base de datos central.
La generacin de informes.
Navegacin desde una visin del servicio por los elementos que lo compo-
nen, conociendo su estado en tiempo real.
La generacin y publicacin de cuadros de mando y paneles de control.
Hay que sealar que en numerosos casos, la implementacin de stas y otras herra-
mientas requeridas por el proceso de generacin de informes de servicio se limitar
a establecer las interfaces con las herramientas ya implementadas dentro de otros
procesos (un caso general es la integracin con las herramientas de monitorizacin
y operacin).
Captura de Indicadores. En esta actividad se realiza la recopilacin de toda la

informacin disponible en forma de indicadores y mtricas durante el periodo de
reporte. Esta informacin procede fundamentalmente de la actividad de los proce-
sos de gestin de servicio:
Gestin de nivel de servicio.
Gestin de incidencias (asociados a un SLA).
Gestin de la capacidad (disminucin de la carga de trabajo).
Gestin de la disponibilidad (mejora de la disponibilidad y fiabilidad).
Gestin financiera (tarifas aplicables y coste real de los servicios).
Etc.
Generacin de informes. En esta actividad se generan los informes con los resul-
tados de los indicadores o mtricas obtenidas. Los informes deben ser tiles y no
unos meros portadores de datos. Por ello, adems de los datos, deben incorporar
anlisis de la informacin, revisin de los resultados obtenidos, descripcin de los
hechos relevantes en el perodo, etc. (aunque estos anlisis, en muchos casos, este
proceso slo se encargue de hacer que otros lo realicen). Como resultado de esta
actividad y, en funcin del destinatario y la periodicidad establecida, se generan los
informes del servicio. Tambin es clave que los informes reflejen el resultado de la
comparacin entre los valores de indicadores obtenidos y los valores objetivo o
umbrales de referencia.
La generacin de informes toma como punto de partida los datos ya recopilados
en la base de datos de indicadores y mediciones, y de los informes tipo, para la
generacin de los informes. En una primera fase, el proceso genera los informes en
modo borrador, para que sean completados y comentados por cada uno de los pro-
cesos o reas involucradas. Por ello, esta actividad debe perseguir a los responsables
para que revisen y complementen con informacin estos borradores.
Distribucin de informes. Una vez generados los informes se deben distribuir a

los destinatarios previstos. La forma ms sencilla o inmediata de realizar la distri-
bucin es subir el informe a una seccin de informes en el portal web de TI y
comunicar a los destinatarios por correo electrnico su disponibilidad, si bien el
mecanismo que se debe utilizar vendr marcado en gran medida por la criticidad
de la informacin. En el caso de tratarse de informes a las reas clientes o a la direc-
cin, ser conveniente mantener una reunin o audioconferencia para explicarlos y
revisarlos en detalle. En estas revisiones convendra contar con la presencia de los
responsables de los procesos tratados en el informe, y si es a los clientes, tambin
del gestor de relaciones con el negocio (gestor del cliente).
Supervisin del funcionamiento del proceso y mejora del mismo. Al igual que
en resto de procesos, el responsable del proceso debe supervisar la eficacia del pro-
ceso, la calidad de los datos contenidos y la entrega a tiempo de los informes.
Una de las facetas importantes de esta actividad es comprobar y conseguir que los
informes sean utilizados por sus destinatarios y que cumplan su misin de infor-
macin, seguimiento o ayuda a la toma de decisiones para los que fueron creados.
Es tambin responsabilidad de esta actividad impulsar en los otros procesos la
generacin de los planes de mejora derivados del anlisis de los informes. Un ejem-
plo claro de esto es el proceso de gestin de nivel de servicio, que vela por que se
subsanen de forma inmediata las roturas de niveles de servicio detectadas en los
informes, desarrollando las iniciativas de mejora. Adems, dado que los informes
llevan tambin integrada la tendencia de evolucin de los indicadores, se podr
detectar anticipadamente el riesgo de incumplimiento de los niveles de servicio
para adoptar las medidas proactivas necesarias.
Todas las mejoras detectadas se incorporarn al plan general de mejora de TI, sin
que por ello, se dejen de ejecutar las acciones correctoras inmediatas.
Poltica de la generacin de informes de servicio

En la Norma ISO/IEC 20000-2 se establecen recomendaciones para la definicin
de una poltica de generacin de los informes, establecindose que se acuerden y
registren los requisitos para la generacin de informes.
UNE-ISO/IEC 20000-2
Poltica
Los requisitos para la generacin de infor- tradores subcontratados por stos, los
mes para clientes y para gestin interna informes deberan reflejar las relacio-
se deberan acordar y ser registrados. nes entre ellos. Por ejemplo, un sumi-
nistrador principal debera informar
La supervisin del servicio y la genera-
sobre la totalidad del servicio que
cin de informes abarcan todos los
presta, incluyendo cualquier servicio
aspectos medibles del servicio, propor-
realizado por un tercero y que forme
cionando datos actuales e histricos.
parte del que el suministrador principal
Cuando existan mltiples proveedores, gestiona como parte del servicio al
suministradores principales y suminis- cliente.
Las fuentes de informacin y de conocimiento en TI

Antes de continuar con los indicadores y los informes conviene reflexionar breve-
mente sobre los diversos tipos de informacin y conocimiento existentes en TI.
Pues no todo el conocimiento de TI se obtiene de los indicadores, ni toda la infor-
macin para la toma de decisiones se incluye en los informes del servicio. Estas dis-
tinciones son importantes para evitar sobrecargar los informes con indicadores,
cuando la informacin se debe obtener de otras fuentes. En general, el conoci-
miento en TI proviene de:
Informacin no escrita: conocimiento histrico, conversaciones informales,
temas tratados en reuniones, etc.
Informacin descriptiva textual: arquitecturas, inventarios, informes,
manuales, procedimientos, comunicados, correo electrnico, etc.
Informacin de seguimiento de la actividad: planificaciones, informes de
avance, cumplimiento de hitos, etc.
Informacin sobre el servicio: informes, notificaciones y escalados, actas.
Informacin creada ad-hoc para una necesidad: auditoras, informes de con-
sultoras, planes de evolucin, tendencias mercado, benchmarking, etc.
Informacin sobre volumetras de TI: estadsticas diversas, volmenes inven-
tariados, volmenes de actividad y de planta, etc.
Informacin en tiempo real: proveniente de la monitorizacin y de los even-
tos surgidos.
Mtricas e indicadores, cuadros de mando.

Conocimiento especialista: de la tecnologa en general, de unas instalaciones
concretas, etc.
La tipificacin del conocimiento utilizado en TI permitir tener una visin panor-

mica ms clara que discierna entre conocimiento, informacin y mtricas. En la
figura 6.2.6 se muestra una tipificacin de la informacin en dos ejes que permiten
clasificarla entre su uso para el gobierno (estrategia y decisin) o la gestin (ejecu-
cin y seguimiento), junto a una visin sobre si la informacin que contiene es des-
criptiva (cualitativa), o ms bien est basada en cifras (cuantitativa).
Cuadros
Tendencias de mando
Benchmarking
Gobierno
Informe mensual
ejecutivo
Verbal
Texto mail Informes del servicio
Mtricas servicio
Gestin
Alertas
Inventarios
Documentacin Monitorizacin
Cualitativa Cuantitativa
Fuente: Telefnica.
Figura 6.2.6. Tipificacin del conocimiento acerca de TI

Por tanto, para la toma de decisiones y para el conocimiento de TI no es suficiente

con los indicadores, ni con los informes del servicio. Se debe recurrir tambin a
otro tipo de informacin, interna y externa. Por ello, en la definicin de los indica-
dores necesarios, se debe tener presente este hecho y no intentar cubrir en base a
indicadores todo el conocimiento sobre TI.
Los indicadores son una parte esencial de los informes

Los informes en TI versan sobre la actividad propia y los resultados de los servicios
ofrecidos a los clientes. Por ello, los informes se sustentan en indicadores y mtri-
cas representados en diversos tipos de grficos.
Los indicadores o las mtricas son el ncleo esencial de los informes. El objetivo de
los indicadores es aportar una visin del estado de TI y del cumplimiento de los
objetivos marcados. No obstante, de acuerdo con lo descrito en el punto anterior,
hay que considerar que los indicadores son un instrumento parcial que aporta una
idea aproximada de la realidad y, adems, pueden ser manipulados en funcin de
los resultados que interese presentar.
Las mtricas y los informes se suelen agrupar en niveles o capas segn el pblico
destinatario de los mismos. De forma general se estructuran en estratgicos, tcti-
cos u operativos (inspirado en COBIT). A continuacin se presenta una visin sim-
plificada de estos tres niveles:
Indicadores estratgicos. Contienen informacin para la toma de decisio-
nes de alto nivel. Dado que en organizaciones grandes, TI suele estar divi-
dida en diferentes reas (por ejemplo, desarrollo, centro de datos y puesto de
trabajo), se ha considerado til desglosar los indicadores e informes estrat-
gicos en dos: los globales con una visin conjunta de todo TI y los espec-
ficos de estas reas:
Estratgicos y globales de TI (KGI, Key Goal Indicator, de TI). Mues-
tran informacin general sobre TI y su desempeo. Estos indicadores for-
man parte del cuadro de mando general de TI. Estos indicadores sobre los
objetivos estn vinculados con el cuadro de mando general de la empresa
y se utilizan tambin para mostrar al negocio y a la direccin de la empresa
(CEO) los resultados de TI.
Ejemplos de KGI de TI pueden ser la disponibilidad de los servicios de
TI, el coste de TI por usuario, la madurez en la gestin de TI, el time-to-
market medio de cambios, el porcentaje de cambios en plazo o la satisfac-
cin de los clientes y usuarios con TI.
Estratgicos y por rea de TI (KGI de rea). Adems, tambin se suelen

definir los indicadores globales de un rea que son indicadores tambin de
alto nivel pero centrados en una de las grandes unidades o reas que sue-
len componer TI, como por ejemplo, desarrollo, puesto de trabajo, pro-
duccin del centro de datos, planificacin y control, etc. Componen un
cuadro de mando especfico de este rea y contribuyen al cuadro de mando
general de TI.
Indicadores tcticos o globales de proceso (KGI de proceso). Muestran

una informacin resumida del desempeo de cada proceso. Se suelen definir
entre 3 y 5 indicadores de objetivos por cada proceso. Estos indicadores los
utiliza el responsable del proceso para mostrar a la direccin de TI (CIO) la
contribucin de su proceso al xito de TI.
Ejemplos de KGI de proceso son: el porcentaje de incidentes resueltos en
plazo, los incidentes resueltos en primera lnea, el nmero de soluciones tem-
porales activas, el porcentaje de elementos de configuracin con actualizacin
automatizada, el porcentaje de objetivos de SLA incumplidos o los costes de
provisin por servicio.
Tambin debe haber otro tipo de indicadores de objetivos, ms all de los
procesos, por ejemplo, los indicadores de evolucin de los proyectos (tanto
de desarrollo, como de produccin), el avance de las iniciativas estratgicas de
transformacin de TI, los indicadores sobre el estado de la plataforma tecno-
lgica, sobre los RRHH, sobre el mbito financiero, etc.
Indicadores operativos o de rendimiento (KPI, Key Performance Indicator).

Indicador que muestra una faceta del comportamiento de una funcin o acti-
vidad de TI. Unos buenos indicadores de rendimiento (KPI) apalancarn la
obtencin de unos buenos indicadores globales o de objetivos (KGI), aunque
no hay una relacin matemtica entre ellos. Habitualmente suelen identifi-
carse entre 10 y 20 indicadores de rendimiento por proceso. Los principales
indicadores de rendimiento que se suelen medir son:
KPI de los procesos de TI: nmero total de incidentes, nmero de pro-
blemas abiertos, nmero de reuniones con clientes al mes, etc.
KPI de los proyectos de TI: proyectos en plazo, tiempo medio de desvia-
cin de los proyectos, etc.
KPI de las iniciativas estratgicas de TI: iniciativas en plazo, objetivos
alcanzados, etc.
KPI sobre la tecnologa, etc.
En la figura 6.2.7 se muestra esta estructura por capas y el mbito de cada indica-
dor (arquitectura de mtricas) y su relacin con los informes asociados.
Fuente: Telefnica.
Figura 6.2.7. Estructura por niveles de los indicadores y

su contribucin a los informes
En esta representacin de indicadores en cascada, no quiere decir que los indicado-

res superiores se calculen como una media ponderada de los indicadores inferiores.
Sencillamente muestran algn aspecto ms general (por ejemplo, la disponibilidad
de los servicios, el coste total por usuario, etc.).
Esta misma estructuracin en pirmide de tres capas se ha utilizado en este libro al
final de cada proceso para categorizar los indicadores recomendados de proceso.
Estos indicadores se recomiendan como parte de la arquitectura de mtricas. En la
figura 6.2.8 se muestra el esquema de rbitas alrededor de un proceso utilizado
para representar los indicadores.
Figura 6.2.8. Representacin en tres niveles de los indicadores de

los procesos utilizada en este libro
Metodologa para la definicin de una arquitectura

de mtricas
Con el fin de tener un control de la actividad, una organizacin de TI madura suele
identificar cerca de 200 indicadores. Adems, cada uno de estos indicadores es la
suma de un conjunto de mediciones, sobre los servicios, sobre los componentes,
etc., lo que conlleva la necesidad de automatizar con herramientas de monitoriza-
cin la captura de indicadores para poder gestionar el alto volumen de mediciones.
Por tanto, se necesita bastante estabilidad en el conjunto de indicadores que se van
a medir, que hay que conjugar con la necesidad cambiante de informacin precisa
sobre los objetivos definidos cada ao.
De cara a mantener una base estable de indicadores que pueda ser utilizada en los
informes y en la gestin de TI, es recomendable realizar un ejercicio de definicin
de un conjunto ms amplio de indicadores que se puedan necesitar en un docu-
mento, aqu denominado arquitectura de mtricas.
En la definicin de la arquitectura de mtricas se suele utilizar una mezcla de tcti-
cas iterativas hasta que se alcanza un mapa de indicadores, con los que se tendrn
controlados los servicios y el desempeo de TI. Las tcnicas principales utilizadas
en la definicin de esta arquitectura son:
Intuitiva. Cada miembro expresa de forma intuitiva las mtricas que consi-
dera ms relevantes. La visin intuitiva es muy importante y se utiliza varias
veces en el ciclo de definicin del mapa de indicadores.
En base a un mix de experiencias (propias y ajenas). La experiencia y la
historia de los indicadores internos y los aportados por organizaciones exter-
nas, conforman la base para la primera propuesta.
Seguimiento de COBIT al 100%. En este caso se toma el estndar COBIT
y de l se extraen indicadores.
Seguimiento de ITIL al 100%. Al igual que en el caso anterior, ITIL se
toma como la nica referencia.
Mix de modelos: ITIL + COBIT. Se toman los procesos ITIL como base, y
se buscan indicadores proporcionados tanto por ITIL como por COBIT, o
bien que resulten complementarios a efectos de completitud de la informacin.
Alineacin con el negocio. El eje conductor de todo el ejercicio de selec-
cin de indicadores se articula en torno a la estrategia del negocio, identifi-
cando los objetivos de la empresa y los objetivos definidos de TI.
De cara a abordar un proyecto de definicin de la arquitectura de mtricas de TI,

se recomienda utilizar una metodologa mixta que contemple de alguna forma las
tcnicas anteriores. En la figura 6.2.9 se muestra una metodologa para la defini-
cin de un mapa o una estructura de mtricas en TI.
Fuente: Quint Group y Telefnica.
Figura 6.2.9. Metodologa ejemplo para la creacin de una arquitectura de mtricas

En la Etapa I se identifica la estrategia de negocio existente y se establece una lista

de 4 5 objetivos de la empresa. Para ello, COBIT aporta cierta ayuda al tipificar
los diferentes objetivos corporativos (que marcarn los posibles objetivos de TI
dentro de la Etapa IV). En la figura 6.2.10 se muestra la tabla de objetivos de
TI de COBIT.
Perspectiva BSC
Tipos de objetivos de negocio en COBIT
del negocio
1 Expandir el porcentaje de mercado.
2 Aumentar el ingreso.
Perspectiva
3 Retorno sobre la inversin.
financiera
4 Optimizar el uso de recursos.
5 Administrar los riesgos del negocio.
6 Mejorar la orientacin y el servicio al cliente.

7 Ofrecer productos y servicios competitivos.
Perspectiva
8 Disponibilidad del servicio.
del cliente
9 Agilidad para responder a los requisitos cambiantes (tiempo para
comercializar).
10 Optimizacin del coste de prestacin del servicio.
11 Automatizar e integrar la cadena de valor empresarial.

12 Mejorar y mantener la funcionalidad del proceso de negocio.
13 Disminuir los costes de los procesos.
Perspectiva
14 Cumplimiento de leyes y reglamentos externos.
interna
15 Transparencia.
16 Cumplimiento de polticas internas.
17 Mejorar y mantener la productividad operativa del equipo de trabajo.
18 Innovacin del producto/negocio.

Perspectiva de
19 Obtener informacin confiable y til para la toma de decisiones
aprendizaje
estratgicas.
y crecimiento
20 Adquirir y mantener personal capacitado y motivado.
Fuente: COBIT 4.0.
Figura 6.2.10. Tabla de objetivos posibles del negocio tipificados en COBIT
Se pasa a la Etapa II, en la que se identifica la estrategia seguida por TI. Igualmente
el resultado es una lista corta de objetivos de TI. En la figura 6.2.11 se muestran
los objetivos tipificados en COBIT para los objetivos de TI.
ID. Objetivos TI COBIT
1 Responder a los requerimientos del negocio en alineacin con la estrategia del negocio.
2 Responder a los requerimientos de gobierno en lnea con el consejo de direccin.
3 Asegurar la satisfaccin de los usuarios finales con los servicios y niveles de servicio ofrecidos.
4 Optimizar el uso de la informacin.
5 Crear agilidad en TI.
6 Determinar cmo las necesidades funcionales y de control del negocio son traducidas en soluciones
automticas efectivas y eficientes.
7 Adquirir y mantener sistemas y aplicaciones estandarizados.
8 Adquirir y mantener infraestructuras de TI integradas y estandarizadas.
9 Adquirir y mantener tcnicas en TI que respondan a la estrategia de las TI.
10 Asegurar la mutua satisfaccin en la relacin con terceros.
11 Integrar perfectamente aplicaciones y soluciones tecnolgicas dentro de los procesos de negocio.
12 Asegurar la transparencia y comprensin de los costes, beneficios, estrategias, polticas y servicios de TI.
13 Asegurar el correcto uso y funcionamiento de las aplicaciones y soluciones tecnolgicas.
14 Responder por todos los activos de TI y protegerlos.
15 Optimizar las infraestructuras, recursos y capacidades de TI.
16 Reducir los defectos y adaptaciones en las entregas de soluciones y servicios.
17 Proteger la consecucin de los objetivos de TI.
18 Establecer con claridad el impacto en el negocio de los riesgos en los objetivos y recursos de TI.
19 Asegurar que la informacin crtica y confidencial est protegida de aquellos que no deben tener acceso
a ella.
20 Asegurar que las transacciones del negocio automatizadas y los intercambios de informacin pueden ser
realizadas correctamente.
21 Asegurar que los servicios e infraestructuras de TI pueden resistir y recuperarse correctamente de fallos
debidos a errores, ataques deliberados o desastres.
22 Asegurar el mnimo impacto en el negocio en caso de una interrupcin o cambio en los servicios de TI.
23 Comprobar que los servicios de TI estn disponibles cuando se les requiera.
24 Mejorar la relacin costes-eficiencia en las TI (rentabilidad) y su contribucin a los beneficios del negocio.
25 Entregar los proyectos en tiempo y presupuesto cumpliendo con los estndares de calidad.
26 Mantener la integridad de la informacin e infraestructura de proceso.
27 Asegurar la conformidad de TI con leyes y regulaciones.
28 Asegurar que TI da servicios de calidad con una demostrada eficiencia en costes, mejora continua y
preparacin para cambios futuros.
Fuente: COBIT 4.0.
Figura 6.2.11. Tabla de posibles objetivos de TI tipificados en COBIT
En la Etapa III, se realiza el cuadre entre las estrategias del negocio y las estrategias
de TI. Para ello se ponen ambas en una matriz y se identifica, para cada cruce, si la
estrategia de TI contribuye o no la estrategia de negocio dada. Con toda esta infor-
macin previa y con el conocimiento preciso del propio negocio y de cmo TI se
alinea con l, se aborda la seleccin de los objetivos de TI (Etapa IV).
A partir de este punto, para cada objetivo de TI se van identificando los indicado-
res de objetivos (KGI). Para cada indicador de objetivos se identifican los indica-
dores de rendimiento (KPI) que le apalancarn (Etapa V). En esta ltima etapa se
entra en un proceso iterativo en el que se relacionan en una tabla todos los indica-
dores posibles (coctelera de indicadores) seleccionados de diversas fuentes (las
mtricas actuales, las deducidas por un ejercicio intuitivo, las que propone ITIL,
las que propone COBIT, etc.). Con todas estas mtricas clasificadas, se estructuran
los tres niveles (KGI-TI, KGI-Proceso y KPI), o los establecidos por la arquitec-
tura de mtricas que hayamos creado, y se realiza una seleccin intuitiva de las que
ms contribuyen a los objetivos concretos de TI.
ETAPA I ETAPA II ETAPA II ETAPA IV ETAPA IV

Estrategia negocio Estrategia TI Alineacin Objetivos TI Seleccin de
TI Negocio las mtricas
Objetivos de negocio (ejemplo) KGI de TI Indicadores estratgicos
COBIT1. Expandir el porcentaje de mercado. Disponibilidad de los servicios TI.

COBIT4. Optimizar el uso de recursos. Coste TI por usuario.
Madurez en la gestin de TI.
COBIT6. Mejorar la orientacin y el servicio al cliente.
Time-to-market medio de cambios.
COBIT9. Agilidad para responder a los requisitos cambiantes.
Porcentaje de cambios en plazo.
COBIT18. Innovacin del producto/negocio. Satisfaccin de los clientes y usuarios con TI.
COBIT20. Adquirir y mantener personal capacitado y motivado.
KGI de proceso Indicadores tcticos

Objetivos de TI (ejemplo)
Porcentaje de incidentes resueltos en plazo.
COBIT3. Asegurar la satisfaccin de los usuarios finales con
Incidentes resueltos en primera lnea.
los servicios y niveles de servicio ofrecidos.
Nmero de soluciones temporales activas.
COBIT5. Crear agilidad en TI.
Porcentaje de CI con actualizacin automatizada.
COBIT8. Adquirir y mantener infraestructuras de TI integradas Porcentaje de objetivos de SLA incumplidos.
y estandarizadas.
Costes de provisin por servicio, etc.
COBIT15. Optimizar las infraestructuras, recursos y capacida-
des de TI.
COBIT21. Asegurar que los servicios e infraestructuras de TI KPI Indicadores operativos
pueden resistir y recuperarse. Nmero total de incidentes.
COBIT24. Mejorar la relacin costes-eficiencia en las TI y su Nmero de problemas abiertos.
contribucin a los beneficios del negocio. Nmero reuniones con clientes al mes.
COBIT25. Entregar los proyectos en tiempo y presupuesto Porcentaje de objetivos de SLA en riesgo.
cumpliendo con los estndares de calidad. Nmero medio de accesos per cpita a la CMDB.
NUEVOAlcanzar una excelencia en procesos TI. Nmero de cambios.
NUEVOMejorar productividad y satisfaccin del empleado. Porcentaje de cambios correctivos, etc.
Figura 6.2.12. Ejemplo de aplicacin de la metodologa para la obtencin

de una arquitectura de mtricas
En la figura 6.2.12 se muestra un ejemplo de los principales resultados de las Eta-

pas I, IV y V del proceso de definicin de una arquitectura de mtricas. Como
ejemplo, se han seleccionado los objetivos de negocio y de TI entre los objetivos
propuestos por COBIT, mientras que el resto de los indicadores de esta arquitec-
tura de mtricas ejemplo se han seleccionado a partir de los indicadores proporcio-
nados al final de cada proceso en este libro.
Como resultado de este ejercicio se obtiene una arquitectura o mapa de indicadores de
TI que cubre todos los niveles de necesidad: cuadro de mando global de TI, cuadros
de mando de cada rea de TI (de desarrollo, del produccin de sistemas o del centro de
datos, del puesto de trabajo o microinformtica, etc.), los indicadores de objetivos
de los procesos y los indicadores de rendimiento de cada uno de los procesos. En la
figura 6.2.13 se muestra el contenido del documento de una arquitectura de mtricas.
Como parte de la arquitectura de mtricas se debe definir de forma detallada cada
indicador, que servir como base para su obtencin y clculo. La ficha contiene el
nombre del indicador, el cdigo asignado al indicador, la versin del indicador
Estructura de una arquitectura de mtricas
3 Alcance de la arquitectura.
3 Antecedentes en la organizacin.
3 Estrategia de la empresa. Objetivos de negocio
identificados.
3 Estrategia de TI. Objetivos de TI identificadas.
3 Alineacin de TI con el negocio. Matriz cruce
objetivos negocio frente a TI.
3 Estructuracin en capas de la arquitectura.
3 Mtricas de objetivos de TI (KGI-TI).
3 Mtricas de objetivos del rea del centro de datos o
sistemas (KGI-CPD).
3 Mtricas de objetivos del puesto de trabajo (KGI-PT).
3 Mtricas globales de desarrollo (KGI-DES).
3 Fichas detalladas de los indicadores.
3 Etc.
Figura 6.2.13. ndice ejemplo de una arquitectura de mtricas

(pues su definicin y clculo puede variar en el tiempo), proceso al que pertenece,

los valores mximos y mnimos esperados, la tendencia del indicador (es decir, si
debe ir al alza o a la baja), su valor de referencia, etc. En la figura 6.2.14 se muestra
la ficha tpica para la definicin de un indicador.
Ficha de definicin de indicadores
Nombre indicador
Cdigo Proceso Valor mx.
Versin Periodicidad Valor mn.
Categora Ind/KPI/KGI Perspectiva (Norton y Kaplan) Valor mn. (Alza-Baja)
Descripcin del indicador
Especificacin
Justificacin
Audiencia Responsable
Restricciones Padres (KPIs o KGIs a los que contribuye)
Fuentes de informacin Hijos (KPIs o KGIs que lo soportan)
Unidad de medida Dominio Valor objetivo Valor de riesgo
Frmula
Fuente: Telefnica.
Figura 6.2.14. Ejemplo de ficha para la definicin de un indicador
La base de datos de indicadores y mediciones

Si la arquitectura de mtricas pone orden en la definicin de los indicadores a utili-
zar, se pone de manifiesto que es necesario organizar tambin todas las mediciones
realizadas. Para ello, se propone centralizar en una base de datos tanto la definicin
de los indicadores como el conjunto de mediciones que se realizan de cada uno de
ellos ya que, el volumen de estas mediciones, puede resultar muy elevado. En este
libro, al repositorio de mediciones se le ha denominado histrico de mediciones,
para resaltar el hecho de su utilidad para el anlisis de tendencias y de la necesidad

de conservar mediciones pasadas.
Alojar las fichas que definen los indicadores en una estructura de base de datos,
permitir incorporar fcilmente cualquier cambio en las fichas. Dado el alto volu-
men de indicadores gestionado en una organizacin madura, si las fichas alojan en
un archivo PowerPoint o Excel, incorporar un cambio en una ficha ser una autn-
tica tortura de edicin.
As, la base de datos de indicadores y mediciones est formada por dos unidades
lgicas diferenciadas y relacionadas:
La definicin de indicadores, que aloja las fichas que definen cada uno de los
indicadores de la arquitectura de mtricas.
El histrico de mediciones, que almacena todas las mediciones en su detalle,
necesarias para los clculos de los valores de los indicadores y para los anli-
sis de tendencias que se necesiten.
Una aproximacin al diseo de la base de datos de indicadores y mediciones se

muestra en la figura 6.2.15.
Diseo de la base de datos de indicadores y mediciones
Ficha de definicin de indicadores Histrico de mediciones

Cdigo indicador. Responsable. Cdigo indicador.
Nombre indicador. Padres. Versin indicador.
Versin. Hijos. Cdigo del elemento de
Categora. Audiencia. configuracin medido.
Proceso. Restricciones. Marca de tiempo: fecha-
Periodicidad. Fuentes de hora-minuto-segundo.
Perspectiva. informacin. Valor medido.
Valor mximo. Unidad de medida. Etc.
Valor mnimo. Dominio.
Tendencia. Valor objetivo.
Descripcin. Valor de riesgo.
Especificacin. Frmula.
Justificacin. Comentarios, etc.
Fuente: Telefnica.
Figura 6.2.15. Campos de la base de datos de indicadores y mediciones

Los informes en TI
Una vez definida la arquitectura de mtricas e implementada la captura automati-

zada de los indicadores, se empezar a nutrir la base de datos de indicadores y
mediciones. En un lapso corto de tiempo, se podrn analizar las tendencias y el hist-
rico de mediciones comenzar a engordar, para aportar toda su vala cuando
alcance la madurez al pasar un ao.
Una vez definidos y capturados los indicadores, la generacin de los informes es
una tarea sencilla, pero requiere de capacidad de anlisis, foco en la calidad de los
datos y una buena dosis de conocimientos estadsticos.
Despus de su definicin terica llega la vida real. Un indicador se calcula en base a
mltiples mediciones de los elementos de configuracin involucrados. Por ejem-
plo, el clculo de la disponibilidad, el indicador estrella y concepto sencillo de
entender por el negocio, se suele realizar en base a mediciones en intervalos (entre
1 y 5 minutos). Si la disponibilidad es de un elemento de infraestructura, las medi-
ciones las facilitar la herramienta de monitorizacin local, si la disponibilidad es
de un servicio, se medir mediante un agente de navegacin desde un puesto
cliente. Adems, habr que recoger la disponibilidad en la franja horaria de cada
servicio (no es lo mismo que un surtidor de gasolina est inoperativo de madru-
gada a que lo est en plena actividad laboral), identificar las paradas planificadas,
calcular si es posible el impacto en el negocio de la no disponibilidad, y recoger, si
es factible, las causas de la indisponibilidad, etc. As, el indicador ya medido y tra-
tado queda listo para ser incorporado en los diversos informes para su anlisis y
utilizacin por parte del solicitante o destinatario del informe. Debemos recordar
que todas estas actividades las realizar el proceso de gestin de la disponibilidad,
siguiendo las pautas y tutela del proceso de generacin de informes.
Dependiendo de la necesidad de la informacin a cubrir, los valores de un indica-
dor se presentan en un informe de diversas maneras:
El valor en el perodo. Representado en forma numrica el valor en el per-
odo de medicin, como porcentaje, plazo de tiempo, cantidad, etc.
Un semforo, indicando si se han cumplido o no los niveles de servicio espe-
rados en el intervalo de medicin. Representado, generalmente y por senci-
llez, en tres colores: rojo, naranja/amarillo y verde.
Su evolucin histrica a lo largo de das o meses. En este tipo de grfico se
muestra la tendencia del indicador. En la representacin grfica tambin
deberan aparecer los umbrales mnimo y mximo del indicador junto con
su evolucin en el tiempo.
Comparativas histricas entre indicadores en un mismo grfico, para aque-

llos en los que haya una relacin entre ellos. Por ejemplo, la disponibilidad
diaria con el nmero de cambios o la disponibilidad horaria con la carga de
transacciones.
Visin de varios indicadores en un perodo, representados en una tabla de
valores, en un grfico de Kiviat en forma de estrella, etc.
Tendencia del indicador. De forma general, en ITIL se considera ms conve-
niente representar los indicadores no con el valor propio del perodo, sino
como una tendencia de crecimiento o decrecimiento en el perodo actual en
relacin a perodos anteriores a efectos de tomar decisiones de actuacin
(correccin y mejora). Por ejemplo, tradicionalmente se mide el volumen
de cambios rechazados. En el caso de ITIL se recomienda medir tambin el
porcentaje de disminucin de los cambios rechazados. Esta forma de
expresar los indicadores permite conocer la tendencia de mejora, pero puede
resultar poco intuitiva y farragosa si slo se observan los indicadores de ten-
dencia, por lo que en este libro se ha optado por mostrar directamente el
valor del indicador en el perodo de medicin.
En relacin a los informes, la Norma ISO/IEC 20000-1 requiere que los mismos
estn identificados y que se verifique el cumplimiento de los requisitos y necesi-
dades del negocio. Tambin establece los conceptos mnimos a cubrir en los
informes.
UNE-ISO/IEC 20000-1
Se debe describir claramente cada informe de servicio, incluyendo su identificador,

el propsito, la audiencia y los detalles del origen de los datos.
Los informes de servicio se deben generar para verificar si se cumplen los requisitos
y necesidades de los usuarios. Los informes de servicio deben incluir:
a) el rendimiento y comportamiento frente a los objetivos de nivel de servicio;
b) las no conformidades y problemas relacionados, por ejemplo con los SLA o
agujeros de seguridad;
c) las caractersticas de la carga de trabajo, por ejemplo volumen o utilizacin
de recursos;
d) los informes de los resultados de los principales eventos, por ejemplo los prin-
cipales incidentes y cambios;
e) la informacin sobre tendencias;

f) el anlisis de satisfaccin.
Las decisiones de gestin y las acciones correctivas deben tener en cuenta los aspectos
destacados en los informes de servicio y deben comunicarse a las partes afectadas.
En la Norma ISO/IEC 20000-2 se desarrolla algo ms el propsito de los informes

del servicio, poniendo nfasis en su generacin a tiempo, en su claridad y en la fia-
bilidad de los datos contenidos. Adems, recomienda generar informes de varios
tipos: reactivos, proactivos y de planificacin de actividades.
UNE-ISO/IEC 20000-2
Propsito de los informes del servicio Se deberan generar distintos tipos de

y verificacin de su calidad informes:
Los informes de servicio se deberan a) informes reactivos, que muestran
generar a tiempo, y ser claros, fiables y lo que ha ocurrido;
concisos.
b) informes proactivos, que avisen
Se deberan adecuar a las necesidades por adelantado de eventos signifi-
de quien lo recibe y ser suficientemente cativos con objeto de permitir que
precisos para poder ser utilizados como se puedan realizar acciones pre-
herramienta de apoyo en la toma de ventivas (por ejemplo, informes
decisiones. sobre inminentes rupturas de los
SLAs);
La presentacin debera ayudar a com-
prender los informes de forma que sean c) distribucin previa de informes
fcilmente asimilables, por ejemplo que muestren las actividades pla-
usando grficos. nificadas.
Tambin en la Norma ISO/IEC 20000-2 se vuelve a tratar el alcance que deberan

cubrir los informes del servicio.
UNE-ISO/IEC 20000-2
Informes de servicio
a) comportamiento frente a objetivos
El proveedor del servicio debera generar de nivel de servicio, por ejemplo
informes para los clientes y para la direc- informes de cadas del servicio,
cin, que cubran los siguientes aspectos: logros;
b) no conformidades frente a nor- e) informacin de tendencias por

mas; periodos (por ejemplo diaria,
semanal, mensual);
c) caractersticas de la carga de tra-
bajo y volumen de la informacin, f) informes que incluyan informa-
por ejemplo incidentes, proble- cin de cada proceso, por ejem-
mas, cambios y tareas, clasifica- plo nmero de incidentes y de
cin, ubicacin, clientes, tenden- preguntas ms frecuentes, com-
cias estacionales, combinacin de ponentes de la infraestructura
prioridades, nmero de solicitu- poco fiables, tareas que consu-
des de ayuda; men gran nmero de recursos
econmicos, tcnicos o humanos;
d) informes de resultados despus
de eventos de alto nivel, por g) informes para destacar cargas de
ejemplo cambios y entregas; trabajo futuras o planificadas.
Aunque en el apartado 6.2 de estas normas se refiere al trmino de informes del

servicio, en realidad, para cubrir sus requisitos y recomendaciones, se requiere desa-
rrollar todo tipo de informes, tal y como se trata en este libro.
Las organizaciones con una excelencia en la gestin de TI, suelen generar una
buena cantidad de informes, necesarios tanto para la gestin como para la toma de
decisiones. Los principales informes son (ntese que en este libro se han incluido
como informes el panel de control y los informes instantneos, generados dinmi-
camente, ya que ambos son tambin una forma de mostrar los indicadores e infor-
macin sobre TI y que sirven para la toma de decisiones):
El panel de control de TI. Informacin continua proporcionada por la moni-
torizacin en tiempo real y mostrada en las consolas de monitorizacin.
Los informes instantneos generados online y accesibles va web. Correspon-
den a consultas en vivo sobre los indicadores. El ejemplo ms significativo
de estos informes lo proporcionan las utilidades de navegacin sobre los ser-
vicios, que mezclan informacin de la CMDB y de la monitorizacin en
tiempo real.
Informes del servicio. Son los informes de gestin de TI por excelencia.
Aglutinan toda la informacin necesaria para gestionar las TI, en sus visio-
nes diarias, semanales, mensuales, trimestrales y anuales.
Los cuadros de mando de TI. Que muestran, con la periodicidad que se haya
acordado o sea requerida, el estado de TI en base a una seleccin de los prin-
cipales indicadores. En organizaciones grandes hay un cuadro de mando
general de TI y otros cuadros de mando especficos para cada rea: del puesto
de trabajo (microinformtica y red), del centro de datos (o explotacin de sis-

temas) y de desarrollo de aplicaciones.
Adems hay planes, documentos especficos que se genera en cada proceso
anualmente y que se actualizan mensual o trimestralmente (a lo largo de este
libro se describe el contenido de ellos), aunque el objeto de este proceso no
son esos planes y documentos, pero s la generacin de los informes para el
seguimiento de sus objetivos. De esta forma, se tiene una visin general de
toda la informacin generada para la gestin de TI. Entre ellos destacan:
El plan financiero de TI y sus informes peridicos.
El plan de capacidad y sus informes.
El plan de disponibilidad y sus informes.
El plan de continuidad de TI y los informes de las pruebas.
El plan de mejora unificado de los procesos y de los servicios, y los infor-
mes derivados de seguimiento.
El plan de proyectos o el informe de iniciativas estratgicas de transforma-
cin y los informes para su seguimiento.
La lista de cambios planificados (FSC) y sus actualizaciones.
El informe sobre los problemas.
Otros informes especficos de cada proceso: seguridad, etc.
En la figura 6.2.16 se muestra la relacin de los principales informes en TI y su

contribucin a los aspectos reactivos, proactivos y de planificacin; tal y como
recomienda la Norma ISO/IEC 20000-2. Adems, se clasifican segn el mbito al
que vayan destinados: estratgico, tctico u operativo.
Segn la necesidad a cubrir, los informes se suelen generar con una periodicidad
diversa: anual (visin esttica, definicin objetivos), trimestral (grado de avance de
los grandes objetivos anuales), mensual (niveles de servicio, consecucin objetivos
mensuales), semanal (relativos a volumetras y niveles de servicio) e incluso diario
(eventos y actividades ocurridas en el da). En la figura 6.2.17 se muestra una apro-
ximacin a la periodicidad en la generacin de los informes.
Como se ha sealado en la figura 6.2.17, los informes del servicio se pueden gene-
rar con diversa periodicidad y su contenido vara segn el perodo. As, se podrn
generar de forma diaria, semanal, mensual y anual:
Informe del servicio diario. Proporciona cierta informacin de la actividad ocurrida
en el da, como, por ejemplo, los incidentes graves, las peticiones de los usuarios ms
Figura 6.2.16. Clasificacin de los informes ms relevantes utilizados en TI
Figura 6.2.17. Periodicidad de los diversos informes en TI

destacadas, los cambios ms relevantes o los volmenes de actividad del da. Estos
informes son descriptivos de lo acontecido en el da y no suelen contener grficos de
indicadores.
Informe del servicio semanal. Proporciona informacin de lo ocurrido en la

semana y permite el control y planificacin semanal de la actividad. Contiene una
parte liviana de indicadores. Casi toda la informacin que contienen es descriptiva
de lo ocurrido en la semana: incidentes, cambios y actividad de TI. Suele incorpo-
rar tambin los valores de disponibilidad de la semana y la acumulada en el tramo
de mes transcurrido. La disponibilidad se presenta sobre los servicios crticos, con
el fin de tener un control ms detallado semana a semana de esta mtrica.
En la figura 6.2.18 se muestra un ejemplo de la estructura de estos informes del
servicio.
Estructura de una arquitectura de mtricas
Informe del servicio diario:

Fecha, cdigo de informe y responsable.
Descripcin de incidentes graves del da.
Peticiones relevantes de los usuarios (VIP).
Resultados de los cambios ejecutados en el da.
Informe del servicio semanal:

Fecha, cdigo de informe y responsable.
Descripcin de incidentes graves semana.
Peticiones relevantes de los usuarios (VIP).
Resultados de los cambios ejecutados en el da.
Actividades realizadas en la semana.
Actividades previstas para la semana prxima.
Disponibilidad de los servicios crticos acumulada en el mes.
Disponibilidad total acumulada en el mes.
Figura 6.2.18. ndice ejemplo de los informes diario y semanal del servicio
Informe del servicio mensual. Es el informe ms relevante para la gestin de TI.

Contiene toda la informacin necesaria para conocer y controlar el devenir de la
actividad. Suele constar de un resumen general y un resumen de cada parte rele-
vante de TI que interese seguir mensualmente:
Resumen ejecutivo del mes.
Informe sobre la disponibilidad.
Informe sobre los incidentes y el anlisis causal asociado.
Anlisis de las peticiones de usuario realizadas.
Informe estadstico y descriptivo de los cambios.
Informe de los proyectos y las iniciativas de transformacin de TI.
Anlisis y volumetras de transacciones.
Resumen del estado presupuestario en el mes.
Variacin de la planta, descripcin de las capacidades de provisin, en lo rela-
tivo a la planta y en las capacidades de trabajo (sourcing).
Informacin resumen sobre el resultado del resto de procesos de gestin
TI, etc.
En la figura 6.2.19 se muestra un ejemplo del contenido del informe mensual

sobre el servicio de TI desde la perspectiva de la prestacin del servicio. Hay que
tener en cuenta que para el rea de desarrollo de aplicaciones la informacin a
tratar para su gestin sera otra muy distinta y origina otro modelo de informe.
El informe mensual comienza con una parte destinada al resumen ejecutivo, en la
que se reflejan los indicadores ms importantes para la gestin de TI, como por
ejemplo, la disponibilidad y tiempo de respuesta de los servicios; los tiempos de
resolucin y volumen de actividad de incidentes, peticiones de usuario y cam-
bios; informacin sobre los proyectos del mbito de infraestructuras; resumen
del grado de cumplimiento presupuestario y la desviacin sobre las previsiones;
un conjunto de indicadores que aporten una visin sobre la calidad de los servi-
cios y la eficiencia del trabajo; tambin es recomendable presentar una visin del
estado de la planta y la capacidad de trabajo disponible (medida mediante el indi-
cador de personas trabajando a tiempo completo equivalentes o FTE (Full Time
Equivalent), que traduce a jornadas equivalentes de 8 horas el volumen de perso-
nal interno, de personal externo y de los servicios contratados); para cerrar el
resumen ejecutivo con un campo descriptivo que permita destacar los aspectos
ms relevantes del mes.
Fuente: Telefnica.
Figura 6.2.19. Diseo ejemplo de un informe mensual sobre el servicio:

apartado especfico del resumen ejecutivo
Dentro del informe mensual del servicio (en la figura 6.2.20 se muestra un ejem-
plo), uno de los apartados ms relevantes es el relativo al anlisis de la disponibili-
dad de los servicios. En el ejemplo se muestran las cifras alcanzadas por cada uno
de los servicios en el mes, junto a una grfica de la evolucin mensual del indica-
dor, representando tambin la disponibilidad de los servicios crticos. Como en
todos los informes, se deben comentar los aspectos ms destacados relativos al
asunto que se est tratando (disponibilidad, etc.) que hubieran ocurrido en el mes,
as como las acciones de mejora emprendidas.
Informe del servicio anual. Muestra un resumen consolidado de la actividad y las

cifras del ao. Suele mantener la estructura de un informe mensual conteniendo
valores referentes al ao.
Fuente: Telefnica.
Figura 6.2.20. Diseo ejemplo de un informe mensual sobre el servicio:

apartado de disponibilidad de los servicios
Mtricas propias del proceso de gestin de informes

El propio proceso de generacin de informes del servicio tiene sus mtricas espec-
ficas que informan sobre su funcionamiento.
Como se indica en el objetivo del proceso, los informes de servicio se debern
generar a tiempo, y ser claros, fiables y concisos. Las mtricas del proceso moni-
torizarn el cumplimiento de estos objetivos, se medir la generacin y entrega en
plazo y sern fiables. Algunas mtricas relevantes del proceso pueden ser:
Porcentaje de incumplimientos de SLA debido a que los informes no se han
entregado en el plazo o con la calidad acordada.
El porcentaje de los informes entregados en plazo.
La calidad del dato en los informes, medida como el porcentaje de errores

medio por informe.
La tasa de indicadores definidos en la arquitectura de mtricas que de verdad
se estn midiendo.
El grado de automatizacin en la obtencin de las mediciones de los indica-
dores, que permitir conocer cuantos indicadores se obtienen de forma com-
pletamente automtica sin requerir el tratamiento humano.
La cantidad de indicadores medidos.
La cantidad de informes generados.
El coste medio de toda la actividad de medicin dividido entre el nmero de
indicadores, nos dar una idea del esfuerzo que se est realizando en la
obtencin de mediciones.
El coste medio por informe generado.
En el grfico de la figura 6.2.21 se muestra un resumen de los indicadores ms rele-

vantes para este proceso.
Figura 6.2.21. Mtricas principales para el proceso

Roles participantes en generacin de informes de

servicio
Dado que la generacin de informes es una actividad considerada no grata por las
reas tcnicas, tiene todo su sentido plantearla como una actividad con dedicacin
especfica centralizada comn para todo TI, que desde un punto central se recopile
toda la informacin y se generen los informes, o por lo menos los ms generalistas
(informes del servicio o cuadros de mando), dejando los informes especializados
(informe financiero de TI, informe de capacidad, etc.) a cada proceso.
Aunque la generacin de informes se centraliza en un proceso, se necesita la parti-
cipacin de los otros procesos y reas de TI de cara a incorporar las mtricas y
medidas, y la interpretacin y anlisis de la informacin presentada.
El gestor del proceso de generacin de informes (gestor del proceso o process
manager). Es responsable de la operacin diaria del proceso de generacin de
informes. Vela tanto por la definicin de la arquitectura de mtricas como por
la ejecucin de los informes en plazo y con calidad. Adems, no slo debe ges-
tionar la generacin de los informes, sino que tambin debe conocer en detalle
y de memoria las principales cifras de su organizacin y los ratios equivalen-
tes del mercado, de tal forma que pueda asesorar a la direccin de TI y a los
clientes sobre los indicadores ms adecuados, sus valores actuales y los de refe-
rencia. Se relaciona con el resto de responsables de proceso y de las reas para
conseguir que los informes contengan informacin til para ellos. Tambin
se encarga de que los informes se utilicen en la gestin y gobierno de TI.
En lo relativo a la etapa de definicin de la arquitectura de mtricas, los roles
adicionales al gestor del proceso son:
El consultor de mtricas que define la arquitectura de mtricas, alineando
los indicadores con los objetivos de TI y del negocio. Adems debe definir
en detalle las fichas de los indicadores.
El tcnico encargado de la definicin y creacin de la base de datos de
indicadores y mediciones.
El tcnico de implantacin de las herramientas de monitorizacin en lo
relativo a la captura automatizada de los valores y su carga en la base de
datos de indicadores y mediciones.
En lo relativo a la generacin de los informes, los roles adicionales al gestor

del proceso son:
El responsable de generacin de los informes (incluidos los cuadros de

mando), que vela por la calidad de la informacin y para que los informes
se generen a tiempo. Conoce en detalle todos los indicadores y ratios de
TI. Se encarga de que los informes sean conocidos y utilizables por las
reas destinatarias.
El tcnico de implantacin de las herramientas de cuadro de mando, de
acceso web al repositorio de informes, de generacin de informes online y
de la navegacin grfica sobre los componentes de un servicio.
En este mbito, tambin se suelen incluir perfiles estadsticos para el ajuste
y anlisis de tendencias a efectos de garantizar la exactitud del dato y la
usabilidad del mismo, no siendo su cometido el anlisis de la informacin,
ya que esto corresponde a los destinatarios y solicitantes (generalmente el
resto de procesos de TI).
Los administradores o el personal de soporte al proceso. Personal que con-

tribuye en organizar la actividad, preparar los informes, etc.

cumplan los niveles pactados. Aporta las necesidades de informacin, indica-
dores e informes necesarios para la gestin del servicio. Revisa y valida los
valores e informacin contenidos en los informes.
El responsable de la gestin de nivel de servicio, que especifica los niveles de
servicio que se van a medir y contemplar en los informes. Adems, revisa y
contrasta los valores de su competencia incluidos en los informes.
El responsable de las relaciones con el negocio, que participa en la definicin
de los informes que necesita entregar a sus clientes.
Los responsables del resto de los procesos, pues especifican los indicadores y
necesidades de informes, o bien, los generan ellos mismos (por ejemplo, el
informe de capacidad o el informe financiero).
(process owner), define el proceso y vela por el cumplimiento y actividades del
proceso, y se encarga de la mejora continua del mismo.
Los roles de mayor relevancia que participan en la generacin de informes de servi-

cios se representan en la figura 6.2.22.
Roles del proceso
Responsable de la
gestin del servicio
Gestor del
proceso de informes
Consultor
de mtricas
Gestores de otros
procesos y reas TI
SGSTI
Responsable de generacin
de los informes
Especialistas en el Administrador y
Propietario del
modelo (SGSTI) diseo del servicio soporte del proceso
Figura 6.2.22. Roles del proceso de generacin de informes del servicio
Resumen
Los indicadores e informes son una necesidad innegable en una gestin con cali-
dad de TI, pero su generacin ha sido siempre una de las asignaturas pendientes de
las organizaciones, muy centradas en la tecnologa y el da a da, y poco en el
gobierno y la gestin.
El proceso de generacin de informes de servicio centraliza las arduas activida-
des de recopilacin de indicadores e informacin, para generar unos informes
con la calidad del dato contrastada, en los plazos convenidos y con la mxima
eficiencia.
Aunque en las Normas ISO/IEC 20000 los requisitos para el proceso son ms
reducidos, en este apartado se han desarrollado en toda su amplitud, con el fin de
llevar a las organizaciones de TI a la excelencia.
La generacin de informes pasa por la definicin de una poltica de informes, que
marque las directrices a cumplir en cuanto al suministro de informacin.
Un segundo paso recomendado, es la creacin de una arquitectura de mtricas, que
defina y estructure los indicadores a medir, poniendo orden y posibilitando la con-
tinuidad en las mediciones.
Las organizaciones situadas en las mejores prcticas, disponen de una base de datos
centralizada (o bien federada) en la que incorporan las definiciones de los indica-
dores y todos los histricos de las mediciones.
Los principales informes de TI van ms all de representar nicamente cifras sobre
cumplimiento de los niveles de servicio. El alcance de los informes abarca todo tipo
de informacin analtica y descriptiva. Tambin se considera dentro del alcance a la
informacin mostrada en vivo. As, los principales informes son:
Informes del servicio: diarios, semanales, mensuales y anuales.
Cuadros de mando de TI.
Informe financiero de TI.
Informe de capacidad.
Informe de disponibilidad.
Informe de continuidad de TI.
Informe de mejora global: SIP + procesos.
Informe de cada proceso.
Lista de cambios planificados (FSC).
Informes de proyectos e iniciativas estratgicas.
Informe de problemas.
Tambin se consideran dentro del alcance del proceso los paneles de control, con
grficas que muestran en tiempo real el estado de los servicios y las infraestructu-
ras, as como, los informes generados de forma instantnea (por ejemplo, va web).
Para poder tratar el ingente volumen de datos, es necesaria la mxima automatiza-
cin, desde la captura de las mediciones mediante las herramientas de monitoriza-
cin, pasando por la carga a la base de datos referida anteriormente, hasta llegar a
la generacin instantnea (online) de los informes.
La fiabilidad y la calidad de los datos son esenciales para que los informes sean de
utilidad.
Muchos de los informes contienen tambin tendencias, descripciones y anlisis de
las actividades y sucesos ocurridos en el perodo.
Beneficios
Los principales beneficios aportados por el proceso de generacin de informes son:
La centralizacin de la generacin de informes en un proceso facilita la espe-
cializacin, y permite al resto de procesos y reas de TI centrarse en sus
cometidos.
Los informes y las mtricas se disean y gestionan de forma comn.
Los informes se planifican con una visin comn de las necesidades de TI y
de los clientes, lo que permite ms claridad y concisin. Adems se ofrece
una visin ms homognea sobre toda la actividad de TI.
Cada rea recibe los informes que necesita y con la periodicidad acordada.
Es ms fcil garantizar que la informacin es fiable. Existe un responsable de
cada dato y de cada informe.
El diseo comn por especialistas facilita que la informacin sea ms clara y
entendible por los destinatarios.
Se centralizan en un punto todos los indicadores y todas sus mediciones.
Con lo cual, cualquier cambio o nuevo informe ser ms fcil de implemen-
tar, al tener la informacin histrica registrada.
La centralizacin facilita la creacin una plataforma comn para la genera-
cin y difusin de los informes. Adems, la dedicacin especfica a esta acti-
vidad aumenta la productividad en la generacin de informes.
La organizacin de TI conoce los resultados de su trabajo, con claridad y a
tiempo. Por tanto, mejora su motivacin.
La comunicacin e informacin clara y a tiempo permite mejorar la satisfac-
cin de los clientes.
Cules son los 10 indicadores principales que se utilizan en su orga-
nizacin
Enumere los informes generados en un ao en el mbito de TI en su
organizacin
Qu aporta los marcos de ITIL y COBIT a los indicadores e informes?
1
99,99%

6.3. Gestin de la continuidad y disponibilidad del servicio 279
6.3. Gestin de la continuidad y disponibilidad

del servicio
Figura 6.3.1. Esquema general del proceso de la gestin de

la disponibilidad y de la continuidad
Bienvenido al astro rey de la informtica, la piedra angular sobre la que gravita la

actividad de TI: la disponibilidad! Es absolutamente importante y adems est
continuamente en boca de todos, tanto en la direccin de TI como en el negocio.
Situacin que ya de partida es un mal augurio, tanta preocupacin de los clientes
por ella viene a resaltar que los servicios prestados fallan y fallan, escenario genera-
lizado en una industria que no acaba de alcanzar la madurez necesaria (vase la
figura 6.3.1).
Los servicios en TI deberan estar operativos cuando los necesite el negocio y de la
manera que los necesite. Pero la realidad en TI es bien distinta, y se est lejos de ofre-
cer unos servicios tan omnipresentes que sus fallos y cadas se pierdan en la memoria
de los tiempos. Hasta que se alcance ese paraso, la disponibilidad seguir saltando
ms all de los mbitos tcnicos, para continuar siendo el centro de las preocupacio-
nes de la direccin de la empresa cuando piensa en los sistemas de informacin.
Emulando la pirmide de necesidades del ser humano definida por Maslow, la dispo-
nibilidad de los servicios se situara en la base, en las necesidades fsicas primarias
de TI, sin la cual no se puede sobrevivir. Para el negocio, la disponibilidad de los

servicios es como el aire que respiramos. No es extrao, ya que una no disponibili-
dad en algn servicio implica que alguien en la empresa no puede hacer su trabajo,
que se quede parado o incluso que se estn perdiendo clientes.
De forma paralela al concepto de la disponibilidad cotidiana de los servicios, apa-
rece la necesidad de garantizar que los servicios se puedan seguir utilizando des-
pus de un evento catastrfico. As, resurge el antiguo concepto de continuidad de
los servicios de TI, tan ignorado o postergado en muchas organizaciones de TI, y
hasta tal punto denostado, que en muchos sectores crticos (por ejemplo, el finan-
ciero) ha sido necesaria la legislacin gubernamental para garantizar a la sociedad
la supervivencia de sus servicios y de la informacin asociada.
Las mejores prcticas existentes, conscientes de la realidad imperfecta de esta indus-
tria, no aspiran a la perfeccin. Centran el foco en que los servicios se diseen para
cumplir lo pactado con los clientes en los acuerdos de nivel de servicio (SLA). As,
todas las medidas para garantizar la disponibilidad y continuidad deben estar aline-
adas con estos SLA.
Pero adems, TI tiene la obligacin de compararse con el segmento de mercado al
que se equipara, con el que compite la empresa, para garantizar que los niveles de
servicio que ofrece y acuerda con su negocio sean parejos o superiores a los de la
competencia.
De forma simplificada, se puede decir que la disponibilidad tiene como objetivo
garantizar que los servicios requeridos por el negocio son prestados cundo y cmo
se necesitan bajo condiciones normales, mientras que la continuidad se encarga de
garantizar la persistencia de los servicios ante condiciones extraordinarias (fuego,
inundaciones, terrorismo, sabotajes, etc.).
Sintetizando estos conceptos en una sola palabra, se puede decir que la gestin de
la disponibilidad es sinnimo de fiabilidad, mientras que la gestin de la continui-
dad es sinnimo de supervivencia.
En relacin a la causa que origina la perturbacin la disponibilidad y la continui-
dad son fcilmente separables, pero ambas tienen muchas disciplinas comunes: la
identificacin de las funciones vitales de negocio, el anlisis de riesgos, el trabajo en
base a planes, etc. Por eso, las Normas ISO/IEC 20000 las unifican en un slo pro-
ceso, en cambio, en ITIL son tratados como dos procesos independientes (libro
Diseo del Servicio, proceso de gestin de la disponibilidad y proceso de gestin de
la continuidad de TI).
En este apartado se respeta la unificacin de procesos realizada en ISO/IEC 20000,
pero se explican las buenas prcticas de forma diferenciada, identificando las disci-
plinas comunes y las formas de trabajo muy distintas en cada uno.
99,99%

En la figura 6.3.2 se muestra una visin introductoria al proceso de gestin de la

disponibilidad y continuidad del servicio de TI.
Proceso de gestin de la Qu aporta:

disponibilidad y continuidad Un plan de disponibilidad orientado
a mejorar la disponibilidad general.
Toma de conciencia sobre los
Definicin: servicios crticos para el negocio.
Proceso responsable de ofrecer unos Garantizar que se pueden satisfacer
niveles de disponibilidad adecuados las necesidades de disponibilidad
a las necesidades de los clientes y actuales y futuras.
unos niveles de funcionamiento
acordados tras una contingencia. Conseguir reducir la frecuencia y
la duracin de las incidentes que
quebranten la disponibilidad.
Objetivo: Minimizar la interrupcin de las

actividades de negocio.
Asegurar que los compromisos de
continuidad y disponibilidad acordados Un plan de continuidad para prevenir,
con los clientes pueden cumplirse bajo detectar, preparar y mitigar los
todas las circunstancias. efectos de los desastres.
Figura 6.3.2. Introduccin al proceso de gestin de la disponibilidad y continuidad
Segn establecen las Normas ISO/IEC 20000, el objetivo de la disponibilidad y

continuidad es asegurar que los compromisos de continuidad y disponibilidad
acordados con los clientes pueden cumplirse bajo todas las circunstancias.
La disponibilidad se centra en:
Desarrollar el plan de disponibilidad de TI, para cumplir con los requisitos
del cliente y alineado con el mercado.
Reducir los tiempos de mantenimiento y no disponibilidad.
Promover una actitud proactiva para reducir la frecuencia y duracin de los
fallos informticos.
La continuidad se articula en torno a:

El desarrollo y actualizacin del plan de continuidad de TI, acorde con la
estrategia y el plan de continuidad del negocio.
Minimizar la interrupcin de las actividades de negocio tras un desastre.

Reducir la vulnerabilidad mediante un eficaz anlisis y gestin de riesgos.
Como se muestra en la figura 6.3.3, una arquitectura robusta, el conocimiento tc-

nico y la constancia son los principios bsicos en los que fundamentar la gestin de
la disponibilidad y continuidad.
Figura 6.3.3. Principios bsicos de la gestin de la disponibilidad y continuidad
La combinacin adecuada de estos tres principios permite establecer y gestionar de

manera eficaz este proceso.
El factor principal de xito de la disponibilidad y la continuidad es un diseo ade-
cuado de la tecnologa en la que se basan los servicios. As, resulta esencial la defi-
nicin de unas directrices tcnicas para la construccin de las aplicaciones y de una
arquitectura para las plataformas tecnolgicas, con la redundancia y replicacin en
remoto necesarias para garantizar los niveles de servicio comprometidos.
El conocimiento tcnico permitir realizar el diseo de las soluciones tcnicas, pues
la disponibilidad y la continuidad son elementos que se conciben en el momento
en que se crea el servicio. Participa tambin en el anlisis proactivo de riesgos y
forense de incidentes, para establecer las soluciones adecuadas. El componente tc-
nico es importante en este proceso.
Ms all del empuje inicial para definir e implantar los planes de disponibilidad y
de continuidad, es necesario mantener una constancia diaria para conseguir que se
99,99%

lleven a cabo las tareas definidas, muchas de ellas, con una visin a futuro que com-
pite con las prisas y sobrecarga que conlleva el da a da de los servicios.
Como es normal, las Normas ISO/IEC 20000 no definen una estructuracin de las
actividades que se deben realizar. Por eso, en este apartado se detalla el proceso
tomando como base la estructura para la gestin de la continuidad de cuatro blo-
ques utilizada en ITIL v2:
Inicio o implementacin del proceso.
Definicin de los requerimientos y de la estrategia a seguir en el proceso.
Implementacin de las soluciones.
Gestin operativa del proceso.
Sobre estos bloques se detallan las actividades que se deben realizar y se aade un
quinto con las actividades de mejora del proceso, tpicas de estas normas.
En la figura 6.3.4 se muestran las diversas estructuras que se dan al proceso de ges-
tin de la disponibilidad en las versiones 2 y 3 de ITIL. Aunque las agrupaciones y
denominacin de las actividades difieren, el concepto de fondo en el proceso es
siempre el mismo.
En ITIL v2 la disponibilidad se estructura En ITIL v3 la disponibilidad se agrupa

en dos reas: planificar y supervisar en dos bloques: reactivas y proactivas
Disponibilidad en ITIL v2 Disponibilidad en ITIL v3
Planificar: Actividades reactivas:

Determinar requisitos. Monitorizacin, medicin, anlisis de informes,
Disear para la disponibilidad. revisin del servicio y disponibilidad de los com-
Disear para la recuperacin. ponentes.
Verificar la seguridad. Investigacin indisponibilidad de todos los servi-

cios y componentes, e impulsar soluciones.
Planificar paradas.
Obtener y mantener el plan de disponibilidad. Actividades proactivas:
Evaluacin y gestin del riesgo.
Supervisar:
Planificacin y diseo para servicios nuevos o
Establecer mtricas e informes. modificados.
Monitorizar y analizar tendencias. Implementar contramedidas justificadas en costes.
Revisar la disponibilidad. Revisin de todos los servicios, nuevos y modifi-
Investigar la indisponibilidad. cados, prueba de la disponibilidad y mecanismos
Mejorar la disponibilidad. de resistencia.
Figura 6.3.4. Diferentes aproximaciones a la disponibilidad en ITIL

Si bien la disponibilidad se trata bajo dos agrupaciones de actividades distintas en

las dos versiones de ITIL, en la gestin de la continuidad se ha seguido una misma
estructura de 4 bloques. Las actividades contempladas son similares, pero enuncia-
das de forma distinta, como se muestra en la figura 6.3.5. En las dos versiones de
ITIL no vara un pice el objetivo y espritu de estos procesos.
Continuidad en ITIL v2 Continuidad en ITIL v3
Inicio: Inicio:
Definir poltica continuidad. Fijar poltica continuidad.
mbito de la continuidad. mbito de la continuidad.
Definicin e inicio proyecto continuidad. Inicio del proyecto continuidad.
Requerimientos y estrategia: Requerimientos y estrategia:
Anlisis impacto en el negocio. Anlisis impacto en el negocio.
Evaluacin del riesgo. Evaluacin de riesgos.
Definicin estrategia continuidad negocio. Definicin estrategia continuidad de TI.
Implementacin: Implementacin:
Organizacin y planificacin implementacin. Desarrollo planes continuidad de servicios TI.
Desarrollo planes de recuperacin. Desarrollo planes TI, planes recuperacin y
Implementar medidas de reserva. procedimientos.
Implementar medidas reduccin del riesgo. Planificacin de la organizacin.
Desarrollar los procedimientos. Prueba de la estrategia.
Pruebas iniciales. Gestin operativa:
Gestin operativa: Educacin, concienciacin y formacin.
Educacin y concienciacin. Revisin y auditora.
Revisin y auditora. Pruebas.
Pruebas. Gestin de cambios.
Control de cambios. Invocacin
Formacin.
Aseguramiento.
Figura 6.3.5. Estructura bastante similar de las actividades de continuidad

en las dos versiones de ITIL
La gestin de la disponibilidad y continuidad utilizan un entorno muy rico y

maduro de tcnicas y componentes. Para el anlisis de los riesgos se utilizan disci-
plinas compartidas con la seguridad, realizando la identificacin de las funciones
que son vitales para el negocio y el anlisis de impacto de las amenazas. Tambin se
99,99%

aplican las metodologas de gestin de riesgos, se identifican los requisitos del

negocio y se establecen las directrices de diseo y arquitecturas. La implementa-
cin se articula en torno a planes que se revisan de forma peridica. Se realizan
pruebas, para garantizar su correcto funcionamiento. Los mecanismos principales
utilizados en este proceso para alcanzar sus objetivos, se muestran en la figura 6.3.6
agrupados en funcin de cada una de las etapas.
Figura 6.3.6. Elementos del proceso de gestin de la disponibilidad y de la continuidad
Los elementos principales que integran el proceso de gestin de la disponibilidad y

de la continuidad son:
Conceptos bsicos. El proceso trata con los siguientes conceptos bsicos:
Continuidad. Capacidad de seguir prestando los servicios del negocio o de
TI despus de un desastre.
Disponibilidad. Perodo en que una funcin est plenamente utilizable por

los usuarios. Se distingue entre disponibilidad del componente (analizado
como elemento tcnico aislado) y la disponibilidad del servicio (como un con-
junto de elementos de configuracin que presta una funcionalidad al negocio).
Fiabilidad. La fiabilidad de un servicio o componente se entiende como lo
fidedigno que es o lo libre que est de fallos (mide la frecuencia entre fallos).
Mantenibilidad. Viene a representar facilidad con que puede ser reparado o
devuelto a su estado normal de funcionamiento a un componente de la
infraestructura. Normalmente realizado por personal interno.
Serviciabilidad. Indicador del nivel y calidad del mantenimiento proporcio-
nado por terceros (mantenibilidad proporcionado por terceros).
Seguridad. La confidencialidad, integridad y disponibilidad de los datos rela-
cionados con un servicio; se trata de un aspecto de disponibilidad general.
Anlisis del rbol de fallos (FTA, Fault Tree Analysis). Mtodo de anlisis de los
sucesos ocurridos en un servicio para determinar la causa una interrupcin de
los servicios de TI. Se representa una cadena de sucesos en un esquema en forma
de rbol booleano.
Anlisis de impacto en el negocio (BIA, Business Impact Analysis). Anlisis del
impacto que tendran los riesgos en la actividad de la empresa u organizacin, si se
produjera la parada de una funcin de negocio. Permite identificar y ponderar cu-
les son las funciones de negocio vitales que debern protegerse mediante la dispo-
nibilidad, la continuidad y la seguridad. Este anlisis es fundamental para el des-
arrollo de las actividades de estos procesos.
Anlisis del impacto por el fallo de un componente (CFIA, Component Failure
Impact Analysis). Predecir y estimar el impacto sobre la disponibilidad del servicio
derivada de los fallos de los componentes incluidos en la infraestructura de TI y del
diseo del servicio propuesto. El CFIA de los componentes permitir identificar
los componentes ms dbiles (vulnerabilidad y amplitud del impacto) que requie-
ren establecimiento de contramedidas de refuerzo.
Anlisis de las paradas del servicio (SOA, Service Outage Analysis). Anlisis a
posteriori de las causas de las cadas de un servicio, con el fin de reducir la frecuen-
cia y duracin de las paradas. De forma similar se utiliza el trmino SFA (Service
Failure Analysis). Toma como fuente de informacin los incidentes ocurridos, para
realizar un anlisis forense de cara a mejorar la disponibilidad.
Arquitectura de disponibilidad. Definicin tecnolgica que establece la forma
homognea de construir servicios en la organizacin para que se cumplan los requi-
sitos de disponibilidad. Esta arquitectura establece la redundancia de componentes,
99,99%

el balanceo de carga y otros aspectos que refuercen la robustez y escalabilidad de

los servicios. Normalmente la arquitectura contempla varias soluciones: unas para los
servicios ms crticos y ms demandantes de disponibilidad, y otras para los menos
crticos. La arquitectura define primero y desarrolla despus las especificaciones tc-
nicas. Se recomienda que, a partir de la arquitectura se construyan plataformas tcni-
cas que alojen los servicios. As, cada nuevo servicio no requerir la compra de nuevo
equipamiento, sino que se incorporar a la plataforma previamente preparada. De
esta forma se facilita la consolidacin de la infraestructura y su virtualizacin.
Arquitectura de continuidad. De forma similar y sincronizada con la arquitectura
de disponibilidad, en este caso se define la solucin tcnica para que los servicios se
puedan recuperar en caso de desastre. Debe contemplar varios tipos de soluciones
para cada una de las necesidades de recuperacin de los servicios (definidas segn
la criticidad de los mismos). Esta arquitectura proporciona las especificaciones tc-
nicas para implementar las opciones de recuperacin, como por ejemplo, la recupe-
racin inmediata (conocida normalmente como mirroring), la recuperacin rpida
(aunque conocida como hot standby), la recuperacin intermedia (warm standby), la
recuperacin gradual (cold standby), acuerdos recprocos o soluciones manuales.
Ciclo de vida expandido del incidente. Detalle que se realiza sobre las diversas
fases en las que se descompone un incidente, con el fin de poder medir cada una de
ellas y determinar acciones correctoras para mejorar su resolucin.
Clientes. Son los destinatarios o usuarios de los servicios. Expresan sus necesida-
des de disponibilidad y continuidad en los contratos y SLA.
CRAMM (CCTA, Risk Analysis Methodology Management). Mtodo creado en
1987 por la Agencia Central de Procesamiento de Datos del Reino Unido (CCTA)
para identificar los riesgos y establecer las contramedidas justificadas con el fin de
reducir o eliminar las amenazas de tales riesgos. La evaluacin de riesgos se divide
en tres etapas, las dos primeras identifican y analizan los riesgos en los servicios, y
la tercera recomienda cmo se deben gestionar estos riesgos. El mtodo CRAMM
es uno de los ms utilizados en la evaluacin de riesgos para la continuidad, pero
tambin es vlido para analizar los aspectos de la disponibilidad.
Diseo para la disponibilidad y continuidad. Conjunto directrices tcnicas para
que la construccin de los servicios tenga la robustez necesaria para cumplir los
requisitos de disponibilidad y continuidad establecidos. El diseo debera llevar a
la definicin de una arquitectura detallada, que posteriormente se debera imple-
mentar como plataforma consolidada que aloje los servicios.
Evaluacin de riesgos. Se trata de una actividad que contextualiza los servicios en
el entorno en que stos van a ser prestados. Proporciona informacin relativa a las
amenazas y vulnerabilidades que pueden afectar a los servicios, as como, la proba-
bilidad de que ocurran. El riesgo es funcin de la amenaza (probabilidad de que
ocurra el suceso) y de la vulnerabilidad de los servicios al mismo. La evaluacin de

riesgos se puede realizar bajo varias perspectivas, dependiendo del proceso que lo
realice, para asegurar la disponibilidad de los sistemas (foco en fallos cotidianos), la
continuidad (foco en contingencias severas) o en la seguridad (foco en la malicia
humana).
Elemento de configuracin. La infraestructura de TI con la que se presta el servi-
cio es la base sobre la que se articula y monitoriza tanto la disponibilidad, mediante
el seguimiento de la disponibilidad de cada uno de los componentes, como la con-
tinuidad, mediante los correspondientes planes. Todo ello teniendo en cuenta las
necesidades del negocio pactadas con los clientes y reflejadas en los SLA.
Funcin vital de negocio (VBF, Vital Business Function). Se utiliza el trmino
funcin vital de negocio para reflejar el conjunto de actividades sin las cuales el
negocio no se sustenta o se producen cuantiosas prdidas. Normalmente se obtie-
nen como resultado del anlisis del impacto en el negocio (BIA) de los riesgos. El
foco se centra en aquellas VBF que se sustentan en servicios de TI.
Gestin de la disponibilidad de TI (AM, Availability Management). Proceso que
gestiona todos los aspectos para poder garantizar los niveles de disponibilidad pac-
tados por TI con los clientes.
Gestin de la continuidad del negocio (BCM, Business Continuity Management).
Conjunto de acciones y actividades en la empresa u organizacin destinadas a
garantizar la supervivencia del negocio en el caso de que ocurra una catstrofe. Su
mbito es toda la actividad, departamentos de la empresa y procesos de negocio.
Gestin de la continuidad del servicio de TI (ITSCM, IT Service Continuity
Management). Proceso especfico en el mbito de TI, que garantiza la superviven-
cia de los servicios de TI y de la informacin que contienen. Forma parte de la con-
tinuidad de negocio y desarrolla la continuidad especfica en TI.
Informes de cumplimiento de planes. Evidencian el grado de ajuste entre lo
recogido en los planes y la realidad. En caso de desviacin, analizan las circunstan-
cias que han llevado a esa situacin.
M_o_R (Management of Risk). Metodologa para la gestin de los riesgos pro-
puesta en ITIL v3, similar a CRAMM. Est estructurada en 5 etapas: polticas,
aproximacin, proceso, institucionalizar y revisar, y comunicar.
Plan de continuidad de los servicios de TI (ITSCP, IT Service Continuity Plan).
Su elaboracin es el eje central que articula todas a las acciones de continuidad. Se
elabora como parte del plan de continuidad del negocio.
Plan o planes de recuperacin de los servicios de TI. Forman parte del ITSCP y
contienen todos los detalles para actuar en el caso de desastre, realizar la recupera-
99,99%

cin de los servicios, las infraestructuras, las telecomunicaciones, la alimentacin

elctrica, los servidores, etc.
Plan de disponibilidad. Recoge las polticas, requisitos, directrices y toda
la informacin necesaria para implementar y gestionar la disponibilidad de los
servicios. Es el documento sobre el que se articula la implantacin de la dispo-
nibilidad.
Plan de paradas planificadas (PSO, Projected Service Outage). Documento que
refleja los intervalos en los que los servicios se pueden parar con fines de manteni-
miento o de cambio. Sirve como entrada para los requisitos del diseo, para los
acuerdos con los clientes, para la planificacin de los cambios, etc.
Porcentaje de disponibilidad. Tiempo en el que los servicios han podido ser utili-
zados frente al tiempo total que los servicios deberan haber estado operativos. Es
la mtrica de TI por excelencia.
Punto nico de fallo (SPOF, Single Point Of Failure). Tcnica para identificar ele-
mentos no redundados que, en caso de fallar, produciran una cada del compo-
nente o del servicio.
Requisitos de continuidad. Establecidos en la estrategia de TI y concretados en
los acuerdos de nivel de servicio con los clientes, son relativos a la continuidad
a cumplir por los servicios. En los requisitos de continuidad, para cada servicio,
se definen dos parmetros esenciales necesarios en el diseo de las soluciones: el
punto de recuperacin (RPO, Recovery Point Objective) y el tiempo de recuperacin
(RTO, Recovery Time Objective).
Requisitos de disponibilidad. Establecidos en la estrategia de TI y concretados
en los acuerdos de nivel de servicio con los clientes relativos a los niveles de dispo-
nibilidad a cumplir. Establecen el porcentaje de disponibilidad de los servicios, los
tiempos de respuesta, los horarios del servicio, etc.
RPO (Recovery Point Objective) o punto objetivo de recuperacin. Representa la
prdida de informacin mxima que el negocio est dispuesto a asumir en un servi-
cio despus de un desastre.
RTO (Recovery Time Objective) o plazo objetivo de recuperacin. Tiempo mximo
en el que se debe recuperar un servicio tras un desastre.
Tiempo de respuesta. Lapso de tiempo en que tarda un servicio online en respon-
der al usuario. Un tiempo de respuesta por encima de los lmites se considera indis-
ponibilidad del servicio. Se pactan con los clientes. En sistemas transaccionales
rabiosos o crticos se considera que debe estar por debajo de los 3 segundos, en
pginas web en Internet el usuario est acostumbrado y da por bueno tiempos
de espera superiores, llegando en algunos casos a superar los 10 segundos.
Entradas, actividades y salidas de la gestin de la

disponibilidad
La gestin de la disponibilidad se encarga de garantizar que los servicios son capa-
ces de cumplir los requisitos de disponibilidad y tiempo de respuesta que se han
pactado con el negocio. Sus actividades se pueden considerar divididas en dos gran-
des grupos: uno primero destinado a planificar e implementar las soluciones de dis-
ponibilidad y, un segundo, que realiza la gestin operativa de la misma.
En el esquema de la figura 6.3.7 se muestran las entradas, actividades y salidas de
la gestin de la disponibilidad. Las actividades de disponibilidad y continuidad se
DISPONIBILIDAD
Desencadenantes 3 Inicio: Salidas principales:

del proceso: Poltica disponibilidad. Plan de disponibilidad.
Peticin de la direccin. Definicin e inicio proyecto. Funciones vitales del
Negociacin de un SLA. negocio-VBF.
3 Requerimientos y estrategia:
Incumplimiento Directrices de diseo
Evaluacin de riesgos.
disponibilidad. de la disponibilidad y
Determinar requisitos. arquitectura.
Fecha revisin del plan
disponibilidad. 3 Implementacin: Informes de
seguimiento de
Disear para la disponibilidad.
Entradas de soporte: disponibilidad.
Disear para la recuperacin.
Riesgos.
Verificar la seguridad. Salidas secundarias:
SLA firmados.
Planificar las paradas. Requisitos de
Informacin de
monitorizacin.
incidentes y problemas. Generar el plan de
disponibilidad. Plan paradas
Datos de monitorizacin .
planificadas-PSO.
RFC. 3 Gestin operativa:
Resultados anlisis de
CMDB. Supervisar la disponibilidad. riesgos.
Investigar y mejorar Resultados tcnicos
disponibilidad. investigacin incidentes.
Actualizar plan de
disponibilidad.
3 Mejora del proceso
Figura 6.3.7. Entradas, actividades y salidas de la gestin de la disponibilidad

99,99%

han estructurado de forma pareja para facilitar su integracin como un proceso

nico. Adems, ambas emulan la estructura utilizada en ITIL para la continuidad.
La gestin de la disponibilidad se inicia con una peticin de la direccin de TI para
que se realice el ciclo de planificacin de la disponibilidad, que termina con el plan
de disponibilidad realizado o actualizado. El inicio de la negociacin de un acuerdo
de nivel de servicio tambin puede activar el proceso con el fin de apoyar a la ges-
tin de nivel de servicio en los aspectos relativos a la disponibilidad. El incumpli-
miento de los niveles de disponibilidad, detectados por otros procesos o reas, tam-
bin puede desencadenar que se inicien las acciones de investigacin y mejora de la
disponibilidad. Adems, el proceso se activa por la proximidad de la fecha de revi-
sin del plan de disponibilidad.
La gestin de la disponibilidad utiliza como entradas de soporte: informacin
sobre los distintos riesgos e informacin tcnica de los componentes; informacin
sobre los incidentes y los problemas con el fin de analizar las causas de fallo; datos
de monitorizacin para el seguimiento de la disponibilidad y las tendencias; peti-
ciones de cambio (RFC) con el fin de velar porque no se pongan en riesgo los nive-
les de disponibilidad y para mantener actualizado el plan de disponibilidad con los
cambios realizados; y la base de datos de gestin de la configuracin (CMDB) para
obtener los detalles de los elementos de configuracin que componen los servicios.
Las principales actividades de la gestin de la disponibilidad se han articulado en
torno a conceptos similares utilizados en la gestin de la continuidad de ITIL.
En este libro se han aadido las fases de inicio y de requerimientos y estrategia. Las
actividades que se deben realizar son:
Inicio. Establece las condiciones para el comienzo de la implantacin de la
gestin de la disponibilidad.
Definir las polticas de disponibilidad. Se fijan las directrices que se
deben cumplir por la disponibilidad de los servicios.
Definicin e inicio del proyecto de disponibilidad. Se crea el proyecto
para implementar la disponibilidad, con su planificacin y dotacin presu-
puestaria. Se inicia su ejecucin.
Requerimientos y estrategia. Establece los requerimientos que se deben

cumplir en relacin a la disponibilidad.
Realizar la evaluacin de riesgos. Identifica las funciones vitales del
negocio (VBF) y realiza el anlisis de riesgos.
Determinar los requisitos de disponibilidad. Se deben establecer los requi-
sitos que deben cumplir los servicios en cuanto a la disponibilidad y tiempo
de respuesta. Se define la estrategia que se debe seguir para satisfacerlos.
Implementar la disponibilidad. Actividades para implantar la disponibilidad.

Disear para la disponibilidad. Definicin de las directrices de diseo
de los servicios (en cuanto a la disponibilidad y tiempo respuesta). Deri-
vado de estas directrices se suele y se deben definir unas arquitecturas tc-
nicas y unas plataformas que alojen los servicios.
Disear para la recuperacin. Fija las pautas y procedimientos de actua-
cin en caso de que se produzca un incidente de prdida de disponibili-
dad, que deber ejecutar la gestin del incidente.
Verificar la seguridad. Asegura que se implantan las medidas de seguri-
dad adecuadas en los componentes del servicio.
Planificar las paradas y el mantenimiento. De forma general, todo ser-
vicio requiere en algn momento de su prestacin la realizacin de tareas
de mantenimiento. El mantenimiento de los servicios debe llevarse a cabo
de forma que se minimice su impacto sobre el servicio y su disponibilidad,
utilizndose cuando es posible las denominadas ventanas de manteni-
miento (paradas planificadas). Para poder aprovechar las mencionadas
ventanas de mantenimiento es necesario tener identificado cundo se
requiere el mantenimiento y cules son las actividades que implica (rela-
cin con el proceso de gestin del cambio). Determina las ventanas de
parada de componentes y de los servicios, para mantenimiento o para la
realizacin de cambios.
Generar el plan de disponibilidad. Todos los resultados de las activida-
des anteriores se recogen en el documento central del proceso: el plan de
disponibilidad, que aglutina en un documento toda la informacin e ini-
ciativas necesarias para mejorar la disponibilidad.
Gestin operativa. Gestin diaria de la disponibilidad de los servicios en

produccin.
Supervisin de la disponibilidad. Prepara los medios necesarios para
realizar un seguimiento de la disponibilidad obtenida de los componentes
y de los servicios: define las mtricas, define los informes, especifica los
umbrales de monitorizacin, genera los informes necesarios sobre la dis-
ponibilidad obtenida y comunica los resultados a las partes interesadas.
Dentro de esta actividad, tambin se puede incluir la definicin de las
herramientas de monitorizacin necesarias y su implementacin; aunque
lo habitual es definir un proyecto especfico para implantar todo el con-
junto de herramientas de monitorizacin necesarias para todos los proce-
sos y para las funciones tcnicas.
99,99%

Investigar y mejorar la disponibilidad. Analiza las causas de la no dispo-

nibilidad e identifica las reas de mejora en los componentes y servicios para
que los valores de disponibilidad se ajusten a los requeridos por el negocio.
Actualizar el plan de disponibilidad. Se actualiza el plan de disponibili-
dad de forma peridica, realizando una revisin completa de su contenido.
Adems, se actualiza con los cambios realizados en la infraestructura.
Mejorar el proceso. Conjunto de actividades destinadas a la revisin del

proceso de la gestin de la disponibilidad para mejorar su eficiencia.
Las actividades de gestin de la disponibilidad se representan en el esquema de la

figura 6.3.8, que simula un esquema legendario de ITIL v2 para la gestin de la
continuidad.
GESTIN DE LA DISPONIBILIDAD
Poltica
Inicio Definicin e inicio
del proyecto
Requerimientos Evolucin de riesgos

y estrategia Determinar requisitos
PLANIFICAR
Disear para la
Implementacin
disponibilidad
Disear para
Verificar la seguridad Planificar las paradas
la recuperacin
Generar el plan de disponibilidad
Gestin Mtricas
operativa Supervisar la Investigar y mejorar
Monitorizar
disponibilidad la disponibilidad SUPERVISAR
Informes
Actualizar el plan de disponibilidad
Mejora del proceso

Fuente: Libros ITIL Provisin de Servicio y Diseo del Servicio publicados por OGC y e.p.
Figura 6.3.8. Actividades de la gestin de la disponibilidad

La salida tangible principal de la gestin de la disponibilidad es el documento

denominado plan de disponibilidad. Tambin quedan claramente identificadas
las funciones vitales del negocio (VBF). Se generan las directrices de diseo y la
arquitectura para la disponibilidad. Asimismo, se producen los informes de segui-
miento sobre la disponibilidad y tiempo de respuesta obtenidos de los servicios.
Como salidas secundarias se producen el documento de requisitos de disponibili-
dad a cumplir; los requisitos y las especificaciones para la monitorizacin de la dis-
ponibilidad, con los umbrales y alarmas correspondientes; el plan de paradas plani-
ficadas (PSO); los resultados para el anlisis de riesgos; y los resultados tcnicos de
las investigaciones forenses de las indisponibilidades o fallos ocurridos.
Requerimientos y estrategia de la disponibilidad

Despus de la fase de inicio, en la que se definen las polticas y el plan de proyecto
para implantar el proceso de disponibilidad, comienza la fase de requisitos y estra-
tegia. En esta fase se realiza el anlisis de los riesgos y se determinan los requisitos
a cumplir en cuanto a la disponibilidad. Las actividades son:
Realizar la evaluacin de riesgos. Para realizar el anlisis de riesgos de prdidas
de disponibilidad existen varias tcnicas o mtodos implantados en el mercado.
Normalmente se suele utilizar CRAMM. La evaluacin de los riesgos utiliza mto-
dos similares en disponibilidad y en continuidad, pero el objeto del anlisis es dis-
tinto. En el primero se identifican los fallos normales que puedan producir indis-
ponibilidad, y en el segundo se identifican los eventos especiales que generen una
grave prdida. Por otra parte, las contramedidas que se deben implantar tambin
suelen ser diferentes.
En esta actividad se identifican tambin las funciones vitales del negocio (VBF),
aqullas cuyo fallo causaran una grave prdida en el negocio. Si se est implan-
tando tambin la continuidad, esta actividad es comn a ambas disciplinas.
A partir de la definicin de las VBF, el tratamiento y la concepcin de la disponibi-
lidad, los servicios de TI se suelen dividir en dos grandes bloques: los servicios cr-
ticos que soportan una o varias VBF, que son tratados con el mejor de los esmeros,
y el resto de servicios. Esta divisin permitir concentrarse especialmente en los
servicios que realmente importan al negocio, y puede dar lugar a plantear arquitec-
turas, presupuestos o estrategias de sourcing completamente distintas para cada uno
de los bloques.
Determinar los requisitos de disponibilidad. Se deben establecer los requisitos
que deben cumplir los servicios en cuanto a la disponibilidad y tiempo de res-
puesta, estructurados por tipo de funcionalidad y criticidad. Estos valores, o rangos
99,99%

de valores, servirn de entrada en la negociacin de los acuerdos del nivel de servi-

cio y, consecuentemente, en el diseo tcnico y del soporte de los mismos.
A este respecto, las Normas ISO/IEC 20000 son claras en sus exigencias, especifi-
cando que los requisitos se establezcan teniendo en cuenta los planes de negocio,
los SLA y las evaluaciones del riesgo realizadas. Los requisitos deben incluir los
derechos de acceso a los servicios, los tiempos de respuesta necesarios y la disponi-
bilidad integral de los servicios.
UNE-ISO/IEC 20000-1
Se deben identificar los requisitos de disponibilidad y de continuidad del servicio

sobre la base de los planes de negocio, los SLAs y las evaluaciones del riesgo. Los
requisitos deben incluir los derechos de acceso y los tiempos de respuesta, as como,
la disponibilidad extremo a extremo de los componentes del sistema.
ISO/IEC 20000-2 recomienda, adems, que se dote de los recursos necesarios para
poder satisfacer estos requisitos en cualquier circunstancia. Insta tambin a que se
trabaje de forma integrada entre la gestin de la disponibilidad y la continuidad.
Tambin detalla el concepto de extremo a extremo mencionado en la parte 1,
incluyendo todos los elementos que sustentan el servicio con independencia de
quin dependan: del proveedor principal o bajo el control, bien del propio cliente,
o de otros proveedores de servicio.
UNE-ISO/IEC 20000-2
Generalidades cadas graves del servicio. El proveedor

del servicio debera planificarse para
Los requisitos de continuidad y disponi-
satisfacer los datos conocidos de incre-
bilidad se deberan identificar sobre la
mentos o decrementos de volumen de
base de las prioridades del negocio del
usuarios, picos o cadas previstos de la
cliente, los acuerdos de nivel de servicio
demanda y cualquier otro cambio futuro
y los riesgos evaluados. El proveedor
conocido. Los requisitos deberan incluir
del servicio debera mantener una capa-
los derechos de acceso y los tiempos de
cidad suficiente para el servicio junto
respuesta as como la disponibilidad de
con planes fcilmente realizables, dise-
los componentes del sistema.
ados para asegurar que los requisitos
acordados pueden ser alcanzados en La gestin de la disponibilidad y continui-
todas las circunstancias, desde el fun- dad del servicio debera trabajar conjun-
cionamiento habitual hasta los casos de tamente con el objetivo de asegurar que
se mantengan los niveles de servicio Los procesos que aseguran que se man-
acordados. Estos requisitos deberan tiene la disponibilidad requerida, debe-
tener una influencia capital en las accio- ran incluir aquellos elementos de la
nes, esfuerzos y recursos destinados para provisin del servicio que estn bajo el
satisfacer la disponibilidad de los servi- control bien del propio cliente o de
cios que los soportan. otros proveedores del servicio.
Los requisitos de disponibilidad deben estar recogidos en trminos y condiciones

cuantificables para evitar cualquier confusin o malentendido entre el negocio y la
organizacin de TI. La cuantificacin de la disponibilidad permitir determinar las
necesidades y los costes para alcanzar los niveles de servicio necesarios.
Los requisitos de disponibilidad deben especificar:
Las funciones clave o vitales para el negocio.
El impacto sobre el negocio causado por la prdida de los servicios.
El grado en el que el negocio puede tolerar una cada o degradacin de un
servicio.
Descripcin de la importancia relativa de los diferentes horarios de trabajo
para cada servicio.
El porcentaje de disponibilidad mensual mnimo admisible por el negocio
para los servicios. En ocasiones se detalla tambin para los servicios crticos
la parada mxima en minutos admisible por franja horaria.
Las condiciones bajo las cules el negocio considera que un servicio no est
disponible, incluyendo el lmite permitido del tiempo de respuesta en
segundos.
Las franjas horarias necesarias para los servicios y las ventanas de manteni-
miento.
Las necesidades especficas de seguridad.
La aceptacin de estos requisitos conlleva la definicin de la estrategia a cumplir

por el proceso de disponibilidad. Los requisitos pueden variar segn la criticidad
del servicio, y estar balanceados con el escenario econmico del negocio y el coste
de la tecnologa necesaria para cumplirlos. Estos requisitos formarn parte de la
definicin de los servicios y estarn recogidos en los correspondientes SLA.
99,99%

Implementar la disponibilidad
Definidos los requisitos que se deben cumplir, se inicia la fase de implementar el
proceso (o subproceso) de gestin de la disponibilidad. En la implementacin
se realizan las actividades siguientes: disear para la disponibilidad, disear para la
recuperacin, verificar la seguridad, planificar las paradas y mantenimiento, y generar
el plan de disponibilidad.
Disear para la disponibilidad. A la hora de disear un servicio o de realizar una

modificacin, uno de los aspectos siempre presentes sern los requisitos de dispo-
nibilidad. La finalidad del diseo es crear una infraestructura robusta de TI que
pueda cumplir los niveles de disponibilidad demandados.
A partir de los requisitos, se establecen las directrices y los estndares de disponibilidad
del servicio que habrn de cumplirse en los diseos, tanto por el desarrollo de aplica-
ciones, como en la construccin de las infraestructuras hardware y software asociadas.
El diseo debe proporcionar soluciones que garanticen la disponibilidad requerida por
cada tipo de servicio, as como, el tiempo de respuesta en situaciones pico de carga.
En la figura 6.3.9 se muestra la frmula tpica de la disponibilidad y lo que sta
representa en tiempo de parada mensual acumulado. Ntese que cuanto menor es
el horario de servicio, una misma tasa de disponibilidad permite un tiempo acumu-
lado de parada menor.
Clculo de la disponibilidad
Tiempo real de servicio

% disponibilidad = x 100
Tiempo esperado de servicio
Tiempo mensual de cada permitido (horas)
Perodo de servicio: 24 x 7 24 x 5 12 x 5
Horas/mes de servicio: 720 horas 480 horas 240 horas
% disponibilidad:
99,999% 25,92 seg 17,28 seg 8,64 seg
99,99% 4,32 min 2,88 min 1,44 min
99,98% 8,64 min 5,76 min 2,88 min
99,90% 43,2 min 28,8 min 14,4 min
99,00% 7,2 horas 4,8 horas 2,4 horas
98,00% 14,4 horas 9,6 horas 4,8 horas
95,00% 1,5 das 24 horas 12 horas
Figura 6.3.9. Clculo de la disponibilidad

Es recomendable, dentro del diseo, acometer la definicin de una o varias arqui-

tecturas, que establecern la forma homognea de construir los servicios. Una vez
fijadas las directrices tecnolgicas en la arquitectura, se implementan en una o
varias plataformas (hardware, software y comunicaciones), sobre las que se irn
incorporando los servicios. Explotar los servicios sobre una plataforma comn
tiene mxima importancia en la actualidad, teniendo en cuenta las tendencias de
consolidacin de infraestructuras y la virtualizacin del equipamiento (servidores y
almacenamiento). La actividad tcnica necesaria en este proceso ser realizada por
los grupos tcnicos: arquitectos, tcnicos de sistemas, especialistas, etc., trabajando
a tiempo parcial para el proceso.
Para cada servicio, o por lo menos para los crticos, conviene realizar el anlisis del
rbol de fallos (FTA, Fault Tree Analysis) con el fin de identificar los puntos nicos
de fallo (SPOF, Single Point Of Failure). Esta identificacin de vulnerabilidades y
puntos dbiles permitir eliminarlos o mitigarlos en la fase de diseo, antes de su
construccin.
Disear para la recuperacin. Dentro de las actividades que se realizan en el diseo

del servicio est la de disear para la recuperacin. Se trata de una actividad proac-
tiva cuyo objetivo es identificar aquellos elementos que, ante un fallo, tienen que
volver a prestar servicio lo antes posible. La gestin de la disponibilidad tambin
debe fijar las pautas de actuacin que deben seguirse, cuando un incidente afecta a
los componentes crticos del servicio, para el restablecimiento de las operaciones.
El diseo para la recuperacin contempla la identificacin de las necesidades de
informacin que tiene el negocio para permitirles gestionar el impacto del fallo, y
las necesidades de la propia organizacin de TI en cuanto a procesos, procedimien-
tos y herramientas y soporte externo para que pueda ejecutar la recuperacin.
Verificar la seguridad. La gestin de la disponibilidad se ocupa de la disponibili-

dad de todos los componentes de los servicios de TI, incluidos los datos. Por tanto,
la gestin de la disponibilidad est estrechamente relacionada con el proceso de
gestin de la seguridad de la informacin. Asegura que se implantan las medidas
de seguridad adecuadas en los componentes del servicio.
Los requisitos de seguridad identificados se transmiten al responsable de la gestin
de la seguridad. Entre ellos se encuentran:
Los productos y servicios deben estar nicamente a disposicin del personal
autorizado. Esto tambin es aplicable a los datos gestionados.
Los productos y servicios deben poder recuperarse despus de un fallo para
garantizar que no se compromete la confidencialidad y la integridad, y que
la disponibilidad del servicio no vuelve a peligrar.
99,99%

Se deben poder recuperar los productos y servicios dentro de unos parme-

tros seguros, es decir, que no debe comprometerse la poltica de seguridad
de TI existente en la organizacin
Estos compromisos forman parte de los requisitos de disponibilidad de los servi-

cios. Adems, se propone que estos requisitos queden recogidos en un acuerdo
interno entre gestin de la disponibilidad y la gestin de la seguridad.
Planificar las paradas (PSO, Projected Service Outage). Parte de la gestin de la dis-
ponibilidad es la gestin del mantenimiento del servicio (planificacin de las para-
das) tanto a efectos propios del mantenimiento como para la incorporacin de
cambios. Organiza las actividades de mantenimiento dentro de los perodos y ven-
tanas (planificaciones de parada para el mantenimiento de los sistemas o para la
implantacin de cambios) en los que se minimiza el impacto sobre la disponibili-
dad del servicio.
Se genera el plan de paradas planificadas (PSO) en el que se definen los perodos
diarios, semanales o mensuales en los que se pueden parar los servicios. Se trata de
un elemento bsico para minimizar el impacto en el negocio de estas actividades.
Adems, las ventanas de parada se suele excluir en el clculo de la disponibilidad
real del servicio.
Generar el plan de disponibilidad. El plan de disponibilidad es un plan a

futuro que cubre un perodo de entre uno y dos aos. Su objetivo es mejorar la
disponibilidad general de la infraestructura de TI para asegurar que se pueden
alcanzar los niveles de disponibilidad de una manera eficiente, tanto actuales,
como futuros.
Este plan es uno de los resultados principales del proceso que aglutina toda la infor-
macin generada en l. Conviene distinguirlo del proyecto de implementacin del
propio proceso de gestin de la disponibilidad (vase la fase de inicio). Los conte-
nidos tipo del plan de disponibilidad se muestran en la figura 6.3.10.
Gestin operativa de la disponibilidad

Una vez implantados los servicios y puestos en produccin, el proceso de gestin
de la disponibilidad se mantiene activo y vigila diariamente los servicios, en cuanto
a los aspectos de disponibilidad y tiempo de respuesta. La gestin operativa com-
prende las actividades de supervisin de la disponibilidad, la investigacin de la
causa de los fallos para mejorar la disponibilidad y la actualizacin del plan de dis-
ponibilidad.
Plan de disponibilidad
3 Poltica de disponibilidad.
3 Riesgos identificados.
3 Requisitos de la disponibilidad y estrategia.
3 Funciones vitales del negocio (VBF).
3 Directrices de diseo de servicios.
3 Arquitectura de los servicios enfocada a la
disponibilidad y tiempo de respuesta.
3 Definicin de las plataformas tecnolgicas que se
van a utilizar.
3 Horarios de los servicios.
3 Plan de recuperacin y procedimientos.
3 Plan de paradas planificadas (PSO). Ventanas de
mantenimiento y cambio.
3 Requisitos de seguridad.
3 Herramientas de monitorizacin.
3 Mtricas de disponibilidad que se van a utilizar.
3 Modelos de informes de disponibilidad.
3 Fijar los mtodos y tcnicas de anlisis a utilizar.
3 Planificacin de la mejora de la disponibilidad.
3 Anlisis tendencias tecnolgicas.
Figura 6.3.10. Contenido tipo de un plan de disponibilidad y

del plan de recuperacin asociado
Supervisin de la disponibilidad. Vela por que se cumplan los compromisos de

disponibilidad de los servicios. Para ello establece las mtricas de la disponibilidad,
gestiona la implementacin de las herramientas de monitorizacin para la obten-
cin de las mtricas y confecciona los informes de disponibilidad.
Como se indica en ISO/IEC 20000, se debera registrar la disponibilidad del servi-
cio. Las mediciones se utilizan para comparar los resultados con los valores estable-
cidos en los SLA y analizar los posibles incumplimientos. Esto se realiza de forma
conjunta con gestin de nivel de servicio.
99,99%

UNE-ISO/IEC 20000-1
La disponibilidad se debe medir y registrar. Se debe investigar la no disponibilidad

no planeada y se deben llevar a cabo las acciones necesarias.
Nota: Cuando sea posible, se deben predecir problemas potenciales y tomar medidas preventivas.
Estas medidas e informes de disponibilidad deben reflejar las perspectivas del nego-
cio, de los usuarios y de la organizacin de soporte. Se analizan las tendencias y
posibles desviaciones, se estudian las tendencias de la disponibilidad de los compo-
nentes de la infraestructura y se comunican los resultados a las partes interesadas.
UNE-ISO/IEC 20000-2
Actividades y supervisin de la d) documentar y revisar las no con-

disponibilidad formidades;
La gestin de la disponibilidad debera: e) predecir la disponibilidad a futuro;
a) supervisar y registrar la disponibi- f) cuando sea posible, se deberan

lidad del servicio; predecir los posibles problemas y
llevar a cabo las acciones preven-
b) mantener datos histricos precisos;
tivas.
c) realizar comparaciones con los
requisitos definidos en los SLA Se debera asegurar la disponibilidad
para identificar no conformidades de todos los componentes del servicio,
con los objetivos de disponibili- registrando y llevando a cabo las accio-
dad acordados; nes correctivas.
Investigar y mejorar la disponibilidad. Consiste en revisar la disponibilidad

de los servicios y los componentes para identificar las reas de incumplimiento o de
perfeccionamiento. La investigacin se centra en identificar las reas de mejora en
los servicios para que los valores de disponibilidad se incrementen. Las mejoras se
incorporan en el plan de disponibilidad y en el plan de mejora unificado de los pro-
cesos y de los servicios (vase el captulo 4).
Es conveniente aclarar la frontera entre la gestin del problema y la investigacin
de la disponibilidad con el fin de evitar conflictos de intereses. La investigacin de
la disponibilidad puede conllevar la necesidad de abrir un problema que ser tra-
tado bajo la gestin del problema. La gestin del problema parte de un incidente o
de un conjunto de ellos para determinar la causa raz que lo provoc y resolverlo
provisional o definitivamente. La investigacin de la gestin de la disponibilidad

va ms all de la causa de los incidentes, es ms general. Se mueve por estadsticas,
informes, tendencias o incumplimientos, para proponer soluciones. La gestin del
problema tambin tiene una parte proactiva que tambin investiga las tendencias.
Los aspectos que analiza la investigacin de la disponibilidad tienen relacin con:
Las tendencias de la gestin de la disponibilidad.
Un deterioro gradual de las mediciones de la disponibilidad.
La incapacidad de un servicio para satisfacer la disponibilidad requerida.
La identificacin de perodos de inestabilidad del servicio.
Tiempos de recuperacin y restauracin del servicio inaceptables.
Solicitudes por parte del negocio para incrementar el nivel de disponibilidad.
La solicitud, por parte de la gestin de niveles de servicio, para mejorar la
disponibilidad como parte de un programa de mejora del servicio.
Actualizar el plan de disponibilidad. De forma peridica, y por lo menos una vez

al ao, se debe actualizar el plan de disponibilidad realizando una revisin completa
de su contenido, desde la poltica hasta el anlisis de tendencias tecnolgicas. Ade-
ms, se actualiza de forma continua con los cambios que se vayan realizando en la
infraestructura, identificados a travs del proceso de gestin del cambio.
ISO/IEC 20000-1 es clara a este respecto e incluye tambin en los requerimientos
a los planes de continuidad:
UNE-ISO/IEC 20000-1
Los planes de disponibilidad y continuidad del servicio se deben desarrollar y revisar

al menos una vez al ao, para asegurar que los requisitos cumplen lo acordado bajo
todas las circunstancias, desde la normalidad hasta la prdida grave del servicio.
Estos planes se deben mantener para asegurar que reflejan los cambios acordados,
requeridos por el negocio.
Los planes de disponibilidad y de continuidad del servicio se deben probar de nuevo

cuando se produzca un cambio importante en el entorno del negocio.
El proceso de gestin del cambio debe evaluar el impacto de cualquier cambio

sobre los planes de disponibilidad y de continuidad del servicio.
99,99%

Mejora del proceso de disponibilidad

Se debe revisar el propio proceso para mejorar su operativa y subsanar sus fallos e
ineficiencias. Las mejoras propuestas pueden estar relacionadas con alguna de las
actividades del proceso o con otros procesos, por ejemplo, la gestin de nivel de
servicio. Nuevamente, las mejoras se centralizan en el plan de mejora unificado
(vase el captulo 4).
Entradas, actividades y salidas del proceso de gestin de

la continuidad de TI
La misin de la gestin de la continuidad de TI es preparar las infraestructuras y su
gestin para que resistan y sobrevivan a las consecuencias de un suceso catastrfico
o devastador en la empresa, como por ejemplo, un incendio, una inundacin en el
centro de datos, una contaminacin masiva de servidores por virus, un ataque exte-
rior, un terremoto, actos vandlicos, etc. Estos hechos pueden parecer remotos o
de probabilidad muy baja, pero TI no est tan a salvo como cree. Una simple
rotura de una tubera puede inundar el centro de datos o provocar un desastre elc-
trico. Los ataques de los virus estn a la orden del da. Que se contaminen los ser-
vidores es un suceso cada vez ms probable.
La gestin de la continuidad de los servicios de TI se centra en garantizar el cum-
plimiento de los requisitos acordados tras una interrupcin del negocio provocado
por una catstrofe.
La gestin de la continuidad tambin est desarrollada en la normativa internacional.
La serie de normas britnicas BS 25999 (Business continuity management) definen los
requisitos para un sistema de gestin de continuidad de negocio en base a un cdigo
de buenas prcticas (parte 1) y unas especificaciones tcnicas (parte 2) que son certifi-
cables. Tambin existe normativa al respecto en Japn, Australia, Singapur, Austria, etc.
La gestin de la continuidad trabaja en la preparacin anticipada y en el manteni-
miento permanente. Por ello, sus actividades se pueden considerar divididas en dos
grandes bloques: la planificacin e implementacin y la gestin operativa de la
misma. El primer bloque define claramente la estrategia e implementa las medidas
de salvaguardia. Este bloque se suele realizar como un proyecto de consultora e
implantacin. Dado que la continuidad de TI parte de un plan de continuidad del
negocio, la definicin de la estrategia se entiende que la debe liderar algn rea de la
empresa, normalmente la de seguridad general. En el segundo bloque, la actividad
se centra en mantener siempre frescos, en la mente de todos, los planes de continui-
dad y en estar preparado para responder inmediatamente a una contingencia.
En la gestin de la continuidad se ha seguido la misma estructura de actividades

planteada en ITIL. Las interacciones y funcionalidades de la gestin de la continui-
dad se resumen en la figura 6.3.11.
CONTINUIDAD
Desencadenantes 3 Inicio: Salidas principales:

del proceso: Definir poltica continuidad. Plan de continuidad.
Plan de continuidad del mbito de la continuidad. Contratos de servicios
negocio. externos de continuidad.
Definicin e inicio proyecto
Contingencia severa. continuidad. Procedimientos y
Fecha de pruebas. medios operativos de
3 Requerimientos y estrategia:
Fecha revisin del plan. recuperacin.
Anlisis impacto en el negocio.
Infraestructura
Entradas de soporte: Evaluacin de riesgos. preparada.
Acuerdos continuidad Definicin estrategia Personal entrenado.
en SLA. continuidad.
Informes resultados
Riesgos. 3 Implementacin: pruebas de continuidad.
Presupuestos. Realizacin plan continuidad
Salidas secundarias:
Cambios. de TI.
Requisitos de continuidad.
CMDB. Desarrollo plan recuperacin.
Plan proyecto continuidad.
Informacin tcnica. Implementar medidas
recuperacin. Funciones vitales de
negocio (VBF).
Implementar medidas
reduccin riegos. Evaluacin de riesgos.
Desarrollar procedimientos.
Pruebas iniciales.
3 Gestin operativa:
Educacin y concienciacin.
Revisin y auditora.
Pruebas.
Control de cambios.
Formacin.
Aseguramiento.
Gestin las contingencias
en TI.
3 Mejora del proceso
Figura 6.3.11. Entradas, actividades y salidas de la gestin de la continuidad

99,99%

Las entradas que desencadenan o activan el proceso son: la realizacin del plan de
continuidad de negocio por parte de la empresa, que requiere de TI la realizacin
de su contribucin a este plan; el acaecimiento de una contingencia severa que
activa la ejecucin de los procedimientos de continuidad; la llegada de la fecha pre-
vista de pruebas de continuidad, que inicia el protocolo de pruebas; y la proximi-
dad de la fecha de revisin del plan de continuidad.
Las entradas ms relevantes que utiliza el proceso como informacin de soporte
son: las condiciones solicitadas o pactadas con los clientes en los acuerdos de nivel
de servicio (SLA); la informacin de los principales riesgos que amenazan a TI; los
presupuestos asignados a la continuidad, que condicionan las inversiones; los cam-
bios realizados en las infraestructuras o los servicios que deban contemplarse en las
soluciones de continuidad; la informacin sobre los elementos de configuracin
contenida en la CMDB; y la informacin tcnica diversa para proporcionar solu-
ciones o directrices.
Las actividades del proceso se estructuran en 5 grupos:
Inicio. El primer paso es determinar sobre qu aspectos del negocio y de los
servicios va a actuar la continuidad de TI y sobre cules no.
Definir poltica continuidad. Directrices y objetivos que establece la
direccin y principales responsabilidades.
mbito de la continuidad. Localizaciones, unidades de negocio o servi-
cios que se deben cubrir. Normalmente no se debera restringir el mbito.
Definicin del proyecto de continuidad. Plan detallado del proyecto de
implementacin de la continuidad (de TI). Designacin del responsable
mximo de plan y de los responsables en cada departamento o rea. Pre-
supuesto para la definicin del plan. Posteriormente se tendr que hacer
una dotacin adicional de presupuesto para la implantacin de la solucin
de continuidad. Organizacin de proyecto y estructura de control. Plan de
calidad del mismo. Lanzamiento del proyecto.
Requerimientos y estrategia. Determinar los requisitos de continuidad del

negocio, as como la estrategia que se debe seguir para garantizar dicha con-
tinuidad.
Anlisis del impacto de un desastre. Repercusin en las infraestructuras
y en el negocio de los diversos tipos de paradas que pueden ocurrir. Iden-
tificacin de las funciones vitales del negocio (VBF) si no se han determi-
nado previamente.
Evaluacin de riesgos. Estudio detallado de las amenazas y vulnerabili-
dades posibles y de la probabilidad de su ocurrencia.
Definicin de la estrategia de continuidad. Definicin de la estrategia

de TI para mantener la continuidad de los procesos de negocio en caso de
ocurrir un desastre.
Implementacin. Elaborar los planes de continuidad y poner en marcha las

contramedidas necesarias para reducir el riesgo y desplegar las soluciones de
TI para mitigar el riesgo y recuperar el negocio en caso de desastre.
Realizacin del plan continuidad de TI. Realizacin de todos los estu-
dios, anlisis y diseos necesarios y confeccin de este documento esencial
de la continuidad.
Desarrollo plan de recuperacin. Definicin de todas las medidas nece-
sarias para poder realizar la recuperacin, abarcando personas, infraestruc-
turas y servicios externos necesarios.
Implementar las medidas de recuperacin. Adquirir, construir y poner
en funcionamiento las soluciones definidas.
Implementar las medidas de reduccin riegos. Puesta en marcha de las
contramedidas para la reduccin de la exposicin a las amenazas o de sus
efectos.
Desarrollar los procedimientos. Instrucciones detalladas de actuacin
para cada uno de los servicios y grupos de soporte.
Realizar las pruebas iniciales. Pruebas completas y detalladas de las solu-
ciones implementadas, antes de dar por concluida la implementacin
Incluyen a las personas, infraestructuras y servicios externos. Control final
de la calidad.
Gestin operativa. Realiza el mantenimiento en activo de las soluciones de

continuidad, las pruebas, la formacin y la divulgacin de los planes de con-
tinuidad.
Educacin y concienciacin de todo el personal de TI y del negocio.
Revisin y auditoria sistemtica y peridica de todo el plan y su imple-
mentacin.
Pruebas y simulacros de los planes de recuperacin. Esta actividad, ade-
ms incluye el anlisis de los resultados de las pruebas como punto de
entrada a la mejora.
Control de los cambios en el personal, la infraestructura y los servicios
externos. Actualizacin de los planes. Debe estar siempre coordinado con
el proceso de gestin del cambio.
99,99%

Formacin y entrenamiento del personal que deber intervenir en los pla-

nes de recuperacin y de reduccin de riesgos.
Aseguramiento, confianza o garanta a la direccin sobre la fiabilidad de
los planes y las medidas implementadas.
Gestin de las contingencias en TI. Ocurrida la contingencia, ejecucin
de lo previsto en el plan de continuidad y recuperacin, para retornar a la
normalidad cuanto antes.
GESTIN DE LA CONTINUIDAD
Poltica de continuidad
mbito de la continuidad
Inicio
Definicin e inicio
del proyecto
Anlisis del impacto

BIA, VMF
en el negocio
Requerimientos
y estrategia Evolucin de riesgos M_o_R, CRAMM
Estrategia de continuidad
Realizar el plan de
Plan de continuidad TI
continuidad de TI
Implementar medidas Desarrollar planes Implementar medidas

Implementacin de recuperacin de recuperacin reduccin del riesgo
Desarrollar los procedimientos
Pruebas iniciales
Gestin Revisin y Pruebas Control de

operativa auditora los cambios
Educacin y
concienciacin Formacin
Aseguramiento
Gestin de las contingencias en TI
Mejora del proceso

Figura 6.3.12. Esquema de las actividades de la gestin de la continuidad de TI

Mejora del proceso. Identificar y poner en marcha aquellas acciones que

contribuyan a incrementar la eficacia del proceso.
Las actividades de la gestin de la continuidad se representan en el grfico de la

figura 6.3.12, un clsico de ITIL.
Las salidas principales del proceso son el plan de continuidad; los contratos de servi-
cios externos de continuidad; el plan de recuperacin con los procedimientos y
medios de recuperacin operativos; la infraestructura de TI preparada para resistir
y recuperarse ante un desastre; el personal de TI perfectamente entrenado; y los
informes de los resultados de las pruebas de continuidad.
Como salidas secundarias del proceso se obtienen las polticas y los requisitos de
continuidad definidos; el plan de proyecto para la implementacin de la continui-
dad; las funciones vitales de negocio (VBF); los resultados de la evaluacin de los
riesgos, etc.
Determinar el mbito de la continuidad

El estudio para la continuidad implica considerar la organizacin de forma com-
pleta definiendo y comunicando la poltica de continuidad (junto con el compro-
miso de la direccin), seleccionando la aproximacin y mtodos para la evaluacin
de riesgos y el anlisis de impacto en el negocio, dedicando recursos y estableciendo
la correspondiente organizacin de proyecto.
Como resultado de esta actividad se identifica el alcance de la continuidad, es decir,
hasta dnde va a llegar la gestin de la continuidad, es decir, qu servicios y hasta
qu nivel van a estar amparados por la gestin de la continuidad.
El alcance esperado de la gestin de la continuidad debe abarcar a todos y cada uno
de los servicios y toda la informacin gestionada. La organizacin de TI no debe
jugar a los dados con la informacin de la empresa y dejar sin cobertura algunos
servicios o informacin, para que el azar determine su permanencia en caso de una
contingencia, por poco relevantes que sean. Por eso, la cobertura de la gestin de la
continuidad debera comprender absolutamente todos los servicios de TI, los crti-
cos y los no crticos, pero con soluciones tcnicas y niveles de recuperacin distin-
tos, adecundolos a los presupuestos disponibles. Poniendo primeramente el foco
en los servicios crticos, para abordar posteriormente los servicios menos crticos.
No hay justificacin para dejar excluido nada, pues en el extremo ms econmico
de las soluciones de continuidad est la cobertura mediante una simple copia de
seguridad completa de sistemas y de los datos, custodiada en instalaciones separadas.
99,99%

Requerimientos y estrategia de la continuidad

Una vez establecido el mbito y el alcance que se va a dar a la continuidad y lan-
zado el proyecto de implementacin, se inicia una etapa en la que el contacto y las
relaciones con todas las reas de la empresa tiene gran importancia. Su objetivo es
determinar los requisitos y la estrategia que se debe seguir en la implementacin.
Lo habitual es que esta actividad se realice dentro del plan general de continuidad
del negocio, en el que TI participara como un rea ms.
En esta etapa de requerimientos y estrategia se realiza:
El anlisis del impacto al negocio y la identificacin de las funciones vitales
del mismo.
La evaluacin de riesgos, amenazas y contramedidas posibles.
La definicin de la estrategia de continuidad de negocio que se debe ejecutar
y la definicin de los requerimientos del negocio que se deben cumplir.
Esta informacin servir de entrada al diseo de las soluciones de continuidad.

Dados los altos costes de las soluciones de continuidad de TI y la reducida frecuen-
cia de su utilizacin, es necesario aquilatar bien los requerimientos, siendo cons-
cientes de que la reduccin del tiempo objetivo de recuperacin (RTO, Recovery
Time Objective) de horas a minutos puede triplicar el coste de las infraestructuras
necesarias. Por ello, se recomienda realizar un anlisis iterativo entre impacto en el
negocio, los riesgos, los requisitos y el coste de las soluciones posibles, para llegar
a un punto de consenso con toda la organizacin.
El anlisis del impacto en el negocio, conocido como BIA (Business Impact Analysis),
permite determinar las prdidas que puede soportar una organizacin como conse-
cuencia de la parada de los servicios. Tambin cuantifica la magnitud de las prdi-
das en funcin del tiempo que dure la parada de los servicios del negocio. El BIA
debe identificar con claridad:
Las funciones o procesos crticos del negocio, conocidos como VBF (Vital
Business Functions).
La magnitud de los daos o prdidas que puede soportar una empresa como
consecuencia del bloqueo de estos procesos crticos de negocio (umbral de
riesgo de la empresa).
En la figura 6.3.13 se muestra un ejemplo de contenido del anlisis del impacto en

el negocio.
Anlisis del impacto en el negocio (BIA)
3 Descripcin de la actividad principal del negocio.

reas principales.
3 Funciones vitales del negocio (VBF).
3 Cuantificacin de las prdidas potenciales:
Prdida de ingresos inmediatas y a largo plazo.
Costes adicionales.
Prdida de reputacin.
Prdida de relaciones comerciales.
Prdida de ventaja competitiva.
Prdidas por incumplimiento de normativa.
Prdida de la capacidad operativa.
3 Evolucin de las prdidas con el tiempo (minutos,
horas, das). Perodos con mayor impacto.
3 Evaluacin de los recursos mnimos para continuar
las operaciones de las funciones vitales del negocio.
3 El plazo mnimo en el que se deberan recuperar
los servicios (RTO), en condiciones mnimas y
en operacin normal.
3 El perodo de informacin perdida que es admisible
por el negocio (RPO).
3 Prioridades del negocio en la recuperacin de las
funciones vitales.
Figura 6.3.13. Estructura tipo del BIA
La descripcin de las funciones vitales del negocio es una actividad clave, que ser
de utilidad para la continuidad, pero tambin para la disponibilidad y para la segu-
ridad. En la figura 6.3.14 se muestra una ficha de ejemplo para la descripcin de
estas funciones de negocio.
La evaluacin de riesgos permite identificar la posibilidad de que ocurra un desas-
tre o alguna interrupcin grave de los servicios. Ofrece una evaluacin de la proba-
bilidad de que ocurra el suceso y la vulnerabilidad o exposicin de la organizacin
99,99%

Funciones vitales de negocio (VBF)

% prdida
ingresos Rendimiento
Prdida Tiempo
+10 d
Funcin Impacto datos parada Valor Valor
Criticidad
2d
5d
2h
1d
de negocio negativo admisible admisible normal mnimo
Denominacin,
descripcin de
la actividad y
su importancia
para la empresa
RPO RTO
Estimacin econmica del impacto Valores lmite Rendimientos

si fallase la funcin de negocio admisibles por de la funcin de
el negocio de prdida negocio, normal
sin impacto o con y el mnimo
Clasificacin en cuanto a la impacto leve admisible
importancia de la funcin para
la actividad de la empresa
Figura 6.3.14. Ficha ejemplo para la descripcin de las VB
al mismo. La metodologa de evaluacin del riesgo es la misma para la continui-

dad, para la disponibilidad o para la seguridad y, aunque la disciplina es similar, los
conceptos analizados son diferentes: fallo extraordinario de los servicios, fallo coti-
diano de los servicios y fallo en la seguridad. En todos ellos se realiza la:
Identificacin de los riesgos.
Evaluacin de los activos y sus niveles de vulnerabilidad y amenazas.
Evaluacin de los niveles de riesgo.
Gestin del riesgo: contramedidas, priorizacin, etc.
En el anlisis de los riesgos se puede utilizar la metodologa CRAMM 1 centrada en

la identificacin de los activos, las amenazas y las vulnerabilidades. Una vez identi-
ficados los riesgos, hay que gestionarlos, identificando las contramedidas justifica-
bles para combatirlos. Para la gestin del riesgo se puede utilizar la metodologa
M_o_R (Management of Risk) que estructura la actividad en 5 etapas: polticas,
1
Vase tambin la Norma ISO/IEC Guide 73. Risk management. Vocabulary. Guidelines for use in
standards.
aproximacin, proceso, institucionalizar y revisar, y comunicar. En la figura 6.3.15

se muestran los esquemas de estas dos metodologas.
CRAMM M_o_R
Gestin de riesgos
Activos Amenazas Vulnerabilidades M_o_R polticas
M_o_R aproximacin:
Polticas gestin de riesgos
Anlisis de riesgos Gua del proceso
Riesgos Planes
Gestin de riesgos
Registros del riesgo
Gestin de logs
M_o_R proceso:
Contramedidas Identificar
Evaluar
Planificar
Implementar
Institucionalizar y revisar M_o_R
Comunicar
Figura 6.3.15. Metodologas de evaluacin y de gestin de riesgos
La evaluacin de los riesgos de contingencia severa en los servicios arroja como

resultados una clasificacin en funcin del nivel de vulnerabilidad de la instalacin,
frente a la probabilidad de ocurrencia del suceso (amenaza). En la figura 6.3.16 se
muestra un ejemplo de la tabla de medicin de riesgos.
Los requerimientos de continuidad se determinan teniendo en cuenta las necesida-
des del negocio, expresadas en el desarrollo del plan de continuidad del negocio, en
reuniones especficas con el negocio y tambin en los requisitos de continuidad
contenidos en los SLA en vigor con los clientes.
La estrategia de continuidad de negocio se define a partir del anlisis del impacto
en el negocio (BIA) y de la evaluacin de los riesgos. La estrategia debe ser el resul-
tado del balance entre las medidas de reduccin del riesgo y las soluciones de conti-
nuidad. La estrategia debe priorizar los servicios por orden de recuperacin, pero
teniendo en cuenta las posibles variaciones dependiendo del momento en el que se
produzca la contingencia.
99,99%

Evaluacin del riesgo
Riesgo = Vulnerabilidad x Amenaza
Terrorismo Pandemia virus

Alta
Terremoto Rotura tubera en CPD

Vulnerabilidad
Media
Incendio Fallo climatizacin

Fallo comunicaciones
Baja
Desbordamiento ros Fallo eclctico exterior

Baja Media Alta
Amenaza
Fuente: Libro ITIL Provisin de Servicio publicado por OGC y e.p.
Figura 6.3.16. Ejemplo de una matriz de evaluacin de riesgos
La Norma ISO/IEC 20000-2 establece claramente los requisitos que se deben con-
siderar en la estrategia de continuidad, indicando adems que se debe revisar por lo
menos una vez al ao, y que los cambios a la misma se deben acordar formalmente.
UNE-ISO/IEC 20000-2
Estrategia de continuidad del servicio siguiente con cada grupo de clientes y

El proveedor del servicio debera des- servicios:
arrollar y mantener una estrategia que a) los perodos mximos aceptables
defina el enfoque general a seguir para de prdida continuada del servicio;
satisfacer las obligaciones de continui-
b) los perodos mximos aceptables
dad del servicio. Esta estrategia debera
de degradacin del servicio;
incluir la evaluacin de riesgos y tener en
cuenta los horarios de servicio acorda- c) los niveles aceptables de degrada-
dos y los periodos crticos del negocio. El cin del servicio durante un periodo
proveedor del servicio debera acordar lo de recuperacin del servicio.
La estrategia de continuidad debera ser Cualquier cambio a la estrategia debe-

revisada con una periodicidad acor- ra ser acordado formalmente.
dada, al menos anualmente.
En la definicin de la estrategia se establecen dos requisitos esenciales para cada

servicio, que servirn de base para determinar las soluciones de continuidad que se
deben establecer:
RPO (Recovery Point Objective) o el punto objetivo de recuperacin, fija el
estado de la informacin que se recuperar despus del desastre, pues siem-
pre habr algo que se puede perder. El RPO determina la frecuencia de las
copias de seguridad o de las soluciones de replicacin remotas de datos.
RTO (Recovery Time Objective) o el tiempo objetivo de recuperacin, esta-
blece el plazo en el que se debera restaurar un servicio. El RTO determina
la arquitectura que se debe seleccionar para la recuperacin. Los plazos
de segundos requerirn soluciones activo-activo. En cambio, los plazos de
semanas permitirn soluciones manuales muy econmicas.
En la figura 6.3.17 se muestra el esquema tpico para explicar el RPO y el RTO.
Figura 6.3.17. Los conceptos de RPO y RTO en continuidad
De cara a la definicin de la estrategia, las principales alternativas de recuperacin

de los servicios de TI se muestran en la figura 6.3.18. Cuanto ms corto es el plazo
99,99%

de recuperacin (RTO), ms cara es la implantacin de la solucin para TI, pero

menos prdidas habr en el negocio.
Fuente: The Definitive Handbook of BCM y e.p.
Figura 6.3.18. Alternativas de recuperacin de los servicios de TI
Siguiendo la clasificacin realizada en ITIL, las principales soluciones de continui-

dad que se pueden considerar son:
Recuperacin inmediata. Proporciona una recuperacin instantnea (mirro-
ring) sin prdida de servicios y sin prdida de informacin apreciable (RPO y
RTO son iguales a cero). Esta solucin se basa en centros de proceso de datos
conectados en activo-activo, es decir, un mismo servicio est ejecutndose de
forma simultnea en ambos centros, con datos sincronizados y balanceando
la carga entre ambos. Las soluciones de procesamiento distribuido entre ml-
tiples servidores y centros de datos (grid computing) son soluciones de alta
resistencia, pero que requieren aplicaciones especialmente adaptadas.
Recuperacin rpida. Conocida como hot standby, est proporcionada por
dos centros de datos conectados y con las aplicaciones cargadas en ambos y
con replicacin de datos entre ellos. Una aplicacin slo est ejecutndose en
uno de los centros y, en caso de necesidad, debe activarse en el otro centro
(de respaldo). Proporciona tiempos de recuperacin inferiores a 24 horas
(RTO), con una prdida de datos (RPO) casi nula si se implementa una
replicacin del almacenamiento por fibra.
Recuperacin intermedia. Conocida como warm standby, utiliza instalacio-
nes de respaldo proporcionadas por terceros. Los plazos de recuperacin
esperados estn normalmente entre las 24 y 72 horas.
Recuperacin gradual. Conocida como cold standby, emplea un centro de
respaldo que nicamente contiene la infraestructura fsica y de conectividad
necesaria. Por lo que, en caso de emergencia, hay que instalar los servidores,
el almacenamiento, las aplicaciones, configurar, etc. Los tiempos de recupe-
racin son superiores a las 72 horas. La informacin se carga desde la ltima
copia de seguridad realizada y llevada a resguardo, por lo que la prdida de
informacin puede ser superior a las 24 horas (RPO).
Acuerdos recprocos. Acuerdos entre empresas u organizaciones para alojar
los servicios en caso de contingencia.
Soluciones manuales. Soluciones provisionales, como por ejemplo, regis-
trar los tickets de incidentes en el service desk en formularios en papel. Tam-
bin comprenden la restauracin de los servicios de forma completa desde
las copias de seguridad.
De acuerdo a los resultados obtenidos en la evaluacin de los riesgos, se desarrolla

un plan general para determinar el alcance especfico que debe tener la continuidad
del negocio. El plan general de continuidad debe ser aprobado por la direccin.
Este plan general se revisa cada vez que hay un cambio en los procesos clave, insta-
laciones, equipos, personal y servicios contratados que pueda producir nuevas inte-
rrupciones con repercusiones en los servicios prestados.
Implementar la continuidad
Una vez establecida la estrategia de continuidad y los requisitos, se pasa a la elabo-
racin del plan de continuidad de TI y a su implementacin. Es necesario que pre-
viamente se haya aprobado el plan general de continuidad del negocio. En la etapa
de implementacin se realizan las siguientes actividades (segn ITIL):
Organizacin y planificacin de la implementacin, que realiza la elabora-
cin y documentacin del plan de continuidad de TI.
99,99%

Implementacin de los acuerdos de recuperacin con suministradores de

servicios.
Desarrollo de los planes de recuperacin para cada servicio, infraestructuras, etc.
Implementacin las medidas de reduccin del riesgo aprobadas.
Desarrollo de los procedimientos detallados de actuacin.
Implantacin de los procedimientos definidos para la recuperacin en los
plazos requeridos.
El plan de continuidad de TI es un documento o estructura documental que

recoge toda la informacin necesaria para implantar las soluciones de continui-
dad y para posteriormente restaurar los servicios. En la figura 6.3.19 se propone
Plan de continuidad de TI
Introduccin Fase de recuperacin servicios

3 Objetivo, alcance y dependencia con otros planes. 3 Plan de alojamiento y de servicios.
3 Polticas. 3 Plan de redes y sistemas informticos.
3 Resumen del anlisis impacto en negocio (BIA). 3 Plan de telecomunicaciones.
3 Funciones vitales (VBF), niveles de servicio 3 Plan de seguridad.
continuidad, RPO y RTO. 3 Plan de personal.
3 Resumen de la evaluacin de riesgos. 3 Plan de administracin y finanzas.
3 Descripcin de la estrategia de continuidad en TI. 3 Relacin de manuales y guas tcnicas y otros
Organizacin y recursos documentos necesarios para la recuperacin.
3 Organizacin: ejecutiva, de coordinacin y de Fase de vuelta a la normalidad
recuperacin. 3 Plan de retorno a la normalidad.
3 Infraestructuras especficas para recuperacin.
Plan de pruebas
3 Servicios externos contratados.
Anexos:
Fase de invocacin
3 Datos de contacto de personal y suministradores.
3 Plan de respuesta a emergencias (procedimientos
notificacin). 3 Descripcin de los centros alternativos de respaldo.
3 Plan de evaluacin de daos. 3 Inventario de infraestructuras.
3 Personas que pueden declarar una emergencia y, 3 Acuerdos de nivel de servicio con suministradores.
consecuentemente, activar el plan. 3 Procedimientos de los equipos de emergencia.
3 Criterios para la activacin del plan de continuidad. 3 Manuales y guas tcnicas.
3 Procedimientos de comunicacin, los equipos de 3 Planes de comunicacin y programas de formacin
emergencia y los suministradores involucrados. del plan.
3 Anlisis impacto en negocio (BIA).
Fase de transicin
3 Relacin de servicios y recursos.
3 Secuencia acciones previas a la recuperacin de los
recursos: traslados, adquisiciones, etc. 3 Relacin de eventos.
3 Plan de salvamento. 3 Alternativas de respaldo (coste, tiempo de activacin
y cobertura).
3 Plan de registros vitales.
3 Plan de gestin de la crisis y de relaciones pblicas.
3 Otros procedimientos fase transicin.
Fuente: Libro ITIL Diseo del Servicio publicado por OGC y Telefnica.
Figura 6.3.19. Estructura ejemplo de un plan de continuidad de TI

esquema del plan articulado en torno al ciclo de vida de la gestin de una con-
tingencia.
En relacin al plan de continuidad, las Normas ISO/IEC 20000 recomiendan una
poltica formal de registro de la documentacin relacionada, la salvaguardia de los
datos de configuracin y, especialmente, de la informacin necesaria para la restau-
racin de los servicios: plan de continuidad, procedimientos, etc.
UNE-ISO/IEC 20000-1
Los planes de continuidad del servicio, la lista de contactos y la base de datos de

gestin de la configuracin deben estar disponibles incluso en el caso de que no sea
posible el acceso normal a las oficinas. El plan de continuidad del servicio debe
incluir la actividad de vuelta a la normalidad.
UNE-ISO/IEC 20000-2
6.3.4 Planificacin y prueba de la

continuidad del servicio d) las copias de seguridad de los
datos, los documentos, el soft-
El proveedor del servicio debera asegu-
ware y cualquier equipo y perso-
rar que:
nal necesario para la restauracin
a) los planes de continuidad tienen del servicio estn disponibles de
en cuenta las dependencias entre forma rpida ante un desastre o
el servicio y los componentes de un fallo importante del servicio;
los sistemas;
e) al menos una copia de todos los
b) se registran y mantienen los pla- documentos relativos a la conti-
nes de continuidad del servicio y nuidad del servicio debera estar
el resto de documentos requeri- almacenada y ser mantenida en
dos para dar soporte a la conti- una localizacin remota y segura,
nuidad del servicio; junto al equipamiento que sea
necesario para permitir su uso;
c) la responsabilidad para activar los
planes de continuidad est clara- f) el personal conoce y asume su rol
mente asignada y los planes esta- para activar y/o ejecutar los pla-
blecen claramente la responsabili- nes y tiene acceso a la documen-
dad para la toma de las acciones tacin relativa a la continuidad
necesarias frente a cada objetivo; del servicio.
99,99%

Como detalle del plan de continuidad se suele generar un plan de recuperacin,

como documento independiente, pues al contener los detalles de las personas de
contacto, procedimientos e instrucciones operativas, su revisin y actualizacin
es muy frecuente. En la figura 6.3.20 se muestra un contenido tipo del un plan de
recuperacin.
Plan de recuperacin
3 Estrategia de recuperacin.
3 Procedimiento de invocacin.
3 Interfaces y dependencias con otros planes.
3 Directrices generales.
3 Dependencias: sistemas, infraestructuras, servicios
externos, etc.
3 Lista de contactos: personal TI, personal otras reas,
direccin, suministradores.
3 Grupo de recuperacin: de TI, de servicios
generales, etc.
3 Lista de comprobacin del grupo de recuperacin.
3 Formulario de evaluacin de daos.
3 Procedimientos de recuperacin:
Recuperacin del service desk.
Recuperacin telecomunicaciones.
Recuperacin de la LAN .
Recuperacin de la WAN.
Recuperacin servidores y almacenamiento.
Recuperacin de datos.
Recuperacin de PC.
Recuperacin alimentacin elctrica.
Recuperacin aire acondicionado.
Comunicacin in situ, etc.
Fuente: Libros ITIL Diseo del Servicio y A Guide to Business Continuity Plan publicados por OGC.
Figura 6.3.20. Contenido tipo de un plan de recuperacin ante un desastre

Gestin operativa de la continuidad

La gestin operativa de la continuidad se centra en mantener actualizados el plan
de continuidad, toda la informacin asociada y a toda la organizacin concienciada
y perfectamente entrenada, adems de la ejecucin del plan de pruebas correspon-
dientes. Las actividades que comprende son:
Educacin y concienciacin de toda la organizacin y, especialmente, en TI.
Revisin y auditoria de los planes y las soluciones: peridicamente, despus
de pruebas o despus de cambios importantes.
Pruebas y simulacros de los planes para comprobar su funcionamiento y
entrenar al equipo humano. Deteccin de acciones de mejora.
Control de los cambios, con el fin de que las soluciones de continuidad estn
siempre vigentes y la informacin actualizada.
Formacin y entrenamiento especfico del personal que deba actuar en las
contingencias.
Aseguramiento o inculcacin de la confianza necesaria en la direccin de que
el plan de continuidad de TI ofrecer los resultados esperados y definidos en
los requerimientos.
Gestin de las contingencias en TI. Activacin del plan de continuidad en el
caso de que ocurra una contingencia severa.
Una vez elaborado el plan de continuidad, debe ser difundido y puesto a disposi-
cin de las partes involucradas. El responsable del plan de continuidad de TI debe
formar al personal a su cargo sobre las actuaciones que se debern realizar en el
caso de que se produzca cualquiera de las situaciones identificadas como de emer-
gencia o desastre.
El responsable del plan establece anualmente un plan de pruebas, donde se definen
las pruebas que se deben llevar a cabo para asegurar la actualizacin y eficacia de
todos los planes de continuidad de la organizacin.
UNE-ISO/IEC 20000-1
El plan de continuidad del servicio debe probarse de acuerdo a las necesidades del
negocio.
Todas las pruebas de continuidad se deben registrar y tras las pruebas fallidas se
deben elaborar planes de accin.
99,99%

UNE-ISO/IEC 20000-2
Los planes de continuidad del servicio y Se deberan llevar a cabo pruebas con
la documentacin relacionada (por una frecuencia suficiente para asegu-
ejemplo los contratos) deberan estar rar que los planes de continuidad son
ligados a los procesos de gestin del efectivos y permanecen as an cuando
cambio y de gestin de los contratos. se producen cambios en los sistemas,
Los planes de continuidad del servicio y procesos, personal y necesidades del
la documentacin relacionada (por negocio. El cliente y el proveedor del
ejemplo los contratos) deberan eva- servicio deberan estar implicados con-
luarse respecto al impacto previamente juntamente en las pruebas, basadas en
a que se aprueben los cambios en el un conjunto acordado de objetivos.
sistema y en el servicio, y previamente a Los fallos en las pruebas se deberan
acordar los nuevos requisitos del cliente documentar y revisar para proveer de
o bien cambios en stos siempre que informacin a un plan de mejora del
sean significativos. servicio.
Una vez aprobado el plan de pruebas, que debe ser respaldado por la direccin, se
realizan acciones de comunicacin entre los responsables de los procesos y servicios
implicados, para que estn al tanto de los planes establecidos.
Cada vez que se realice una prueba, el responsable de realizarla dejar constancia
del resultado en el informe de pruebas, que describe las acciones llevadas a cabo y
la eficacia del plan de continuidad. Esta informacin la analiza el responsable del
proceso, que revisa peridicamente la eficacia de los planes para proponer las mejo-
ras que crea necesarias.
Asimismo, el responsable del proceso es el encargado de que los planes de conti-
nuidad se mantengan actualizados y acordes a la situacin actual de la organizacin.
Para ello, peridicamente debe analizar los cambios realizados que pudieran afectar
al plan, como por ejemplo los:
Cambios en los procesos (existentes, nuevos o suspendidos).
Cambios en la estrategia de negocio.
Cambios en los SLA.
Cambios en los acuerdos o contratos con proveedores.
Cambios en la legislacin.
Una nueva evaluacin de riesgos.
Cambios en las ubicaciones, dispositivos y recursos.
Cambios en el personal.
Cambios de direcciones, nmeros de telfono o informacin de contacto.
En caso de modificacin del plan de continuidad de TI, el responsable del proceso,

emite una nueva revisin del plan, identificando el motivo del cambio, el nmero
de versin del documento y la fecha del cambio para su posterior aprobacin. Asi-
mismo, se actualizar el plan general de continuidad del negocio si fuera necesario.
Mejora del proceso de continuidad

Al igual que se ha detallado para la disponibilidad, en la gestin de la continuidad
es recomendable identificar reas de mejora. Las mejoras pueden proponerse desde
el propio proceso, identificarse por el resultado de las pruebas o definirse tras una
situacin de contingencia. El resto de los procesos proporcionan informacin que
puede contribuir a mejorar la continuidad. Tambin se deben tener en cuenta los
cambios que vayan ocurriendo, como por ejemplo, nuevos SLA, variaciones en los
resultados de la evaluacin de riesgos en seguridad o disponibilidad, cambios en la
infraestructura, etc.
Las mejoras a la continuidad, al igual que en la disponibilidad, una vez aprobadas,
se gestionan en el plan de mejora unificado (vase el captulo 4).
Mtricas del proceso (disponibilidad y continuidad)

Al ser la disponibilidad el centro sobre el que giran todos los servicios, las mtricas
de la gestin de la disponibilidad tienen mucha importancia para el seguimiento
diario, semanal, mensual y anual, de los servicios de TI. Las ms destacadas son:
Porcentaje de disponibilidad de los servicios. Es sin lugar a duda, la
mtrica por excelencia en TI. La vorgine de mtricas no debe hacer perder
el foco en este rey de reyes de los indicadores de TI, que siempre se debe
medir y seguir.
Porcentaje de disponibilidad de los servicios crticos, con un detalle espe-
cfico para cada una de las funciones vitales del negocio.
El tiempo de respuesta de los servicios es otro de los grandes indicadores
de TI, pues indica si son utilizables. Influye directamente en la productivi-
dad de la empresa. Se debe detallar el tiempo de respuesta segn la criticidad
de los servicios.
99,99%

Porcentaje de disponibilidad total de los servicios prestados por suministra-

dores.
MTBSI (Mean Time Between Systems Incidents), frecuencia media con la que
se producen los incidentes.
MTTR (Mean Time To Repair, downtime, Mean Time To Restore), tiempo
medio de restauracin de los servicios tras incidentes.
Nmero de fallos o incidentes repetidos.
Costes asociados al proceso.
Porcentaje de no disponibilidad de los servicios por paradas planificadas.
Porcentaje de servicios con niveles de disponibilidad acordes a los SLA.
Porcentaje de disponibilidad de los componentes de los servicios.
Aumento del porcentaje de la fiabilidad de servicios y componentes.
Porcentaje de roturas de SLA, OLA y contratos con terceros revisados.
Mejora del porcentaje en disponibilidad global extremo a extremos de los
servicios.
Porcentaje de reduccin en el nmero e impacto de las paradas (manteni-
mientos) en el servicio.
En la figura 6.3.21 se muestra el modelo abreviado de mtricas de itSMF Espaa

para la disponibilidad.
Las mtricas de la gestin de la continuidad son mucho menos relevantes que las
relativas a la disponibilidad. Estn centradas en informar sobre los grados de cober-
tura, resultados de las pruebas, de las auditorias, etc. Las principales mtricas de la
gestin de la continuidad son:
Porcentaje de servicios cubiertos por el plan de continuidad de TI.
Retraso en la actualizacin del plan de continuidad.
Nmero de fallos en las pruebas de los planes de continuidad.
Costes asociados al proceso.
Retrasos en las fechas de las pruebas planificadas.
Porcentaje de servicios recuperados en tiempo en las pruebas del plan.
Prdida de ingresos estimada segn los resultados de las pruebas.
Mtricas principales de la gestin de la disponibilidad
Figura 6.3.21. Mtricas de la gestin de la disponibilidad
Resultados de la encuesta de conocimiento del plan de continuidad.

Nmero de cambios generados para subsanar los fallos en las pruebas.
Tiempo total dedicado a las pruebas del plan.
Porcentaje de personal que ha recibido formacin sobre las actividades de
recuperacin.
En la figura 6.3.22 se muestran las mtricas recomendadas en el modelo abreviado

de mtricas de itSMF Espaa.
Roles participantes en la gestin de la disponibilidad y

la continuidad
Al igual que en la generacin de informes, la disponibilidad y la continuidad tienen
una etapa de definicin e implementacin y otra de gestin operativa. La etapa de
implementacin se suele contratar externamente con un enfoque orientado a pro-
yecto llave en mano (especialmente en el caso de continuidad), mientras que en la
etapa de gestin operativa se realizan las pequeas tareas del da a da que mantie-
nen activos y vigentes los planes. Sobre estas dos facetas tan distintas acta un rol
99,99%

Mtricas principales de la gestin de la continuidad
Figura 6.3.22. Mtricas principales de la gestin de la continuidad
responsable que, primero controla el proyecto de definicin e implementacin del

plan, para despus gestionar la operativa del da a da.
La responsabilidad del proceso puede recaer en una sola persona o puede dividirse
en dos, asignando a uno la disponibilidad y a otro la continuidad. Depender de
las dimensiones de la organizacin y los servicios que preste. Las tareas relaciona-
das con la continuidad aparecen con frecuencia vinculadas al rea de seguridad, por
lo que la titularidad del proceso puede ser desempeada conjuntamente.
Los principales roles del proceso son:
El gestor de la disponibilidad. Se responsabiliza de la definicin, implanta-
cin y control de la disponibilidad. Es tambin el responsable de la mejora
continua del proceso. Trabaja en funcin de los objetivos generales acorda-
dos con el responsable de los servicios de TI.
El gestor de la continuidad. Es el encargado de definir, desarrollar e imple-
mentar el plan de continuidad de los servicios de TI para cumplir en todo
momento los objetivos de recuperacin del negocio. Gestiona la mejora con-
tinua del proceso y se coordina con el responsable de la gestin de servicios
de TI. Tambin es el responsable de:
Mantener y ejecutar el plan de pruebas.
Realizar revisiones peridicas de la calidad de todos los procedimientos

para asegurar su inclusin en el plan de pruebas.
Realizar revisiones regulares, al menos anualmente, de los planes de con-
tingencia con las reas del negocio para asegurarse de que reflejan con
exactitud la realidad.
En lo relativo a la etapa del proyecto de implantacin se puede contar con

un jefe de proyecto que asista al gestor.
Arquitecto tecnolgico. Realiza la definicin de la arquitectura tecnolgica
para que los sistemas sean capaces de alcanzar la disponibilidad demandada.
Tambin disea las plataformas para la continuidad de los servicios. Las prin-
cipales disciplinas de su mbito son: el balanceo de carga, la consolidacin,
la virtualizacin y la replicacin remota. Una vez definidas las arquitecturas,
se informa de su rendimiento y se mantiene al da del avance tecnolgico con
el fin de proponer mejoras al mismo.
Especialistas de soporte. Son tcnicos especializados que se encargan de la
monitorizacin de los elementos de infraestructura de TI, participan en las
pruebas de la continuidad, etc.
Administrador y soporte de disponibilidad. Es el responsable de la adminis-
tracin a nivel tcnico (de sistemas y de herramientas) del proceso de ges-
tin de disponibilidad. Se ocupa de proporcionar y mantener los medios tc-
nicos necesarios para una gestin eficiente del proceso.
Administrador y soporte de continuidad. Apoya al gestor de la continuidad
en sus funciones.

El responsable del plan de continuidad del negocio, con el que tiene que
enganchar el plan de continuidad de TI.
cumplan los niveles pactados. Aporta la relacin con la direccin de la
empresa y las principales directrices para la disponibilidad y continuidad.
Proporcionan los presupuestos para los costosos planes de implementacin.
Revisa y valida las alternativas de diseo y los resultados finales.
El responsable de las relaciones con el negocio lleva el contacto con el negocio
para el anlisis de impacto (BIA), la identificacin de las funciones vitales, en la
definicin de los requerimientos del negocio y en la gestin de todo contacto,
participacin o validacin que se requiera por parte de las reas cliente de TI.
99,99%

El gestor financiero debe dotar de recursos para la implementacin de las

arquitecturas y soluciones definidas. Debe adems balancear entre los presu-
puestos disponibles y las soluciones que se desean alcanzar.
El gestor de cambios debe identificar los cambios que tienen impacto en la
disponibilidad y en la continuidad, para que sean validados por este proceso.
El propietario del modelo SGSTI acta como propietario del proceso (process
owner), define el proceso, vela por el cumplimiento y actividades del proceso, y
se encarga de la mejora continua del mismo.
En la figura 6.3.23 se muestran los principales roles del proceso:
Roles del proceso
Responsable de la
gestin del servicio
Gestor continuidad TI
Gestor
disponibilidad
Responsable plan
de continuidad negocio
Gestores de otros
procesos y reas TI Arquitecto tecnolgico Especialista
de soporte
SGSTI
Propietario del Administrador y Administrador y

modelo (SGSTI) soporte disponibilidad soporte continuidad
Figura 6.3.23. Roles de gestin de la disponibilidad y continuidad

Resumen
La gestin de la disponibilidad y de la continuidad parte de principios muy simila-
res de alineacin con las necesidades del negocio y de creacin de planes, para poste-
riormente divergir en dos disciplinas diferenciadas. La primera es la disponibilidad
que se convertir en el astro rey de los servicios. El porcentaje de disponibilidad ser
la obsesin de todo responsable. La segunda, la gestin de la continuidad, juega a
los dados con el azar y el futuro de la empresa, proponiendo a la direccin impor-
tantes inversiones para garantizar la supervivencia, e intentando sustraer presu-
puesto de las actividades operativas.
Una vez implantados los planes, la gestin de la disponibilidad estar continua-
mente en boca de todos, mientras que la gestin de la continuidad se convertir en
ese profeta que muchas veces predica en el desierto.
La gestin de la disponibilidad tiene por objeto que se alcancen las mximas cotas
de disponibilidad posibles (dentro de las requeridas por el negocio), o por lo menos,
los niveles pactados siempre movindose dentro del mbito presupuestario asig-
nado. La gestin de la disponibilidad trabaja para alcanzar los siguientes resultados:
Tasas de disponibilidad y tiempos de respuesta acordes con lo pactado con el
negocio y, al menos, que sean similares a las de las empresas de la competencia.
Definicin de las directrices de diseo para la disponibilidad. Diseo de
arquitecturas de disponibilidad.
Tipificacin de los servicios en funcin de su criticidad para el negocio.
Generacin y revisin del plan de disponibilidad.
Planificacin y control de componentes de la infraestructura y de los servi-
cios, para asegurar el cumplimiento de las necesidades de disponibilidad
actuales y futuras.
Anlisis de las situaciones de no disponibilidad del servicio, con el fin de
identificar mejoras. Interviene a posteriori, despus de que la gestin del
incidente haya restaurado el servicio.
Mejorar la disponibilidad de la infraestructura.
Controlar que los cambios cumplen con unos niveles de disponibilidad ade-
cuados y fiables.
La gestin de la disponibilidad y la continuidad deben estar presentes desde

el momento en que se decide crear un servicio. Para ello, es necesaria una perfecta
sintona tanto con gestin de nivel de servicio, como con el proceso de creacin de
nuevos servicios o modificacin de los existentes.
99,99%

La gestin de la continuidad de TI se centra en garantizar que, despus de una con-

tingencia severa, la empresa seguir teniendo los servicios que necesita en el plazo
acordado. Proporciona los siguientes resultados:
Identificacin de los riesgos que la organizacin est afrontando, en trmi-
nos de probabilidad e impacto. La identificacin y priorizacin de los proce-
sos clave de la organizacin.
Evaluacin del impacto que tendran las interrupciones en el negocio y fijar
los objetivos del negocio en lo referente a los recursos de TI.
Formulacin de la estrategia de continuidad de negocio coherente con los
objetivos y prioridades de negocio.
Realizacin del plan de continuidad de TI, junto con todos los procedimien-
tos o planes de recuperacin asociados.
Contratacin de plizas de seguros adecuadas para mitigar la exposicin a
prdidas econmicas.
Implantacin de las contramedidas de reduccin del riesgo y de las solucio-
nes de continuidad.
Personal concienciado y entrenado para actuar en el caso de un desastre.
Beneficios
Los principales beneficios son la obtencin de una correcta disponibilidad y tiempo
de respuesta de los servicios, y una mejora significativa en la garanta de continui-
dad de los servicio de TI.
En cuanto a la gestin de la disponibilidad, los beneficios se resumen en:
El negocio utiliza unos servicios con unos niveles de disponibilidad y tiempo
de respuesta adecuados a sus necesidades.
Los servicios se disean sobre una arquitectura planificada para ofrecer la
disponibilidad deseada.
Los cambios se prueban para verificar el cumplimiento de los criterios de
disponibilidad.
Se identifican los incumplimientos y se investiga su causa.
Los niveles de disponibilidad se monitorizan continuamente y se mejoran
donde sea necesario.
Se detecta la incapacidad de determinados suministradores para satisfacer los

requisitos de servicio.
Se salvan fallos evitables en los servicios.
Los beneficios aportados por la gestin de la continuidad son:

Se conocen y se tienen acordados, con el negocio, las necesidades de conti-
nuidad de los servicios de T, en funcin de las necesidades de continuidad de
las funciones del negocio.
Se dispone de un plan de continuidad de TI que aglutina todo lo necesario
para definir, implantar y actuar.
Se analizan las situaciones que pueden poner en peligro la continuidad de los
servicios, para identificar acciones que controlen esos riesgos, as como, para
identificar acciones de mejora. Se gestionan los riesgos para que la organiza-
cin pueda seguir funcionando, al menos, al nivel mnimo predeterminado.
Se reduce el riesgo a un nivel aceptable y se planifica la recuperacin de los
servicios de TI. Por tanto, se puede esperar una reduccin de la prima de
seguros, una mejora de la imagen de la empresa, etc.
Las soluciones de replicacin remota, consolidacin y virtualizacin, que
muchas veces son necesarias, aportan mejoras en la robustez de las infraes-
tructuras y ahorros en la gestin de una planta ms uniforme.
Cules son los principales riesgos a los que estn expuestos los servi-
cios de TI en su organizacin
Cules son las funciones vitales en su negocio?
Qu impacto tendra en su negocio una parada de una hora de los
servicios de TI ms crticos (bien por fallo interno o por desastre)?
2
6.4. Gestin financiera de TI 331
6.4. Elaboracin del presupuesto y contabilidad de

los servicios de TI (gestin financiera de TI)
Figura 6.4.1. Actividades principales del proceso de gestin financiera de TI
La reduccin de los costes de TI lleva siendo, en los ltimos aos, una de las prin-
cipales prioridades de la direccin de sistemas de informacin. El reto est en con-
jugar esta progresiva constriccin presupuestaria con la presencia cada vez mayor
de las tecnologas de la informacin en el negocio. En tiempos de crisis econmica,
el proceso de gestin financiera de TI aporta elementos esenciales de decisin y de
control (vase la figura 6.4.1).
En sentido contrario a la reduccin de costes, ha ido creciendo el nmero de servi-
cios de TI considerados crticos por el negocio. Con la apertura a Internet el
nmero de usuarios se ha disparado y la demanda de nuevas tecnologas en la
empresa se incrementa cada da.
Adems, los antiguamente iletrados usuarios de los sistemas son hoy ciudadanos
de un mundo cada vez ms digitalizado, que exigen a la empresa el mismo nivel
tecnolgico que ellos reciben en su vida privada: un correo con la calidad y capaci-
dad de gmail, entornos colaborativos como los de Internet, un espacio en disco de
red equivalente a su disco USB de bolsillo, etc. Para colmo de males, estos servicios
son gratuitos o a un coste unas cien veces inferior a los que la empresa puede ofre-
cer a sus usuarios.
Todo ello, genera la sensacin de que los servicios que TI ofrece al negocio son
inflexibles y caros, provocando una percepcin muy negativa en la alta direccin y
en las reas cliente de TI.
Por fortuna, hay algunos apuntes en el haber de TI para equilibrar un poco
la balanza, como por ejemplo las grandes holguras presupuestarias del pasado, la
capacidad actual para poner el foco en lo verdaderamente esencial para la empresa
y el aumento de prestaciones del equipamiento hardware y las nuevas formas de
gestin de TI ms eficientes, como las definidas en ISO/IEC 20000 o en ITIL.
La adopcin de las mejores prcticas en la gestin econmica o financiera de TI y
otras medidas de eficiencia y calidad, aportarn una solucin a este callejn sin
salida de hacer ms con menos presupuesto. Estas prcticas proporcionan instru-
mentos para responder a los retos de reduccin de costes en un entorno de negocio
cada vez ms exigente e impulsa a las organizaciones de TI hacia una gestin efi-
ciente de los recursos. Aunque en realidad, la gestin financiera no permite por s
sola la reduccin de costes o el hacer ms con menos, necesita la existencia del
resto de procesos.
Una gestin econmica avanzada de los servicios de TI est caracterizada por:
La definicin de unas polticas de gestin econmica o financiera de TI.
La elaboracin precisa y formal de los presupuestos anuales y el seguimiento
con rigor de su evolucin.
La realizacin de una contabilidad analtica de los costes, que permite el
conocimiento al detalle de los costes de TI en la provisin de los servicios.
La imputacin de costes a las reas cliente mediante una facturacin acorde
con los servicios ofrecidos, para contrapesar la demanda con los costes reales.
Hay que sealar que esta actividad no est dentro del mbito de la Normas
ISO/IEC 20000, si bien es una actividad muy recomendable y, por ello, tra-
tada en este libro.
Aunque las tecnologas de la informacin son importantes y estratgicas para la

empresa, el departamento interno de sistemas de informacin suele ser un centro
de costes, es decir, no genera ingresos. El negocio y el departamento financiero de
la empresa consideran a TI como una unidad interna ms, al igual que marketing,
servicios generales, recursos humanos, vigilancia fsica, etc. Adems, el mbito con-
table-financiero no es una especialidad de TI. Por ello, hay que hacer una aproxi-
macin a la gestin financiera de TI con mucha humildad, reconociendo que se
est ante una actividad que es la especialidad de otro departamento y ante el que TI
es uno ms.
Por todo lo anterior, el enfoque de este proceso debe ser algo diferente al resto de
los procesos de TI. Muchas de las descripciones realizadas en este proceso son ms
bien explicaciones simplificadas de las disciplinas econmicas y van destinadas al
personal de TI para que realice adecuadamente la parte que les corresponde en la
gestin financiera. En este proceso no se pretende dar ningn tipo de leccin a los
profesionales de las finanzas.
El proceso de gestin financiera de TI debera conseguir que las necesidades y requisi-
tos particulares de TI se incorporen en los sistemas financieros y contables de la
empresa. Desde la estructura de los presupuestos hasta la contabilizacin de la ltima
factura, se deberan realizar integrados en estos sistemas. Es frecuente y lgico que las
organizaciones grandes de TI tengan un grupo propio de personas dedicadas al control
y a la gestin financiera. Pero se debe evitar la tendencia natural de crear un sistema de
control y de gestin de costes de TI paralelo y conseguir que las necesidades puedan
ser cubiertas por el sistema financiero corporativo, aunque en muchos casos, las nece-
sidades particulares de TI (sobre todo desde la perspectiva de gestin de activos y en la
utilizacin de recursos) requieren la utilizacin de sistemas complementarios.
En ISO/IEC 20000-2, la gestin financiera de TI se describe en torno a tres reas:
la definicin de las polticas, la elaboracin del presupuesto y la contabilidad de los
servicios. Adems, en este libro se incorporan tambin muchas de las recomenda-
ciones de ITIL v2, entre otras, la facturacin de los servicios, esencial para equili-
brar la balanza entre la demanda de las reas cliente y de la oferta de TI. En la
figura 6.4.2 se muestra una introduccin a este proceso.
El objetivo principal del proceso es conseguir una administracin eficiente de los
recursos econmicos de TI. Genera como principales contribuciones:
La administracin eficiente de los activos de TI utilizados para proveer los
servicios de TI.
Una integracin y dilogo perfecto con el rea financiera de la empresa.
El poder realizar una contabilidad exacta de los servicios de TI.
Facilitar la toma de decisiones sobre inversiones en TI de una forma efi-
ciente.
Orientar las organizaciones de TI a estructuras de costes ms competitivas.
La optimizacin de los costes de los servicios de TI. La deteccin de inefi-
ciencias en costes, permitiendo concentrar los recursos econmicos en fun-
ciones esenciales para el negocio.
Proceso de gestin financiera Qu aporta:

de TI Define las directrices para la gestin
econmica de TI.
Integracin con el rea financiera de
Definicin: la empresa.
Proceso centrado en la gestin Aumento del rigor en la definicin y
econmica de los servicios TI, que gestin de los presupuestos.
realiza una administracin cuidadosa, Proporciona una informacin precisa
responsable y eficiente de los costes. sobre los costes, para la toma de
decisiones sobre inversiones en TI.
Conocimiento exacto de los costes
Objetivo: totales de propiedad (TCO) a lo largo
Presupuestar y contabilizar los costes de la vida de los servicios.
de la provisin del servicio. Identifica ineficiencias existentes en
relacin a los costes.
Adems, en el libro se incluye la
facturacin de los servicios. Permite un uso ms eficiente de
los recursos y los servicios de TI,
moderando la demanda de los clientes.
Figura 6.4.2. Introduccin al proceso de gestin financiera de TI
La repercusin de costes indirectos y la asignacin de costes directos a servi-

cios, bien a los clientes internos de la organizacin, o bien a los clientes fina-
les en el caso de proveedores de servicios de TI.
La racionalizacin de la demanda de peticiones de servicios en funcin de su
coste y aportacin al negocio, con el resultado de un consumo eficiente de los
servicios por los usuarios.
Este proceso estructura su mbito en torno a las siguientes reas:

Polticas. Directrices que determinan la forma de alcanzar los objetivos.
Presupuestar. Su finalidad es predecir el gasto econmico, conseguir los
recursos necesarios y controlar el cumplimiento del presupuesto de la orga-
nizacin de TI. Genera un ciclo de negociaciones peridicas que permite
confeccionar los presupuestos (habitualmente anuales), para realizar poste-
riormente el seguimiento semanal o mensual de su ejecucin.
Contabilizar. La contabilidad analtica de costes permite conocer en detalle la
distribucin del coste en la cadena de valor de TI. Esta actividad pone nfasis
en la identificacin y conocimiento de los costes por servicio y por cliente.
Facturar. Este punto, no cubierto en las Normas ISO/IEC 20000, agrupa el

conjunto de actividades necesarias para gestionar el cobro a los clientes por
los servicios prestados. Gracias a la contabilidad realizada se puede establecer
una tarifa de precios por cada servicio y sus opciones. Aunque una organiza-
cin determine no facturar a sus clientes, es clave que el cliente conozca de
forma oficial los costes reales de los servicios de TI que demanda y recibe.
A diferencia de los presupuestos, la contabilidad detallada y la facturacin son reas

que no se suelen percibir como prioritarias en TI. Aunque en una certificacin
ISO/IEC 20000, los presupuestos y la contabilidad sern requisitos necesarios.
El gestor de este proceso se enfrenta a un entorno tcnico, en el que la cultura de la
gestin financiera en TI no es apreciada, ni est extendida. En la figura 6.4.3 se
muestran los principios directores que se deben tener en cuenta en la implementa-
cin de este proceso.
Figura 6.4.3. Principios directores que deben regir el proceso
El primer principio es la integracin con la empresa. Este proceso de gestin

financiera pretende que el rea de TI se comporte econmicamente y en sus deci-
siones como si fuera una compaa. Por esto, su implementacin debe estar com-
pletamente integrada con las formas de hacer del resto de la empresa en todos sus
mbitos: en los presupuestos, en la contabilidad y en la facturacin. De esta

forma, TI podr aprovechar el conocimiento y las herramientas ya en uso en el
resto de la organizacin para no crear una isla aparte reinventando la forma de
gestionarse econmicamente.
Otro de los aspectos clave que contribuyen al xito de este proceso es el estableci-
miento de los presupuestos de forma negociada con todas las partes implicadas,
tanto con las reas cliente como con los grupos internos que forman TI. Si el res-
ponsable de un grupo no se siente identificado con el presupuesto y ste no se
ajusta a la realidad, en muy poco tiempo se producirn desviaciones con las consi-
guientes peticiones de ampliacin presupuestaria.
La sencillez, que proporciona claridad, es quiz uno de los puntos ms difciles de
conseguir y debe ser un principio bsico para todas las actividades que rodean a
este proceso. La sencillez debe estar presente en la elaboracin del presupuesto y
sus partidas, en la definicin del modelo de costes utilizado, en la contabilizacin
y en la asignacin de precios a los servicios.
La implantacin de la normativa legal financiera en las empresas la suele liderar el
departamento financiero, quedando este proceso a sus rdenes para ejecutar los
requerimientos correspondientes al mbito de TI.
Las empresas multinacionales estn sujetas adems al cumplimiento de normativas
especficas en el mbito financiero, entre ellas destaca la relativamente reciente
Sarbanes-Oxley, conocida como SOX, que es una ley federal del Gobierno de
Estados Unidos para controlar la gestin financiera de las grandes empresas. Esta
ley americana toma el nombre del senador Paul Sarbanes (demcrata) y el congre-
sista Michael G. Oxley (republicano). Se public el 30 de julio de 2002 como
respuesta a los grandes escndalos 1 que hicieron caer la confianza de la opinin
pblica en los sistemas de contabilidad y auditora. Establece nuevos requerimientos
para los consejos de administracin y direccin, fija mecanismos contables para
todas las empresas que cotizan en las Bolsas de Estados Unidos, introduce respon-
sabilidades penales en el consejo de administracin y establece unos requerimientos
por parte de la SEC (Securities and Exchange Commission), la comisin reguladora
del mercado de valores de Estados Unidos. Los partidarios de esta ley afirman que
la legislacin era necesaria y til, mientras los crticos creen que causar ms dao
econmico del que previene 2.
1
Enron, Tyco International, Adelphia, Peregrine Systems y WorldCom.
2
La informacin sobre SOX se ha obtenido de Wikipedia.
Requerimientos
financieros del
negocio para TI
Objetivos financieros Planificacin de TI

para TI Cartera de proyectos
y actividades de TI
PRESUPUESTO CONTABILIDAD
Poltica de gestin SGSTI

financiera de TI Modelo de gestin TI

Gestin del cambio
Modelo
Proceso Procesos
de costes
Mejoras
FACTURACIN
PDCA
Modelo de SGSTI
facturacin
Precios
Catlogo
de servicios
Figura 6.4.4. Componentes principales del proceso de gestin financiera de TI
Catlogo de servicios. Proporciona una visin sencilla, en terminologa entendi-

ble por el negocio, de todos los servicios provistos por TI y las alternativas u opcio-
nes de prestacin. El catlogo debera contener los precios.
Contabilizar. Registro detallado de los costes en los que incurre TI, con una visin
de los costes por cada servicio y sus componentes.
Coste. El coste es todo importe econmico que debe pagar la organizacin. El
coste se divide en inversin y en coste operativo.
Coste de capital (CAPEX, Capital Expenditure) o Inversin. Trmino que
recoge los importes econmicos dedicados a incrementar los activos amortizables.
Coste operativo (OPEX, Operating Expenses). Se aplica al coste dedicado a
soportar la actividad (operacin y control).
Depreciacin o amortizacin de activos. Es la imputacin contable en varios
aos de la inversin de capital. El valor de compra del activo se distribuye entre los
aos del perodo de amortizacin. En la contabilidad de un ao no se imputa el

coste total de los activos, sino que slo se contabiliza la prdida de valor o depre-
ciacin del activo durante el ejercicio. El perodo de amortizacin fija el plazo en
que el activo deja de tener valor contable (el valor de adquisicin menos el valor
amortizado se iguala con el valor residual del activo). Cada tipo de activo (hard-
ware, software, etc.) tiene un perodo de amortizacin regulado legalmente en cada
pas (los coeficientes mximos y mnimos estn fijados en Espaa por el Ministerio
de Hacienda), que suele oscilar entre los 3 y 5 aos.
Elemento de coste. Es todo elemento de configuracin o componente que lleva
asociado un coste, como, por ejemplo: el hardware, el software, el personal, la ubi-
cacin, etc.
Facturar. Repercutir de manera real o informativa los costes en los que incurre TI
a consecuencia de la creacin de los servicios y de su uso por las reas cliente.
Mejoras. Las mejoras identificadas en el proceso, bien debido a la necesidad de
optimizacin de costes, o bien por la deteccin de deficiencias en otros procesos,
se incorporan al plan general de mejora del servicio.
Modelo de costes en TI. Define la estructura de las partidas presupuestarias y de
la contabilidad analtica de TI. Se debe intentar utilizar una clasificacin uniforme
de partidas para el presupuesto y para la contabilidad, y debe estar alineada con la
estructura de la CMDB. El modelo debe balancear entre el suficiente detalle para el
control de los presupuestos y la simplicidad en la contabilidad analtica, de tal forma
que se tenga suficiente informacin para la toma de decisiones. La obtencin de
dicha informacin debe ser sencilla. Si en el modelo de costes se decidiese conocer
al mnimo detalle el coste de cada tarea, sera necesario, por ejemplo, implantar un
sistema de imputacin de tiempos, con una precisin de minutos o de horas, para
todo el personal de TI.
Modelo de facturacin de TI. Forma en la que se cobrarn los servicios a las reas
cliente o, por lo menos, en la que se les informar de los costes incurridos por TI
para proveerlos. El modelo de facturacin, visible externamente para el cliente,
debe ser sencillo y, para el control interno de TI, debe alinearse con la estructura
del modelo de costes. La facturacin va a permitir que se controle mejor la
demanda de los clientes y la utilizacin por los usuarios. El cliente valorar aquello
por lo que tiene que pagar, pero por el contrario exigir precios y calidad equipara-
bles al mercado, y un retorno de valor por su dinero.
Modelo o sistema de gestin de los servicios de TI (SGSTI). Las polticas, y
todos los modelos de costes y facturacin se incorporan en el modelo general de
gestin de TI.
Objetivos financieros para TI. En el ciclo de preparacin de los presupuestos, la

direccin financiera del negocio establece el marco econmico en el que se debe
mover TI que, en estos ltimos aos, est siendo restrictivo. Estos objetivos econ-
micos que se deben cumplir deben ser acordes con la estrategia general de TI y con
las demandas de las reas cliente. Por ejemplo, en un entorno expansivo del nego-
cio o de fuerte innovacin tecnolgica sera difcil garantizar la respuesta de TI si
se estableciera un marco de presupuestos en constante reduccin. Normalmente el
truco est en que se fuerza una reduccin del presupuesto en las partidas de los
costes operativos, permitiendo aumentar as las partidas para la inversin.
Planificacin de TI. Los objetivos, el portfolio de servicios, la cartera de proyectos
y las actividades a realizar por TI estn estrechamente vinculados con los objetivos
financieros y los presupuestos asignados, pues la mayora de las actividades de TI
necesitan de un presupuesto para mantenerse. Por tanto, sern necesarias varias rondas
de revisin y negociacin con todas las partes para encajar la planificacin con el
marco presupuestario.
Poltica de gestin financiera de TI. Define las directrices que se deben cumplir
por este proceso, necesarias para la definicin del modelo de costes y el de factura-
cin (si procede).
Precios. Es recomendable que el catlogo de servicios refleje los precios de los
servicios o, por lo menos, de los costes en los que incurre TI al proveerlos.
Presupuestar. Establecimiento y aprobacin de los presupuestos de TI.
Requerimientos financieros del negocio para TI. El departamento financiero, en
representacin de la empresa, establece los requerimientos econmicos que debe cum-
plir TI (control, reduccin de costes, forma de repercusin de los costes, etc.); aprueba
los presupuestos de TI y realiza el seguimiento de los cierres mensuales; y, adems, las
reas cliente reciben una realimentacin de los costes de los servicios que demandan y
utilizan. Por otra parte, son las reas de negocio las que presentan a TI sus necesidades,
quien deber analizar la forma de cubrirlas en el mbito del presupuesto establecido.

Las prioridades principales del proceso son el control de los costes de TI y el cono-
cimiento de lo que cuestan los servicios y las principales funciones de TI. En la
figura 6.4.5 se muestran las entradas, actividades y salidas del proceso destinadas a
conseguir estos objetivos.
Las entradas principales que desencadenan el inicio del proceso son la necesidad de
planificar el siguiente ejercicio presupuestario de la empresa y de TI (normalmente
anual), que suele conllevar la definicin de unos nuevos objetivos financieros para
TI realizados en funcin de la planificacin de las actividades que se deben realizar;
y de una necesidad de compra que TI inicia y solicita su aprobacin presupuestaria.
Hay otras entradas de soporte que se utilizan en el proceso. Destacan los objetivos
financieros establecidos por la organizacin para TI; la planificacin de proyectos y
actividades previstas para TI, donde se reflejan todas las actividades y compromisos
planificados; el modelo de costes, formado por una estructura que permite regis-
trar y asignar todos los costes; el modelo de facturacin o imputacin de costes a
Desencadenantes 3 Definicin de la poltica de Salidas principales:

del proceso: gestin financiera. Poltica de gestin
Necesidad de planificar 3 Presupuestar: financiera de TI.
el siguiente ejercicio Seguimiento del Presupuesto de TI.
presupuestario. presupuesto. Informes de
Necesidad de compra. Autorizar econmicamente seguimiento
las compras. presupuestario.
Entradas de soporte:
3 Contabilizar: Informe de los costes
Objetivos financieros
de TI por servicio y
para TI. Definir el modelo de costes.
por cliente (*).
Planificacin de TI. Registrar compras y costes.
Facturas por los
Modelos de costes y de 3 Facturar (*): servicios prestados (*).
facturacin anteriores.
Definir precios.
Peticin de informes Salidas secundarias:
Emisin de facturas.
econmicos y consultas. Planificacin de TI
CMDB y catlogo de 3 Identificacin de mejoras ajustada.
servicios. en TI. Informes e informacin
3 Supervisin del econmica. Ratios de
funcionamiento del proceso. costes.
Mejora del proceso. Autorizaciones a
compras.
Modelo de costes en TI.
Modelo de facturacin.
CMDB actualizada.
Precios del catlogo
actualizados.
(*)
No requerido por ISO/IEC 20000.

clientes; diversas peticiones de informes y consultas econmicas sobre TI; y la

CMDB, para identificar los elementos intervinientes en un servicio y el catlogo de
servicios, con el fin de identificar los costes de los servicios ofrecidos.
Las principales actividades que realiza este proceso son la definicin de la poltica
de gestin financiera, a partir de los requerimientos y objetivos del negocio para
TI; la elaboracin del presupuesto (presupuestar), que tiene como objetivo dotar
de recursos econmicos a TI en funcin de las predicciones de gasto (dentro de esta
actividad se realiza el seguimiento del presupuesto para controlar su evolucin, y la
autorizacin econmica de las compras para garantizar que se gastan slo las parti-
das comprometidas); la contabilidad de los servicios de TI, que tiene como obje-
tivo llevar un registro completo de la forma en que se gasta el presupuesto; la fac-
turacin de los servicios de TI, para gestionar la imputacin de los costes a los
clientes por los servicios ofrecidos; y la supervisin del funcionamiento del proceso
y las acciones de mejora del mismo, que permiten ir eliminando las ineficiencias y
la tendencia natural del control econmico hacia la burocracia.
Las salidas principales del proceso son el documento con la poltica de gestin
financiera de TI definida; el presupuesto econmico de TI para el ejercicio; los
informes de seguimiento presupuestario, que proporcionan informacin de la
situacin actual y de los cierres presupuestarios intermedios; y la informacin del
coste de los servicios prestados a los clientes, ya sea en forma de facturacin real o
mediante un informe especfico.
Entre las salidas secundarias destacan la planificacin general de TI ajustada y
modificada acorde con los presupuestos; informes e informacin econmica
diversa, as como, ratios econmicos (coste por usuario, coste por capacidad de
proceso, etc.); las autorizaciones econmicas a las compras de TI; los documentos
con el modelo de costes de TI y el modelo de facturacin; la CMDB actualizada en
cuanto a los costes de los elementos de configuracin y servicios; y el catlogo
de servicios actualizado con los precios revisados.
Interrelacin con otros procesos y reas de TI

La gestin financiera de TI est estrechamente ligada a otras reas y procesos: el
rea financiera de la empresa, la gestin de las relaciones con el negocio, la gestin
de nivel de servicio, la gestin de la capacidad, la gestin de la disponibilidad-con-
tinuidad y la gestin de suministradores.
rea financiera de la empresa. El proceso de gestin financiera de TI es receptor
de los requerimientos del negocio para TI en sus aspectos econmicos y los des-
pliega. Adems, negocia los presupuestos e informa peridicamente de su ejecucin.
El objetivo es conseguir que la gestin financiera de TI est integrada completa-

mente en la gestin financiera general de la empresa. Para ello es necesario que los
requerimientos especficos de TI se reflejen en sta ltima. El presupuesto de TI se
realiza igual que en el resto de departamentos de la empresa, la contabilidad utiliza
los sistemas contables de la empresa y la facturacin se realiza a travs del rea
financiera o de cobros. En la figura 6.4.6 se ilustra esta integracin.
DEPARTAMENTO FINANCIERO DE LA EMPRESA
PRESUPUESTO CONTABILIDAD FACTURACIN
Necesidades Necesidades de Detalles de

presupuestarias de TI. clasificacin contable consumo TI
Cumplimiento para TI. de los clientes
presupuesto. Desglose de los
costes TI incurridos
GESTIN FINANCIERA DE TI
SISTEMAS DE
INFORMACIN
MARKETING VENTAS FABRICACIN ADMINISTRACIN SERVICIOS Etc.
GENERALES
Figura 6.4.6. Integracin de la gestin financiera de TI con

la gestin financiera de la empresa
Relaciones con el negocio. Cuando se definen los presupuestos es necesario man-

tener reuniones con los clientes para acordar los servicios que se van a prestar en el
ejercicio, su evolucin y sus precios. Esta negociacin se lleva a cabo a travs del
proceso de las relaciones con el negocio.
Gestin de nivel de servicio. La gestin de nivel de servicio acuerda con la gestin
financiera la presupuestacin de los recursos necesarios para cumplir los niveles de
servicio pactados y la financiacin de los planes de mejora del servicio (SIP). Por
ejemplo, si se negocia con un cliente la atencin en fines de semana, ser necesario
tener presupuestado y aprobado este coste extra antes de cerrar el SLA. Con la ges-
tin de nivel de servicio tambin se analizan las mejoras de eficiencia en costes de
los servicios. Adems, en el catlogo de servicios se incorpora el precio de cada ser-
vicio y sus opciones.
Gestin de suministradores. La gestin de suministradores est muy vinculada a
este proceso. Las relaciones entre ambos se establecen en todos los mbitos de la
gestin de suministradores: en la definicin de la estrategia de sourcing, que debe
ser acorde con los objetivos financieros; en el ciclo de seleccin y contratacin, que
lleva a cabo las compras; y en el ciclo de gestin de la prestacin del suministrador,
para velar por los pagos y las variaciones econmicas dependientes de la demanda.
Gestin del cambio. Los cambios importantes deben valorarse en cuanto al coste
y aprobarse bajo el mbito de la gestin del cambio. Este requisito obliga a la ges-
tin financiera a trabajar de una forma conjunta con el resto de la organizacin en
la aprobacin de los cambios y sus costes bajo el proceso de gestin del cambio.
Gestin de la capacidad. La gestin de la capacidad participa en la elaboracin de
los presupuestos con las previsiones de recursos identificadas en el plan de capaci-
dad. Con las previsiones, se pueden concentrar las compras y evitar las compras de
urgencia para obtener ahorros adicionales. Adems, proporciona informacin sobre
la utilizacin de las infraestructuras y de los recursos.
Gestin de la disponibilidad y continuidad. La continuidad puede requerir gran-
des inversiones en replicaciones, en servicios externos y en centros redundados. La
elaboracin de presupuestos y contabilidad debe conseguir que las soluciones de
continuidad tengan el equilibrio entre el coste y el beneficio aportado al negocio.
Pues, podra ocurrir que la prdida posible del negocio sea menor que el coste de
los mecanismos redundados.
Gestin de la configuracin. La informacin sobre los costes de los activos los
proporciona el proceso de gestin financiera, y gestin de la configuracin los
almacena como un atributo de informacin ms. Posteriormente se utilizarn para
el clculo de los costes por servicio.
Este proceso tambin se relaciona con el resto de procesos y reas para definir las
partidas presupuestarias del ejercicio, identificar mejoras de eficiencia econmica y
el seguimiento de los objetivos econmicos.
Alcance del proceso

El apartado 6.2 de las Normas ISO/IEC 20000 cubre nicamente la definicin de
las polticas, la realizacin de los presupuestos y la contabilidad de los servicios
de TI. Pero en la prctica, se est implantando tambin la facturacin de los servi-

cios a los clientes, como uno de instrumentos para lograr unos servicios eficientes
alineados en trminos de coste con las necesidades del negocio. En estas normas se
aclara el alcance que cubren:
UNE-ISO/IEC 20000-1
Nota: Esta seccin cubre la elaboracin de presupuestos y de la contabilidad del los servicios de TI. En
la prctica, muchos proveedores del servicio estarn involucrados en facturar por tales servicios.
Sin embargo, dado que la facturacin es una actividad opcional, no est cubierta por la norma.
Se recomienda a los proveedores que si hacen uso de la facturacin, el mecanismo para hacerlo
est plenamente definido y entendido por las partes. Todas las prcticas contables en uso se debe-
ran alinear con las prcticas contables ms amplias de la organizacin del proveedor del servicio.
En la nota anterior se deja claro el alcance de los requisitos del proceso en la parte 1,
en los que no se incluye la facturacin, aunque en este libro s se trata.
Por otra parte, se recalca la importancia de que la elaboracin de presupuestos y la
contabilidad de TI estn perfectamente alineadas con las prcticas contables gene-
rales de la organizacin. Hay que intentar que la contabilidad de la empresa con-
temple las necesidades de la contabilidad analtica de TI, con el fin de poder extraer
de sta los costes por servicio, los costes por cliente, los costes por actuacin, etc.
As, se evita realizar la contabilizacin dos veces, una en los sistemas contable gene-
rales de la empresa y otra en los sistemas contables especficos de TI.
UNE-ISO/IEC 20000-2
Generalidades
La responsabilidad sobre muchas de las
Esta seccin cubre la realizacin de los decisiones financieras va a estar fuera
presupuestos y de la contabilidad para del mbito de la gestin del servicio y
los servicios de TI. En la prctica, tambin podran dictarse externamente
muchos proveedores estn implicados los requisitos acerca de qu informacin
en la facturacin del servicio. Sin financiera se debe facilitar, de qu
embargo, dado que la facturacin es manera y con qu frecuencia. Las dis-
una actividad opcional, no est cubierta posiciones de esta seccin estn enfo-
por esta norma. Se recomienda a los cadas en las prcticas que se deberan
proveedores del servicio que cuando seguir para satisfacer los requisitos de la
lleven a cabo la facturacin, el meca- norma. Sin embargo, se pueden tener
nismo empleado para ello est definido en cuenta requisitos ms amplios en el
en detalle y sea entendido por todas las caso de que impacten en alguna de las
partes implicadas. polticas y procedimientos definidos.
ISO/IEC 20000-2 hace hincapi en que muchas decisiones financieras que afectan
a este proceso se toman fuera de l. La gestin financiera de TI est supeditada a
las directrices del departamento financiero de la organizacin. En algn escenario,
como en el caso de las empresas pequeas, la responsabilidad completa del proceso
puede ser externa a TI.
Planificacin e implementacin del proceso

La planificacin e implementacin del proceso de gestin financiera de TI se reali-
zar por el mismo equipo especialista en procesos que se encarga de definir las for-
mas de trabajar en toda la organizacin de TI. Este equipo colaborar estrecha-
mente con el futuro responsable de la gestin financiera de TI. La implementacin
de este proceso no debe realizarse aisladamente, sino como parte de la implementa-
cin de todo el sistema de gestin de TI (vase el captulo 3), que se realizar
siguiendo el rigor del ciclo PDCA establecido en el proceso de implementacin
de la gestin del servicio (vase el captulo 4).
Los principales aspectos a tener en cuenta en la implementacin del proceso son:
Un firme compromiso de la direccin con el proceso de gestin financiera
de TI, pues toda la organizacin de TI deber asumir y adaptarse a los pre-
supuestos acordados. Adems, cada compra deber ser aprobada en sus
aspectos de encaje presupuestario.
Una clara asignacin de responsabilidades, para que la organizacin de TI
acepte sin dudas la figura del gestor econmico de TI. Este proceso tiene un
control estrecho de los gastos de toda la organizacin de TI, que general-
mente se percibe como burocrtico y con poca aportacin de valor. Es nece-
sario vencer la resistencia de los participantes en el resto de procesos y del
resto de los departamentos.
Un plan adecuado de comunicacin, que informe a todos los responsables y
usuarios de la organizacin de TI de las ventajas de una correcta gestin de
la elaboracin del presupuesto y contabilizacin de los servicios de TI.
La sencillez en la implementacin, descendiendo slo al nivel de detalle nece-
sario.
Transparencia en la informacin presupuestaria y su ejecucin, incorporn-
dolos al modelo de documentacin estructurado para ofrecer informacin y
ayuda online a toda la organizacin de TI.
La necesidad de definir una poltica de gestin econmica de los servicios de
TI que marque las reglas de funcionamiento.
Las herramientas de soporte a la gestin del proceso deben ser los mismos
sistemas de gestin de la empresa. Deben permitir gestionar los presupues-
tos, la contabilizacin de los gastos por servicio y por cliente, el registro del
consumo de recursos y su facturacin.
Contemplar los propios costes originados por el proceso, que esencialmente
estn relacionados con el personal y la adaptacin de los sistemas financieros
de la empresa.
Definicin de la poltica de gestin financiera

A partir de los requerimientos y objetivos del negocio para TI, se desarrollan las
principales directrices econmico-financieras para las cuales el proceso debe garan-
tizar su cumplimiento por el resto de la organizacin de TI.
La misin de toda poltica es definir los objetivos que se deben alcanzar y preparar
un marco de directrices para conseguirlos. En las Normas ISO/IEC 20000 se
requiere que exista una poltica para la gestin financiera de los servicios de TI, es
decir, que se presupuesten y contabilicen todos los componentes, que se repercutan
los costes directos e indirectos de los servicios y que haya un control econmico y
sus procedimientos de autorizacin.
UNE-ISO/IEC 20000-1
Debe haber polticas y procedimientos claros para:

a) presupuestar y contabilizar todos los componentes, incluyendo los activos de
tecnologas de la informacin, recursos compartidos, gastos generales, servi-
cios suministrados externamente, personas, seguros y licencias;
b) la repercusin de costes indirectos y la asignacin de costes directos a servi-
cios;
c) el control econmico efectivo y la autorizacin.
ISO/IEC 20000-2 desarrolla el contenido recomendado para la poltica financiera

de TI, en la que se detallan los tipos de costes que se deben contabilizar, la forma
de repercusin de los gastos generales comunes, el grado de detalle que se debe
alcanzar, cmo se gestionarn las desviaciones presupuestarias, la relacin con la
gestin de nivel de servicio, etc.
UNE-ISO/IEC 20000-2
Poltica ejemplo el nivel de variacin nece-

sario para que se escale a la alta
Debera existir una poltica para la ges-
direccin;
tin financiera de los servicios. La pol-
tica debera definir los objetivos a ser e) los enlaces o vinculacin con la
cumplidos por la realizacin de los pre- gestin de nivel de servicio.
supuestos y la contabilidad.
El nivel de inversin en los procesos de
La poltica debera definir tambin el elaboracin del presupuesto y contabili-
nivel de detalle al que se lleva a cabo la dad debera estar basado en las necesi-
elaboracin de los presupuestos y la dades de detalles financieros que ten-
contabilidad, teniendo en cuenta: gan los clientes, el proveedor del
a) los tipos de costes a ser contabili- servicio y los proveedores, segn est
zados; definido en la poltica.
b) el reparto de los gastos generales, Nota: Los proveedores del servicio que operen en
por ejemplo reparto en partes igua- un entorno comercial podran necesitar
les, reparto porcentual o reparto invertir mucho ms esfuerzo y tiempo en la
gestin financiera. Contrariamente, para
basado en el tamao de los ele- aquellos proveedores del servicio que slo
mentos variables empleados; necesiten la simple identificacin de los
costes, esta gestin puede ser mucho ms
c) la granularidad del negocio del simple.
cliente, por ejemplo unidades de
negocio tomadas como una sola, La realizacin de los presupuestos y la
dividas en departamentos o segn contabilidad se deberan realizar por
las diferentes ubicaciones; todos los proveedores del servicio, cua-
d) las reglas para manejar las varia- lesquiera que fueran sus otras polticas
ciones frente al presupuesto, por en cuanto a gestin financiera
En la poltica se define el modelo de costes, con foco en los criterios de asignacin

de costes por servicio. Este modelo debe ser:
Sencillo. Con mecanismos de clculo de costes simples y fcilmente enten-
dibles por los clientes. Tambin se debe buscar la sencillez en la gestin, para
evitar la burocracia que comnmente se asocia a este tipo de actividades, con
el fin de proporcionar una mayor eficiencia global.
Justo. El sistema de asignacin de costes debe ser ecunime y realista, ya que
aquellos servicios que no sean eficientes en trminos de coste se debern
revisar y, en muchos casos, habr que tomar medidas drsticas. Realmente
cada unidad de negocio debera pagar el mismo precio por el mismo servicio.
Realista. Uno de los puntos clave es buscar la eficiencia econmica de los

servicios. Por tanto, los mecanismos de gestin econmica de los servicios
de TI se deben disear para conseguir esta eficiencia. Pero, el ahorro en TI
debe contemplar que el resultado final no sea un mayor gasto o ineficiencia
en el negocio.
La poltica de gestin financiera debe ajustarse al tipo de organizacin. Por ejem-

plo, si el negocio de la empresa es la venta de los servicios de TI al mercado, reque-
rir un sistema de gestin econmica que permita la imputacin de costes y la asig-
nacin a clientes de forma justa, sencilla y realista. Por el contrario, en el caso de
unidades de TI internas, los objetivos del proceso podran limitarse nicamente al
conocimiento de los costes totales incurridos en la prestacin los servicios de TI, de
modo que los clientes sean conscientes de lo que cuestan sus demandas agregadas.
Al principio de la implantacin de una poltica de gestin financiera de los servi-
cios de TI, al cliente le puede parecer que los costes de los servicios son altos y que
la relacin con TI se vuelve ms burocrtica, pues se incluye la gestin econmica
en la toma de decisiones. Para limitar este riesgo, la poltica debera considerar:
Los aspectos de comunicacin, transparencia y difusin del proceso y sus
objetivos.
Que los modelos de clculo de costes se desarrollen en coordinacin con los
clientes.
La propia eficiencia del proceso.
Estructura comn de elementos de coste

De cara a mantener una gestin financiera sencilla y homognea en TI se reco-
mienda definir una estructura comn de elementos de coste, a modo de tesauro
contable, que permita clasificar los presupuestos y los costes con los mismos crite-
rios. As, se utilizarn desgloses similares en la elaboracin del presupuesto, en la
contabilizacin y en el clculo de costes para la facturacin. Esta misma clasifica-
cin se debera mantener entre las grandes reas de TI: en el puesto de trabajo, en
el centro de datos o explotacin de sistemas, y en el desarrollo de aplicaciones.
Se propone utilizar la misma estructura de elementos de coste definida en ITIL v2:
costes de hardware, costes de software, costes de personal, costes de ubicacin
fsica, costes de servicios externos y costes de transferencia (imputaciones de otras
reas de la empresa). En la figura 6.4.7 se muestra el detalle de esta estructura pro-
puesta para la clasificacin de los datos econmicos.
Figura 6.4.7. Propuesta de una estructura comn de los elementos de coste en TI
Elaboracin del presupuesto (presupuestar)

La elaboracin del presupuesto consiste principalmente en realizar una estimacin
detallada de los gastos e inversiones necesarios para la provisin, mantenimiento y
evolucin de los servicios de TI, teniendo en cuenta las necesidades de los clientes
y asegurar que se proporcionen a TI los fondos necesarios. Bajo presupuestar se con-
templa tambin el seguimiento diario de la ejecucin del presupuesto, el control eco-
nmico de las compras y la autorizacin de los posibles desvos presupuestarios.
El presupuesto se formaliza generalmente en perodos anuales. Se establece
mediante tres ciclos de negociaciones: entre TI y el rea financiera de la empresa,
para acordar los montos totales y las principales partidas; entre la gestin financiera
de TI y las reas internas de TI, para conocer las necesidades y ajustar las partidas;
y entre TI y las reas cliente, con el fin de adecuar el presupuesto a sus necesidades.
Entre los tres ciclos de negociacin hay una realimentacin hasta alcanzar un equi-
librio.
El presupuesto dota econmicamente a TI y, por tanto, condiciona toda la acti-

vidad en el ejercicio. Debe ir estrechamente vinculado al desarrollo de la estrategia
de TI.
Las Normas ISO/IEC 20000 requieren que los presupuestos tengan el suficiente
detalle para posibilitar el control econmico y la toma de decisiones.
UNE-ISO/IEC 20000-1
Los costes se deben presupuestar con suficiente detalle para permitir el control eco-
nmico efectivo y la toma de decisiones.
El proveedor del servicio debe monitorizar e informar de los costes contra el presu-
puesto, revisar las previsiones econmicas y gestionar los costes en consonancia.
Los costes de los cambios en el servicio se deben valorar y aprobar a travs del pro-
ceso de gestin del cambio.
ISO/IEC 20000-1 requiere que los cambios se valoren en cuanto a sus costes y que
se aprueben a travs del proceso de gestin del cambio. De esta forma, se tiene
un mejor conocimiento y control de los costes. Las peticiones de cambio (RFC),
presentadas con el fin de aprobar su ejecucin, deben incorporar el coste asociado
(as se establece en el formato de RFC del apartado 9.2). El proceso de gestin
financiera controlar a travs de su presencia en el comit de cambios (CAB,
Change Advisory Board), que se actu dentro de los presupuestos asignados.
Una vez aprobado el cambio, cuando se necesite la ejecucin de alguna compra
(equipamiento, licencias, servicios, etc.), volver a intervenir la gestin financiera
para autorizarla econmicamente.
UNE-ISO/IEC 20000-2
Elaboracin del presupuesto ficar la gestin que se va a hacer del

dficit.
La elaboracin del presupuesto debe-
ra tener en cuenta los cambios planifi- La elaboracin de los presupuestos
cados de los servicios durante el puede tener en cuenta factores tales
periodo presupuestario y, en el caso de como variaciones estacionales y cam-
que las necesidades presupuestarias bios planificados a corto plazo en los
excedan los fondos disponibles, plani- costes y facturacin de los servicios.
El seguimiento de los costes frente al La elaboracin de los presupuestos y

presupuesto debera facilitar lo antes el seguimiento de los costes deberan
posible la informacin de las variacio- dar soporte a la planificacin de la
nes frente al presupuesto. operacin de cambios en los servicios
para que los niveles de dichos servi-
Se debera establecer un proceso para
cios puedan mantenerse a lo largo del
gestionar las implicaciones de las varia-
ao.
ciones frente al presupuesto.
Aunque no existe forma estndar de realizar el presupuesto de TI, se suelen utilizar

dos estrategias:
Presupuesto incremental: se toma como punto de partida el presupuesto
del ao anterior, y sobre l se corrigen las partidas, teniendo en cuenta la
variacin de los precios, de la planta, de la actividad, de los servicios, etc.
Presupuesto con base cero: en este ejercicio se parte de una hoja en
blanco para replantear y cuestionar todas las necesidades y partidas presu-
puestarias. Esta forma, ms laboriosa, tiene como ventaja que se detectan
mejor las partidas presupuestarias repetitivas que aportan poco valor. Cada
partida que se incluye hay que justificarla. Se corre el riego de olvidar com-
promisos o partidas necesarias, como por ejemplo, los mantenimientos.
El presupuesto es una tabla en la que se relacionan las partidas presupuestarias

que se deben considerar, junto con el monto econmico acordado para cada una de
ellas en el ejercicio. El nivel de detalle y su clasificacin depende de las prcticas
financieras de cada organizacin. Se debe mantener la misma estructura clasificato-
ria en el presupuesto que en la contabilidad que registra su ejecucin. En la figura
6.4.8 se muestra una plantilla para la elaboracin de un presupuesto.
Adems, en el presupuesto se suele discriminar entre inversin (coste de capital o
CAPEX) y coste operativo (OPEX). La inversin aumenta el valor de la empresa,
se presupuesta segn la forma de pago prevista en la compra y se imputa contable-
mente en el transcurso del perodo de amortizacin.
En el presupuesto conviene tambin detallar a nivel mensual las partidas con el fin
de poder realizar de forma ms precisa el seguimiento presupuestario.
En la elaboracin de un presupuesto adems hay que considerar otros aspectos
como por ejemplo:
Los lmites para la inversin.
Los lmites para el coste operativo.
Figura 6.4.8. Plantilla simplificada para la elaboracin de un presupuesto de TI
La variacin permitida entre los gastos reales y los previstos.

Se debe confeccionar una gua de cmo utilizar el presupuesto y cmo reali-
zar el seguimiento.
Se debe establecer el tratamiento de las excepciones.
En teora, antes de la realizacin del presupuesto, se deberan tener cerradas las pro-
puestas de los planes anuales de los otros procesos y reas, que tienen una influen-
cia directa en el presupuesto, como por ejemplo, el plan estratgico de TI, la car-
tera de proyectos anual, el plan de capacidad, el plan de continuidad, el plan de
disponibilidad y las estimaciones de costes de otras reas y procesos (service desk,
problemas, cambios, infraestructuras, etc.).
Seguimiento del presupuesto. Una vez aprobado formalmente el presupuesto,

puede comenzar su ejecucin con el fin de ir nutriendo a TI de los recursos que
necesita. Para garantizar que el presupuesto se gasta en las partidas comprometidas

y que se ejecuta segn lo previsto, es necesario realizar un seguimiento presupues-
tario peridico que controle la evolucin del gasto.
El seguimiento presupuestario conlleva la realizacin de cierres intermedios, (habi-
tualmente mensuales) en los que se totalizan todos los elementos de coste y se com-
prueba que evolucionan segn lo previsto. Estos cierres se almacenan a modo de
lnea base presupuestaria y se comunican a los interesados a travs de los infor-
mes de seguimiento presupuestario. De esta forma, cuando de detecten desviacio-
nes en algunas partidas se podr actuar estableciendo acciones correctoras antes de
que sea demasiado tarde.
Esta actividad de seguimiento se realiza utilizando el sistema o herramienta conta-
ble (general de la empresa), para generar de forma automatizada los informes de
evolucin de los costes y su comparacin con los presupuestos.
La actividad de seguimiento presupuestario se suele hacer (segn ITIL v2):
Diaria o semanalmente:
Recoger los datos de los costes incurridos y comprobar que son exactos y
completos.
Participar en la valoracin de los cambios y si es necesario asistir a las reu-
niones del comit de cambios (CAB).
Mensualmente:
Comprobar que los costes consolidados del mes en curso se corresponden
con las previsiones, y analizar y explicar cualquier desviacin.
Realizar anlisis de costes.
Obtener los precios reales por servicio-cliente, y compararlos con los pre-
supuestos.
Difundir un balance de situacin mensual.
Notificar las desviaciones producidas a cada rea.
Revisar la recuperacin de los costes en comparacin con los objetivos
establecidos.
Trimestral o semestralmente:
Evaluar la exactitud de las frmulas para el clculo de costes, comparando
los costes y los ingresos reales con los previstos.
Comprobar las listas de precios de los servicios.
Determinar la exactitud de las previsiones para mejorarlas en el futuro.

Preparar el ciclo anual del presupuesto realizando previsiones trimestrales
o semestrales.
Anualmente:
Planificar los cambios necesarios en el personal y los recursos para el pr-
ximo ao.
Revisar los sistemas de contabilidad y facturacin de TI, para:
Generar las cuentas finales del ao financiero en curso.
Asegurar de que se alcanzan los objetivos de negocio de la organizacin
de TI.
Generar los anlisis anuales del coste.
Confeccionar y difundir un balance final.
Revisar los elementos de coste estndar (es importante tener en cuenta
que las correcciones deben ser las imprescindibles, ya que cualquier cam-
bio dificultar las comparaciones entre distintos aos).
Recalcular el valor por unidad del coste para comprobar que se correspon-
den con los resultados previstos.
Revisar la poltica de gestin econmica y los procedimientos de la conta-
bilidad de TI.
Ayudar al cliente y a otros gestores de TI a definir los presupuestos para el
nuevo ao financiero.
Revisar las necesidades de continuidad de los servicios que soportan la
gestin econmica de TI, y comprobar que todos sus requerimientos y
necesidades estn cubiertos.
Autorizar compras. La conversin del presupuesto en recursos disponibles para

TI se realiza principalmente a travs de las compras o contrataciones a suministra-
dores (vase tambin el apartado 7.3). Dentro del mbito de presupuestar, tambin
se contempla la autorizacin econmica de las compras. Toda compra, antes de eje-
cutarse, debe ser autorizada por este proceso con el fin de garantizar que tiene una
partida asignada y que se encuentra dentro del plan previsto. De esta forma, se con-
trolan las desviaciones antes de que se produzcan. Para agilizar las compras, se sue-
len preautorizar grandes partidas sobre las que se ejecutan compras al detalle (por
ejemplo, compra de PC, de consumibles, etc.).
Contabilidad de los servicios de TI

El objetivo principal de la contabilidad es conocer el coste real de la provisin y del
mantenimiento de los servicios de TI. La contabilidad lleva un registro completo
de la forma en la que se gasta el presupuesto.
La contabilidad de los servicios viene a paliar el desconocimiento histrico de los
costes a nivel servicio. La razn principal proviene de la utilizacin de plataformas
y recursos comunes, lo que genera dificultades a la hora de repartir los costes hasta
el ltimo nivel. La evolucin del mercado y el mayor peso de los costes de TI en la
estructura empresarial, hacen absolutamente imprescindible el conocimiento del
coste de cada servicio.
Como TI es un rea ms de la empresa, se debe poner nfasis en que la contabili-
dad la realice el departamento contable de la empresa y no el personal de TI. Se
debe evitar tener una actividad de contabilizacin paralela. Para conseguir este
objetivo, hay que gestionar la incorporacin del modelo de costes definido para TI
en el sistema contable de la empresa. En ocasiones, TI prefiere mantener los deta-
lles de sus presupuestos y costes a resguardo, con el fin de tener ms margen de
maniobra y no dar explicaciones a otras reas.
En este mbito, las Normas ISO/IEC 20000 aportan unas recomendaciones muy
livianas:
UNE-ISO/IEC 20000-2
Contabilidad
Los modelos de costes deberan ser
Los procesos de contabilidad se debe- capaces de mostrar los costes de la pro-
ran usar para realizar el seguimiento de visin del servicio.
los costes hasta el nivel de detalle acor-
Los estados de cuentas deberan mostrar
dado durante un periodo de tiempo
las situaciones de excesos y defectos
tambin acordado.
de gasto as como las recuperaciones de
Las decisiones sobre la provisin del dichas situaciones y deberan permitir al
servicio deberan estar basadas en com- lector entender los costes de niveles bajos
paraciones sobre la eficacia en costes. de servicio o de prdidas de servicio.
Se debe poner un foco especial en conocer el gasto por cliente, por servicio y por
actividad, lo cual implica tener que realizar un desglose o asignacin por cliente y
por servicio en todos los gastos. En lo relativo a la actividad, se necesitar un sis-
tema de imputacin de tiempos por parte del personal.
La informacin proporcionada por contabilidad y el seguimiento presupuestario

de TI, es esencial para mantenerse en el marco del presupuesto asignado, la toma
las decisiones sobre inversiones y renovaciones de contratos, e identificar ineficien-
cias y actividades que no aporten valor.
El establecimiento de la contabilidad de TI puede resultar una tarea compleja si se
implementa con un nivel de detalle excesivo y puede llegar a costar ms que los
beneficios que aporta.
Un buen sistema contable debe:
Permitir realizar el seguimiento de los costes reales y compararlos con el pre-
supuesto.
Proporcionar informacin de los costes incurridos para la prestacin del ser-
vicio con el rendimiento requerido.
Facilitar la evaluacin y establecimiento de las prioridades de la utilizacin
de recursos.
Facilitar el seguimiento de los costes y la toma las decisiones diarias con una
comprensin plena de las implicaciones en cuanto a costes y, con el mnimo
riesgo.
Dar soporte a la actividad de facturacin de los servicios de TI, si la organi-
zacin lo considera necesario.
Modelo de costes en TI. Un modelo de costes por servicio es una estructura con-
table en la que se pueden registrar y asignar todos los costes conocidos a servicios,
de manera que se puedan conocer los costes de toda la estructura productiva nece-
saria para un servicio. De igual manera, existe el modelo de costes por cliente (mar-
keting, ventas, etc.), que permite conocer todos los costes incurridos por TI para
prestar los servicios a cada uno de ellos.
El modelo de costes de TI se debe definir e implementar de forma conjunta entre
TI y el rea financiera de la empresa. De esta manera, adems de cumplir con la
legalidad vigente, se evita tener que realizar una contabilidad duplicada.
A la hora de plantear el desarrollo e implantacin de un modelo de costes, y antes
de lanzarse a definir los elementos de coste tpicos de TI, se debera obtener la
siguiente informacin.
La informacin procedente de las cuentas de gasto de la empresa a la que
pertenece la organizacin de TI (gastos de personal, contratos de servicios
de TI, mantenimiento de licencias, amortizacin del hardware y del soft-
ware, etc.).
El catlogo de servicios de TI de la organizacin.

El detalle de los servicios de TI y la infraestructura que los soporta. En esta
tarea resulta de gran utilidad disponer de una CMDB actualizada.
El modelo de costes es un aspecto clave y piedra angular para una adecuada ges-
tin econmica de los servicios de TI. En la figura 6.4.9 se muestra el ejemplo de
un modelo de costes de TI enfocado a los servicios.
Hardware Software Personal Ubicacin Servicios externos Transferencia
Elementos de coste
Costes directos Costes indirectos Costes indirectos

del servicio imputables al servicio no imputables
Hardware Hardware Hardware
Software Software Software
Personal Ubicacin Personal
Servicios externos Ubicacin
Servicios externos
Transferencia
Costes directos Costes indirectos
del servicio del servicio
Reglas de
Costes directos y % de
reparto de los
costes absorbidos incremento
costes indirectos
del servicio comn
no imputables
Coste total del servicio
Figura 6.4.9. Ejemplo de un modelo de coste por servicio

El modelo de costes por servicio es una forma de asignar internamente los costes
con el fin de conocer el coste total de prestacin de cada servicio. Para ello, prime-
ramente se obtiene la informacin contable por elemento de coste segn la estruc-
tura comn definida: costes de hardware, costes de software, costes de personal,
costes de ubicacin fsica, costes de servicios externos y costes de transferencia.
Una vez recopilados todos los costes, se clasifican los costes en dos tipologas,
directos o indirectos:
Costes directos del servicio. Son aqullos que pueden atribuirse de manera
clara a un nico servicio. Por ejemplo: un servicio que se ejecuta en una
mquina especfica.
Costes indirectos. Son aqullos en los que se incurre de forma comn a
todos los servicios o en un nmero acotado de ellos. Por ejemplo, la red o el
departamento de soporte tcnico, que tendrn que ser distribuidos entre
todos de manera equitativa. Al distribuir los costes indirectos se dan dos
casos:
Costes indirectos imputables a un servicio. Son aquellos costes
de recursos comunes que razonablemente se pueden imputar a un ser-
vicio mediante un tipo de prorrateo por el uso que hace el servicio del
recurso. Por ejemplo, el consumo de CPU de un servicio en una mquina
virtual.
Costes indirectos no imputables a un servicio o no absorbibles. Es el
coste de cualquier recurso que presta servicios de una forma comn a
todos y que no tiene una relacin posible con un servicio o cuya imputa-
cin es muy compleja. Se repercute entre todos los servicios del modo ms
justo posible. Estos elementos comunes pueden ser de hardware, de soft-
ware, de personal, de ubicacin, de servicios externos o de transferencia.
Por ejemplo, un cortafuegos del centro de datos, los sistemas de aire acon-
dicionado, el personal administrativo, etc. En este caso, los costes se dis-
tribuyen en base a una tasa comn que incrementa los costes del servicio
calculados hasta ese momento.
La suma de los costes totales asignados a los servicios debe ser igual a la suma de
los costes iniciales.
Registrar las compras y los costes. La actividad fundamental de la contabiliza-

cin es el registro de los costes incurridos. Los costes en TI se incurren a travs de
una compra o a travs de una imputacin interna de otro departamento, como por
ejemplo, los costes de personal (nminas, viajes, administracin, etc.) o los de
transferencia (imputaciones de otras unidades como servicios generales o seguri-

dad fsica).
La misin principal en esta actividad es conseguir que el departamento de contabi-
lidad realice las anotaciones contables contemplando las necesidades de TI. Para
ello, TI deber colaborar en proporcionar informacin precisa sobre el desglose de
las partidas en cada una de las compras adjudicadas (equipamiento hardware, pro-
ductos software, consultora, servicios tcnicos, formacin, etc.).
Facturacin de los servicios de TI

La facturacin es el conjunto de tareas que permite calcular el precio de los servi-
cios de TI que utilizan los clientes y la emisin de las facturas asociadas. Requiere
que se fijen unos precios justos y entendibles por todas las partes y que se lleve un
registro del consumo o utilizacin de estos recursos.
Las Normas ISO/IEC 20000 no cubren esta actividad por considerarla un requeri-
miento no generalizable a todas las organizaciones. Otras buenas prcticas del mer-
cado, como por ejemplo ITIL, s recomiendan establecer una relacin tipo comer-
cial entre TI y sus clientes internos. La facturacin es especialmente til para
moderar la demanda de los clientes.
La facturacin, condicionada por la informacin aportada por la contabilidad e ins-
pirada en la experiencia del mercado en la facturacin de productos y servicios,
debe ser tambin sencilla (precio por usuario, precio por servicio, precio por trans-
accin, etc.).
Existen dos situaciones de partida muy distintas. Una, que la empresa venda los
servicios de TI al exterior (al mercado o a las empresas pertenecientes a un mismo
grupo), en cuyo caso la facturacin es obligada y se realiza a travs del canal de fac-
turacin-cobros habitual de la empresa; y otra, que TI sea un departamento
interno. En este caso TI enva los detalles de los consumos y los precios acordados
al departamento financiero de la empresa, para que proceda a la imputacin o
transferencia de los costes a las reas cliente. En ambos escenarios, el contacto con
el cliente se realiza bajo el proceso de relaciones con el negocio.
Muchas organizaciones de TI consideran que la facturacin interna no es una tarea
prioritaria. En caso de no realizarse la facturacin real, es aconsejable que al menos
se informe al cliente de los costes en los que ha incurrido por los servicios prestados.
Cuanto ms precisa es la facturacin, mayor esfuerzo se requiere en la contabiliza-
cin de los gastos. Cada organizacin debe encontrar su punto de equilibrio entre
el detalle deseado y la complejidad asociada.
Existen diferentes tipologas a la hora de calcular los costes, las dos ms utilizadas
son:
En base al coste total de la propiedad o TCO (Total Cost of Ownership), que
calcula todos los costes necesarios durante el ciclo de vida completo del
servicio. En este caso, los clientes soportan la totalidad de los costes de pro-
visin y prestacin del servicio.
En base al coste marginal, calculando el coste en funcin del incremento en el
total de costes por proveer un servicio adicional. Slo se repercuten al cliente
los costes incrementales del ejercicio. Es una forma ms sencilla e imprecisa de
repercutir los costes, pero igualmente sirve para moderar la demanda.
Los modelos ms utilizados para la distribucin de los costes en funcin de los con-
sumos son:
Coste por usuario de los servicios. En este modelo, se carga una cuota fija
por cada usuario con independencia del uso que se realice. Muy utilizado en
los servicios al puesto de trabajo (PC, archivos en red, navegacin por Inter-
net, correo electrnico, etc.). Es un modelo sencillo, pero poco equitativo.
Para que tenga su efecto de moderar la demanda, debe combinarse con otros
costes que sean reflejo del consumo variable. Tambin se utiliza para reper-
cutir los costes de las aplicaciones con complejidad de administracin o
cuando el coste de las licencias es alto.
Coste por capacidad de proceso consumida. Forma histrica de medicin
en el mbito mainframe. Las mediciones son sencillas y las proporciona el
propio sistema. Se factura por tiempo de uso del procesador. El coste por
MIP (Millones de Instrucciones por Segundo) en el mainframe, o por MIP
equivalente para entornos abiertos, es un dato con benchmarking del mercado.
Coste por servidor (o por caja). Se tipifican los servidores segn su sistema
operativo y capacidad para fijar un precio por cada uno de ellos. Es un modelo
poco preciso, pero sencillo y fcil de contrastar con los inventarios. Por ello se
utiliza mucho en los contratos de outsourcing completos. En el precio se distin-
gue entre los servidores que se compran y entre los que slo se administran.
Coste por capacidad de proceso asignada. En los nuevos entornos virtua-
lizados, un servidor alberga varias mquinas virtuales, por lo cual la capaci-
dad de proceso asignada es una medida algo ms precisa que la medicin por
servidores fsicos.
Coste por unidad de almacenamiento. En relacin al almacenamiento, se
miden los gigas (GB) o los teras (TB) netos totales instalados o los asig-
nados a un cliente para cada servicio.
Aunque ninguno de estos modelos para la imputacin de los consumos es muy pre-
ciso, su contabilizacin mensual resulta sencilla.
Una vez calculado el coste de la provisin y prestacin del servicio, se pueden apli-
car distintas formulas de facturacin:
Precios fijos o tarifa plana. El precio mensual es constante, con indepen-
dencia del consumo.
Precios con dos tramos. La cual incluye un trmino fijo para cubrir los cos-
tes fijos y un trmino variable en funcin del consumo que recuperara los
costes variables.
Precios alineados con el mercado. Los precios se regulan por el propio
mercado o por benchmarking externos.
En cualquier caso, el modelo de facturacin debe ser sencillo y entendible por las
partes. Para la fijacin del precio se pueden seguir varias tendencias: la ms utili-
zada para servicios internos es cuando los precios se basan en el coste real de los
servicios; otra es el establecimiento del precio segn la demanda que exista del
mismo o segn la exclusividad del servicio ofertado.
En los primeros aos o ejercicios en que se aplique la facturacin, se deben revisar
las tendencias del consumo de los clientes y usuarios para evitar que las estruc-
turas de precios estn generando distorsiones en el consumo ptimo de los servi-
cios de TI.
Supervisin del funcionamiento del propio proceso

Su objetivo es medir y revisar el cumplimiento de los objetivos del proceso. Se debe
comprobar que se realiza el seguimiento del presupuesto y sus cierres, que no se
ejecutan compras sin la autorizacin de este proceso, que se contabilizan todos los
costes con el detalle definido, que se realiza la facturacin, etc.
En este proceso es especialmente importante establecer un programa de auditoras
y revisiones del cumplimiento de los requisitos legales y la normativa interna.
Como gran parte de la actividad del proceso la realizarn las reas econmicas de la
empresa, las auditoras y las revisiones deberan ser conjuntas.
Las revisiones, evaluaciones y auditoras del proceso se deben registrar, junto con
las conclusiones obtenidas, las acciones correctivas identificadas y las comunicacio-
nes realizadas a las partes correspondientes.
Mejora del proceso de gestin financiera de TI

Al igual que el resto de los procesos, se debe tener en cuenta la actividad de
mejora continua: monitorizar, informar, dirigir la calidad y cumplimiento de lo
establecido, comunicar resultados y establecer las mejoras que se deben realizar.
Es importante velar por que el control econmico necesario no genere una
burocracia innecesaria. Se tienen que analizar los atrasos e ineficiencias que
genera el propio proceso para ir implementando medidas correctoras. La auto-
rizacin de partidas por bloques a las reas de TI puede ser una forma de agili-
zar las actividades, delegando el control detallado de las pequeas partidas de
gasto.
Estas mejoras se incorporarn, para su tratamiento y aprobacin, en el plan unifi-
cado de mejora de la gestin del servicio (vase el captulo 4) y debern coordi-
narse con el rea financiera de TI.
Roles participantes en la gestin financiera de TI

Como en el resto de los procesos, los roles intervinientes en este proceso se estruc-
turan en: los roles propios del proceso y los roles ajenos al mismo. En una organi-
zacin interna de TI se pueden simplificar mucho, pero la situacin cambia si la
empresa se dedica a la comercializacin de servicios de TI, en cuyo caso es necesa-
rio desarrollar mucho ms los roles expuestos a continuacin.
El gestor financiero de TI es el responsable de que la actividad del proceso se
lleve a cabo: dialoga con el rea financiera de la empresa, elabora los presu-
puestos, realiza su seguimiento, supervisa la contabilizacin del gasto de TI,
supervisa la facturacin, etc.
Los administradores o personal de soporte al proceso ayudan al titular del
proceso en el control de toda la actividad.
El rea o departamento econmico-financiero de la empresa realiza muchas
de las actividades de gestin presupuestaria, contabilidad y facturacin del
proceso. En esta rea destaca el rol del contable que realiza la contabilizacin
del gasto de TI, al igual que para el resto de reas de la empresa.

cumplan los niveles pactados, incluido el econmico.
El propietario del modelo de gestin de TI (SGSTI), que acta como pro-

pietario del proceso (process owner), define el proceso y vela por el cumpli-
miento de sus actividades, y se encarga de la mejora continua del mismo.
Todo ello, de una forma integrada con el modelo de gestin de TI incorpo-
rado en el SGSTI.
El comit de cambios (CAB), que aprobar los cambios, con su correspon-
diente coste econmico asociado.
El gestor de la capacidad, que proporciona la informacin del consumo tc-
nico de los recursos, necesaria para las previsiones presupuestarias y para la
facturacin a los clientes.
El gestor de las relaciones con el negocio, que trata con las reas cliente los
presupuestos para su rea, los costes de los servicios y el detalle de las factu-
raciones.
Roles del proceso
OTROS PROCESOS PROCESO DE GESTIN

FINANCIERA DE TI
Responsable de la Comit de cambios

gestin del servicio (CAB)
SGSTI Gestor financiero

de TI
Administrador y
soporte del proceso
Propietario del
Gestor de la
modelo (SGSTI)
capacidad
Gestor de las
relaciones con Departamento financiero
de la empresa Contables de
el negocio la empresa
Figura 6.4.10. Roles del proceso de gestin financiera de TI

El personal de TI, que imputa su dedicacin a las diversas tareas con el fin
de tener una contabilizacin detallada de los servicios.
Las diversas reas de TI, que realizan las peticiones de compra.
En la figura 6.4.10 se muestran los roles principales relacionados con el proceso.
Mtricas
Las mtricas se deben adaptar a las necesidades de gestin y control que tenga cada
organizacin. Las mtricas de gestin financiera de TI suelen proporcionar infor-
macin sobre los costes, en forma de ratios, y medidas especficas sobre el funcio-
namiento del proceso:
Ratios sobre presupuestos y costes:
Presupuesto de TI en relacin al volumen de facturacin de la empresa
(ITR, IT Spending per unit of Revenue). Representa el porcentaje de los
ingresos de la empresa que deben destinarse a sostener las tecnologas de
la informacin en la empresa.
Peso del presupuesto de inversin (CAPEX) en relacin al presupuesto
total de TI.
Ratio de coste total de TI por usuario.
Ratio de coste total de TI por potencia de proceso instalada (MIP, MIP
equivalente, specs, transacciones por minuto, etc.)
Ratio de coste total de TI por GB almacenamiento instalado.
Con frecuencia se miden ratios de costes sobre reas o temticas de inters
en un perodo dado, como por ejemplo, el porcentaje de presupuesto dedi-
cado a seguridad informtica, presupuesto dedicado a innovacin, etc.
Mtricas sobre el proceso:

Porcentaje de los servicios que tienen los costes conocidos en detalle.
Porcentaje de desviacin o del cumplimiento en presupuesto.
El ITR es el ratio ms utilizado y ms importante, pues refleja el coste de TI

en relacin al volumen de la facturacin del negocio. Dependiendo del sector
de negocio, este indicador suele oscilar entre el 3% y 8% segn las necesidades
tecnolgicas de la empresa 3. En la figura 6.4.11 se muestran algunas de las princi-

pales mtricas de la gestin financiera de TI.
de itSMF Espaa
Adicionalmente, tambin se pueden utilizar otro tipo de indicadores econmicos

dependiendo del anlisis que se quiera realizar, como por ejemplo:
Inversin de TI frente a la inversin de la empresa (CAPEX TI/Presupuesto
de inversin de la empresa).
Gasto operativo de TI frente al presupuesto de TI (OPEX TI/Presupuesto
de TI).
Coste de los recursos humanos de TI frente al presupuesto total de TI.
Resumen
El crecimiento de los recursos dedicados a los sistemas de informacin y la utili-
zacin extensiva de los servicios de TI, junto con la tendencia a la reduccin de
3
El lmite inferior del ITR puede llegar al 1%, como es el caso del sector de distribucin.
presupuestos asignados, provoca la necesidad imperiosa de una gestin financiera en

TI ms avanzada que posibilite una adecuacin de los costes y las inversiones a los
presupuestos disponibles, para ser capaces de satisfacer las necesidades del negocio.
En la actualidad, los proveedores de servicios de TI reciben presiones desde dife-
rentes puntos para que reduzcan sus costes. Pero al mismo tiempo se les pide que
mantengan e incluso mejoren los servicios y, todo ello, en un entorno tecnolgico
cada vez ms complejo. La ausencia frecuente de una gestin financiera en TI trans-
parente y en lenguaje del negocio, provoca que, mientras la direccin recorta los
presupuestos de TI, las reas cliente continen realizando unas demandas irreales e
injustificables en este nuevo escenario.
La gestin financiera de los servicios de TI es aplicable tanto a organizaciones de
TI internas como a proveedores de servicios al mercado. Se articula en torno a tres
grandes actividades: presupuestar, contabilizar y facturar.
La elaboracin de los presupuestos permite controlar y predecir el gasto eco-
nmico mediante un ciclo de negociaciones peridicas, que permiten su con-
feccin, publicacin y seguimiento.
La contabilidad de TI realiza el registro en las cuentas del gasto del dinero,
haciendo nfasis en la identificacin de los costes por servicio, cliente y por
actividad.
La facturacin de los servicios de TI, actividad opcional en ISO/IEC 20000,
permite trasladar a los clientes, de forma real o informativa, el coste ocasio-
nado por los servicios prestados, de esta forma se influye en la demanda y
grado de utilizacin de los servicios.
Otro objetivo del proceso es la integracin plena con los departamentos financie-
ros y contables de la empresa evitando mantener registros paralelos. Pero estos sis-
temas de la empresa se deben adaptar para satisfacer tambin las necesidades de
informacin analtica de TI.
Beneficios
El principal beneficio es una gestin ms eficiente y controlada de los gastos en tec-
nologas de la informacin.
La presupuestacin es la actividad clave en el proceso de gestin financiera de los
servicios de TI y proporciona:
Mejora en la priorizacin de los proyectos de inversin. Toma de decisiones
sobre los servicios en base a anlisis de rentabilidad de las inversiones.
Mayor agilidad en la realizacin y ejecucin del presupuesto.

Mejora en la planificacin de las compras, consiguiendo una mejora en los
precios de adquisicin.
Minimiza los desvos en las estimaciones establecidas, proporcionando una
organizacin de TI ms predecible en sus costes para el negocio.
Los principales beneficios de la contabilidad de los costes en los servicios de TI son:

Proporciona informacin detallada de los costes incurridos, para el anlisis
de ineficiencias, y la optimizacin de la capacidad y la disponibilidad de los
servicios.
Mejora la precisin de las predicciones presupuestarias futuras.
Pasa a trminos econmicos la infrautilizacin o sobreutilizacin de las
infraestructuras.
Facilita informacin sobre el coste de cada servicio, de cada cliente y de
las principales actividades.
Los principales beneficios de un proceso adecuado de facturacin son:

Uso eficiente de los servicios de TI por parte de los clientes y usuarios.
Crear una consciencia en los clientes del coste incurrido por la organizacin
de TI en la prestacin de servicios de TI.
Moderacin de la demanda por parte de los clientes y del consumo por parte
de los usuarios, al conocer los costes y pagar, si procede, por ellos.
Reduccin del TCO de los servicios debido al conocimiento y control de sus
estructuras de coste.
Disponibilidad de los precios como herramienta a utilizar en la gestin de la
demanda.
Recuperacin del coste incurrido en TI mediante los pagos de los clientes,
en caso de que la estrategia corporativa no marque TI como un centro de
coste.
Quiz el beneficio ms relevante es el de proporcionar el nexo de unin entre la

organizacin de TI y el negocio mediante parmetros objetivos y mesurables, que
contribuyen a lograr el equilibrio entre ambos, evitando que la organizacin de TI
se separe demasiado de las necesidades reales del negocio y que los negocios
demanden servicios no justificables en trminos de coste/beneficio.
Cules de las tres actividades principales de este proceso (presupues-
tar, contabilizar y facturar) se realizan en su organizacin?
Indique tres procesos que son necesarios tener implantados previa-
mente para que el proceso de gestin financiera de TI tenga xito.
4
6.5. Gestin de la capacidad 369
6.5. Gestin de la capacidad
Figura 6.5.1. Esquema general del proceso de gestin de la capacidad
La actividad del negocio no debera ser coartada por una falta de capacidad o un mal
rendimiento de los sistemas de informacin. En momentos de mxima demanda
los sistemas deben responder. Los incrementos de carga deben estar previstos, los
sistemas diseados para absorberlos y tambin lo deben estar para poder crecer
de forma dinmica. Pero alcanzar este estatus de podero no es una tarea sencilla.
Se requiere la ejecucin de un conjunto complejo y diverso de actividades. En este
proceso se explican las ms relevantes que estn contenidas en las mejores prcticas
del mercado (vase la figura 6.5.1).
El proceso de gestin de capacidad, muy maduro en la dcada de 1980 con los
entornos mainframe, pas al olvido a comienzos de la dcada de 1990 con la lle-
gada de los sistemas abiertos; cuando duplicar la capacidad de un equipo era ms
econmico que pagar a un ingeniero de sistemas para que la planificara. Pero las
alegras y derroches en TI finalizaron con la burbuja de las puntocom. Se ha
vuelto a la senda del estricto control econmico y al seguimiento del retorno de
la inversin. As, la gestin de la capacidad vuelve a tener plena vigencia en los
comienzos del siglo XXI.
Como si los ajustes econmicos no hubieran sido justificacin suficiente, las ten-
dencias a la consolidacin y a la virtualizacin de las infraestructuras refuerzan la
necesidad de disponer de una buena gestin de la capacidad (y rendimiento).
Implantar plataformas comunes requiere gestionar y controlar los recursos que
consume cada servicio para evitar que interfiera en el rendimiento de sus compae-
ros de habitculo.
Recientemente se ha incorporado a la ecuacin la necesidad de ajustar el consumo
elctrico, como consecuencia de los problemas con la refrigeracin de los centros
de datos, la reduccin del impacto ambiental de las TI y la necesidad de rebajar la
factura elctrica. Este recin llegado sita tambin a la gestin de la capacidad
como un buen instrumento para ejecutar las polticas medioambientales, o verdes,
en TI relativas al uso eficiente de las infraestructuras.
Gestionar la capacidad de los servicios de TI permite garantizar que se tendr, en
todo momento, la capacidad suficiente para cubrir la demanda actual y futura acor-
dada con el negocio, manteniendo siempre un coste razonable y equiparable con el
mercado. La gestin de la capacidad debe equilibrar las previsiones de utilizacin o
carga con los recursos disponibles, de modo que se eviten prdidas o degradacio-
nes del servicio. Pero tambin debe vigilar el coste de la sobrecapacidad para evitar
el derroche de recursos.
Gestionar adecuadamente la capacidad no es una tarea fcil. Se debe tener un cono-
cimiento tcnico de las infraestructuras de TI, pues se encarga de supervisar la capa-
cidad actual, de anticipar las ampliaciones necesarias, de modelar el comporta-
miento de las aplicaciones, y del ajuste y mejora continua del rendimiento.
Adems, requiere un entendimiento de la actividad del negocio, para poder predecir
las variaciones en el consumo de recursos (crecimiento vegetativo, campaas de
marketing, variaciones estacionales, acontecimientos singulares, etc.). La gestin de la
capacidad debe conocer las variaciones temporales del negocio para ajustar los recur-
sos, como es tpico en la facturacin mensual. Segn el ciclo del negocio, se pueden
presentar campaas segn la estacin del ao. As, en las empresas de telefona mvil,
las pocas de fin de ao y de verano se dispara la actividad de los consumidores y los
sistemas se ven sometidos a su mxima carga. Tambin hay que tener en cuenta acon-
tecimientos puntuales, como el lanzamiento de una campaa de marketing. Por todo
ello, es necesaria una comunicacin fluida entre la gestin de la capacidad y el negocio.
En la figura 6.5.2 se presenta una visin introductoria al proceso de gestin de la
capacidad.
El objetivo del proceso de gestin de la capacidad es garantizar que siempre existe
la capacidad de TI necesaria, justificable en trminos de coste, y ajustada a las nece-
sidades del negocio, actuales y futuras.

capacidad Conocimiento de la evolucin de
actividad del negocio en su relacin
con la utilizacin de las TI.
Definicin:
Gestin adecuada de la capacidad
Procesos que velan por que los servicios existente, evitando las carencias y
tengan en todo momento la capacidad tambin los excesos.
necesaria y trabajen con un rendimiento Un rendimiento optimizado.
ptimo.
Garanta de que los servicios cumplen
con la capacidad requerida en cada
momento.
Objetivo:
Ahorro de costes, al tener los
Asegurar que el proveedor del servicio recursos ajustados a las necesidades.
tiene, en todo momento, la capacidad Prepara un plan de capacidad de TI.
suciente para cubrir la demanda
Predicciones continuas y peridicas
acordada, actual y futura, de las
basadas en datos de negocio y de la
necesidades del negocio del cliente.
tecnologa.
Minimiza las incidencias por falta de
capacidad.
Figura 6.5.2. Introduccin al proceso de gestin de la capacidad
El proceso de gestin de la capacidad debe ser el foco central de todos los temas
relacionados, tanto con la capacidad como con el rendimiento. Las tareas diarias
debern realizarse por los grupos tcnicos de la organizacin (tcnica de sistemas,
administracin de bases de datos, ingeniera, soporte de redes, etc.), trabajando
para este proceso en las actividades que marca la gestin de la capacidad.
La gestin de la capacidad trata aspectos proactivos y reactivos.
La faceta proactiva comprende todas las actividades que permiten anticiparse
a una carencia de capacidad y a un escaso rendimiento, como por ejemplo, la
previsin de la demanda por parte del negocio, la previsin de la capacidad
necesaria por los servicios, el modelado de servicios, el dimensionado de las
aplicaciones, el plan de capacidad, etc.
Los aspectos reactivos del proceso estn relacionados con la deteccin de faltas
de capacidad, el ajuste o tuning de componentes o de los servicios, la provisin
con urgencia de soluciones, el establecimiento de umbrales en la monitoriza-
cin, etc.
En ITIL v2 y v3, la gestin de la capacidad se estructura en tres reas: gestin de la

capacidad del negocio, de los servicios y de los recursos. Como en las Normas
ISO/IEC 20000 no se establece nada al respecto, en este libro se ha decidido seguir
el mismo esquema de ITIL por considerarlo un enfoque muy amplio que abarca
desde una visin del negocio, hasta el detalle tcnico de los recursos.
Siguiendo con el alcance dado en ITIL, el mbito de la gestin de la capacidad
comprende todos los aspectos necesarios para que los servicios estn operativos con
el rendimiento pactado, como por ejemplo:
El seguimiento y monitorizacin de la capacidad y rendimiento de los servi-
cios y de la infraestructura:
Los servidores, almacenamiento, redes, etc.
Las unidades de soporte. La capacidad de ejecucin de los recursos huma-
nos, propios o de servicios subcontratados. nicamente en lo relativo a su
participacin en el soporte de los servicios de TI.
Las aplicaciones.
Las instalaciones, climatizacin y suministro elctrico.
Los proveedores y cmo se contempla la variacin de capacidad en sus con-
tratos (de forma coordinada con el proceso de gestin de suministradores).
Revisin de equipamiento y aplicaciones sin utilizar.
La ejecucin de mejoras que conlleve la utilizacin ms eficiente de los recur-

sos existentes.
La realizacin de previsiones sobre la demanda y utilizacin de los recursos
de TI.
La influencia en la demanda de los recursos, con el apoyo de la gestin finan-
ciera.
Generacin del plan de capacidad y las sucesivas actualizaciones.
El proceso de gestin de la capacidad tambin gestiona la obsolescencia de los equi-

pos y los servicios, realiza la evaluacin de los efectos sobre la capacidad que pue-
den producir los cambios y trabaja en la identificacin del impacto de las nuevas
tecnologas.
Igualmente, debe tener en cuenta el impacto de la evolucin del entorno exterior
de la empresa, como por ejemplo, cambios legislativos, cambios sociales que afec-
ten en la demanda en TI, etc.
Adems, el proceso debera tratar otros aspectos relacionados con la mejora o inno-
vacin en las plataformas informticas, como por ejemplo:
La automatizacin de la provisin de peticiones de los usuarios, autorregis-
tro, autorresolucin, distribucin de software, etc.
La automatizacin de los centros de datos, con la implantacin de polticas
de asignacin dinmica de recursos segn las previsiones de carga, provisin
automatizada de infraestructura virtual, etc.
La consolidacin de servidores y del almacenamiento.
La virtualizacin de los sistemas operativos.
La gestin de la obsolescencia del equipamiento y la renovacin del parque.
La desconexin y retirada de equipos. La gestin del apagado de aplicacio-
nes sin uso.
En coordinacin con las polticas medioambientales en TI (green IT), parti-
cipa en la implantacin de las polticas relacionadas con el consumo energ-
tico y de materiales menos contaminantes, como por ejemplo:
El seguimiento del consumo elctrico. Implantacin de polticas de reduc-
cin del consumo en equipos, como la entrada en suspensin tras pero-
dos de inactividad.
La definicin de polticas de compra de equipamiento certificado con eti-
quetas verdes de bajo consumo y materiales reciclables.
Una correcta gestin de la capacidad permitir no slo reducir las incidencias y

degradaciones del servicio por falta de recursos, sino que anticipa las necesidades
permitiendo a la organizacin de TI trabajar con menos presin y con costes ms
ajustados. En la figura 6.5.3 se muestran los principios bsicos que se deben tener
en cuenta al implementar el proceso.
Un entendimiento del negocio y de la evolucin del mercado es esencial para el
diagnstico de la variacin de la demanda en la utilizacin de los recursos de TI. El
contacto con el negocio se debe llevar a cabo manteniendo un dilogo continuo
con las unidades clientes, apoyndose en la gestin de relaciones con el negocio.
As, el contacto entre TI y los clientes est coordinado. La gestin de la capacidad
tiene que entender la estrategia a largo plazo del negocio al tiempo que propor-
ciona informacin sobre las ltimas ideas, tendencias y tecnologas que desarrollan
los proveedores de hardware y software.
El conocimiento tcnico de las infraestructuras tecnolgicas es necesario para realizar
una adecuada monitorizacin de la capacidad y una gestin tcnica de la capacidad
de los recursos. Debe conocer el potencial de la tecnologa y aprovechar las innova-

ciones para asegurar que los servicios de TI se adaptan a las expectativas cambian-
tes del negocio. La gestin de la capacidad debe promocionar que los avances tec-
nolgicos se incorporen al diseo de los sistemas con el fin de facilitar la
flexibilidad de las infraestructuras y acortar los tiempos de provisin de nuevas
capacidades. Destacan la consolidacin y virtualizacin de los servidores y del alma-
cenamiento, como nuevos principios que se deben tener en cuenta en la arquitec-
tura tecnolgica de los sistemas. La automatizacin de la provisin de recursos
siguiendo unas polticas predefinidas, permitir asignar dinmicamente los recur-
sos a los servicios segn se necesiten. Otras estrategias son la compra de infraes-
tructura con capacidad preinstalada que se puede activar por software cuando se
necesita (capacidad bajo demanda), los blade servers con una gestin conjunta como
pool de servidores, etc.
La previsin de la evolucin de la demanda y de la tecnologa permitir a TI ir por
delante de las crisis internas y gestionar las necesidades con el plazo necesario. En
el mbito de la previsin y anticipacin, se utiliza el plan de capacidad como el ins-
trumento formal ms importante de este proceso.
Previsin
Utilizacin de la carga
o carga
Capacidad Plan de
Previsiones
del negocio Modelos capacidad de capacidad
Dimensionados Informes sobre

CDB recursos y
servicios
Base de datos
de capacidad Informes de
excepciones
Capacidad de
los servicios Datos de negocio
Datos del servicio
Datos tcnicos
Datos financieros
Datos de utilizacin
Capacidad de Umbrales utilizacin Monitorizacin

los recursos Umbrales de SLA de la capacidad Ajuste o tuning
Figura 6.5.4. Componentes principales del proceso de gestin de la capacidad
Los principales componentes del proceso son:

Ajuste o tuning. Optimizacin de los sistemas con respecto de la carga actual o
prevista de acuerdo con el resultado del anlisis de la informacin de rendimiento
de los servicios.
Base de datos de gestin de la capacidad (CDB, Capacity Data Base). La base de
datos de gestin de la capacidad centraliza los datos y el conocimiento de este pro-
ceso. Es un repositorio en el que se almacenan informacin de negocio, de servicio,
tcnica, financiera, de utilizacin, etc. Las actividades de la gestin de la capacidad
almacenan y utilizan los datos contenidos en la CDB. Normalmente, la CDB no
ser una nica base de datos, sino que es un concepto lgico que recopila datos,
ficheros de log, informes, documentos, etc.
Carga, utilizacin o demanda operacional. Consumo o utilizacin de los recur-
sos por parte de los clientes y usuarios. Se utiliza como entrada para el dimensiona-
miento y en la definicin de polticas de utilizacin. Conviene no confundir este
trmino (demanda operacional) con el concepto de la gestin de la demanda utili-

zado en el libro Estrategia del Servicio de ITIL v3 (demanda estratgica), que se
centra en gestionar las peticiones (demandas) de nuevos servicios realizadas por el
negocio hacia TI; mientras que la carga o utilizacin tratan con las previsiones de
uso o trabajo real que ejecutan los servicios.
Dimensionado. Estimacin de la capacidad que necesitar un servicio, una aplica-
cin o un recurso cuando entre en el entorno productivo. Se contemplan varios
escenarios de evolucin de la carga de trabajo. Se suele realizar en la fase de diseo
(normalmente sobre los crticos) o en cambios importantes.
Gestin de la capacidad del negocio. Subproceso que se encarga de garantizar
que se consideran, planifican e implementan los requisitos de capacidad y rendi-
miento del negocio para los servicios de TI.
Gestin de la capacidad de los servicios. Subproceso que se centra en la gestin
de la capacidad y el rendimiento de los servicios de TI. Se encarga de garantizar el
cumplimiento de estos aspectos especificados en los acuerdos del nivel de servicio.
Gestin de la capacidad de los recursos. Subproceso que se encarga de la gestin
de la capacidad y el rendimiento de todos los componentes contenidos en la
infraestructura de TI.
Informe sobre los recursos y los servicios. Muestra el comportamiento en
cuanto a capacidad y rendimiento de los recursos y servicios. Refleja el grado de
ocupacin o de saturacin de los mismos.
Informe de excepciones. Pone foco en situaciones de incumplimiento de los nive-
les de servicio o de saturacin de la capacidad de los recursos o servicios. Analiza
las causas y proponen soluciones.
Modelado. Predicciones del comportamiento de los servicios frente a variaciones
previsibles de la carga de trabajo. Las principales tcnicas de modelado son el anli-
sis de tendencias de consumo, el modelado analtico o matemtico, las simulacio-
nes ante variaciones de carga, etc. En el mejor de los casos, los modelos se calculan
de forma emprica sobre una instalacin piloto. Los modelos deben ser sencillos y
estar representados en forma de tabla de valores o de grfica.
Monitorizacin. Es la medicin de la capacidad, rendimiento y utilizacin de cada
servicio y recurso de manera continuada. La monitorizacin utiliza como entradas
los umbrales de utilizacin de recursos y los umbrales establecidos en los acuerdos
de nivel de servicio y en las polticas tecnolgicas.
Previsin de la carga. Actividad que consiste en pronosticar la carga o utilizacin
de los recursos informticos.
Previsin de la capacidad. Estimaciones sobre la capacidad necesaria en el futuro

de los componentes y servicios. Se realiza a partir de la experiencia histrica y de la
base de datos de capacidad. Las previsiones se incorporan en el plan de capacidad.
Plan de capacidad. Es el documento sobre el que se articula la dotacin de recur-
sos en TI. Describe los niveles actuales de utilizacin de recursos y de rendimiento
de los servicios, y estudia los planes y estrategia de negocio para predecir los recur-
sos futuros necesarios para los servicios de TI.

El proceso de gestin de la capacidad carece de un gran flujo predefinido que aglu-
tine a la mayora de sus actividades, sino que stas se desencadenan por eventos dis-
cretos, unas veces por que se alcanzan las fechas para la realizacin de un informe o
del plan de capacidad, otras por una alarma de falta de rendimiento, por la llegada
de un nuevo servicio que requerir dimensionarlo, porque antes del paso a explota-
cin habr que comprobar el consumo de recursos y el rendimiento de las nuevas
aplicaciones, etc.
En el proceso, nicamente existe un pequeo flujo, denominado ciclo de mejora de
la capacidad, que revisa de forma continua y permanente la capacidad y el rendi-
miento.
Este proceso requiere profundos conocimientos tcnicos, tanto en el mbito del
desarrollo, como en la gestin de las infraestructuras, especialmente en las activida-
des de ajuste o tunning. Conviene tener presente que el proceso gestiona tanto la
capacidad de los sistemas como su rendimiento. Ambos aspectos influyen directa-
mente en la disponibilidad y tiempo de respuesta de los servicios. Por ello, el pro-
ceso est muy vinculado a la gestin de la disponibilidad.
A pesar de no tener una secuencia encadenada de acciones, el proceso tiene unas
entradas, unas actividades y unas salidas. Tradicionalmente, en ITIL, las activida-
des del proceso se estructuran en forma matricial. Primero se contemplan los tres
grandes subprocesos: la gestin de la capacidad del negocio, de los servicios y de
los recursos para describir, posteriormente, un conjunto de actividades que se reali-
zan en cada uno de estos mbitos: elaborar el plan de capacidad, ciclo de mejora de
la capacidad, etc. En la figura 6.5.5 se muestra un esquema de ellas.
Las entradas que desencadenan el inicio de alguna actividad en el proceso son la
proximidad de la fecha para iniciar la revisin del plan de capacidad (normalmente
de forma trimestral y como mnimo anual); la activacin de una alarma sobre capa-
cidad o rendimiento, que requiere actuacin antes de que se produzca un incidente;
Desencadenantes Gestin capacidad del negocio. Salidas principales:

del proceso: Plan de capacidad.
Gestin capacidad de servicios.
Fecha preparacin del CDB.
Gestin capacidad de recursos.
plan de capacidad o
Informes capacidad.
de informes. x x x Elaborar el plan de capacidad.
Dimensionado de
Alarma de capacidad o x x x Ciclo de mejora de la aplicaciones.
rendimiento. capacidad y rendimiento:
Proyectos desarrollo. Monitorizacin. Salidas secundarias:
Variaciones en los SLA. Anlisis. Umbrales y alarmas.
Solicitud de un informe Ajuste o tunning. Lneas base y perfiles.
de capacidad o
Implementacin. Recomendaciones
rendimiento.
para SLA.
Cambio en la estrategia x Relacionarse con otros procesos. Recomendaciones
o tecnologa.
para polticas de
x Influir en la utilizacin.
Entradas de soporte: facturacin.
Estrategias del negocio x x Modelado. Cambios proactivos.
y de TI.
x Dimensionado de aplicaciones. Planificacin
SLR y SLA. operacional revisada.
x x x Realizacin de informes. Propuesta de
Incidentes y problemas
ocurridos. actividades para la
Administrar la base de datos de
mejora de los servicios.
CMDB y CDB anterior. capacidad (CDB).
Lista de cambios.
x x x Supervisin y mejora del proceso.
Presupuestos.
la llegada de un nuevo proyecto, de un nuevo desarrollo, de evolucin de un servi-

cio existente o de cambio de las infraestructuras, que requieren el dimensionado de
recursos; nuevos acuerdos o variaciones a los acuerdos de nivel de servicio existen-
tes (SLA); solicitud por otra rea de un informe de capacidad o rendimiento; un
cambio en la tecnologa o en la estrategia tecnolgica (por ejemplo, se inicia una
poltica de consolidacin y de virtualizacin).
Las entradas que se utilizan en las actividades del proceso como soporte son la
estrategia de negocio para conocer las futuras variaciones de la demanda y la estra-
tegia de TI relacionada con la capacidad y rendimiento; los requerimientos de capa-
cidad demandados y los acuerdos de nivel de servicio pactados; los incidentes ocu-
rridos cuyo origen fue una falta de capacidad o de rendimiento, los problemas
abiertos o cerrados sobre este mbito; la informacin obtenida sobre cualquier ele-
mento a partir de la base de datos de gestin de la configuracin (CMDB, Change
Management Data Base) y la informacin sobre los histricos de monitorizacin en
la base de datos de gestin de la capacidad (CDB, Capacity Data Base); la planifica-
cin de los cambios a partir de la lista de cambios planificados (FSC, Forward Sche-
dule of Changes) o bien change schedule (siguiendo la terminologa ITIL v3), para
conocer en qu momento se necesitar la capacidad; los presupuestos de TI que
establecen los recursos econmicos disponibles; etc.
La gestin de la capacidad tiene tres subprocesos o mbitos de actuacin: el nego-
cio, los servicios y los recursos.
La gestin de la capacidad del negocio. Se enfoca en conocer la capacidad
que va a demandar el negocio para anticiparse en la cobertura de las necesi-
dades. Los requisitos futuros se obtienen a partir de los planes de negocio,
crecimiento, planes de desarrollo, nuevos servicios, etc.
En la capacidad del negocio tambin se incluyen los aspectos de la capacidad
de los servicios en lo concerniente a su relacin con otros procesos: asisten-
cia en la definicin de los requisitos de nivel de servicio de capacidad, diseo
de nuevos servicios y la provisin de infraestructuras, verificacin de SLA en
rendimiento y carga, firma de los acuerdos, etc.
La gestin de la capacidad de los servicios. Se centra en la gestin de la
capacidad y rendimiento de los servicios de TI, que deben cumplir los mni-
mos establecidos en los acuerdos de nivel de servicio. Se puede considerar
como la visin hacia el interior de los servicios centrada, principalmente,
en conseguir su adecuado funcionamiento, ya que las interacciones con el
entorno se tratan en la capacidad del negocio.
La gestin de la capacidad de los recursos. Se centra en la gestin de los
componentes individuales de la infraestructura de TI: capacidad, rendi-
miento, parametrizacin, optimizacin, monitorizacin, obsolescencia, etc.
Siguiendo ITIL, en cada uno de estos tres mbitos se realiza un conjunto de activi-
dades que se enumeran de forma comn, aunque unas son ms especficas de un
mbito y otras, en cambio, se realizan en los tres.
Elaborar el plan de capacidad. Documento que recoge de forma precisa las
necesidades inmediatas y a medio plazo de recursos. Su elaboracin orquesta
un movimiento en toda la organizacin para predecir las necesidades de
capacidad del negocio, de los servicios y de los recursos. Es el documento
maestro que pronostica las necesidades para que se proporcionen los presu-
puestos necesarios.
Ciclo de mejora de la capacidad y rendimiento. Conjunto de 4 activida-

des encadenadas que permiten mejorar de forma permanente la capacidad y
el rendimiento de los servicios y de los componentes. Este ciclo debe estar
actuando de forma continua.
Monitorizacin. Registro automatizado, mediante herramientas, de la
capacidad y el rendimiento de los recursos, de los servicios e, incluso, de
la actividad en el negocio (medida en este caso a travs del uso de los
servicios).
Anlisis. Estudio de los resultados de la monitorizacin para detectar
mejoras.
Ajuste o tunning. Identificacin de las acciones correctoras que se deben
llevar a cabo en los recursos fsicos con el fin de mejorar el rendimiento o
el uso de la capacidad.
Implementacin. Implantacin de las mejoras identificadas (anlisis o
ajuste), siempre bajo el proceso de gestin del cambio, generando las peti-
ciones de cambio (RFC, Request for Change) correspondientes.
Relacionarse con otros procesos. La gestin de la capacidad interacciona

en temas de capacidad y rendimiento con muchos procesos. Da soporte a la
gestin de nivel de servicio (SLR, SLA y cumplimiento de niveles de servi-
cio), necesita de las relaciones con el negocio, establece requisitos, supervisa
las pruebas de gestin de la entrega, interacta con la gestin financiera en la
elaboracin del plan de capacidad, determina las compras necesarias, interac-
ta con la gestin del incidente y del problema para detectar las carencias en
la capacidad o rendimiento, etc.
Influir en la utilizacin. Conjunto de acciones que permiten adecuar el uso
y la carga de trabajo de servicios y recursos generados por parte de las reas
cliente y de los usuarios. En cierta manera gestiona la demanda, entendida
como utilizacin de los servicios. Se encarga de ejecutar las polticas de TI
en cuanto al uso.
Modelado. Prediccin o estimacin de la actividad del negocio o del compor-
tamiento de los servicios bajo varios escenarios de carga. El modelado permi-
tir predecir el rendimiento y el consumo de recursos. Presenta como resultado
tablas y grficos que relacionan actividad, carga, capacidad o rendimiento.
Dimensionado de aplicaciones. Clculo de los recursos que necesitar una
aplicacin para satisfacer los niveles de servicio. Se realiza bien al inicio del
proyecto (en el caso de aplicaciones bajo desarrollo o adquisicin) o en la
fase de pruebas (en el caso de aplicaciones sujetas a mantenimiento). Tam-

bin se puede realizar en cambios importantes. Si se ha realizado el mode-
lado, se utilizarn sus resultados.
Realizacin de informes de capacidad y rendimiento. Preparacin y difu-
sin de informes diversos sobre la utilizacin de recursos (tcnicos y huma-
nos), la capacidad remanente y el rendimiento de los sistemas. Los informes
se realizarn de forma peridica o bajo peticin, en ambos casos coordina-
dos con el proceso de gestin de informes.
Administrar la base de datos de capacidad (CDB). Diseo y creacin de
la base de datos y administracin posterior de la misma. La base de datos
contiene informacin histrica sobre la demanda y crecimiento del negocio,
sobre los servicios y sobre la capacidad de los elementos de configuracin.
Supervisin y mejora del proceso. Revisin continua del funcionamiento
del proceso y de sus actividades con el fin de detectar mejoras al mismo.
Las actividades de este proceso, con su participacin en los mbitos de negocio,

servicios y recursos, se muestran en la figura 6.5.6.
Actividades
Elaborar Ciclo de mejora Relacionarse
el plan de de la capacidad con otros
Subprocesos capacidad y rendimiento procesos
Modelado
Gestin capacidad Monitorizacin

del negocio
Realizacin
de informes
Anlisis
Gestin capacidad Influir en la
de los servicios utilizacin Dimensionado
Ajuste aplicaciones
Gestin capacidad Implementacin

de los recursos
Administrar la base de datos de capacidad

CDB
Supervisin y mejora del proceso
Fuente: Libro ITIL Provisin de Servicio publicado por OGC y e.p.
Figura 6.5.6. Actividades de la gestin de la capacidad

Las principales salidas o resultados del proceso son: el plan de capacidad elaborado o
actualizado, con las previsiones de recursos necesarias; la base de datos de capacidad,
con toda la informacin de capacidad y rendimiento recogida en la monitorizacin;
los informes de capacidad elaborados; y el dimensionado de aplicaciones realizado.
Como resultados secundarios del proceso se obtienen: los umbrales y alarmas para
la monitorizacin de la capacidad y rendimiento; las lneas base en cuanto a la utili-
zacin de recursos y los perfiles de comportamiento; las recomendaciones de par-
tida para los acuerdos de nivel de servicio; las recomendaciones sobre polticas de
facturacin, de cara a influir en el consumo de recursos; los cambios proactivos (y
sus RFC) para la mejora de la capacidad y del rendimiento; la planificacin de las
operaciones revisada, de cara a ajustar los picos en la carga de los recursos; las pro-
puestas de actividades para la mejora de los servicios; etc.
El plan de capacidad
Uno de los principales instrumentos del proceso es el plan de capacidad, cuyo obje-
tivo es predecir las necesidades de capacidad con el fin anticiparse a su demanda.
Alrededor de la elaboracin del plan se desencadena la actualizacin de informa-
cin y revisin completa de la situacin actual. Las actualizaciones del plan marcan
el tempo de este proceso. Al igual que ocurriera en disponibilidad y continuidad, el
plan de capacidad marca el ciclo vital del proceso, que debe ir acompasado con la
gestin financiera de TI.
En el plan de capacidad tambin se incorporan los niveles actuales de utilizacin de
recursos y el rendimiento de los servicios. Se estudian los planes y la estrategia del
negocio. Las estimaciones y suposiciones realizadas se deben indicar con claridad.
Tambin debera incluir recomendaciones sobre los recursos requeridos, sus costes,
los beneficios, el impacto, etc.
Las Normas ISO/IEC 20000 explicitan un conjunto de requerimientos que se
deben cumplir a travs del plan de capacidad:
UNE-ISO/IEC 20000-1
La gestin de la capacidad debe elaborar y mantener un plan de capacidad.

La gestin de la capacidad debe estar dirigida a las necesidades del negocio y debe
incluir:
a) los requisitos de capacidad, rendimiento y comportamiento, actuales y previstos;
b) la identificacin de plazos, umbrales y costes para las actualizaciones del servicio;
c) la evaluacin de los efectos sobre la capacidad de actualizaciones anticipa-

das del servicio, peticiones de cambio, y nuevas tecnologas y tcnicas;
d) la previsin del impacto de cambios externos, por ejemplo cambios legislativos;
e) los datos y los procesos para poder realizar anlisis predictivos.
UNE-ISO/IEC 20000-2
Se debera generar un plan de capacidad mentar las opciones existentes junto con
donde se documente el rendimiento real su coste para cumplir con los requisitos
de la infraestructura y los requisitos espe- del negocio, as como, las soluciones
rados, con la frecuencia suficiente para recomendadas para conseguir los obje-
tener en cuenta el ritmo de cambios de los tivos de nivel de servicio tal como estn
servicios y de los volmenes de servicio, la definidos en el SLA.
informacin de los informes de gestin del
Debera existir una buena comprensin
cambio y del negocio del cliente.
de la infraestructura tcnica y sus capa-
Dicho informe debera elaborarse al cidades presentes y las que estn pro-
menos anualmente. Se deberan docu- yectadas.
El plan de capacidad debe publicarse anualmente y debe estar alineado con el ciclo
presupuestario. Hay que tener presente que est muy vinculado al plan de inver-
sin y debe estar finalizado antes de que se inicie la elaboracin de los presupuestos
de TI. Se recomienda su actualizacin cada tres meses, para reflejar los cambios en
el negocio o para corregir las previsiones.
En la figura 6.5.7 se muestra la estructura propuesta en ITIL, que divide el plan en
11 apartados.
Los apartados de mayor inters del plan de capacidad son:
Los escenarios del negocio. Que analizan la situacin actual del negocio,
visto desde la demanda hacia TI. Se presenta la situacin actual del negocio
(nmero de departamentos, nmero de usuarios, nmero de edificios, volu-
men de transacciones, etc.). A partir de la estrategia y planes del negocio, se
realiza una previsin sobre la evolucin del negocio, en cuanto a la actividad
prevista, nueva actividad, nuevos edificios, etc. Contemplando siempre las
repercusin que tendrn en los servicios de TI.
El resumen de los servicios. Presenta la situacin actual de los servicios, mos-
trando servicio a servicio un perfil del mismo: carga, trfico, almacenamiento,
Plan de capacidad
Resumen de los servicios: 1. Introduccin.

Perfil de cada uno de 2. Resumen ejecutivo. Escenarios de negocio:
los servicios ofrecidos.
3. Escenarios del negocio: Situacin actual del negocio
Incluyendo ratios de trfico y previsiones de evolucin,
y utilizacin de los recursos. Situacin actual del negocio. en cuanto a la actividad,
Detalles de los nuevos Evolucin prevista. diversificacin, etc.
servicios planeados.
4. Objetivo y alcance.
Crecimiento o reduccin
en la utilizacin de sistemas. 5. Mtodos. Resumen de los recursos:
Informe sobre la retirada Utilizacin de recursos actual.
de sistemas. 6. Hiptesis.
Tendencias de utilizacin
7. Resumen de los servicios: de recursos a corto medio
Situacin actual servicios. y largo plazo desglosadas
por plataformas.
Previsiones servicios.
Previsiones de recursos.
8. Resumen de los recursos: Estudio del impacto de los
nuevos escenarios de negocio
Situacin actual recursos.
descritos en el plan.
Previsiones recursos.
Opciones de mejora: 9. Opciones de mejora de los
Presin de costes:
Posibles opciones de servicios.
mejora de la eficacia Descripcin de los costes
y/o eficiencia (por ejemplo, 10. Previsin de costes. de las opciones de mejora.
consolidacin, virtualizacin, Costes actuales de los servicios.
11. Recomendaciones.
renovacin, etc.). Costes previstos.
Fuente: Libro ITIL Diseo del Servicio publicado por OGC y e.p.
Figura 6.5.7. Estructura del plan de capacidad propuesta en ITIL
procesamiento, etc. Tambin se reflejan las tendencias de crecimiento vegeta-

tivo en la planta actual. El proceso de gestin de la capacidad recibe infor-
macin de los planes de negocio sobre la planificacin de nuevos servicios o
sobre variaciones de uso correspondientes a servicios actuales. Con todo ello,
se realiza una previsin del crecimiento de los servicios a partir del escenario
de negocio previsto. Las previsiones van cuantificadas de tal forma que per-
mitan identificar las necesidades econmicas asociadas: proyectos de inver-
sin, costes de soporte, costes de mantenimiento, etc.
El resumen de los recursos. Realiza un resumen, a modo de inventario,
de los recursos actuales (hardware, software, aplicaciones, comunicaciones,
personal propio, personal ajeno, servicios, etc.). Analiza las tendencias de

variacin a corto y medio plazo. A partir de las previsiones de los servicios se
realizan las previsiones de los recursos necesarios, de nuevo en todos sus
mbitos (hardware, software, aplicaciones, RRHH, servicios externos, etc.).
La previsin de costes. Con una visin ms clara del destino del negocio,
con los servicios que sern necesarios mantener o crear, y con un inventario
de los recursos necesarios, se realiza la previsin de los costes. El objetivo de
este apartado es identificar las necesidades econmicas para sostener y evolu-
cionar los servicios. Esta previsin servir de entrada al plan financiero de
TI y se realizar de forma conjunta con el proceso de gestin financiera de TI.
La base de datos de gestin de la capacidad

(CDB, Capacity Data Base)
Si el plan de capacidad condensa en un documento la situacin actual y las previ-
siones, la base de datos de la capacidad aloja todos los datos y la informacin nece-
saria para el trabajo en el proceso. As, esta base de datos es un instrumento esen-
cial para el proceso. Se utiliza tanto para las actividades tcnicas, como para la
generacin de los informes de gestin y las previsiones.
La base de datos de gestin de la capacidad est formada por la informacin nece-
sitada por los tres subprocesos de gestin de la capacidad y por sus correspondien-
tes actividades. Es un concepto lgico, no tiene porqu ser una nica base de datos
en el sentido estricto del trmino.
En la figura 6.5.8 se muestra una la estructura lgica que se deriva de ITIL para la
CDB.
La CDB se puede estructurar en 5 reas (segn ITIL):
Datos del negocio. Contiene la informacin necesitada por el subproceso
de gestin de la capacidad del negocio para realizar las previsiones sobre el
negocio y su impacto sobre la capacidad necesaria y rendimiento de los ser-
vicios. La informacin ms relevante puede ser: los procesos de negocio a
los que se da soporte por TI; la identificacin de los edificios y emplaza-
mientos en los que se desarrolla el negocio; la distribucin geogrfica y fun-
cional de los usuarios de TI; los volmenes de actividad del negocio y trans-
acciones del negocio y sus variaciones horarias, semanales y estacionales; los
perodos crticos para cada proceso de negocio; etc.
Datos de los servicios. Contiene informacin sobre la capacidad y rendi-
miento de cada uno de los servicios o, por lo menos, de los principales, con
Estructura de la CDB
Datos de Datos utilizacin

Datos del negocio
los servicios recursos
Lmites tcnicos
Procesos de negocio. Por cada servicio: Comunicaciones
externas. Lmite uso CPU.
Edificios y Rendimiento: perfil de
emplazamientos. variacin de la carga: Red interna. Lmite uso
Picos de carga. almacenamiento.
Distribucin Cortafuegos.
geogrfica usuarios. Nmero de Lmite uso red.
transacciones. Servidores frontales.
Distribucin funcional Tiempos de Servidores
usuarios. respuesta. middleware.
Volmenes de Capacidad: consumo Servidores backend. Informacin
actividad del negocio. por usuario o Almacenamiento financiera
Transacciones de transaccin. compartido.
negocio. Costes del servicio. TCO por puesto.
Copias de seguridad
Perfil de la actividad Datos de rendimiento Coste licencias por
del negocio (horario, reas de soporte:
de la infraestructura usuario.
semanal y estacional). Service desk.
que soporta el servicio.
Operacin. Coste transaccin.
Perodos crticos para Concurrencia con otros
Soporte tcnico. Coste por MIP.
cada proceso de servicios sobre las
negocio. plataformas comunes. Coste por GB.
TCO: Coste total de propiedad.

MIP: Millones de instrucciones por segundo.
Figura 6.5.8. Estructuracin ejemplo de la base de datos de capacidad
detalles horarios. Tpicamente se recoge la informacin sobre el rendimiento

(picos de carga, volumen de transacciones, tiempos de respuesta, perfil de
variacin horaria de la carga del servicio, concurrencia en nmero de usua-
rios, etc.); el rendimiento de los componentes de la infraestructura que
soporta el servicio; la coincidencia de la carga entre los servicios sobre las
plataformas comunes (comunicaciones exteriores, red interna, frontales web,
backend de procesamiento, red almacenamiento, backup, etc.); los niveles de
servicio acordados en los SLA; etc.
Los datos de los servicios se obtienen de las herramientas de monitoriza-
cin extremo a extremo de los servicios y de las herramientas de monitori-
zacin especficas de los recursos. Junto a la informacin tcnica se registra
la informacin necesaria para el clculo de los costes y su posterior imputa-
cin por el proceso de gestin financiera.
Datos de utilizacin de los recursos. Informacin resultante de la monito-

rizacin de los recursos. Cada recurso tiene sus propios parmetros de moni-
torizacin y, para cada uno de ellos, se mide la utilizacin de los componentes
y el rendimiento. As, se monitorizarn las aplicaciones; las comunicaciones
exteriores; las comunicaciones entre los edificios; las comunicaciones internas
en los centros de datos; los principales equipos de comunicaciones; el equipa-
miento de seguridad; los servidores frontales web, middleware y backend; el
almacenamiento compartido en red LAN o en red SAN; las copias de seguri-
dad o backup; la carga de trabajo de las unidades de soporte (service desk, ope-
racin, soporte tcnico, pruebas); etc.
Los parmetros tpicos de monitorizacin son el nmero de transacciones, el
tiempo de respuesta de las aplicaciones, el tiempo de respuesta de red, el por-
centaje de utilizacin del procesador, el porcentaje de utilizacin de disco
compartido, utilizacin de memoria en los servidores, duracin del proce-
sado por lotes (batch), etc.
Lmites tcnicos de los recursos. Cada recurso tiene un lmite de capacidad
por encima del cual se satura y se degrada su comportamiento. Es el caso del
porcentaje de utilizacin del procesador, de la capacidad libre de almacena-
miento o de la saturacin de las comunicaciones. Esta informacin se alma-
cena en la CDB. Con estos valores lmite, se definen los umbrales y alarmas
de monitorizacin.
Informacin financiera. Conjunto de datos econmicos que se necesitan
en el proceso para establecer el punto de equilibrio entre la tcnica y el coste,
como se realiza en la definicin de escenarios. La informacin sobre el
entorno econmico en el que moverse y los costes se obtienen de varias
fuentes: los planes financieros del negocio, los presupuestos de TI, los sumi-
nistradores, la base de datos de gestin de la configuracin (CMDB), etc.
Con la informacin de la CDB tambin se obtienen informes, por ejemplo, de los

servicios y recursos; de las excepciones; de las previsiones de capacidad; o del con-
sumo y la facturacin.
Debido a la dificultad de integrar los datos provenientes de las diversas herramien-
tas de monitorizacin, normalmente la base de datos de la capacidad estar for-
mada por varios repositorios de informacin. Resulta esencial el control de la cohe-
rencia de la informacin y de la fiabilidad de los datos, por lo que se debe designar
quin o quines desempearn el rol de administradores y quines accedern en
modo de slo consulta. Como toda base de datos, deber ajustarse a las polticas
de gestin del cambio. Tambin deberan realizarse controles o revisiones internas
peridicas de los contenidos de la CDB.
Hay que determinar claramente la frontera entre la base de datos de la capacidad,

la base de datos de gestin de la configuracin (CMDB) y la informacin finan-
ciera, con el fin de evitar el tratamiento duplicado de informacin.
Gestin de la capacidad del negocio

Como se indica en ITIL, el objetivo principal del subproceso de gestin de la
capacidad del negocio es asegurar que se tienen en cuenta y se comprenden los
requisitos futuros del negocio respecto a los servicios de TI, y que se planifica e
implementa la capacidad suficiente para dar soporte a los servicios, en los plazos
adecuados.
Tambin en ISO/IEC 20000-2 se establece la necesidad de alinear la gestin de la
capacidad con los requerimientos y previsiones de carga del negocio.
UNE-ISO/IEC 20000-2
Los requisitos actuales y esperados del ciones en la carga de trabajo o en el

negocio en relacin al servicio se debe- entorno deberan ser predecible; se
ran conocer en trminos de lo que el deberan recoger y analizar datos actua-
negocio va a necesitar para dar servicio les e histricos de utilizacin de compo-
a sus clientes. nentes y recursos, al nivel adecuado,
con el fin de dar soporte al proceso.
Las previsiones de negocio y las estima-
ciones de carga de trabajo se deberan La gestin de la capacidad debera ser
traducir a requisitos especficos y quedar el punto focal de todas las cuestiones
documentadas. El resultado de las varia- de rendimiento y capacidad.
Del conjunto comn de actividades del proceso, las principales actividades que se
pueden considerar para llevar a cabo el subproceso de gestin de la capacidad del
negocio son las siguientes:
Elaborar el plan de capacidad en el mbito del negocio. Se centra en identificar
la evolucin y las necesidades que tendr el negocio en el perodo cubierto por el
plan. Las necesidades se convertirn en los requisitos que TI debe satisfacer. En esta
actividad se desarrolla el apartado del plan de capacidad relativo a los escenarios del
negocio, que est formado por dos subapartados: la situacin actual del negocio y
la evolucin prevista del negocio. El objetivo principal es predecir la evolucin del
negocio en los aspectos que puedan impactar en TI, como por ejemplo, el volumen
de actividad, la variacin o la diversificacin de actividades, la incorporacin de nue-
vas tecnologas, el impulso a la movilidad, las polticas de teletrabajo, etc.
Idealmente, el plan de capacidad en el mbito del negocio no se realiza aislada-

mente, sino que forma parte de un ejercicio de estrategia ms amplio y global de la
empresa. Parte con la definicin de la estrategia del negocio, de los planes de nego-
cio, del avance de la tecnologa y de la estrategia de TI alineada con el negocio. La
estrategia de TI se ejecuta en base a un porfolio de proyectos (para la evolucin de
los servicios ya existentes o para la construccin de los nuevos), que produce como
resultado el nuevo catlogo de servicios. El plan de capacidad, cuando se realiza en
este mbito ideal, obtiene la informacin de los planes del negocio y la estrategia
de TI para predecir la carga de trabajo que recaer en TI.
El anlisis se realiza por reas o procesos de negocio, mostrando la situacin hist-
rica, la actual y las predicciones. Las predicciones utilizan la informacin de los
datos de negocio de la CDB, por lo que la estructura de las predicciones y de la
CDB debern estar armonizadas.
En la figura 6.5.9 se muestra un ejemplo de los resultados del apartado 3 del plan
de capacidad, relativo a la identificacin de los escenarios del negocio. Se ha
tomado como ejemplo una empresa con una estrategia expansiva territorialmente,
con foco en nuevos productos de mayor valor aadido, la diversificacin de los
canales de venta, la ampliacin de los horarios comerciales y una fuerte expansin
territorial en China y Latinoamrica. En el ejemplo, el escenario del negocio est
alineado con la estructura de datos recopilados en la CDB.
Conviene tener presente que el contacto con el negocio lo lidera el proceso de relacio-
nes con el negocio, al que el presente proceso le asiste en el aspecto de la capacidad.
Si no existiera un ejercicio formalizado de estrategia del negocio y de TI, la defini-
cin del plan de capacidad se deber realizar, igualmente, utilizando el ejercicio pre-
supuestario como palanca.
Ciclo de mejora de la capacidad y rendimiento del negocio. Esta rutina en con-

tinua ejecucin en el proceso, propone mejoras de capacidad o rendimiento moni-
torizando la actividad del negocio a travs de su utilizacin de los servicios (altas
de clientes, transacciones de venta, etc.).
Relacionarse con otros procesos. El subproceso de gestin de la capacidad del
negocio acta a modo de interfaz entre la gestin de la capacidad y el resto de pro-
cesos de TI.
Ayuda en la definicin de los requerimientos del servicio (SLR) en temas
relativos a la capacidad y rendimiento, asistiendo al proceso de gestin de
nivel de servicio.
Participa en el diseo, provisin y modificacin de los servicios en temas
relacionados con la capacidad, rendimiento, adquisiciones, tecnologa, etc.
Plan de capacidad: escenarios del negocio
Escenario Situacin actual del negocio Evolucin prevista

del negocio Ao -2 Ao -1 Ao 0 Ao +1 Ao +2 Ao +3
Estrategia negocio. Expansin europea, crecimiento ventas Expansin intercontinental.

Venta web y logstica: 24x7.
Nuevos productos con mayor valor aadido.
Un 50% del personal con movilidad.
Un 30% del personal en teletrabajo.
Procesos de negocio:
+10% +10% +10% +15% +15% +25%
Ventas.
+10% +10% +10% +10% +5% +5%
Fabricacin.
Edificios y emplazamientos. Consolidacin nacional y presencia UE Expansin LATAM y China
Distribucin geogrfica <tabla de usuarios por ciudades> <nueva tabla de usuarios por ciudades>
usuarios.
Distribucin funcional <tabla de usuarios por departamentos> <tabla de usuarios por departamentos>
usuarios.
Transacciones de negocio. <tabla histrico transacciones> <tabla estimacin transacciones>
Perfil de la actividad Horario de L a V de 9 a 20 h Horario comercial: L a D de 9 a 22 h

del negocio (horario, Horario web: 24x7 incluido CRM
semanal y estacional).
Periodos crticos para cada Ventas: diciembre. Ventas: diciembre, julio y septiembre.
proceso de negocio. Facturacin: ltima semana mes. Facturacin: continua.
Cierre contable: ltima semana mes. Cierre contable: ltima semana mes.
Figura 6.5.9. Ejemplo del apartado de escenarios del negocio

en un plan de capacidad
Verifica los acuerdos de nivel de servicio (SLA), asesorando al gestor de nivel

de servicio y responsabilizndose de los temas de rendimiento en los servi-
cios comprometidos.
Apoya en la negociacin de los SLA, realizando, si es necesario, tcnicas pre-
dictivas del rendimiento.
Controla cambios y entregas, especificando las pruebas de rendimiento que
se deben realizar y comprobando que se realizan.
Modelado de la actividad del negocio. El modelado, en cualquiera de sus formas

simples o complejas, permitir tener una prediccin de la evolucin de la actividad
del negocio. El modelado tambin relaciona diversos procesos de negocio con el

fin de identificar la concurrencia de los picos de demanda. Servir como entrada
para el modelado de los servicios y las previsiones del plan de capacidad. El mode-
lado presenta como resultado una tabla o grfica con la evolucin de la actividad
del negocio en parmetros trasladables a la carga sobre TI.
Realizacin de informes de capacidad y rendimiento del negocio. Se realizan
informes sobre la evolucin del negocio y su reflejo en los principales parmetros
de la actividad del negocio con impacto en TI.
Gestin de la capacidad de los servicios

El subproceso de gestin de la capacidad de los servicios se centra en que los servi-
cios tengan los recursos necesarios para que estn operativos. Teniendo como obje-
tivo el cumplimiento de los requisitos de los servicios (SLR) y los acuerdos de nivel
de servicio (SLA), analiza su utilizacin, su rendimiento, el consumo de recursos,
los patrones de trabajo, las subidas y bajadas de carga.
En ISO/IEC 20000-1 se exige expresamente que se monitorice la capacidad y ren-
dimiento de los servicios.
UNE-ISO/IEC 20000-1
Se deben identificar mtodos, procedimientos y tcnicas para la monitorizacin de

la capacidad del servicio, el ajuste del comportamiento y de las prestaciones del ser-
vicio y la provisin de la adecuada capacidad.
ISO/IEC 20000-2 recomienda la realizacin del dimensionamiento y modelizacin

de los servicios.
UNE-ISO/IEC 20000-2
El proceso debera ofrecer soporte directo dimensionamiento y una modelizacin de

al desarrollo de servicios nuevos y a la servicios.
modificacin de los mismos realizando un
Elaborar el plan de capacidad de los servicios. En esta actividad, el subproceso

elabora el apartado 7, dedicado al resumen de los servicios del plan de capacidad.
Realiza un mapa de la situacin actual de los servicios y sus datos histricos, y el

pronstico de la evolucin de la carga de los servicios.
El plan de capacidad de los servicios hace una previsin de la carga que llegar a los
servicios y las necesidades de infraestructura para soportarla. Las previsiones de
carga de los servicios y la concurrencia de las mismas cobran especial relevancia en
escenarios con servidores consolidados y virtualizados.
Hay que tener en cuenta las situaciones transitorias en las que la carga aumenta,
como por ejemplo, la ejecucin en paralelo de dos servicios que se realizan en la
puesta en marcha de nuevos servicios utilizando elementos comunes, que requieren
que el antiguo y el nuevo estn operativos.
Ciclo de mejora de la capacidad y rendimiento de los servicios. Este conjunto
de 4 actividades tiene su mximo inters en la mejora de los servicios puestos en
produccin. Este ciclo debe actuar de forma continua.
Monitorizacin. Seguimiento automatizado mediante herramientas de la
capacidad y el rendimiento de los servicios. La monitorizacin de los servi-
cios se realiza, principalmente, mediante dos tcnicas complementarias:
Monitorizacin de extremo a extremo mediante puestos de navegacin,
unos puestos situados en la red de usuarios lanzan rtmicamente unas
transacciones o navegacin predeterminadas.
Visin del servicio (service view). La monitorizacin extremo a extremo se
suele complementar con una visin del estado de los servicios obtenida en
base a la monitorizacin uno a uno de todos los componentes que utiliza
el servicio, teniendo en cuenta las redundancias de los mismos.
Anlisis. Estudio de los resultados de la monitorizacin para detectar mejoras.
Ajuste o tunning. Cobra especial importancia en los servicios en fase de
pruebas o recin implantados en produccin. Muchas veces las mejoras
obtenidas por el ajuste son de tal calibre que sin l los servicios no seran
utilizables.
Implementacin. Implantacin de las mejoras identificadas (anlisis o
ajuste), siempre bajo el proceso de gestin del cambio, generando las peti-
ciones de cambio (RFC) correspondientes.
Influir en la utilizacin de los servicios. El objetivo principal es evitar los malos

usos o utilizacin desmedida de los servicios. Dados los recursos limitados de TI, es
necesario establecer los mecanismos para que los usuarios sean conscientes de que la
utilizacin no necesaria de servicios de TI puede tener un impacto negativo en el
negocio debido a la utilizacin de recursos limitados. La influencia en la utilizacin
debe ejecutar las polticas de TI y utiliza como principal medio la imputacin de cos-
tes, pero tambin tiene otras alternativas, como por ejemplo, la comunicacin, la
limitacin del uso (por ejemplo, el tamao de los buzones de correo), etc. La
influencia en el uso se debe realizar con una visin general del negocio, pues muchas
veces infringe graves prejuicios e improductividad en el negocio. Adems, se deben
realizar de forma alineada con la gestin de la estrategia del negocio y apoyadas en
la gestin financiera de TI.
Modelado de los servicios. En el caso de los servicios, el modelado permite definir
varios escenarios de trabajo, con variaciones en la carga que soportarn los servicios
y la cuantificacin de los recursos necesarios para soportarla. El modelado se utiliza
en la etapa de diseo de los servicios. En la mayora de los casos el resultado es una
simple tabla o grfica que representa las diversas cargas junto con los recursos nece-
sarios. En el caso de productos software, el modelado debe partir del realizado por
los propios fabricantes, que se podr complementar con pruebas en el escenario real,
ya que los datos de los fabricantes generalmente se referirn a configuraciones lim-
pias y que no consideran escenarios de comparticin de los recursos.
Dimensionado de aplicaciones. Actividad muy similar al modelado cuyo resul-
tado est orientado a conocer con detalle los recursos que necesitar una aplicacin
para satisfacer los niveles de servicio. Se realiza o al inicio del proyecto o en la fase
de pruebas y tambin se puede hacer en cambios importantes. Si se ha realizado el
modelado previamente, se utilizarn sus resultados. Se realiza principalmente en
aplicaciones crticas. En los desarrollos a medida, slo se podr realizar en la fase
de las pruebas finales antes de entrada en produccin, sometiendo a la aplicacin a
diversas situaciones de carga, utilizando para ello herramientas de generacin auto-
mtica. Por este motivo, es mucho ms importante la identificacin e incorpora-
cin de requisitos de rendimiento durante la fase de establecimiento de requisitos
tcnicos al nuevo desarrollo.
Realizacin de informes de capacidad y rendimiento. Emisin de informes
sobre los servicios, detallando el rendimiento de los servicios, la utilizacin de
recursos (tcnicos y humanos), la capacidad remanente, etc. Los informes se reali-
zarn de forma peridica o bajo peticin, en ambos casos coordinados con el pro-
ceso de gestin de informes.
Gestin de la capacidad de los recursos

Despus de una visin de los servicios y del racimo de recursos que cada uno aglu-
tina, es necesario un tratamiento de la capacidad de los recursos por especialidades:
comunicaciones, servidores, almacenamiento, etc. Esta visin, centrada en un tipo de
recurso, permite tener a punto todos los engranajes que forman un servicio. Tratar
los recursos por especialidades permite que un conjunto de especialistas gestione un

pool grande de recursos similares.
El subproceso de gestin de la capacidad de los recursos se centra en la capacidad
y rendimiento de estos elementos de la infraestructura. Procura un uso ptimo de
los recursos hardware y software (si bien en ITIL v2 las personas no son considera-
das como recursos salvo que sean sustitutivos de un componente, en ITIL v3 s
son considerados como recursos, ya que, al fin y al cabo, representan un aspecto
de capacidad fundamental en la prestacin de numerosos, si no todos, los servi-
cios de TI).
Elaborar el plan de capacidad de los recursos. El subproceso participa en la ela-
boracin del apartado 8 Resumen de los recursos del plan de capacidad. El obje-
tivo es detallar los recursos actuales y estimar las necesidades para los prximos
perodos. Con estos pronsticos se elaboran las necesidades presupuestarias que
proporcionarn una parte de los fondos que necesita TI.
Ciclo de mejora de la capacidad y rendimiento. El anlisis de los elementos per-
mite detectar oportunidades de mejora tcnica en la configuracin de cada ele-
mento. Unos componentes bien ajustados sern capaces de proporcionar un rendi-
miento mximo en los picos de carga. La monitorizacin de los componentes es
fundamental para esta actividad.
Realizacin de informes de capacidad y rendimiento. Son informes tcnicos,
que analiza un pool de recursos.
Mtricas del proceso

Las mtricas de este proceso se consideran internas a TI, pues al contrario que en
el caso de la disponibilidad, los clientes no estn nada interesados en conocer los
ratios de ocupacin, los indicadores de saturacin o el grado de precisin de
los planes de capacidad. La medicin de la gestin de la capacidad se centra, por
una parte, en el seguimiento del uso de la capacidad en los servicios (ratios de utili-
zacin de procesador y de almacenamiento), y por otra, en informar sobre el desem-
peo del propio proceso (desviacin en las predicciones).
Las principales mtricas del proceso son las siguientes:
Porcentaje de uso de CPU, que da una idea de las holguras que existen en la
capacidad de proceso. Tambin se suele medir el consumo de memoria.
Porcentaje de disco asignado sobre el total de la capacidad de almacenamiento
en disco instalada.
Porcentaje de servidores saturados.

Porcentaje de elementos de red saturados.
Porcentaje de presupuesto gastado en compras urgentes sobre el presupuesto
total, que indica el grado de precipitacin debido a nuevos temas no previs-
tos, precipitacin en las ampliaciones, etc.
Porcentaje de incidencias provocadas por falta de capacidad o de rendi-
miento, que muestra claramente si el proceso es eficaz o no. De forma simi-
lar, se puede medir el porcentaje de no disponibilidad o los incumplimientos
de SLA provocados por la falta de capacidad.
Porcentaje de desviacin previsto en el plan de capacidad frente al real utili-
zado, que indica la precisin de las estimaciones realizadas.
Desviaciones del plan medidas en trminos presupuestarios.
Porcentaje de servicios o de componentes hardware monitorizados.
De cara a medir la actividad del proceso se pueden medir el nmero de reco-
mendaciones hechas por la gestin de la capacidad o el nmero de cambios
propuestos por la gestin de la capacidad y que han dado lugar a cambios.
El coste que supone tener sobrecapacidad instalada (y no utilizada), especial-
mente til en organizacin en outsourcing o en licenciamiento de sofware que
se pague en base a la capacidad instalada.
La capacidad de trabajo de la organizacin, que se puede medir como la
capacidad de cumplimiento de los plazos comprometidos en incidencias,
peticiones, cambios y trabajos planificados (jobs).
Porcentaje de procesos de negocio modelizados por la gestin de la capa-
cidad.
En la figura 6.5.10 se muestran los indicadores ms relevantes para este proceso

recomendadas por itSMF Espaa.
Roles participantes en la gestin de la capacidad

La gestin de la capacidad tiene una parte inicial de actividad orientada a la implan-
tacin del proceso, a la definicin de la estructura del plan de capacidad, a la reali-
zacin del primer plan, a la definicin de la forma de modelizar el negocio, a la
implantacin de las herramientas de monitorizacin (o establecimiento de los
umbrales y alarmas), etc. Esta parte de implantacin, no es frecuente realizarla en
de itSMF Espaa
base a un proyecto llave en mano, como puede ocurrir con la continuidad, sino que
se suele realizar por el propio equipo que posteriormente llevar el proceso.
Una vez puesta en marcha, la gestin de la capacidad requiere perfiles con una pro-
funda especializacin tcnica en las tecnologas que se utilizan (se realiza en tuning
de aplicaciones, se resuelven problemas de rendimiento, etc.) y tambin es necesario
conocimiento del negocio de cara a predecir el comportamiento del mismo.
Los roles involucrados en la gestin de la capacidad se estructuran en roles propios
del proceso y roles ajenos al proceso.
Gestor de la capacidad. Es el responsable de la implantacin del proceso defi-
nido por el propietario del modelo de gestin. Tambin supervisa y coordina
la ejecucin y el control del proceso, se encarga de proponer mejoras al pro-
ceso, realiza el plan de capacidad, tiene la visin del negocio, interacta con
el resto de procesos, asegura que se cumplen los SLA en cuanto a la capaci-
dad y rendimiento, vela por el correcto tratamiento de los datos que utiliza
el proceso y supervisa la implementacin de la monitorizacin.
Administrador y soporte del proceso de capacidad. Asiste al gestor de la
capacidad en lo que necesite.
Especialistas en monitorizacin. Implementan y gestionan la plataforma de

monitorizacin. Con frecuencia este rol est desempeado por un grupo tc-
nico especializado que gestiona toda la monitorizacin.
Especialistas tecnolgicos. Bajo este rol se incluye todo el personal tcnico
necesario para gestionar las distintas tecnologas, como por ejemplo las
redes, los sistemas, las bases de datos, el middleware, las aplicaciones, la segu-
ridad, el backup, el procesado batch, etc.
Administrador de la base de datos de capacidad (CDB). Tcnico responsable
de mantener las herramientas en las que se almacenan los datos e informa-
cin de la capacidad.

El gestor de las relaciones con el negocio, pues actuar de interlocutor de
cara a las previsiones del negocio, la toma de requisitos y el acuerdo de los
SLA. Tambin participa en la revisin de informes de seguimiento con el
negocio.
El gestor de nivel del servicio, transmite los requisitos de los servicios y los
SLA en relacin a capacidad y rendimiento.
El gestor de disponibilidad, por la fuerte relacin tcnica entre disponibili-
dad, tiempo de respuesta, capacidad y rendimiento.
El gestor del incidente y el gestor del problema, pues proporcionan informa-
cin de las incidencias cuyo origen est en la capacidad o rendimiento.
El gestor del cambio o gestor de la entrega, por la necesidad de que controle
la realizacin de las pruebas sobre el consumo de capacidad y realice el tuning
de las aplicaciones antes de su paso a produccin.
El gestor financiero de TI aporta los costes unitarios y recibe las estimacio-
nes presupuestarias del plan de capacidad, dado que el plan de capacidad est
muy relacionado con los presupuestos.
El propietario del modelo de gestin SGSTI, que acta como propietario del
proceso (process owner), define las actividades del proceso y se encarga de la
mejora continua del mismo.
Los roles de mayor relevancia que participan en el proceso de gestin de la capaci-

dad de representan la figura 6.5.11.
Roles del proceso
Responsable de la
gestin del servicio
Administrador y
Gestor de soporte del proceso
la capacidad de capacidad
Gestores de otros procesos:

relaciones, financiero y entrega
SGSTI
Especialista
tecnolgico
Especialista en Administrador
monitorizacin de la CDB
Propietario del
modelo (SGSTI)
Figura 6.5.11. Roles del proceso de gestin de la capacidad
Resumen
Si este proceso cay alguna vez en el olvido, vuelve a tener plena vigencia debido a
las nuevas tendencias en TI: los ajustes en los costes, la consolidacin y la virtuali-
zacin de las infraestructuras de procesamiento o la reduccin del consumo elc-
trico. La necesidad de compartir plataformas requiere gestionar y controlar los
recursos que consume un servicio para evitar que interfiera en el rendimiento de
los otros.
La gestin de la capacidad es un proceso que comprende un amplio abanico de
especialidades diferentes, desde el entendimiento de la evolucin del negocio, hasta
las funciones ms tcnicas de ajuste de las aplicaciones y de las plataformas para
conseguir un rendimiento ptimo.
El proceso se revitaliza con la realizacin del plan de capacidad y sus revisiones

peridicas, lo que le obliga a estar al tanto de las tendencias del negocio y sus varia-
ciones en la utilizacin de los servicios, estar al da de la evolucin tecnolgica y de
la situacin econmica de la empresa.
La gestin de la capacidad se estructura en tres subprocesos o reas de actividad:
La gestin de la capacidad del negocio: que traslada las necesidades y planes
del negocio en requisitos para los servicios y las infraestructuras, con el fin
de asegurar que los futuros requerimientos del negocio se puedan cumplir.
La gestin de la capacidad de los servicios: est centrado en la gestin, control y
prediccin del rendimiento extremo a extremo de los servicios para el cumpli-
miento de los requisitos del servicio y los acuerdos pactados de nivel de servicio.
La gestin de la capacidad de los recursos: cuyo objetivo es la gestin y el
control de los recursos de TI, y especialmente de los ms esenciales para que
presten el mejor rendimiento posible.
En estas tres reas se realizan el siguiente conjunto de actividades.

La elaboracin del plan de capacidad, que sincroniza a toda la organizacin
en las previsiones de recursos necesarios para satisfacer la evolucin de las
demandas del negocio.
El ciclo de mejora de la capacidad y rendimiento garantiza que se estn revi-
sando estos parmetros de forma continua. Se inicia en la monitorizacin,
sigue con el anlisis de los datos, para identificar las necesidades de ajuste o
tuning de aplicaciones y de infraestructuras, para realizar posteriormente la
implementacin de las mejoras a travs del proceso de cambios.
Influir en la utilizacin de los servicios y consumo de recursos es otra de las
facetas que desarrolla el proceso. Despliega las condiciones (comunicacin,
facturacin, etc.) para que el uso transcurra por la senda prevista.
Se realiza el modelado de los servicios, con el fin de tener una previsin de
su comportamiento en situaciones de carga pico.
El dimensionado de aplicaciones en las fases tempranas de su concepcin,
permitir anticipar las necesidades de infraestructuras.
Realiza los informes de capacidad y rendimiento de los servicios y los recursos.
Crea y administra la base de datos de capacidad (CDB), que centraliza la
informacin de monitorizacin de la capacidad y del rendimiento.
Como en el resto de los procesos, se supervisa a s mismo y se mejora.
El proceso de gestin de la capacidad es el proceso tacao por excelencia, velando

por la optimizacin y evitando derroches. Por ello, ao tras ao, se ir viendo cmo
la gestin de la capacidad va cobrando mayor relevancia en un mundo que requiere
ajustar al mximo el consumo de recursos materiales y energticos.
Beneficios
La gestin de la capacidad es un proceso de previsin que permite anticipar las
necesidades y gestionar la dotacin de fondos para conseguirlos. Por tanto, tiene
una vertiente importante en la planificacin econmica.
Tambin lucha contra el despilfarro en la compra o utilizacin de los recursos, ajus-
tando la demanda a las infraestructuras necesarias.
En su faceta tcnica pura, se centra en conseguir un rendimiento ptimo de los ser-
vicios, realizando el ajuste fino de las aplicaciones y de las plataformas.
Los principales beneficios esperados con la implantacin de este proceso son los
siguientes:
Se conocen anticipadamente las necesidades de recursos.
Se pueden agrupar y racionalizar las compras.
El dilogo con el negocio permite identificar los perfiles de utilizacin de los
servicios y reconducir el consumo que se hace de ellos por parte de los usua-
rios.
Se controlan los gastos imprevistos por nuevos proyecto o por necesidades
de compras urgentes.
La optimizacin de recursos, la revisin de la utilizacin de licencias, la ges-
tin de la obsolescencia del parque de equipamiento y la retirada de recursos
no utilizados, pueden generar importantes ahorros.
La mejora del rendimiento y el tunning es una garanta para la estabilidad de
los servicios y la utilizacin ptima de los recursos.
La monitorizacin permitir seguir el consumo de capacidad (por ejemplo,
el consumo energtico) y el rendimiento.
El ciclo de mejora de la capacidad asegura que las instalaciones estn siendo
revisadas y mejoradas continuamente.
Por tanto, el proceso de gestin de la capacidad aporta prediccin en las necesida-

des, con los beneficios que trae consigo la anticipacin. Es un proceso de ajuste y
correccin de los excesos, tanto en el uso como en la dotacin de equipamiento.

Adems, es un proceso tcnico en el que se afina el funcionamiento de la maquina-
ria de TI. Aportar un mejor control de los costes en las plataformas y una mayor
estabilidad en las mismas.
Cul es el contenido del plan de capacidad de su organizacin?
Cmo se realizan las pruebas de rendimiento de las aplicaciones?
Cite las dos mejores prcticas de su organizacin relativas al proceso
de capacidad.
1
6.6. Gestin de la seguridad de la informacin 403
6.6. Gestin de la seguridad de la informacin
Figura 6.6.1. Actividades del proceso de gestin de la seguridad de la informacin
En los ltimos aos la seguridad de las tecnologas de la informacin se ha conver-

tido en una de las preocupaciones ms importantes de las empresas. La informacin
es quiz uno de los activos ms crticos, sin informacin o con una informacin alte-
rada, las compaas no pueden desarrollar su actividad. Pero an conservando la
informacin, si sta es accedida y cae en manos de la competencia, o es divulgada en
el mercado, el dao puede ser an mayor.
La facilidad de acceso a cualquier parte del mundo mediante la gran red Internet,
pone al alcance de la mano cualquier ordenador que est conectado a ella. Los ata-
ques, los virus, los gusanos y los troyanos son cada vez ms frecuentes. La adecuada
gestin de la seguridad de la informacin se ha convertido por obligacin en uno
de los objetivos estratgicos de toda compaa.
Tradicionalmente, la gestin de la seguridad ha sido una actividad aislada del da a
da en TI. Slo se le daba importancia en situaciones de crisis, era considerada
inconscientemente como una rmora. Con la llegada de las Normas ISO/IEC
20000, la gestin de la seguridad asciende de categora y se trata de igual a igual
con los procesos ms importantes en la gestin de TI. Sale del rincn en el que
estaba postergada para ser considerada parte de los procesos de provisin, que son
proactivos y alinean los servicios con los requisitos del negocio. De hecho, implan-
tar la gestin de la seguridad y sus actividades tiene bastante similitud con la
importante gestin de la disponibilidad. Ambas tienen una fase previa de implanta-
cin, se articulan en torno a un plan, participan en el diseo de los servicios, tienen
actividades proactivas, analizan los riesgos, dan su apoyo en la resolucin de los
incidentes y problemas que impactan en la disponibilidad o en la seguridad, tienen
facetas reactivas, generan informes, proponen mejoras, supervisan el funciona-
miento en su mbito, etc. Teniendo en mente estas similitudes, es ms sencillo
entender las grandes directrices de la gestin de la seguridad (vase la figura 6.6.1).
La seguridad en TI ha ido evolucionando desde la resolucin de crisis, a golpe de
inversin en tecnologa de proteccin, hacia el concepto de gestin, que combina
tecnologa con medidas organizativas, con procesos y con procedimientos de segu-
ridad. La evolucin hacia un modelo de gestin de la seguridad de la informacin
viene impulsada por la Norma UNE-ISO/IEC 27001, que resalta la necesidad de
disponer de un sistema de gestin de la seguridad y la Norma UNE-ISO/IEC
17799 que detalla cada uno de los controles necesarios para garantizar la seguri-
dad.
La empresa actual debe entender la gestin de la seguridad como un proceso, que
garantice y salvaguarde su informacin, pero que no suponga una barrera para la
organizacin a la hora de desarrollar su actividad.
La gestin de seguridad de la informacin es el proceso con responsabilidad sobre
los niveles de seguridad de los activos utilizados para la prestacin de los servicios
de TI a los clientes. En la figura 6.6.2 se presenta una introduccin al proceso de
gestin de seguridad de la informacin.
Las Normas ISO/IEC 20000 establecen para este proceso un objetivo muy claro:
gestionar la seguridad de la informacin de manera eficaz para todas las activida-
des del servicio. El proceso de gestin de seguridad de la informacin debe traba-
jar para asegurar que los activos utilizados en la prestacin de los servicios se
encuentren en unos niveles de exposicin al riesgo aceptables para el negocio.
Por otra parte, en ITIL v3 se enuncia el objetivo con un enfoque algo diferente: ali-
near la seguridad de TI con la seguridad del negocio y garantizar que la seguridad
de la informacin es gestionada de forma efectiva en todas las actividades de la ges-
tin del servicio. Es muy interesante el matiz aadido por la versin 3, poniendo
nfasis en que la seguridad en TI est integrada con la seguridad general de la
empresa. Tambin destaca que la seguridad no es una isla dentro del rea de TI, sino
que enfoca la actividad del proceso principalmente a velar porque los diversos gru-
pos especialistas de TI desarrollen entre sus actividades los aspectos de la seguridad.
As, este proceso, al igual que ocurriera con la gestin de la disponibilidad, marca las

seguridad de la informacin Reduce el riesgo de virus, troyanos,
gusanos, etc.
Mejor custodia de los activos de
Definicin:
informacin de la empresa.
Proceso responsable de gestionar la Aumenta la fiabilidad de los servicios,
seguridad de la informacin equilibrando reduciendo la probabilidad de
las medidas con los costes que supone incidentes de seguridad.
implementarlas.
Desarrolla mtodos ms eficientes
en la resolucin de incidentes de
seguridad.
Objetivo:
Una gestin integral que proporcione
Proceso que debe garantizar el nivel de una visin conjunta del impacto de la
seguridad requerido sobre los activos seguridad en el negocio.
utilizados por la organizacin para la Mejora continua del nivel de riesgo
prestacin de los servicios de TI. de los servicios prestados a clientes.
Figura 6.6.2. Introduccin al proceso de gestin de seguridad de la informacin
pautas, define las medidas de salvaguardia y vela por que se cumplan, ms que des-
arrollar las medidas por si mismo.
Las principales ventajas que aporta el proceso son:
Mejora la seguridad de los sistemas de informacin en todos sus aspectos.
Reduce el riesgo de contagio de virus, de entrada de los silenciosos troyanos,
de expansin de gusanos que saturan las comunicaciones, etc.
Mejora el control y la custodia de los activos de informacin de la empresa,
implantando medidas adecuadas a la criticidad de la informacin o de los sis-
temas.
La mayor proteccin ante las amenazas permite aumentar la fiabilidad de los
servicios, reduciendo la probabilidad de ocurrencia de incidentes de seguridad.
Define y prepara mtodos eficientes en la resolucin de incidentes de segu-
ridad.
Implementa una gestin integral de la seguridad, que proporciona una
visin conjunta del impacto de la seguridad en el negocio.
Realiza la mejora continua de la seguridad reduciendo nivel de riesgo de los
servicios prestados a los clientes.
De forma general, la seguridad informtica se plantea desde dos mbitos o discipli-

nas: la seguridad fsica y la seguridad lgica.
La seguridad fsica se centra en la interposicin de controles y barreras mec-
nicas o materiales para el acceso, y en la deteccin de intrusiones a recintos,
infraestructuras o localizaciones. Entre las medidas habituales de seguridad
fsica se encuentran los permetros de seguridad fsica para proteger las reas
en las que ubican los sistemas de informacin; los controles fsicos de
entrada-salida; y las medidas de proteccin frente a incendios, inundaciones,
terremotos, explosiones, disturbios, manifestaciones, atentados o cualquier
otra forma de desastre natural o provocado. La seguridad fsica se puede
solapar en algunos riesgos con la gestin de la continuidad, por lo que es
conveniente delimitar claramente las fronteras entre ambas.
La seguridad lgica se centra en la proteccin de la informacin en su pro-
pio medio. Algunos ejemplos de medidas de seguridad lgica son el control
del acceso de los usuarios a los sistemas de informacin; los mecanismos de
control del acceso a la informacin y a los sistemas; los cortafuegos y las pro-
tecciones en la conexin a las redes de telecomunicaciones; etc.
Cuando se trata de definir el alcance de la seguridad es ya un clsico considerar que se

deben cubrir tres aspectos: la confidencialidad, la integridad y la disponibilidad de la
informacin. En la figura 6.6.3 se muestran los principios bsicos de este proceso.

de gestin de la seguridad de la informacin
La confidencialidad asegura que slo acceden a la informacin aquellas personas

o sistemas que estn autorizados. La confidencialidad permite retener el conoci-
miento y los datos fundamentales para el negocio. Permite asegurar que slo los
usuarios autorizados tienen acceso cuando lo requieran a la informacin y a sus
activos asociados. Cuando falta confidencialidad se puede producir la divulgacin
de informacin esencial de la empresa o de las personas.
La disponibilidad de la informacin vela por que est siempre disponible en el
momento y lugar necesarios, para ser utilizada por las personas autorizadas. Est
propiedad bsica de la seguridad, se provee a travs del proceso de gestin de la
disponibilidad.
La integridad permite garantizar la exactitud y completitud de la informacin, as
como, los mtodos de su procesado. Esta caracterstica consigue que el contenido
de la informacin permanezca inalterado, a menos que sea modificada por personal
autorizado.
Existen otras propiedades asociadas a la seguridad que aportan confianza en la
autenticidad y el no repudio de las transacciones o intercambios de informacin.
Tambin es importante la auditabilidad, caracterstica que permite verificar las
acciones que se han llevando a cabo, quin las ha realizado y en qu momento de
tiempo se han realizado.
El proceso de gestin de la seguridad de la informacin tambin requiere que se
traten los incidentes de seguridad. En este caso, se realizar por el proceso de ges-
tin del incidente, es decir, que todo evento o serie de eventos de seguridad de la
informacin se deben gestionar siguiendo el mismo proceso que cualquier otro
incidente. En el momento en que existe un incidente abierto, su resolucin corre
siempre a cargo del nico proceso encargado de resolverlo, la gestin del incidente,
mientras que la gestin de la seguridad habr preparado los procedimientos de
actuacin, dejando que transcurra el flujo del incidente. Igualmente ocurre en la
gestin de la capacidad o de la disponibilidad en sus respectivos tipos de inciden-
tes, lo cual no exime de que exista un grupo de especialistas en seguridad que
acten como segunda opcin, pero trabajando para el proceso de incidentes.
Los conceptos y componentes principales que se utilizan en el proceso son el anli-
sis de riesgos, los activos de informacin, los riesgos de seguridad, la declaracin
de los riesgos, los controles de seguridad o medidas de salvaguardia, el plan de ges-
tin de riesgos, el comit de seguridad y los registros que detallan los eventos e
incidentes de seguridad. En la figura 6.6.4 se muestran los principales elementos
que intervienen el proceso de gestin de seguridad de la informacin.
Adicionalmente a los principios bsicos de la seguridad (confidencialidad, disponi-
bilidad, integridad, autenticidad, no repudio, auditabilidad y gestin de incidentes
Evaluacin Declaracin Tratamiento Supervisin
Activo Riesgos de
seguridad
Objetivos
de control Monitorizacin
de la seguridad
Amenaza
de seguridad Declaracin de Controles de
Eventos de
riesgos (SoA) seguridad seguridad
Vulnerabilidad Plan de
Probabilidad tratamiento de
Incidentes
riesgos de
Impacto seguridad de seguridad
Nivel de riesgo
Registros de
seguridad
d
Informes
seguridad
de
da
eg uri Comit de
es
ad seguridad
tic
Pol
Figura 6.6.4. Componentes del proceso de gestin de seguridad
de seguridad), hay que tener en cuenta los conceptos principales que se utilizan en
el proceso de gestin de seguridad de la informacin:
Activo de sistemas de informacin o elemento de configuracin. Dato, infor-
macin, programa, equipo, persona o cualquier otro recurso de los sistemas de
informacin utilizado en la prestacin de los servicios. En el mbito de seguridad
se denomina activo, mientras que en el proceso de gestin de la configuracin y
en el resto de procesos se utiliza el trmino elemento de configuracin. As,
activo y elemento de configuracin son conceptos similares.
Amenaza. Suceso de ocurrencia probable que puede desencadenar un incidente en la
organizacin, produciendo daos o prdidas materiales o inmateriales en sus activos.
Anlisis de riesgos de seguridad. Actividad que proporciona informacin relativa
a las amenazas de seguridad que pueden afectar a los servicios, as como, la probabi-
lidad de que ocurran. En TI se suele realizar un anlisis de riesgos especfico en cada
uno de los tres procesos (incidentes, continuidad y seguridad), pero con objetivos
distintos: para asegurar la disponibilidad de los sistemas (foco en fallos cotidianos),

para garantizar la continuidad (foco en contingencias severas) o la seguridad (foco
en la malicia humana).
Comit de seguridad. Organismo interno asesor del responsable de seguridad que
centraliza la informacin y la toma de decisiones en los aspectos de seguridad.
Control de seguridad o medida de salvaguardia. Accin, procedimiento,
medida o dispositivo (fsico o lgico) que reduce el riesgo. La gestin de la seguri-
dad se articula en torno a la definicin de unos objetivos de control y a la implanta-
cin de los controles necesarios para conseguir los objetivos.
Declaracin de riesgos de seguridad. Documento formal que relaciona los ries-
gos con los niveles de exposicin a los que est sometida una organizacin.
Declaracin de aplicabilidad (SoA, Statement of Applicability). Declaracin de
riesgos especfica de ISO/IEC 27001. Documento que detalla los objetivos de con-
trol y los controles de seguridad que se utilizarn (seleccionados de los propuestos
en la Norma ISO/IEC 27001), tambin se deben justificar cules no se consideran
que sean prioritarios o necesarios para el proveedor de servicios de TI. Se basa en
los resultados de la evaluacin de riesgos y del tratamiento de riesgos, justificando
las inclusiones y exclusiones. La declaracin de aplicabilidad es un requisito formal
de ISO/IEC 27001 y sirve de punto de entrada para planificar el tratamiento de los
riesgos.
Evento de seguridad de la informacin. Suceso identificado en un activo o ele-
mento de configuracin, que indica una posible brecha en la poltica de seguridad
de la informacin, fallo de las salvaguardias o una situacin que podra ser relevante
para la seguridad.
Impacto. Consecuencia sobre los servicios y el negocio en caso de materializarse
una amenaza.
Incidente de seguridad de la informacin. Evento o serie de eventos de seguri-
dad de la informacin que impacta en los servicios de TI.
Informe de seguridad. Informe centrado especficamente en la seguridad, expli-
cando los hechos acaecidos en el perodo. Tambin puede haber un informe espec-
fico que detalle lo ocurrido en un incidente severo de seguridad.
Monitorizacin de la seguridad. Sistemas informticos que supervisan y miden
los controles de seguridad, y registran los eventos de seguridad.
Nivel de riesgo. Grado de exposicin a un riesgo.
Objetivo de control. Situacin o aspecto que se quiere alcanzar en el mbito de la
seguridad. La seguridad se implanta definiendo los objetivos de control necesarios
y, para cada uno de estos, se establecen los controles que harn posible alcanzar
el objetivo fijado. Las Normas ISO/IEC 27001 e ISO/IEC 17799 establecen cerca
de 40 posibles objetivos de control de la seguridad de la informacin.
Registro de seguridad. Informacin relativa a un aspecto o un evento de seguri-
dad que se almacena de una forma controlada. Los registros son un instrumento
esencial en las normas para desarrollar el principio de auditabilidad.
Plan de tratamiento de riesgos (RTP, Risk Treatment Plan). Documento base
que articula la implantacin de la gestin de los riesgos.
Plan Director de Seguridad de la Informacin (PDSI). Nombre un poco rimbom-
bante que se suele dar al documento que unifica todas las acciones a varios aos para
transformar la seguridad. Tiene categora de plan estratgico. Normalmente contiene
el plan de implantacin del proceso o del SGSI, y el plan de tratamiento de riesgos.
Probabilidad. Frecuencia con la que puede ocurrir un suceso, o la relacin entre el
nmero de casos favorables y el nmero de casos totales.
Riesgo. Es la posibilidad de que se materialice una amenaza y sta cause un
impacto en un determinado servicio o activo. El riesgo es funcin de la magnitud
de la amenaza, de la vulnerabilidad al mismo de los servicios y de la probabilidad
de que ocurra el suceso. En torno al riesgo aparecen un conjunto de actividades:
Aceptacin del riesgo. Decisin de aceptar un riesgo.
Anlisis del riesgo. Sistemtica de uso de informacin para identificar fuen-
tes y estimacin del riesgo.
Valoracin del riesgo. Todo el proceso de anlisis y evaluacin del riesgo.
Evaluacin del riesgo. Proceso de comparar un riesgo estimado con el
riesgo dado por los criterios para determinar la importancia del riesgo.
Tratamiento o gestin del riesgo. Proceso de seleccin e implantacin de
las medidas para cambiar el riesgo.
Sistema de Gestin de la Seguridad de la Informacin (SGSI, o en ingls

ISMS, Information Security Management System). Es un sistema de gestin o
modelo formalizado con el que se gestiona la seguridad de la informacin. La
Norma ISO/IEC 27001 define este sistema de gestin.
Conviene que el SGSI est integrado en el SGSTI y ambos en el sistema de gestin
de la calidad general de la empresa (basado en ISO 9001).
Sistema de Gestin del Servicio de TI (SGSTI). Es un sistema de gestin o
modelo formalizado con el que se gestionan los servicios de las TI. Las Normas
ISO/IEC 20000 definen este sistema de gestin y se explica en el captulo 3 de

este libro. Ambos sistemas (SGSTI o SGSI) se pueden implementar de forma
independiente, pero lo recomendable es que se implementen de forma integrada
entre s, e integrados en el sistema de gestin de la calidad general de la empresa
(ISO 9001).
Vulnerabilidad. Debilidad o escaso blindaje de un activo para resistir a una ame-
naza.

La seguridad es un proceso poco conocido para los iniciados en la gestin de los
servicios. Muchas veces se implementa por grupos de personas diferentes, unos
especializados en ITIL y los otros en seguridad. El proceso parte de unas polticas
dictadas por la direccin, se planifica su implementacin, se realiza un anlisis de
riesgos y se determinan unas soluciones o medidas de proteccin a implementar. A
partir de este punto, se realiza la supervisin, se prepara la actuacin ante inciden-
tes de seguridad, se registran estos y se presentan informes. Como en el resto de
procesos, debe tener una actividad de mejora de si mismo.
La Norma ISO/IEC 27001 y la Norma ISO/IEC 17799 asociada son la mejor
referencia para cumplir con creces los requisitos de ISO/IEC 20000. As se reco-
noce de forma expresa en la parte 2 de la norma. Por ello, estas dos normas se utili-
zan en este libro como base para estructurar el proceso.
UNE-ISO/IEC 20000-2
Generalidades
El personal del proveedor del servicio
La seguridad de la informacin es el con roles de especialista en seguridad
resultado de un sistema de polticas y de la informacin debera estar familia-
procedimientos diseados para identifi- rizado con la norma ISO/IEC 17799,
car, controlar y proteger la informacin y Tecnologas de la informacin. Tcni-
cualquier equipamiento empleado junto cas de seguridad. Cdigo de prcticas
con el almacenamiento, transmisin y para la gestin de la seguridad de la
procesamiento de dicha informacin. informacin.
La gestin de la seguridad se centra en proteger los activos de informacin. En el

ncleo central del proceso se realiza una evaluacin de riesgos, para seleccionar las
medidas necesarias de proteccin (controles) e implementarlas de forma organizada
en un plan de tratamiento de riesgos. Pero hay que entender que la seguridad no se

resuelve slo a golpe de tecnologa. Por ello, los controles son de todo tipo: directri-
ces, organizativos, procedimentales, tecnolgicos, culturales, etc. Adems, una vez
implantados, hay que supervisar el correcto funcionamiento de los mismos,
entrando en el crculo de mejora continua.
Las interacciones y funcionalidades de la gestin de seguridad de la informacin se
presentan en la figura 6.6.5.
Desencadenantes 3 Creacin del proceso o SGSI: Salidas principales:

del proceso: Alcance, poltica y enfoque. Poltica de
Poltica de seguridad Proyecto implantacin. seguridad TI.
del negocio. Evaluacin de riesgos.
Evaluacin de riesgos.
Requisitos de seguridad Plan de tratamiento de
del negocio. Seleccin de objetivos de
control y sus controles. riesgos de seguridad.
Acuerdos seguridad en Declaracin de riesgos.
SLA. Declaracin de riesgos.
Objetivos de control.
Incidente severo de 3 Implementacin y operacin:
seguridad. Controles de seguridad.
Plan de tratamiento de riesgos.
Fecha de pruebas. Registros de seguridad.
Implementar controles.
Fecha revisin del plan. Auditoras de
Procedimiento incidentes
seguridad.
Fecha de auditoras. seguridad.
Informes de seguridad.
Pruebas iniciales.
Gestionar recursos Salidas secundarias:
Anlisis de riesgos y plan seguridad.
de continuidad de TI. Requisitos de seguridad.
Informacin de 3 Supervisin y revisin: Plan proyecto seguridad.
incidentes y problemas. Formacin y comunicacin. Procedimientos de
Datos de monitorizacin. Revisin y auditora. deteccin y respuesta a
incidentes de seguridad.
Cambios (RFC). Pruebas de los controles.
Activos clasificados.
Activos y CMDB. Supervisar, monitorizar y
registrar. Personal concienciado.
Entorno legal.
Investigar incidentes. Informes resultados
Presupuestos asignados.
pruebas de seguridad.
Actualizar los planes.
Gestionar incidentes severos
de seguridad.
3 Mantenimiento y mejora
Fuente: e.p. a partir de UNE-ISO/IEC 27001-1.
Figura 6.6.5. Entradas, actividades y salidas

de gestin de seguridad de la informacin
Las entradas desencadenantes del proceso son la definicin de una poltica de segu-
ridad en el negocio, que origina el inicio de la creacin del proceso; los requisitos
de seguridad del negocio concretados en los acuerdos de nivel de servicio; la ocu-
rrencia de un incidente severo de seguridad, pues este proceso colabora con la ges-
tin del incidente en la gestin de la crisis; y la llegada de un conjunto de fechas
especficas (de pruebas de seguridad, de revisin del plan de tratamiento de riesgos
o las fechas de las revisiones o auditoras).
El proceso utiliza unas entradas de soporte de otras fuentes necesarias para llevar a
cabo sus cometidos. Entre dichas entradas destacan el anlisis de riesgos realizado en
el plan de continuidad de TI, pues en caso de que se haya realizado aportar un enten-
dimiento mejor del negocio y de los riesgos; la informacin de incidentes y de los pro-
blemas ocurridos relacionados con la seguridad; los datos de la monitorizacin de los
sistemas y de la seguridad; los cambios en curso para supervisar que se evale su segu-
ridad; la informacin de los activos y de la CMDB; el entorno legal y regulatorio que
influye en la seguridad; los presupuestos asignados a la seguridad; etc.
Las salidas principales del proceso son la poltica de la seguridad definida; los resul-
tados de la evaluacin de riesgos de seguridad; el plan de tratamiento de los riesgos;
la declaracin de riesgos; los objetivos de control y los controles seleccionados; los
resultados de las auditoras de seguridad; o los informes relativos a la seguridad y
sus indicadores.
Las salidas secundarias, o de menor importancia, que se obtienen del proceso son,
por ejemplo, los requisitos formalizados para la seguridad; el plan de proyecto para
implantar el proceso de seguridad; los procedimientos para deteccin y respuesta a
incidentes de seguridad; una clasificacin de los activos en cuanto a su criticidad; el
personal de TI y de la empresa concienciado; los informes de los resultados de las
pruebas de seguridad; etc.
En la definicin de las actividades del proceso se han tenido en cuenta lo establecido
en la Norma ISO/IEC 27001 en su apartado 4.2, que agrupa las actividades de
gestin de la seguridad en torno al ciclo PDCA de Deming (vase la figura 6.6.6).
Extrayendo cada epgrafe del apartado 4.2 de la Norma ISO/IEC 27001 se esta-
blecen un total de 30 actividades. En la figura 6.6.7 se relacionan stas.
Como se ha mencionado anteriormente, en este libro se ha decidido respetar lo defi-
nido en ISO/IEC 27001 como la mejor va para llevar a cabo los requisitos estable-
cidos en las Normas ISO/IEC 20000, adems, para facilitar el entendimiento de las
actividades, se ha realizado una agrupacin intermedia. De esta forma, en el presente
proceso las actividades de gestin de la seguridad quedan estructuradas en dos nive-
les: el primero alineado el ciclo PDCA de ISO/IEC 27001, mientras que el segundo
nivel permite entender mejor el transcurso del proceso.
P Planificar A Actuar
Creacin del proceso o SGSI Mantenimiento y mejora
Establecer poltica, objetivos, evaluar el riesgo, Plan Implementar mejoras, acciones correctivas
seleccionar controles, obtener la aprobacin Planificar y preventivas, comunicar resultados,
de la direccin, declaracin de riesgos. asegurar implantacin de las mejoras.
Do Act
Hacer Actuar
D Hacer Check C Verificar
Implementacin y operacin Verificar Supervisin y revisin
Plan de tratamiento del riesgo, implementar Supervisar, monitorizar, revisiones regulares,
controles, formacin, implantar procedimientos medir la efectividad, auditoras, actualizar
gestin incidentes de seguridad. planes, registro de acciones y eventos.
Figura 6.6.6. La gestin de la seguridad se articula en torno al ciclo PDCA
Actividades del sistema de gestin de la seguridad (SGSI) en UNE-ISO/IEC 27001
4.2.1 Creacin del SGSI 4.2.3 Supervisin y revisin del SGSI

a) Definir el alcance. a) Ejecutar procedimientos de supervisin y revisin.
b) Definir una poltica de seguridad. b) Realizar revisiones peridicas de la eficacia del SGSI.
c) Definir el enfoque de la evaluacin de riesgos de la c) Medir la eficacia de los controles.
organizacin. d) Revisar las evaluaciones de riesgos en intervalos
d) Identificar los riesgos. planificados y revisar los riesgos residuales.
e) Analizar y valorar los riesgos. e) Realizar las auditoras internas del SGSI en
f) Identificar y evaluar las opciones para el tratamiento intervalos planificados.
de riesgos. f) Realizar una revisin general del SGSI.
g) Seleccionar los objetivos de control y los controles g) Actualizar los planes de seguridad.
para el tratamiento de los riesgos. h) Registrar las acciones e incidencias que pudieran
h) Obtener la aprobacin de los riesgos residuales afectar a la eficacia o al funcionamiento del SGSI.
propuestos.
4.2.4 Mantenimiento y mejora del SGSI
i) Obtener la autorizacin para implementar y operar
a) Implementar en el SGSI las mejoras identificadas.
el SGSI.
b) Aplicar las medidas correctivas y preventivas
j) Elaborar una declaracin de aplicabilidad.
adecuadas.
4.2.2 Implementacin y operacin del SGSI c) Comunicar las acciones y mejoras a todas las
a) Formular un plan de tratamiento de riesgos. partes.
b) Implementar el plan de tratamiento de riesgos. d) Asegurar que las mejoras alcancen los objetivos
c) Implementar los controles seleccionados. previstos.
d) Definir el modo de medir la eficacia de los controles.
e) Implementar programas de formacin y de
concienciacin.
f) Gestionar la operacin del SGSI.
SGSI: Sistema de Gestin de la Seguridad de la Informacin o
g) Gestionar los recursos del SGSI. modelo formalizado con el que se gestiona la seguridad
h) Implementar procedimientos y controles para de la informacin. La Norma UNE-ISO/IEC 27001 define
deteccin y respuesta a incidentes de seguridad. este sistema de gestin.
Figura 6.6.7. Las 30 actividades de gestin de la seguridad en la Norma ISO/IEC 27001

En la figura 6.6.8 se muestra un esquema con las actividades del proceso, realizado
imitando el ya legendario esquema de gestin de la continuidad de ITIL v2.
GESTIN DE LA SEGURIDAD DE LA INFORMACIN
Creacin del proceso Alcance, poltica y enfoque Poltica seguridad

Alcance, poltica y enfoque Proyecto implantacin
PLAN
Anlisis de riesgos
Evaluacin de riesgos
de seguridad
Seleccin de objetivos de
Requerimientos y estrategia
control y sus controles
Declaracin de
Declaracin de riesgos
riesgos de seguridad
Implementacin Plan tratamiento

Plan tratamiento de riesgos
y operacin riesgos seguridad
DO
Implementar el plan de tratamiento de riesgos
Procedimiento incidentes seguridad Pruebas iniciales
Pruebas iniciales
Prueba de Supervisar,
Supervisin
controles monitorizar
y revisin
CHECK
Revisin y y registrar Investigar

auditora incidentes
Actualizar
Gestionar incidentes severos de seguridad
Mantenimiento y mejora
ACT
Fuente: e.p. a partir del libro ITIL Provisin de Servicio publicado por OGC y de UNE-EN ISO 27001.
Figura 6.6.8. Enfoque de la gestin de la seguridad de la informacin en este libro
Siguiendo esta estructuracin en dos niveles, a continuacin se relacionan las acti-

vidades del proceso alineadas con lo indicado en la Norma ISO/IEC 27001.
Creacin del proceso o del sistema de gestin SGSI. La primera etapa para
empezar a implantar la seguridad es la fase de creacin del propio proceso de ges-
tin de la seguridad (si se est en ISO/IEC 20000) o del sistema de gestin de la
seguridad (si se est aplicando ISO/IEC 27001). La creacin del proceso se realiza
en las etapas de inicio, y de requerimientos y estrategia, al igual que en la implanta-
cin de los procesos de continuidad y disponibilidad. En el inicio se establece el
entorno necesario para que comience la implantacin de la gestin de la seguridad.
A partir del entorno del negocio, se determinan los requerimientos de seguridad, se
identifican los riesgos, se acuerda el tratamiento a los mismos, se establecen los
objetivos de control y se seleccionan los controles adecuados para conseguir estos
objetivos, y se realiza la declaracin formal de los riesgos.
Alcance, poltica y enfoque. Se concretan las directrices que debe cumplir
el proceso:
Definir el alcance (4.2.1.a 1): se concreta el alcance y los lmites del pro-
ceso en trminos de las caractersticas de la actividad del negocio, de la
organizacin, su ubicacin, sus activos y tecnologa, incluyendo los deta-
lles y la justificacin de cualquier exclusin del alcance.
Definir una poltica de seguridad (4.2.1.b): que incluya un marco para
la fijacin de objetivos y establezca una orientacin general; que tenga en
cuenta los requisitos de la actividad del negocio, los requisitos legales y las
obligaciones contractuales.
Definir el enfoque de la evaluacin de riesgos de la organizacin
(4.2.1.c): la metodologa seleccionada para la evaluacin de riesgos debe
asegurar que las evaluaciones de riesgos generen resultados comparables y
reproducibles.
Proyecto implantacin. Se recomienda que la implantacin de la gestin de

la seguridad se estructure en forma de proyecto, pues es un trabajo complejo
y que afecta a muchos aspectos: organizativos, procedimentales, modifica-
ciones tcnicas, implantacin de herramientas, etc. Se requiere la designa-
cin de un nico responsable que controle toda la implementacin, que se
doten los recursos necesarios y que se realice una planificacin detallada de
las tareas. El proyecto de implantacin asume la puesta en marcha del pro-
ceso o del SGSI, segn sea el caso.
Evaluacin de riesgos. Se realiza la identificacin de los riesgos de la segu-
ridad, se analizan y se determinan los niveles de riesgo. Ntese que la activi-
dad de evaluacin de riesgos es similar a la realizada en el proceso de dispo-
nibilidad y de continuidad, por lo que se recomienda que se realicen de
forma conjunta o, por lo menos, integrada.
1
Entre parntesis la referencia al epgrafe equivalente en la Norma UNE-ISO/IEC 27001.
Identificar los riesgos (4.2.1.d): identificacin de los activos, identifica-

cin de las amenazas, identificacin de vulnerabilidades y determinacin
del impacto que sobre los activos puede tener una prdida de confidencia-
lidad, integridad y disponibilidad en los mismos.
Analizar y valorar los riesgos (4.2.1.e): analizar el impacto sobre la acti-
vidad del negocio de un incidente de seguridad, evaluar la probabilidad de
que se produzcan estos fallos, estimar los niveles de riesgo y determinar si
los riesgos son aceptables.
Seleccin de objetivos de control y sus controles. La Norma ISO/IEC

27001 proporciona un juego muy completo de objetivos de control, cada
uno con sus controles de seguridad asociados. Para cada control se detalla
la finalidad y las recomendaciones para su implementacin. La gestin de la
seguridad est claramente orientada a la implantacin de controles, que se
pueden seleccionar entre estos proporcionados u otros que se consideren
necesarios.
Identificar y evaluar las opciones para el tratamiento de riesgos
(4.2.1.f), para cada uno de los riesgos se determina la forma de trata-
miento: si se le aplicar las medidas de salvaguardia o controles adecua-
dos, se asumir el riesgo, se evitar el mismo o se transferir a un ter-
cero.
Seleccionar los objetivos de control y los controles para el trata-
miento de los riesgos (4.2.1.g): una vez identificado el tratamiento de
los riesgos, se determinan los objetivos para controlarlos. Para cada obje-
tivo de control se establecern los controles que se consideren necesarios
para conseguir que se alcancen. Objetivos y controles se seleccionan pri-
meramente entre los contenidos en la Norma ISO/IEC 27001 y detalla-
dos en ISO/IEC 17799. Esto no quita para que se aadan otros objetivos
y sus controles asociados si se consideran necesarios. Esta seleccin debe
tener en cuenta los criterios de aceptacin de riesgos, adems de los requi-
sitos legales, reglamentarios y contractuales.
Declaracin de riesgos. Formalizacin y aprobacin por la direccin de la

evaluacin de riesgos realizada y la seleccin de los controles.
Obtener la aprobacin de los riesgos residuales propuestos (4.2.1.h),
por parte de la direccin.
Obtener la autorizacin para implementar y operar (4.2.1.i) el pro-
ceso de gestin de la seguridad o el SGSI, por parte de la direccin.
Elaborar una declaracin de aplicabilidad SoA 2 (4.2.1.j). Es un docu-

mento que especifica los objetivos de control y los controles de seguridad
que se utilizarn para el tratamiento de los riesgos, seleccionados entre los
propuestos por ISO/IEC 27001 y de otras fuentes. La declaracin de apli-
cabilidad proporciona un resumen de las decisiones relativas al tratamiento
de los riesgos. La justificacin de las exclusiones facilita una comprobacin
cruzada de que no se ha omitido inadvertidamente ningn control. Se ela-
bora a partir de las opciones de tratamiento de riesgos decididas, y de la
seleccin realizada de los objetivos de control y sus controles asociados.
Implementacin y operacin. Una vez evaluados los riesgos, identificada la estra-

tegia de tratamiento para cada uno y seleccionados los objetivos de control y los
controles, se procede a la implementacin del proceso de gestin de seguridad. Se
comienza con un plan para el tratamiento de riesgos, para continuar con las accio-
nes para implantar los controles y la definicin de los procedimientos especficos
para incidentes de seguridad.
Plan de tratamiento de riesgos. Dentro del plan de implantacin general
de la seguridad se encuentra el plan concreto de tratamiento de riesgos, que
es un plan de implantacin especfico para las medidas correctoras de los
riesgos. Se centra en planificar la puesta en marcha de cada una de las opciones
definidas para el tratamiento de los riesgos, detalla especialmente la planifi-
cacin para implementar los controles.
Formular un plan de tratamiento de riesgos (4.2.2.a) que identifique
las acciones, los recursos, las responsabilidades y las prioridades adecua-
dos para gestionar los riesgos de la seguridad de la informacin.
Implementar el plan de tratamiento de riesgos. Desarrollando las acciones

planificadas en el plan de tratamiento anterior, se llevan a cabo las tareas nece-
sarias para implementar cada uno de los controles seleccionados. Tambin se
definen e implementan los indicadores para medir la eficacia de los controles.
Implementar el plan de tratamiento de riesgos (4.2.2.b) para lograr los
objetivos de control identificados, que tenga en cuenta su financiacin, y
la asignacin de funciones y responsabilidades.
Implementar los controles seleccionados (4.2.2.c): conjunto de subpro-
yectos o tareas necesarias para la puesta en marcha de los controles. Esta es
una de las actividades ms extensas y costosas de la implementacin de la
2
SoA, Statement of Applicability.
seguridad, pues los controles son de todo tipo, unas veces sern directrices
internas, otras la designacin de funciones, otras requerir la compra de
equipamiento o de soluciones software, puede ser necesario cambiar la con-
figuracin de los sistemas, etc.
Definir el modo de medir la eficacia de los controles (4.2.2.d): la
medicin de la eficacia de los controles permite determinar hasta qu
punto los controles cumplen los objetivos de control planificados. Se
define la forma de medir la eficacia de los controles o de los objetivos
de control seleccionados, tambin se especifica cmo se tienen que usar
estas mediciones.
Procedimiento de gestin de incidentes seguridad. De forma integrada

con el proceso de gestin del incidente, en este proceso especializado en la
seguridad, se desarrollan e implementan los procedimientos especficos para
la alerta temprana de este tipo de incidentes y los procedimientos de detalle
para que la respuesta sea lo ms eficaz posible. Este procedimiento se debe
integrar con el resto de procedimientos generales de gestin del incidente.
Implementar procedimientos y controles para deteccin y respuesta a
incidentes de seguridad (4.2.2.h) para realizar una deteccin temprana
de eventos de seguridad y facilitar una respuesta rpida ante cualquier
incidente de seguridad.
Pruebas iniciales. Conjunto de pruebas que garantizan que las medidas

implementadas funcionan correctamente. Se deben realizar antes de dar por
finalizada la implementacin.
Gestionar recursos seguridad.
Gestionar la operacin de la seguridad (4.2.2.f): conjunto de activida-
des y procedimientos tcnicos del da a da que permiten que los controles
implantados sigan activos.
Gestionar los recursos de la seguridad (4.2.2.g y 5.2) que cubre tanto
la provisin de los recursos, la dotacin de presupuestos para la concien-
ciacin, formacin y capacitacin del personal.
Implementar programas de formacin y de concienciacin (4.2.2.e
y 5.2.2). Es necesario formar a todo el personal al que se le hayan asignado
responsabilidades para que sea competente para llevar a cabo las tareas reque-
ridas. Mediante diversas acciones de comunicacin se asegura que el resto del
personal sea consciente de la trascendencia y de la importancia de las activi-
dades de seguridad de la informacin y de su contribucin a las mismas.
Supervisin y revisin. Una vez implantados los controles, se llevan a cabo de

forma continua un conjunto de actividades que supervisan que los controles se
mantengan activos y que la seguridad permanezca vigente.
Revisin y auditora. Revisiones, mediciones y auditoras internas del fun-
cionamiento de todos los aspectos de la seguridad.
Realizar revisiones peridicas de la eficacia de la seguridad (4.2.3.b), con
el fin de comprobar que la seguridad funciona como se espera. Las revisiones
comprenden: los resultados de las auditoras de seguridad, los incidentes de
seguridad, los resultados de las mediciones de la eficacia, las sugerencias y los
comentarios de todas las partes interesadas. Estas revisiones incluyen el cum-
plimiento de la poltica de seguridad, de los objetivos fijados y de los contro-
les de seguridad.
Medir la eficacia de los controles (4.2.3.c), para verificar si se estn
cumpliendo los requisitos de seguridad. Como resultados de las medicio-
nes se emiten los informes asociados.
Revisar las evaluaciones de riesgos y revisar los riesgos residuales
(4.2.3.d). Revisin de las evaluaciones de riesgos en los intervalos planifi-
cados y revisin de los riesgos residuales y los niveles de riesgo aceptables
que han sido identificados, teniendo en cuenta los cambios ocurridos
(organizacin, tecnologa, objetivos y requisitos del negocio, amenazas,
factores externos, etc.).
Realizar las auditoras internas (4.2.3.e) sobre la seguridad en los perodos
planificados. Las auditoras internas las lleva a cabo la propia organizacin o
bien se contratan externamente pero con fines de evaluacin internos.
Realizar una revisin general (4.2.3.f) del proceso de gestin de la seguri-
dad (o del SGSI) con carcter peridico, para asegurar que el mbito de apli-
cacin sigue siendo adecuado y que se revisan todos los aspectos del mismo.
Pruebas de los controles. Una vez implantados los controles y realizada la

prueba inicial en la etapa de implementacin, se deben realizar pruebas
peridicas de los controles para verificar que siguen siendo vlidos y que
producen los resultados especificados de tratamiento de los riesgos. Entre
estas pruebas hay que destacar los ataques concertados o hacking tico, no
malicioso, con el que se intenta vulnerar la seguridad para comprobar los
puntos dbiles y el funcionamiento de los controles.
Supervisar, monitorizar y registrar. Labor permanente de la gestin ope-
rativa de la seguridad que vela de forma constante por el cumplimiento de lo
establecido y la deteccin temprana de los incidentes.
Ejecutar procedimientos de supervisin y revisin (4.2.3.a), para iden-

tificar lo antes posible las debilidades del sistema de seguridad, ayudar a
detectar eventos de seguridad, determinar si las acciones tomadas para
resolver una vulneracin de la seguridad han sido eficaces, etc.
Registrar las acciones o incidentes (4.2.3.h) relacionados con la seguri-
dad, con el fin de recolectar toda la informacin necesaria para su evalua-
cin posterior.
Investigar incidentes de seguridad. Se deben investigar los incidentes de

seguridad de cara a identificar las debilidades y generar las mejoras o accio-
nes correctoras adecuadas. La investigacin de incidentes de seguridad se
debe registrar como un ticket de problema y se debe realizar como parte del
proceso de gestin del problema.
Actualizar. La informacin, documentacin, etc.
Actualizar los planes de seguridad (4.2.3.g) teniendo en cuenta las con-
clusiones de las actividades de supervisin y revisin, los cambios en los
servicios, etc.
Gestionar incidentes severos de seguridad. Los incidentes de seguridad se

deben gestionar por el mismo cauce que el resto de incidentes o de contin-
gencias de continuidad. En el caso de incidentes severos, se deben definir los
procedimientos especficos de actuacin y es conveniente tener un conjunto
de especialistas en seguridad preparados. El tratamiento de incidentes graves
de seguridad tienen muchas similitudes con la gestin de una contingencia
de continuidad: hay una prdida importante en los servicios de TI, se debe
gestionar soluciones alternativas, movilizar los medios de recuperacin, ges-
tionar la comunicacin exterior, etc. En ciertas organizaciones, se tiene pre-
parada una sala o un centro especializado en la gestin de estos incidentes
graves de seguridad. En otras ocasiones se integra en la sala de crisis para la
gestin de todo tipo de incidentes graves.
Mantenimiento y mejora del proceso o del SGSI. Como en todo proceso se

debe contemplar la mejora continua del mismo. A este respecto, ISO/IEC 27001
establece las actividades siguientes:
Implementar las mejoras identificadas (4.2.4.a).
Aplicar las medidas correctivas y preventivas adecuadas (4.2.4.b).
Comunicar las acciones y mejoras a todas las partes (4.2.4.c).
Asegurar que las mejoras alcancen los objetivos previstos (4.2.4.d).
El enfoque dado al proceso en ITIL v3 es de concepcin muy similar al de

ISO/IEC 27001, aunque mucho menos detallado. Tambin se basa en una poltica
de seguridad de la informacin, en un sistema de gestin de la seguridad para
implementar el proceso, en una estructura organizacional, en unos controles, en
comunicacin, en formacin, en concienciacin, etc. El proceso se plantea en
aspectos ms all de los puramente tcnicos. En la figura 6.6.9 se muestra el enfo-
que que se da en ITIL v3 para este proceso.
Enfoque del proceso en ITIL v3 muy similar a 27001 Actividades de gestin de la seguridad en ITIL v3
El proceso consiste principalmente en: Producir y mantener una poltica de seguridad de la

Un poltica de seguridad de la informacin que informacin.
conduce a la estrategia, los controles y la regulacin. Evaluar y categorizar los activos de informacin y
Un sistema de gestin de la seguridad (SGSI) vulnerabilidades.
conteniendo normativa, procedimientos de gestin Imponer y revisar controles de seguridad, revisin
y directrices. e implementacin de mitigacin del riesgo.
Una estrategia clara de seguridad ligada a los Comunicar, implementar e impulsar la adhesin a
objetivos de negocio. todas las polticas de seguridad.
Informar, revisar y reducir las vulnerabilidades de
Una estructura organizacional de seguridad.
seguridad y los incidentes mayores.
Un conjunto de controles que soporte la poltica. Peridicamente evaluar, revisar e informar los riesgos
Procedimientos de supervisin que aseguren el y amenazas de seguridad.
cumplimiento y proporcionen informacin sobre Supervisar y gestionar incidentes y vulnerabilidades
la efectividad. de seguridad.
Una estrategia y plan de comunicacin para la
seguridad.
Una estrategia y plan de formacin y concienciacin.
Figura 6.6.9. Planteamiento de la gestin de la seguridad en ITIL v3
La poltica de seguridad de la informacin

La poltica de seguridad de la informacin es un documento en el que la direccin
realiza una declaracin formal estableciendo los objetivos generales de seguridad a
alcanzar por la organizacin. Debe ser el punto de partida que desencadena y marca
el contexto para la implantacin de este proceso.
La poltica de seguridad de la informacin debera contemplar de manera explcita:
El objeto de la misma, el alcance y el marco jurdico.
La organizacin y responsabilidades, y la aplicacin de la misma.
La evidencia del compromiso de la direccin en materia de seguridad.
El aseguramiento de la confidencialidad, disponibilidad e integridad de la

informacin derivada de los servicios prestados.
La referencia al desarrollo posterior de los procesos y procedimientos que la
respaldan.
La referencia a la mejora continua de la seguridad en la organizacin.
La potenciacin de la concienciacin, formacin y motivacin del personal
de la empresa u organizacin.
El compromiso del cumplimiento de la legislacin vigente en materia de
seguridad.
El compromiso de establecer objetivos especficos en materia de seguridad.
Su difusin a todo el personal de la empresa u organizacin.
Su revisin peridica o siempre que haya cambios significativos en la
empresa u organizacin.
En la figura 6.6.10 se muestra un enfoque para este documento.
Poltica de seguridad de la informacin
Objeto, alcance, marco, jurdico y vigencia. Para velar por el cumplimiento

de la poltica, promueve la
Organizacin y responsabilidades.
existencia de:
Compromiso de la direccin.
Un responsable de seguridad.
Compromiso de establecer objetivos especficos en
materia de seguridad. Un comit de seguridad.
Polticas relativas a: control de accesos, control de

contraseas, antivirus, correo electrnico, Internet, Responsable
clasificacin de la informacin, acceso remoto, de seguridad
acceso de suministradores, etc.
Desarrollo posterior de los procesos y procedimientos.
Mejora continua de la seguridad en la organizacin. Comit de
Confidencialidad, disponibilidad e integridad de la seguridad
informacin en los servicios prestados.
Potenciar la concienciacin, formacin y motivacin del
personal de la organizacin.
Compromiso con el cumplimiento de la legislacin
vigente en materia de seguridad.
Debe ser difundida a todo el personal de la empresa u
organizacin.
Revisin de la poltica. Fuente: Telefnica y Libro ITIL Provisin
de Servicio publicado por OGC.
Figura 6.6.10. Contenidos de la poltica de seguridad de la informacin

La Norma ISO/IEC 20000-1 establece el requisito claro de la existencia de la pol-

tica de seguridad y la necesidad de que sea difundida al personal de TI e incluso a
los usuarios de los servicios de TI.
UNE-ISO/IEC 20000-1
La direccin, con la autoridad apropiada, debe aprobar una poltica de seguridad
de la informacin, que debe comunicarse a todo el personal implicado y, cuando
sea adecuado, a los clientes.
La poltica de seguridad es un documento de alto nivel firmado habitualmente por

el presidente, el consejero delegado o el cargo de mayor nivel en la empresa u orga-
nizacin. Una vez firmado, debe publicarse en diferentes medios, como, por ejem-
plo, la intranet de la empresa, y su contenido tiene que divulgarse. Tambin debe
extenderse a todos los empleados, pues debern seguir en sus actividades diarias los
preceptos que se indican en la misma.
El comit de seguridad
La poltica de seguridad conviene que est respaldada por un rgano interno en el
que se traten todas las cuestiones que precisen de la intervencin de la direccin,
adems de servir como instrumento que ejecuta el compromiso con la seguridad de
la informacin.
El comit de seguridad, por su composicin, se convierte en el asesor del responsa-
ble de seguridad para las decisiones de mayor nivel en la organizacin en los asun-
tos relacionados con la seguridad de la informacin. Al frente del mismo se encuen-
tra el responsable del proceso de seguridad. El comit se debera reunir con una
periodicidad mnima mensual. El resultado de las reuniones de este comit deber
quedar reflejado en unas actas de reunin.
El comit de seguridad se responsabiliza de:
El asesoramiento al responsable de seguridad.
La comunicacin a toda la organizacin de la importancia de cumplir tanto
los requisitos de la norma como los legales y reglamentarios.
La evolucin de la poltica y objetivos de la seguridad.
El aseguramiento de la disponibilidad de presupuestos y recursos adecuados.
La aprobacin y respaldo ejecutivo a los planes de implantacin y de trata-
miento de riesgos de la organizacin.
Que se realicen todas las actividades del proceso, desde la creacin, hasta el
mantenimiento y mejora.
La revisin de los temas de seguridad ms relevantes para la empresa u orga-
nizacin.
Evaluacin de riesgos
Es recomendable que la evaluacin de riesgos de seguridad y su tratamiento est
basada en alguna de las metodologas existentes relacionadas con esta materia,
como por ejemplo, CRAMM, NIST, Magerit, etc. Cada organizacin puede deci-
dir utilizar la metodologa que considere ms adecuada.
ISO/IEC 20000-2 recomienda adems que la evaluacin de riesgos se realice con
una periodicidad, que se registre, que se mantenga actualizada con los cambios, etc.
UNE-ISO/IEC 20000-2
Prcticas para la evaluacin de Seguridad y disponibilidad de

los riesgos de seguridad la informacin
La evaluacin de los riesgos de seguri- Al evaluar los riesgos, se debera pres-
dad debera: tar atencin a los siguientes puntos:
a) ser realizada con una periodici- a) revelacin de informacin sensi-
dad acordada; ble a partes no autorizadas;
b) ser registrada; b) informacin inexacta, incompleta
o invlida (por ejemplo: informa-
c) ser mantenida durante los cam-
cin fraudulenta);
bios (cambios de las necesidades
del negocio, de procesos o de c) informacin que quede inservible
configuraciones); para su uso (por ejemplo: debido
a un corte de energa elctrica);
d) ayudar a entender en qu podra
impactar uno de los servicios ges- d) dao fsico o destruccin de los
tionados; equipos necesarios para proveer
e) proveer de informacin para las los servicios.
decisiones referentes a los tipos Tambin se deberan tener en cuenta los
de controles a establecer. objetivos de la poltica de seguridad de la
informacin, las necesidades para satisfa-
cer los requisitos especficos de los clien-
tes respecto a la seguridad (por ejemplo:
niveles de disponibilidad) y los requisitos
legales o regulatorios que apliquen.
En la evaluacin de riesgos se realiza la identificacin de los riesgos, y el anlisis y

valoracin de los mismos. A su vez, cada una de estas actividades est formada por
tareas ms detalladas:
Identificar los riesgos:
Identificacin de los activos.
Identificacin de las amenazas.
Identificacin de las vulnerabilidades.
Determinacin del impacto sobre los activos.
Analizar y valorar los riesgos:

Anlisis del impacto sobre la actividad del negocio.
Evaluacin de la probabilidad de ocurrencia.
Estimacin de los niveles de riesgo.
Determinacin de si los riesgos son aceptables.
Identificacin de los activos o elementos de configuracin. Inicialmente se

deben identificar todos aquellos elementos de configuracin empleados en el fun-
cionamiento de las infraestructuras y servicios prestados a clientes, as como, la pro-
pia informacin gestionada de su uso. La identificacin de los activos desemboca
en un inventario detallado de los mismos. En la identificacin se realiza tambin su
clasificacin en cuanto a su criticidad o importancia para el funcionamiento de los
servicios. Tambin se debe identificar al propietario de cada uno, o responsable de
su proteccin y funcionamiento. Si se ha implantado el proceso de gestin de la
configuracin (vase el captulo 9 de este libro), esta actividad ya se habr realizado
y nicamente habr que complementar los inventarios con la informacin que se
precisa para la seguridad.
ISO/IEC 20000-2 es clara en sus recomendaciones al respecto.
UNE-ISO/IEC 20000-2
Identificacin y clasificacin de los

activos de informacin ordenadores, sistemas de comuni-
cacin, equipos del entorno, docu-
El proveedor del servicio debera: mentos y otra informacin) que
a) mantener un inventario de los acti- son necesarios para la provisin
vos de informacin (por ejemplo, del servicio;
b) clasificar cada activo de acuerdo c) la responsabilidad para la protec-

con su criticidad para el servicio y cin de los activos debera recaer
el nivel de proteccin que ste en el propietario de dichos acti-
requiera, as como nombrar a un vos, aunque estos pueden delegar
propietario que sea el responsable las responsabilidades de la ges-
de proporcionar dicha proteccin; tin diaria de la seguridad.
La estructura lgica de estos inventarios de activos, realizados desde la perspectiva

de la seguridad, debe estar perfectamente alineada con la base de datos de la confi-
guracin (CMDB). La informacin sobre los activos o elementos de configuracin
identificados se deben incluir en la CMDB o en inventarios especficos. Segn las
necesidades de cada organizacin, este inventario para seguridad, puede contener
las siguientes categoras:
Hardware. Servidores, almacenamiento, equipos de comunicacin, ordena-
dores personales, impresoras, etc.
Software. Aplicaciones que forman los servicios de TI, productos y paquetes
software, herramientas, software ofimtico, etc.
Documentacin. Organizativa, operativa tcnica, etc.
Servicios. Servicios de TI, servicios internos, servicios de terceros, etc.
Activo de informacin. Bases de datos, archivos que contienen datos per-
sonales, manuales de usuarios, material de formacin, procedimientos de tra-
bajo, planes de continuidad, contratos, documentacin de la organizacin,
correos electrnicos, etc.
Contratos. SLA o acuerdos con clientes, OLA o acuerdos internos, UC o
contratos con suministradores.
Personas. Personal de TI, directivos de la empresa, personal subcontratado,
personas de contacto de suministradores, de vigilantes de seguridad, perso-
nal de servicios, personal de limpieza, etc. A efectos de la gestin de la segu-
ridad de la informacin, puede ser necesario tener una relacin exhaustiva de
personas propias o ajenas que habitualmente tienen acceso a las instalaciones
y sistemas de la empresa.
Localizaciones. Edificios, centros de datos, sistemas de climatizacin, siste-
mas de alimentacin elctrica, sistemas de deteccin de incendios etc.
En la identificacin de activos se realiza una valoracin de cada uno en relacin a:

La criticidad del activo para la organizacin.
La criticidad del activo para los servicios de TI.

El nivel de proteccin requerido para mantener la integridad, confidenciali-
dad y disponibilidad de la informacin.
A partir de esta valoracin, se le asigna a cada activo o elemento de configuracin

un nivel que determina su importancia para los servicios de TI y, por tanto, para el
negocio:
Importancia alta. El activo interviene en procesos clave para la organiza-
cin (necesarios y suficientes) y su no disponibilidad puede poner en peligro
la continuidad del negocio.
Importancia media. El activo interviene en los procesos de apoyo a los
esenciales de la organizacin. Su indisponibilidad puede retrasar un determi-
nado proceso pero no se vera afectada la continuidad del negocio.
Importancia baja. El activo interviene en procesos que no estn directa-
mente relacionados con el negocio, aunque s son necesarios. Su no disponi-
bilidad causa algn contratiempo pero en ningn caso se vera afectada la
continuidad del negocio.
La importancia otorgada a cada uno de los activos se reflejar tambin en el inven-

tario de activos.
Identificacin de las amenazas. El siguiente paso dentro de la evaluacin de ries-

gos es identificar todas las amenazas sobre los activos o elementos de configura-
cin. Las amenazas pueden provenir de distintas fuentes, como por ejemplo:
Del entorno. Sucesos exteriores a la organizacin que pueden afectar a los
servicios: eventos de carcter natural, interrupciones de los servicios exter-
nos, factores climatolgicos, etc.
Humanas. Sucesos en los que hay una intervencin humana negligente,
intencionada o deliberada.
Fallos tcnicos. Derivados de algn tipo de fallo en equipos, en programa-
cin, en instalaciones, en infraestructuras o del uso de las mismas.
UNE-ISO/IEC 20000-2
Riesgos para los activos de

a) su naturaleza (por ejemplo: fun-
informacin
cionamiento defectuoso del soft-
Los riesgos para los activos de informa- ware, errores de operacin, fallos
cin se deberan evaluar en funcin de: de comunicacin);
b) probabilidad; d) experiencias pasadas.

c) impacto potencial para el negocio;
Se lleva a cabo un anlisis de las amenazas que pueden derivarse de cada una de
estas fuentes, en funcin de los activos existentes en la organizacin, los procesos y
servicios prestados, la posicin en el mercado, el tipo de clientes y los antecedentes.
Las amenazas se irn reflejando en el anlisis de riesgos, detallndose:
Tipo de amenaza. Por ejemplo, robo de informacin.
Motivo. Se indican los motivos que pueden provocar que una amenaza se
materialice.
Resultado (ataque o incidente). Se indican las consecuencias que tendra
para la organizacin cada una de las amenazas en caso de materializarse. Los
resultados tendrn alguna de las siguientes consecuencias sobre la informa-
cin: visualizacin, modificacin, destruccin o prdida, e interrupcin.
Identificacin de las vulnerabilidades. En funcin de las amenazas, y para poder

valorar su importancia, se tendrn en cuenta las vulnerabilidades o debilidades que
puedan existir. Las amenazas para ser consideradas como tal, habrn de tener aso-
ciadas una vulnerabilidad. Al mismo tiempo, estas vulnerabilidades han podido ser
detectadas en la actividad de identificacin de activos.
La identificacin de vulnerabilidades se realiza a travs de un anlisis exhaustivo de
cada uno de los activos. La informacin de este anlisis podr ser completada con
listados de vulnerabilidades, con el asesoramiento de expertos en seguridad o con
la informacin proporcionada por los propios proveedores de los activos (en los
casos que se trate de recursos materiales). En la identificacin de vulnerabilidades
se tendrn en cuenta:
La poltica de seguridad.
Los procedimientos de seguridad (si existiesen en ese momento).
Los requerimientos de los sistemas.
Los controles o salvaguardias tcnicas implantadas.
Los chequeos de vulnerabilidades anteriores.
Las auditoras de conformidad tcnica realizadas.
Determinar el impacto sobre los activos. Con el conocimiento de los activos, de

las amenazas y de las vulnerabilidades, se determina a nivel de cada activo el posible
impacto en l si se materializase la amenaza. El impacto de la amenaza en el activo

se valora teniendo en cuenta la prdida, y la degradacin del activo, considerando
las consecuencias:
Prdida de integridad. La integridad del sistema o de los datos se pierde.
Prdida de disponibilidad. Implica la imposibilidad de que el activo pueda
realizar su funcin.
Prdida de confidencialidad. La informacin que gestiona el activo queda
expuesta y desprotegida.
Analizar el impacto sobre la actividad del negocio. Consiste en determinar y

cuantificar las consecuencias que sobre el negocio tendra cada una de las amenazas
en caso de materializarse, es decir, el ataque o incidente identificado en el anlisis
de riesgos. En funcin de las consecuencias se establecer el nivel de impacto, que
podr ser:
Impacto alto. Se provoca una prdida elevada, afecta a los activos de mayor
valor. Impacta no slo a los procesos crticos de la organizacin sino tambin
a su misin o la imagen que se da al exterior. Tambin puede provocar daos
o vctimas humanas. Se deben cuantificar las posibles prdidas.
Impacto medio. Se provoca una prdida media. Deber estar cuantificado.
Impacto bajo. Puede provocar la prdida de algn activo no muy impor-
tante. Deber estar cuantificado.
El nivel de impacto se refleja y justifica en el anlisis de riesgos.
Evaluar la probabilidad de ocurrencia. A la hora de determinar la probabilidad

de que una amenaza se materialice se debern tener en cuenta:
La motivacin y capacidad del origen de la amenaza.
El tipo de vulnerabilidad
Los controles o salvaguardias existentes
En funcin de las consideraciones anteriores se determina la probabilidad de

ocurrencia de un riesgo. En todos los casos es recomendable cuantificar la pro-
babilidad en forma de porcentaje. Como mnimo la probabilidad se clasificar
como:
Probabilidad alta. Si el origen de la amenaza tiene una motivacin clara y
tiene capacidad para actuar. No existen salvaguardias adecuadas.
Probabilidad media. El origen de la amenaza est motivado y tiene capaci-

dad para actuar. Existen salvaguardias adecuadas.
Probabilidad baja. El origen de la amenaza no est motivado o no tiene
capacidad para actuar. Existen salvaguardias.
La probabilidad de que una amenaza se materialice tambin estar reflejada en el

anlisis de riesgos.
Estimar los niveles de riesgo. En el siguiente paso se determina el nivel de riesgo

para cada una de las amenazas. El riesgo estar cuantificado, calculado en base a la
probabilidad de que la amenaza se materialice y por el impacto que sta puede lle-
gar a tener en la empresa u organizacin, teniendo en cuenta los controles o salva-
guardas existentes. El riesgo se clasifica como:
Riesgo alto. Existe una gran necesidad de medidas correctivas (controles)
que deben articularse en un plan.
Riesgo medio. Son necesarias medidas correctivas (controles) que se incor-
porarn a un plan para ser ejecutadas en un plazo de tiempo razonable.
Riesgo bajo. Ser necesario determinar qu medidas correctivas (controles)
son necesarias, o bien aceptar el riesgo.
El riesgo es una funcin de la probabilidad y del impacto (vase la figura 6.6.11).
Riesgo Impacto
Probabilidad Alto Medio Bajo
Alta Alto Medio Bajo
Media Medio Medio Bajo
Baja Medio Bajo Bajo
Figura 6.6.11. Clculo del riesgo en funcin de la probabilidad y del impacto
El nivel del riesgo se refleja en el anlisis de riesgos. Se calcula como el resultado de

multiplicar el valor de la probabilidad de que la amenaza se materialice por el valor
del impacto que dicha amenaza tendra para la organizacin.
El nivel de riesgo de cada amenaza deber cruzarse con cada uno de los activos. De
este modo se conoce el riesgo total soportado por cada uno de los activos. Este
riesgo total es ponderado en funcin de la importancia dada al activo en el
momento de su identificacin. Para cada uno de los activos se tendr un nivel de
riesgo ponderado.
Determinar si los riesgos son aceptables. Con los valores de los riesgos calculados
se determinan los riesgos asumibles por la organizacin y los que no son aceptables.
Con la determinacin de los riesgos aceptables termina la evaluacin de riesgos.

A partir de esta informacin deber iniciarse la fase de tratamiento del riesgo.
Identificacin y evaluacin de las opciones de

tratamiento de riesgos
Tras la evaluacin de riesgos se pasa a la actividad de identificar y evaluar las
diferentes opciones para el tratamiento de riesgos. El primer paso es definir el
umbral del riesgo, es decir, cundo se considera que el nivel de riesgo obtenido
es aceptable, y por tanto, nicamente se vigilarn las condiciones para mante-
ner el nivel obtenido. Tambin se define cundo el riesgo no es aceptable, en
cuyo caso ser necesario seleccionar e implantar controles de seguridad para
cambiar el valor del riesgo. Esta decisin se reflejar posteriormente en una
declaracin formal por parte de la direccin (declaracin de riesgos o de apli-
cabilidad) y en ella se establece tanto el umbral del riesgo efectivo como el del
riesgo residual.
El nivel de riesgo aceptable es la resultante del equilibrio entre el coste de seguri-
dad (coste de los controles de seguridad) y el coste del riesgo (coste que tendra si
el riesgo se hiciera realidad).
A partir de los resultados de la evaluacin de riesgos, y teniendo en cuenta el
nivel de riesgo aceptable establecido para la empresa, el responsable de seguri-
dad, junto con el responsable del activo afectado, identifican aquellos controles o
salvaguardias que le protejan efectivamente contra los riesgos identificados y los
no aceptables. Para cada riesgo se evalan las posibles alternativas que son las
siguientes.
Reducir el riesgo (reducir amenazas, vulnerabilidades, posibles impactos,
etc.) implantando los controles apropiados.
Asumir el riesgo.
Evitar el riesgo.
Transferir el riesgo a terceros (seguros, proveedores, etc.).
Seleccin de los objetivos de control y sus controles

Para cada uno de los riesgos identificados como no aceptables, se identifican los
objetivos de control y los controles adecuados. Inicialmente se seleccionan entre
los propuestos en ISO/IEC 27001, aadiendo posteriormente los que se conside-
ren necesarios y que no estn incluidos en la norma.
Estos controles van orientados a la reduccin del nivel de riesgo existente, de tal
manera que el nivel total de riesgo soportado por la organizacin sea menor al fina-
lizar el perodo de implantacin.
Sobre los riesgos identificados como aceptables tambin se podrn establecer obje-
tivos o se podrn incluir en los planes de gestin del riesgo y contingencia, pero la
organizacin puede determinar no trabajar especficamente en mitigarlos.
En ISO/IEC 20000-1 se requiere que se trabaje con controles de seguridad para
implementar la poltica de seguridad y gestionar los riesgos. Adems, se debern
documentar los controles implementados y se tendr que evaluar previamente el
impacto de los cambios sobre los mismos.
UNE-ISO/IEC 20000-1
Los adecuados controles de seguridad deben ayudar a:

a) implementar los requisitos de la poltica de seguridad de la informacin;
b) gestionar los riesgos asociados al acceso al servicio o a los sistemas.
Los controles de seguridad deben estar documentados. La documentacin debe des-

cribir los riesgos a los que estn asociados los controles, la manera de utilizarlos y el
mantenimiento de los mismos.
El impacto de los cambios sobre los controles se debe evaluar antes de que los cam-
bios sean implementados.
Los controles se asocian a cada uno de los riesgos con el nivel de detalle necesario.
La seleccin de controles debe:
Evaluar y seleccionar los controles. En funcin de los controles seleccio-

nados a priori, antes de proceder a su implantacin, hay que tener en cuenta
la capacidad de adaptacin, compatibilidad y eficiencia que stos tienen.
Analizar su viabilidad econmica. Otro elemento que se debe tener en
cuenta es la viabilidad econmica de cada uno de los controles seleccionados.
Se realizar una valoracin econmica aproximada de los costes que tendra
su implantacin.
Priorizacin de los controles. Dado que todos los controles no se podrn
implantar a la vez, es necesario establecer un orden de implantacin en fun-
cin del riesgo, del plazo y del coste.
Estos controles se implementarn a travs del plan de tratamiento de riesgos.

La Norma ISO/IEC 27001 establece los objetivos de control en torno a 7 reas de
gestin de la seguridad. En la figura 6.6.12 se muestran estas reas.
Figura 6.6.12. reas de gestin de la seguridad en ISO/IEC 27001

y el apartado en el que se tratan en la norma
Para cada una de estas reas de gestin de la seguridad se establecen sus objetivos
de control. Para cada objetivo de control se establece un conjunto posible de con-
troles. En ISO/IEC 27001 se propone un total de 39 objetivos de control y 133
controles. En la figura 6.6.13 se muestra un ejemplo de este contenido.
Objetivos de control y controles en UNE-ISO/IEC 27001 Actividades de gestin de la seguridad en ITIL v3
rea: 10 Gestin de comunicaciones y operaciones. Gua de implementacin:

10.1 Responsabilidades y procedimientos de La segregacin de las tareas es un mtodo
operacin. para reducir el riesgo de un mal uso accidental o
10.1.1 Documentacin de los procedimientos de deliberado del sistema. Se debiera tener cuidado
operacin. que nadie pueda tener acceso, modificar o
utilizar los activos sin autorizacin o deteccin.
10.1.2 Gestin de cambios.
Se debera separar la iniciacin de un evento
10.1.3 Segregacin de tareas. de su autorizacin. Se debera considerar la
posibilidad de colisin en el diseo de los
Control: Las tareas y reas de responsabilidad
controles.
deben segregarse para reducir la posibilidad de
que se produzcan modificaciones no autorizadas Las organizaciones pequeas pueden encontrar
o no intencionadas o usos indebidos de los difcil de lograr la segregacin de las tareas,
activos de la organizacin pero se debera aplicar el principio mientras
sea posible y practicable. Cuando es difcil de
10.1.4 Separacin de los recursos de desarrollo, segregar, se deberan considerar otros controles
prueba y operacin. como la supervisin de actividades, rastros de
10.2 Gestin de la provisin de servicios por terceros. auditora y supervisin gerencial. Es importante
que la auditora de seguridad se mantenga
10.3 Planificacin y aceptacin del sistema. independiente.
10.4 Proteccin contra cdigo malicioso y descargable.
10.5 Copias de seguridad.
10.6 Gestin de la seguridad de las redes.
10.7 Manipulacin de los soportes.
Figura 6.6.13. Ejemplo de los controles en las

Normas ISO/IEC 27001 e ISO/IEC 17799
Adems de los controles seleccionados de ISO/IEC 27001, tambin se debern

tener en cuenta los 8 controles recomendados en ISO/IEC 20000-2.
UNE-ISO/IEC 20000-2
Controles una buena prctica en gestin de la

Adems de otros controles que puedan seguridad de la informacin:
ser justificables y aconsejados en esta a) la alta direccin debera definir la
parte de la Norma ISO/IEC 20000 (por poltica de seguridad de la infor-
ejemplo: en la continuidad del servicio), macin, comunicarla a su perso-
los proveedores del servicio deberan nal y a sus clientes y asegurarse
aplicar los siguientes controles como de que se implanta eficazmente;
b) los roles y las responsabilidades e) todo el personal debe ser con-

para la gestin de la seguridad de cienciado acerca de la poltica de
la informacin se deberan definir seguridad de la informacin;
y asignar a un puesto de trabajo; f) debera haber apoyo de expertos
c) un representante del equipo de en la evaluacin de riesgos y en la
direccin (el rol puede ser desem- implementacin de los controles;
peado por un propietario que g) los cambios no deberan compro-
sea un responsable senior) debe- meter la operacin efectiva de los
ra supervisar y mantener la efica- controles;
cia de la Poltica de Seguridad de h) se debera hacer un informe de
la Informacin; los incidentes de seguridad de la
d) el personal que ejerza un rol sig- informacin siguiendo los proce-
nificativo en seguridad debera dimientos de gestin del incidente
recibir formacin en seguridad de y, tambin, se debera iniciar una
la informacin; respuesta a dichos incidentes.
En relacin al acceso de terceros u organizaciones externas (suministradores, clien-

tes externos, etc.) a los sistemas de informacin, en ISO/IEC 20000-1 se establece
claramente que debe existir un acuerdo formal que regularice los aspectos relacio-
nados con la seguridad.
UNE-ISO/IEC 20000-1
Los servicios que impliquen el acceso de organizaciones externas a los sistemas de

informacin y a los servicios, deben estar basados en un acuerdo formal que defina
todos los requisitos de seguridad necesarios.
Este mismo tema de terceros est desarrollado tambin en ISO/IEC 27001 (vase
el apartado A.6.2 Terceros) que establece como objetivo mantener la seguridad
de la informacin de la organizacin, as como la de los dispositivos de procesado
de la informacin que son objeto de acceso, tratamiento, comunicacin o gestin
por terceros.
Elaborar una declaracin de riesgos o de aplicabilidad

(SoA, Statement of Applicability)
La declaracin de riesgos o de aplicabilidad es un documento formal, aprobado por
la direccin, que proporciona un resumen de las decisiones relativas al tratamiento
de los riesgos. Una declaracin de aplicabilidad debe incluir:
Los umbrales de riesgo asumibles por la organizacin.
Los objetivos de control y los controles seleccionados y las justificaciones de
su seleccin.
Los objetivos de control y los controles actualmente implementados.
La exclusin de cualquier objetivo de control y control de ISO/IEC 27001 y
la justificacin de esta exclusin. La justificacin de las exclusiones facilita
una comprobacin cruzada para no omitir inadvertidamente ningn control.
Plan de tratamiento de riesgos (RTP, Risk Treatment Plan)

La implantacin de los controles tiene complejidad bastante diversa e implica a
muchas partes de la organizacin. Por ello, se llevar a cabo de una forma organi-
zada y controlada desde un punto centralizado y con enfoque de proyecto. El plan
de tratamiento de riesgos desempea est misin. Este plan se elabora con una
periodicidad anual y debe ser aprobado por la direccin.
Los puntos que contendr el plan sern los siguientes:
Riesgos tratados.
Objetivos de control que se deben implantar.
Controles que se deben implantar.
Plan de fechas de implantacin.
Criterios de aceptacin o rechazo.
Responsable del plan y de cada uno de sus apartados.
Recursos asignados.
Etc.
El responsable de seguridad tambin es el encargado de la modificacin del plan

de tratamiento de riesgos en el caso de que cambien las condiciones en las que se
desarrolla la actividad de la empresa u organizacin, o hubiera cambios en la evalua-

cin de riesgos, o se produzcan modificaciones en los requisitos legales u otros requi-
sitos aplicables. En estos casos, el responsable de seguridad debe comunicar a la direc-
cin las modificaciones introducidas presentando un nuevo plan para su aprobacin.
Tanto los resultados como las acciones llevadas a cabo se deben comunicar a la
direccin con carcter anual. Adicionalmente, el responsable de seguridad debe
mantener informada continuamente a la direccin, comunicndole, siempre que
crea necesario, los resultados negativos obtenidos durante el seguimiento, y el
estado de los controles y su eficacia en la reduccin de los riesgos para poder tomar
una decisin a tiempo.
Gestin de incidentes de seguridad

Un incidente de seguridad de la informacin es un suceso o una serie de sucesos
que indican una posible brecha en el blindaje proporcionado por los controles, con
una probabilidad elevada de comprometer las operaciones del negocio y amenazar
la seguridad de la informacin.
Los incidentes de seguridad deben ser tratados segn las actividades y tareas des-
critas en el proceso de gestin del incidente (vase el captulo 8). Un incidente de
seguridad tiene el mismo ciclo de vida que cualquier otro incidente: comienzo del
incidente, deteccin y registro, clasificacin y soporte inicial, asignacin y escalado,
investigacin y diagnstico, reparacin y recuperacin, y cierre del incidente.
La Norma ISO/IEC 20000-1 requiere algunas particularidades especficas relativas
a los incidentes de seguridad: cuantificar y monitorizar los diferentes tipos de inci-
dentes de seguridad, medicin de cantidades de estos y el impacto causado. Como
es habitual, las acciones de mejora se deben registrar e incorporar al plan de mejora
del servicio.
UNE-ISO/IEC 20000-1
Los incidentes de seguridad se deben comunicar y registrar tan pronto como sea
posible de acuerdo a los procedimientos de gestin del incidente. Se deben poner
en marcha procedimientos para asegurar que todos los incidentes de seguridad son
investigados, y que se toman medidas al respecto.
Se deben poner en marcha mecanismos para poder cuantificar y monitorizar los
tipos, volmenes e impacto de los incidentes y el mal funcionamiento de la seguri-
dad. Las acciones de mejora identificadas durante este proceso se deben registrar y
servir como informacin de entrada al plan de mejora del servicio.
El responsable del proceso de seguridad de la informacin debe asegurar que todos

los incidentes de seguridad son correctamente notificados, registrados, resueltos y
cerrados. Deber llevarse un registro de los incidentes de seguridad. Por ejemplo,
se pueden parametrizar las herramientas de gestin del servicio relacionadas con
los incidentes, para que se puedan notificar incidentes de seguridad, que debern
ser gestionados, en la medida de lo posible, por personal con conocimientos en
materia de seguridad, o por lo menos, seguir las pautas y recomendaciones que
dicho personal pueda indicar.
Los procedimientos de seguridad deben estar claramente identificados y marcarn
las pautas a seguir en caso de un incidente de seguridad.
Conviene tener presente que los incidentes de seguridad, adems de afectar a
la prestacin del servicio de TI, tambin pueden comprometer la imagen de la
empresa u organizacin. En algunos casos, ser necesario tratarlos como una con-
tingencia, siendo necesario activar la gestin de contingencias del proceso de ges-
tin de la continuidad.
Documentacin y registros de seguridad

Un registro de seguridad es una informacin relativa a un aspecto o un evento de
la seguridad que se almacena de una forma controlada. Son necesarios para poder
realizar las auditoras y seguimientos (auditabilidad).
El proceso de gestin de la seguridad requiere poner un nfasis especial en la for-
malizacin de la documentacin generada por el propio proceso y en registrar
formalmente ciertas actividades (medicin de la eficacia, tendencias, los accesos a la
informacin y activos, etc.).
UNE-ISO/IEC 20000-2
Documentos y registros
Los registros se deberan analizar peri- c) dar entrada de informacin a un
dicamente para proporcionar informa- plan de mejora del servicio;
cin a la direccin en cuanto a: d) tener bajo control el acceso a la
a) la eficacia de la poltica de segu- informacin, los activos y los sis-
ridad de la informacin; temas.
b) las tendencias que aparezcan en La gestin de la seguridad de la infor-
los incidentes en seguridad de la macin debera estar documentada de
informacin; una manera fiable.
En relacin a los registros, la Norma ISO/IEC 27001 establece unos controles

especficos:
Se deben realizar registros de auditoria de las actividades de los usuarios, de
las excepciones y de los eventos de seguridad de la informacin, y se deben
mantener estos registros durante un perodo acordado para servir como
prueba en investigaciones futuras y en la supervisin del control de acceso
(vase el control A.10.10.1 Registro de auditoras).
Los dispositivos de registro y la informacin de los registros se deben prote-
ger contra manipulaciones indebidas y accesos no autorizados (vase el con-
trol A.10.10.3 Proteccin de la informacin de los registros).
Se deben registrar las actividades del administrador del sistema y de la ope-
racin del sistema (vase el control A.10.10.4 Registros de administracin
y operacin).
Los fallos se deben registrar y analizar y se deben tomar las correspondientes
acciones (vase el control A.10.10.5 Registro de fallos).
La documentacin debe incluir las decisiones de la direccin junto con los registros
de las mismas, debiendo quedar constancia de que las acciones dan respuesta a las
decisiones y a las polticas adoptadas, y garantizando que dichos documentos y los
correspondientes registros estn disponibles (vase el apartado 4.3 de la Norma
UNE-ISO/IEC 27001).
La gestin de la seguridad se puede implementar como un proceso ms dentro del
sistema de gestin del servicio de TI (SGSTI) o en base a un sistema de gestin
especfico para la seguridad (SGSI). De cara a simplificar y mantener una coheren-
cia, todos los modelos de gestin relativos a TI debern implementarse bajo el
paraguas formal del sistema de gestin de la calidad definido en la Norma ISO
9001. En la figura 6.6.14 se muestra esta tendencia a la unificacin de los sistemas
de gestin en TI (vase el captulo 3).
La documentacin del SGSI debe incluir (vase el apartado 4.3 de la Norma UNE-
ISO/IEC 27001):
Las declaraciones documentadas de la poltica y de los objetivos del SGSI.
El alcance del SGSI.
Los procedimientos y mecanismos de control que soportan al SGSI.
Una descripcin de la metodologa de evaluacin de riesgos.
El informe de evaluacin de riesgos.
Tecnologas de la informacin Sistema de gestin integrado

Gestin y operacin Desarrollo de SW
SG de otras reas Gobierno Seguridad
del servicio de TI Madurez +
de la empresa SG GOB SGSI
SGSTI SG DES. SW
ISO/IEC ISO/IEC
20000 27001
Figura 6.6.14. Tendencia a la unificacin de los sistemas de gestin
El plan de tratamiento de riesgos.

Los procedimientos documentados que necesita la organizacin para asegu-
rar una correcta planificacin, operacin y control de sus procesos de seguri-
dad de la informacin, y para describir cmo medir la eficacia de los contro-
les.
Los registros requeridos por esta norma internacional.
La declaracin de aplicabilidad.
Mtricas del proceso

La gestin de la seguridad, al igual que el resto de los procesos, necesita un con-
junto de mtricas o indicadores que permitan seguir la efectividad de los controles
implantados, los niveles de seguridad alcanzados o la eficiencia del propio proceso.
Asimismo, es necesario elaborar informes que permitan realizar el seguimiento de
las acciones emprendidas y dar a conocer los resultados del proceso. Las mtricas
ms destacadas para este proceso son las siguientes.
Nmero de incidentes de seguridad ocurridos en el perodo de medicin.
Nmero de incidentes de seguridad ocurridos que ha tenido impacto legal.
Porcentaje de incidentes que son debidos a la seguridad, en relacin al total
de incidentes.
Nmero medio de incidentes de seguridad por servidor.
Coste de la inseguridad, debido a tiempos de parada del negocio a conse-

cuencia de incidentes de seguridad, lucro cesante del negocio, etc.
Coste de la seguridad, porcentaje del presupuestario dedicado a seguridad en
relacin al presupuesto total de TI.
Ratio de recursos humanos dedicados a la seguridad en relacin al total de
personal de TI.
ndice de rotacin del personal en seguridad de la informacin.
Porcentaje de ordenadores personales asegurados tcnicamente.
Porcentaje de no disponibilidad de servicios debido a incidentes de seguri-
dad de la informacin.
Nmero y porcentaje de controles de seguridad revisados en el mes.
Nmero de no conformidades relacionadas con la seguridad en auditoras y
controles internos.
Nmero de mejoras sugeridas a los controles de seguridad.
En la figura 6.6.15 se muestra un resumen de los indicadores anteriormente men-

cionados, teniendo en cuenta que no son los nicos.
Fuente: Telefnica.
Figura 6.6.15. Mtricas del proceso de seguridad de la informacin

Roles participantes en la gestin de seguridad

Como en el resto de los procesos, los roles intervinientes en la gestin de la seguri-
dad de la informacin se estructuran en dos roles; los roles propios del proceso y
los roles ajenos al proceso.
Entre los roles clave del proceso, a nivel interno, se encuentran los siguientes:
La direccin de la empresa u organizacin, cuyo representante tiene la res-
ponsabilidad de revisar y aprobar el anlisis de riesgos, declarar qu riesgos
no son aceptables por la organizacin, incluir en las revisiones del sistema
por la direccin el estudio del anlisis de riesgos, aprobar el plan de gestin
del riesgo, conocer el grado de implantacin del plan de gestin del riesgo,
incluir en las revisiones del sistema por la direccin un anlisis del plan de
gestin del riesgo implantado en el perodo anterior.
El gestor de seguridad de la informacin, responsable del funcionamiento de
todo el proceso y especficamente de:
Realizar la evaluacin de riesgos.
Presentar a la direccin el nivel de riesgo soportado por la organizacin.
Elaborar el plan de tratamiento de riesgos.
Realizar el seguimiento del plan de tratamiento de riesgos.
Informar a la direccin de la implantacin de los planes.
Analizar los resultados de la implantacin de los controles y los planes.
El comit de seguridad, como mecanismo asesor al responsable de seguridad

y medio para la participacin de todas las reas en los temas esenciales relati-
vos a la seguridad.
El administrador de soporte del proceso de seguridad, que contribuye a que
las actividades del proceso funcionen, es responsable de coordinar y apoyar
la elaboracin del anlisis de riesgos, presentar al responsable de seguridad el
nivel de riesgo soportado por la organizacin, coordinar y apoyar la elabora-
cin del plan de tratamiento de riesgos, coordinar y realizar el seguimiento
del plan de gestin del riesgo, informar al responsable de seguridad de la
implantacin del plan de gestin del riesgo y coordinar y apoyar la implanta-
cin del plan de gestin del riesgo.
Este proceso se apoya tambin en otros roles relevantes para el mismo y que son
ajenos al proceso:
El responsable de seguridad general de la organizacin, a quin habr que

informar de los temas especficos de seguridad de la informacin.
cumplan los niveles pactados, aporta la relacin con la direccin de la
empresa y las principales directrices para la seguridad de la informacin, pro-
porcionan los presupuestos, presenta al comit de direccin la evaluacin de
riesgos elaborada, el plan de tratamiento de riesgos y la declaracin de ries-
gos, con el fin de que sean aprobados convenientemente y se otorgue el res-
paldo adecuado a las medidas tcnicas y organizativas necesarias para miti-
gar el riesgo.
El responsable de la gestin de la continuidad de los servicios de TI, pues los
dos procesos tienen muchos puntos en comn, especialmente en la evalua-
cin de riesgos, cada uno desde la perspectiva de su proceso.
El gestor de las relaciones con el negocio. Para llevar la relacin con las reas
cliente de una forma centralizada, la gestin de la seguridad tomar los
requisitos del negocio y presentar los informes. El gestor de nivel de servi-
cio velar por el cumplimiento de los requisitos de seguridad y por atender
las expectativas de los clientes respecto a esta materia.
El propietario del modelo de gestin (SGSTI y tambin del SGSI), que
acta como propietario de este proceso (process owner), define las actividades
del proceso y se encarga de la mejora continua del mismo. Este propietario
tambin debera desempear las funciones de propietario del modelo de gestin
de la seguridad SGSI.
En la figura 6.6.16 se muestran los roles principales del proceso.
Resumen
El incremento continuo de las amenazas hace que la seguridad de la informacin
sea cada vez un aspecto ms crtico en las empresas. La red Internet es el cauce por
el que llegan la mayora de ellas. Si las amenazas han aumentado por esta va, las
vulnerabilidades tambin: la conectividad desde cualquier lugar, la proliferacin de
aparatos tecnolgicos en el mercado de consumo en la empresa, la gran capacidad
de los dispositivos de bolsillo en la empresa, etc.
La seguridad se ha convertido en los cimientos sobre los que se sustenta la infor-
macin de la empresa, cimientos que hay que cuidar continuamente para que no
pierdan su solidez.
Roles del proceso
Responsable de la
gestin del servicio
Direccin
SGSTI
SGSI
Responsable
de seguridad
Propietario del modelo

(SGSTI y SGSI)
Comit de seguridad
Administrador y
soporte del proceso
reas tcnicas de seguridad
Gestor continuidad TI
Figura 6.6.16. Roles que intervienen en el proceso de gestin

de la seguridad de la informacin
El marco normativo internacional pone foco en la gestin de la seguridad apor-

tando un conjunto de requisitos y buenas prcticas que ayudan a las empresas a
enfocar su implantacin. Resulta esencial utilizar la normativa existente. La Norma
ISO/IEC 27001 aporta un conjunto de actividades y buenos controles para mejo-
rar la seguridad, mientras que ISO/IEC 20000 integra la gestin de la seguridad
con el resto de los procesos de gestin de los servicios de TI.
La implementacin de la gestin de la seguridad de la informacin se articula en
torno a un proceso especfico, que permite controlar la seguridad en la empresa y
sus riesgos asociados. Este proceso gestiona el mantenimiento de unos niveles de
seguridad adecuados, tanto en la prestacin de los servicios de TI, como para el
control de los activos de informacin de la organizacin.
Los principales elementos de la gestin de la seguridad son:

La poltica de seguridad.
El responsable de seguridad.
El comit de seguridad.
La evaluacin de riesgos.
Los objetivos de control y los controles.
La declaracin de riesgos o declaracin de aplicabilidad.
El plan de tratamiento de riesgos.
La gestin de incidentes de seguridad.
Los registros de seguridad.
Beneficios
Entre los beneficios ms relevantes que proporciona la gestin de la seguridad de la
informacin destacan los siguientes.
Protege y aumenta la robustez y seguridad de los sistemas de informacin,
realizando un tratamiento adecuado de los riesgos, reduciendo el riesgo de
sustraccin o prdida de informacin esencial.
Proporciona confianza a todas las partes. A la direccin porque sus activos
estn mejor protegidos, al mercado porque son ms robustos los sistemas, y
al departamento de TI porque le permite cumplir las exigencias de la direccin.
Asegura que los incidentes de seguridad de la informacin son correcta-
mente gestionados, reduciendo su impacto en el negocio.
Establece auditoras de seguridad con regularidad, que comprueban la ade-
cuacin de las medidas de seguridad implantadas.
Aporta informacin a la direccin sobre el estado de seguridad de la empresa
u organizacin, de cara a adoptar las medidas que se consideren oportunas.
Fortalecimiento de la imagen ante el mercado y confianza de los clientes en
una organizacin que apuesta por la seguridad de la informacin.
Ahorro de costes por evitar incidentes de seguridad, en primas de seguros,
por sanciones derivadas de incumplimientos legales, etc.
Cmo se realiza la gestin de la seguridad de la informacin en su
empresa?
Est la direccin de su empresa implicada en la gestin de la seguri-
dad de la informacin?
La gestin de la seguridad se trata en su organizacin como un
mbito independiente o de forma integrada con los otros procesos de
gestin de los servicios de TI?
3 Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
7 Procesos de
Captulo 7
relaciones
7.1. Generalidades
7.2. Gestin de las relaciones con el negocio
7.3. Gestin de suministradores


7. Procesos de relaciones 451
Con el fin de garantizar que el proveedor de TI trabaje alineado con las necesida-
des de la empresa, las Normas ISO/IEC 20000 establecen los procesos de relacio-
nes. Regulan las relaciones en los dos extremos de la cadena de provisin de TI. Por
una parte se definen las relaciones con el negocio y, por otra, las relaciones con los
suministradores.
La misin de la gestin de las relaciones con el negocio es garantizar que se crean,
mantienen y mejoran continuamente los servicios de TI que necesita la empresa. Al
igual que en ITIL, en ISO/IEC 20000 el negocio est representado por la figura
del cliente. Se entiende como cliente a la persona, rea o reas de la empresa que
especifican los servicios de TI que necesitan y acuerdan los SLA. Para ello, el pro-
ceso de gestin de las relaciones con el negocio servir de interlocucin nico entre
el cliente y la organizacin de TI, para la identificacin de necesidades y la provi-
sin de los servicios. Cuenta con la colaboracin continua de la gestin de nivel de
servicio y de otros procesos, para tratar de encontrar el balance correcto entre la
demanda del cliente, la provisin de los servicios, el coste de los mismos y la satis-
faccin del cliente.
Por otra parte, hay que tener presente que los servicios que TI ofrece se construyen
formando un puzzle de piezas tecnolgicas, adecuadamente integradas y gestio-
nadas. Para mantener en marcha este puzzle de tecnologas, la organizacin de TI
necesita suministradores diversos: de hardware, de productos software, integrado-
res, consultores, empresas de servicios, etc. La gestin adecuada de dichos suminis-
tradores es tambin esencial para poder garantizar los niveles de servicio requeridos.
En este captulo se presentan las mejores prcticas para el xito en la gestin de las
fronteras de la organizacin de TI: con el negocio y con los suministradores.
7. Procesos de relaciones
7.1. Generalidades 453
7.1. Generalidades
Figura 7.1.1. Los procesos de relacin en ISO/IEC 20000
Con frecuencia se oye hablar de la importancia de una gestin adecuada de las rela-
ciones, especialmente en el mbito de TI. Pero, en qu consiste la gestin de una
relacin?, aunque esta disciplina parece atractiva, no es fcil concretar su contenido
y conseguir con ello un aporte real a la mejora del servicio de TI.
En general, se puede decir que la gestin de una relacin es aquella disciplina que
establece el mtodo para que la interaccin entre dos partes sea eficaz, ayuda a que
transcurra con las mnimas fricciones y contribuye a que sea duradera (vase la
figura 7.1.1). Los mecanismos habituales que permiten regular y organizar una
relacin compleja son los siguientes:
El establecimiento de los objetivos principales que se quieren conseguir con
la relacin.
La definicin de los diversos interlocutores por cada parte, los perfiles perso-
nales y las habilidades necesarias.
La utilizacin de un marco, reglas y lenguaje comn aceptado por ambas
partes.
Definicin y regulacin de los momentos de interaccin, estableciendo su

periodicidad, los medios, los mecanismos y los documentos que recojan los
acuerdos. Todo ello, mediante comits, grupos de trabajo, traspaso de peti-
ciones, integracin de herramientas, etc.
El establecimiento de los mecanismos de seguimiento, midiendo la eficacia y
la satisfaccin con la relacin para poder mejorarla.
El establecimiento de los procedimientos y los mecanismos de apoyo a una
relacin formalizada: convocatorias, actas, peticiones, informes, mtricas,
reclamaciones, cobros, etc.
Los principales actores en los procesos de relacin son los clientes de los servi-
cios (tanto internos de otras reas de la empresa, como clientes comerciales rea-
les), el proveedor del servicio de TI (organizacin de TI o rea de TI a la que
se est aplicando estas normas) y los suministradores (que proporcionan bienes
o servicios a la organizacin de TI, que pueden ser internos de la empresa o
externos).
UNE-ISO/IEC 20000-1
Los procesos de relacin describen los aspectos relacionados con la gestin de

suministradores y con la gestin de las relaciones con el negocio.
UNE-ISO/IEC 20000-2
Esta norma se dirige hacia el rol de un de servicio o de soporte interno que son
proveedor del servicio, el cual cumple a menudo designados como acuerdos
un papel entre los suministradores, que de nivel operacional.
proporcionan bienes o servicios a dicho
El proveedor del servicio juega un papel
proveedor del servicio, y los clientes, que
dentro de la cadena de suministro, en la
reciben los servicios.
cual cada eslabn debera aadir valor,
Tanto los suministradores, como los de forma que el proveedor del servicio
clientes pueden ser internos y externos que recibe bienes o servicios proceden-
a la organizacin del proveedor del tes del suministrador y entrega un servi-
servicio. cio mejorado al cliente.
Las relaciones externas se formalizarn A modo de aclaracin, dentro de esta
mediante contratos. Las relaciones inter- seccin el trmino proveedor del servicio
nas se formalizarn mediante acuerdos se utiliza siempre para describir la orga-
7.1. Generalidades 455
nizacin a la que se dirige este docu- b) entienden las capacidades y limi-

mento, independientemente del papel, o taciones;
sentido en la cadena, que tiene en el c) entienden las responsabilidades y
proceso que se describe. las obligaciones.
En la prctica, las relaciones raramente Estos procesos tambin deberan asegu-
son as de simples, sino que implican rar que los niveles de satisfaccin del
mltiples participantes, asumiendo cliente son apropiados y que se comu-
papeles, tanto como suministradores, nican y entienden las necesidades futu-
como clientes y con conexiones de ras del negocio.
negocio entre muchos de ellos de
forma directa o bien mediante el prove- El alcance, los roles y las responsabilida-
edor del servicio. des de las relaciones con el negocio y
las relaciones con los suministradores
Los procesos de relacin deberan ase- deberan definirse y acordarse. Esto
gurar que todas las partes: debera incluir la identificacin de todos
a) entienden y satisfacen las necesi- los grupos de inters, los contactos y los
dades del negocio; medios y frecuencia de la comunicacin.
Si se echa una mirada a ITIL v2, se aprecia que no establece ningn proceso espe-
cfico que describa la relacin con los suministradores, aunque hace mucho hinca-
pi en que los contratos con suministradores (contratos de soporte, Underpinning
Contracts o UC) respalden los compromisos del nivel de servicio que TI asume con
sus clientes. En cambio, en ITIL v3 el libro Diseo del Servicio define especfica-
mente un proceso de gestin de suministradores.
En el marco para el gobierno y auditora de TI (COBIT) de estos temas se encuen-
tran referencias, indicadores y controles centrados principalmente en el control de
las adquisiciones y el gobierno de TI. No trata especficamente las relaciones con el
negocio ni las relaciones con los suministradores bajo el concepto de proceso.
En el mbito del desarrollo de software, las relaciones tanto con el cliente como con
los suministradores de desarrollo, estn bastante detalladas en el modelo CMMI. Asi-
mismo, la universidad Carnegie Mellon tambin ha desarrollado el marco eSCM-SP
(eSourcing Capability Model for Service Providers) formado por 84 prcticas especficas
para la gestin de suministradores y el ciclo de vida del sourcing en TI.
Adems, existen otros marcos de mejores prcticas en los que se trata la mejora de
las relaciones con los suministradores, como por ejemplo, el modelo ISPL (Infor-
mation Services Procurement Library1), que es un compendio europeo de mejores
1
Vase http://projekte.fast.de/ISPL/.
prcticas para la provisin y prestacin de proyectos y servicios TI. ISPL fue publi-
cado en 1999 por un consorcio de 5 organizaciones europeas dentro del programa
SPRITE-S2 de la Comisin Europea y se bas en la experiencia de ms de 200 pro-
cesos de compra reales en TI. Trata la definicin de una estrategia de aprovisiona-
miento de servicios (sourcing), as como las etapas posteriores: peticiones de oferta,
establecimiento del contrato, planificacin de la provisin y seguimiento de la eje-
cucin. ISPL hoy est en desuso, por lo que la llegada del proceso en ITIL v3 es
bien acogida por el mercado.
Otros modelos sectoriales tambin tratan el entorno de la gestin de suministrado-
res, como es el caso del modelo eTOM para el sector de las telecomunicaciones,
que contempla procesos como por ejemplo, la gestin de partners/suministradores
o la gestin de la cadena de suministro.
7.2. Gestin de las relaciones con el negocio 457
7.2. Gestin de las relaciones con el negocio
Figura 7.2.1. Actividades del proceso de gestin de las relaciones con el negocio
Las empresas e instituciones tienen cada vez una mayor dependencia de las tecnolo-
gas de la informacin. Los departamentos de TI, y las actividades que desarrollan,
han sido vistos tradicionalmente como una carga y un coste para el negocio, infrauti-
lizndose el potencial de la tecnologa para ponerse en primera lnea, aportando ideas
y abriendo nuevas oportunidades para la empresa. Para que las tecnologas de la
informacin estn alineadas con las necesidades de la empresa, es necesario instru-
mentar una va de comunicacin permanente, regulada y eficaz entre TI y el negocio.
La gestin de las relaciones con el negocio asegura que la comunicacin entre TI y
sus clientes sea clara y fluida (vase la figura 7.2.1). Se entiende como cliente a
las reas internas de la empresa o a las unidades externas que especifican y contra-
tan los servicios de TI, diferencindolo as de la figura del usuario que es la per-
sona que utiliza los servicios. Igual que el centro de atencin al usuario (service desk)
es el punto nico de contacto entre TI y la comunidad de usuarios, el proceso de
gestin de las relaciones con el negocio se convierte en canal nico de la comunica-
cin reglada entre TI y el negocio.
Este proceso se preocupa de dar una respuesta adecuada a las demandas del cliente,
actuando de interfaz entre el negocio y las reas de TI. Vela por la satisfaccin del
cliente atendiendo sus reclamaciones y revisando peridicamente los acuerdos o

contratos establecidos.
Gran parte de las relaciones con el negocio se centralizan en una figura denomi-
nada habitualmente gestor del cliente. Con cierta frecuencia, se encuentra polari-
zada nicamente hacia los aspectos relacionados con el desarrollo de las aplicacio-
nes, descuidando todo lo relativo al seguimiento de los servicios en explotacin. El
gestor del cliente debe tratar con el negocio dos aspectos: la provisin de la funcio-
nalidad requerida en forma de servicios (desarrollo) y el seguimiento de los servi-
cios ya operativos en explotacin regular (produccin).
La gestin de las relaciones con el negocio aporta una sistemtica de trabajo que
facilita y hace ms eficaz la relacin. Ayuda a que TI ponga el foco en la provisin
de los servicios que realmente necesita la empresa.
El proceso de gestin de las relaciones con el negocio saca a TI de su ensimisma-
miento tecnolgico para trabajar directamente en lo que necesita el negocio.
Refuerza y formaliza los lazos entre TI y sus clientes. Los servicios prestados se
revisan y contrastan con los clientes, se mide su satisfaccin y se impulsan acciones
de mejora. En la figura 7.2.2 se presenta un esquema introductorio al proceso.
Proceso de gestin de las Qu aporta:

relaciones con el negocio El objetivo de TI es la satisfaccin
del cliente.
Definicin: Saca a TI de su mundo tecnolgico.

Fuerza a TI a trabajar para lo que
Proceso que regula las relaciones
necesita el negocio.
entre el departamento de TI y sus
reas clientes. Las relaciones con las reas cliente se
gestionan con mayor profesionalidad.
Los servicios prestados se revisan de
Objetivo: forma regular con los clientes de TI.
Establecer y mantener una buena Se formalizan las reclamaciones.
relacin entre el proveedor del
Se mide la satisfaccin del cliente.
servicio y el cliente, basndose en
el entendimiento del cliente y de Se impulsan acciones de mejora del
los fundamentos de su negocio. servicio.
Figura 7.2.2. Introduccin al proceso de gestin de las relaciones

con el negocio
El objetivo de la gestin de las relaciones con el negocio es establecer y mantener

unas buenas relaciones entre los clientes y TI mediante el entendimiento entre
ambos. Este entendimiento de las necesidades del negocio se debe traducir en la
prestacin de servicios cumpliendo los niveles de servicio acordados y siguiendo e
informando acerca del rendimiento del servicio.
Para ello, el proceso de gestin de las relaciones con el negocio servir de interlocu-
cin nica entre el cliente y la organizacin de TI. Con la colaboracin continua de
la gestin de nivel de servicio, tratar de encontrar el balance correcto entre la
demanda del cliente, la provisin del servicio, el coste y la satisfaccin del cliente.
La gestin de las relaciones con el negocio constituye el nico punto de contacto
entre el negocio o cliente y la organizacin de TI involucrada en la prestacin de
los servicios. En la figura 7.2.3 se muestra el papel de interlocutor con las reas
cliente de este proceso.
Fuente: Telefnica.
Figura 7.2.3. El proceso de relaciones con el negocio enmarcado

entre el negocio y el resto de la organizacin de TI
Para el desarrollo con xito de la misin de este proceso es necesario que el perso-
nal involucrado en l, por parte de TI, conozca a fondo la naturaleza del propio
negocio. Pero tambin es imprescindible que estos profesionales conozcan perfec-
tamente a TI y sus capacidades, para saber qu puede ofrecer y en qu condiciones.
El espritu de servicio al cliente es otro de los valores a buscar y potenciar entre los
participantes en este proceso, pero no es un requisito exclusivo del mismo, sino que
debe hacerse extensivo a toda la organizacin de TI. El rigor en la relacin facili-
tar a TI alinearse con el negocio, tomando nota de las necesidades, formalizndo-
las en requisitos, redactando las actas de las mismas, realizando un seguimiento del
cliente e impulsando en el resto de TI al cumplimiento de las demandas. As, estos
cuatro pilares en los que se sustenta este proceso se muestran en la figura 7.2.4.
Figura 7.2.4. Bases de la gestin de las relaciones con el negocio
Los mecanismos principales que facilitan el cumplimiento de los objetivos de este

proceso son: los acuerdos de nivel de servicio con el cliente (SLA) y el catlogo de
servicios de TI. Alrededor de estos dos elementos se desencadena la transformacin
de la organizacin de TI, orientndose hacia el servicio y el cliente. En la figura 7.2.5
se muestra los principales componentes del proceso.
Los componentes principales que se emplean en el proceso de gestin de las rela-
ciones con el negocio son se detallan a continuacin:
Acuerdo de nivel de servicio (SLA). Es un documento que recopila los compro-
misos acordados entre el cliente y el proveedor de servicios de TI relativos a las
condiciones de prestacin o explotacin del servicio requerido. El SLA lo gestiona
y define el proceso de gestin de nivel de servicio (vase el apartado 6.1).
Estrategia del negocio

Convertir
Estrategia de TI
necesidades en SLR
requisitos de servicio
Catlogo Necesidades
de servicios Servicios nuevos
o modificaciones
Cli
SLA: ent
e
Acuerdo PDCA
de nivel de SGSTI
servicio
TI
Informes Mejoras
del servicio
Reclamaciones Programa de mejora
al servicio del servicio (SIP)
Reuniones cliente-TI,
Encuestas y entrevistas
demanda y revisin
de satisfaccin
del servicio
Figura 7.2.5. Componentes ms destacados del proceso
El catlogo de servicios. Se utiliza para poner claridad en toda la relacin con el

cliente, pues esta relacin tiene como eje central la prestacin de los servicios pre-
definidos en el catlogo. El catlogo lo gestiona y define el proceso de gestin de
nivel de servicio (vase el apartado 6.1).
Encuestas y entrevistas de satisfaccin. Medio para conocer la valoracin y per-
cepcin subjetiva del cliente sobre los servicios de TI.
Estrategia del negocio y de TI. La estrategia y tendencias del negocio son un ele-
mento que utiliza las relaciones del negocio para identificar qu necesidades del
cliente estn alineadas con esta estrategia y cules no. Tambin la estrategia de evo-
lucin de TI debe ser tenida en cuenta para enfocar las soluciones en la misma
direccin hacia la que camina TI.
Informes del servicio. El proceso trata con el cliente el tipo de informes del servicio
que se utilizarn para el seguimiento del cumplimiento de los niveles de servicio acor-
dados. Los informes los gestiona el proceso de generacin de informes de servicio
(vase el apartado 6.2).
Las necesidades del cliente. El cliente manifiesta sus necesidades, alineadas o no

con la estrategia del negocio y encajadas o no con el catlogo. El proceso de ges-
tin de las relaciones con el negocio debe tratar con el cliente el encaje de las nece-
sidades concretas manifestadas con la estrategia y con el catlogo.
Nuevos servicios o modificaciones. Las necesidades del cliente no cubiertas por
servicios del catlogo dan origen a la creacin de nuevos servicios o a las modifica-
cin de los existentes (vase el captulo 5).
Propuestas de mejora. Realizadas por el proceso en funcin de los defectos
encontrados en la prestacin de los servicios de TI. Se encaminan hacia el plan de
mejora de los servicios (SIP) o de la gestin del servicio (plan de mejora unifi-
cado).
Requisitos del servicio (SLR, Service Level Requirements). Documento que
estructura y formaliza las necesidades del cliente. Se escribe en el lenguaje y termi-
nologa del propio cliente. Es un documento que elabora este proceso en colabora-
cin con el proceso de gestin de nivel de servicio.
Reuniones cliente-TI. Las reuniones entre ambas partes son el instrumento prin-
cipal del proceso de gestin de las relaciones con el negocio para gestionar la
demanda de soluciones por parte del cliente y la realizacin de un seguimiento con-
junto de la prestacin de los servicios en curso.
Reclamaciones al servicio. Instrumento que formaliza el malestar y disconformi-
dad del cliente con el servicio o la atencin prestada por TI. Es una pieza clave para
velar por la subsanacin de los errores de TI y supone una oportunidad para me-
jorar la satisfaccin del cliente.
Hay que tener en cuenta que el proceso de relacin con el negocio colabora muy
estrechamente con el proceso de gestin de nivel de servicio. El primero gestio-
nando la relacin de TI con el cliente y el segundo se responsabiliza del cumpli-
miento, por parte de la organizacin de TI, de los compromisos pactados con los
clientes.
En lo relativo al tratamiento que se hace a las relaciones con el negocio, en ITIL v2
y v3 se han distribuido las funciones entre la definicin de la estrategia y la gestin
de nivel de servicio:
En ITIL v2 las relaciones con el negocio se tratan en el libro Business Perspec-
tive, desde un punto de vista de la estrategia y tambin en el libro Soporte de
Servicio en el proceso de gestin de nivel de servicio.
En ITIL v3, de forma similar, las relaciones con el negocio se tratan en el
proceso de gestin de la demanda (libro Estrategia del Servicio) y en el pro-
ceso de gestin de nivel de servicio (libro Diseo del Servicio).
En la figura 7.2.6 se muestra una comparativa entre el tratamiento de las relaciones

con el negocio en los diferentes marcos de gestin de TI.
Procesos en ISO/IEC 20000 Proceso en ITIL v3 Proceso en ITIL v2
Libro Estrategia del Servicio:

Gestin relacin con el negocio Libro Business Perspective:
Generacin de la estrategia
Gestin de la demanda Gestin relacin con
el negocio
Gestin del portfolio de servicios
Libro Provisin de Servicio:
Gestin Generacin Libro Diseo del Servicio:
de nivel de de informes Gestin de nivel de
Gestin del catlogo de servicios servicio
servicio del servicio
Figura 7.2.6. Tratamiento de las relaciones con el negocio o cliente

en los diferentes marcos de gestin de TI

El proceso de gestin de las relaciones con el negocio se encarga del dilogo con el
cliente para atender sus necesidades, utilizando la oferta estndar de TI definida en
el catlogo de servicios. El gestor o los gestores de clientes deben escuchar al cliente
y tomar nota de sus necesidades. Si stas encajasen con la oferta estndar de servi-
cios (catlogo) se realizar una peticin de servicio, en caso contrario, se analizar
la posibilidad de proveerlas.
Por lo tanto, el proceso es el desencadenante del conjunto de actividades para la
satisfaccin de las demandas del cliente, pero tambin el punto final de esta cadena
de provisin, para terminar comprobando con el cliente los resultados. Las entra-
das, actividades y salidas del proceso se muestran en la figura 7.2.7.
Como ya se ha sealado anteriormente, las entradas que activan el proceso son las
solicitudes expresas del cliente de nuevas necesidades, de informacin, las peticio-
nes o acuerdos obtenidos en las reuniones peridicas de seguimiento entre TI y el
cliente, y las reclamaciones o quejas comunicadas por el cliente a TI. Las entradas
de soporte secundarias utilizadas para el desempeo del proceso son la estrategia
del negocio, que aporta informacin sobre la evolucin futura del mismo; la estra-
tegia de TI, que permite proponer soluciones alienadas con el resto de la organiza-
cin; el catlogo de servicios, en el que se refleja el mbito de trabajo de TI; los
SLA existentes; el plan de mejora del servicio; los informes del servicio; etc.
En cuanto a la actividad realizada por este proceso, es muy similar a una funcin
comercial, realizando actividades propias o participando en su rol de canal de
Desencadenantes 3 Identificacin de los clientes Salidas principales:

del proceso: 3 Seguimiento comercial de los Requisitos nuevos o
Solicitudes del cliente. clientes y de los compromisos. evolucin de servicios
Reuniones peridicas de 3 Contrastar necesidades con el (SLR).
seguimiento del cliente. catlogo de servicios de TI. SLA firmado.
Reclamaciones de los 3 Definir los requisitos de nuevos Informes seguimiento
clientes. servicios o evolucin de los clientes.
existentes (SLR). Resultados encuesta
3 Aprobacin por gestin del satisfaccin cliente.
Estrategia del negocio. cambio. Propuestas de mejora.
Estrategia de TI. 3 Propuestas de servicio y de SLA.
Catlogo de servicios. Salidas secundarias:
3 Negociacin del SLA.
SLA anteriores. Informes resolucin
3 Seguimiento de la provisin del
reclamaciones.
Plan de mejora de la servicio.
gestin del servicio. Actas de las reuniones.
3 Revisiones del servicio prestado.
Informes del servicio. 3 Gestin de reclamaciones al
servicio.
3 Medicin de la satisfaccin del
cliente.
3 Generacin de propuestas de
mejora, de los servicios al Plan
de mejora del servicio (SIP) y a
los otros procesos.
3 Supervisin funcionamiento
del proceso. Mejora del
propio proceso.
comunicacin con el cliente para los otros procesos. Se conforma as como un

punto nico de relacin con las reas cliente de TI. El proceso interviene en las pri-
meras etapas de la creacin de servicios (vase el captulo 5) y engrana con la ges-
tin de nivel de servicio, tanto para la creacin como para la prestacin de los mis-
mos (vase el apartado 6.1). Las principales actividades del proceso son:
Identificacin de los clientes. En la implementacin de este proceso, una
de las primeras actividades es la identificacin de las reas cliente y conseguir
que estas designen a sus representantes legtimos y reconocidos interna-
mente. Con los clientes identificados se podr determinar la carga de trabajo
necesaria y el inicio de la gestin de estas relaciones. Este aspecto est reco-

gido de forma expresa en ISO/IEC 20000-1:
UNE-ISO/IEC 20000-1
El proveedor del servicio debe identificar y documentar quienes son los actores prin-
cipales y los clientes de los servicios.
Seguimiento comercial de los clientes y de los compromisos. Es una

funcin permanente, en la que la gestin de las relaciones con el negocio se
convierte en un punto de relacin nico de TI con el cliente.
Contrastar las necesidades con el catlogo de servicios de TI. Las necesi-
dades del cliente pueden venir motivadas directamente por las necesidades
del negocio, o bien por otras causas, como por ejemplo, normas de obligado
cumplimiento, polticas de la organizacin, imperativos legales del sector,
etc. Las necesidades expresadas por el cliente se contrastan con la oferta de
servicios contenida en el catlogo de servicios. Si las necesidades encajan en
el catlogo, se activa el procedimiento previsto de provisin del servicio
determinado.
Definir los requisitos de los nuevos servicios o evolucin de los existen-
tes (SLR). Si el catlogo de servicios no es capaz de cubrir las necesidades
planteadas, se toman los requisitos del servicio (formalizados en el docu-
mento SLR) para analizar si se pueden cumplir por TI, mediante un nuevo
servicio o la evolucin de uno existente. La intervencin de la gestin de
nivel de servicio en este punto es fundamental para ayudar la identificacin
de los nuevos servicios o mejora de los ya existentes. El gestor de relaciones
con el negocio debe realizar la toma de requisitos de forma estructurada,
empleando el lenguaje del cliente y evitando la terminologa tcnica.
Propuestas de servicio y de SLA. Una vez determinadas las distintas opcio-
nes posibles para satisfacer los requisitos del cliente, teniendo en cuenta la
relacin calidad-precio, se establece una propuesta de servicio que describe
la solucin por parte de TI en trminos de objetivos, alcance, funcionalidad,
estimacin de plazos de disponibilidad, esfuerzo y costes asociados. Lo
lgico es que las propuestas de servicio se hayan previsto en la cartera de pro-
yectos anuales y se disponga de un presupuesto asignado. Si no es as, porque
la necesidad de negocio no se ha podido prever, se deber encajar en la car-
tera de proyectos actual y en los presupuestos en curso, o bien planificarla
para ms adelante.
La propuesta de servicio, adems de la solucin propuesta, debe recoger los

indicadores y mtricas de gestin, as como los mecanismos necesarios para
la revisin del servicio, control, seguimiento y evaluacin del cumplimiento
de los niveles de servicio acordados. Antes de proponer estos compromisos
es necesario verificar, a travs de la gestin de nivel de servicio, que la orga-
nizacin de TI puede cumplirlos y que cuenta con los medios de monitoriza-
cin necesarios para obtener las mtricas acordadas.
La propuesta de servicio proporciona la informacin necesaria para elaborar
un borrador de acuerdo de nivel de servicio (SLA) para revisar y negociar
con el cliente como respuesta a su demanda. El contenido de este documento
se muestra en la figura 7.2.8.
Primer borrador de SLA
Funcionalidad.
Seguridad y continuidad.
Estimacin de plazos de provisin y entrega.
Estimacin de costes asociados.
Indicadores y mtricas de gestin.
Mecanismos de control y seguimiento de los
niveles de servicio acordados.
Fuente: Telefnica.
Figura 7.2.8. Ejemplo de estructura para el primer borrador de SLA
A continuacin, el proceso de gestin de nivel de servicio genera un docu-

mento que describe la relacin entre la funcionalidad requerida por el cliente
y la solucin tecnolgica necesaria para implementarla. Este documento se
denomina hoja especificaciones del servicio (SS, Spec Sheet). Es un docu-
mento interno de TI y describe los requisitos tcnicos que son necesarios
para la provisin y entrega del servicio.
Antes de someter la propuesta de servicio a su estudio, a efectos de aproba-

cin preliminar, el gestor del nivel de servicio debe cerciorarse de que TI
puede cumplir los compromisos, verificando los acuerdos de nivel operativo
(OLA) internos con el resto de reas de la organizacin de TI involucradas
en la prestacin del servicio y los contratos de soporte (UC) con los sumi-
nistradores de servicios externos necesarios.
Aprobacin por la gestin del cambio. La propuesta de servicio debe ser apro-
bada por el proceso de gestin del cambio, de tal forma que nadie en TI incor-
pore un nuevo servicio o se proponga evolucionar uno existente sin la aproba-
cin de este proceso, que garantiza la cohesin y estabilidad de los servicios.
Tambin se acotan los mrgenes entre los que deben oscilar los niveles de servicio
a negociar con el cliente y se encaja en la planificacin general de los proyectos y
en la lista de cambios (FSC, Forward Schedule of Change, vase el apartado 9.2).
Negociacin y aprobacin SLA. Autorizado por la gestin del cambio, el
gestor de relaciones con el negocio, inicia un ciclo de negociaciones y revi-
siones con el cliente sobre los trminos y condiciones del servicio a prestar
por la organizacin de TI. En esta actividad se acuerdan los plazos y funcio-
nalidades para la creacin (plan de proyecto) y las condiciones de prestacin
(SLA para la explotacin).
Una vez que el servicio es aprobado por el cliente y el SLA formalizado, se
ponen en marcha, bajo la supervisin de la gestin del nivel servicio y, con la
ayuda de la gestin del cambio, las actividades necesarias para la provisin
y entrega al cliente del servicio demandado. En el apartado 6.1 del captulo 6
se detallan el resto de actividades.
Seguimiento de la provisin del servicio. Durante todo el perodo en el
que se est desarrollando el servicio, la gestin de las relaciones con el nego-
cio mantiene informado al cliente y gestiona las reuniones de validacin que
sean necesarias.
Revisiones del servicio prestado. Una vez que el servicio se ha puesto en
explotacin, este proceso mantiene reuniones con el cliente para informarle
y realizar un seguimiento de los niveles de servicio que se estn alcanzando.
Gestin de reclamaciones al servicio. Es importante instrumentar un
mecanismo formal por el cual el cliente pueda manifestar su disconformidad
con algn aspecto de los servicios prestados o con el comportamiento de TI
(ms adelante se trata este tema).
Medicin de la satisfaccin del cliente. Al igual que en el mundo comer-
cial, se debe medir la satisfaccin del cliente, mediante encuestas o entrevis-
tas (ms adelante se trata tambin este tema).
Generacin de propuestas de mejora. La relacin con el cliente, las recla-

maciones y las encuestas de satisfaccin llevan al gestor de las relaciones con
el negocio a identificar acciones de mejora de los servicios (que comunicar
a la gestin de nivel de servicio) para su incorporacin al SIP (programa de
mejora del servicio), y oportunidades de mejora de los otros procesos, que
comunicar al gestor correspondiente.
Supervisin y mejora del propio proceso. Como en todos los procesos de
ISO/IEC 20000, cada proceso debe realizar su propia actividad de mejora
continua, en este caso identificando puntos que redunden en una mayor
satisfaccin del cliente. Las mejoras identificadas se comunican al plan de
mejora de la gestin del servicio (vase el captulo 4).
Los resultados o salidas principales del proceso de relaciones con el negocio son los
requisitos de servicio acordados con el cliente, los SLA firmados, los informes de
seguimiento entregados al cliente, los resultados de las encuestas de satisfaccin al
cliente y las propuestas de mejora. Otras salidas del proceso son, por ejemplo, los
informes emitidos sobre cmo se han resuelto las reclamaciones, las actas de las
reuniones con el cliente, etc.
Interrelacin entre relaciones con el negocio y gestin

Los mbitos de actuacin de la gestin de las relaciones con el negocio y de la ges-
tin de nivel de servicio son complementarios y perfectamente engranados para
posibilitar dos temas clave: el xito en la identificacin de las necesidades del cliente
y su prestacin con los niveles pactados. La gestin de la relacin con el negocio se
encarga de todo lo relativo a la relacin entre TI y el cliente, se podra decir que
lleva las relaciones comerciales de TI.
En cambio, la gestin de nivel de servicio desempea una funcin ms centrada en
organizar los servicios, se responsabiliza de su provisin y controla que TI cumple
los compromisos pactados. As, se encarga de identificar, catalogar y documentar
los servicios, describiendo claramente los elementos que los integran para comple-
tar el catlogo de servicios. Tambin debe capturar el grado de colaboracin entre
las distintas reas de la organizacin de TI e identificar todos los actores involucra-
dos en la provisin del servicio. Colabora en la identificacin de nuevos servicios y
lleva el programa de mejora de los servicios (SIP) ya existentes.
En la figura 7.2.9 se muestra el engranaje entre las actividades de estos dos proce-
sos en el ciclo de creacin de un servicio (vase tambin el captulo 5).
Figura 7.2.9. Distribucin de actividades entre la gestin de nivel de servicio

y la gestin de las relaciones con el negocio en ISO/IEC 20000
Requisitos de servicio del cliente (SLR, Service Level

Requirements)
Como ya se ha indicado, es un documento que describe de forma detallada las
necesidades del cliente. La descripcin se realiza en el lenguaje del cliente para faci-
litar su entendimiento y validacin. Este documento contiene la informacin de la
funcionalidad que deber proveer el servicio. Se debe formalizar con el cliente, pues
sobre esta base se ejecuta todo el proceso de creacin.
En la confeccin del documento de SLR, es mejor crear un primer borrador a
grandes rasgos que sirva como punto de partida para el dilogo con el cliente, para
ir ganando progresivamente ms detalle y profundidad. Hay que involucrar al
cliente en la tarea de reflejar en un documento sus necesidades. Hay que tener cui-
dado de no ir demasiado lejos y de no parecer que est presentndole al cliente un
hecho consumado.
La definicin de los requisitos puede resultar difcil, pues puede que el negocio no
sepa exactamente lo que quiere, por lo que pueden necesitar ayuda para compren-
der y definir sus necesidades. Hay que tener en cuenta que los requisitos expresa-
dos al inicio irn concretndose y diferirn de los que finalmente se acuerden. Si se
realiza facturacin del servicio, es frecuente que las diferencias entre lo solicitado
inicialmente y lo acordado sea mayor. Pueden ser necesarias varias tandas de nego-
ciaciones antes de lograr el equilibrio entre lo que se busca y lo que econmica-
mente se puede conseguir.
En la figura 7.2.10 se muestra un ejemplo de estructura para el SLR.
Requisitos de nivel de servicio SLR
Acuerdo de nivel de servicio firmado.
Datos de contacto del cliente.
Fecha de solicitud.
Nombre del servicio.
Descripcin de las funcionalidades requeridas.
Caractersticas del servicio:
Fecha de inicio del servicio .
Fecha de finalizacin/desconexin del servicio.
Horario del servicio y soporte.
Requerimientos de disponibilidad y fiabilidad.
Requerimientos de seguridad y continuidad.
Requerimientos de interfaces.
Requerimientos de rendimiento (tiempos de respuesta).
Requerimientos de explotacin y operacin.
Diseo del nivel de servicio.
Modificaciones en caso necesario a los acuerdos de nivel
de servicio existentes.
Responsabilidad del diseo/departamentos involucrados:
Nombre del departamento.
Participacin requerida.
Responsables y datos de contacto.
Planificacin.
Fecha requerida de disponibilidad.
Figura 7.2.10. Ejemplo de SLR

Revisiones del servicio prestado

Una vez puesto el servicio en explotacin regular, se deben realizar reuniones de
revisin peridicas del servicio con el cliente, mantenindose as un contacto per-
manente que genera un ciclo de relacin que permitir a TI conocer su desempeo
y ajustarlo a las necesidades del cliente.
A este respecto, existe un nuevo reparto de funciones entre relaciones con el nego-
cio y la gestin de nivel de servicio. La gestin de nivel de servicio monitoriza el
servicio para determinar la calidad, fiabilidad y disponibilidad del mismo, y genera
informes del nivel de servicio, de acuerdo al proceso de generacin de informes
(vase el apartado 6.2). Las relaciones con el negocio presenta y analiza con el
cliente toda la informacin y los informes generados.
ISO/IEC 20000 establece unos requisitos mnimos para que la revisin del servicio
prestado se realice de una forma peridica y procedimentada.
UNE-ISO/IEC 20000-1
El proveedor del servicio y los clientes se deben reunir, al menos una vez al ao,
para la revisin del servicio y para discutir cualquier cambio en el alcance del
mismo, en el SLA, en el contrato (si existe) o en las necesidades del negocio. Se
deben mantener reuniones a intervalos acordados para discutir el comportamiento y
las prestaciones, los cumplimientos, asuntos varios y planes de accin. Estas reunio-
nes se deben documentar.
A las reuniones puede invitarse a otros actores relacionados con el servicio.
Los cambios al contrato(s), si existen, y al SLA deben ser el resultado de las reunio-
nes mencionadas, cuando sea apropiado. Estos cambios deben estar sujetos al pro-
El proveedor del servicio debe permanecer al tanto de las necesidades del negocio y de
los principales cambios en el mismo para preparar una respuesta a dichas necesidades.
UNE-ISO/IEC 20000-2
El proveedor del servicio y los clientes previo, tratar las necesidades de nego-
deberan realizar revisiones del servicio, cio actuales y previstas y proponer cual-
al menos anualmente y antes y despus quier cambio necesario en el alcance
de cambios importantes. La revisin del servicio y los SLA. Otros grupos de
debera considerar el comportamiento inters implicados como por ejemplo
subcontratistas, clientes, grupos de El proveedor del servicio debera planificar

usuarios u otros grupos representativos, y registrar todas las reuniones formales,
pueden ser invitados a participar en las registrar los problemas tratados y realizar
reuniones de revisin. el seguimiento de las acciones acordadas.
El proveedor del servicio y los clientes El proveedor del servicio debera esta-
deberan tambin acordar los procedi- blecer una relacin con sus clientes de
mientos de revisin parcial para tratar el manera que stos puedan estar al tanto
progreso, los logros y los problemas de las necesidades del negocio y de los
detectados. Estas reuniones deberan cambios principales para poder pre-
planificarse y ser notificadas a los grupos pararse para dar una respuesta a los
de inters para los que sea relevante. mismos.
Conviene destacar varios aspectos que se deben tener en cuenta en las revisiones
del servicio con los clientes, apuntados por estas normas, pues suponen un avance
a muchas de las prcticas actuales. Son las siguientes:
El gestor de la relacin debe reunirse de forma peridica con todas las reas
cliente para revisar el servicio, los niveles de servicio prestados frente a los
requeridos en el SLA, el grado de satisfaccin del cliente, etc. Se trata de eva-
luar la calidad del servicio desde el punto de vista del cliente.
El mantenimiento de reuniones en los plazos acordados y, como mnimo,
una vez al ao. Lo habitual es que las reuniones de revisin con los clientes
sean mensuales. En servicios crticos en perodos de inestabilidad las reunio-
nes pueden llegar a ser semanales.
Las reuniones de revisin deberan estar procedimentadas, para que transcu-
rran de una forma eficiente y no se deje ningn tema sin tratar. De estas reu-
niones debe haber un acta formalizada y aprobada por todas las partes.
A las reuniones con los clientes se puede invitar a otros actores, pues la rela-
cin con el cliente no es un coto cerrado. Ahora bien, la asistencia de diver-
sos miembros debe ser preparada para presentar entre todos una imagen de
TI coherente y alineada hacia los mismos objetivos. No hay nada ms
penoso que una discusin interna de TI delante del cliente.
Como consecuencia de estas reuniones, surgirn propuestas de cambio al
servicio o al SLA. Toda propuesta de cambio se gestionar con una peticin
de cambio reglada (RFC) que pasar al control del proceso de gestin del
cambio.
Este contacto permanente debe aprovecharse para que TI est al tanto de
la situacin y evolucin del rea de negocio, con el objetivo de facilitar la
anticipacin de TI. Por ello, el gestor de las relaciones con el negocio debe-
ra concretar esta informacin obtenida en un informe, o un comunicado por
escrito, a la direccin de TI o al rea de estrategia de TI, de los cambios de
tendencia junto con una prediccin sobre las demandas futuras del rea
de negocio hacia TI.
Es necesario establecer el punto de inflexin en el que se considera que un servicio

deja de ser til para la organizacin. La gestin de las relaciones con el negocio debe
detectar los casos en los que la provisin de un servicio genera un coste superior al
valor que proporciona, analizar su retirada o proponer alternativas de evolucin.
Como resultado de esta etapa, en la que se evalan los niveles de los servicios prestados
realmente, se identifican y proponen las acciones oportunas para su mejora. La gestin
de relaciones con el negocio propone estas acciones de mejora al proceso de gestin de
nivel de servicio para que las incorpore al programa de mejora del servicio (SIP).
Reclamaciones del servicio

Debido a la propia naturaleza de los servicios de TI, complejos y con una interven-
cin humana intensiva, es normal que ocurran fallos. Los procesos de resolucin
(gestin del incidente y gestin del problema) junto con el resto de los procesos
tratan de evitar, minimizar y resolver estos fallos. Pero los fallos ocurrirn y crearn
dificultades al negocio.
Las Normas ISO/IEC 20000 incorporan un apartado bastante innovador en las
prcticas de las organizaciones de TI, que es la gestin de las reclamaciones de los
clientes sobre los servicios. El tratamiento de las reclamaciones es una nueva
palanca que impulsar numerosas acciones de mejora de TI, subsanando carencias
y permitiendo que los servicios prestados estn ms prximos a los clientes.
El tratamiento de las reclamaciones es una actividad asignada a la gestin de las
relaciones con el negocio.
UNE-ISO/IEC 20000-1
Debe existir un proceso de reclamaciones. La definicin de la reclamacin formal

sobre el servicio debe estar acordada con el cliente. Todas las reclamaciones forma-
les sobre el servicio son registradas por el proveedor del servicio, investigadas, con-
troladas emprendiendo acciones sobre ellas, informadas y formalmente cerradas.
Cuando una reclamacin no sea resuelta mediante los canales normales, el cliente
debe disponer de un mecanismo de escalado.
UNE-ISO/IEC 20000-2
El proveedor del servicio y los clientes Las reclamaciones ms relevantes se

deberan acordar un procedimiento for- deberan revisar peridicamente y ser
mal de reclamaciones que elimine cual- escaladas a la alta direccin si no se
quier ambigedad sobre qu constituye resuelven dentro de los plazos acorda-
una reclamacin y cmo se debera dos con los clientes.
gestionar. El proveedor del servicio
debera poner en marcha un proceso
analizar peridicamente las reclamacio-
para tomar las acciones adecuadas en
nes registradas para identificar tenden-
la resolucin de los problemas.
cias y elaborar informes con este anli-
El proceso debera identificar a la persona sis para los clientes.
de contacto en el proveedor del servicio al
Los resultados de tal anlisis se debe-
que dirigir las reclamaciones formales.
ran usar cuando sea apropiado para el
El proveedor del servicio debera regis- establecimiento de un plan de mejora
trar, investigar, tomar acciones, elaborar del servicio.
informes y cerrar formalmente todas las
reclamaciones de servicio.
Un cliente no se molesta en poner una reclamacin si no est fuertemente discon-

forme con el servicio o el trato recibido. Por tanto, la gestin de la reclamacin es
fundamental para conseguir mejorar la satisfaccin del cliente.
La reclamacin es el ltimo instrumento que le queda al cliente para manifestar su
disconformidad. Las reclamaciones ms graves, si no se resuelven, se deben escalar
a la alta direccin.
Para que las reclamaciones resulten un instrumento de mejora para TI, se debe esta-
blecer un procedimiento para su registro, seguimiento y resolucin. Las reclama-
ciones deben ser analizadas, clasificadas y tratadas. Unas desencadenarn una
mejora sencilla en TI, en otras ser suficiente con una explicacin o disculpa al
cliente, pero habr algunas que requieran un cambio ms sustancial en el servicio o
en la organizacin de TI. El tratamiento de reclamaciones en ISO/IEC 20000 no
llega a tener la categora de proceso principal, aunque se pide un procedimiento o
sistemtica para su seguimiento y resolucin. Las reclamaciones se registran, tienen
plazos de resolucin, se investigan, se escalan, se inician acciones para su resolu-
cin, se informa sobre ellas y se cierran formalmente.
Las reclamaciones se deben dirigir a una persona de contacto en TI claramente
identificada, que conviene que sea distinta de los gestores que habitualmente se
relacionan con el cliente.
En la figura 7.2.11 se presenta un ejemplo del formato para la ficha de registro de

una reclamacin.
Ficha de reclamacin
Datos a rellenar por el cliente:

Cdigo reclamacin.
Estado de la reclamacin.
Persona que la realiza.
Fecha alta.
Servicios implicados.
Ttulo de la reclamacin.
Descripcin o detalle de la reclamacin.
Valoracin de la importancia por el cliente.
Datos a cumplimentar por TI en su resolucin:

Clasificacin de la reclamacin.
Prioridad de la reclamacin (similar a incidentes).
Acuerdo del nivel de servicio asociado.
Datos de contacto del cliente.
Fecha de registro.
Asignacin.
Resultados de la investigacin.
Conclusin y acciones emprendidas.
Fecha de cierre prevista.
Cierre de la reclamacin.
Comentarios del cliente al cierre.
Fecha de cierre real.
Etc.
Figura 7.2.11. Ejemplo de ficha de registro de reclamaciones

Medicin de la satisfaccin del cliente

La medicin de la satisfaccin del cliente es una prctica habitual en el mundo
comercial y tambin frecuente en las organizaciones de TI. La medicin de la satis-
faccin permite conocer de forma proactiva la percepcin y la opinin sobre los
servicios prestados y la atencin recibida.
La organizacin de TI mide la satisfaccin en tres mbitos:
La satisfaccin de las reas clientes, realizada por este proceso.
La satisfaccin de los usuarios, realizada por el centro de servicio al usuario
(service desk), en el cierre de cada incidencia o de forma peridica, bajo las
directrices de este proceso.
La encuesta de clima laboral interno en TI, realizado habitualmente en cola-
boracin con recursos humanos (fuera del alcance de este proceso).
En las Normas ISO/IEC 20000 no queda clara la distincin del trmino cliente
(rea cliente de TI que especifica los servicios) y de usuario (persona que utiliza los
servicios). Por lo que el tratamiento de la medicin de la satisfaccin del cliente en
estas normas se debe entender que corresponde a los dos mbitos: al cliente y al
usuario.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener una o varias personas asignadas como respon-
sable(s) de gestionar la satisfaccin del cliente y todo el proceso de gestin de rela-
ciones con el negocio. Debe existir un proceso de medicin peridica de la satisfac-
cin del cliente para obtener informacin y comentarios, y actuar en consecuencia.
Las acciones de mejora que se identifiquen durante este proceso se deben registrar y
utilizar como informacin de entrada para un plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Se debera medir la satisfaccin del de forma que los clientes puedan respon-
cliente para permitir al proveedor del ser- der fcilmente y sin que se requiera un
vicio comparar el desempeo con los excesivo tiempo para cumplimentar de
objetivos de satisfaccin de clientes y con una manera adecuada dicha encuesta.
encuestas previas. El alcance y la comple- Se deberan investigar las variaciones
jidad de la encuesta se deberan concebir significativas en los niveles de satisfac-
cin para llegar a entender las razones deberan tratar con el cliente. Se debe-
de las mismas. ra acordar un plan de accin, utilizn-
Los anlisis de tendencias u otras com- dolo como entrada para un plan de
paraciones solo deberan realizarse mejora del servicio sobre cuyo progreso
sobre preguntas comparables y entre se informe al cliente.
mtodos de muestreo comparables. Las felicitaciones sobre el servicio se
Los resultados y conclusiones de las deberan documentar y dar a conocer al
encuestas de satisfaccin del cliente se equipo que est prestando el servicio.
Los medios habituales para la medicin de la satisfaccin son la encuesta y la entre-

vista guiada. En ocasiones se puede conocer la percepcin de un grupo de clientes
o de usuarios seleccionados sobre un servicio mediante tcnicas de anlisis en
grupo como pueden ser los focus group.
En el proceso de relaciones con el negocio recae la responsabilidad de la medicin
de la satisfaccin del cliente (y de los usuarios). Se debe establecer un procedi-
miento peridico para la medicin de la satisfaccin. Las encuestas deben ser senci-
llas de cumplimentar. Los resultados deben analizarse e investigarse las desviacio-
nes que existan. Con los resultados de las encuestas se debe preparar un plan de
mejora a tratar con las reas cliente. Las mejoras se incorporarn al programa
de mejora del servicio (SIP) o al plan unificado de mejora de los procesos, segn
sea el tipo de mejora.
Es importante difundir entre el personal de TI las felicitaciones recibidas por el
servicio, de cara a subir la moral y reforzar las acciones positivas.
Relaciones con otros procesos

Si el centro de servicio al usuario (service desk) es el punto nico de contacto con
los usuarios, el proceso de relaciones con el negocio hace de punto nico de con-
tacto con las reas cliente. Todo proceso o unidad de TI que necesite contactar con
los clientes lo har a travs de este proceso. De esta forma se centralizan las relacio-
nes y el cliente siempre trata todos sus asuntos con el mismo interlocutor de TI.
El proceso de gestin de relaciones con el negocio participa en la planificacin e
implementacin de servicios nuevos o de servicios modificados, en los proyectos y
procesos de desarrollo de software, en el seguimiento de los niveles de servicio, etc.
En la figura 7.2.12 se muestra la funcin de punto de contacto con el cliente, man-
tenida por este proceso, y la estrecha colaboracin existente entre el gestor de rela-
ciones y el gestor de niveles de servicio.
Fuente: Telefnica.
Figura 7.2.12. La misin de punto de contacto nico con el cliente de este proceso
Mtricas del proceso

Las mtricas asociadas al proceso miden el desempeo de la relacin entre TI y el
cliente para determinar cmo es de fluida, eficiente y satisfactoria. Por otra parte,
las mtricas recogern informacin sobre la satisfaccin de los clientes y usuarios
con los servicios de TI. Los principales indicadores asociados al proceso son:
Intensidad de la relacin: nmero de reuniones con las reas cliente, ratio de
nmero de reuniones por cliente al ao, duracin media de una reunin,
nmero medio de asistentes de TI y del negocio por reunin, nmero medio
de personal de TI ajeno al proceso que participa en las reuniones con el
cliente y nmero de actas de reunin remitidas en el plazo acordado.
Eficacia de la relacin: mediante el plazo medio necesario para cerrar un
SLA, el nmero medio de veces que es necesario reunirse para acordar
un SLA y el nmero de necesidades del cliente que no se han podido satis-
facer.
Porcentaje de propuestas de SLA aceptadas por el cliente a la primera.

Porcentaje de SLA con modificaciones relevantes en el ao por peticin
expresa del cliente.
Porcentaje medio de satisfaccin de los clientes con TI. Porcentaje medio de
satisfaccin de los usuarios con TI. Aunque es una mtrica claramente subje-
tiva, su valor es innegable para TI. Se miden mediante encuestas de satisfaccin.
Nmero total de reclamaciones al mes o al ao. Nmero y porcentaje de
reclamaciones abiertas al final del mes, nmero anual de reclamaciones por
rea cliente y tiempo medio en cerrar una reclamacin.
Nmero de total mejoras propuestas por este proceso. Del total de las mejo-
ras, porcentaje de ellas que han sido propuestas por este proceso.
Nmero de mejoras generadas como consecuencia de la gestin de reclama-
ciones.
Costes del proceso. Ratios de costes medio por actividad del proceso: coste
medio por reunin, coste medio en la definicin de un SLA, coste medio de
resolucin de una reclamacin, etc.
En la figura 7.2.13 siguiente se muestra el resumen de los indicadores ms relevan-

tes para este proceso.
Figura 7.2.13. Resumen de las mtricas para este proceso

estratificadas por destinatario

Como en el resto de los procesos, los roles intervinientes se estructuran en los roles
propios del proceso y los roles ajenos al proceso (el gestor del nivel de servicio).
El gestor de las relaciones con el negocio (gestor del proceso o process mana-
ger), que es el responsable mximo del proceso y del cumplimiento de los
objetivos del mismo. Se encarga del funcionamiento del proceso en detalle,
de subsanar las deficiencias, de resolver conflictos, etc.
Los gestores del cliente, que desempean una funcin operativa de conocer
al cliente, reunirse con l, conocer en detalle su actividad y mantener el da a
da de la relacin. El gestor de cliente trata en su relacin tanto la creacin
de servicios (mediante desarrollo o adquisicin), como el seguimiento de la
prestacin de los mismos (explotacin y operacin).
Los administradores o personal de soporte al proceso, personal que contri-
buye en organizar la actividad, realizar encuestas de satisfaccin, realizar
informes, apoyo a los gestores de cliente, etc.

El responsable de la gestin del servicio (service manager), que vela por que
todos los servicios cumplan los niveles pactados.
Los gestores de nivel de servicio (SLM, Service Level Managers), que siguen
el cumplimiento de los acuerdos de los servicios a su cargo.
El responsable de informes, aportando los informes a entregar al cliente.
Los jefes de proyecto, bajo el proceso de planificacin e implementacin de
nuevos servicios o de servicios modificados.
(process owner), define las actividades del proceso y se encarga de la mejora
continua del mismo. Todo ello, de una forma integrada con el modelo de
gestin del proveedor de TI incorporado en el SGSTI.
Los roles de mayor relevancia que participan en el proceso de gestin del cambio
se representan en la figura 7.2.14.
Entre las habilidades y aptitudes necesarias, tanto del responsable del proceso
de gestin de relaciones con el negocio como de los gestores de cliente, deben
destacar:
Roles del proceso
Responsable de la
gestin del servicio
Gestor de las relaciones
SGSTI
con el negocio
Gestor del cliente
Propietario del
modelo (SGSTI)
Administrador y soporte
del proceso de relaciones
con el negocio
Gestores del Gestor de informes

nivel de servicio del servicio Jefes de proyecto
Figura 7.2.14. Roles del proceso de gestin de las relaciones con el negocio
Una buena comprensin de los servicios de la organizacin de TI y de los

factores que los influyan, a fin de entender cmo afectarn los requisitos del
cliente a la provisin del servicio.
Un buen entendimiento del negocio del cliente.
Excelentes capacidades comunicativas y de negociacin.
Conocimientos y experiencia en gestin de contratos y suministradores.
La capacidad para interactuar satisfactoriamente con todos los niveles de la
organizacin del cliente
Un conocimiento tcnico razonable y la capacidad para traducir los comple-
jos requisitos y especificaciones tcnicas en conceptos que resulten fciles de
entender para el negocio, y viceversa.
Innovacin respecto a la calidad del servicio y los modos en que puede mejo-
rarse dentro de los lmites de la organizacin.
Saber escuchar y tener la capacidad de aplicar los conocimientos recin
aprendidos de una manera efectiva.
Resumen
La gestin de la relacin con el negocio permite una mejor alineacin continua de
TI-Negocio, facilita y formaliza la relacin para asegurar que la actividad de TI se
enfoca a las necesidades de la empresa.
Establece una disciplina de comunicacin que, con un conjunto de documentos,
permite mejorar la efectividad de la relacin. Los principales medios de formaliza-
cin que aporta o utiliza este proceso son:
El catlogo de servicios, que constituye la base para el dilogo.
Las necesidades del cliente se registran en una hoja de requerimientos del
servicio (SLR).
Se negocia la formalizacin de los compromisos mediante los acuerdos de
nivel de servicio (SLA).
Se mantienen reuniones de seguimiento peridicas del servicio prestado.
Las quejas del cliente se registran como reclamaciones.
Se conoce la opinin del cliente y de los usuarios mediante encuestas y entre-
vistas.
Beneficios
La gestin de las relaciones con el negocio se asegura de que las actividades lleva-
das a cabo en la provisin de los servicios contribuyen a los objetivos de negocio
del cliente. Entre los beneficios obtenidos destacan:
Se asegura que el objetivo de TI es la satisfaccin del cliente y que sta se
mide.
Saca a TI de su mundo tecnolgico para orientarse al negocio.
Fuerza a TI a trabajar para lo que necesita el negocio.
Las relaciones con las reas cliente se gestionan con mayor profesionalidad.
Los servicios prestados se revisan regularmente con los clientes de TI.

Se formalizan las reclamaciones.
Se impulsan acciones de mejora del servicio.
Cmo se desempean las relaciones entre TI y las reas de negocio en
su organizacin?
Cmo se tratan las quejas de los clientes en su empresa?
Cul es la frecuencia y contenido principal de las encuestas a las reas
cliente en su organizacin?
1
7.3. Gestin de suministradores 485
7.3. Gestin de suministradores
Figura 7.3.1. Actividades del proceso de gestin de suministradores
Mantener operativos y actualizados los servicios de TI requiere ineludiblemente

la gestin adecuada de un conjunto de suministradores, que ser ms o menos
amplio dependiendo de las estrategias de consolidacin seguidas a lo largo de la
historia de la organizacin. Conocer cmo las empresas lderes llevan a cabo con
xito la gestin de la relacin con estas empresas externas aportar un conjunto
esencial de prcticas imprescindibles, que garantizarn la consecucin de los
objetivos de TI.
Las relaciones entre empresas contratantes y sus suministradores se han enfo-
cado tradicionalmente como relaciones jefe-subordinado. Pero las relaciones
entre empresas acaban siendo siempre relaciones entre personas con nombres y
apellidos. Entendiendo este escenario, quiz se pueda abordar con ms sensatez
las relaciones entre la organizacin de TI y sus suministradores (vase la figura
7.3.1). Dado que en los extremos de esta relacin hay siempre personas, se
necesita un marco de actuacin, una misin, ilusin, confianza, estmulo y tam-
bin exigencia. As, en un contexto que equilibre la inteligencia emocional con
una demanda de resultados extrema, es en donde se debe desarrollar la relacin
con los suministradores.
Esta relacin se desarrolla en un entorno econmico de tremenda presin y compe-

tencia. Por ello, el ajuste de costes puede ser tremendamente intenso en algunas
contrataciones. Esto introduce una fuerte presin sobre toda la cadena de suminis-
tro, pero se debe ser capaz de conjugar el rigor y la exigencia con el factor emocio-
nal que alimenta las relaciones humanas.
Por otra parte, la actividad de la organizacin de TI se torna cada da ms compleja
y su evolucin ms dinmica. Se demandan nuevas especializaciones tcnicas, se
necesita capacidad de adaptacin, crecimiento, decrecimiento o evolucin. Estas
funciones, que inicialmente se realizaban completamente por el personal propio de
la empresa, presentaba la problemtica de necesitar una constante de evolucin en
los conocimientos, por lo que las empresas han necesitado recurrir paulatinamente
a servicios externos para aprovisionarse de las nuevas capacidades necesarias.
De esta forma, la situacin ha ido avanzando hasta el punto en el que una gran
parte de la actividad de la organizacin de TI se realiza por manos externas.
As, es raro encontrar una gran organizacin que tenga programadores propios,
gran parte del desarrollo de software se ha externalizado, ya sea en forma de contra-
tos llave en mano (normalmente en el caso de grandes evolutivos) o bajo el con-
cepto de software factories (normalmente para el caso de pequeos desarrollos o
mantenimiento correctivo), y buscando siempre las economas de escala y zonas
geogrficas de bajo coste salarial (offshore y nearshore).
El mbito de la produccin o explotacin de los servicios, tampoco es ajeno a las
corrientes de externalizacin, que se iniciaron con la incorporacin de personal
ajeno en formato de prestacin de servicios o body shopping. Ha ido evolucionado
hacia la externalizacin de las funciones tcnicas en modo servicio o sourcing selec-
tivo. En el caso ms extremo de externalizacin se presenta el outsourcing completo
de toda la produccin, cuando la organizacin de TI nicamente realiza el control
de un suministrador que realiza ntegramente todas las actividades.
Por ello, en la situacin actual de fuerte externalizacin de las actividades, la ges-
tin adecuada de los suministradores cobra una gran importancia, pues en muchos
casos, estos llevan ms del 70% de la actividad del departamento de TI.
La gestin de suministradores, si bien no es un proceso nuevo ya que exista como
tal en ITIL v2 dentro del libro Business Perspective, s es un proceso que cuenta
con poco arraigue en la cultura de los departamentos de TI. En la mayora de las
ocasiones, su foco se reduce al conocido proceso de compras y contrataciones. Con
este precedente, la gestin de suministradores se suele iniciar con la centralizacin
de las compras de TI, que impone cierto rigor en el proceso de adquisicin. Pero el
seguimiento del cumplimiento y desempeo del suministrador a lo largo de todo
el ciclo de prestacin del servicio, se ha dejado tradicionalmente al albedro y a la
capacidad de reaccin del equipo tcnico que recibe el servicio contratado. La rea-
paricin de este proceso primero en ISO/IEC20000 y despus en ITIL v3 (en el
libro de Diseo del Servicio) pone de manifiesto la importancia que tiene en la nor-
mativa y marcos de buenas prcticas. En el presente apartado se presenta una visin
integral de la gestin de suministradores, que se inicia con la definicin de la estra-
tegia y concluye con el trmino de los servicios contratados. Esta visin va ms all
de los lmites establecidos en ISO/IEC 20000 para el proceso.
La gestin de suministradores es toda actividad dirigida a que los servicios contra-
tados al suministrador se presten segn la forma acordada, para obtener el benefi-
cio previsto de los contratos para la organizacin de TI. Por tanto, la gestin de
suministradores supervisa, gua y exige a los suministradores el cumplimiento de lo
pactado en el contrato. Y, por otra parte, tambin debe velar porque la propia orga-
nizacin de TI contratante haga todo lo posible para que el servicio se preste con la
fluidez deseada.
Recalcar la diferencia terminolgica entre suministrador o empresa externa a la que
se contrata algn producto o servicio y el trmino proveedor de TI en ISO/IEC
20000, que se refiere a la propia organizacin de TI o al departamento interno de
informtica.
En la figura 7.3.2 se presenta un esquema introductorio al proceso.
Proceso de gestin Qu aporta:

de suministradores Asegura la ejecucin de la estrategia
de sourcing en lo relativo a la
contratacin externa.
Definicin:
Da rigor y transparencia a las
Proceso que gestiona todo el actividades de contratacin
aprovisionamiento y la prestacin de los de productos y servicios.
productos y servicios que TI necesita.
Abarca las reas de desarrollo de Implementa una sistemtica para que
software, de produccin, etc. la relacin y gestin de los
suministradores se realice de forma
homognea por todas las unidades.
Objetivo: Implementa las mejores prcticas
Gestionar los suministradores para del mercado en la gestin de los
garantizar la provisin sin suministradores.
interrupciones de servicios de calidad. Alinea los servicios contratados
con las necesidades de TI.
Almacena el conocimiento sobre los
suministradores y su desempeo.
Figura 7.3.2. Introduccin al proceso de gestin de suministradores

La gestin de suministradores se encarga de la ejecucin de la estrategia de sourcing

en lo relativo al aprovisionamiento exterior de productos y servicios relacionados
con las TI. Es un proceso ejecutor de la estrategia y las polticas de la empresa, pero
no se encarga de definirlas. La estrategia de sourcing es una parte importante de la
estrategia general de las TI y se desarrolla en otro mbito (en el caso de ITIL v3,
los aspectos relacionados con la estrategia de sourcing se desarrollan dentro del libro
Estrategia del Servicio). En esta estrategia se definen las funciones esenciales que se
deben retener (que se realizarn internamente por personal propio) y las actividades
o reas a externalizar, conformando lo que se conoce como polticas de sourcing.
La gestin de suministradores gestiona todo tipo de contratacin, bien sea de con-
sultora, de desarrollo de software, de soporte, de equipamiento, etc. Tambin pone
foco en la gestin de la prestacin de servicios del suministrador posterior a la con-
tratacin.
El correcto desempeo de estas actividades requiere desarrollar 4 disciplinas o pila-
res esenciales que se muestran en la figura 7.3.3.
Una de las disciplinas principales en la gestin de suministradores es la perseveran-
cia en la relacin, manteniendo una continuidad en las exigencias, en el segui-
miento, y en el trato con terceros. La perseverancia convertir el buen hacer en
Figura 7.3.3. Bases de la gestin de suministradores

rutina habitual en la prestacin del servicio, de tal forma que las reuniones, infor-
mes, escalados, etc. fluyan con total normalidad sin necesitarse un esfuerzo espec-
fico para conseguirlos.
Junto a esta faceta, el rigor en la relacin, manteniendo un trato formal y documen-
tado, permitir dejar trazas y evidencias de todo lo acontecido a lo largo de la his-
toria de la relacin con cada uno de los suministradores.
No hay que olvidar que la relacin con el suministrador se desarrolla en un marco
contractual, en el que debe haber una cobertura legal para la prestacin y la gestin
de los desacuerdos. El carcter contractual debe estar presente a lo largo de toda la
relacin.
El cuarto aspecto importante es el relativo a la funcin de interlocutor entre la
organizacin de TI y los suministradores. Para tener xito en la mediacin es nece-
sario que se conozcan y se gestionen los mecanismos que se van utilizar para que
fluya la relacin con los suministradores y asegurar as el cumplimiento de lo con-
tratado y la satisfaccin mutua. Frecuentemente se ignora esta faceta de facilitador
interno con toda la organizacin de TI para alcanzar los objetivos esperados en las
contrataciones, pero se debe velar por que todo el mundo cumpla con su parte. En
ocasiones, es el propio personal de la organizacin contratante quien dificulta o
ralentiza la prestacin del servicio. Otras veces, son las deficientes interfaces entre
las herramientas las que dificultan el flujo de intercambio de informacin, de peti-
ciones o de trabajos.
En la gestin de suministradores, normalmente los problemas suelen surgir en las
fronteras e interfaces. En las fronteras en cuanto a la determinacin de los lmites
de lo contratado, entrando en discusiones sobre si una actividad est contratada o
no. En las interfaces por la necesidad de integracin de los sistemas, organizacio-
nes, culturas, procesos y formas de hacer entre la organizacin TI contratante y las
diversas organizaciones de prestacin de servicios de los suministradores.
De forma general, aunque no plenamente coincidente con las normas y estndares
de referencia, como se ver ms adelante, el alcance de este dominio (gestin de
suministradores) debera comprender desde la definicin de la estrategia de sour-
cing (realizada en el mbito de la definicin de la estrategia general de TI), pasando
por la seleccin y contratacin, para seguir con la prestacin o recepcin de los ser-
vicios, hasta concluir con la etapa de finalizacin de los mismos.
De esta forma, y tomando como referencia el proceso similar definido en ITIL (en
su versin 2 dentro del libro Business Perspective, y en su versin 3 dentro del libro
Diseo del Servicio), en este captulo se desarrolla un enfoque propio en el que,
cubrindose tambin las actividades de establecimiento de la estrategia de sourcing
y de finalizacin o terminacin del suministro, las actividades se agrupan en dos
grandes ciclos centrales: el ciclo de seleccin y contratacin, y el ciclo de prestacin.

Son dos ciclos en continuo movimiento en el que el primero se encarga de todas las
actividades a realizar en la fase de adquisicin o compra (que se inicia con la necesi-
dad identificada y finaliza con el contrato adjudicado), mientras que el segundo
ciclo, el de prestacin, controla la recepcin de los productos o servicios contratados
(se inicia despus de la adjudicacin y finaliza con la expiracin del contrato).
Como se ha indicado estos dos ciclos principales se complementan con una etapa
previa de implementacin de la poltica de gestin de suministradores y otra de
finalizacin que gestiona adecuadamente la terminacin de los servicios. En para-
lelo a todas las actividades se desarrolla la mejora continua del proceso.
As, el proceso se presenta agrupado en los siguientes bloques.
Etapa de planificacin e implementacin del proceso y de la poltica de sumi-
nistradores.
Ciclo de seleccin y contratacin de productos y servicios.
Ciclo de prestacin de los servicios contratados.
Etapa de renovacin o finalizacin de los servicios.
La mejora continua del proceso.
El alcance dado al proceso en los diferentes estndares tiene sus diferencias. En

ITIL v3 la estrategia de sourcing se trata como parte de general de la estrategia de
TI (libro Estrategia del Servicio). En la figura 7.3.4 se muestra el esquema utilizado
en ITIL v3 para este proceso, identificndose los dos grandes ciclos propuestos en
este libro.
Por otra parte, la Universidad Carnegie Mellon, el otro gran actor en los marcos de
trabajo para la gestin de las TI, ha desarrollado un modelo de madurez para la
gestin de las externalizaciones y del outsourcing en dos versiones: una para las
organizaciones contratantes de servicios, denominadas clientes (eSCM-CL,
eSourcing Capability Model for Client Organizations) y otra para organizaciones
suministradoras de servicios, denominadas proveedoras (eSCM-SP, eSourcing
Capability Model for Service Providers). En la figura 7.3.5 se muestra un esquema del
primer modelo, constituido por 95 mejores prcticas.
En ISO/IEC 20000, los requisitos definidos para el proceso de gestin de suminis-
tradores no contemplan ni la estrategia de sourcing ni la seleccin de suministrado-
res. No obstante, en este libro s se incluyen ambos aspectos porque la gestin de
suministradores es crtica en los resultados globales de la organizacin de TI. En la
figura 7.3.6 se muestra el alcance del proceso en el presente libro comparado con
los diversos alcances establecidos en ITIL v3 y en ISO/IEC 20000.
Figura 7.3.4. El proceso de gestin de suministradores en ITIL v3
Fases del ciclo de vida del outsourcing desde la perspectiva de organizaciones contratantes
Anlisis Inicio Prestacin Terminacin

Anlisis oportunidades Planificacin de Gestin del servicio Finalizacin del
externalizacin la externalizacin externalizado servicio
Estrategia de Evaluacin de
externalizacin suministradores
Acuerdos (contratos)
Transferencia
del servicio
reas permanentes de capacidad
Gestin estratgica del sourcing Gestin del valor Gestin de los

Gestin de la gobernabilidad Gestin del cambio recursos humanos
Gestin de las relaciones organizacional Gestin del conocimiento
Fuente: CMMI y ASENTTI.
Figura 7.3.5. Esquema del modelo de gestin de outsourcing del modelo eSCM-CL
Figura 7.3.6. Diversos alcances del proceso de gestin de suministradores
En las Normas ISO/IEC 20000 la responsabilidad de demostrar el cumplimiento

de estos procesos de gestin de suministradores recae en el rea de TI, denominada
proveedor del servicio. Hay que tener en cuenta que pueden existir relaciones en
cascada, encadenndose contratos de varios suministradores para el servicio final
de TI, como se muestra en el ejemplo de la figura 7.3.7.
Suministrador 1
Proveedor de TI
Negocio Suministrador 2
(rea TI)
Suministrador 4
Suministrador 3
subcontratado
Figura 7.3.7. Ejemplo de relaciones entre el proveedor del servicio

y mltiples suministradores
Los mecanismos principales utilizados en el proceso de gestin de suministradores

para alcanzar sus objetivos, agrupados en funcin de cada una de las etapas, se
muestran en la figura 7.3.8.
Estrategia Seleccin y Renovacin

Prestacin
de sourcing contratacin o finalizacin
Estrategia de Necesidad de TI Contrato adjudicado, Requisitos de

externalizacin RFI con sus niveles de terminacin
Perfil de actividades a servicio Preparacin para la
Caso de negocio
externalizar Entrega del producto terminacin
RFP (SOR) o prestacin del
Polticas de Renovacin y
contratacin Hoja de compra servicio transicin
Objetivos de nivel Asiento en el ERP de Mecanismos de
de servicio a cumplir la compra relacin:
(de SLA pactados) Hoja seguimiento Interlocutores
de ofertas Comits
Contrato (UC) Informes
Base datos Interfaces
suministradores y
contratos (SCD)
PDCA
Mejora
SGSTI
Figura 7.3.8. Componentes ms destacados del proceso
Los componentes principales que se emplean en el proceso son, por orden alfab-
tico, los siguientes:
Contrato. Documento legal que formaliza la compra o la contratacin.
Contrato de soporte (UC, Underpinning Contract). Trmino muy utilizado
en el mbito de ITIL. Se refiere al contrato especfico de servicios con un
suministrador externo en el que se fijan los niveles de servicio que el sumi-
nistrador debe cumplir. Los niveles de servicio pactados en los contratos de
soporte deben ser igual o ms exigentes que los acordados con las reas clien-
tes en los SLA.
Declaracin de requisitos (SOR, Statement Of Requirements). La declaracin
de requerimientos es el trmino utilizado en ITIL v3 para referirse a la RFP.
Estrategia de sourcing. La estrategia de sourcing determina qu actividades
o funciones se van a realizar internamente (retenidas) y cuales se van a con-
tratar al mercado (externalizadas). Determina as el perfil de externalizacin.

Adems, pueden marcar directrices para la seleccin de los suministradores y
el marco de calidad y niveles de servicio a obtener.
Hoja de peticin de compra. Ficha con los datos de la compra que se pre-
tende realizar (detalle de los productos o servicios a contratar, rea proponente,
elementos de configuracin y servicios de TI a los que afecta, presupuesto asig-
nado, justificacin, documentacin de respaldo, etc.). La crea el rea de TI que
tiene la necesidad, la aprueba el rea financiera de TI y la completa la gestin
de suministradores a lo largo del ciclo de seleccin y contratacin.
Hoja de seguimiento de ofertas. Fichas con los datos econmicos y carac-
tersticas de todas las ofertas recibidas para una solicitud de compra. Sirve
como base para analizar las diversas ofertas, en sus aspectos econmicos y en
su contenido. Esta ficha suele contener el resumen de la valoracin tcnica y
econmica de las ofertas.
Interfaces entre los procesos de la organizacin de TI y el suminis-
trador. Para que la prestacin de servicios sea eficiente, es necesario
que los procesos del proveedor de TI y del suministrador engranen a la
perfeccin. Las interfaces realizan la conexin entre los dos procesos.
Muchas veces sern interfaces informticas entre las herramientas de ges-
tin de ambas organizaciones y otras sern interfaces o comunicaciones
humanas.
Interlocutores. Rol que designa a los diversos representantes por parte de la
organizacin contratante y por parte de la organizacin contratada.
Niveles de servicio (en UC). Al igual que la organizacin de TI compro-
mete unos niveles de servicio con el negocio firmando los SLA, en la con-
tratacin con suministradores se deben fijar unos niveles de servicio, de
forma paralela, que sean capaces de soportar los compromisos adquiridos
de la organizacin de TI. As, los UC deben estar alineados con los SLA,
contratando unos niveles de servicio homogneos a los suministradores.
Mecanismos de relacin (con suministradores). Regula la relacin entre la
empresa contratante y la empresa contratada. Define la interrelacin entre
ambas partes, los comits, los roles de interlocucin, los tipos de informes,
las mtricas para el seguimiento del cumplimiento, la gestin de los aspectos
financieros y contractuales, las penalizaciones y reclamaciones, la gestin del
conocimiento, la confidencialidad, etc.
Peticin de compra (RFP, Request For Proposal). Documento que contiene
las especificaciones del producto o servicio que se pretende comprar y que se
utiliza para peticin de ofertas al mercado. Su contenido suele tener carcter
contractual y pasa a formar parte del contrato final (est relacionado con otra
forma de emitir solicitudes de ofertas denominadas: ITT, Invitation To Tender).
Si se ha realizado un RFI previo, se toman sus resultados como punto de par-
tida. Toda compra importante debera llevar una RFP que especifique todos
los detalles y acuerdos de la compra. La RFP se remite a los suministradores
candidatos y suele formar parte del contrato final.
Polticas de contratacin. Directrices y normativas internas que dictan las
pautas establecidas en la estrategia de sourcing que se deben seguir en todas
las adquisiciones o contrataciones.
Proveedor de TI. Organizacin, departamento, rea de TI que presta los
servicios de TI. Es el contratante de los servicios de terceros que necesite
para ser capaz de proveer los servicios TI prestados al negocio.
RFI (Request For Information). Peticin de informacin, de ideas y de enfo-
ques que solicita la organizacin de TI a ciertos suministradores clave.
Mediante la RFI se plantea al mercado una situacin y se le solicitan ideas y
posibles soluciones. Con los resultados de este sondeo se enfoca de forma
ms precisa la contratacin a realizar.
SCD (Supplier and Contract Data base). Es la base de datos de suministrado-
res y contratos, que centraliza y registra toda la informacin sobre los con-
tratos realizados. Este trmino se ha acuado en ITIL v3, aunque el con-
cepto ya era muy conocido en el mercado.
Servicio. En lo relativo al trmino de servicio, surge un nuevo conflicto ter-
minolgico, pues tambin se denomina servicio a la prestacin contratada a
un suministrador. Por tanto, ya existen tres tipos de servicios:
Los servicios que comercializa el negocio al mercado, que en algunas oca-
siones son servicios de TI puros.
Los servicios que presta el proveedor o rea de TI internamente a las reas
de cliente de la empresa.
Los servicios que presta un suministrador al proveedor o rea de TI.
Solicitud de ofertas (ITT, Invitation To Tender). Comunicado remitido a

los potenciales suministradores para la solicitud de ofertas formales para pro-
ceder a la contratacin de servicios. La diferencia entre la RFP y una ITT
no est del todo clara y depende de los usos y hbitos en cada pas o en cada
sector. En trminos generales, en la ITT la carga de la descripcin del pro-
ducto o servicio recaen en el suministrador, mientras que en la RFP la des-
cripcin est contenida en la propia RFP (por ello, pasar a formar parte
del contrato final). El trmino ITT se utiliza en ITIL v3, mientras que en la
versin 2 se utiliza ms RFP.
La RFP o la ITT son formas parecidas de solicitar ofertas al mercado para efec-
tuar una compra y, por tanto, deben tener asignado un presupuesto interno.
Sourcing. El trmino sourcing comprende todas las actividades relativas al
aprovisionamiento de productos y a la provisin y el soporte de los servicios,
necesarias para poder prestar el servicio de TI. En los dos extremos del sour-
cing estn: el outsourcing (externalizacin completa de una unidad de TI) y el
insourcing (realizacin de la actividad internamente por el personal de planti-
lla y subcontratado). Entre medias est el outsourcing selectivo (externaliza-
cin de funciones al mejor suministrador en cada una de ellas) y una amal-
gama de posibles subcontrataciones. La proporcin de cada uno depende de
las polticas y estrategias de sourcing de la organizacin. Por tanto, el con-
cepto de sourcing va ms all de su traduccin literal por suministro, pues
tambin incluye las actividades internas retenidas en la organizacin de TI.
Subcontratistas. Empresas a las que un suministrador contrata a su vez algn
servicio necesario para prestar el servicio contratado con el proveedor TI.
Suministrador de TI. Empresa externa al proveedor de TI que provee
algn producto, o presta algn de servicio a ste, bajo un contrato de com-
pra o de prestacin. El abanico de suministradores es muy amplio y com-
prende a fabricantes de equipamiento hardware, fabricantes de productos
software, proveedores de telecomunicaciones, servicios mantenimiento hard-
ware y software, servicios de soporte, servicios de body shopping, consultores,
integradores, servicios de valor aadido, outsourcers de funciones especficas
de TI, outsourcers integrales, etc.
Conviene destacar que, para evitar la confusin terminolgica, en las Nor-
mas ISO/IEC20000 se ha adoptado el trmino de suministrador para desig-
nar a toda organizacin a la que se le contrata algn tipo de prestacin, que-
dando el trmino proveedor para aquellas organizaciones que quiere cumplir
con lo especificado por la norma (a efectos de certificacin). Se distingue,
as, entre suministrador de TI y proveedor de TI (rea o departamento de
TI). Esta consideracin es muy importante en el mbito de estas normas, y
hay que afinar el lenguaje, utilizando siempre suministrador para estas pres-
taciones contratadas externamente.
Tipos de sourcing. Los tipos de sourcing son tan variados como tipos de ser-
vicios, o parte de los mismos, que se pueden contratar. Los tipos ms fre-
cuentes en el mercado son: internalizacin o realizacin interna, prestacin
de servicios o body shopping, outsourcing selectivo, y outsourcing completo.
Interrelacin entre la gestin de suministradores y otros

procesos y reas de TI
El proceso de gestin de suministradores da un servicio a otros procesos o reas de
TI con el fin de canalizar en un punto la gestin del suministro externo. Pero, cada
tipo de producto o servicio contratado tiene unas caractersticas de gestin espec-
fica. As:
En los servicios con una gestin por proyecto (consultora, desarrollo de soft-
ware, transformacin de infraestructuras, etc.), el proceso lidera el ciclo de
seleccin y contratacin, acompaado y soportado por el rea solicitante.
Pero en la ejecucin del proyecto, puede pasar a un segundo plano, dejando
que el jefe de proyecto lleve la gestin del suministrador.
En la compra de productos (hardware, software, etc.), el proceso lidera tam-
bin el ciclo de contratacin. La implementacin la realizan las reas tcni-
cas bajo el proceso de gestin de la entrega. Vuelve a tomar un papel rele-
vante en la gestin de los contratos de mantenimiento y de soporte, para
garantizar su alineamiento con los niveles de servicio y controlar el desem-
peo del fabricante.
En la contratacin de servicios continuos (outsourcing, comunicaciones, hos-
ting de servidores, body shopping, mantenimiento de software, software facto-
ries, etc.), el proceso se despliega completamente en toda su extensin ya
que, adems del ciclo de contratacin, gestiona en todo su esplendor el ciclo
de prestacin (en la faceta de control y seguimiento continuo), hasta la ges-
tin de la etapa de renovacin o finalizacin.
La gestin de suministradores tiene una relacin muy estrecha con el proceso de

gestin de nivel de servicio, pues se responsabiliza de la contratacin y cumpli-
miento de los niveles de servicio de los suministradores para que garanticen o res-
palden los SLA con los clientes.
Siguiendo el ciclo de vida del servicio de ITIL v3, en la etapa de diseo del servicio
se realiza el ciclo de seleccin y contratacin del suministrador, mientras que la
transicin y la operacin del servicio se relacionan con el ciclo de gestin de la pres-
tacin del suministrador. La etapa de operacin participa en la actividad de renova-
cin o finalizacin.
En muchas organizaciones, la funcin de compras se centraliza en un departamento
fuera de TI, que suele llevar a cabo el ciclo de seleccin y contratacin del servicio. El
departamento de compras dispone de personal especializado en la contratacin de pro-
ductos o servicios de TI. En este escenario, el proceso de gestin de suministradores se
extiende ms all de la organizacin de TI hacia el departamento de compras para

engranar la estrategia de sourcing de TI con las polticas de compras.

El proceso de gestin de suministradores se encarga de garantizar al resto de la
organizacin de TI que se alcanzan los objetivos contemplados en los contratos
externos de suministro, de soporte, de consultora, etc. velando por la mnima fric-
cin entre las diferentes organizaciones. Las entradas, actividades y salidas del pro-
ceso se muestran en la figura 7.3.9.
Las entradas que activan el proceso son la definicin o modificacin de la estrate-
gia de sourcing, que activa las acciones necesarias para la revisin de las polticas de
Desencadenantes 3 Etapa de planificacin e Salidas principales:

del proceso: implementacin del proceso. Producto o servicio
Modificacin en la 3 Definicin de la estrategia de contratado y
estrategia de sourcing. sourcing. prestndose a TI.
Necesidad de compra 3 Ciclo de seleccin y contratacin: Contrato firmado.
(hoja peticin compra). Identificacin de la necesidad y SCD actualizada.
Peticin de SLM. preparacin del caso de negocio. Informes seguimiento
Necesidad de TI Evaluacin y provisin de nuevos del suministrador.
en relacin a contratos y suministradores. Sistemas de gestin
suministradores. Establecimiento de nuevos TI-suministrador
suministradores y contratos. interconectados.
Categorizacin de
Estrategia y polticas Salidas secundarias:
suministradores y
de sourcing. RFI, RFP, ITT enviadas
mantenimiento de la SCD.
Especificaciones de la al mercado.
compra (RFP o SOR). 3 Ciclo de gestin de la prestacin:
Reuniones con
gestin y desempeo de
Caso de negocio asociado suministradores.
suministradores y contratos.
la compra. Actas de las reuniones.
3 Etapa de renovacin o de
SLA firmados. Contactos entre TI y
finalizacin de contratos.
CMDB. suministrador.
3 Supervisin funcionamiento
Presupuestos. del proceso. Mejora del Actualizacin de la
propio proceso. CMDB.
Propuestas de mejora del
proceso.
Fuente: e.p. y Libro ITIL Diseo del Servicio publicado por OGC.

contratacin y desencadena la ejecucin de la nueva estrategia en relacin al aprovi-

sionamiento; una necesidad de una compra o contratacin de un servicio, remitida
desde otras reas de TI mediante la hoja de peticin de compra, para que el pro-
ceso realice la seleccin y contratacin del producto o servicio; una peticin de la
gestin de nivel de servicio (SLM) relativa a los suministradores (alineamiento de
los niveles de servicios, reunin con un suministrador, informes, etc.); y cualquier
necesidad del rea de TI en relacin a los suministradores, peticiones diversas de la
direccin de TI o de otras reas.
Las entradas relevantes de soporte o auxiliares que utiliza el proceso en el desarrollo
de su actividad son la estrategia general de sourcing de la empresa, as como, las direc-
trices para su ejecucin contenidas en las polticas de sourcing; la documentacin pre-
via generada que acompaa a la peticin de compra (RFI, RFP o SOR, el caso de
negocio justificativo de la compra, si procede, etc.); los acuerdos de nivel de servicio
firmados con los clientes, con el fin de garantizar que los suministradores son capaces
de respaldar estos niveles de servicio; informacin sobre los diversos elementos de
configuracin contenida en la CMDB; y el detalle de los presupuestos disponibles,
con el fin de ajustar las polticas y contrataciones a los lmites presupuestarios.
Se entiende como una salida principal del proceso el producto que se pretende comprar
ya suministrado y operativo, y la necesidad de un servicio externo prestndose y gestio-
nado, en tanto en cuanto el proceso tiene como misin controlar la adecuada prestacin
de los servicios y productos contratados. No es de su responsabilidad, obviamente, la
ejecucin de tareas propias de prestacin del mencionado servicio o producto.
Tambin se consideran salidas principales del proceso los contratos de soporte firma-
dos (UC); la base de datos de suministradores y contratos (SCD) creada y actuali-
zada; los diversos informes de seguimiento de los suministradores realizados (calidad
del servicio, satisfaccin, desempeo, etc.); sin olvidar la interconexin entre los siste-
mas de gestin de TI y del suministrador, en aquellos casos en los que sea necesario.
El proceso tambin genera otro tipo de salidas de menor relevancia o secundarias.
stas son la emisin de RFI, RFP o ITT al mercado para la contratacin, las reu-
niones realizadas entre suministradores y la organizacin de TI; las actas de las reu-
niones; los contactos entre TI y el personal del suministrador de soporte; la CMDB
actualizada; las propuestas de mejora del proceso; etc.
Las Normas ISO/IEC 20000 definen los siguientes requisitos introductorios para
este proceso:
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener documentados los procesos de gestin de suminis-
tradores y debe designar un gestor responsable del contacto con cada suministrador.
Los SLAs con los suministradores se deben alinear con los SLAs con el negocio.
Las interfaces entre los procesos utilizados por cada parte deben ser acordadas y docu-
mentadas.
Todos los roles y relaciones entre suministradores principales y subcontratados deben
estar claramente documentados. Los suministradores principales deben ser capaces
de demostrar que tienen procesos para garantizar que los subcontratistas cumplen
con los requisitos contractuales.
Se debe disponer de un proceso para la revisin detallada del contrato o del
acuerdo formal, con periodicidad mnima anual, que garantice que las necesidades
y obligaciones contractuales del negocio se siguen cumpliendo.
UNE-ISO/IEC 20000-2
Los procedimientos de gestin de sumi- c) los cambios son gestionados;

nistradores deberan garantizar que:
d) se registran las transacciones de
a) el suministrador entiende sus obli- negocio entre todas las partes;
gaciones frente al proveedor del
e) se puede controlar la informacin
servicio;
sobre el desempeo de todos los
b) los requisitos acordados y legtimos suministradores y actuar en conse-
son cumplidos dentro del alcance y cuencia.
los niveles de servicio acordados;
El proceso, que en este libro se inicia con la estrategia de sourcing y definicin de

las polticas de suministro y contratacin, se responsabiliza tambin de la ejecucin
de las contrataciones, para posteriormente, realizar el seguimiento de toda la pres-
tacin del servicio, hasta la necesidad de renovacin o finalizacin. En los aparta-
dos siguientes se detallan estas actividades siguiendo la estructura indicada en la
figura 7.3.10.
Estrategia Seleccin y Gestin de

Finalizacin
de sourcing contratacin la prestacin
Figura 7.3.10. Estructura del proceso de gestin de suministradores

utilizada en este libro
Estrategia de sourcing
La estrategia de sourcing forma parte de la estrategia general de TI. En la estrategia
de sourcing se definen las actividades que se realizarn internamente en la organiza-
cin de TI y las actividades que se externalizarn. Por tanto, la estrategia de sourcing
define la forma en que se cubrirn las necesidades para la creacin y prestacin de los
servicios. Abarca tanto a las reas de desarrollo como las de produccin o explota-
cin, contemplando todo tipo de funciones de TI (planificacin y control, arquitec-
tura, programacin, operacin, tcnica, etc.). Para todas ellas, se define que activida-
des se realizarn internamente y en cules se recurrir al apoyo de suministradores.
Adems, la estrategia de sourcing refleja la visin final deseada en cuanto al mapa de
suministradores, definiendo si habr una concentracin de suministradores o una
atomizacin de los mismos, el nmero idneo de suministradores deseado, etc.
La estrategia de sourcing define los tipos de servicios que puede contratar la organi-
zacin de TI. stos son de muy diversa ndole. En la figura 7.3.11 se muestran
diversos ejemplos de tipos de contrataciones que se podran realizar.
Ejemplos de contrataciones
3 Compra de hardware y software.

3 Mantenimiento de hardware y software.
3 Soporte de fabricante.
3 Proyectos llave en mano de desarrollo de software.
3 Contratos de mantenimiento de aplicativos.
3 Consultora y asesora.
3 Diseo tcnico o funcional.
3 Prestacin de servicios Body Shopping.
3 Contratacin de un servicio: comunicaciones,
ASP, provisin del PC.
3 Externalizacin de un proceso de negocio.
3 Externalizacin de una funcin o rea de TI
(call center, monitorizacin, hosting).
3 Consolidacin de proveedores.
3 Contratacin de un bloque en modo servicio.
3 Outsourcing de la administracin.
3 Renting de la infraestructura.
3 Outsourcing selectivo.
3 Outsourcing completo.
Figura 7.3.11. Diversos tipos de aprovisionamiento en la organizacin de TI

La definicin de la estrategia de sourcing contempla cinco actividades 1: la identifi-

cacin de la situacin de partida, el anlisis del mercado, el diseo de escenarios, la
realizacin del caso de negocio y la toma de la decisin de la estrategia que se debe
seguir y su implementacin. En la figura 7.3.12 se muestran estas 5 actividades.

Finalizacin
Actividades de la estrategia de sourcing
Identificacin de la estrategia de la empresa (objetivos) y anlisis de la situacin

de partida (capacidades).
Anlisis del mercado, identificacin de la oferta existente.
Diseo y anlisis de los escenarios alternativos.
Realizacin del caso de negocio.
Decisin e implementacin de la estrategia.
Fuente: Gartner y e.p.
Figura 7.3.12. Actividades en la definicin de la estrategia de sourcing
Un aspecto importante de la definicin de la estrategia de sourcing es la determina-

cin del modelo de control y supervisin del mismo ya que, si este es muy ligero
no se tendrn garantas en el cumplimiento de lo contratado, mientras que si el
control es muy pesado se generar un sobre esfuerzo de gestin importante, tanto
en el suministrador, como en la organizacin de TI.
Otro aspecto importante es la identificacin, para cada uno de los mbitos de TI,
de las actividades que deben ser retenidas y aqullas que pueden ser externalizadas.
De forma general, al efecto de delimitar el alcance de una externalizacin, las acti-
vidades de TI se pueden tipificar en: estratgicas, de control, de planificacin, de
relacin, de supervisin, de arquitectura, de diseo, de construccin, tcnicas
de detalle, de administracin, de operacin y de atencin. Para cada uno de estos
1
Documento: Best practices for creating an IT service sourcing strategy. Gartner 2007.
tipos, se debe definir cules de sus actividades se deben retener y cules se pueden
externalizar (vase el ejemplo de la figura 7.3.13).
Funciones de TI Estrategia de sourcing
Direccin Retener + consultora estratgica y coaching
Relacin Retener + personal de apoyo externo

Volumen de personas
Gestin Retener
involucradas
Control Retener
Definicin tcnica Retener + proyectos externos arquitectura
Tecnolgicas Externalizar
+ Operativas Externalizar
Figura 7.3.13. Ejemplo de un enfoque para la estrategia de sourcing

de las funciones TI
Desarrollando el ejemplo de la figura 7.3.13, si se aaden ahora en columnas las

reas que conforman la organizacin de TI (en este ejemplo se ha seguido un
esquema clsico de 4 reas: gobierno de TI, arquitectura funcional y tcnica, desa-
rrollo de software y produccin o explotacin de servicios) se tiene un mayor detalle
de las funciones que se pueden externalizar por cada rea. De esta forma, en la
figura 7.3.14 se muestra la aplicacin de una estrategia homognea de externali-
zacin de las funciones tecnolgicas y operativas tanto para el desarrollo, como
para la produccin (en este ejemplo la gestin tecnolgica y las funciones operativas
se externalizan).
En un tercer nivel de detalle (nivel de servicio), en la estrategia de sourcing se debe
definir la estrategia de suministro que se seguir y el grado de consolidacin de
suministradores objetivo. Como es lgico, el perfil de externalizacin tambin
puede variar segn el tipo de servicio de TI del que se trate. En la figura 7.3.15
se muestra otro ejemplo de estrategia de sourcing con una externalizacin fuerte, se
detalla para cada servicio de TI siguiendo el ciclo de vida del servicio. En este caso,
la estrategia para el puesto de trabajo se focaliza en la contratacin de algunos
servicios ofrecidos en forma de producto por el mercado como, por ejemplo, el puesto
cliente gestionado (suministrador A), el correo electrnico en modo servicio
Gobierno
Funciones de TI Arquitectura Desarrollo Produccin
de TI
Direccin INTERNO INTERNO INTERNO INTERNO
Relacin INTERNO INTERNO INTERNO INTERNO
Internalizado
Gestin INTERNO INTERNO INTERNO INTERNO
Control INTERNO INTERNO INTERNO INTERNO
Definicin tcnica INTERNO INTERNO INTERNO
Externalizado
Tecnolgicas EXTERNO EXTERNO EXTERNO
Operativas EXTERNO EXTERNO
Frontera tpica
de externalizacin INTERNO Internalizado EXTERNO Externalizado
Figura 7.3.14. Ejemplo de la frontera de externalizacin
Mejora
Estrategia Diseo Construccin Transicin Operacin
continua
Servicios TI
PC, LAN,
INTERNO INTERNO
ficheros
SUMINISTRADOR A
Movilidad
INTERNO INTERNO
(WIFI+RAS)
eMail INTERNO SUMINISTRADOR B INTERNO
CRM INTERNO INTERNO SUMINISTRADOR C
Facturacin INTERNO INTERNO SUM. D INTERNO SUMINIS. E INTERNO
ERP INTERNO INTERNO SUMINISTRADOR F
Comunica-
INTERNO SUMINISTRADOR G INTERNO
ciones WAN
Diversos
INTERNO Internalizado SUM. n
suministradores
Figura 7.3.15. Ejemplo de definicin de una estrategia de outsourcing selectivo

a nivel de servicio de TI, detallada segn el ciclo de vida del servicio
externo (suministrador B) o la externalizacin completa de las comunicaciones

(suministrador G). En el caso de los servicios de aplicaciones de negocio, la estrate-
gia de sourcing diferencia entre los suministradores de construccin y transicin
(suministradores C, D y F), frente al suministrador de operacin (suministrador E);
retenindose la estrategia y el diseo.
Desarrollando otro ejemplo en el mbito concreto de la operacin, las actividades
que se podran traspasar hacia el territorio de los suministradores en una estrategia
de externalizacin de las funciones operativas reteniendo la gestin y el control
seran las siguientes:
Resolucin de incidentes. La realizacin por el suministrador de funciones
en la resolucin de incidentes, como:
La atencin telefnica en el service desk.
La primera lnea de soporte.
El soporte tcnico general (segunda lnea de soporte).
El soporte especializado del fabricante (tercera lnea).
Peticiones. Una parte o el total de la gestin de las peticiones en el catlogo

de servicios por parte del usuario.
Resolucin de problemas. La participacin especializada de suministra-
dores en la resolucin de problemas.
Gestin de la configuracin. La actualizacin de los elementos de configura-
cin en los que interviene el suministrador (nuevos productos, actuaciones, etc.).
Gestin del cambio. Normalmente la participacin del suministrador pro-
viene de su intervencin en proyectos de desarrollo o de infraestructuras.
Gestin de la entrega. Algunas funciones operativas en el despliegue de
entregas.
En actividades de la gestin de la capacidad, de la disponibilidad y de la con-
tinuidad.
Infraestructuras. En el diseo de soluciones de infraestructuras, en su ope-
racin, en el soporte tcnico o en el despliegue de las mismas.
En el mbito de la estrategia de sourcing, se suele contemplar la definicin de un

conjunto de suministradores estratgicos segn el tipo de servicio que se va a con-
tratar. Se realiza una homologacin de suministradores y se establecen de tarifas en
base a un catlogo de los servicios que se pueden externalizar. As, se concretan una
serie de suministradores predefinidos de servicios homologados y caracterizados

segn las fases del ciclo de vida de los servicios de TI, asociados a las tecnologas
que conocen y a las actividades que pueden realizar. Para agilizar las tramitaciones,
con este tipo de suministradores se desarrollan unas polticas internas de contrata-
cin ms ligeras y con preautorizaciones establecidas.
La estrategia de sourcing tiene tal importancia en TI que, con frecuencia, a la lle-
gada de un nuevo director de TI, la consolidacin de suministradores o la imple-
mentacin de un tipo de outsourcing se convierten en los estandartes para una trans-
formacin radical.
Ciclo de seleccin y contratacin de productos y

servicios
Una vez definida la estrategia de sourcing entra en accin el primer ciclo de gestin
de suministradores, destinado a la seleccin y contratacin de productos y servi-
cios. Este ciclo se activa con una necesidad de compra, que surge de la ejecucin de
la cartera anual de proyectos, de un plan de capacidad o de cualquier otra demanda
puntual. Como su nombre indica, el propsito de esta actividad o ciclo es la selec-
cin de los suministradores y la adquisicin de productos y servicios.
Es importante recordar en este punto que, como se ha sealado anteriormente, la
parte del ciclo dedicada a la seleccin de suministradores no forma parte del alcance
y requisitos de las Normas ISO/IEC 20000, pero que se incluye, al igual que la
actividad anterior, a efectos de completitud en la descripcin de la gestin de sumi-
nistradores.
Este ciclo de seleccin y contratacin transcurre vinculando el rea de la empresa
encargada de gestionar las compras (normalmente externa a TI). En esta situa-
cin, la organizacin de TI acta como unidad solicitante y que presenta la nece-
sidad de la adquisicin. Ambas reas trabajan de forma estrecha en el mismo
proceso; el rea de compras gestionando y formalizando la relacin con el exte-
rior, y la unidad solicitante aportando el conocimiento tcnico relativo al objeto
de la adquisicin.
El ciclo comienza con la definicin de las especificaciones del producto o servicio
que se va a adquirir, realizadas en la etapa de diseo del servicio o en otros proce-
sos o reas de TI. Dependiendo de cada caso particular, despus de las especifica-
ciones se realizar y aprobar el caso de negocio (business case o estudio que analiza
los costes y beneficios que aporta un proyecto), se emitir una consulta al mercado
o RFI, se confeccionar la especificacin de compra o RFP, se crear la hoja de
peticin de compra, etc.
Dado que los tipos de adquisiciones gestionados pueden ser muy diversos, desde
un equipamiento sencillo, pasando por un proyecto llave en mano, hasta la contra-
tacin de un servicio de externalizacin a varios aos, es necesario que los procedi-
mientos existentes se adapten a la envergadura y criticidad de cada tipo de adquisi-
cin. En las simples y repetitivas, bastar con una sencilla hoja de peticin de
compra. En cambio, en los grandes proyectos ser necesario recorrer todas las eta-
pas: la RFI, pasando por el caso de negocio, la aprobacin de la inversin, la gene-
racin de la RFP, etc.
Incorporando la estructura de las actividades definidas en ITIL v3 a este ciclo de selec-
cin y contratacin queda un esquema como el que se muestra en la figura 7.3.16.

Finalizacin
Necesidad de TI.
RFI.
Actividades de seleccin y contratacin Caso de negocio.
RFP (SOR).
Hoja de compra.
Identificacin de la necesidad y preparacin del caso de negocio Asiento de la peticin
de compra en el ERP.
Evaluacin y provisin de nuevos contratos y suministradores Hoja seguimiento
de ofertas.
Implementacin de nuevos suministradores y contratos
Contrato (UC).
Categorizacin de suministradores y mantenimiento de la SCD Base de datos

suministradores
y contratos (SCD).
Figura 7.3.16. Principales actividades del ciclo de seleccin y

contratacin de suministradores
A continuacin se resume el alcance de estas actividades.

Identificacin de la necesidad y preparacin del caso de negocio Actividad que
realiza el rea de TI solicitante dentro del proceso de gestin de suministradores,
actuando para un nuevo proyecto de creacin o evolucin de servicios o para satis-
facer cualquier otra necesidad. En esta etapa se realiza:
La definicin de la necesidad de adquisicin.
La confeccin de la RFI, solicitud de emisin al mercado y anlisis de las res-
puestas (si procede).
La realizacin del caso de negocio o business case (si procede).

La presentacin al comit de inversiones o a la direccin de TI para su apro-
bacin (si procede).
Como se ha apuntado, la realizacin del caso de negocio o business case slo se reco-
mienda en las grandes inversiones. Se analizarn las alternativas, los costes y los
beneficios del proyecto tanto para el negocio, como para la organizacin de TI.
Una vez realizado, el comit de inversiones o la direccin de TI decidirn si es id-
neo llevarlo a cabo y la alternativa ms adecuada. El caso de negocio y la gestin de
la aprobacin del presupuesto asociado los suele realizar el rea proponente traba-
jando para el proceso de gestin de suministradores. La estructura y el contenido
tipo de un caso de negocio deben estar estandarizados en la organizacin para evi-
tar reinventar continuamente la rueda y reducir el tiempo de su confeccin. Para la
realizacin de los casos de negocio se necesita informacin de los costes unitarios y
totales de la actividad, de los mantenimientos, de las amortizaciones, etc. Esta
informacin analtica de los costes conviene recogerla y mantenerla centralizada
para los diversos estudios que se realicen. En la figura 7.3.17 se muestra un ejem-
plo de estructura de un caso de negocio.
De forma previa a la realizacin del caso de negocio, puede ser necesario hacer una
consulta o peticin de ideas (RFI) a los proveedores principales, que pudieran dar
una orientacin sobre la solucin ms adecuada. La RFI permite realizar una pros-
peccin del mercado en un mbito en el que no se tiene experiencia y, en cierta
manera, ahorra la contratacin de una consultora externa. La RFI tambin la rea-
liza el rea proponente de la compra y, en contra de la prctica habitual, siempre lo
debe remitir al mercado el rea de compras, ambas trabajando bajo este proceso de
gestin de suministradores.
Evaluacin y provisin de nuevos contratos y suministradores. Esta etapa se

centra en desarrollar el proceso de contratacin, que finaliza con la licitacin adju-
dicada a un suministrador y el contrato formalizado. Las actividades que se suelen
contemplar (inspiradas en ITIL v3) son las siguientes:
Creacin de la especificacin de compra o RFP, documento que se enviar a
los suministradores candidatos.
Preparacin de la hoja de peticin de compra, documento interno con los
datos de centros de coste, plazos, estimacin de recursos y presupuesto de la
compra.
Registro de la peticin de compra en el sistema de gestin de la empresa
(ERP) para su aprobacin presupuestaria.
Estudio de negocio (business case )
3 Descripcin del alcance:

Breve descripcin y funcionalidades.
Objetivos a alcanzar.
mbito de aplicacin y relaciones con otros
servicios.
mbito temporal.
3 Justificacin de la necesidad.
3 Tendencias del mercado. Referencias externas.
Benchmarking externos.
3 Presentacin de alternativas o soluciones posibles.
Realizacin interna-externa, compra-desarrollo.
3 Estimacin del coste total de propiedad a 3 o 5 aos
de cada alternativa.
3 Beneficios cualitativos esperados.
3 Beneficios cuantitativos esperados.
3 Anlisis de escenarios posibles y riesgos
3 Recomendaciones y conclusiones.
3 Anexos:
Costes totales y unitarios del negocio.
Costes totales y unitarios de TI.
Figura 7.3.17. Ejemplo de la estructura de un caso de negocio

para un proyecto importante
Envo de la peticin de compra al rea de compras. Recepcin, registro y

validacin de la hoja de peticin de compra.
Identificacin del mtodo de compra o del suministro ms adecuado.
Establecimiento de los criterios de evaluacin: calidad, coste, capacidad de
ejecucin, experiencia, etc.
Seleccin de posibles suministradores.
Remisin de la RFP (por el rea de compras) a los proveedores selecciona-
dos para que concursen, se especifica un perodo de preguntas.
Recepcin de ofertas, revisin y homogeneizacin de las mismas (si es nece-

sario).
Evaluacin de las ofertas, en sus aspectos tcnicos y comerciales. La evalua-
cin tcnica la realiza el rea proponente, mientras que la comercial la realiza
el rea de compras. Realizacin de las hojas de seguimiento de ofertas.
Como resultado de la evaluacin se obtiene si una oferta es adecuada o no, y
cunto es mejor una oferta que otra, expresada en un diferencial econmico,
tcnico o mixto.
Negociacin de las ofertas y adjudicacin a un suministrador.
Negociacin del contrato, objetivos, trminos y condiciones.
Acuerdo y formalizacin del contrato.
En adquisiciones importantes es extremadamente importante la elaboracin de un

documento con las especificaciones detalladas de la compra que se va a realizar
(RFP o SOR). Normalmente, la RFP es relativa a la contratacin de servicios, aun-
que tambin se debe realizar para grandes compras de equipamiento. En la RFP se
definen todas las caractersticas del servicio que se pretende adquirir: alcance, des-
cripcin de los servicios a prestar, entorno en el que se prestarn los servicios, equi-
pamiento involucrado, niveles de servicio a cumplir, resultados a entregar, condi-
ciones de prestacin, penalizaciones, etc. La estructura de la RFP debe estar
tipificada y adaptada al tipo de compra, por ejemplo, un desarrollo llave en mano,
un proyecto de consultora, un servicio de externalizacin de las operaciones, etc.
El escenario en el que la RFP alcanza su mximo esplendor y relevancia es en la
contratacin de servicios de outsourcing. En este caso, la confeccin de la RFP pude
llevar varios meses, en los que se realiza un inventario previo de todos los elemen-
tos que se van a gestionar (denominado lnea base o baseline) y se especifica con
detalle los servicios a recibir. Este documento ser parte integrante del contrato
posterior. En la figura 7.3.18 se muestra un esquema ejemplo de una RFP enfo-
cada a la externalizacin de un servicio.
La RFP se confecciona por el rea solicitante y su preparacin se considera una
actividad propia de este proceso (ITIL v3 la enmarca en el libro Diseo del Servicio).
Es importante recalcar que la comunicacin con el entorno exterior siempre se
debe realizar de forma canalizada a travs la unidad de compras. Las diversas reas
de TI no debern enviar por su cuenta ningn tipo de comunicado o documenta-
cin para la contratacin a los futuros suministradores, ni siquiera la RFI.
El ltimo documento que debe realizar el rea solicitante es una peticin interna de
compra, expresada en forma de hoja de peticin de compra. Esta peticin adjunta
Especificacin de compra
(RFP o SOR) enfocada
a una externalizacin
3 Trminos bsicos y condiciones: 3 Condiciones comerciales:

Objetivo y alcance. Coste del servicio y forma de pago.
Duracin del contrato.
3 Penalizaciones:
Definiciones.
Penalizaciones e incentivos.
SLA y OLA de referencia. Rgimen de pago variable
Estndares a cumplir. segn cumplimiento.
Partes implicadas: suministrador,
3 Responsabilidades y dependencias:
unidad TI.
Responsable de planificacin e
3 Descripcin del servicio a contratar: implantacin de servicios nuevos o
Objetivo y alcance del servicio. modificados.
Funcionalidades del servicio. Responsable de nivel de servicio.
mbito de aplicacin y relaciones Proveedores de servicios externos.

con otros servicios.
3 Requisitos para la etapa de
3 Caractersticas del servicio transicin.
a contratar: 3 Etapa de finalizacin del contrato.
Funcionales.
3 Inventarios base (baseline).
Horario de servicio y soporte,
disponibilidad y fiabilidad. 3 Informacin que se requiere del
oferente.
Niveles de servicio pactados.
Rangos para la carga de trabajo. 3 Criterios para seleccin o
Continuidad y seguridad, descalificacin de propuestas.
rendimiento. 3 Fechas relevantes, incluyendo las
Modelo relacin e interfaces de apertura y cierre del proceso.
tcnicas. Fechas para entrevistas y visitas.
Explotacin y operacin, etc. 3 Requerimientos de confidencialidad.
3 Mecanismos de control y seguimiento 3 Elementos legales del contrato.
del servicio:
Etc.
Indicadores y mtricas para
controlar los niveles de servicio.
Informes de gestin.
Figura 7.3.18. Ejemplo de RFP para la contratacin

de un servicio de externalizacin
toda la documentacin previa que ha debido preparar el rea de TI solicitante.

Dependiendo del tipo y de la importancia de la adquisicin puede contener los
resultados de la RFI, el caso de negocio, la decisin del comit de inversin, la
especificacin de la compra RFP o SOR, la documentacin del proyecto, etc.
Recuerde que no es necesario realizar todos estos documentos en todas las adquisi-
ciones. En las polticas de creacin de nuevos servicios y en las de gestin de sumi-
nistradores se determinarn qu tipo de documentacin se debe generar en cada
tipo de adquisicin.
La peticin de compra y su presupuesto se introducen en el sistema de gestin
general de la empresa (ERP) para su ciclo de aprobacin formal.
La hoja de peticin de compra, generada por el rea de TI solicitante, desencadena
el resto del ciclo de seleccin y contratacin. El primer paso ser la generacin de
una hoja o ficha de seguimiento de las ofertas, que esta vez realiza y mantiene el
rea de compras. Esta hoja contiene todos los datos resumidos de la adquisicin y
de las diversas ofertas recibidas. Incluye el detalle de los precios y de los contenidos
tcnicos de las diversas ofertas. Mantendr un mismo formato para registrar todas
las ofertas, de esta forma, se homogeneiza y sintetiza en una ficha toda la informa-
cin remitida por los suministradores en sus diversas ofertas. En adquisiciones
complejas, se puede descargar parte de este trabajo en el suministrador exigindole
que consigne los datos bsicos de la adquisicin en el formato especificado para
esta ficha. Como se ha indicado, la ficha de seguimiento de las ofertas tambin
incorpora las valoraciones tcnicas y comerciales realizadas. Quiz la forma ms
sencilla de almacenar estas fichas sea en archivos de hoja de clculo.
En la figura 7.3.19 se muestra la estructura ejemplo de una hoja de peticin de
compras y de una hoja de seguimiento de ofertas.
Establecimiento de nuevos suministradores y contratos. El propsito de esta

actividad es garantizar no slo la correcta recogida y gestin de los contratos for-
malizados como resultado de la actividad anterior, sino tambin garantizar que se
tienen en cuenta otros aspectos fundamentales en la relacin con los suministrado-
res seleccionados (por ejemplo, el riesgo asumido por ambas organizaciones),
como paso previo a su incorporacin formal al registro de suministradores.
A efectos prcticos, tomando como referencia lo especificado por ITIL v3, el con-
junto de tareas objeto de la presente actividad son las siguientes.
Incorporacin del servicio del suministrador y del contrato, tanto dentro de
la base de datos de suministradores y contratos (SCD), como en el resto de
sistemas corporativos que as lo requieran (por ejemplo, en el sistema de ges-
tin de recursos o ERP).
Hoja de peticin de compra Hoja seguimiento de ofertas
3 Ttulo de la compra. 3 Ttulo de la compra.

3 rea proponente y persona de 3 Hoja de peticin de compra asociada.
contacto.
3 Histrico de ofertas recibidas en
3 Cdigo de gasto y presupuesto el proceso de negociacin por cada
asignado. proveedor, con el detalle de precios
y caractersticas.
3 Fechas y plazos a cumplir en la
compra. 3 Tabla desglose y comparativa
de precios.
3 Breve descripcin y justificacin de
la compra. 3 Valoracin tcnica y comercial de
las ofertas recibidas.
3 Detalles y volumetras de la compra
(perfiles a contratar, nmero de 3 Personal interviniente en el proceso:
jornadas, etc.). Clculo estimativo propio y de los suministradores
del presupuesto.
3 Documentacin remitida por los
3 Proveedores propuestos. suministradores concursantes.
3 Antecedentes y condicionantes de 3 Modelo de negociacin seguido.
la compra.
3 Documentacin asociada a la compra:
proyecto, caso de negocio, RFI
anteriores, RFP o SOR, etc.
3 Comentarios y aclaraciones.
Elaborada por el rea TI proponente Elaborada por el rea de compras
Figura 7.3.19. Ejemplo de estructura de las hojas de peticin de compra

y de seguimiento de ofertas
Establecimiento de los contactos y relaciones. Designacin de interlocutores

e implementacin del resto de mecanismos para la gestin de la relacin.
Transicin del servicio. Fase transitoria en la que el nuevo suministrador
asume el servicio, se integran procedimientos y se interconectan las herra-
mientas de gestin. En esta fase los niveles de servicio suelen ser menos
exigentes que en la etapa de prestacin del contrato. Las actividades que se
realizan van desde la codificacin hasta la integracin, pruebas, elaboracin
de documentos de uso, traducciones, revisiones de documentacin o de usa-
bilidad, etc.
De acuerdo con lo especificado en las Normas ISO/IEC 20000, toda incorpora-

cin de nuevos suministradores o contratos, as como la modificacin de los mis-
mos, ser gestionada por el proceso de gestin del cambio, de tal forma que se ase-
gure que se evalan y se comprenden todos los posibles impactos. El proceso
de gestin de suministradores acta como propietario de la SCD (base de datos de
suministradores y contratos) fuente principal de informacin para la ejecucin
de sus actividades.
Categorizacin de suministradores y mantenimiento de la SCD. Esta etapa se

centra en la categorizacin y evaluacin de los suministradores para poner foco en
la gestin de los contratos importantes frente a los menos importantes. Como
resultado de la evaluacin y categorizacin de suministradores, tambin es respon-
sabilidad de esta actividad asegurar el mantenimiento actualizado de la base
de datos de suministradores y contratos (SCD). Igual que en el caso anterior, de
acuerdo con lo descrito por ITIL v3, las tareas principales de esta actividad son:
Categorizacin de los suministradores. Se recomienda realizarlo en funcin
de dos ejes: su valor-importancia y su riesgo-impacto. As, se obtiene de
forma general una categorizacin que permite dosificar el esfuerzo y las
actuaciones, en los siguientes tipos:
Estratgicos. Contempla alianzas y relaciones a largo plazo.
Tcticos. Para aquellos suministradores con relaciones que involucran
gran volumen de actividad e interacciones de negocio.
Operacionales. Para los suministradores de productos y servicios opera-
cionales.
Bsicos (commodity). Para los suministradores de productos y servicios de
bajo valor fcilmente suministrables, ya sea por la naturaleza del suminis-
tro o bien por la abundancia de suministradores.
Evaluacin o reevaluacin del suministrador y del contrato, obteniendo una
calificacin de su desempeo, y un registro de los xitos y conflictos.
Actualizacin de la SCD.
Mantenimiento continuo de la SCD.
La base de datos de suministradores y contratos (SCD)

Esta base de datos aloja todo el conocimiento existente sobre los suministradores y
sobre los contratos efectuados. La SCD debe almacenar informacin til para la
gestin de cada contrato, producto o servicio, y de los suministradores. Debe alo-

jar los archivos con la versin firmada de los contratos, informacin sobre el his-
trico de la relacin con el suministrador, los servicios contratados a cada uno, los
niveles de servicio, los costes, las fechas de renovacin, las personas de contacto, el
personal de TI que ha ido participando en la relacin, los principales xitos y con-
flictos, etc.
La SCD se compone, como mnimo, de dos estructuras lgicas: las fichas de los
suministradores y las fichas de los contratos. En la figura 7.3.20 se muestra un
ejemplo del contenido de una SCD.
Estructura de la base de datos de

suministradores y contratos (SDC)
Fichas de suministradores:
3 Cdigo y nombre del suministrador.
3 Contactos principales.
3 Contratos realizados.
3 Volumen total contratado por ejercicios.
3 Valoracin del suministrador.
Fichas de contratos:
3 Cdigo y ttulo del contrato.
3 Servicios contratados. Descripcin.
3 Niveles de servicio a cumplir.
3 Importe contratado.
3 Fechas y perodo del contrato.
3 Fecha lmite para la comunicacin de la terminacin
del contrato.
3 Valoracin de los resultados del contrato.
3 xitos y conflictos surgidos.
Relaciones:
3 Tipos de relaciones y procedimientos.
3 Interlocutores para cada una de ellas.
3 Interfaces entre herramientas.
3 Histrico de la relacin.
Figura 7.3.20. Estructura ejemplo de la SCD

Contratos de Soporte (UC, Underpinning Contracts)
Dentro de los diversos tipos de contratos existentes entre la organizacin de TI y

sus suministradores destaca la figura tradicional de los contratos de soporte (UC),
pues son los que extienden la organizacin de TI para delegar una parte de la pres-
tacin de los servicios en empresas externas. El foco principal en estos contratos es
reflejar todos los acuerdos en el proceso de negociacin, con especial nfasis en la
alineacin con los niveles de servicio comprometidos por la organizacin de TI con
los clientes.
UNE-ISO/IEC 20000-1
Los requisitos, alcance, nivel de servicio y procesos de comunicacin a ser propor-

cionados por el suministrador(es) se deben acordar por todas las partes y documen-
tar en los SLAs u otros documentos.
Los SLAs con los suministradores se deben alinear con los SLAs con el negocio.
El contrato de soporte es un documento vinculante legalmente entre la organizacin

de TI y un suministrador externo, por tanto utilizar el formato de contrato habitual
de la empresa, o en su defecto usar el propuesto por el suministrador. Este contrato
define el objetivo, alcance y caractersticas del servicio que se va a prestar.
El contrato de soporte debera reflejar conceptos similares a los SLA utilizados, en
la figura 7.3.21 se muestra un ejemplo de su estructura.
Ciclo de gestin de la prestacin de los servicios

contratados
Una vez cerrado el contrato con el suministrador se inicia la prestacin de los servi-
cios contratados. Hay que tener en cuenta que la etapa de transicin al nuevo servi-
cio se realiza en el ciclo anterior de seleccin y contratacin (siguiendo ITIL v3).
Con el fin de garantizar la eficiencia del da a da en la prestacin de los servicios
del suministrador, aparece el ciclo de gestin de la prestacin, que sin interponerse
en la realizacin de las actividades del da a da, estructura, organiza y supervisa
todo lo necesario para que la prestacin sea efectiva.
As, este ciclo desarrolla una funcin transversal para todos los otros procesos de TI,
pero sin afectar a la realizacin del flujo de trabajo diario. Se encarga de articular y
Contenidos de un contrato de soporte (UC)
Contrato redactado en trminos contractuales

3 Alcance del contrato.
3 Horarios y niveles de servicio.
3 Condiciones comerciales.
3 Penalizaciones.
3 Responsabilidades y dependencias.
3 Procedimientos de revisin y seguimiento
del contrato.
3 Gestin de conflictos.
3 Requisitos para la etapa de transicin.
3 Etapa de finalizacin del contrato. Obligaciones.
3 Confidencialidad y derechos de propiedad
intelectual.
3 Anexos:
Inventarios base (baseline).
Contenido completo del RFP.
Figura 7.3.21. Contenido tipo de los contratos de soporte (UC)
desplegar lo necesario para que este flujo sea efectivo: reuniones, interlocutores,
herramientas, interfaces, procedimientos, escalados, etc. Por tanto, ste es un ciclo o
subproceso que prepara los conectores entre la organizacin de TI y sus suminis-
tradores, para supervisar posteriormente su funcionamiento.
En las Normas ISO/IEC 20000 se establecen unos requisitos muy bsicos para la
gestin de la prestacin del servicio del suministrador:
UNE-ISO/IEC 20000-1
Se debe monitorizar y revisar el comportamiento y las prestaciones frente a los

objetivos de nivel de servicio. Las acciones de mejora identificadas durante este
proceso se deben registrar y utilizar como informacin de entrada al plan de
mejora del servicio.
UNE-ISO/IEC 20000-2
Definicin del servicio c) un proceso de gestin de contra-

tos, los niveles de autorizacin y
Para cada servicio y suministrador el pro- un plan de extincin del contrato;
veedor del servicio debera mantener:
d) las condiciones de pago, si son
a) una definicin de servicios, roles y relevantes;
responsabilidades;
e) los parmetros de informe y el re-
b) el alcance del servicio; gistro acordados sobre el desem-
peo alcanzado.
Como se ha mencionado anteriormente, hay grandes diferencias entre la importan-

cia y los alcances entre los diferentes contratos. Por ello, la gestin de los suminis-
tradores se llevar con ms o menos intensidad, adecundose al tipo y la relevancia
de la funcin contratada en cada uno de ellos (resultado de la categorizacin de
suministradores y contratos de la actividad anterior).
Los principales mecanismos que articula este ciclo, necesarios para que sea efectivo
el flujo entre la organizacin de TI y las organizaciones de los suministradores son
los siguientes:
Escalados. Al igual que en el caso del proceso de gestin del incidente, aqu tam-
bin existe el concepto de escalado, en sus dos versiones, funcional y jerrquica. El
escalado funcional corresponde al traspaso de trabajos entre los grupos funcionales,
bien entre la organizacin de TI y los suministradores o bien entre ellos mismos.
En el escalado jerrquico se remite informacin hacia instancias superiores, para
poner en conocimiento o para la toma de decisiones. El escalado jerrquico tam-
bin es la primera etapa en la resolucin de discrepancias y conflictos en la relacin.
En ambos casos, las rutas de escalado deben estar previamente definidas y procedi-
mentadas.
Herramientas. Definicin e implementacin de las herramientas para el soporte
del flujo de trabajo. Las diversas soluciones de integracin entre las herramientas
pueden ir desde permitir el acceso del suministrador a las herramientas internas de
TI, hasta una interconexin entre las herramientas de ambas organizaciones.
Informes. Informacin peridica sobre la actividad y desempeo del suministra-
dor en relacin a los servicios contratados. Los informes contienen informacin
cuantitativa (indicadores o mtricas) sobre volumetras de los trabajos, sobre la
calidad de los mismos y sobre los niveles de los servicios prestados. Adems, los
informes incorporan informacin descriptiva de la actividad realizada en el perodo
y del grado de avance de proyectos y trabajos de plazo ms largo.
Interfaces. Como parte de la definicin de las herramientas, aparecen las interfaces

para el traspaso de trabajos e informacin entre la organizacin de TI y del sumi-
nistrador. Las interfaces pueden ser automatizadas, interconexionando las herra-
mientas (traspaso de tickets de incidentes, de ordenes de trabajo, informacin de
configuracin, etc.), semiautomticas (por ejemplo, a travs del correo electr-
nico), o manuales (por ejemplo, el contacto por telfono). Segn el volumen del
flujo que se gestionar se decidir la interfaz ms adecuada a cada caso.
Interlocucin. Definicin de los niveles de interlocucin entre las personas de
ambas organizaciones. Definicin de los roles de interlocucin y la designacin for-
mal de las personas que desempearn estas funciones. Se deben definir los puntos
de contacto (touch points) entre ambas organizaciones y las funciones que desempe-
ar cada uno de ellos.
Monitorizacin del desempeo. Seguimiento continuo de los principales indica-
dores definidos para el control de la prestacin del servicio contratado.
Procedimientos. Definicin del procedimiento para la gestin del flujo de trabajo
entre ambas organizaciones, junto a la definicin de cmo fluirn todos los proce-
sos de gestin del servicio (incidente, cambio, entrega, etc.) entre ambas organiza-
ciones. La estandarizacin de los procesos de TI, proporcionada por la amplia
aceptacin de ITIL en el mercado, hace mucho ms sencilla la extensin de un pro-
ceso (por ejemplo, la gestin del incidente) entre la organizacin de TI y los sumi-
nistradores. Adems, puestos en la perspectiva de un suministrador que presta ser-
vicio a mltiples organizaciones de TI clientes, ITIL les permite mantener unos
procesos nicos que enganchan perfectamente con los procesos de sus clientes.
Programa de mejora del suministrador (SIP). Las acciones de mejora identifica-
das se incorporan en un plan de mejora con cada suministrador. Al igual que en la
gestin de nivel de servicio (vase el apartado 6.1), a estos planes de mejora de
los servicios proporcionados por el suministrador tambin se les denominan SIP
(Service Improvement Program), y se coordinan de forma conjunta en el Plan de
mejora unificado de los procesos y de los servicios (vase el captulo 4).
Reuniones. Establecimiento de las reuniones como instrumentos de supervisin,
decisin y reporte. En los contratos de prestacin de servicios continuos de una
cierta importancia, las reuniones se suelen estructurar en tres niveles:
Comit ejecutivo del contrato. rgano mximo de decisin. Se suele reu-
nir con carcter trimestral. En contratos muy grandes, tambin se suele ins-
trumentar un comit de seguimiento econmico.
Comit de seguimiento del servicio. Grupo mixto en el que se sigue men-
sualmente la evolucin del servicio, del cumplimiento de los niveles de servi-
cio contratado y de los principales trabajos.
Grupos de trabajo. Equipos de trabajo especializados en una temtica o

actividad especfica. Creados ad hoc para resolver una problemtica determi-
nada o de forma permanente (de tecnologa, de arquitectura, etc.).
Revisiones del servicio. Anlisis y reuniones peridicas realizadas para comprobar

el cumplimiento de compromisos y la identificacin de acciones de mejora por
ambas partes.
Una vez identificados estos mecanismos anteriores, necesarios para que el flujo de
informacin y trabajo entre ambas organizaciones sea eficaz, se debe definir el con-
junto de actividades principales que componen este ciclo de prestacin (para ello,
se ha considerado importante seguir la definicin de ITIL v3). En la figura 7.3.22
se muestran las principales actividades de este ciclo.

Finalizacin
Actividades gestin de la prestacin
Gestin y control de la operacin y del suministro de productos y servicios.

Monitorizacin y generacin de informes.
Revisiones y mejora.
Gestin del suministrador y de la relacin.
Revisin peridica de los objetivos del servicio frente a las necesidades del
negocio, objetivos y acuerdos.
Planificacin para posible cierre, renovacin o extensin.
Figura 7.3.22. Principales actividades de la gestin de la prestacin

de los suministradores
Gestin y control de la operacin y del suministro de productos y servicios. La

prestacin de los servicios, y en general las actividades del da a da implican la parti-
cipacin de dos organizaciones diferentes, que en la mayora de los casos cuentan
con procesos operacionales diferentes. El foco de esta actividad es garantizar la reali-
zacin eficiente de las mencionadas actividades del da a da. Para ello revisa los atas-
cos y los retrasos en las peticiones y rdenes de trabajo diarias, controla la calidad de
los productos o servicios recibidos, integra los servicios recibidos de los suministra-
dores con los servicios de TI ofrecidos a las reas cliente, y supervisa de forma conti-
nua el funcionamiento de las herramientas y las interfaces para garantizar que el tra-
bajo fluye con normalidad.
Para asegurar una correcta relacin con los suministradores es fundamental el esta-
blecimiento de conductos de comunicacin eficientes, que permitan a ambas partes
profundizar en su conocimiento mutuo. De esta forma, la interrelacin para la
prestacin diaria de los suministradores se suele articular en base a tres tipos de uni-
dades de informacin que fluyen hacia los suministradores:
Tickets. Traspaso de tickets de incidentes y peticiones de servicio recogidas
en el catlogo de servicios, que normalmente provienen directamente del
contacto con el usuario.
rdenes de trabajo. Envo de rdenes de trabajo o peticiones, que son
generadas por la organizacin de TI para solicitar trabajos al suministrador
(cambios, informes, actuaciones, etc.).
Proyectos. Actividades de mayor envergadura y complejidad que suelen
contener unos objetivos, una planificacin, unos compromisos, una direc-
cin especfica, un presupuesto determinado, etc. Los proyectos pueden ser
de todo tipo: de desarrollo de software, de arquitectura, de diseo, de plata-
forma tecnolgica, etc.
Dependiendo del nivel de externalizacin o del alcance de cada contrato, la gestin

de la prestacin vara mucho. En contratos de adquisicin de hardware o productos
software, termina una vez entregado e instalado el producto la prestacin del sumi-
nistrador. Los contratos de mantenimiento tienen algo ms de penetracin en la
actividad diaria (incluyendo la garanta). En los contratos de soporte tcnico de los
fabricantes slo se activan en casos espordicos de necesidad ante averas o proble-
mas tcnicos con sus plataformas. En el extremo opuesto de intensidad en la inter-
accin con el da a da aparecen los contratos de externalizacin de un servicio o de
una funcin de TI. En ellos, los flujos de trabajo son constantes entre la organiza-
cin de TI y los diversos suministradores.
As, dependiendo del perfil de externalizacin y del nmero de suministradores,
vara bastante el flujo diario de la actividad que cruza las fronteras de las organiza-
ciones. En todo momento, y a efectos puros de certificacin bajo las Normas
ISO/IEC 20000, es necesario mantener el control de su gestin.
Hay que tener cuidado en que la gestin de la operacin del suministrador no se
interponga entre las reas operativas de ambas partes, sino que supervise el flujo
desde el exterior, para detectar atascos y malos rendimientos.
Monitorizacin y generacin de informes (del servicio, calidad y costes). Se realiza

el seguimiento de la actividad y de los resultados mediante indicadores sobre la pres-
tacin de servicios y sobre la entrega de productos. La misin principal es contrastar
que los niveles de servicio recibidos cumplen lo requerido en el contrato. Por tanto, la
monitorizacin tiene el objetivo de comprobar que el suministrador cumple con
lo pactado. Si en el contrato se contempla una tarifa variable o unas penalizaciones en
funcin de unos indicadores, la monitorizacin es el instrumento de medicin.
Tambin se generan los informes peridicos definidos asociados al seguimiento del
servicio y del suministrador. La periodicidad de los informes con los suministrado-
res se marca segn la importancia de los servicios contratados, y siempre alineados
con los informes ms globales del servicio de TI. En su amplitud mxima los infor-
mes comprenden:
Semanal. En los informes semanales se realiza el seguimiento y control de la
actividad del suministrador en la semana, normalmente el avance de proyec-
tos crticos, volumetras de resolucin y los principales eventos de la semana.
Mensual. Recoge un cierre del mes, con los principales indicadores, avance
de los proyectos e hitos globales del suministrador.
Trimestral. Recoge un seguimiento de aquellos ratios anuales sobre los que
conviene realizar un seguimiento ms de cerca de cara a emprender acciones
correctoras en caso de desviaciones negativas.
Anual. Refleja los principales parmetros del suministrador y su contribu-
cin a los indicadores generales de TI. Normalmente se contemplan: varios
ratios de coste medio, mtricas de volmenes de trabajo (medido por usua-
rio), cumplimientos de plazos, cumplimientos de objetivos, etc. Se utilizan
para medir el logro de los macroobjetivos definidos en la estrategia del ao
bajo consideracin (en curso o cerrado y objeto de revisin) y para definir la
nueva estrategia.
Revisiones y mejora (del servicio, calidad y costes). De forma peridica se debe

realizar un anlisis del desempeo del suministrador, contemplando tanto la canti-
dad de servicios y productos entregados, como los niveles de servicio, plazos, cali-
dad y los costes. Con estas revisiones, consensuadas entre ambas partes, se identifi-
can diversas acciones de mejora y se crea un programa de mejora del servicio
prestado (SIP) por el suministrador. En las revisiones se debe comprobar no slo
el servicio en s mismo, sino cmo contribuye en la cadena de aseguramiento del
servicio final de TI hacia los clientes.
En las revisiones se debe poner foco tambin en aprender de las mejores prcticas
del suministrador para evitar imponerle prcticas menos efectivas.
Gestin del suministrador y de la relacin. Comprende la gestin de las relacio-

nes, de los contratos y de las discrepancias surgidas. Atiende los escalados verticales
por discrepancias, y mantiene los contactos a nivel de gestin y de direccin por
ambas partes. Se suele realizar en el mbito del comit de seguimiento del servicio.
En esta actividad se marca una pauta de reuniones peridicas (quincenales o mensua-
les) de este comit. En la gestin de discrepancias es importante la resolucin tem-
prana de conflictos, para que stos no afecten al servicio o contaminen la relacin.
Con respecto a la gestin de contrato en vigencia se realiza:
El seguimiento del cumplimiento de los trminos y condiciones del contrato.
La revisin de las facturas.
La aprobacin de los pagos.
La negociacin de las revisiones del contrato.
La gestin de los cambios al contrato (va proceso de gestin del cambio).
El entendimiento de la cultura de ambas organizaciones y de la forma de trabajar

de cada una de ellas, permitir un planteamiento de la relacin ms acorde con la
realidad y proporcionar unos mejores resultados a ambas partes por el adecuado
entendimiento de necesidades y capacidades (gestin de expectativas). Tambin se
debe poner foco en que las vas de comunicacin fluyan y, sobre todo, que los nive-
les directivos estn disponibles y dediquen el tiempo necesario para la toma de
decisiones en el momento adecuado.
A este respecto las especificaciones de las Normas ISO/IEC 20000 aportan una for-
malizacin a la relacin contractual:
UNE-ISO/IEC 20000-1
Los cambios al contrato(s), si existen, y los SLAs deben ser el resultado de estas revi-
siones o de aquellas requeridas en cualquier otro momento. Cualquier cambio debe
estar sujeto al proceso de gestin del cambio.
UNE-ISO/IEC 20000-2
Gestin de contratos todo un grupo de personal involucrado

en esta tarea, debera existir un proceso
El proveedor del servicio debera desig- comn para asegurar que la informacin
nar un responsable para hacerse cargo sobre el desempeo de los suministrado-
de los contratos y acuerdos con los res est controlada y se acta conse-
suministradores. En el caso de que haya cuentemente.
Debera existir una persona de contacto El proceso para la modificacin de con-

definida dentro de la organizacin del tratos debera estar tambin claramente
proveedor del servicio que sea el res- definido. Cualquier cambio a este proce-
ponsable de la relacin con cada sumi- dimiento se debera notificar formalmente
nistrador. a todos los suministradores afectados.
Todos los contratos con suministradores Se debera mantener una lista de puntos
deberan contener una planificacin de de contacto dentro de las respectivas
las revisiones para evaluar si los objeti- organizaciones (la del suministrador y la
vos de negocio para el suministro de un del proveedor del servicio). Si un contrato
servicio siguen siendo vlidos. incluye penalizaciones o bonificaciones,
Debera existir un proceso claramente se deberan establecer claramente sus
definido para la gestin de cada con- fundamentos y elaborar un informe del
trato. cumplimiento de los requisitos.
Revisin peridica de los objetivos del servicio frente a las necesidades del
negocio, objetivos y acuerdos. Se suele realizar en el mbito del comit ejecutivo.
Se identifican los puntos conflictivos, el desempeo de los interlocutores y se rea-
liza la revisin de todos los indicadores comprometidos. Su periodicidad suele ser
trimestral, con los suministradores esenciales, y anual con el resto. Tambin se
deben replantear si los objetivos contratados estn alineados con las necesidades
de TI y del negocio.
En este mbito se llevan a cabo dos tipos de revisiones formales: la revisin del
desempeo del suministrador (en base a revisiones del servicio) y la revisin del con-
trato (del rendimiento, de los escalados, los costes, las variaciones en la demanda, las
mejoras al servicio, la opinin de los clientes, etc.).
Planificacin para posible cierre, renovacin o extensin. Toda la actividad dia-
ria debe estar concebida para que se retenga el conocimiento, de esta forma, la
dependencia de un suministrador determinado es menor. Adems de esto, con la
anticipacin necesaria (normalmente 3 meses antes) se debe decidir si se continuar
con el servicio, se proceder a su renovacin y en qu mbitos se modificar su
alcance. En funcin de la decisin tomada, se iniciarn las acciones de recopilacin
de informacin, auditoras necesarias, denuncia del contrato, etc.
Etapa de finalizacin del contrato

La etapa de finalizacin del contrato est tambin reglada en ISO/IEC 20000, en
el que se requiere que exista un procedimiento para la finalizacin de un servicio
contratado, bien sea por que se alcance la fecha de trmino del contrato (terminacin
normal) o de forma anticipada. Tambin se debe contemplar la transferencia a un

tercero o la reabsorcin por parte de la organizacin de TI.
UNE-ISO/IEC 20000-1
Debe existir un proceso para gestionar la finalizacin normal o anticipada de un

servicio, o la transferencia del mismo a un tercero.
UNE-ISO/IEC 20000-2
El proceso de gestin de contratos debe- Tambin debera proporcionar un meca-

ra contemplar la extincin del contrato nismo de transferencia del servicio a otra
(tanto planificada, como prematura). organizacin.
Conviene aclarar que este proceso de gestin de contratos, mencionado en

ISO/IEC 20000-2, forma parte del proceso de gestin de suministradores, pues es
uno de los requisitos especificados en ISO/IEC 20000-1, aunque no se le da el
nombre formal de gestin de contratos.
Las principales actividades de la etapa de finalizacin del contrato se muestran en
la figura 7.3.23.

Finalizacin
Actividades de finalizacin del contrato
La revisin del contrato.

La renegociacin o cierre del contrato.
Figura 7.3.23. Principales actividades de la fase de finalizacin del contrato
Llegada la fecha en la que el contrato finaliza, se deben realizar dos acciones princi-
pales (segn ITIL v3).
La revisin del contrato. Antes de la finalizacin del contrato se debe realizar un

anlisis y revisin de los resultados obtenidos y del transcurso del contrato. Esta
revisin se realiza desde una visin ms alejada de las turbulencias del da a da, con
la perspectiva de la distancia, para poder tener una valoracin justa de los resulta-
dos obtenidos y poder recomendar las acciones para las nuevas contrataciones.
La renegociacin o cierre del contrato. Si se ha decidido continuar el contrato se ini-
cia una nueva fase de contratacin, entrndose de nuevo en el ciclo de seleccin y con-
tratacin. Si la decisin es de finalizacin o terminacin del contrato, se deben activar
las clusulas de expiracin. Como se ha debido planificar previamente la finalizacin del
mismo, la ejecucin del cierre ser ms sencilla. En las clusulas de cierre, se habr con-
templado el perodo de transicin del saliente hacia el nuevo entrante o hacia la propia
organizacin (reabsorcin del servicio). Normalmente este coste de transicin se
imputa al contrato entrante, salvo que la finalizacin sea por causas achacables al sumi-
nistrador saliente, en cuyo caso y en funcin de lo especificado en las clusulas de pena-
lizacin, podr ser imputado a dicha organizacin. La identificacin de personal clave y
una transferencia de conocimientos documentada, planificada y auditada son esenciales.
Gestin de los conflictos contractuales

La gestin de conflictos de carcter contractual tambin se trata en las Normas
ISO/IEC 20000, especificndose en la parte 1 que debe estar procedimentada la
gestin de los desacuerdos contractuales, y en la parte 2 recomendndose que se
incluya el procedimiento en el contrato y que los conflictos se registren, se investi-
guen, se resuelvan y se cierren formalmente.
UNE-ISO/IEC 20000-1
Debe existir un proceso para tratar los desacuerdos contractuales.
UNE-ISO/IEC 20000-2
Tanto el proveedor del servicio como el que no puedan ser resueltos mediante
suministrador deberan funcionar con- el procedimiento ordinario.
forme a un proceso para gestionar los El proceso debera asegurar que los
conflictos, el cual se debera definir o conflictos son registrados, investigados,
referenciar dentro del contrato. que se toman las acciones necesarias
Debera existir un procedimiento o itine- sobre ellos y que se cierran formal-
rario para poder escalar los conflictos mente.
La mejora continua del proceso

Al igual que en el resto de los procesos de gestin de TI en ISO/IEC 20000, la ges-
tin de suministradores debe tener una actividad de autorrevisin del propio pro-
ceso, analizando cmo est funcionando el proceso, si est siendo positivo para la
organizacin, si se cumplen los objetivos definidos, etc. Como resultado, se pro-
duce un programa de mejora del proceso que se debe coordinar con el resto de los
procesos a travs del Plan de mejora unificado de los procesos y de los servicios
(vase el captulo 4); ya que ningn proceso debe cambiarse a s mismo sin estar
en coordinacin con los dems.
Gestin de mltiples suministradores

En ISO/IEC 20000-2 se establecen algunas recomendaciones para el caso de que
se encargue a un suministrador principal la gestin del resto de los suministradores
para la prestacin del servicio.
UNE-ISO/IEC 20000-2
Debera quedar claro si el proveedor del cin del proveedor del servicio si as lo
servicio trata con todos los suministradores requiere.
de forma directa o mediante un suministra-
El proveedor del servicio debera obtener
dor principal que toma la responsabilidad
evidencias de que los suministradores
de los suministradores subcontratados.
principales gestionan formalmente a los
El suministrador principal debera regis- suministradores subcontratados; guin-
trar los nombres, responsabilidades y dose, cuando sea apropiado, por los
relaciones entre todos los suministrado- requisitos incluidos en la Norma ISO/IEC
res subcontratados y ponerla a disposi- 20000-1.
sta es una situacin frecuente en grandes externalizaciones, en las que se quiere

alcanzar una madurez en la gestin del servicio, y que para ello se recurre a una
empresa especializada en la gestin de servicios que se encarga nicamente de los
procesos y herramientas de gestin, mientras que se contrata a otros suministrado-
res la provisin de servicios ms especializada.
Otro caso frecuente es la concentracin de contratos de mantenimiento del hard-
ware a una nica empresa.
Mtricas del proceso

Las mtricas asociadas al proceso miden el cumplimiento de lo contratado por
parte del suministrador, junto con el comportamiento concreto del proceso. Para
que las mtricas asociadas a la prestacin del servicio por parte del suministrador
puedan tener el respaldo contractual, es necesario que se definan las mismas con
carcter previo al establecimiento del contrato, o bien que se establezca su defini-
cin en la etapa de transicin.
Las mtricas dependen del tipo de producto o servicio contratado, ya que no es
lo mismo la compra de equipamiento hardware, que la prestacin continua de un
servicio de telecomunicaciones.
Para el caso de prestacin de servicios de externalizacin, las mtricas seran las mis-
mas que las definidas para cada uno de los procesos. De forma general, las mtricas
aportarn informacin sobre el cumplimiento de lo contratado, en relacin a los
niveles de servicio, los plazos de ejecucin, los volmenes de trabajo, los costes, la
calidad, etc.
Al tratarse tambin de una relacin entre dos organizaciones, tambin se podr
medir el funcionamiento de la relacin entre la organizacin de TI y el suministra-
dor, para determinar si es de fluida, eficiente y satisfactoria. Por otra parte, las
mtricas recogern informacin sobre la satisfaccin de la organizacin de TI con
los servicios del suministrador.
Los indicadores que se enumeran a continuacin son de mbito genrico con inde-
pendencia del servicio contratado.
Valoracin de la calidad global del suministrador y de sus servicios, en base a
encuestas de satisfaccin de las reas internas que reciben los servicios.
La disponibilidad total y de cada uno de los servicios durante el horario
comprometido de los mismos.
Cumplimiento de plazos medios de ejecucin de peticiones de los usuarios.
Cumplimiento de plazos medios de ejecucin de peticiones u rdenes de tra-
bajo de la organizacin de TI al suministrador.
Cumplimiento de plazos y calidad de los proyectos
El grado de cumplimiento de otros aspectos de los acuerdos del nivel de ser-
vicio en cuanto a calidad, horario, tiempos de atencin, etc.
Volumen de actividad realizada en el perodo.
El coste medio por unidad de servicio o por unidad de capacidad.
La calidad de la informacin registrada, evaluada por revisiones o auditoras

internas.
Nmero de escalados horizontales medios por peticin o trabajo, que miden
la eficacia en la actividad diaria.
Nmero de conflictos surgidos.
Etc.
En la figura 7.3.24 se muestra un resumen de los indicadores ms relevantes para

este proceso.
Figura 7.3.24. Ejemplo de mtricas para este proceso

Los roles que participan se estructuran en los roles propios del proceso y los roles
ajenos al proceso (el gestor del nivel de servicio).
En este caso, dada la diferencia tan importante entre las actividades de estrategia de
sourcing, el ciclo de seleccin y contratacin, y el ciclo de gestin de la prestacin,
se suelen establecer roles especficos para cada una de estas etapas del proceso. En
empresas de tamao medio muchos de estos roles se suelen agrupar en una nica
persona.

El responsable de la estrategia de sourcing o responsable de la oficina de sour-
cing (CSO, Chief Sourcing Officer), que define y vela por la implementacin
de la estrategia de sourcing.
En la estrategia de sourcing:
El gestor de contratos. Que se encarga de la gestin formal y contractual
de todos los contratos firmados en curso.
En el ciclo de seleccin y contratacin:

El responsable de compras. Responsable de la ejecucin de la poltica de
seleccin y contratacin de productos y servicios.
El comprador. Lleva a cabo la ejecucin de la seleccin y contratacin de
productos y servicios.
En el ciclo de gestin de la prestacin:

El gestor de las relaciones con el suministrador (gestor del proceso o pro-
cess manager), que es el responsable mximo del proceso y del cumpli-
miento de los objetivos del mismo. Se encarga del funcionamiento del
proceso en detalle, de subsanar las deficiencias, de resolver conflictos, etc.
Los gestores de suministradores, que desempean una funcin operativa
de supervisar da a da la relacin con el suministrador. Lidera las reunio-
nes con el suministrador, supervisa el cumplimiento de los procedimien-
tos y el correcto funcionamiento del da a da.
Los administradores o personal de soporte al proceso, personal que con-
tribuye en organizar la actividad, realizar encuestas de satisfaccin, reali-
zar informes, apoyo a los gestores de cliente, etc.
Los roles ajenos que son relevantes en este proceso son los siguientes.
cumplan los niveles pactados. Aporta los niveles de servicio a mantener en
los contratos.
Las reas de TI proponentes de las compras, que son las que solicitan la rea-
lizacin de las compras.
El responsable de informes, aportando los informes que se deben entregar al
cliente.
Los roles de mayor relevancia que participan en el proceso de gestin de suminis-

tradores se representan en la figura 7.3.25.
Roles del proceso
Estrategia Seleccin y
Prestacin
de sourcing contratacin
Responsable de la
gestin del servicio
Chief Sourcing Responsable Gestor de las
SGSTI Officer de compras relaciones con
el suministrador
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
Gestor de
suministradores
Gestores del reas de TI proponentes
nivel de servicio de las compras
Figura 7.3.25. Roles del proceso de gestin de suministradores
Resumen
La maduracin del sector lleva paulatinamente hacia la concentracin de la fbrica
de los servicios de TI en empresas especializadas que prestan servicios al resto de
organizaciones internas de TI. Lo que permite que las empresas se centren en las
actividades que aporten un valor diferencial a su negocio, recurriendo a la exter-
nalizacin de las funciones no esenciales que el mercado comercializa empaque-
tadas en forma de producto o servicio (ERP, mantenimiento correctivo de soft-
ware, comunicaciones, hosting, monitorizacin, operacin, atencin telefnica al
usuario, etc.).
Como consecuencia, cada vez se externalizan ms actividades de la organizacin de
TI. Por ello, la gestin de los suministradores, casi inexistente hasta, ahora se ha
convertido en un proceso clave para el xito en los servicios de TI.
La gestin de suministradores tambin debe tener en cuenta que detrs de un sumi-
nistrador hay personas, que adems de ser eficientes en el cumplimiento de sus
compromisos, tienen sentimientos, vida personal, familia, frustraciones, etc.
De forma histrica las grandes organizaciones han desarrollado el ciclo de seleccin
y contratacin de suministradores, implementando buenas prcticas y polticas en
la seleccin y en la contratacin. En cambio, el ciclo de gestin de la prestacin del
suministrador es apenas un recin nacido, pero esencial en un escenario con cada
vez ms funciones de TI externalizadas.
Los aspectos ms destacados de este proceso son los siguientes:
El proceso de gestin de suministradores abarca todo tipo de servicios, desde
la compra de productos, pasando por la contratacin de servicios, hasta los
diversos tipos de externalizaciones.
La estrategia de sourcing define las actividades que se realizarn interna-
mente y las que se contratarn a los suministradores. Una vez definida, la
implementacin de esta estrategia pasa por el establecimiento de acuerdos
marcos de tarifas con los suministradores principales, que promocionen ms
agilidad para las contrataciones del da a da y faciliten la tendencia hacia una
consolidacin de suministradores.
El proceso, bajo aproximacin pura ISO/IEC 20000, partira de una estrate-
gia de sourcing ya definida para dividirse en dos grandes ciclos, junto con una
actividad de finalizacin del contrato:
El ciclo de seleccin y contratacin de productos y servicios.
El ciclo de gestin de la prestacin de los suministradores.
Dado su carcter contractual, este proceso requiere mayor formalizacin que

otros, desde la designacin de los representantes hasta un seguimiento por
escrito de la actividad (actas).
El ciclo de seguimiento de la prestacin es bastante nuevo en las reas de TI,

por lo que es una disciplina en pleno desarrollo que ir madurando y espe-
cializndose segn los tipos de servicios que se contraten.
La definicin de los mecanismos de relacin y seguimiento de la prestacin
resulta esencial, comprendiendo comits, dinmica de reuniones, informes
de seguimiento, interlocutores, interconexin de los flujos de trabajo, inter-
faces entre herramientas, etc. Por ello, es necesaria la definicin clara de las
funciones de los roles de interlocucin de las organizaciones participantes.
Las interfaces entre las herramientas de gestin en toda la cadena de sumi-
nistradores son esenciales para la eficacia de los diversos flujos de trabajo:
incidentes, peticiones, rdenes de trabajo, etc.
El proceso recopila todo el conocimiento de la relacin en la base de datos
de suministradores y contratos (SCD).
El ciclo de seguimiento de la prestacin no debe ser tan denso que estran-
gule la fluidez necesaria en la actividad del suministrador.
Estamos asistiendo a la transformacin de la actividad de TI externalizando cada

vez ms funciones, en bsqueda de la eficiencia en costes, la calidad y la agilidad.
En esta evolucin es esencial velar tambin por el cambio cultural de la organiza-
cin. Se debe considerar que con frecuencia, las restricciones propias impuestas por
la organizacin contratante o el incumplimiento por alguno de sus miembros de
sus responsabilidades, puede perjudicar gravemente los resultados de la prestacin
del suministrador. Por ello, este proceso debe mirar tambin hacia el interior de su
organizacin, para limar imposiciones no necesarias, para supervisar el desempeo
de la organizacin retenida y para velar por la adaptacin progresiva de la organi-
zacin a la nueva realidad en TI.
Beneficios
La gestin de suministradores permite garantizar que las necesidades de la organi-
zacin de TI se aprovisionan de forma alineada con la estrategia general, y que los
productos y servicios contratados cumplen con los acuerdos firmados. Entre los
beneficios obtenidos destacan:
Definicin de una estrategia de sourcing, que identifica las actividades crticas
a retener y las funciones que se externalizarn.
Se asegura la ejecucin de la estrategia de sourcing en lo relativo a la contra-
tacin externa.
Da rigor y transparencia a las actividades de contratacin de productos y ser-

vicios.
Obtiene importantes ahorros por una gestin de las compras coordinada y
homogeneizada.
Implementa una sistemtica para que la relacin y gestin de los suministra-
dores se realicen de forma homognea por todas las unidades.
Implementa las mejores prcticas en la gestin de los suministradores.
Alinea las necesidades de la organizacin de TI con los servicios contratados.
Se almacena el conocimiento sobre los suministradores y su desempeo.
Segn su opinin, qu debe contemplar la estrategia de sourcing de TI?
Cmo se realizan la seleccin y contratacin de suministradores en su
organizacin?
Segn su experiencia, qu aspectos destacara en la gestin de los sumi-
nistradores?
8 Procesos de
resolucin
Captulo 8
8.1. Antecedentes
8.2. Gestin del incidente
8.3. Gestin del problema


8. Procesos de resolucin 537
Los procesos de resolucin gestionan el alto volumen de incidentes y peticiones de

usuario que se generan en torno a los servicios de TI. Tambin incluyen las accio-
nes necesarias para ir mejorando los defectos en los sistemas y las infraestructuras
que soportan los servicios.
El proceso de gestin del incidente pretende restaurar los servicios a su funciona-
miento normal de la forma ms rpida posible.
Adems, la gestin del incidente tambin incluye la gestin de la peticin, enten-
dindose como tal las solicitudes de servicio de los usuarios previstas en el catlogo
de servicios.
Los incidentes y las peticiones generan cada uno de ellos un flujo de actividad que
recorre gran parte de los equipos de soporte de TI. Suponen una importante carga
de actividad en TI, por ello, se debe poner nfasis su automatizacin y en optimi-
zar su tratamiento en busca de cuotas altas de eficiencia.
Para mejorar la calidad de los servicios y reducir la frecuencia de aparicin de inci-
dentes, aparece el concepto de problema. En este mbito de TI, el trmino pro-
blema tiene un significado algo diferente al uso cotidiano: es todo defecto subya-
cente en los servicios que genera o puede generar incidentes.
La gestin del problema tiene como objetivo identificar y eliminar los defectos y
fallos en los servicios. Con ello, se consigue reducir en nmero de percances en los
mismos, mejorar la calidad ofrecida al negocio y reducir la actividad de soporte.
En este captulo se presentan las directrices, mejores prcticas y recomendaciones
para la gestin de los incidentes, as como, la mejor forma de abordar la tarea anal-
tica y de investigacin que es la resolucin de los problemas.
8. Procesos de resolucin
8.1. Antecedentes 539
8.1. Antecedentes
Figura 8.1.1. Relaciones entre los procesos de resolucin
La gestin del incidente se centra en restaurar el servicio cuanto antes, sin admitir
dilaciones por investigaciones tcnicas. Su objetivo es que todo servicio cado o
degradado retorne cuanto antes a la normalidad.
Mantener nicamente esta actividad frentica de apaga fuegos no sera produc-
tivo, pues los defectos no reparados produciran ms y ms incidentes. As, de
forma independiente, se debe realizar una labor ms sosegada y concienzuda
de anlisis de los fallos, para buscar soluciones definitivas. Aqu aparece la necesi-
dad de un nuevo proceso como la gestin del problema.
Las Normas ISO/IEC 20000 dedican unos prrafos introductorios a los procesos
de resolucin, estableciendo una relacin permanente entre ambos procesos, defi-
niendo el concepto de prioridad e introduciendo las soluciones provisionales:
UNE-ISO/IEC 20000-1
Antecedentes
La gestin del incidente y la gestin del problema son procesos separados, aunque
ambos estn fuertemente relacionados.
UNE-ISO/IEC 20000-2
La gestin del incidente y del problema mientras la gestin del problema tiene
son procesos distintos, aunque estn como misin la identificacin y la elimi-
estrechamente relacionados. El proceso nacin de las causas de los incidentes.
de gestin del incidente se encarga de la
restauracin del servicio a los usuarios,
La relacin entre ambos procesos es constante, pues la gestin del incidente genera
informacin que posteriormente analizar la gestin del problema en busca de
defectos en los servicios. As, en su actividad diaria de restaurar el servicio, la ges-
tin de incidente se encuentra frecuentemente con defectos en los servicios. Como
su funcin no es dedicarse a erradicarlos, los comunicar a la gestin del problema
para a su anlisis y resolucin. Por otra parte, la gestin del problema vuelca su
conocimiento y las soluciones encontradas en una base de datos, para que la ges-
tin del incidente los pueda aplicar en futuros incidentes similares.
Prioridad de un incidente y de un problema

Puesto que en una organizacin media de TI se gestiona un volumen alto de inci-
dentes, es necesario definir, en la actividad de clasificacin, la prioridad con la que
se debe tratar este incidente. Igualmente ocurre a la hora de asignar un orden de
resolucin a una lista de problemas abiertos. ISO/IEC 20000-2 recomienda calcu-
lar la prioridad como resultado de dos aspectos: la urgencia y el impacto en la orga-
nizacin.
UNE-ISO/IEC 20000-2
Los objetivos para la resolucin debe- La planificacin de la resolucin de inci-

ran estar basados en la prioridad. La dentes o problemas debera tener en
prioridad se debera basar en el cuenta, como mnimo, lo siguiente:
impacto y la urgencia. El impacto se a) la prioridad;
debera basar en el nivel de dao real
b) las habilidades disponibles;
o potencial al negocio del cliente. La
urgencia se debera basar en el tiempo c) los requisitos de competencia para
entre la deteccin del problema o del los recursos;
incidente y el momento en que se pro- d) el esfuerzo/coste necesario para
duce el impacto sobre el negocio del proporcionar el mtodo de reso-
cliente. lucin;
e) el tiempo transcurrido para pro- Nota: La prioridad se utiliza durante toda la ges-
porcionar un mtodo de resolu- tin del servicio pero es fundamental para la ges-
tin del incidente y del problema.
cin.
Estas dos variables independientes condicionan el nivel de prioridad de un inci-

dente y la rapidez con la que se va a tratar de resolverlo:
El impacto: medida del efecto sobre el negocio que actualmente tiene un
incidente o que potencialmente podra tener. Se relaciona con el grado en
que se podra llegar al incumplimiento de los SLA. Se puede valorar en fun-
cin de la criticidad para el negocio del servicio afectado, del nmero de
usuarios perjudicados y de su importancia para la organizacin. El impacto
se suele medir en 3 niveles; alto, medio y bajo.
La urgencia: medida de la criticidad en cuanto al plazo de resolucin de un
incidente en funcin de las fechas lmites para su resolucin. Se asocia con el
tiempo disponible para la resolucin antes de que se llegue al incumpli-
miento de los SLA. La prioridad se puede medir en 3 niveles: alta, media y
baja. Tambin es frecuente asignarla a metales: platino, oro, plata y bronce.
Esta misma clasificacin de impacto y urgencia se utiliza para ordenar por priori-
dad los cambios (vase tambin el apartado 9.2).
En cualquier caso, los criterios para definir el impacto y la urgencia deberan esta-
blecerse en coordinacin con los responsables del negocio y formalizarse en el SLA.
En la figura 8.1.2 se presentan los tipos de prioridad ms habituales y un rango
orientativo del tiempo de atencin asociado.
Tiempo
Prioridad Descripcin
atencin
Se necesita una accin inmediata. Se identifica como

incidente grave.
Inmediata En minutos
Puede ser necesario asignar recursos inmediatamente y
activar el procedimiento de crisis.
Alta Tienen preferencia de atencin. <1 hora
Ser asignada una prioridad media en cuanto a la

Media <2 horas
dedicacin de recursos.
La resolucin del incidente puede esperar.
Baja <6 horas
Sern asignados recursos en cuanto queden libres.
Figura 8.1.2. Ejemplo de tipificacin de prioridades de un incidente

Los incidentes de prioridad inmediata suelen tener la consideracin de incidente

grave y tienen un tratamiento predefinido. Cuando se prev que un incidente grave
no va a poder cumplir el SLA se debe activar el procedimiento de crisis.
La tabla de la figura 8.1.3 permite calcular la prioridad en funcin de estas dos
variables.
Prioridad de un incidente
PRIORIDAD/ IMPACTO
Tiempo de resolucin
Alto Medio Bajo
Alta Inmediata / Alto / Medio /

u Oro en min <1 h <2 h
URGENCIA
Media Alto / Medio / Bajo /

o Plata <1 h <2 h <6 h
Planificar /
Baja Medio / Bajo /
Cuando haya
o Bronce <2 h <6 h
hueco
si > SLA
Incidente grave Crisis
Figura 8.1.3. Ejemplo de clculo de la prioridad de un incidente

en funcin de su impacto y de su urgencia
Solucin provisional (workaround) y error conocido (KE)
UNE-ISO/IEC 20000-2
Siempre que sea necesario, la gestin error deje de existir (por ejemplo, por-
del problema debera desarrollar y que el servicio ya no se utilice).
mantener soluciones provisionales para La gestin del problema debera tener
permitir a la gestin del incidente ayu- acceso a la informacin sobre las reas
dar a los usuarios o al personal a res- de negocio afectadas por los problemas.
taurar el servicio.
Se debera almacenar y mantener en la
Un error conocido slo se debera base de datos de conocimiento, la infor-
cerrar cuando se haya aplicado satis- macin sobre las soluciones provisiona-
factoriamente un cambio correctivo o el les, su aplicabilidad y su efectividad.
Se entiende por solucin provisional (workaround) de un incidente a cualquier solu-

cin utilizada para restablecer el servicio rpidamente y que no haya resuelto la
causa raz del mismo. Esta solucin, al ser provisional, no resuelve el defecto que lo
origin, pero permite que los usuarios continen su trabajo. Las soluciones provi-
sionales utilizadas deben registrarse, identificando el elemento de configuracin
relacionado, pues ocultan defectos subyacentes que volvern a aparecer. En ocasio-
nes tambin se puede encontrar el trmino de solucin rpida (quick fix).
Otro concepto utilizado en los procesos de resolucin es el error conocido (KE,
Known Error). Se entiende como tal cuando la gestin del problema ha identificado
un defecto subyacente y la forma de resolverlo. Un error conocido es un fallo cuya
causa es conocida. Es decir, es la causa raz ya identificada que provoca el incidente.
El error conocido lleva implcito las explicaciones, el conocimiento y las soluciones
para la resolucin de los incidentes provocados por este defecto. Una de las misio-
nes de la gestin del problema es la eliminacin de los errores conocidos.
8.2. Gestin del incidente 545
8.2. Gestin del incidente
Figura 8.2.1. Actividades principales del proceso de gestin del incidente
La permanencia en su puesto del director de sistemas de informacin (CIO, Chief

Information Officer) depende claramente de que su organizacin sepa resolver, tanto
las grandes crisis, como los incidentes y peticiones diarias que llegan a TI. Aunque
este no es el nico factor, s es quizs el primero a considerar, pues de l depende la
confianza del negocio en TI.
Los incidentes son una consecuencia del resto de las actividades de TI. En ellos
influye la calidad del desarrollo, el cumplimiento de las polticas de pruebas, la soli-
dez de la arquitectura, la robustez de las plataformas, la calidad de los tcnicos, la
estabilidad de los productos, el desempeo de todos los otros procesos, etc.
La gestin del incidente se centra en apagar los incendios rpidamente, dejando
de lado la eliminacin de los defectos subyacentes en los servicios, que se debern
corregir en el proceso de la gestin del problema. Mientras que no se erradiquen
todos los defectos, la gestin del incidente seguir resolviendo las incidencias una
tras otra de la forma ms rpida posible, comunicando a la gestin del problema
los defectos que encuentre en su da a da.
As, la gestin del incidente es el proceso que se ocupa del tratamiento de los sucesos
que provocan la degradacin o prdida del funcionamiento normal de un servicio,
con el objetivo fundamental de recuperar el servicio para el negocio lo ms rpida-

mente posible.
En ISO/IEC 20000, al igual que ocurre en ITIL v2, la gestin del incidente tam-
bin incluye el tratamiento de peticiones de servicio o solicitudes de los usuarios
relacionadas con TI. En este caso, el objetivo es atenderlas de forma eficiente y den-
tro de los plazos acordados. Pero por desgracia, este importante proceso prctica-
mente no se desarrolla en ninguno de estos dos marcos de referencia.
Produce cierta confusin que la gestin del incidente se divida a su vez en la propia
gestin del incidente y en la gestin de peticiones. Tambin se debe aclarar que en
este proceso cuando se habla de incidente o de ciclo de vida de incidente, se suele
referir al incidente propiamente dicho y no incluye a las peticiones.
Se ha tenido que esperar a ITIL v3 para que la gestin de las peticiones (request ful-
fillment) haya sido reconocida y tratada como un proceso especfico. La atencin a
las peticiones es una fuerte carga de trabajo en las reas de produccin o explota-
cin de TI, de ah la importancia en desarrollar unos procedimientos y mecanismos
para alcanzar la mxima eficiencia en su resolucin.
En la figura 8.2.2 se presenta un esquema introductorio al proceso de gestin del
incidente.
La misin del proceso de gestin del incidente es restaurar el funcionamiento nor-
mal del servicio para minimizar el impacto negativo sobre el negocio, garanti-
zando de este modo que se mantiene el ms alto nivel de calidad y disponibilidad
del servicio. El funcionamiento normal del servicio se entiende aqu como el
funcionamiento del servicio dentro de lo previsto (segn lo recogido en el acuerdo
de nivel de servicio o SLA), de tal forma que el negocio no vea interferida su acti-
vidad.
En la prestacin de los servicios no se debe aspirar a mediocridades. Se debe buscar
que los servicios no fallen, pues un incidente es una privacin de algn servicio y,
por tanto, siempre va a producir un trastorno en la actividad de la empresa. Por
ello, los plazos de resolucin de los incidentes, en los acuerdos de nivel de servicio
(SLA), han de ser tomados como lmites que no se deben traspasar y nunca como
el desempeo esperado de la funcin de TI.
Los objetivos de la gestin del incidente son los siguientes:
Minimizar el tiempo de resolucin de los incidentes.
Priorizar la atencin de incidentes de acuerdo con los compromisos de servicio.
Reducir el impacto de los incidentes gracias a una resolucin oportuna,
incrementando de este modo la eficiencia del negocio.

del incidente Prioriza la atencin de incidencias
de acuerdo con los compromisos de
servicio.
Definicin:
Reduce el impacto de los incidentes
Proceso que se ocupa del tratamiento poniendo foco en la restauracin
de los sucesos que provocan la cuanto antes del servicio.
degradacin o prdida del
Almacena informacin de los
funcionamiento normal de un servicio,
incidentes producidos.
con el objetivo fundamental de
recuperar el servicio para el cliente Gestiona el conocimiento en relacin a
lo ms rpidamente posible. la resolucin de incidentes.
Adems, gestiona las peticiones de Mejora la eficiencia en el tratamiento
servicio para atenderlas de la forma de los incidentes y peticiones de los
ms eficiente y rpida posible. usuarios.
Colaborar en la identificacin
Objetivo: proactiva de mejoras en los servicios
y en los procedimientos.
Restaurar el servicio acordado con el
negocio tan pronto como sea posible y
responder ecientemente a las
peticiones de servicio.
Figura 8.2.2. Introduccin al proceso de gestin del incidente
Colaborar en la identificacin proactiva de mejoras y modificaciones para los

servicios.
Atender a tiempo las peticiones de servicio de los usuarios.
Optimizar los procedimientos de atencin y resolucin, incrementando de
este modo la eficiencia en el trabajo diario.
Mejorar la satisfaccin de clientes y usuarios.
La gestin del incidente es el proceso que ms volumen de trabajo genera en TI.

Adems involucra a un nmero de actores bastante amplio, desde los teleoperado-
res, pasando por todas las reas tcnicas, hasta llegar a los desarrolladores de las
aplicaciones.
Hay que tener en cuenta que en una organizacin de TI se atienden entre 2 y 3
contactos por mes de cada usuario, relativos a incidentes y peticiones de servicio
(una empresa de 5.000 personas generar unas 15.000 llamadas al mes que TI
deber atender). Adems, hay que considerar que la tendencia es a que este volu-
men de contactos se vaya incrementando, debido al aumento de la diversidad de
dispositivos mviles y a la progresiva penetracin de las TI en la actividad de la
empresa. Por ello, es importante disponer de una organizacin perfectamente pre-
parada y entrenada para su atencin y resolucin.
Una buena gestin de los incidentes y las peticiones en la organizacin, reducir
enormemente las tensiones internas y permitir a la organizacin salir de la crisis
continua como nico medio de gestin y de trabajo. Adems, liberar a la direc-
cin de TI de llamadas y quejas inoportunas de los otros directores, permitiendo
que en la organizacin de TI cada uno realice su propio trabajo.
Por tanto, es un proceso que tiene dos flujos de trabajo (workflow) diferenciados y
amplios, que se deben afinar y optimizar. El primero de ellos es el ciclo de vida del
incidente y el otro el ciclo de vida de la peticin de servicio. Ambos comienzan en
el mismo punto, el centro de servicio al usuario (SD, Service Desk) que atiende los
contactos del usuario, bien sea a travs de llamadas telefnicas o, ms reciente-
mente, a travs de una aplicacin web. A partir de este momento, el flujo de ambos
procesos se separan para recorrer diversas partes de la organizacin de TI: el inci-
dente se trata por los niveles tcnicos especializados y las peticiones por la adminis-
tracin de los servicios.
Ya que estos dos flujos recorren gran parte de la organizacin, hay que transmitir a
todos los implicados los objetivos que se deben cumplir, para que TI acte como
un autntico equipo sincronizado. Los tres pilares en los que se sustenta este pro-
ceso se resumen en la figura 8.2.3.
Figura 8.2.3. Bases de la gestin del incidente

Vocacin de servicio. La vocacin de servicio al usuario es el eje central de la organi-

zacin de TI y uno de los aspectos que se deben cuidar y desarrollar en este proceso.
La amabilidad, la capacidad de explicacin y la comunicacin son facetas importantes
que deben desarrollar las personas que estn en contacto con los usuarios.
Tiempo de resolucin. Este proceso es una fbrica masiva de resolucin, tanto
de los incidentes como de las peticiones. El concepto de pertenencia a la cadena de
resolucin debe estar mentalmente asumido por todos los participantes. Los invo-
lucrados en la cadena deben ser conscientes de la importancia del cumplimiento de
los plazos. Las herramientas de gestin de incidentes y peticiones deben facilitar el
control de los tiempos de resolucin. Adems, debern activar las alarmas y priori-
zar los incidentes o peticiones (tickets) cuando el plazo de resolucin est prximo
a su expiracin.
Conocimiento tcnico. No hay que olvidarse de la importancia fundamental del
conocimiento tcnico del personal. Los proyectos de implantacin de procesos en
las organizaciones de TI hacen que la direccin se centre en las formas de trabajar y
pudiera ocurrir que se dejara en un segundo plano el conocimiento tcnico. Esto
no es lo que debera suceder, ya que un buen conocimiento tcnico permitir resol-
ver un incidente en minutos, mientras que un tcnico iletrado generar percances
en la ms mnima actuacin y desbaratar cualquier planificacin o compromiso
adquirido.
A la hora de estructurar los equipos de personas, el proceso de gestin del incidente
se articula normalmente en torno a tres lneas o niveles de atencin y soporte tc-
nico: la primera lnea o centro de servicio al usuario (service desk), la segunda lnea
o soporte tcnico especializado, y la tercera lnea o soporte tcnico de fabricantes o
suministradores. En la figura 8.2.4 se presentan los componentes ms destacados
de este proceso.
Los componentes que intervienen en el proceso de gestin del incidente son:
Incidente (o incidencia). Cualquier suceso que no forme parte del funciona-
miento estndar de un servicio y que motive, o pueda motivar, una interrupcin o
reduccin de la calidad del servicio y de la productividad del usuario.
Peticin (o solicitud) del usuario. Contacto del usuario para requerir a TI la pro-
visin de una funcionalidad individual ya prevista en el catlogo de servicios, por
ejemplo, un nuevo ordenador personal, alta como usuario en una aplicacin, una
consulta sobre el uso de un servicio, etc.
La diferenciacin entre usuario y cliente en este proceso se aprecia en todo su deta-
lle, pues, conviene no confundir las peticiones de los usuarios, que siempre son de
carcter individual, con las demandas de carcter colectivo de los clientes (o reas
cliente) para requerir un nuevo servicio o la evolucin de uno existente.

Eventos de
monitorizacin
Ticket Escalado
Incidentes
Personal
tcnico
Incidentes
Primera lnea Segunda lnea Tercera lnea

Peticiones de soporte, de soporte de soporte
service desk o centro (reas tcnicas (fabricantes y
de servicio al usuario internas) suministradores)
Usuarios
Problemas
identificados Conocimiento
tcnico
Peticiones de
Incidentes cambio (RFC) Errores
conocidos CMDB
Base de datos Solucin temporal Base de datos Base de datos

de incidentes (work-around) de problemas de configuracin
Figura 8.2.4. Las lneas de atencin y soporte son el eje de

la gestin del incidente
Problema. La causa raz desconocida de uno o ms incidentes existentes o poten-

ciales. Los problemas pueden ser identificados a travs de varios incidentes que
muestren sntomas comunes. Tambin pueden identificarse a partir de un incidente
de relevancia, indicativo de un error con causa desconocida. La gestin del inci-
dente o el service desk comunican a la gestin del problema los problemas que iden-
tifiquen como consecuencia de estar continuamente reparando incidencias.
Error conocido (KE, Known Error). Es un defecto del que se ha identificado la
causa raz que lo origin (se tenga o no una solucin, sea temporal o permanente).
Los errores conocidos son una pieza clave en la gestin del conocimiento para la
resolucin de incidentes.
Los problemas y errores son tratados exclusivamente por el proceso de gestin del
problema.
Solucin provisional (workaround). Es una solucin temporal a un incidente con

el fin de restaurar rpidamente un servicio. Las soluciones temporales no eliminan
o resuelven la causa raz que caus el incidente, pero permiten restaurar el servicio
(vase el apartado 8.1).
Ticket. Se suele denominar ticket a la ficha de registro de un incidente, bien sea un
incidente como tal o una peticin del usuario. A cada incidente se le asigna un
nmero. En la literatura de origen anglosajn, al flujo que conduce a un incidente
desde su registro inicial, como ticket en una herramienta, hasta su cierre se le deno-
mina trouble ticketing (gestin de tickets de dificultades), en realidad este trmino
representa al propio ciclo de vida de un incidente.
Primera lnea de atencin o centro de servicio al usuario (SD, Service Desk).
Equipo de personas que recibe los contactos de los usuarios (llamadas, mensajes,
tickets, etc.), los registra y clasifica, e intenta resolverlos o remitirlos a los grupos de
soporte adecuados. Es importante destacar que el service desk es el nico punto
de contacto del usuario con la organizacin de TI (SPOC, Single Point of Contact).
Todo incidente o peticin se comunica va service desk. Es tambin el punto de
comunicacin de vuelta desde TI hacia el usuario para informarle del avance de sus
peticiones o del cierre de los incidentes. El SD tambin recibe incidentes generados
por los sistemas de monitorizacin. El centro de servicio al usuario es conocido
como nivel 1 de atencin o primera lnea de soporte.
Segunda y tercera lneas de soporte. Realizan las funciones tcnicas de soporte
especializado. Se encargan de resolver los incidentes que provienen del service desk.
Reciben el ticket del incidente, investigan y resuelven el incidente y, una vez
resuelto, lo comunicarn al SD. En las lneas segunda y tercera participan gran
parte de la organizacin de TI, pues los especialistas suelen estar agrupados en gru-
pos tecnolgicos.
Evento de monitorizacin. Es una notificacin de un posible incidente generada
automticamente por las herramientas de monitorizacin. Este evento llega al
service desk para su evaluacin.
Call center, centro de contactos o centro de llamadas. En las grandes organiza-
ciones es frecuente encontrar el centro de servicio al usuario dividido entre dos
equipos de personas diferentes: el de recepcin exclusiva de llamadas y el de resolu-
cin de primera lnea. El call center o centro de contactos se encarga nicamente de
registrar las llamadas y abrir una ficha del contacto con el usuario. La llamada y la
ficha pasan al soporte tcnico de la primera lnea para su resolucin.
Escalado. Es la actividad de remitir un incidente a otro grupo de TI para que con-
tine su resolucin. Por tanto, el escalado es el mecanismo que permite el traspaso
de informacin y requerimientos de actuacin sobre un incidente a las lneas o
niveles predefinidos y especializados de resolucin, contribuyendo a que los inci-

dentes se resuelvan a tiempo.
Hay dos tipos de escalado, escalado funcional (o enviar a otra lnea de soporte) y
escalado jerrquico (comunicar situacin).
Base de datos de incidentes. Repositorio que contiene la informacin de los inci-
dentes ocurridos. Adems suele incluir tambin las peticiones y consultas. Contiene
los registros o fichas de los incidentes registrados, junto a la informacin sobre su
resolucin. Esta base de datos va ligada a la herramienta de gestin del incidente o
de atencin al usuario. Registra la actividad de resolucin de los incidentes y suele
contener una breve explicacin de la resolucin, por lo que contribuye al conoci-
miento de la organizacin en relacin a estos temas. Es una de las piezas que utiliza
el service desk para la conocer cmo se ha resuelto de incidentes similares. La ges-
tin del problema busca en ella para identificar defectos latentes que se deban resol-
ver. Contiene informacin detallada de los incidentes y su resolucin con la
siguiente informacin:
Incidentes resueltos y cerrados con las soluciones temporales.
Toda la informacin relevante asociada con el incidente
Informacin relativa a la comunicacin con el usuario.
Explicacin de la resolucin con la fecha y hora.
Informacin de todos los grupos intervinientes detallando sus tiempos con-
sumidos.
Etc.
Peticin de cambio (RFC, Request For Change). Medio para proponer un cam-
bio en cualquier componente de la infraestructura de TI o en cualquier aspecto de
un servicio de TI. La gestin del incidente genera las peticiones de cambio que
necesite para la resolucin rpida de los incidentes abiertos.

Como se ha comentado anteriormente, la gestin del incidente tiene dos grandes
flujos de actividad: el ciclo de vida del incidente y el ciclo de vida de la peticin de
servicio. Estos dos flujos tienen un inicio comn en la primera lnea de soporte que
realiza el service desk. A partir de aqu, y tras su clasificacin, se separan en dos.
Otras actividades de la gestin del incidente, son la generacin de las peticiones
de cambio (RFC) que se necesiten para resolver los incidentes, la identificacin de
posibles causas recurrentes de incidentes (generando tickets de problemas) y la

supervisin de la evolucin de los incidentes y la mejora del proceso.
La figura 8.2.5 muestra las entradas, actividades y salidas del proceso.
Desencadenantes 3 Ciclo de vida del incidente: Salidas principales:

del proceso: Autorregistro y Comunicacin al usuario
Contactos de los autorresolucin por parte con incidente resuelto.
usuarios. del usuario. Base datos incidentes.
Eventos de Deteccin y registro del
monitorizacin. incidente. Salidas secundarias:
Clasificacin y soporte inicial. Peticin de cambios
Entradas de soporte: (RFC).
Asignacin y escalado.
CMDB. Informacin de gestin.
Investigacin y diagnstico.
BD de incidentes. Informacin de la
Reparacin y recuperacin.
BD de problemas existencia de un
(errores conocidos). Cierre del incidente. problema.
SLA. 3 Generar peticiones de cambio Encuestas de
Catlogo de servicios. para resolucin de incidentes. satisfaccin de los
3 Comunicar problemas detectados. usuarios.
3 Gestin de incidentes graves.
3 Ciclo de vida la peticin usuario.
3 Supervisin y mejora del
proceso.
Las principales entradas a este proceso son:

Contactos de los usuarios. Para comunicar incidentes, consultas, solicitudes,
reclamaciones o reaperturas de los incidentes, etc., relacionados con los sistemas de
informacin.
Eventos de monitorizacin. Se reciben los eventos o alertas desde las herramien-
tas de monitorizacin, que pueden estar relacionados con:
Hardware: servidores, discos, routers, impresoras, etc.
Comunicaciones y telefona.
Software: aplicaciones, otros sistemas, utilidades, etc.
CMDB. Base de datos de gestin de la configuracin, utilizada frecuentemente

para conocer que elementos de configuracin pueden estar afectados por un inci-
dente, los servicios afectados y sus relaciones. Tambin se utiliza para conocer el
catlogo de servicios, los SLA, autorizaciones de usuarios, documentacin, ubica-
cin, etc.
BD de incidentes. La base de datos de incidentes donde se registran y controlan
las fases por las que pasan los incidentes. Proporciona informacin para controlar
que no se abra ms de un incidente por la misma causa y para identificar incidentes
anteriores y sus soluciones.
BD de problemas. La base de datos de problemas se utiliza para identificar si el
incidente en curso est provocado por un error conocido, y por tanto, saber la
forma de solucionarlo.
SLA. Los acuerdos de nivel de servicio facilitan la informacin necesaria para prio-
rizar el incidente y para conocer el plazo pactado para su resolucin.
Las actividades del proceso se dividen entre las relativas a los incidentes, las de
tratamiento de las peticiones y las de mejora. Ms adelante se describen con
detalle.
Las principales salidas de este proceso son:
Comunicacin al usuario. Informacin de salida hacia el usuario para man-
tenerle informado sobre el estado del incidente o bien al final para confirmar
su resolucin.
Base datos de incidentes. Se obtiene como salida una base de datos con los
incidentes registrados y el tratamiento realizado.
Peticiones de cambio (RFC). Se remiten las peticiones de cambio, cuando
se requieran, para solventar los incidentes.
Informacin de gestin. Se genera la informacin relevante para la gestin
y mejora del proceso (indicadores de gestin y mtricas).
Informacin de la existencia de un problema. Se remite a gestin del pro-
blema la informacin relativa a posibles problemas encontrados en el trans-
curso de la actividad de gestin del incidente.
Encuesta de satisfaccin del usuario. Realizada en el cierre de cada inci-
dente.
Ciclo de vida del incidente

Observando los volmenes de actividad en TI, se aprecia que la gestin de los
incidentes, de las peticiones de usuario y de los cambios, son los tres grandes
ciclos de frentica actividad que giran y giran continuamente en una organi-
zacin.
En la figura 8.2.6 se muestra el ciclo de vida de un incidente, en su transcurrir por
las lneas de soporte 1, 2 y 3. Tambin se muestra su paralelismo con el ciclo de
vida de una peticin de servicio.
Fuente: Libros ITIL Soporte de Servicio y Operacin del Servicio publicados por OGC.
Figura 8.2.6. Ciclo de vida del incidente
En ISO/IEC 20000-1 estn condensados los requisitos para la gestin del inci-
dente. En ella se especifica lo siguiente:
UNE-ISO/IEC 20000-1
Se deben registrar todos los incidentes.

Se deben adoptar procedimientos para gestionar el impacto de los incidentes.
Los procedimientos deben definir el registro, la priorizacin, el impacto en el nego-
cio, la clasificacin, la actualizacin, el escalado, la resolucin y el cierre formal de
todos los incidentes.
ISO/IEC 20000-2 indica lo siguiente:
UNE-ISO/IEC 20000-2
El proceso de gestin del incidente e) la verificacin y el cierre de los

debera incluir lo siguiente: incidentes;
a) la recepcin, el registro, la asig- f) el contacto de primera lnea con
nacin de prioridad y la clasifica- los clientes;
cin de las llamadas; g) el escalado.
b) la resolucin de primera lnea o la
Todos los incidentes se deberan regis-
derivacin;
trar de modo que la informacin rele-
c) la consideracin de cuestiones de vante se pueda recuperar y analizar.
seguridad;
d) el seguimiento y la gestin del
ciclo de vida de los incidentes;
Deteccin y registro del incidente

La primera actividad en el ciclo de vida del incidente es la deteccin. Idealmente, el
incidente debera ser detectado por las herramientas de monitorizacin. Pero, con
demasiada frecuencia, es el propio usuario el que lo detecta y lo sufre, y quin
informa al service desk, bien mediante una llamada de telfono o bien mediante su
registro en una aplicacin web (autorregistro).
Una vez detectado debe ser registrado en la herramienta de gestin de incidentes. Es
posible registrar directamente como incidente un evento o alarma captada por alguna
herramienta de monitorizacin. La dificultad estriba en la forma de tratar las alarmas
para discriminar entre las informativas, preventivas, crticas o fatales. La monitoriza-
cin deber permitir detectar un incidente antes de que sus efectos afecten al servicio.
El objetivo es evitar la degradacin del servicio y anticiparse a su cada.
Las tareas que habitualmente se realizan en la deteccin y registro son las siguientes:
Comprobar que la comunicacin del usuario o el ticket abierto automtica-
mente por la monitorizacin corresponde de verdad a un incidente.
Registrar los datos preliminares en la ficha o pantalla de registro de incidentes
(bien por el teleoperador del service desk o directamente por el usuario va web).
Si se trata de un incidente, verificar que no se ha registrado previamente, en
cuyo caso se asocia con el incidente existente. Si no existe, se graba como
incidente nuevo.
Si se trata de una peticin o solicitud de servicio o similar, se graba el regis-
tro con los datos requeridos para tramitarla.
En la figura 8.2.7 se muestra un ejemplo de la estructura de la ficha de un inci-

dente, que se ir cumplimentando segn progrese en su ciclo de vida.
Ficha de un incidente
3 Datos de identificacin del usuario que abre

la incidencia: nombre, telfono, etc.
3 Fecha de apertura del incidente.
3 Datos descriptivos del incidente:
Efecto percibido por el usuario
(tipificacin de entrada).
Servicio o aplicacin. Grupo.
Prioridad.
Detalles.
Causa del incidente.
Efecto real.
Objeto fallo.
3 Datos descriptivos de la resolucin:
Fecha de resolucin.
Causa final del incidente.
Solucin aplicada.
Descripcin de la resolucin.
3 Datos descriptivos del cierre.
Fuente: Libros ITIL Soporte de Servicio y Operacin del Servicio publicados por OGC, y Telefnica.
Figura 8.2.7. Ficha o ticket tipo de un incidente

Autorresolucin por el usuario

Esta funcionalidad ofrece la posibilidad al usuario de poder intentar resolver su
incidente o peticin. Si lo consigue, no es necesario proceder al registro de una
ficha del incidente.
La aplicacin de autorresolucin suele ser distinta a la del autorregistro. Combina
una base de conocimientos de problemas genricos relativos al ordenador personal
(conocimientos que se pueden comprar en el mercado como producto), con el
conocimiento de la propia empresa sobre la configuracin del PC o de los servi-
cios. Adems, la autorresolucin puede llamar a aplicaciones o rutinas propias de la
organizacin para ejecutar acciones sencillas asociadas a la resolucin de un inci-
dente o a la provisin automtica (por ejemplo, el borrado de la contrasea de
usuario en una aplicacin).
En la autorresolucin es importante facilitar al usuario la bsqueda en la base de
datos del conocimiento, que permita identificar fcilmente la solucin a su inci-
dente.
Autorregistro y clasificacin por el usuario

Resulta tremendamente til implantar un formulario web que permita a los usua-
rios el registro de los incidentes y las peticiones. As, se alivia al centro de atencin
de llamadas de la labor de registrarlos, con lo que se reduce drsticamente el
nmero de teleoperadores. Tambin, se reducen los tiempos de espera al telfono
de los usuarios para ser atendidos. Los registros dados de alta por los usuarios,
deben ser tratados inmediatamente por la primera lnea de soporte, para poder
establecer contacto con el usuario si lo necesitasen. Una vez que el usuario se iden-
tifica, los datos de su puesto de trabajo se deben cargar en la aplicacin de forma
automtica, para evitar que introduzca una y otra vez la misma informacin.
En el autorregistro es muy importante disponer de una herramienta de ayuda a la
clasificacin por el usuario del tipo de incidente o de peticin, para poder automa-
tizar mejor la primera atencin del ticket creado.
Asociado al autorregistro, conviene poner tambin foco en la resolucin inmedia-
tamente posterior al registro del ticket, as se puede localizar al usuario en su puesto
de trabajo y se evitan importantes prdidas de tiempo en sucesivos intentos de esta-
blecer contacto.
La autorresolucin y el autorregistro son esenciales para reducir la carga de
actuaciones triviales de los grupos de soporte y proporcionan satisfaccin al usua-
rio al permitirle resolver por s mismo necesidades de una forma ms gil. Una
buena combinacin de ambas puede reducir en un 30% el nmero de contactos

con el service desk.
Clasificacin y soporte inicial

Est formada por dos actividades: clasificar el incidente y proporcionar una solu-
cin al incidente.
Clasificacin. Establece la categora del incidente y su prioridad. La clasificacin
resultar fundamental para la comparacin automtica del incidente frente a las
bases de datos de problemas y errores conocidos.
La categora de un incidente tiene como objeto identificar su origen, sus sntomas
y la causa (si es detectada); lo que permitir localizar ms fcilmente una solucin
existente (error conocido) y su asignacin a los grupos de soporte adecuados. En la
figura 8.2.8 se muestra un posible sistema de categoras.
Clasificacin de un incidente
Categora Subcategora
Hardware Instalacin/Configuracin.
Rotura.
Factor humano.
Funcionalidad.
Software Inconsistencia/Corrupcin.
Rendimiento/Bloqueos.
Factor humano.
Causa ajena a TI Servicios internos.
Defecto de fabricacin hardware.
Bug software.
Red WAN.
Desconocido
Figura 8.2.8. Ejemplo de categoras de un incidente

En ITIL siempre que es necesario clasificar incidentes, peticiones o cambios se uti-

liza el mismo esquema, se les asigna un orden de importancia, denominada priori-
dad y que se asigna en funcin del impacto y de la urgencia (esta actividad se ha
descrito en el apartado 8.1 siguiendo la estructura de las Normas ISO/IEC 20000).
As, la prioridad se establece en funcin del:
Impacto en el negocio. Es la medida de la severidad para el negocio de un
incidente. A menudo se identifica con el grado en que el incidente lleva al
incumplimiento de los niveles de servicio acordados. Tambin el impacto
est relacionado con el nmero de usuarios o sistemas afectados. Los crite-
rios para definir el impacto deben estar definidos en los SLA.
Urgencia. Se refiere a la rapidez requerida para resolver un incidente de un
determinado impacto. Generalmente viene determinada por el tiempo dis-
ponible para la resolucin del incidente sin afectar al servicio.
Normalmente se har una distincin entre la clasificacin realizada inicialmente

en el registro del incidente por el service desk, sobre la base de los sntomas, y la
clasificacin final, sobre la base de conocer ya la causa real. El incidente podr
reclasificarse a lo largo de su ciclo de vida.
En el momento del cierre es necesario revisar la clasificacin ya que esta informa-
cin es clave para:
Asociar el incidente con el elemento de configuracin (CI, Configuration
Item) afectado, utilizando para ello la CMDB.
Facilitar la identificacin de los incidentes.
Disponer de estadsticas fiables.
Soporte inicial. Una vez clasificado el incidente, se trata de resolverlo siguiendo

los siguientes pasos en secuencia:
Comparacin del incidente con los incidentes registrados en la base de datos
de incidentes, para ver si existen otros incidentes relacionados con este y, ade-
ms, tienen una solucin identificada. Si se encuentra un caso de estos se
salta a la actividad de reparacin y recuperacin para aplicar la solucin.
Comparacin con los errores conocidos (KE, Known Error) y comprobar
si existe una solucin que sirva para resolver el incidente. Si se encuentra, se
pasa a la actividad de reparacin y recuperacin del incidente.
Utilizacin del conocimiento propio para encontrar una solucin al inci-
dente.
En este paso, si se identifican incidentes repetitivos o taras en los componentes del

servicio, se generar un registro de problema. De la misma forma, se notificara si
no se hubiera podido diagnosticar un incidente.
El soporte inicial finaliza, se haya resuelto o no el incidente, ya sea por falta de
conocimientos, medios o por expiracin del plazo de tiempo determinado para su
resolucin en esta lnea. Si se ha resuelto el incidente se pasa a la fase de reparacin
y recuperacin.
Asignacin y escalado
Cuando la primera lnea no puede resolver el incidente, de forma inmediata lo
asigna al grupo tcnico que corresponda en la segunda lnea de soporte (escalado
horizontal). Si adems, el incidente cumple unos requisitos definidos, se informa
inmediatamente a los responsables superiores (escalado vertical).
El escalado tiene el objetivo de resolver el incidente lo antes posible, para no
incumplir los niveles de servicio acordados. Es una actividad que puede ser itera-
tiva y que puede pasar por diferentes grupos de soporte e incluso a suministradores
hasta que se restaure el servicio.
Hay dos tipos de escalado:
Escalado funcional (que equivale a enviar a otra lnea de soporte). Es la
remisin de un incidente a otro grupo de soporte tcnico o funcional para
que se contine trabajando en l cuando es necesario aumentar la especiali-
zacin necesaria. Tambin se le conoce como escalado horizontal. Se realiza
generalmente desde los grupos de soporte de la primera lnea a la segunda, o
de la segunda a la tercera. Es importante una buena tipificacin del incidente
para conseguir que ste llegue al grupo de soporte adecuado. Los motivos
para promover un escalado pueden ser:
El grupo que investiga la resolucin del incidente no cuenta con los
conocimientos o experiencia requeridos para resolver el incidente. En
este caso, la peticin partir probablemente del equipo encargado de la
resolucin.
El tiempo disponible para la resolucin del incidente pone en riesgo el
cumplimiento de los niveles de servicio acordados (SLA). En este caso,
el escalado puede ser tambin jerrquico.
Escalado jerrquico (que equivale a comunicar situacin). Es la notifica-

cin o informacin sobre un incidente hacia instancias superiores de mayor
jerarqua en la organizacin, normalmente con fines de informar o para soli-

citar una toma de decisin. Los motivos para un escalado jerrquico son:
Comunicacin. El tiempo disponible para la resolucin del incidente pone
en riesgo el cumplimiento de los niveles de servicio acordados (SLA). El
incidente es grave o de alto impacto y las instancias superiores deben estar
informadas. Es necesario informar al cliente de que no pueden cumplirse
los niveles de servicio acordados.
Decisin. Los recursos necesarios son importantes y la direccin y el clien-
tes tienen que estar informados. Es necesario tomar decisiones respecto a
la ampliacin o aplicacin de recursos.
La herramienta de gestin del incidente proporciona los medios para la asigna-

cin del incidente entre los diversos grupos tcnicos de soporte (trouble ticke-
ting). El service desk debe supervisar todo el proceso y controlar mediante alarmas
internas los incidentes que se han quedado atascados en un grupo o que no se
resuelven.
UNE-ISO/IEC 20000-2
Siempre que sea posible, se debera cliente. Cuando la causa del problema
proporcionar al cliente los medios nece- siga sin determinarse pero se haya esta-
sarios para continuar con sus activida- blecido una solucin provisional, se
des empresariales, aunque sea con un deberan registrar los detalles para utili-
servicio degradado (por ejemplo inhabi- zarlos durante la diagnosis continua del
litando una funcin defectuosa). El problema y cuando se produzcan inci-
motivo es minimizar la repercusin dentes similares.
sobre las actividades empresariales del
El service desk debe identificar la necesidad de proporcionar al cliente los medios

alternativos para paliar la ausencia del servicio de TI. Esta situacin debe estar deta-
llada en el SLA y previstos los medios paliativos, si se puede.
En el momento en que se implemente una solucin provisional para la resolucin
del incidente (conocida como workaround), se debe registrar. En la herramienta de
gestin del incidente se identifica que el incidente se ha resuelto con una solucin
provisional. La herramienta de gestin del problema mantendr un registro con
todas las soluciones provisionales que haya activas.
Investigacin y diagnstico del incidente

El rea de soporte tcnico que recibe el ticket con el incidente asignado, realiza la
investigacin de los sntomas y un diagnostico del incidente, antes de proceder a su
resolucin. Aunque el diagnstico y la resolucin estn separados como actividades
independientes, en la mayora de los casos se realiza en un nico paso.
El equipo encargado de la resolucin del incidente deber investigar utilizando
todos los medios, conocimientos y experiencia para resolver el incidente dentro de
los lmites de tiempo acordados en los procedimientos de escalado.
En esta actividad se realiza la:
Evaluacin de los detalles del incidente.
Recopilacin y anlisis de toda la informacin relacionada.
Ampliacin de la informacin en el registro del incidente con los detalles
resultantes de la investigacin.
Si el equipo encargado de la resolucin no es capaz de resolver el incidente en

plazo, se produce una nueva asignacin y escalado. Esta accin podr iterarse hasta
que se resuelva el incidente.
Existe el riesgo de que el personal de soporte se dilate en el anlisis y no sea capaz
de controlar el plazo lmite de ejecucin que se tiene en el SLA, para realizar su
escalado funcional o jerrquico.
Reparacin y recuperacin del servicio

Una vez diagnosticada la causa del incidente y encontrada una solucin, definitiva
o temporal, se procede a la reparacin del fallo. Esta actividad contempla, tres eta-
pas distintas: la reparacin del fallo en el elemento de configuracin, la recupera-
cin del elemento de configuracin y la restauracin del servicio (momento en que
se reanudan las operaciones normales del negocio).
En la reparacin, puede ser necesario contar con la autorizacin de la gestin del
cambio para aplicar la solucin. Segn sea la urgencia, se realizar una peticin de
cambio normal o se actuar por el procedimiento de emergencia, generndose
en cualquier caso la correspondiente solicitud de cambio (RFC). La reparacin del
fallo no implica necesariamente que el servicio haya vuelto a la normalidad, pues
igual hay que esperar a que se pueda reiniciar el sistema para que el servicio vuelva
a la normalidad. Una vez se ha recuperado el servicio, se informa o se pasa el ticket
al service desk.
Desgraciadamente, en la vida diaria las situaciones no son tan sencillas. Por ejemplo,
un fallo puede hacer que se haya corrompido una base de datos o que unos procesos
batch se hayan quedado a mitad y haya que reanudarlos y terminarlos, posiblemente
borrando datos incompletos y repitindolos desde el principio. Tambin puede suce-
der que sea necesario recurrir a las copias de seguridad y avisar a clientes de que se han
perdido las ltimas altas o facturas.
Estas situaciones complican a veces extraordinariamente la solucin de un incidente
y generan discusiones sobre si los SLA se estn cumpliendo o no. Por ejemplo, el
servicio se puede recuperar, pero reparar una base de datos corrupta puede llevar
das o semanas Se puede decir que el servicio se ha recuperado hasta que la base
de datos est limpia? Si ha fallado una cadena batch (programada en JCL), se puede
corregir y liberar una nueva versin, pero termina el incidente con esto, o no ter-
mina hasta que el trabajo se ha lanzado otra vez y ha finalizado correctamente? El
servicio no se puede restablecer al cien por cien hasta que el trabajo batch haya fina-
lizado, pero es posible que no se pueda lanzar hasta la noche siguiente, aunque el
error en la programacin en el JCL se haya corregido en minutos.
El equipo que solucion el incidente, deber actualizar el registro del incidente
cumplimentando los detalles propios de la resolucin e informacin complementa-
ria, como por ejemplo:
La fecha y hora de la resolucin del incidente.
El equipo que proporcion la solucin.
El detalle de la solucin.
El detalle de los procedimientos y elementos utilizados en la resolucin.
Los incidentes relacionados, si los hubiese.
Cierre del incidente

El service desk recibe de vuelta el ticket del incidente ya resuelto, apareciendo en la
lista de tareas pendientes de tratar. Se pasa a obtener la conformidad del usuario
antes de proceder al cierre. La conformidad del usuario normalmente se realiza de
forma automatizada por la herramienta de gestin, que enva un correo infor-
mando de la restauracin del servicio. A partir de aqu hay dos prcticas habituales:
Una es pedir al usuario que de expresamente su conformidad respondiendo al
correo o entrando en la herramienta de gestin. Si el usuario no responde en
dos das se cierra de forma automatizada (no contando este plazo en el SLA).
Otra prctica es cerrar por defecto todos los incidentes e informar al usuario
que puede reabrirlo si no est conforme con el cierre.
En los casos graves es recomendable obtener la conformidad del usuario directa-

mente a travs los tcnicos que estn resolviendo el incidente y estn ya en contacto
con l, o bien, o mediante una llamada telefnica del service desk.
UNE-ISO/IEC 20000-2
Un incidente slo debera cerrarse defi- confirmar que el incidente se ha resuelto

nitivamente cuando el usuario que haya y el servicio ha sido restaurado.
notificado dicho incidente haya podido
En el momento de la comunicacin del cierre, se suele adjuntar un enlace a una

pgina web en la que se le realiza una breve encuesta sobre la atencin recibida.
Responder a la encuesta suele ser opcional para los usuarios. De esta forma se
obtiene informacin inmediata sobre la satisfaccin del usuario.
Ahora bien, una vez que se decide realizar las encuestas a los usuarios, se deben
analizar y gestionar, tanto los resultados, como los comentarios recibidos y las que-
jas. Por desgracia, es comn utilizarlas nicamente para obtener una mtrica men-
sual o anual de satisfaccin del usuario. Es el service desk el encargado de analizar
estas encuestas de forma regular (diaria o semanalmente) y de tomar las medidas
inmediatas adecuadas o realizar las propuestas de mejora que se incorporarn al
plan de mejora general del servicio. Las encuestas con valoracin muy negativa,
deberan implicar el contacto con el usuario para conocer detalles de su punto de
vista sobre servicio recibido y, por otra parte, restaurar la confianza del usuario en
el servicio.
La responsabilidad del cierre del incidente recae en el service desk, de forma manual
o automatizada.
En el cierre de incidentes importantes, se deber verificar que el registro del inci-
dente contiene toda la informacin necesaria y anexada la documentacin apro-
piada. En el resto de incidentes, la comprobacin puede ser hecha por una valida-
cin informtica de los campos en el momento del cierre o por auditoras
peridicas de la base de datos de incidentes.
Reabrir el incidente
En caso de disconformidad del usuario con la resolucin del incidente no se podr
cerrar el incidente y volver a la actividad de asignacin, registrando en la informa-
cin del incidente que se ha reabierto.
En el caso habitual del cierre por defecto del incidente es muy importante tener
posibilidad de su reapertura para disponer de informacin estadstica sobre la cali-
dad en la resolucin. Se debe evitar la prctica de generar un nuevo ticket de inci-
dente, en lugar de reabrir el anterior.
En la reapertura, se registra en la base de datos de incidentes la causa de la reaper-
tura y la no conformidad del usuario.
Estados de un incidente
El estado de un incidente es un indicador del progreso realizado en su resolucin.
Marca las diversas etapas por las que puede pasar el ticket de un incidente hasta su
resolucin. El estado permite conocer al instante en que fase del flujo de resolucin
se encuentra. Adems, al marcar la evolucin en etapas, posibilita extraer ciertas
mtricas con el fin de evaluar el desempeo del proceso. En la figura 8.2.9 se mues-
tra un ejemplo de los posibles estados de un incidente.
Estados de un incidente (ejemplo)
Notificado.
Detectado.
Diagnosticado.
Reparado el fallo.
Recuperado el CI.
Restaurado servicio.
Cerrado.
Fuente: Libro ITIL Soporte de Servicio publicado por OGC y Telefnica.
Figura 8.2.9. Estados tpicos de un incidente
A continuacin se describen cada uno de los distintos estados asociados a un incidente:

Notificado. Es el estado inicial y se produce en el momento en que el usua-
rio informa al service desk de la prdida o perturbacin del servicio. Tambin
es posible registrar un incidente de forma automtica a partir de los eventos

lanzados por los sistemas de monitorizacin de las infraestructuras y de los
servicios.
Detectado. Indica que el incidente ha sido registrado y clasificado en la
herramienta de gestin del incidente.
Diagnosticado. Se conoce la causa del incidente y se ha encontrado una
solucin (normalmente temporal) al incidente. Permite obtener informacin
estadstica sobre el tiempo que se tarda en diagnosticar y encontrar una solu-
cin al incidente.
Reparado el fallo. Se logra este estado tras haber solucionado o reparado el
fallo del elemento de configuracin (por ejemplo, en una infeccin de virus
se ha reparado el servidor infectado inicialmente).
Recuperado el CI (Configuration Item o elemento de configuracin).
Se pasa a este estado cuando se logra la recuperacin del componente
(por ejemplo, en el caso anterior, se ha recuperado uno de los PC conta-
minados).
Restaurado el servicio. Este estado se logra cuando se reanudan las opera-
ciones normales del negocio (por ejemplo, se han recuperado todos los pues-
tos infectados y el servicio del puesto funciona con normalidad).
Cerrado. El usuario ha confirmado que el fallo se ha solucionado y se ha res-
tablecido el funcionamiento de las operaciones normales de negocio.
Un cierto detalle en los estados del incidente permite identificar en que etapas hay
que actuar para mejorar el proceso.
Modelos o patrones de incidentes y de peticiones

ITIL v3 introduce el concepto de modelos del incidente y de modelos de la peti-
cin. Muchos incidentes no son nuevos, sino repeticiones o similares a otros ante-
riores, por ello, puede ser interesante definir modelos o patrones de actuacin ante
un tipo de incidente determinado. De la misma forma, las peticiones son clara-
mente repetitivas, por lo que tener tipificada su resolucin aporta gran eficiencia al
proceso.
El modelo contiene una forma predefinida de los diversos pasos o tareas a realizar
para su resolucin. La herramienta de soporte puede contener almacenada la
secuencia de intervencin para estos incidentes tipificados.
Centro de servicio al usuario (SD, Service Desk)

El service desk es el nico punto de entrada de incidentes. Es por tanto el nico
punto de contacto con los usuarios, para recepcin de incidentes y todo tipo de
peticiones y solicitudes de servicio. Tambin recibe incidentes generados por los
sistemas de monitorizacin. Frecuentemente es conocido como primer nivel de
atencin o primera lnea de soporte.
El primer concepto a mantener en la implantacin de este proceso es que el service desk
es el nico punto de entrada para todos los contactos de los usuarios con TI. Todo
incidente y cualquier comunicacin con el usuario deben pasar por el service desk.
UNE-ISO/IEC 20000-2
Nota 1: El proceso de gestin del incidente puede afecten, o que pudieran potencial-
ser proporcionado por un servicio de mente, afectar al servicio;
atencin al cliente, que acte como punto
b) un proceso centrado en la restaura-
de contacto diario con los usuarios.
cin del servicio a los clientes y no en
Nota 2: La gestin de incidentes debera ser: la determinacin de la causa de los
incidentes.
a) un proceso tanto proactivo como reac-
tivo, que responda a los incidentes que
El service desk es el propietario de las incidencias y, por tanto, es el responsable de su

seguimiento hasta su cierre. Debe de estar alerta ante cualquier desviacin o posi-
ble incumplimiento de los SLA en cuanto a los plazos para su resolucin.
Se encarga fundamentalmente de realizar las siguientes acciones.
Deteccin y registro del incidente.
Clasificacin del incidente y soporte inicial.
Resolucin del incidente en la primera lnea de soporte, si se puede.
Asignacin y escalado funcional del incidente, si no se puede resolver en la
primera lnea.
A partir de este punto, las lneas segunda y tercera de soporte trabajan con
el incidente hasta resolverlo. Mientras dura esta etapa de trabajo interno, el
service desk y una aplicacin web deben mantener informado al usuario, espe-
cialmente en incidentes importantes.
Cuando es necesario, realiza el escalado jerrquico del incidente, haciendo de
intermediario en la comunicacin con la direccin. Con frecuencia, muchos
de los escalados jerrquicos se realizan de forma automatizada por la herra-

mienta de gestin del incidente, cuando se cumplen las condiciones fijadas.
Cierre del incidente. Comprobacin con el usuario de que el incidente est
correctamente resuelto. Realiza las encuestas de satisfaccin del usuario.
Como propietario de los incidentes debe realizar un seguimiento de los inci-
dentes y las peticiones abiertos, con independencia del nivel en el que se
encuentren y con el fin de revisar si progresan adecuadamente para tomar las
medidas necesarias en caso contrario.
Si un incidente no progresa, se deber actuar poniendo en marcha las accio-
nes de escalado previstas.
Seguimiento de los incidentes y peticiones abiertos, con independencia del
nivel en el que se encuentren. Controlar los incidentes que pasan por varios
grupos de resolucin, coordinando los escalados horizontales a travs de estos
grupos, con el fin de resolver los conflictos de competencias entre los distin-
tos grupos. Este control tambin servir para detectar mejoras en la relacin
existente entre la tipificacin de los incidentes y los grupos de resolucin.
Hacer un seguimiento especial de los incidentes de prioridad alta.
Mantener informados a los usuarios afectados sobre el progreso de resolu-
cin del incidente.
Gestin de las peticiones de los usuarios.
Reabrir el incidente, si lo reclama el usuario.
La funcin del service desk dentro del proceso de gestin del incidente, lleva a cabo
una labor importantsima. Aparte de centralizar todas las gestiones de seguimiento
del ciclo de vida del incidente, gestiona todas las comunicaciones de TI con el usua-
rio, en ambos sentidos, tanto para atender las llamadas como para emitir comuni-
cados o contactar con el usuario.
Lo recomendable es apoyarse en la herramienta de gestin del incidente para la
comunicacin, que posibilita el acceso de los usuarios para consultar el estado de
sus incidentes y peticiones. Otro medio muy habitual es el correo electrnico y oca-
sionalmente debera ser el telfono.
UNE-ISO/IEC 20000-1
Se debe mantener informado al cliente del progreso del incidente sobre el que haya
informado o de su solicitud de servicio, y se le debe alertar por adelantado sobre si sus
niveles de servicio no se pueden satisfacer, acordando con l las acciones a tomar.
UNE-ISO/IEC 20000-2
Se puede informar sobre incidentes ticamente mediante un software de

mediante llamadas telefnicas, buzn supervisin automtica.
de voz, visitas, cartas, faxes o mensa-
jes de correo electrnico, o bien pue- El progreso (o su ausencia) de la resolu-
den ser registrados los avisos directa- cin del incidente se debera comunicar
mente por los clientes que tengan a las partes real o potencialmente afec-
acceso al sistema de registro de inci- tadas. Todas las acciones se deberan
dentes, o se pueden registrar autom- registrar en el registro del incidente.
Se debe poner foco en que el service desk, como primera lnea de soporte, resuelva
el mayor nmero de incidentes y peticiones posibles; de esta forma, se reducir
la carga de trabajo de todo el resto de la organizacin de TI. Para ello, es necesa-
rio contar con perfiles ms cualificados que los tradicionales teleoperadores y
poner nfasis en una buena documentacin que contenga los procedimientos de
resolucin.
Dado el alto volumen de incidentes que se gestionan, es recomendable disponer
de una herramienta que, mediante reglas, realice el escalado funcional o jerrquico de
los incidentes de forma automtica y enve notificaciones a los gestores del proceso,
que les permitan reaccionar antes de rebasar los plazos del nivel de servicio pactado.
Esto libera a los supervisores del service desk de la ardua tarea de descubrir, en las
colas de trabajo, qu incidentes estn a punto de superar su SLA. El tiempo de
resolucin y las mtricas clave del proceso se mejoran sustancialmente en cuanto
se implanta esta automatizacin.
Los resultados de las encuestas de satisfaccin tambin mejoran cuando, mediante
otra automatizacin, se informa a cada usuario del estado de su incidente y de sus
ajustes, ofreciendo transparencia en la gestin.
Se recomienda que el service desk realice tambin el tratamiento de las quejas o recla-
maciones de los usuarios, como instrumento esencial para la mejora del servicio y
la atencin prestada. La recepcin de quejas aporta informacin importante de
mejora y sirve para restaurar la confianza del usuario en el servicio. Las quejas de los
usuarios se deben registrar y valorar. Tambin debe asegurarse de que se tomen
las acciones correctoras adecuadas. Toda queja debe tener una gestin asociada:
registro, seguimiento, informe al usuario y cierre.
En las Normas ISO/IEC 20000 en el nico lugar en el que explcitamente se tra-
tan las reclamaciones y quejas es en el proceso de gestin de las relaciones con el
negocio (vase el captulo 7). En ese proceso no se hace distincin explcita entre
reclamaciones de cliente o reclamaciones de usuario, por lo que podra entenderse

que slo trata las de clientes. Pero la ausencia de referencias a la gestin de recla-
maciones de usuarios de forma explcita en algn otro lugar de la norma, lleva
a asumir que las relaciones con el negocio las trata todas, aunque sigue siendo el
service desk el nico contacto para su registro.
El xito del uso del service desk est siendo tal, que en muchas empresas empieza a
atender tambin otras peticiones de servicio externas a TI, relacionadas con los ser-
vicios generales de la empresa (facilities), como por ejemplo, reservas de sala, peti-
cin de material de oficina, etc. En este caso se amplia el concepto de punto nico
de contacto para todo tipo de servicios (y no slo para TI), pero es importante que
el service desk tenga siempre presente su misin prioritaria de resolucin de inciden-
cias sobre otras peticiones que no suponen una prdida de servicio.
Soporte de incidentes en segunda y tercera lnea

Soporte de incidentes en la segunda lnea (o soporte especializado interno) y en la
tercera lnea (o soporte especializado del fabricante o suministrador) se encargan
de resolver los incidentes que el service desk no puede solucionar. Reciben la infor-
macin del incidente, lo investigan y resuelven, y se encargan de comunicrselo de
vuelta al service desk. Realizan el escalado funcional del incidente y solicitan el esca-
lado jerrquico al service desk, en caso de necesidad.
Las acciones principales de este subproceso son las siguientes:
Investigacin y diagnstico del incidente.
Asignacin de un incidente a otras lneas de resolucin (escalado), que se
realiza en funcin de:
Los conocimientos requeridos para resolver el incidente
El tiempo disponible para la resolucin del incidente en funcin de los
acuerdos de nivel de servicio (SLA).
Reparacin del incidente y recuperacin del servicio.
En el soporte de segunda lnea intervienen todo un elenco de grupos especialistas

(servidores, almacenamiento, comunicaciones, sistema operativo, productos mid-
dleware, productos frontend, aplicaciones, etc.) que comparten su actividad entre la
resolucin de los incidentes y la gestin tcnica de su mbito. El soporte de
segunda lnea debe ser capaz de resolver por s mismo la mayora de los asuntos
tcnicos, en el caso de que no pueda, lo escala a la tercera lnea.
El soporte de tercera lnea se sustenta en una serie de contratos de soporte (deno-

minados underpinning contracts o UC) que cubren la reparacin de los defectos o
atencin muy especializada. Estos contratos se deben suscribir con los fabricantes
(normalmente son contratos de mantenimiento y soporte del hardware y de los
productos software), con las empresas que realizan el desarrollo de aplicaciones
(para el mantenimiento correctivo) y con los suministradores de servicios (de tele-
comunicaciones, de operacin, etc.). En estos contratos se debe velar porque los
niveles de servicio pactados sean iguales o ms exigentes que los acuerdos de nivel
de servicio (SLA) firmados con los clientes (vase el apartado 7.2).
Generar la peticin de cambio (RFC)

La gestin del incidente es una de las fuentes generadoras de peticiones de cam-
bio (RFC). Con frecuencia la resolucin de un incidente requiere la realizacin de
una actuacin o de un cambio en algn componente. En este caso, deber generar
una peticin de cambio (normal o de emergencia), siguiendo los procedimientos
dictados por el proceso de gestin del cambio.
Despus de tramitar la solicitud de cambio, se har un seguimiento del mismo para
su rpida ejecucin. Una vez realizada la implementacin, se debe revisar el cambio
realizado con el fin de verificar que se han obtenido los resultados esperados. Esta
revisin, conocida como evaluacin postimplementacin (PIR), la realiza la ges-
tin del gestin del cambio y comunica los resultados a la gestin del incidente.
Comunicar los problemas y mejoras detectados

La gestin del incidente, que trata todos los das con los incidentes y peticiones, es
la mejor fuente de informacin para detectar los defectos permanentes en los com-
ponentes de los servicios. Subsanar estos defectos disminuir el volumen de inciden-
tes y, con ello, la presin sobre TI. Los defectos encontrados en los servicios se debe-
rn comunicar a la gestin del problema siguiendo los procedimientos definidos.
Como tambin trata las peticiones de los usuarios, podr identificar los aspectos de
mejora, tanto en los temas funcionales de los servicios para la reduccin del
nmero de consultas, como para proponer soluciones de automatizacin en la pro-
visin de servicios.
Las mejoras identificadas en los servicios se comunican a la gestin de nivel de
servicio para que las incorpore en el programa de mejora del servicio (SIP). Por
otra parte, las mejoras identificadas en los procesos sern remitidas al propietario
del mismo y las de los grupos de soporte a sus responsables jerrquicos.
Acceso al conocimiento tcnico

A menudo, la primera reaccin ante un nuevo incidente no es la de consultar cmo
se resolvi un incidente similar. Lo habitual es centrarse inmediatamente en los sn-
tomas y precipitadamente emitir un diagnostico, que inexorablemente marcar el
rumbo de la resolucin, hasta que alguien se d cuenta de que el diagnstico inicial
era errneo.
Por otra parte, tampoco es fcil encontrar la informacin de soporte relevante entre
todos los comentarios que se insertan en los registros durante el ciclo de vida de un
incidente. Por ello, las Normas ISO/IEC 20000 ponen nfasis en el acceso al cono-
cimiento generado.
UNE-ISO/IEC 20000-1
Todo el personal implicado en la gestin del incidente debe tener acceso a informa-
cin relevante como, por ejemplo errores conocidos, resoluciones de problemas y la
base de datos de gestin de la configuracin.
UNE-ISO/IEC 20000-2
El personal de gestin del incidente nados y errores conocidos, soluciones

debera tener acceso a una base de provisionales y listas de comprobacin
conocimientos actualizada que contenga que ayuden a restaurar el servicio para la
informacin sobre tcnicos especialistas, empresa.
incidentes anteriores, problemas relacio-
Es importante poner foco en el registro y la difusin del conocimiento tcnico

sobre los servicios y sus componentes. Pero esta meta no es fcil en un proceso que
gestiona multitud de incidentes y peticiones diarias, en el que se estn exigiendo
unos ratios de resolucin muy altos. En esta frentica actividad diaria, es difcil
inculcar a los tcnicos la disciplina de documentar el conocimiento sobre los casos
que les son asignados, no obstante es esencial realizarlo para reutilizar experiencias
y ser ms eficientes cada vez. Lo ms sensato es que los detalles de la resolucin de
incidentes se comenten brevemente en la ficha del incidente y slo haga un informe
para incidentes de especial relevancia o cuyos condicionantes polticos lo exijan.
En ITIL v3 se define un proceso dedicado exclusivamente a la gestin del conoci-
miento en TI, debido a que el conocimiento sobre los servicios lo genera toda la
organizacin: problemas con la base de datos de errores conocidos, incidentes con
las explicaciones en el ticket del incidente de las resoluciones realizadas, desarrollo

de aplicaciones con los manuales de arquitectura, operacin y para el service desk,
las reas tcnicas con la documentacin generada en el diseo de las infraestructu-
ras y las plataformas, etc.
Es importante la eleccin de la herramienta que soporta el conocimiento, pues
pocas herramientas permiten registrar adecuadamente la informacin (incluyendo
anexos), ni tampoco consultarla fcilmente. Normalmente, se utiliza la propia
herramienta de gestin del incidente y del problema para almacenar el conoci-
miento, pero tambin existen algunos productos independientes que realizan esta
funcin. Se requieren funcionalidades de clasificacin y bsqueda tpicas de gesto-
res documentales, que permitan diversas vistas del mismo conocimiento (segn
perfiles), funcionalidades de bsqueda avanzadas y la gestin del conocimiento
obsoleto o no visitado, integracin con otras herramientas, etc.
El conocimiento tcnico registrado permite a la organizacin retener informacin
esencial sobre su instalacin e independizarse algo de las personas que la soportan.
Teniendo en cuenta todos estos antecedentes, se recomienda tener presenta las
siguientes consideraciones:
Facilitar al personal tcnico el acceso a las bases de datos de errores conoci-
dos, CMDB, resolucin de problemas, etc. como describe la norma, y evi-
dencie la disponibilidad gil de esos recursos, mediante enlaces directos en la
interfaz de operacin o en las herramientas de gestin.
Los errores conocidos o incidentes, deberan comprender tambin los que
hayan sido detectados durante las pruebas en los entornos de desarrollo o
preproduccin y que no hayan sido subsanados. Las buenas prcticas esta-
blecen que slo cuando los defectos han sido subsanados por completo se
puede proceder a su puesta en produccin, pero en numerosos casos, por
condicionantes de negocio, se autoriza su puesta en produccin pese a la
existencia de defectos conocidos.
Facilitar al personal tcnico la consulta, mediante motores de bsqueda gi-
les, de los comentarios de los incidentes y mediante navegacin por mens
en cascada clasificados por rea tcnica.
Clasificar y permitir tambin bsquedas de los registros de incidentes por
tipologas o sntomas, por tecnologas, o por elementos de configuracin
(CI), por servicios, grupos, tcnicos, etc.
Actualizar en el cierre la clasificacin del incidente, pues seguramente haya
variado sobre la realizada inicialmente. Esto permite acceder sin errores en el
caso de incidentes similares.
Foco tambin en la autorresolucin. Crear conocimiento destinado a los

usuarios finales, para que puedan resolver por s mismos algunos incidentes
o peticiones (por ejemplo, configuracin del acceso remoto).
Mantener una nica base de conocimiento centralizada, clasificando los con-
tenidos por tipos de perfiles a los que van dedicados: personal tcnico de la
lnea 2, personal del service desk o primera lnea y para usuarios.
Comunicar al personal tcnico las actualizaciones de la base de conocimien-
tos. Supervisar y verificar que todo el personal la conoce, sabe cmo acceder
y la utiliza.
Importar y comprar el conocimiento. Los fabricantes disponen de bases de
conocimiento accesibles va web, adems, hay soluciones con informacin
de resolucin tcnica ya precargada, sobre todo en lo relativo al puesto de
trabajo.
Procedimentar la forma en que el personal tcnico documenta los incidentes
asignados, no permitiendo incluir comentarios accidentales asociados al ciclo
de vida (por ejemplo, no se localiza al usuario, escalado a supervisor,
incidencia cerrada OK, que no aportan nada a la base de conocimiento) y
garantizando la inclusin de comentarios esenciales de conocimiento sobre
el diagnostico o resolucin (como: el error muestra un mensaje con el
cdigo VM2005, se aplica el parche RF12345 y funciona, etc.).
El conocimiento debe estar salvaguardado con criterios de alta disponibili-
dad y continuidad ante desastres, ya que cuando es imprescindible su utiliza-
cin es en casos de graves dificultades.
Relacionar los procesos de gestin del incidente, del problema, el soporte
tcnico y el desarrollo, para que el conocimiento creado en el da a da se
mantenga completamente actualizado y vivo entre todos. Una base de cono-
cimiento poco veraz, no confiable, poco gil u obsoleta, dejar de ofrecer
confianza y caer en el olvido.
Incidentes graves
Hay organizaciones de TI que se gestionan en base a crisis, que acaban marcando
el ritmo de trabajo del da a da. No hay nada peor que una crisis para desbaratar la
productividad. Pero las crisis se producirn, por lo que se debe predefinir el com-
portamiento de la organizacin ante estos incidentes graves. Estas normas tratan el
tema de forma expresa.
UNE-ISO/IEC 20000-1
Los incidentes graves se deben clasificar y gestionar de acuerdo con un proceso.
UNE-ISO/IEC 20000-2
Se debera definir claramente qu cons- Esto debera incluir una responsabilidad

tituye un incidente grave y quin est del escalado y una comunicacin efica-
capacitado para llevar a cabo cambios ces entre todas las reas implicadas en
en el funcionamiento habitual del pro- la resolucin y hacia los clientes que se
ceso de incidentes/problemas. vean afectados por dicho incidente
grave.
Todos los incidentes graves deberan
tener en todo momento un gestor res- Nota: Este nivel de autoridad puede ser temporal
ponsable claramente definido. y aplicarse slo mientras dure el incidente
grave.
La designacin como responsable de un
incidente grave debera proporcionar los El proceso para un incidente grave
niveles de autoridad individual adecua- debera incluir una revisin que propor-
dos para la funcin de coordinar y con- cionar informacin al plan de mejora
trolar todos los aspectos de la resolucin. del servicio.
En la clasificacin de incidentes descrita, se establece como prioridad inmediata

los incidentes de impacto alto y de urgencia alta. Esta misma clasificacin se debe
utilizar para definir qu es un incidente grave, que normalmente ser el de priori-
dad inmediata.
En el caso de incidentes graves, al igual que en los cambios urgentes, se dispone de
un tratamiento especial: notificaciones a mandos, informacin a todo el equipo,
asociacin de incidentes relacionados, con la misma causa comn, etc.
Cuando un incidente grave excede o se dictamina que va a exceder el SLA, se debe
activar la situacin de crisis, en la que deben estar procedimentadas las acciones que
se realizarn, quin deber participar y la creacin del comit de crisis. Es habitual
disponer tambin de una sala de crisis, adyacente a la sala de control, con todos los
medios necesarios para que el equipo predesignado para estas emergencias pueda
desempear su labor.
Entre los incidentes graves tambin se incluyen los desastres. Puede ocurrir que
un incidente grave, en un momento de su trayectoria, requiera la activacin de
este plan cediendo el control al proceso de gestin de la continuidad (vase el
apartado 6.3).
Los incidentes graves, as como, todos los incidentes con un impacto alto, se deben
notificar en tabln de anuncios web de TI, y adems, en la pantalla principal de la
herramienta de incidentes.
El objetivo que se pretende conseguir ante un incidente grave es su resolucin en
un tiempo rcord, minimizando el alto impacto que ocasiona. Tambin es necesa-
rio mantener un flujo de comunicacin constante entre las reas tcnicas resoluto-
rias y el comit de crisis, sin descuidar mantener puntualmente informadas a las
reas cliente afectadas.
Normalmente, este tipo de incidentes son de obligada y cuidada documentacin,
de la forma ms extensa y eficaz posible. Requieren un informe especial, aparte del
seguimiento extraordinario y especfico por parte de los gestores de nivel de servi-
cio, y de los gestores de los procesos implicados.
Ciclo de vida de la peticin de servicio (request fulfillment)

Se entiende por peticin de servicio a toda solicitud que realiza el usuario al rea de
TI, contemplada en el catlogo de servicios, para requerir un servicio, realizar una
consulta o cualquier otro tipo de contacto (a excepcin de los provenientes de fallos
o incidentes). Hay organizaciones que no hacen distincin del tipo de peticin y
desarrollan un tratamiento comn para todas ellas, as se considera tambin servicio
a la atencin de consultas y de otros tipos de contactos de los usuarios. Otras orga-
nizaciones definen flujos distintos diferenciando las peticiones de servicio de las con-
sultas. Muchas peticiones de servicio suponen pequeos cambios, pero de muy bajo
riesgo y con un impacto muy bajo, por ello, se podrn tratar bajo el tipo de cambio
preautorizado (vase el proceso de gestin del cambio en el apartado 9.2).
La gestin de las peticiones de servicio es de gran importancia para el rea de TI,
pues genera un gran volumen de actividad (posiblemente el 15% de toda la activi-
dad de TI) y presenta una casustica muy diversa. En ITIL v2 y tambin en
ISO/IEC 20000, se ha tratado como un subproceso dentro de la gestin del inci-
dente, aportando escasas buenas prcticas al mercado. En ITIL v3 ha subido de
categora, ascendiendo al rango de proceso (proceso de gestin de peticiones en el
libro Operacin del Servicio), lo que emplaza al sector a poner foco en la mejora de
la eficiencia y calidad en este rea de actividad, hasta ahora ninguneada por los
estndares.
No se debe confundir el tratamiento de peticiones con la gestin de nuevos servi-
cios o nuevas necesidades del negocio. Las peticiones las solicita el usuario y estn
tipificadas en el catlogo, mientras que las segundas slo las demanda el represen-
tante de las reas cliente. De aqu, la importancia en distinguir entre el rol del
usuario, como utilizador de los servicios, y el rol del cliente o rea cliente, como
representante del negocio ante TI.
Como es lgico, los servicios que se pueden solicitar deben estar identificados el
catlogo de servicios de TI. Algunos ejemplos de peticiones de servicio son las
siguientes:
Solicitud de alta en un servicio del tipo aplicacin o solicitud de acceso a un
servicio existente.
Peticin de equipamiento. Solicitud de nuevos componentes (hardware o
software) relacionados con el puesto de trabajo.
Peticin de actuaciones en el puesto de trabajo. Configuracin del acceso
remoto UMTS, instalacin de actualizaciones de los controladores de dispo-
sitivo, etc.
Peticin de ejecucin de servicios planificados, como por ejemplo, la ejecu-
cin de cadenas batch.
Consultas funcionales o tcnicas, preguntas o dudas del usuario sobre un
tema del mbito de servicios de TI. Las preguntas pueden ser de ndole tc-
nico o funcional. Para la resolucin de consultas funcionales suele haber un
equipo funcional especfico, bien vinculado al rea de desarrollo, al rea de
relaciones con las unidades de negocio o bien al rea de negocio (en este caso
fuera de TI). En todos los casos, TI debe registrar y tramitar este tipo de
consultas.
Reclamaciones o quejas. El usuario manifiesta su disconformidad con un
servicio prestado.
Las entradas de las peticiones, al igual que los incidentes, se realizan a travs del
service desk, punto nico de contacto para el usuario.
Establecido que TI slo aceptar del usuario peticiones de servicio ya predefinidas
en el catlogo, la primera accin que se realizar es comprobar si la peticin est
entre los servicios que ofrece TI y que el usuario tiene permiso para realizarla.
Como ya hemos comentado, las soluciones de autorregistro y autorresolucin por
parte del usuario son esenciales para reducir la carga del soporte en TI. Automati-
zar al mximo la provisin, junto a una gestin eficiente y previsora de la capaci-
dad (nmero de licencias) y del stock (componentes) son elementos claves para
reducir los tiempos de entrega y aliviar la carga de trabajo rutinaria en TI. Permitir
al usuario conocer va web la evolucin de su peticin, facilita la comunicacin y
mejora la imagen de TI.
Las peticiones de servicio que llegan al service desk recorren el mismo camino que
los incidentes en las dos primeras etapas (las actividades de deteccin y registro y
clasificacin y soporte inicial), pasando despus a un itinerario propio. Destacar
que algunas peticiones requerirn un itinerario de aprobacin jerrquica y del con-
trol presupuestario. En la figura 8.2.10 se muestra el ciclo de vida de una peticin
de servicio, segn la estructura propuesta en ITIL v3.
Figura 8.2.10. Ciclo de vida de la peticin de servicio
Tambin es necesaria la implantacin de procedimientos livianos y giles relativos a

las aprobaciones internas de las peticiones, especialmente de las que tienen impacto
en los presupuestos de los departamentos.
En el cierre de peticiones, reaperturas y reclamaciones se deben seguir las mismas
polticas definidas para el incidente.

El xito de la gestin del incidente se demuestra a travs de:
La reduccin de los tiempos necesarios para la resolucin de los incidentes.
La disminucin de los costes asociados a la resolucin.
Todo proceso tiene una actividad (o subproceso) dedicada a la supervisin de las

actividades que se realizan, para asegurarse que se cumple lo planificado y que se
identifican las mejoras necesarias.
En el proceso de gestin del incidente es bsico realizar un seguimiento continuo
de los incidentes y peticiones, para identificar deficiencias en los procedimientos o
en las formas de actuar de los diversos grupos de soporte. La vigilancia permanente
de este gran engranaje resolutor resulta esencial para mejorar la productividad de la
organizacin de TI.
La actividad de supervisin y mejora enva las propuestas de mejora, para su trata-
miento y aprobacin, al plan unificado de mejora de la gestin del servicio (vase
el captulo 4) y debern coordinarse con el rea financiera de TI.
Mtricas del proceso

Las mtricas del proceso se suelen dividir en tres mbitos:
Mtricas relativas al service desk y la actividad de atencin de llamadas o con-
tactos.
Mtricas relativas a al ciclo de vida del incidente.
Mtricas relativas a al ciclo de vida de la peticin.
Al ser la gestin del incidente un proceso de gran volumen de actividad, toman

especial relevancia las mtricas volumtricas y las de eficiencia en el desempeo.
Las mtricas relativas a la funcin del service desk suelen contener informacin como
el nmero de llamadas atendidas, el nmero de contactos atendidos, el ratio de lla-
madas perdidas, el porcentaje de incidentes bien clasificados, los ratios de actividad
por persona, el porcentaje de contactos que son peticiones de servicio, los ratios de
autorregistro, el ratio de incidentes resueltos en la primera llamada, los incidentes
resueltos en la primera lnea, etc.
En relacin a la medicin del ciclo de vida del incidente, los ms representativos
son los siguientes:
Tiempo medio de reparacin o MTTR (Mean Time To Repair), es el tiempo

medio transcurrido desde que ocurre un incidente hasta que se restaura el ser-
vicio. Representa el tiempo que el servicio est cado (downtime). Esta mtrica
suele estar asociada a otras mtricas de disponibilidad como, por ejemplo, el
tiempo medio entre fallos o MTBF (Mean Time Between Failures), que es
el tiempo medio que tarda en fallar un servicio (uptime) y el tiempo medio entre
incidentes en servicios MTBSI (Mean Time Between System Interruptions), que
es el tiempo medio transcurrido entre dos fallos consecutivos en un servicio.
En la figura 8.2.11 se aprecia la diferencia entre ellas.
Porcentaje de incidentes resueltos en plazo.
Calidad en la asignacin de los incidentes.
Calidad de la documentacin.
Figura 8.2.11. Mtricas de resolucin de incidentes junto a las de disponibilidad
Adems, es habitual medir los ratios de incidentes autorresueltos por el usuario, el

porcentaje de incidentes reclamados, el coste medio de resolucin de un incidente,
el porcentaje de incidentes resueltos, etc.
En la figura 8.2.12 se muestra el resumen de los indicadores ms relevantes para
este proceso seleccionados por un grupo de trabajo de itSMF Espaa.
Mtricas principales del proceso (incidente)
de itSMF Espaa
La medicin del ciclo de vida de una peticin se centra en ratios de agilidad, de efi-
ciencia y de satisfaccin del usuario. Los ms comunes son el volumen de peticiones
gestionadas, el volumen de peticiones segn su estado, desglose de las peticiones por
tipo (de servicio, consulta, etc.), el tamao de lista de peticiones de servicio pendien-
tes, el plazo medio de provisin por tipo de peticin, las peticiones de servicio ter-
minadas en plazo, el nmero de quejas y reclamaciones, el coste medio de provisin,
la satisfaccin del usuario con la gestin de peticiones de servicio, etc.
En la figura 8.2.13 se muestra el resumen de los indicadores ms relevantes para
este proceso seleccionados en ITIL v3 (en el libro Operacin del Servicio).

Como en el resto de los procesos, los roles intervinientes en este proceso se estruc-
turan en los roles propios del proceso y los roles ajenos al proceso (el gestor del
nivel de servicio).
Los roles propios del proceso (del ciclo de vida del incidente) son los siguientes:
Gestor de incidentes. Es el responsable de que los incidentes y peticiones de
los usuarios se resuelvan con la mxima eficiencia y se cumplan los acuerdos
Mtricas principales del proceso (peticin)
Fuente: Libro ITIL Operacin del Servicio publicado por OGC y e.p.
Figura 8.2.13. Mtricas relevantes de la gestin de la peticin en ITIL v3
de nivel de servicio. Est involucrado en el da a da del funcionamiento del

proceso y de los diversos grupos de soporte. Sus principales responsabilida-
des son las siguientes:
Todas las actividades del proceso y asegurarse de que se realicen de forma
eficiente.
Realizar el seguimiento de las mtricas del proceso. Es el responsable ltimo
de implantacin del proceso y su configuracin en las herramientas de soporte.
Asegurarse de que todos los implicados estn suficientemente involucra-
dos en el proceso.
Coordinar el trabajo del personal de soporte de incidentes. Recibe el esca-
lado jerrquico de los incidentes.
Autorizar el escalado jerrquico a la direccin, previa consulta al responsa-
ble de la gestin del servicio. O bien, define las reglas para la configura-
cin de los parmetros del escalado.
Asegurarse de que se establecen unas buenas relaciones de trabajo con
todas las organizaciones implicadas, tanto internas como externas.
Monitorizar la eficacia y eficiencia del proceso y hacer recomendaciones
sobre posibles mejoras.
Analizar, proponer y verificar la revisin de la metodologa de trabajo en

la resolucin de incidentes y peticiones para su mejora.
Elaborar la informacin de gestin del proceso.
Velar por la calidad del soporte y la satisfaccin del cliente/usuario.
Gestor del service desk. Es el responsable del funcionamiento del personal que
forma el centro de servicio al usuario, incluidas las herramientas. Es otro de
los roles importantes del proceso. Sus principales responsabilidades son las
siguientes:
Supervisar la operativa diaria del service desk.
Vigilar el estado de los tickets o contactos abiertos.
Preparar los planes de formacin para el personal asignado.
Analizar la carga de trabajo de su personal, su nivel de conocimientos y
los costes laborales asociados.
Avisar y realizar el seguimiento de la prdida y degradacin de servicios.
Supervisar el progreso de los contactos, y en su caso tomar decisiones ante
dificultades en su resolucin.
Informar de las desviaciones e incumplimiento de los acuerdos de nivel de
servicio (SLA).
Realizar los informes necesarios, como por ejemplo, los informes puntua-
les de actividad a peticin, los informes del progreso del contacto y los
informes detallados de la actuacin del service desk.
Teleoperador. Con frecuencia, en primera lnea del service desk se pone un

conjunto de operadores telefnicos que nicamente realiza tareas de registro
de incidentes y de contacto con los usuarios. En este caso, esta lnea de aten-
cin forma parte de la primera lnea de soporte. La tendencia es reducir estas
posiciones de atencin, reemplazndolas por herramientas de autorregistro.
Especialista del service desk (primera lnea). En el caso de no haber teleopera-
dores, atiende los contactos de los usuarios (llamadas de telfono, autorre-
gistro web, etc.) y los registra generando un ticket del mismo. Resuelve con-
sultas sencillas, clasifica los incidentes, tramita las peticiones y mantiene
informado al usuario. Realiza un primer diagnstico de la incidencia.
Resuelve todas las incidencias que puede, en esta primera lnea de soporte,
para reducir el paso de trabajo a otros niveles ms especializados y ms caros.
Las que no puede resolver las escala a la siguiente lnea de soporte (escalado
funcional). Resuelve o escala los incidentes abiertos por las herramientas de
monitorizacin.
Especialista de soporte (lneas 2 y 3). Es el rol responsable de diagnosticar la
incidencia, resolverla, comprobarla, asignarla a otro grupo y documentarla.
Participa en la resolucin in situ de incidentes que no pueden resolverse
desde una ubicacin remota y en el tratamiento personalizado de las inciden-
cias de los usuarios de direccin. Est formado por grupos de especialistas
tcnicos en la gestin de la tecnologa, en la administracin de las aplicacio-
nes y sus datos, o en el desarrollo de software. Incluye a los grupos internos y
al soporte de fabricantes y terceros.
Administracin y soporte al proceso del incidente. Apoya al gestor del inci-
dente en sus responsabilidades. Vela por la implicacin de los equipos ante la
llegada de una incidencia crtica, asegurando que se cumplen los SLA. Coor-
dina los escalados entre grupos en caso de necesidad. Supervisa a los miem-
bros de las diferentes lneas de soporte. Participa en la resolucin de conflic-
tos internos.
Los roles ajenos que son relevantes en este proceso son los siguientes:
El responsable de gestin de la configuracin, pues el acceso a la CMDB es
imprescindible para toda la actividad de la gestin del incidente.
El responsable de problemas facilita soluciones y errores conocidos para la
resolucin de nuevos incidentes.
El responsable de la gestin del servicio vela por que todos los servicios cum-
plan los niveles pactados.
El responsable de gestin de la entrega. Su proceso debe proporcionar for-
macin al service desk y a las otras lneas de soporte sobre los nuevos servicios
o evolucin de los existentes.
El responsable de la gestin del cambio debe proporcionar informacin de
todos los cambios en los componentes (CI).
El propietario del modelo de gestin de TI (SGSTI) acta como propietario
del proceso (process owner), define las actividades del proceso y se encarga de
la mejora continua del mismo. Todo ello, de una forma integrada con el
modelo de gestin de TI o SGSTI.
Roles del proceso (slo ciclo de vida del incidente)
Responsable de la
gestin del servicio
SGSTI
Gestor del Administrador y

incidente soporte del proceso
Propietario del
modelo (SGSTI)
Gestor de la
configuracin Especialista de Especialista de Especialista de
Gestor del service desk lnea 2 lnea 3
problema (proveedor TI) (fabricante)
Figura 8.2.14. Roles del proceso de gestin del incidente
Resumen
ISO/IEC 20000 e ITIL v2 tratan en un mismo proceso los dos ciclos de la gestin
del incidente y la gestin de la peticin del usuario, porque ambos ciclos tiene una
parte comn (el service desk) y con frecuencia se ve involucrado el mismo personal
tcnico en su tratamiento. En cambio, en ITIL v3 se ha decidido separar estos
ciclos en dos procesos diferenciados, pues el primero debe restaurar cuanto antes el
servicio para que el negocio pueda seguir trabajando aportando productividad,
mientras que la gestin de peticiones atiende nuevas necesidades predefinidas al
usuario y otorga agilidad al negocio.
La gestin del incidente es un proceso esencial para apagar los fuegos que se
produzcan en TI y minimizar el impacto en el negocio de los fallos y cadas de los
servicios.
Es muy importante no olvidar la necesidad de buenos especialistas tcnicos, sin los

cuales todo intento de mejora ser intil.
Hay que entrenar a los equipos de soporte en ser eficientes en su trabajo, principal-
mente a los especialistas de lnea 2, pues deben compaginar su dedicacin a resol-
ver incidentes rpidamente con otras funciones tcnicas a medio plazo.
La informacin es esencial, tanto la proporcionada por la CMDB, como la obtenida
desde la base de dato del conocimiento (sobre incidentes, sobre problemas, etc.).
Disponer de una herramienta de soporte al proceso es algo irrenunciable.
Hay que poner foco en el autorregistro, la autorresolucin y en la resolucin de
incidentes en la primera lnea.
Los incidentes y peticiones generan un gran volumen de actividad y tienen un flujo
que recorre gran parte de la organizacin, por lo que todo esfuerzo en su reduc-
cin y optimizacin aportar grandes beneficios.
Hay que prever y elaborar el procedimiento de actuacin del soporte ante los inci-
dentes graves.
La gestin de conocimiento tcnico, es una labor de toda la organizacin, no ni-
camente de este proceso. Se debe disponer de una herramienta de gestin del cono-
cimiento y gestin documental que facilite su almacenamiento y consulta.
Beneficios
Algunos de los beneficios de alcanzar una correcta gestin el incidente son los
siguientes:
Resolucin ms rpida de los incidentes y reduccin del impacto en el nego-
cio de los fallos. Se produce una mejora de la disponibilidad.
El proceso pone foco en la restauracin del servicio, como eje fundamental.
Mejor alineacin de TI con las necesidades en el da a da del negocio.
Mejor atencin a los usuarios.
Tratamiento eficiente del alto volumen de actividad requerido. Implementa-
cin de herramientas de autoatencin por parte de los usuarios.
Mayor nmero de incidentes resueltos en primera lnea, con lo que se alivia
la carga de trabajo de las lneas de soporte ms especializadas.
Estar preparado ante las crisis.
Retencin del conocimiento.

Identificacin de fallos recurrentes para que se solventen por la gestin del
problema. Mejora de la infraestructura.
Oportunidad de mejora de los servicios, tanto en su resistencia al fallo, como
en su usabilidad.
El service desk puede identificar nuevas necesidades de servicio o de forma-
cin.
Revisin del ciclo de vida de provisin de peticiones para su optimizacin.
Identificacin de necesidades de provisin. Las peticiones y comentarios.
Reduccin de costes ocultos.
Describa las etapas de la gestin del incidente en su organizacin.
Qu mejorara para que la resolucin de incidentes fuera ms efi-
ciente?
Describa el ciclo de gestin de peticiones en su organizacin.
1
8.3. Gestin del problema 589
8.3. Gestin del problema
Figura 8.3.1. Actividades principales del proceso de gestin del problema
La gestin del incidente est centrada en apagar y apagar incendios, y no debe

perder ni un segundo en resolver la causa que los provoca. Pero si nicamente se
hiciera esto, no se resolveran los defectos y los servicios se volveran a caer una y
otra vez. El personal de soporte tendra cada vez ms actividad de apaga fuegos
y se pasara todo el da levantando servicios que volveran a fallar. Para evitarlo se
define un segundo proceso dentro de la categora de resolucin que va por detrs
del proceso de gestin del incidente, eliminando los defectos ya aparecidos en los
componentes de TI. Tambin trabaja buscando los defectos latentes, evitando que
se manifiesten y causen estragos en la funcionalidad prestada al cliente.
Por tanto, la gestin del problema es el proceso que identifica la causa raz de los
fallos que ocurren o que potencialmente pueden ocurrir en los servicios de TI, al
objeto repararlos para evitar la aparicin de nuevos incidentes o la repeticin de los
mismos.
Si la gestin del incidente se enfoca en resolver los incidentes, la gestin del pro-
blema se centra en evitar que se produzcan, para lo cual identifica y subsana los
defectos en los componentes de los servicios para aumentar su estabilidad y su ren-
dimiento. As, se minimiza el impacto negativo que tienen sobre el negocio los
fallos en los elementos de TI y se contribuye a la mejora continua de la infraestruc-

tura que soporta los servicios.
Conviene tener claro que este proceso no interviene en la resolucin como tal de
un incidente cuando est abierto. En esta etapa es el proceso de gestin del inci-
dente el nico dueo y seor de la situacin. La gestin del problema se activar
para identificar y eliminar la causa que provoc el incidente, una vez restaurado el
servicio o de forma paralela a su restauracin.
La gestin del problema es uno de los procesos ms sencillos de iniciar y que antes
produce resultados, por tanto debe tenerse en cuenta para proporcionar xitos rpi-
dos (quick-wins).
En su misin de evitar que se produzcan incidentes, el proceso de gestin del pro-
blema trabaja los aspectos reactivos y los proactivos. La parte reactiva trata de
resolver los defectos que ya se han identificado, bien sea por el propio proceso, por
la gestin del incidente, por otros procesos (gestin de nivel de servicio, gestin de
la disponibilidad, gestin de la capacidad, etc.) o bien por otras reas (desarrollo,
seguridad, soporte tcnico, ingeniera, arquitectura, etc.). Mientras que el aspecto
proactivo est relacionado con la bsqueda de los defectos latentes, que no han
aparecido todava pero que generarn interrupciones en los servicios.
En la figura 8.3.2 se presenta un esquema introductorio al proceso.

del problema Reduce el nmero de incidentes.
Estabiliza el entorno de produccin.
Definicin: Asegura la resolucin de defectos
graves que afectan al servicio.
La misin del proceso es evitar que se
produzcan incidentes repetitivos o Identifica la causa raz de las
nuevos. Para lo cual, identifica y subsana incidencias, evitando su repeticin.
los defectos en los componentes de los Propone proyectos de mejora para
servicios. resolver los defectos.
Encuentra soluciones provisionales y
Objetivo: permanentes.
Minimizar los efectos negativos sobre Realizar el seguimiento de la

el negocio de interrupciones del resolucin de los problemas
servicio, mediante la identicacin identificados.
y el anlisis proactivos de la causa Registra el conocimiento tcnico.
de los incidentes y la gestin de los
problemas para su cierre.
Figura 8.3.2. Introduccin al proceso de gestin del problema

Los principales beneficios que aporta la gestin del problema son los siguientes:
Reduce el nmero de incidentes y, por tanto, mejora la calidad de los servi-
cios.
Estabiliza los servicios en produccin regular para mantener el transcurrir
normal del negocio.
En su trabajo, encuentra soluciones provisionales y permanentes a los defec-
tos de los servicios.
Asegura la resolucin de defectos graves que afectan al servicio.
Identifica la causa raz de los incidentes, evitando incidentes repetitivos.
Propone proyectos de mejora para resolver los problemas.
Realiza el seguimiento de los problemas identificados.
Incrementa el conocimiento de la organizacin, proporcionando:
La identificacin de tendencias en los datos histricos.
Los medios para prevenir fallos y para reducir el impacto de los fallos en
el negocio.
Los errores conocidos, soluciones provisionales y soluciones permanentes
a la base de datos del conocimiento.
La mejora del ratio de resoluciones de incidentes en el primer contacto o
en la primera lnea de atencin por el service desk.
Para el xito del proceso es necesario desplegar tres disciplinas bsicas: un buen
conocimiento tcnico, una vocacin por la calidad tcnica y el seguimiento de los
temas hasta que los defectos queden completamente eliminados. En la figura 8.3.3
se muestran estas disciplinas esenciales del proceso.
Tarde o temprano, los defectos latentes acaban saliendo a la luz, generando inci-
dentes en los servicios. En este momento aparece la necesidad de disponer de espe-
cialistas con un buen conocimiento tcnico para realizar la investigacin a fondo
hasta identificar el defecto y buscar una solucin.
El proceso tambin requiere perseverancia para el seguimiento de todos los temas
hasta su finalizacin, pues con frecuencia, ser necesaria la participacin de muchas
reas tcnicas: unas veces habr que revisar todo un desarrollo, otras los equipos de
comunicaciones, en ocasiones habr que reemplazar un equipamiento o actualizar
al ltimo parche el software base. Por tanto, el proceso debe controlar mltiples acti-
vidades de resolucin de los problemas que transcurrirn en paralelo, actuando
Figura 8.3.3. Bases de la gestin del problema
como coordinador e impulsor de la actividad de otros procesos o grupos de

soporte.
El proceso tambin requiere una autntica vocacin por la calidad tcnica de los
componentes, buscando indicios de defectos latentes y disfrutando con la mejora
paulatina de los servicios. En la vorgine que actualmente existe en el interior de
las organizaciones de TI, mantener una actividad cuyos resultados tengan efectos
en un futuro puede parecer una situacin idlica y utpica. Pero las organizaciones
maduras, que ya han implementado la parte proactiva del proceso, obtienen gran-
des beneficios en la estabilidad de los servicios y en la tranquilidad de la organiza-
cin con estas acciones proactivas de mejora tcnica continua.
Los principales componentes que son necesarios para el correcto desempeo del
proceso se muestran en la figura 8.3.4.
En ITIL este proceso est dotado de cierta riqueza terminolgica para de tener clara-
mente identificadas las fases por las que pasa un problema (problema, error y error
conocido) y los tipos de soluciones (provisional o permanente).
Problema. Conjunto de hechos o circunstancias que dificultan la consecucin de
los servicios y provocan incidentes. Es la causa desconocida que origina uno o ms
incidentes, existentes o potenciales. Los problemas se pueden identificar a travs de
Problema
Service desk Solucin provisional
Gestin incidente Causa raz (workaround)
Gestin disponibilidad CONTROL DE Error
Gestin capacidad PROBLEMAS
Solucin
Gestin nivel de servicio
Ticket de Error permanente
reas tcnicas
problema conocido
Seguridad (KE)
Desarrollo
Solicitud de
cambio (RFC)
CONTROL DE
PREVENCIN ERRORES
PROACTIVA DE
PROBLEMAS Problema PIR
resuelto Resolucin
del error
CMDB BD de problemas
Conocimiento
BD incidentes Base datos Fichas de Errores tcnico
configuracin problemas conocidos
Figura 8.3.4. Componentes principales del proceso
la aparicin de varios incidentes que muestren sntomas comunes. Tambin pueden

identificarse a partir de un incidente de alta relevancia. Otras veces se identificarn
antes de que ocurran incidentes.
Causa raz. Es el defecto o tara que origina incidentes. Este concepto es impor-
tante, pues a partir de l se divide en dos etapas el ciclo de vida del problema.
Conocer la causa no implica que se conozca la forma de solucionarla.
Error. Un defecto o mal funcionamiento que causa fallos de uno o ms elementos
de configuracin o servicios TI. Un error cometido por una persona o un desper-
fecto en un proceso que impacta un CI o un servicio TI es tambin un error. Un
problema pasa a la categora de error cuando se ha identificado la causa raz que
origin el problema y origina el paso a la segunda fase del proceso (control de
errores).
Error conocido (KE, Known Error). Es un error para el que, adems de cono-
cerse cul es la causa raz que lo origin, se ha diseado o definido tambin la o las
formas de resolverlo, mediante una solucin provisional o una solucin perma-

nente. El error conocido se trata como una unidad de informacin especfica y se
registra mediante una ficha que contiene el conocimiento sobre su resolucin. Los
errores conocidos se registran por el propio proceso de gestin del problema, pero
tambin pueden ser dados de alta por otros actores externos al proceso, general-
mente se tratar de otras reas de ndole tcnico, como por ejemplo, infraestructu-
ras, seguridad, desarrollo, etc.
Solucin provisional o workaround. Es la solucin temporal a un error con el fin
de restaurar rpidamente un servicio. Las soluciones provisionales no eliminan o
resuelven la causa raz (vase el apartado 8.1 Antecedentes). Los workaround se
crean en diversos mbitos, por ejemplo, en el proceso de gestin del incidente para
la restauracin del servicio, en el propio proceso de gestin del problema y tam-
bin pueden ser originados por el equipo de desarrollo debido a fallos identificados
en la aplicacin durante las pruebas de certificacin. La gestin del problema
deber tratar de eliminar estos parches en los servicios para implantar soluciones
permanentes.
Solucin permanente. Es el conocimiento de la forma de erradicar definitiva-
mente la causa raz que dio origen al fallo, como por ejemplo, mediante mejoras en
la infraestructura. Las soluciones permanentes son identificadas por el proceso de
gestin del problema, pero las construyen las reas de desarrollo o de infraestructu-
ras, las autoriza la gestin del cambio y las implementa la gestin de la entrega.
Resumiendo toda esta secuencia semntica, importante para conocer el proceso:
un problema latente se manifiesta y provoca incidentes, por lo que pasa a la catego-
ra de problema (no se conoce la causa pero se sabe que hay algo que est provo-
cando incidentes). Investigando el problema se encuentra la causa raz que lo ori-
gin, por lo que el problema pasa a estado de error. En el momento en el que se le
encuentra una forma de solucionarlo, el error se convierte en un error conocido.
Las soluciones pueden ser provisionales o permanentes.
Ticket de problema. Ficha o registro que contiene los datos asociados a un pro-
blema. El soporte del registro no es obligatorio que sea electrnico, aunque es reco-
mendable por su facilidad de utilizacin.
Base de datos de problemas. Repositorio que contiene informacin necesaria
para el proceso de gestin del problema. Est divida en dos partes lgicas: la fichas
de problemas y los registros de errores conocidos.
Conocimiento tcnico. Diversas fuentes de conocimiento tcnico existentes,
como por ejemplo, las generadas por la organizacin de TI, de los fabricantes, etc.
Clasificacin de un problema. Al igual que ocurre con los incidentes y con los
cambios, es necesario clasificar un problema para determinar inicialmente el grupo
de resolucin al que asignarlo y el orden de ejecucin. La clasificacin de los pro-

blemas sigue los mismos criterios que los utilizados para incidentes: se asigna una
categora (hardware, software, etc.) y una prioridad (en funcin del impacto y de la
urgencia).
La clasificacin del problema puede variar a lo largo de la vida del problema, segn
se vaya avanzando en su conocimiento, desde los indicios iniciales hasta su resolu-
cin. La clasificacin de un problema permitir a otros procesos acceder al conoci-
miento de los errores conocidos de forma precisa, mientras que la prioridad permi-
tir identificar los problemas a resolver en primer lugar.

En una organizacin grande, la cantidad de problemas abiertos suele rondar entre
100 y 200 tickets al mes, al contrario que en incidentes y peticiones que suele osci-
lar entre 10.000 y 30.000 al mes. El nmero de tickets de problemas es de un orden
de magnitud cien veces inferior al de incidentes. Por ello, la implantacin de la ges-
tin del problema es organizativamente mucho ms sencilla, muy centrada en acti-
vidades de investigacin tcnica y anlisis.
Las funcionalidades que se deben desarrollar en la gestin del problema se resumen
en el esquema de la figura 8.3.5.
La entrada principal que activa el proceso es la recepcin de tickets de problemas
por parte del service desk, de la gestin del incidente, de la gestin de la disponibili-
dad, de la gestin de la capacidad, de la gestin de nivel de servicio, etc. Otras
entradas que desencadenan el proceso son los fallos y sus soluciones provisionales
o workarounds aplicados, y la informacin de defectos en los productos proporcio-
nada por los proveedores. Tambin es importante tener en cuenta que actores exter-
nos al proceso de gestin del problema (pertenecientes generalmente a otras reas
como desarrollo, seguridad o infraestructuras) pueden generar errores conocidos
que entran directamente en la mitad del proceso, en el control de errores. Otra
entrada que identifica problemas puede ser la revisin proactiva o diaria de los dis-
tintos elementos del servicio; por ejemplo, un grupo responsable de la administra-
cin de bases de datos, mediante las revisiones diarias de las mismas, pueden iden-
tificar posibles problemas que an no han desencadenado incidencias.
El proceso utiliza tambin entradas de soporte que aportan la informacin necesaria,
como por ejemplo, la informacin de los incidentes procedente de la base de datos
de incidentes, la informacin sobre los componentes de los servicios desde la base de
datos de gestin de la configuracin (CMDB), su comportamiento y su relacin con
los niveles de servicio comprometidos con los clientes, el conocimiento tcnico de la
Desencadenantes REACTIVAS: Salidas principales:

del proceso: 3 Control de problemas Problemas resueltos.
Tickets de problema (buscar la causa raz). BD de problemas, con
desde service desk, 3 Control de errores los errores conocidos:
otros procesos y otras (diseo de la solucin y Soluciones provisionales.
reas. resolucin definitiva). Soluciones permanentes.
Fallos y sus
workarounds aplicados. RFC a gestin del
PROACTIVAS: cambio.
Informacin de
productos de los 3 Revisin de problemas
importantes. Salidas secundarias:
fabricantes.
3 Prevencin proactiva Notificacin de
Errores conocidos
de problemas (identificar resolucin del ticket
identificados por
posibles problemas). de problema
otras reas ajenas
(a incidentes, etc.).
al proceso.
3 Supervisin y mejora del Base de datos de
Revisin proactiva de
proceso. incidentes.
los elementos del
servicio. Modificaciones en la
CMDB.
Entradas de soporte: Informacin gestin y
BD de incidentes. costes.
CMDB. Propuestas de mejora.
Conocimiento tcnico.
Estado del RFC desde
gestin del cambio.
Fuente: e.p., libro ITIL Soporte de Servicio publicado por OGC y Telefnica.
organizacin o de los fabricantes, la situacin de evolucin de las peticiones de cam-

bio emitidas para la erradicacin de los problemas, etc.
Las actividades principales del proceso son las siguientes:
Control de problemas (buscar la causa raz). Se ocupa de la identificacin,
registro, clasificacin y seguimiento de los problemas, llevando a cabo la
investigacin y diagnstico de su causa raz. Al finalizar la etapa, el problema
alcanza el estado de error, es decir, se conoce su causa raz. En la actividad
de investigacin de la causa raz tambin se identifican las diversas vas de
solucin, que servirn de entrada al control de errores. Si se ha descubierto
tambin la forma de resolverlo se alcanza directamente el estado error cono-
cido y se pasa directamente a la etapa de control de errores.
Control de errores (diseo de la solucin y su resolucin definitiva). Esta

fase parte de un error, generado en la etapa anterior, para despus valorar la
idoneidad de la alternativas de solucin, disear la ms adecuada y gestionar
su construccin e implementacin.
Mientras que el control de problemas se centra en la bsqueda de la causa
raz, el control de errores se centra en su resolucin definitiva.
Revisin de problemas importantes. Es necesario que en los problemas
ocurridos con trascendencia o con un impacto alto en el negocio, se lleve a
cabo una revisin de lo ocurrido, para proponer mejoras en las infraestructu-
ras, en las formas de actuacin de las personas o en la propia organizacin.
Prevencin proactiva de problemas (identificar posibles problemas). Tiene
como objetivo la prevencin de los posibles problemas antes de que ocurran,
analizando las tendencias e identificando componentes dbiles o sobrecargados.
Supervisin y mejora del proceso. Conjunto de actividades ligadas que
tiene como objetivo que el proceso funcione a la perfeccin mediante la
supervisin de su funcionamiento y la identificacin de actividades para
la mejora continua. Para ello se debe:
Capturar indicadores que permitan medir el proceso, puesto que no se
puede mejorar lo que no se puede medir.
Verificar el grado de cumplimiento del proceso establecido mediante la
realizacin de auditoras peridicas.
Monitorizar el proceso realizando el control y seguimiento de los proble-
mas y errores a lo largo de todo su ciclo de vida.
Evaluar los resultados obtenidos y de forma consensuada con los respon-
sables de otros procesos afectados, identificar planes de mejora.
Las salidas principales del proceso de gestin del problema son los problemas
resueltos y la base de datos de problemas, que contiene los errores conocidos con
sus soluciones provisionales y permanentes. La informacin sobre los errores cono-
cidos es una fuente importante de conocimiento, a veces se considera una base de
datos independiente de los errores conocidos, y es esencial para que el proceso
de gestin del incidente diagnostique y resuelva con rapidez. Tambin es una salida
principal las peticiones de cambio (RFC) generadas para la construccin e imple-
mentacin de las soluciones (provisionales o permanentes) encontradas.
Otras salidas de ndole secundario son la notificacin sobre la evolucin o resolucin
del problema a quin gener el ticket del problema; la base de datos de incidentes
actualizada con las causas races identificadas, con las soluciones provisionales o
ermanentes encontradas a estos incidentes; la actualizacin de la CMDB con infor-

macin sobre los defectos encontrados en los elementos de configuracin y sus solu-
ciones; informacin de gestin del proceso, de sus costes y de las valoraciones
de costes asociados a la investigacin y resolucin de problemas; o las propuestas de
mejora de las infraestructuras o de los procesos, encontradas a lo largo de la activi-
dad del proceso.
Alcance de la gestin del problema
UNE-ISO/IEC 20000-2
El proceso de gestin del problema cin o la duplicacin de los incidentes o

debera investigar las causas subyacen- de los errores conocidos de acuerdo
tes de los incidentes. con los requisitos del negocio.
La gestin del problema debera preve-
nir de una manera proactiva la repeti-
La gestin del incidente y la gestin del problema tienen dos objetivos claramente
diferenciados. Mientras el primero debe recuperar el servicio lo antes posible, el
segundo se ocupa de que ese tipo de incidente no se reproduzca.
Tambin en los mtodos de ejecucin actan de forma diferente. Mientras la gestin
del incidente trabaja en una carrera contrarreloj para lograr obtener la recuperacin
del servicio en tiempo rcord; la gestin del problema trabaja, normalmente a medio
plazo, para erradicar la causa raz con independencia del cierre o no del incidente.
La gestin del problema requiere un esfuerzo nada despreciable, tanto econmico,
como de apoyo de la direccin, ya que el equipo de resolucin de problemas, a
menudo experto en la tecnologa afectada, debe liberarse del da a da. As, se nece-
sita el soporte de la direccin para la dedicacin de estos recursos y mantenerlos,
aunque en ocasiones los plazos de resolucin se prolonguen.
Tambin, el proceso debe velar por que el ratio coste (de investigacin y de resolu-
cin) frente al beneficio (por la eliminacin de los incidentes) sea ptimo.
A la hora de iniciar la implementacin del proceso se recomienda poner primero
foco en resolver los problemas que se produzcan en los servicios vitales para el
negocio, para ir extendiendo paulatinamente su cobertura al resto de servicios
menos crticos. En etapas posteriores se incorporarn las actividades proactivas,
para identificar los problemas latentes antes de que generen incidentes.
Por otra parte, la eficacia de este proceso slo podr obtenerse, tras disponer de un pro-
ceso de gestin del incidente suficientemente maduro, que registre toda la informacin
necesaria (clasificacin, sntomas, resolucin, etc.) para poder actuar a posteriori.
Tambin es conveniente disponer de buenos sistemas de monitorizacin tecnol-
gica, correlacin de eventos y anlisis de estadsticas.
Ciclo de vida de un problema

De forma similar a la gestin del incidente, las actividades repetitivas de este pro-
ceso se pueden agrupar bajo el concepto de ciclo de vida del problema, teniendo en
cuenta que este proceso no gestiona grandes volmenes de actividad, ya que es un
proceso centrado en la investigacin profunda y tenaz. En la figura 8.3.6 se pre-
senta un esquema de este ciclo.
Figura 8.3.6. Actividades del ciclo de vida de un problema

El ciclo de vida de un problema se estructura en dos etapas o subprocesos: el con-

trol de problemas y el control de errores.
Control de problemas
La etapa de control de problemas es la primera que se activa cuando se detecta un
problema, se inicia con la recepcin del ticket del problema y concluye con la iden-
tificacin de la causa raz del mismo. El ticket entra en estado de problema y sale en
estado de error.
UNE-ISO/IEC 20000-1
Se deben registrar todos los problemas identificados.

Se deben adoptar procedimientos para identificar, minimizar y evitar el impacto de
los incidentes y de los problemas. Estos procedimientos deben definir el registro, la
clasificacin, la actualizacin, el escalado, la resolucin y el cierre de todos los pro-
blemas.
UNE-ISO/IEC 20000-2
Se deberan clasificar los incidentes Nota: Cuando se registren incidentes por primera
para ayudar a determinar las causas de vez, su categorizacin se ver influenciada
por otros factores que incluyen el servicio,
los problemas. La clasificacin puede
el rea de negocio afectada y los sntomas
hacer referencia a los problemas y cam- que se presenten.
bios existentes.
Al igual que en los incidentes, todo problema debe estar previamente registrado. Si
este proviene de un incidente, se deben establecer referencias cruzadas entre ambos.
Las actividades comprendidas en la etapa de control de problemas son:
Identificacin y registro de problemas. La identificacin de los problemas proviene
de distintas fuentes de la organizacin de TI, ya sea de forma reactiva o proactiva:
Del service desk y de la gestin de incidentes.
De problemas propuestos a partir del anlisis de eventos de las herramientas
de monitorizacin de la infraestructura desde la gestin de eventos.
De problemas asociados a los servicios detectados en la gestin de nivel de
servicio.
Del anlisis de tendencias realizada por la faceta proactiva del proceso.

Del anlisis de las encuestas, las quejas y las sugerencias de los usuarios, que
pueden revelar tambin posibles problemas.
Las reuniones con los clientes y las encuestas, pueden tambin llevar a la
identificacin de las tendencias y de las reas de problemas (potenciales).
Cuando se ha identificado un problema, se genera un ticket o ficha de problema,

con los datos identificativos del mismo. Estos tickets se registran en la base de datos
de gestin del problema. A lo largo de la vida del problema se ir actualizando y
enriqueciendo la informacin registrada. Un ejemplo de contenido del ticket o ficha
de problema se muestra en la figura 8.3.7. Los registros de problemas deben estar
asociados con todos los registros de los incidentes que resuelven.
Ticket o ficha de un problema
3 Nmero de ticket.
3 Persona que abri el problema.
3 Fechas: apertura, actualizaciones, cierre.
3 Estado del problema.
3 Datos descriptivos del problema:
Descripcin.
Detalles.
CI implicados. Servicio o aplicacin.
Categora.
Prioridad (impacto+urgencia). Esto ayudar a
Incidentes asociados. tener documentado
el problema ms
3 Historial del problema: escalados, participantes,
detalladamente y
descripcin de las investigaciones realizadas, etc.
dar pistas a posibles
3 Datos descriptivos de la resolucin: investigaciones para
Descripcin de la solucin provisional. solucionar otros
Descripcin de la solucin definitiva. problemas.
RFC generados, sus fechas y sus estados.
Fecha de cierre.
3 Revisin del problema
Esfuerzo y costes necesarios para la resolucin.
Beneficio aportado.
Figura 8.3.7. Ejemplo de ficha de un problema

Una buena clasificacin de los incidentes es esencial para extraer informacin pre-
cisa para la identificacin de problemas.
Por otra parte, las soluciones generadas por incidentes se deberan almacenar tam-
bin en la base de datos de problemas, para que el conocimiento se centralice en un
nico punto.
Clasificacin de problemas. Al igual que los incidentes y los cambios, los proble-
mas deben tener tambin asignada una categora y una prioridad (en funcin del
impacto y urgencia) para poder planificar los recursos adecuadamente.
Es importante que la asignacin de una categora a los problemas sea precisa y bien
realizada, para poder asignar el problema a los equipos de soporte adecuados y,
para una vez resuelto, poder acceder con precisin al conocimiento. La clasifica-
cin de un problema se va depurando segn avanza la investigacin sobre el
mismo.
Con relacin a la prioridad, se necesita que se asigne una a cada problema y aun-
que el volumen de problemas puede ser bajo, el nmero de recursos asignados a la
gestin de los problemas tambin suele ser escaso, por lo que disponer de un orden
de ejecucin resulta nuevamente fundamental. En la definicin del impacto se
estima la criticidad de los servicios que se veran afectados si el problema provocase
un incidente, el nmero de servicios, el volumen de usuarios amenazados, etc. La
urgencia se determina en funcin de la probabilidad de que se puedan producir
incidentes.
Los problemas tienen tambin un estado segn avanzan en su ciclo de vida, para
tener un mayor control del proceso y poder realizar anlisis estadsticos posteriores.
En la figura 8.3.8 se muestra un ejemplo de algunos detalles relevantes del proceso.
Investigacin y diagnstico de problemas. Los problemas se gestionan de forma
centralizada por el proceso, pero en su investigacin y resolucin se asignan a los
especialistas de TI, denominados analistas tcnicos (propietarios de los elementos
de configuracin involucrados en el problema, tcnicos de las reas afectadas,
equipo de desarrollo, responsables del servicio afectado, etc.). En la investigacin,
con frecuencia se necesita tambin la participacin de los fabricantes.
El analista tcnico de problemas asignado realiza la investigacin y diagnstico con
los medios a su alcance para identificar la causa raz del problema. Si a lo largo de
esta actividad surgen conflictos por la necesidad de dedicacin de recursos, se lo
comunicar al responsable del proceso, de modo que ste pueda tomar las acciones
correctoras necesarias.
Tradicionalmente en este punto de la investigacin se describen varias tcnicas
genricas que ayudan al anlisis en las tareas de investigacin y diagnstico.
Detalles relevantes de un problema
Estados de un problema Clase Subclase
Nuevo Hardware Instalacin

Configuracin
Clasificado
Factor humano
Asignado Funcionalidad
En diagnstico Software Inconsistencia
Rendimiento
Error
Bloqueo
Error conocido
Desconocido
En resolucin
Solucionado
Cerrado
Prioridad de un problema
IMPACTO
PRIORIDAD
Alto Medio Bajo
Se
Alta rvi
cio
sv
ita
URGENCIA
Pro les
bab , vo
ilid lum
Media ad en
de de
pro usu
duc ari
ir i os,
nci etc
Baja den .
tes
Figura 8.3.8. Ejemplo de detalles relativos a la clasificacin de un problema
El mtodo de anlisis de Kepner y Tregoe, sistematiza en 5 pasos el anlisis

de los problemas:
1. Definicin del problema.
2. Descripcin del problema (identidad, emplazamiento, tiempo y tamao).
3. Establecer las posibles causas.

4. Probar la causa ms probable.
5. Verificar la causa verdadera.
La tcnica de anlisis causaefecto de Ishikawa que plantea sobre un

esquema horizontal, de izquierda a derecha, en forma de raspa de pescado
las posibles causas y los efectos que producen.
La tcnica estadstica de Pareto, permite centrarse en el 20% de los proble-
mas esenciales, que resolveran el 80% de los incidentes. Sirve ms para fil-
trar y priorizar problemas que para investigar o diagnosticarlos
La actividad de investigacin y diagnstico de problemas es muy similar la de

investigacin de incidentes, pero el objetivo primordial en cada caso es distinto. El
primero busca el diagnstico de los defectos subyacentes, mientras que el segundo
se centra en la restauracin rpida del servicio. El objeto de la investigacin es pro-
porcionar un diagnstico del problema encontrado su causa raz. Diagnosticada la
causa raz, el problema pasa al estado de error. La investigacin tambin debe
identificar las posibles soluciones para eliminar o paliar los efectos de la causa raz.
Este abanico de soluciones servir de entrada a la fase de control de errores.
La causa de un problema puede ser debida un error en la actuacin humana (por
ejemplo, la instalacin de una versin incorrecta, olvido de cambiar algn parme-
tro de configuracin, etc.) y no slo ocasionada por un defecto en un componente.
En estos casos, el problema se resuelve corrigiendo la equivocacin (que tambin
puede requerir una peticin de cambio) y no es necesario generar una solucin
permanente, pero si es necesario registrar la solucin aplicada a efectos de mejora
del proceso.
Control de errores
El control de errores se encarga de subsanar los errores y eliminar las causas races
que los provocan. Realiza el seguimiento de todos los errores conocidos, desde su
identificacin hasta su resolucin.
UNE-ISO/IEC 20000-2
Cuando la investigacin de la gestin para resolver los incidentes, el pro-

del problema haya identificado la causa blema se debera clasificar como un
del origen de un incidente y un mtodo error conocido.
Se deberan registrar todos los errores Un error conocido no se debera cerrar

conocidos tomando como referencia los hasta que se haya resuelto satisfactoria-
servicios real o potencialmente afecta- mente.
dos adems del elemento de configura-
Nota: El cliente o el proveedor del servicio pue-
cin que se sospeche que causa el error den decidir que la resolucin resulta
en cuestin. demasiado cara o que no aporta beneficio
al negocio. En este caso, esto debera
La informacin sobre los errores conoci- quedar claramente documentado. No obs-
dos en los servicios que se estn intro- tante, el error conocido debera permane-
duciendo en el entorno productivo se cer abierto, puesto que an existe la posi-
debera pasar a la gestin del servicio y bilidad de que se produzcan incidentes a
consecuencia de este error y es posible que
se debera registrar en la base de datos se necesiten soluciones provisionales y/o
de conocimiento, junto con las solucio- una reconsideracin de la decisin para
nes provisionales existentes. resolver el error.
Las Normas ISO/IEC 20000 ponen foco en la responsabilidad de gestin del pro-
blema como generador y difusor del conocimiento sobre los errores conocidos. Los
errores conocidos se almacenan en una base de datos, tpicamente como un sub-
conjunto integrado en la base de datos de gestin del problema, y se ponen a dis-
posicin de otros procesos en modo de slo lectura. Por otra parte, la gestin del
incidente mantiene la base de datos de incidentes en la que se registra todo lo que
se analiza e identifica en la resolucin del incidente. Por tanto, las bases de datos de
problemas y de incidentes son complementarias.
Adems, los instrumentos, ms utilizados en la resolucin de incidentes son el
rbol de tipologas de incidentes, la base de datos de incidentes, con la resolucin
de incidentes similares, y la base de datos de problemas, en su vista de los errores
conocidos.
Por ello, la coordinacin aqu es muy importante ya que se debe aportar coherencia
y consistencia a las clasificaciones de cada elemento. Muchas veces, aparecen rbo-
les de tipologas (propiedad del proceso de incidentes), que simulan la lista de erro-
res conocidos (propiedad de gestin del problema), que se solapan y confunden al
tcnico de soporte de primer nivel.
Identificacin y registro de errores. En el proceso los errores se tratan como una
estructura de informacin especfica, por ello, la primera actividad de la etapa de
control de errores es la identificacin y el registro de los mismos.
Valoracin de errores. En esta actividad se realiza una evaluacin de los recursos y
plazos necesarios para las alternativas de solucin. En la evaluacin se contrasta el
coste con los beneficios y la situacin actual de la organizacin, para determinar si

se lleva a cabo su resolucin.
Puede ocurrir que el coste de resolucin de un problema o el esfuerzo requerido
no compense o justifique su realizacin. Como se aprecia en el ejemplo de un caso
real en el que una aplicacin de recursos humanos para el autoservicio de los
empleados, de uso poco intensivo, montada sobre una arquitectura web de tres
capas y que se bloqueaba espordicamente varias veces al da. El equipo de proble-
mas identifica e implanta primero una solucin provisional, mediante un programa
(o cron) que supervisa continuamente el funcionamiento del servidor web, que
cuando se bloquea lo reinicia. As, el bloqueo dura un minuto escaso. Se contacta
con el fabricante, que informa que para resolverlo es necesario actualizar a la ltima
versin el producto base. Pero esto conlleva un coste alto, pues es necesario revisar
todo el aplicativo y la parametrizacin del producto base. Dado que la solucin
provisional permite salir temporalmente del paso, se decide no resolverlo definiti-
vamente hasta que por necesidades funcionales sea necesario realizar una actualiza-
cin de versin de esta plataforma.
Registro de la resolucin del error (investigacin de la solucin y lanzamiento
de la RFC). En este momento se realiza la investigacin detallada para encontrar o
disear la solucin permanente. La identificacin de la causa raz y el conocimiento
de la solucin permanente a aplicar, en muchos casos no implica que se tenga dis-
ponible el nuevo componente a cambiar, que se haya adquirido el producto o que
se tenga ya el desarrollo modificado. Para la construccin de la solucin perma-
nente, se genera una peticin de cambio (RFC) para que el proceso de gestin del
cambio apruebe la construccin de la solucin por las reas adecuadas (desarrollo o
infraestructuras). Una vez construida la solucin, el proceso de gestin de la
entrega se encargar de su implementacin.
UNE-ISO/IEC 20000-1
Se deben remitir al proceso de gestin del cambio los cambios necesarios para
corregir la causa subyacente de problemas.
UNE-ISO/IEC 20000-2
Cuando la causa raz se haya identifi- debera conducir a travs del proceso
cado y se haya tomado una decisin de gestin del cambio.
para resolver el error, la resolucin se
En el momento en que se conoce una solucin provisional o permanente, el error

pasa al estado de error conocido. El conocimiento completo sobre el error cono-
cido se almacena en la vista o base de datos de errores conocidos.
Tambin existen otras fuentes de errores conocidos generados desde otras reas,
como por ejemplo, la informacin de los fabricantes, la informacin desde el
mbito de seguridad en cuanto a nuevas vulnerabilidades y, muy frecuentemente,
los que llegan desde el desarrollo de aplicaciones. Estos errores conocidos se regis-
tran directamente en la base de datos de errores conocidos.
Cierre de errores (y revisin postimplementacin). Enviada la peticin de cam-
bio para la construccin de la solucin, desarrollada e implementada, el proceso de
gestin de la entrega realiza la primera revisin postimplementacin (PIR, Post
Implementation Review) de cambios para comprobar que la solucin se ha implan-
tado con xito. Este hecho se comunica a la gestin del cambio, que registra el PIR
y cierra el cambio. La gestin del cambio comunica a control de errores que su
cambio se ha implementado con xito, que comprueba (PIR de problemas)
durante un perodo que no se vuelven a producir incidentes y se asegura que la
reparacin ha sido efectiva. Esta comprobacin, en el caso de problemas menores,
puede reducirse a un contacto con el usuario para comprobar que todo va correcta-
mente. En el caso de problemas graves es necesaria una revisin formal.
UNE-ISO/IEC 20000-2
El procedimiento de cierre del registro soporte estn al corriente de la

debera incluir comprobaciones para resolucin;
garantizar que: d) el cliente acepte que la resolucin
a) los detalles de la resolucin se se ha conseguido;
hayan registrado con precisin; e) el cliente sea informado si no se
b) la causa est categorizada para va a llegar a una resolucin o
facilitar el anlisis; sta no resulta posible.
c) si es necesario, tanto el personal
del cliente como el personal de
En el cierre, las mejores prcticas indican que:

No solamente se debe contemplar que el cambio ha culminado con el xito
que certifica su revisin postimplementacin (PIR de cambios).
Sino que, tambin se revisa desde el proceso de gestin del problema que los
incidentes no se reproducen (PIR de problemas), normalmente pasado un
tiempo prudencial, que variar segn las estadsticas de anlisis de problema

y su temporalidad.
Y que tambin, una vez subsanado el error conocido, se deshacen todos los
workarounds o soluciones provisionales que se realizaron para mantener dis-
ponible la infraestructura afectada, sanendola y dejndola en optimas condi-
ciones (por ejemplo, quitando el cable auxiliar que se haba tendido fuera de
su canalizacin, eliminando el programa cron que reiniciaba el servicio, etc.).
Resumiendo, mientras el PIR de cambios certifica que el cambio y la entrega han

sido satisfactorios segn las especificaciones constructivas originales, el segundo
PIR de problemas constata que los incidentes no se han vuelto a repetir, y se puede
dar por concluido el caso o problema.
En el cierre del error y del problema se revisan la documentacin sobre el error
conocido y la solucin permanente, y se documenta con el detalle suficiente para
que la primera lnea de soporte pueda implementarla o pedir que se implemente.
El registro de error conocido se cierra, junto con el del problema y el de los inci-
dentes relacionados.
Se aade a la informacin del cierre un breve estudio del retorno de la inversin
efectuado en la resolucin del problema, en trminos de ahorro del lucro cesante
en trminos econmicos, que el negocio entienda y que tambin documentarn de
manera tangible los beneficios del proceso.
Comunicacin y conocimiento
Las Normas ISO/IEC 20000 recomiendan que se comunique a las partes interesa-
das las soluciones provisionales, permanentes y el progreso de la resolucin del pro-
blema. Pero la faceta de comunicacin del proceso va ms all, proporcionando una
base de conocimiento de errores conocidos muy importante a la organizacin en
general y especialmente a la gestin del incidente. Adems, presenta informes a la
direccin y a otros procesos sobre la evolucin de su actividad, y especialmente al
centro de servicio al usuario.
UNE-ISO/IEC 20000-1
Para que resulte eficaz la resolucin de problemas, se debe supervisar, revisar y ela-
borar informes sobre ella.
El equipo de gestin del problema debe ser responsable de garantizar que est dis-
ponible, para la gestin de incidentes, la informacin actualizada sobre errores
conocidos y problemas corregidos.
UNE-ISO/IEC 20000-2
La informacin sobre soluciones provi- comunicar a las partes afectadas o

sionales, arreglos permanentes o el pro- puede requerirse para dar soporte a los
greso de los problemas se debera servicios afectados.
Es una buena prctica poner a disposicin libre de todo el personal tcnico todas las
soluciones de errores, tendencias, previsiones y el resto de conocimiento que desde
gestin del problema se genere. Y tambin lo es, aprovechar el feedback que, ante
dicho conocimiento, propongan los colaboradores de los equipos de soporte tcnico.
Seguimiento y escalado de problemas y errores

De forma transversal a todo el proceso se debe desarrollar la actividad de segui-
miento de los problemas y errores, y su escalado a otras reas o a la direccin para
obtener el respaldo adecuado. En la funcin de seguimiento se generan informes
sobre la evolucin del proceso, contrastndolo con los acuerdos de nivel de servicio.
UNE-ISO/IEC 20000-2
Se debera realizar un seguimiento del c) la distribucin de informacin en

progreso de todos los problemas. cascada a los clientes y colegas
para que puedan llevar a cabo las
Todos los problemas se deberan esca-
acciones adecuadas para minimi-
lar a las partes apropiadas. El proceso
zar la repercusin del problema no
debera cubrir:
resuelto;
a) el registro de los cambios de las
d) la definicin de los puntos de esca-
identidades de los responsables de
lado;
la resolucin de problemas durante
el ciclo de vida de cada problema; e) el registro de los recursos emplea-
dos y de las acciones realizadas.
b) la identificacin de incidentes que
rompan los objetivos del nivel de
servicio;
Durante el ciclo de vida del problema, se debe registrar informacin para poder
realizar el seguimiento y escalado. A veces no es sencillo descubrir al inicio del
registro del problema todos los actores que van a acabar trabajando en l. Por esto
se debe alimentar constantemente el registro del caso, con todos los implicados y
sus aportaciones. Como en un anlisis forense, cualquier prueba que sea subesti-
mada en una parte del proceso puede ser vital para el esclarecimiento del caso. En
un problema pasa lo mismo; todos los elementos son vitales para la determinacin
de la causa raz.
Revisin de problemas importantes

Una vez finalizada la resolucin de un problema importante, el proceso de gestin
del problema debe realizar una revisin del mismo con el fin de identificar lo que
se realiz bien, los errores de actuacin, las mejoras y la forma de evitar que vuelva
a ocurrir un problema de este tipo.
UNE-ISO/IEC 20000-1
Las acciones de mejora identificadas durante este proceso se deben registrar e

incluir en el plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Se deberan realizar revisiones de los pro- de problemas respecto a los nive-

blemas siempre que, la investigacin para les de servicio;
esclarecer los problemas no resueltos, no
b) revisiones de la direccin para
habituales o de gran repercusin, las justi-
resaltar los problemas que requie-
fique. La finalidad de estas revisiones es
ren una accin inmediata;
encontrar mejoras para el proceso y evitar
la repeticin de incidentes o errores. c) revisiones de la direccin para
determinar y analizar tendencias y
Las revisiones de problemas son nor-
para proporcionar informacin a
malmente:
otros procesos como, por ejem-
a) revisiones de los niveles de inci- plo, el de educacin y formacin
dentes individuales y del estado del cliente.
En ISO/IEC 20000-2 se detallan los temas que se deben tratar en las revisiones de
los problemas importantes.
UNE-ISO/IEC 20000-2
Las revisiones deberan incluir informa- f) el compromiso del personal para

cin de: resolver los incidentes y los pro-
a) tendencias, por ejemplo, proble- blemas;
mas e incidentes recurrentes, erro- g) repeticin de incidentes o proble-
res conocidos, etc.; mas ya resueltos.
b) problemas recurrentes de una Las mejoras del servicio o del proceso
determinada clasificacin de de gestin de problemas se deberan
componente o de ubicacin; registrar e incluir en un plan de mejora
c) deficiencias causadas por la sub- del servicio.
contratacin, la formacin o la La informacin se debera aadir a la
documentacin; base de conocimientos de gestin de
d) no conformidades, por ejemplo, problemas.
conforme a normas, polticas y Toda la documentacin relevante se
leyes; debera actualizar, por ejemplo, las
e) errores conocidos en las entregas guas del usuario y la documentacin
planificadas; del sistema.
Todas las acciones de mejora identificadas a lo largo del proceso de gestin del pro-
blema, tanto tcnicas (causas raz detectadas) como organizacionales, constituye
informacin importante para aportar al plan de mejora del servicio (SIP, vase el
apartado 6.1) o al plan de mejora unificado de los procesos y de los servicios (vase
el captulo 4).
Prevencin proactiva de problemas

La gestin del problema tiene un componente denominado reactivo muy impor-
tante, tratado anteriormente. Pero no hay que olvidar su otra faceta proactiva, que
quiz es la que ms contribuya a la evitar incidentes graves. Las actividades proacti-
vas se centran en identificar defectos o problemas subyacentes antes de que provo-
que incidentes.
UNE-ISO/IEC 20000-1
Se deben llevar a cabo acciones preventivas para reducir los problemas potenciales,
por ejemplo las derivadas de anlisis de tendencias de volmenes y tipos de incidentes.
En ISO/IEC 20000-2 se establece un alcance bastante amplio para la gestin pro-

activa, que comprende desde la prevencin de problemas individuales, pasando por
la toma de decisiones estratgicas de cambio, hasta las acciones de formacin a los
usuarios y clientes sobre el uso de los servicios.
UNE-ISO/IEC 20000-2
La gestin proactiva de problemas dentes individuales, tales como las difi-

debera conducir a una reduccin de los cultades reiteradas para utilizar una
incidentes y de los problemas. Debera determinada funcin de un sistema,
incluir referencias a la informacin que hasta las decisiones estratgicas. Es
resulte de ayuda para el anlisis como, probable que estas ltimas requieran
por ejemplo: un gasto de implementacin considera-
ble, por ejemplo, la inversin en una
a) activos y configuracin;
red mejor; a este nivel, la gestin del
b) gestin del cambio; problema proactiva se funde con la
c) un error conocido y divulgado, gestin de la disponibilidad.
informacin sobre las soluciones La prevencin de problemas tambin
provisionales de los proveedores; incluye el suministro de informacin a
d) informacin histrica sobre pro- los clientes para evitar que tengan que
blemas similares. pedir ayuda en el futuro, por ejemplo,
para prevenir incidentes causados por
La prevencin de problemas debera la falta de conocimiento o la falta de
abarcar desde la prevencin de inci- formacin del usuario.
En ITIL se establece que las actividades principales de los procesos de gestin pro-
activa de problemas son el anlisis de tendencias y la identificacin de acciones pre-
ventivas.
Anlisis de tendencias. El objetivo es identificar componentes frgiles en la
infraestructura de TI e investigar las razones de esta fragilidad. As, los informes
sobre el anlisis de incidentes y problemas proporcionan informacin sobre medi-
das proactivas. El anlisis de tendencias puede llevar a la identificacin de defectos
en la infraestructura de TI y tambin puede llevar a identificar reas que necesita-
rn ms atencin del rea de soporte.
Identificacin de acciones preventivas. Como consecuencia de la actividad ante-
rior se identifican acciones preventivas que de deben implementar e integrar en el
plan de mejora del servicio (SIP) o en el plan de mejora unificado de los procesos y
de los servicios. Debera ser posible establecer comparaciones significativas expre-
sndolas en trminos de costes financieros para la organizacin.

Aunque resulte paradjico, el propio proceso de gestin del problema encargado
de identificar defectos en los servicios, tambin debe realizar una labor de auto-
mejora de su propia actividad, identificando la utilizacin excesiva de recursos,
demoras, problemas con la asignacin de personal tcnico, etc.
Todas las acciones de mejora del propio proceso identificadas no se implementan
sin una coordinacin global, por ello, deben integrarse en el plan de mejora unifi-
cado de los procesos y de los servicios (vase el captulo 4).
Mtricas del proceso

Las mtricas del proceso deberan facilitar una visin del rendimiento del proceso:
los recursos y esfuerzo utilizados en la investigacin, diagnstico y resolucin de
los problemas y errores conocidos. Adems, es importante que se proporcione una
visin del estado de los trabajos y de los resultaos obtenidos. Tambin son impor-
tantes los indicadores de resultados sobre la mejora de la calidad de los servicios.
Algunas mtricas relevantes del proceso pueden ser las siguientes:
Nmero medio de incidentes resueltos por los errores conocidos.
Nmero de problemas abiertos y cerrados en el perodo.
Nmero total de errores conocidos existentes en la base de datos de pro-
blemas.
Nmero de RFC generadas proactivamente desde gestin de problemas.
Promedio del coste en resolver un problema.
Tiempo medio en resolver un problema.
Tiempo medio empleado en diagnosticar problemas.
Porcentaje de problemas no diagnosticados.
Nmero medio de personal tcnico que interviene en un problema.
Nmero de soluciones provisionales actualmente activas (workarounds).
Mejora de la disponibilidad de los servicios generada por la resolucin de
problemas.
Productividad inducida en el negocio por una mayor estabilidad de los servi-
cios. Est mtrica puede ser bastante subjetiva.
Los resultados esperados por una buena gestin del problema se pueden apreciar a
travs de:
La reduccin de la cantidad de incidentes, al eliminar la causa raz que los
provoca y, por tanto, evitar su recurrencia.
La reduccin de tiempo para la reparacin de un incidente (MTTR), debido
a la base de conocimiento que se va generando, junto con un incremento de
la tasa de resolucin de incidentes en primer nivel.
La reduccin de los tiempos necesarios para la resolucin de los problemas.
La disminucin de los costes asociados a la resolucin.
En el grfico de la figura 8.3.9 se muestra el resumen de los indicadores ms relevan-

tes para este proceso seleccionados por un grupo de trabajo de itSMF Espaa. En l
se aprecia que la gestin del problema es un proceso interno de TI, con poca visibili-
dad directa por parte del negocio. Por ello, no tiene presente ningn KGI de TI.
de itSMF Espaa

Si bien, en el mbito del proceso, las fronteras entre incidentes y problemas estn
claramente delimitadas, en el mbito de los tcnicos especialistas puede ocurrir que
tengan que intervenir primero para restaurar el servicio y posteriormente para eli-
minar la causa raz, participando as en los dos procesos asumiendo diferentes roles.
Esta situacin puede implicar un conflicto de intereses entre la dedicacin a la res-
tauracin del servicio y la dedicacin a la eliminacin de los defectos. Se debe dife-
renciar claramente entre la actuacin del personal tcnico bajo la resolucin de pro-
blemas y en caso de incidentes.
Los participantes en este proceso deben tener una cualificacin tcnica muy alta,
involucrando a los especialistas, internos o externos, que se necesiten.
Como en el resto de los procesos, los roles que intervienen en el proceso se estruc-
turan en los roles propios del proceso y los roles ajenos al proceso (el gestor del
nivel de servicio).
Los roles propios del proceso son los siguientes:
El gestor de problemas (gestor del proceso o process manager). Es el respon-
sable de la operacin diaria del proceso de gestin de problemas, velando
por la implicacin de los equipos ante la definicin de un problema, asegu-
rando que se cumplen los SLA, y coordinando los escalados entre grupos en
caso de necesidad.
Lder de equipo de gestin del problema. Es el responsable de liderar de
forma eficaz y eficiente al equipo de trabajo encargado de la resolucin
de un problema
Analista tcnico de problemas. Es el rol encargado de llevar a cabo la investi-
gacin, diagnstico y resolucin de problemas. En este rol participan los tc-
nicos especialistas de todo tipo, de desarrollo, tcnico de sistemas, del hard-
ware, etc., que participan en las actividades de investigacin y diagnstico
del problema y en la resolucin de errores.
El responsable del centro de servicio al usuario, por la estrecha relacin entre
el soporte en la primera lnea de incidentes y la gestin del problema.
El responsable de desarrollo y el responsable de infraestructuras o de tecno-
loga, pues deben proveer tcnicos especialistas en las disciplinas que se nece-
siten para identificar y resolver los problemas.
Los roles de mayor relevancia que participan en el proceso de gestin del problema
se representan en el grfico de la figura 8.3.10.
Roles del proceso
Responsable de la
gestin del servicio
SGSTI
Administrador y
Gestor de soporte del proceso
problemas
Propietario del
modelo (SGSTI)
Lder de equipo Analista tcnico

de gestin del problema de problemas
Gestor del
service desk
Figura 8.3.10. Roles principales del proceso de gestin del problema.
Resumen
La misin del proceso de gestin del problema es evitar que se produzcan inciden-
tes repetitivos o nuevos. Este proceso es uno de los ms eficaces y que mejores
resultados proporciona, pues va buscando y subsanando defectos en los servicios
para hacerlos ms estables.
Es un proceso de fcil implementacin ya que no requiere grandes herramientas, ni

la involucracin de todo el personal. Con dos expertos el proceso empieza a dar sus
resultados. La gestin del problema se divide principalmente en dos grandes blo-
ques: la gestin reactiva (que comprende el control de problemas y el control de
errores) y la gestin proactiva (que busca problemas latentes).
Para conseguir obtener toda la eficiencia del proceso, en sus aspectos reactivos y
proactivos, se debe disponer de un proceso de gestin del incidente suficientemente
maduro que registre informacin suficiente para realizar los anlisis forenses. El
principal resultado de este proceso es la estabilidad de los servicios, con la visibili-
dad ante el negocio que esto tiene.
La reduccin de los incidentes produce un efecto positivo en el estrs y carga de
trabajo de los equipos de soporte.
Adems, este proceso es un generador de conocimiento en forma de errores cono-
cidos (que contienen la descripcin del problema, la causa raz y su solucin).
La gestin del problema no se limita a una mera enumeracin de los errores, sino
que trabaja en todo el ciclo de vida de la solucin, y a lo largo de todo el ciclo de
vida del servicio
Beneficios
Entre las ventajas de adoptar un enfoque formal de gestin del problema se inclu-
yen las siguientes:
Mejora de la calidad de los servicios de TI. La gestin del problema ayuda a
generar un ciclo en el que la calidad de los servicios de TI se incrementa rpi-
damente.
Reduccin del volumen de incidentes. La gestin del problema contribuye a
reducir el nmero de incidentes que interrumpen el curso normal del negocio.
Aporte de soluciones permanentes. Se produce una reduccin gradual del
nmero e impacto de problemas y errores, ya que las soluciones son perma-
nentes y no parches provisionales.
Incremento del conocimiento de la organizacin. El proceso de gestin del
problema genera la base de errores conocidos que permite reutilizar las expe-
riencias previas.
Mejora del ratio de resoluciones en la primera lnea de soporte. El conoci-
miento generado sobre la resolucin de errores permite resolver mayor
nmero de incidentes en la primera lnea.
Describa un problema relevante que haya ocurrido en su organizacin, y
sobre l:
Realice un esquema Ishikawa (raspa de pez) con los errores ms fre-
cuentes para un servicio crtico, agrupados segn esta metodologa de
anlisis de causa-raz.
En el caso, describa qu se hizo mal, qu se hizo bien y que cambia-
ra en su organizacin.
9 Captulo 9
Procesos
de control
CMDB 9.1. Gestin de la configuracin
9.2. Gestin del cambio


9. Procesos de control 621
Tener todo bajo control es el primer deseo de los responsables de TI. Los siste-
mas de informacin, cada vez ms importantes para la empresa, deben evolucio-
nar de una forma controlada. La industria ha consensuado dos procesos cuyo
nfasis se centra en este deseado control de TI y de sus servicios: el proceso de la
gestin de la configuracin y el proceso de la gestin del cambio. El primero con-
trola la informacin sobre los elementos considerados clave para la gestin de los
servicios de TI, y el segundo, que no se cambie nada sin seguir las reglas preesta-
blecidas.
Se puede considerar que la gestin de la configuracin supone para TI lo que la
imprenta para la Humanidad: una forma industrializada de tratamiento con rigor
del conocimiento comn. Efectivamente, los servicios de TI cada vez ms crti-
cos no se pueden gestionar mediante acciones voluntaristas de algunos profesio-
nales de TI, la informacin y el conocimiento de TI debe ser tratado con rigor
bajo una estricta poltica definida en la empresa. Slo de esta forma se podr
garantizar que las decisiones se toman con la informacin precisa y fidedigna.
Al avanzar en el presente captulo se apreciar cmo el proceso de gestin de la
configuracin articula las polticas y mecanismos que hacen posible que la informa-
cin que se necesite para la gestin de TI est disponible y con la calidad y fiabili-
dad deseadas.
Por otra parte, el mayor porcentaje de incidentes y fallos en los servicios de TI pro-
vienen de errores o defectos introducidos al cambiar. Pero los cambios son necesa-
rios para mantener los servicios alineados con la evolucin del negocio y de la tec-
nologa.
El proceso de la gestin del cambio introduce una serie de mejores prcticas que
ayudan a que la necesaria actividad de realizar modificaciones se realice de la forma
ms segura y controlada posible.
Las prcticas ms importantes que se aprendern es este captulo son las siguientes:
Cmo disear y gestionar la base de datos de la gestin de la configuracin.
Cmo articular la informacin comn para que sea til.
Los dos roles para garantizar el control: el gestor de la configuracin y el
gestor del cambio.
Cmo pone orden un simple formulario, la peticin de cambio.
A definir y articular el comit de control de cambios, que posibilita la
coordinacin de todos los recursos humanos que estn involucrados en un
cambio.
La necesidad de disponer de una la lista con la planificacin y control de

todos los cambios previstos.
La importancia de revisar y confirmar la idoneidad de un cambio despus de
su implantacin.
CMDB
9.1. Gestin de la configuracin 623
9.1. Gestin de la configuracin
Figura 9.1.1. Actividades principales del proceso de gestin de la configuracin
Una organizacin sin informacin est completamente ciega y es totalmente

dependiente del conocimiento traspasado verbalmente entre las personas que for-
man TI. Las decisiones se toman nicamente con la informacin que los profesio-
nales de TI retienen en su cabeza.
Segn va creciendo la organizacin o va rotando el personal, ese conocimiento y
dominio que los primeros tenan se va haciendo cada vez ms difcil de mantener
y empiezan a aparecer los apaos, listas o anotaciones que unos y otros hacen por
doquier. Hasta que llega un momento en el que ya no es posible la gestin bajo esta
forma artesanal y rudimentaria de manejar la informacin y se hace necesario que
el conocimiento se almacene y retenga con rigor.
En una organizacin sin gestin de la configuracin es frecuente encontrarse situa-
ciones como:
Me puedes decir qu infraestructura soporta el servicio de venta online? y cules
son los niveles de servicio que debemos cumplir?
Espera, te lo digo maana, pues tengo que cruzar varias listas y preguntar a los tc-
nicos de servidores, de red, de aplicaciones, etc.
Sabes qu tcnico est de guardia este fin de semana?

No s, cada semana cambia, llama a Pedro y l te dir a quines les toca el prximo.
Tengo en lnea a un cliente de TI y me pide que le actualicemos el listado de las
empresas de fabricacin de componentes metlicos de aluminio en la regin para un
mailing; esto es un poco raro qu le digo?
Yo creo que esta actividad no la hacemos nosotros, es el propio departamento de mar-
keting el que lo hace, llmales y psales el marrn.
Voy a instalar un parche del sistema operativo en 5 servidores, crees que afectar a
alguna aplicacin?
Desde la consolidacin y virtualizacin no hay quien se aclare, para estar seguros
convoca una reunin con todos los tcnicos de sistemas para que cada uno diga si le
impacta o no.
Como se aprecia en la ltima situacin, las organizaciones estn consolidando sus

infraestructuras y virtualizando las instancias de los sistemas operativos, el almace-
namiento, etc. En este escenario, la infraestructura se comparte, y la facilidad de
asignacin de recursos hace ms difcil conocer de memoria a qu est dedicado
cada equipo, pues la misma infraestructura fsica soporta muchos servicios (vase la
figura 9.1.1).
La gestin de la configuracin es el proceso que se ocupa de controlar y proveer
la informacin comn sobre TI y sus servicios que necesitan todos los procesos o
reas de TI. Este proceso vuelca en un repositorio la informacin importante a
compartir por cualquier rea de TI. Se centra principalmente en informacin
esencial o que necesita ser compartida entre las diversas reas. Este repositorio es
una base de datos lgica que puede estar formada por mltiples bases de datos
y formas de almacenamiento, y repartida en mltiples emplazamientos. En la
figura 9.1.2 se presenta un esquema introductorio al proceso.
Es un proceso interno a TI, no visible directamente para los usuarios y clientes.
Est centrado en facilitar informacin precisa y fiable al resto de la organizacin de
TI. Por tanto, su labor es la de bibliotecario o clasificador, similar a otras discipli-
nas como la gestin de inventarios y la gestin de activos, pero con un foco claro
en la gestin de la informacin de configuracin que se ha definido como necesaria
para ser compartida.
El que sea un proceso interno de TI no le merma importancia. De hecho es uno de
los procesos esenciales, que facilitando informacin precisa, hace posible el xito
de la actividad de TI.
CMDB

configuracin Informacin precisa y actualizada
sobre los componentes de TI.
Definicin: Visin de todos los elementos que

componen un servicio y las relaciones
Proceso responsable de gestionar entre ellos.
y mantener actualizada toda la
Fiabilidad en las actuaciones al
informacin comn que necesitan
disponer de informacin precisa.
las reas de TI.
Eficiencia en el trabajo al tener
accesible la informacin comn que se
Objetivo: necesita.
Denir y controlar los componentes Compartir la informacin comn entre
del servicio y de la infraestructura, todos los procesos.
y mantener informacin precisa
Control de todos los elementos
sobre la conguracin.
software instalados.
Figura 9.1.2. Introduccin al proceso de gestin de la configuracin
El proceso, primero define qu tipo de informacin es esencial compartir (alcance

y profundidad), establece las polticas para su gestin, disea el soporte inform-
tico para la misma, identifica los elementos que se van a cargar, para pasar a con-
trolar sus actualizaciones posteriores. Adems, realiza verificaciones y auditoras
para garantizar la fidelidad de la informacin compartida.
Por tanto, la gestin de la configuracin garantiza que est correctamente regis-
trada la informacin necesaria para la gestin de los servicios. La misin del pro-
ceso de gestin de la configuracin es proporcionar informacin veraz de los com-
ponentes de TI y sus relaciones al resto de los procesos.
Los principales aportes que realiza la gestin de la configuracin al proveedor de
TI pueden resumirse en:
Llevar el control de todos los elementos de configuracin de la infraestruc-
tura de TI con el adecuado nivel de detalle y gestionar dicha informacin a
travs de la base de datos de configuracin (CMDB).
Proporcionar informacin precisa sobre la configuracin de TI a todos los
diferentes procesos de gestin.
Interactuar con la gestin del incidente, del problema, del cambio y de la
entrega de manera que stas puedan resolver ms eficientemente las incidencias,
encontrar rpidamente la causa de los problemas, realizar los cambios

necesarios para su resolucin y mantener actualizada en todo momento la
CMDB.
Monitorizar peridicamente la configuracin de los sistemas en el entorno
de produccin y contrastarla con la almacenada en la CMDB para subsanar
discrepancias.
Este proceso tambin gestiona el repositorio que almacena las diversas entre-
gas de software, denominado biblioteca de software definitivo (DSL, Defini-
tive Software Library). En ITIL v2 es diferente, ya que esta responsabilidad
recae sobre el proceso de gestin de la entrega.
Los tres pilares en los que se sustenta este proceso se resumen en el esquema de la
figura 9.1.3.
Figura 9.1.3. Bases de la gestin de la configuracin
La gestin de la configuracin se articula en torno a dos conceptos principales: los

elementos de configuracin, denominacin dada a todo componente de TI cuya
informacin es necesaria para la gestin de los servicios de TI; y la base de datos de
la configuracin, repositorio informtico en el que se almacenan los elementos de
configuracin. En el esquema de la figura 9.1.4 se presentan la CMDB junto a los
componentes ms destacados de este proceso.
CMDB
Servicios
Documentacin
SLAs
CI CI CI CI
Gestor de la CI CI
configuracin CI CMDB
CI HW
CI CI CI CI CI
SW
Base de datos de gestin
de la configuracin Elementos de configuracin
(CMDB) (CI)
El resto de los procesos

utilizan la informacin Lnea base
5. Planificacin e implementacin de nuevos servicios o de servicios modificados (baseline)
DSL 6. Procesos de la provisin del servicio
Biblioteca de continuidad y
disponibilidad
6.2 Generacin de
informes del servicio
6.4 Elaboracin de
presupuesto y contabilidad
software definitivo
Figura 9.1.4. La gestin de la configuracin y la CMDB son considerados

el ncleo de la gestin de los servicios de TI
Los componentes principales que se emplean en el proceso de gestin de la confi-

guracin son los siguientes:
Base de datos de la gestin de la configuracin (CMDB, Configuration Mana-
gement Data Base). Es el repositorio que alberga los registros sobre los elementos
de configuracin que se hayan decidido incluir. Contiene los detalles relevantes de
cada elemento de configuracin o CI (atributos e historial), as como detalles
de las relaciones importantes entre ellos.
Esta base de datos debe incluir nicamente la informacin comn a los procesos
que se haya planificado compartir. No hay que confundirla con la informacin o
base de datos que cada proceso y cada rea de TI deben disponer y controlar, que
retendrn la informacin que se necesite para cada actividad. De esta forma, la
gestin del incidente dispondr de una base de datos de los incidentes ocurridos
con las indicaciones para resolverlos, de igual manera que ocurre con el resto de
los procesos. De toda esta informacin gestionada por los procesos y reas, slo se
alojar en la CMDB la que se haya decidido que compartirla aporta valor. No obs-
tante, es necesaria una buena integracin entre las herramientas, de tal forma que
desde la CMDB se pueda consultar los registros asociados a un CI que existan en las
herramientas de soporte especfico de otros procesos (incidente, capacidad, etc.).
La CMDB est formada por:
Fichas con la informacin detallada de cada elemento de configuracin, pero
no suele albergar el elemento de configuracin en s mismo. Slo en los
casos en que los elementos de configuracin son documentos electrnicos
(SLA, contratos, etc.), se podrn incluir el CI de forma completa en la CMDB.
Los archivos fuentes y los ejecutables de los programas no se suelen incluir
en la CMDB.
Relaciones entre los diferentes elementos de configuracin.
Biblioteca de software definitivo (DSL, Definive Software Library). Es un repo-

sitorio, archivo fsico o electrnico, que aloja todos los archivos fuentes y ejecuta-
bles de los productos y programas que utilizan los servicios. La DSL contiene los
archivos completos correspondientes a todo CI de software, con un histrico de sus
versiones. Toda versin del CI recogida en la CMDB debe tener sus ficheros origi-
nales en la DSL, para poder reinstalar el CI software cuando sea necesario.
Hay que destacar que en ITIL v2 la gestin de la DSL se encarga al proceso de
gestin de la entrega. En ISO/IEC 20000, el control de la DSL lo ejercita el pro-
ceso de gestin de la configuracin; situacin que parece ms razonable y acorde
con las funciones requeridas de bibliotecario. En ITIL v3, la DSL se denomina
DML (biblioteca de medios definitivos) y est gestionada por el proceso de ges-
tin de la configuracin y activos del servicio.
En cualquier caso, la actualizacin de la DSL con las ltimas versiones del software
instalado parece razonable que lo realice la gestin de la entrega, con la supervisin
de la gestin de la configuracin.
Por tanto, la CMDB contiene las fichas que identifican y catalogan los elementos
software, mientras que la DSL contiene los archivos que contienen el software y sus
versiones.
Luego, tanto en la planificacin de la gestin de la configuracin como en sus activi-
dades posteriores habr que considerar el diseo, implementacin y control de la DSL.
Elemento de configuracin (CI, Configuration Item). Un CI es todo compo-
nente fsico o lgico de tecnologa de la informacin necesario para la prestacin
del servicio. Como ejemplo se citan los siguientes:
CMDB
Dispositivos hardware, como por ejemplo, servidores, almacenamiento

externo, PC, impresoras, equipos de comunicaciones, etc.
Software: sistemas operativos, productos software, todo tipo de aplicaciones,
scripts, parametrizaciones de productos, etc.
Documentacin: manuales, acuerdos de niveles de servicio, contratos de
soporte, etc.
Personas que intervienen en la prestacin del servicio.
Localizaciones, edificios, oficinas, etc.
Servicios que presta TI.
Entidades lgicas, como particiones, clusters, instancias, etc.
Indicadores, mtricas, informes, etc.
En resumen, CI es todo componente que ha de ser gestionado por la organizacin

de TI y cuya ficha vaya a estar bajo el control de la gestin de la configuracin y
que, por tanto, estar sujeto a un control de cambios formal.
Hay que determinar cul es el nivel ms detallado de informacin que interese con-
trolar en el proceso. Por ejemplo, se tratar como elemento de configuracin un
PC, pero no compensa tratar como elementos independientes el ratn, la memoria,
o el disco interno, que en todo caso sern caractersticas del PC.
Los elementos de configuracin pueden ser muy diferentes en complejidad,
tamao y tipo, desde un sistema o servicio completo (incluyendo todo el hardware,
software y documentacin, etc.), hasta un nico mdulo o un simple componente
hardware. Cada organizacin deber determinar el alcance y profundidad de la
ficha de informacin sobre cada tipo de elemento.
Un CI debe tener asociados o referenciados los incidentes, problemas, cambios,
etc., en los que est o ha estado involucrado.
Lnea base de configuracin (baseline). Es la configuracin (versiones) de los ele-
mentos de configuracin que forman un servicio o sistema en un momento deter-
minado del tiempo. Es una foto tomada en un instante determinado sobre el
estado y versiones de todos los CI que componen un servicio. Recoge tanto la
estructura como todos los detalles necesarios para que el servicio o sistema pueda
reimplantarse o restaurarse posteriormente, en caso de necesidad.
Por ello, una lnea base se utiliza como medida de seguridad antes de realizar un
cambio importante y facilita informacin para regresar a la situacin inicial. Tam-
bin puede ser establecida para el paso a produccin de nuevos CI y para facilitar
informacin en una situacin de recuperacin ante desastres.
La lnea base recoge informacin de la CMDB sobre el estado en un instante deter-

minado de la configuracin de un CI o de un conjunto de CI, es decir, las fichas de
los CI. Como la lnea base contiene slo la informacin del estado de los CI, para
la recuperacin completa se necesitarn tambin las copias de seguridad realizadas,
los archivos fuentes y ejecutables, la parametrizacin realizada, etc. (contenidas en
la DSL).
Relaciones entre los elementos de configuracin. Un CI no est aislado. Nece-
sita e interacta con otros elementos para componer el servicio final que presta TI.
Por ello, es importante definir, cargar y controlar en la CMDB las relaciones entre
los elementos de configuracin. Las relaciones aportan un valor excepcional a la
informacin sobre la configuracin.
Las relaciones entre dos CI pueden ser de diversos tipos. A continuacin se mues-
tran ejemplos de ellas:
Usa. Un CI del tipo empleado utiliza al otro CI del tipo PC.
Parte de (hijo). Un componente de red es parte de una red.
Formado por (padre). Una red est formada por componentes de comuni-
caciones.
Conectado a. Un CI de almacenamiento est conectado a un CI servidor.
Instalado en. Un CI software est instalado en un CI servidor.
Localizado en. Un CI est ubicado en otro CI del tipo localizacin.
Las relaciones nos permiten obtener todos los CI que participan en un servicio
determinado.
Con las relaciones se construyen estructuras de configuracin o esquemas de rela-
cin, que tienen por eje central el CI que interese conocer en un momento deter-
minado. Forman, por tanto, el rbol en el que se estructuran las categoras de los
elementos de configuracin. As, los esquemas de relacin ms habituales son
los siguientes:
Esquema de relacin de un servicio, que muestra todos los componentes que
participan en ese servicio.
Esquema de relacin de un servidor, para conocer todo lo instalado en l y
en que servicios est soportando.
Esquema de relacin de red, muestra los componentes de una red.
CMDB

Las entradas del proceso proporcionan la informacin necesaria para actualizar la
CMDB, que proviene de los resultados de las herramientas de autodescubrimiento
de infraestructura (muy habituales para los PC y los elementos de red), de cargas de
datos realizadas por lotes (provenientes de actualizaciones o de un esfuerzo manual
para ampliar el alcance o la profundidad de la CMDB), o de otros procesos (princi-
palmente de gestin del cambio, gestin de la entrega y gestin de nivel de servicio).
Las Normas ISO/IEC 20000 siguen una definicin de actividades para este pro-
ceso muy similar a la establecida en ITIL v2, pero por desgracia, ambas denomina-
ciones resultan poco afortunadas y algo confusas, pues bajo la actividad denomi-
nada identificacin se centra principalmente en la localizacin y etiquetado de CI.
Bajo la actividad denominada control se realiza la carga y actualizacin de informa-
cin (CMDB y DSL), y en el seguimiento del estado se informa respondiendo a
las consultas del resto de la organizacin.
Las funcionalidades que debe desarrollar la gestin de la configuracin se resumen
sucintamente en la figura 9.1.5.
Desencadenantes 3 Planificacin e implementacin de Salida principal:

del proceso: la gestin de la configuracin. Plan de gestin de la
Detalles para 3 Identificacin de configuracin configuracin.
actualizar la CMDB. (estructurar). CMDB creada, cargada
Resultados 3 Control de configuracin y actualizada.
herramientas (registrar y actualizar). DSL creada, cargada y
autodescubrimiento. 3 Seguimiento del estado de actualizada.
Cargas de datos. la configuracin e informes Informacin de detalles
Cambios. (informar). del estado de la
3 Verificacin y auditora configuracin (CI).
Ficheros para actualizar
de la configuracin.
la DSL. Salidas secundarias:
3 Supervisin y mejora del
Fuentes y ejecutables Inconsistencias.
proceso.
de programa. Informacin del proceso.
Software del Plan de mejora del
fabricante. Tanto de la CMDB como de la DSL. proceso.

Para cumplir su finalidad, la gestin de la configuracin articula su trabajo en torno

a las siguientes actividades:
Planificacin e implementacin del proceso de gestin de la configuracin,
incluyendo el diseo e implementacin de la CMDB y de la DSL en sus res-
pectivas herramientas.
Identificacin de la configuracin (estructurar), que permite establecer la
estructura de configuracin (alcance y detalle de la informacin sujeta a ges-
tin de la configuracin y recogida en la CMDB) y polticas de nomencla-
tura para la numeracin, clasificacin y etiquetado de los elementos de con-
figuracin (CI).
Control de la configuracin (registrar y actualizar), para que los cambios en
los elementos de configuracin se actualicen en la CMDB y DSL segn los
mecanismos definidos. Esta actividad realiza la carga las fichas de los CI en la
CMDB; controla la carga del software (archivos) en la DSL, que realiza gestin
de la entrega a la aceptacin de cada entrega; y asegura que slo se registran
elementos autorizados e identificables, desde su recepcin hasta su retirada. Se
debe asegurar que no se aada, modifique, reemplace o elimine ningn CI sin
la documentacin de control adecuada. stas actuaciones slo se realizarn por
el personal autorizado a travs de una correcta asignacin de roles.
Seguimiento del estado de la configuracin e informes (informar). Propor-
cionar informacin exacta sobre las la configuracin y su documentacin
para apoyar a todos los dems procesos de gestin del servicio. As, se facili-
tan datos consistentes para la gestin del incidente, gestin del problema,
gestin del cambio y gestin de la entrega.
Verificacin y auditora de la configuracin. Comprueba los registros de con-
figuracin, contrastndolos con la infraestructura real, y corrige cualquier
excepcin. Realiza la auditora formal de la informacin contenida.
Supervisin y mejora del proceso, aportando entradas al plan de mejora
general de la gestin del servicio.
En la figura 9.1.6 se presenta un esquema de estas actividades que forman la ges-

tin de la configuracin.
Las principales salidas del proceso son las siguientes.
Plan de gestin de la configuracin. Documento resultante de la planifica-
cin de la implantacin de la configuracin.
CMDB creada, cargada y actualizada. La base de datos de gestin de la con-
figuracin se crea y se carga con la configuracin inicial, de acuerdo al
CMDB
Identificacin de
la configuracin Control de configuracin
(estructura, alcance y detalle)
(registrar y actualizar)
Modificaciones
a los CI
Planificacin e implementacin
de la gestin de la
configuracin Otros procesos

CI CI CI CI disponibilidad
del servicio
informes del servicio
presupuesto y contabilidad
CI CI de entrega
8. Procesos
de relaciones
CMDB
10.1 Proceso de gestin 7.2 Gestin de las
CI CI
Verificacin y CI CI CI CI CI
auditora de la
configuracin
DSL
PDCA Supervisin y Seguimiento del estado de
SGSTI mejora del proceso la configuracin e informes
(informar)
Fuente: HP y e.p.
Figura 9.1.6. Actividades principales de gestin de la configuracin
alcance y nivel de detalle establecidos. Se actualiza con los cambios produci-

dos sobre los elementos de configuracin.
DSL creada, cargada (inicial) y actualizada (a travs de gestin de la
entrega).
Informacin detalles del estado de la configuracin. Informacin sobre
el estado y detalles de la configuracin almacenados en la CMDB y DSL
que es requerida por otros procesos o reas de la organizacin de TI para el
desarrollo de su actividad.

La planificacin e implementacin de este proceso se debe realizar de la misma forma
que el resto de procesos, bajo el amparo y liderazgo del proceso de planificacin e
implementacin de la gestin del servicio (vase el captulo 4). El equipo de imple-

mentacin de la gestin del servicio tambin asumir la implementacin de este pro-
ceso, teniendo en cuenta lo que dictan estas normas y las caractersticas propias de la
organizacin de TI.
En el apartado 9.1 de estas normas se establecen los requerimientos y recomenda-
ciones que se deben cumplir en la planificacin e implementacin de la gestin de
la configuracin. As, se establece que la planificacin del proceso debe definir el
propsito, objetivos, alcance, estrategia, polticas y procedimientos, as como,
la organizacin e infraestructura tecnolgica necesaria para la implantacin del
proceso.
La implantacin de este proceso es ardua y muchas veces desemboca en el fracaso,
principalmente porque se suele ser muy ambicioso en los objetivos iniciales de
informacin a albergar en la CMDB y despus de un tremendo esfuerzo en la carga
inicial, no es fcil mantener los datos actualizados. Por ello, se suele recomendar
que se inicie con unos objetivos muy acotados; empezar poco a poco, con una
estructura liviana de CMDB para ir creciendo segn vaya madurando la implanta-
cin de la monitorizacin y el descubrimiento automtico de la infraestructura, que
permitir actualizar automticamente los cambios en los elementos de configura-
cin (CI).
ISO/IEC 20000-1 pone ms nfasis en el control de los activos, requiriendo un
vnculo claro con la contabilidad financiera, el control de los activos de software (en la
DSL) y sentando las bases de la CMDB.
UNE-ISO/IEC 20000-1
Debe existir una visin integrada para la planificacin de la gestin del cambio y de
la configuracin.
El proveedor del servicio debe definir la interfaz con los procesos de contabilidad
financiera de activos.
Nota: La contabilidad financiera de los activos queda fuera del mbito de esta seccin.
Debe existir una poltica que defina qu se considera como elemento de configura-
cin y qu componentes lo constituyen.
Deben estar controladas, en una biblioteca fsica o electrnica segura, las copias
maestras de los elementos de configuracin digitales, con referencias a los registros
de configuracin, por ejemplo software, productos de prueba, documentos de
soporte.
Todos los elementos de configuracin deben ser identificables de manera nica y
registrados en la base de datos de gestin de la configuracin, cuyo acceso para
CMDB
actualizaciones se debe controlar de manera estricta. La base de datos de gestin

de la configuracin se debe gestionar y verificar activamente para asegurar su fiabi-
lidad y precisin. El estado de los elementos de configuracin, sus versiones, ubica-
cin, cambios y problemas relacionados, as como la documentacin asociada
deben estar visibles para quienes lo requieran.
En cambio, ISO/IEC 20000-2 se centra ms en las recomendaciones prcticas para

que el proceso sea efectivo.
UNE-ISO/IEC 20000-2
La gestin de la configuracin se debe- Este gestor responsable debera dispo-

ra planificar e implementar junto con la ner de la informacin necesaria para
gestin del cambio y la gestin de delegar esta responsabilidad, por ejem-
entregas para asegurar que el provee- plo, la persona que autoriza un cambio
dor del servicio pueda gestionar sus podra requerirle informacin del coste,
activos y configuraciones de TI de forma riesgos, impacto del cambio y recursos
efectiva. para la implementacin.
Debera estar disponible una informa- La infraestructura y/o los servicios debe-
cin precisa sobre la configuracin para ran tener un plan(es) actualizado(s) de
dar soporte a la planificacin y al control gestin de la configuracin, que puede
de los cambios a medida que los siste- ser independiente o formar parte de
mas y los servicios nuevos y modificados otros documentos de la planificacin.
son liberados y distribuidos. El resultado stos deberan incluir o describir:
debera ser un sistema eficiente que inte- a) mbito, objetivos, polticas, roles y
gre los procesos de gestin de la infor- responsabilidades normalizados;
macin de configuracin del proveedor
del servicio con los de los clientes y b) los procesos de gestin de la con-
suministradores, cuando proceda. figuracin para definir los elemen-
tos de configuracin de los servi-
Todos los activos y configuraciones prin- cios e infraestructuras, controlar
cipales se deberan tener en cuenta y los cambios en las configuracio-
tener un gestor responsable que ase- nes, registrar e informar del estado
gure que se mantienen la proteccin y de los tems de configuracin y
el control apropiados, por ejemplo: los verificar la integridad y la exactitud
cambios son autorizados antes de la de los elementos de configuracin;
implementacin.
c) los requisitos para la contabili-
Se podra delegar la tarea de imple- dad, el seguimiento y la auditoria,
mentar los controles, pero la responsa- por ejemplo, para propsitos de
bilidad sigue estando en el gestor res- seguridad, legales, regulatorios o
ponsable. de negocio;
d) el control de la configuracin (ac- tener los activos y las configura-

ceso, proteccin, versionado, cons- ciones bajo control y mantener el
truccin, control de entrega); sistema de gestin de la configu-
e) el proceso de control de los ele- racin, por ejemplo, formacin;
mentos de contacto que identifi- g) la gestin de los suministradores y
quen, registren y gestionen los subcontratistas que estn llevando
elementos y la informacin de la a cabo labores de gestin de la
configuracin en los lmites comu- configuracin.
nes a dos o ms organizaciones,
por ejemplo: interfaces de siste- Nota: Se debera implantar un nivel apropiado
mas, versiones; de automatizacin para asegurar que los
procesos no se conviertan en ineficaces,
f) la planificacin y el estableci- o en proclives al error o que no pudieran
miento de los recursos para man- ejecutarse.
Adems de lo indicado en la segunda parte de estas normas, es conveniente consi-

derar los siguientes aspectos:
Designar un responsable: una descentralizacin excesiva puede generar
descoordinacin y llevar al fracaso todo el proceso.
Invertir en una herramienta de software adecuada para la CMDB y DSL.
En grandes organizaciones es esencial y suele ser uno de los primeros pro-
yectos que se inician en la gestin del servicio, ya que una solucin ama-
nuense es impracticable. Aunque en el caso de pequeas instalaciones y,
sobre todo si el volumen de CI que se van a gestionar es pequeo, podra
considerarse el uso de una simple herramienta ofimtica.
Realizar un cuidadoso anlisis de los recursos ya existentes: gestin de
activos, autodescubrimiento, etc.
Establecer claramente un alcance y objetivos modestos inicialmente, defi-
niendo el nivel de detalle adecuado en los CI. Una falta de planificacin, as
como un alcance y grado de detalle demasiado ambicioso en una fase tem-
prana de la implementacin del proceso, conducir con total certeza a una
gestin de la configuracin con informacin desactualizada, con las graves
consecuencias que esto supondr para el resto de los procesos.
Coordinar las actualizaciones estrechamente con la gestin del cambio, la
gestin de la entrega y los departamentos de compras o suministros.
Uno de los aspectos importantes a la hora de garantizar el xito de la actividad de pla-

nificacin es la determinacin de los procedimientos, las estructuras organizativas y el
contexto tcnico para la generacin y mantenimiento de la CMDB. La importancia
es mayor si se tiene en cuenta que muchas veces se piensa que para alimentar una base
CMDB
de datos de configuracin basta con disponer de un formulario de entrada de datos y

disponer de suficientes recursos (horas/hombre) introduciendo los datos para cada
cambio o manipulacin que se realice en la infraestructura de TI. La carga y actuali-
zacin manual es una tarea laboriosa y rudimentaria. Aunque para algunos elementos
no habr otra forma de proceder, se debe intentar disponer de ayudas al poblado de
datos (autodescubrimiento) para que, ante cambios organizativos o tecnolgicos, se
facilite el trabajo al tcnico y se garantice la consistencia y fiabilidad de la informacin
de la CMDB.
La automatizacin utiliza sistemas avanzados de asignacin de activos basados en
reglas de decisin que facilitan la laboriosa tarea de asignacin de propietarios, cla-
sificadores, etc., que son el pan de cada da de la gestin de la configuracin.
El plan de gestin de la configuracin debe contener al menos la informacin indi-
cada en la figura 9.1.7.
Plan de gestin de la configuracin
Propsito.
Objetivo.
Alcance.
Polticas y procedimientos.
Estrategia de implantacin.
Planificacin de actividades:
Diseo de la CMDB.
Diseo de la DSL.
Organizacin.
Herramientas de soporte.
Anlisis de la informacin disponible y sus
fuentes.
Figura 9.1.7. ndice ejemplo del plan de gestin de la configuracin
Las principales dificultades con las que se encuentra la implementacin de la ges-

tin de la configuracin son las siguientes:
Un diseo terico no realista: no involucrar a los equipos adecuados a la
hora de definir los campos y de registrar el contenido de la CMDB, puede
llevar a tener una CMDB intil.
Una incorrecta planificacin: es esencial programar correctamente las activi-

dades necesarias en la identificacin de la configuracin para evitar duplica-
ciones o incorrecciones.
Una estructura muy pesada de la CMDB: mantener actualizada una base de
datos de la configuracin excesivamente detallada y compleja puede ser una
tarea muy engorrosa y que consuma demasiados recursos.
Herramientas inadecuadas: es necesario disponer del software adecuado para
agilizar los procesos de registro y sacar el mximo provecho de la CMDB y
la DSL.
Falta de coordinacin con la gestin de cambios y de la entrega que imposi-
bilita el mantenimiento actualizado de la CMDB y la DSL.
Falta de organizacin: es importante que haya una correcta asignacin de
recursos y responsabilidades. Es preferible que la gestin de la configuracin
se lleve a cabo por personal independiente y especializado.
Falta de compromiso: los beneficios de la gestin de la configuracin no son
inmediatos y son casi siempre indirectos, lo que puede provocar el desinters
de la direccin de la empresa y consecuentemente de los implicados.
Identificacin de la configuracin (estructura, alcance y

detalle)
La identificacin de la configuracin es la actividad dedicada a localizar, identificar
y clasificar los elementos de configuracin existentes, para su carga posterior (por la
actividad de control) en la CMDB y la DSL. As, los CI debern desglosarse e iden-
tificarse unvocamente para permitir el control y registro al nivel que se necesite
por los procesos o unidades usuarias de la CMDB.
UNE-ISO/IEC 20000-1
Se debe definir la informacin que se debe registrar para cada elemento, y se

deben incluir las relaciones y la documentacin necesaria para la gestin efectiva
del servicio.
La gestin de la configuracin debe proporcionar los mecanismos para identificar,
controlar y hacer el seguimiento de las versiones de los componentes identificables
del servicio y de la infraestructura. Se debe asegurar que el grado de control es sufi-
ciente para cubrir las necesidades del negocio, los riesgos de fallo y la criticidad del
servicio.
CMDB
UNE-ISO/IEC 20000-2
Todos los elementos de configuracin g) activos fsicos que sean necesarios

deberan estar identificados de manera para la gestin financiera de acti-
unvoca y estar definidos por atributos vos o bien por motivos de nego-
que describan sus caractersticas funcio- cio, por ejemplo: medios magn-
nales y fsicas. La informacin debera ticos seguros, equipamiento;
ser relevante y auditable. h) documentacin relativa al servi-
En la base de datos de la configuracin cio, por ejemplo: SLAs, procedi-
se deberan utilizar y registrar los marca- mientos;
dos apropiados u otros mtodos de i) instalaciones para el soporte del
identificacin. servicio, por ejemplo: energa elc-
trica para la sala de ordenadores;
Los elementos a ser gestionados se debe-
ran identificar usando los criterios de j) relaciones y dependencias entre
seleccin establecidos y deberan incluir: los elementos de la configuracin.
a) todas las distribuciones y entregas Nota: Otros elementos que podran se considera-
de los sistemas de informacin y del dos como elementos de configuracin son:
software (incluyendo software de a) otra documentacin;
terceras partes) y la documentacin b) otros activos;
relativa de los sistemas, por ejem- c) otras instalaciones, por ejemplo: empla-
plo, las especificaciones de requisi- zamientos;
tos, diseos, informes de prueba, d) unidades de negocio;
documentacin de la entrega; e) personas.
b) las lneas de referencia de la con-
Se deberan identificar las relaciones y
figuracin o las premisas de cons-
dependencias adecuadas entre los ele-
truccin para cada entorno,
mentos de configuracin para propor-
mdulo hardware normalizado y
cionar el nivel de control necesario.
versin;
c) copia fsica maestra y bibliotecas Cuando sea necesario establecer alguna
electrnicas, por ejemplo: la biblio- trazabilidad, el proceso debera asegurar
teca definitiva de software; que se puede seguir el registro de los ele-
mentos de la configuracin en todo su
d) las herramientas o paquetes usa-
ciclo de vida, desde los documentos de
dos para la gestin de la configu-
requisitos hasta los registros de entrega,
racin;
por ejemplo, utilizando una matriz de
e) licencias; trazabilidad.
f) componentes de seguridad, por
ejemplo: cortafuegos;
Como se aprecia entre los apartados del a) al j) de ISO/IEC 20000-2, se recomienda

una serie de tipos de elementos de configuracin (CI) que deberan contemplarse
para cargarlos en la CMDB. Esta relacin, aunque no est muy estructurada, aporta
indicaciones sobre qu categoras de elementos habr que contemplar al disear la

CMDB.
El elemento de configuracin se almacena en la CMDB bajo una ficha o registro
que permite catalogarlo, e incorpora la informacin especfica que se haya decidido
que es til para el proveedor de TI. En la figura 9.1.8 se muestra la parte genrica
de una ficha de un CI.
Elemento de configuracin (CI)
Campos comunes en la ficha de un CI:

ID. Situacin en la que se
Todos los CI encuentra el elemento en
Nombre. el ciclo de vida estipulado.
tienen un ncleo
de informacin Estado. Indica que el CI no debe
comn. ser usado.
Categora.
Nombre de la persona/grupo
Bloqueo. de trabajo responsable de
Descripcin. la administracin del CI.
Informacin puntual o
Propietario (responsable).
importante de recoger
Administrador. relacionada con el CI.
Proveedor. Identificador de elemento

nico.
Marca del producto.
Nombre del entorno
Comentarios. donde se encuentra el CI:
desarrollo, integracin,
nico. produccin
Entorno. N. de veces mximo que
puede existir un elemento
Segn el tipo N. mximo de instalaciones.
no nico. Slo se aplica
de CI (servidor,
a elementos no nicos.
red, servicio, Campos adicionales segn el tipo de CI: (Instancias, licencias, )
persona, etc.)
se necesitar ......
informacin
......
especfica.
......
Fuente: Libros ITIL Soporte de Servicio y Transicin del Servicio publicados por OGC, y Telefnica.
Figura 9.1.8. Ficha ejemplo de un elemento de configuracin

CMDB
Como ejemplo, en la figura 9.1.9 se muestran los campos adicionales de un CI tipo

servidor.
CI tipo servidor
Campos comunes en la ficha de un CI:

... (vase la figura anterior).
Campos adicionales segn el tipo de CI:

Nmero de serie.
Modelo.
Clase de servidor.
N. de procesadores.
Tipo de procesador.
Tipo de memoria.
Tamao de la memoria.
Velocidad del procesador.
Direccin IP.
Hostname.
Capacidad almacenamiento local.
Est en alta disponibilidad.
N. de interfaces de red.
Tipo de interface.
MAC Address .
Fuente: Telefnica.
Figura 9.1.9. Campos adicionales para un CI tipo servidor hardware
En relacin a la nomenclatura identificativa de los CI, se deben predefinir los cdi-

gos de clasificacin para que el sistema sea operativo. Las recomendaciones exis-
tentes convergen en que:
El identificador sea constante, que no vare a lo largo de la vida del elemento
(desde su registro, a su enajenacin).
La identificacin debe ser, por supuesto, nica y, si es posible, interpretable

por los usuarios.
Este cdigo debe ser utilizado en todas las comunicaciones referentes a cada
CI y, si es posible, debe ir fsicamente unido al mismo (mediante una eti-
queta de difcil eliminacin).
La codificacin no slo debe ser utilizada para componentes de hardware,
sino tambin para la documentacin y el software.
Hay muchas alternativas y para gustos no hay nada escrito. Lo ms sencillo es esta-
blecer una clave con un nmero secuencial precedido de un acrnimo de categora
o clasificacin dentro de la CMDB, en el mximo nivel de abstraccin posible. Por
ejemplo HW001001 (correspondiente a la categora hardware). Otros prefieren
incorporar alguna caracterstica del CI a la clave para hacerla ms inteligible, pero
esta caracterstica debera ser constante durante la vida del CI, por ejemplo
HWSER001001 (correspondiente a un servidor en la categora HW).
La base de datos de gestin de la configuracin (CMDB)

La CMDB es una base de datos que almacena informacin relativa a elementos de
la configuracin (CI), tanto de los servicios, como de elementos de infraestructura
de TI y sus relaciones, entre ellos tambin estn los SLA establecidos con el cliente.
Sobre la CMDB hay que contemplar los aspectos siguientes:
Diseo de la CMDB. Documento resultante de la actividad de la planificacin de
la configuracin que contiene el diseo de la CMDB, es decir, el diseo lgico
de la base de datos: alcance y profundidad, estructura general, tablas, relaciones,
atributos de los CI, estados de un CI, etc. Es necesario predeterminar la estructura
de la CMDB de manera que:
Los objetivos sean realistas: una excesiva profundidad o detalle puede sobre-
cargar de trabajo a la organizacin y resultar, a la larga, en una dejacin de
responsabilidades. En general cualquier servicio o proceso es susceptible
de ser incluido en la CMDB, pero unos objetivos en exceso ambiciosos pueden
resultar contraproducentes.
La informacin sea suficiente: debe existir, al menos un registro de todos los
sistemas crticos para la infraestructura de TI.
Alcance. En primer lugar se debe determinar qu sistemas y componentes de TI se

van a incluir en la CMDB:
CMDB
Es esencial incluir, al menos, todos los sistemas de hardware y software impli-

cados en los servicios crticos.
Se debe determinar qu CI deben incluirse, dependiendo del estado de su ciclo
de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
Es recomendable incorporar, al menos, la documentacin asociada a la
estructura organizativa, los proyectos, los SLA, los contratos con suministra-
dores (UC) y las licencias.
Profundidad y nivel de detalle. Una vez determinado el alcance es necesario esta-

blecer la profundidad (tipos de CI que se deben contemplar dentro de una catego-
ra) y el nivel de detalle de la informacin asociada a un tipo de CI, como:
Los atributos que describen a un determinado CI.
Tipo de relaciones lgicas y fsicas registradas entre los diferentes CI.
Subcomponentes que se deban registrar independientemente.
Por ejemplo, en el caso de los ordenadores de sobremesa en la CMDB se podra

seleccionar:
Atributos: fecha de compra, fabricante, procesador, sistema operativo, pro-
pietario, estado, coste, etc.
Relaciones: conexin en red, impresoras conectadas, departamento, etc.
Profundidad: memoria, disco, tarjetas grficas, software instalado, tipo moni-
tor, etc.
En la figura 9.1.10 se muestra un boceto del diseo de una CMDB.

La estructura de la CMDB normalmente contemplar las siguientes categoras :
Hardware. Servidores, almacenamiento, equipos de comunicacin, ordena-
dores personales, impresoras, etc.
Software. Aplicaciones que forman los servicios, productos y paquetes soft-
ware, herramientas de desarrollo, herramientas tcnicas de monitorizacin y
de gestin, software ofimtico, etc.
Documentacin. Organizativa, operaciones, tcnica, etc.
Servicio. Servicios de TI, servicios internos, servicios de terceros, etc.
Activo de informacin. Bases de datos, archivos que contienen datos per-
sonales, manuales de usuarios, material de formacin, procedimientos de
Figura 9.1.10. Diseo ejemplo de una CMDB
trabajo, planes de continuidad, etc. Contratos, documentacin de la organi-

zacin, correos electrnicos, etc.
Contrato. SLA o acuerdos con clientes, OLA o acuerdos internos, UC o
contratos con suministradores.
Persona. Personal de TI, directivos de la empresa, personal subcontratado,
personas de contacto de suministradores, de vigilantes de seguridad, perso-
nal de servicios, personal de limpieza, etc. A efectos del proceso de gestin
de la seguridad de la informacin, puede ser necesario tener una relacin
exhaustiva de personas propias o ajenas que habitualmente tienen acceso a
las instalaciones o sistemas de la empresa.
Localizacin. Edificios, centros de datos, sistemas de climatizacin, siste-
mas de alimentacin elctrica, sistemas de deteccin de incendios, etc.
Entidad lgica. Clusters, instancias de servidores virtualizados, etc.
CMDB
En organizaciones grandes, la CMDB se suele formar como un conjunto de bases

de datos distribuidas, implementadas fsicamente en equipos y localizaciones dis-
tintos, pero continan formando una nica entidad lgica. En la literatura, a este
tipo de CMDB se le suele denominar federada (FCMDB).
Existe tambin el concepto de base de datos de gestin de activos (asset manage-
ment data base) destinada a la gestin contable del inventario. La base de datos de
activos se relaciona con la CMDB normalmente por medio del identificador del
elemento de configuracin mantenido de forma comn en ambas bases de datos.
Interesa conseguir la trazabilidad de la informacin financiera de los CI, aun
cuando no resida fsicamente en la CMDB.
Una faceta muy importante a exigir a la herramienta que soporta la CMDB es su
facilidad para integracin con otros productos, tanto para la carga de datos, como
para integrarse en otras herramientas, ya que la CMDB acaba teniendo interfaces
con todo tipo de herramientas existentes. As, la CMDB deber integrarse con:
Gestin del incidente.
Gestin del cambio.
Gestin de informes.
Gestin de inventarios.
Autodescubrimientos.
Herramientas web de visualizacin grfica de las configuraciones.
Si bien queda fuera del mbito de responsabilidad de la gestin de la configuracin,

es importante hacer notar la existencia de soluciones o herramientas que, a partir
de la informacin contenida en la CMDB, proporcionan una visin grfica de los
servicios de TI (service view). Estas soluciones, por otro lado, tambin son capaces
de integrarse con herramientas de monitorizacin a efectos de ofrecer en tiempo
real un cuadro de mando de monitorizacin de los servicios de TI. Esta vista suele
ser navegable, pudindose descender grficamente entre los elementos que compo-
nen un servicio, hasta llegar al componente que est fallando.
Los cambios realizados en los elementos de configuracin y sus relaciones, provo-
cados por los cambios habituales en la infraestructura (peticin de cambio o RFC),
deben automatizarse en la medida de lo posible. Adems, se debe dejar un registro
cruzado, tanto en CI con el RFC que lo ha modificado, como en el RFC con los
CI que modifica. As, desde dicho elemento de configuracin, se podr acceder a
un histrico de las solicitudes de cambios que han provocado las modificaciones de
dicho elemento. Dicha trazabilidad entre la peticin de cambio y el CI afectado es,

a menudo, una evidencia solicitada por cualquier auditora para constatar la inte-
gridad del sistema de gestin. Y aqu, la consistencia de datos es ineludible.
As pues, una CMDB tiene que estar bien integrada con su entorno, con modelado
grfico de relaciones entre CI y con mecanismos de asignacin masivos basados en
clasificadores o reglas de negocio, pues son muy tiles para eliminar tareas mon-
tonas en el mantenimiento de sus contenidos.
La biblioteca de software definitivo (DSL)

La biblioteca de software definitivo (DSL, Definitve Software Library) es un reposi-
torio en el que se almacena una copia de todo el software instalado en el entorno de
TI. En ITIL v3 se la ha denominado como biblioteca de medios definitivos (DML,
Definitive Media Library).
Este sistema de almacenamiento, normalmente estar formado por una base de
datos que tiene las fichas de catalogacin de todos los CI software, un conjunto
de directorios compartidos que almacenan los archivos con el software original y un
conjunto de armarios que contienen los CD originales del fabricante y un justifi-
cante impreso de la propiedad de la licencia (en los casos en los que se tuviera).
Contiene los originales controlados de todo el software de la organizacin. La DSL
deber contener las copias finales del software adquirido (junto con sus licencias o
informacin), as como el software de desarrollo propio. Los originales de toda la
documentacin de un sistema tambin se almacenarn en la DSL en forma digital.
nicamente debe aceptarse en la DSL el software autorizado.
En realidad, este sistema de almacenamiento puede constar de una o ms bibliotecas
de software o sistemas de almacenamiento de archivos que deberan estar separados
de los sistemas de almacenamiento de archivos de desarrollo, pruebas y produccin.
La DSL almacena tanto el cdigo fuente de los programas, como los ejecutables y
su documentacin. Tambin incorpora el software comprado a los fabricantes (sis-
tema operativo, gestor de bases de datos, etc.) y todas las actualizaciones del mismo
instaladas. Esto incluye tambin a los controladores de dispositivos y documenta-
cin asociada. Incorpora la parametrizacin realizada en los productos y aplicati-
vos, as como, todas las configuraciones necesarias a realizar en la planta instalada
durante la etapa de integracin y pruebas. No hay que olvidar tambin la necesidad
de registro del software que se descargue de Internet (gratuito o de pago).
La DSL debe contener el histrico completo de versiones de un mismo software
para proporcionar la versin necesaria en el caso de que se deban implementar los
planes de marcha atrs.
CMDB
En la figura 9.1.11 se muestran los principales elementos que se deben considerar

en el diseo de la DSL.
Diseo de la DSL
Gestor de la
configuracin
Ficha CI CI CI CI
del CI CI CI
CICMDB CI
Diseo de la DSL: software CI CI CI CI CI
Definir nomenclatura, etiquetado

y ficha catalogrfica.
Definir mbito, alcance. CI
Definir tipos de CI software a incluir. software
Requisitos herramienta DSL y Archivo fsico Archivo electrnico
del almacenamiento fsico.
Perodo retencin del software.
Procedimientos actualizacin.
Relacin con procesos de cambio
y de entrega.
Relacin con el rea de proyectos
desarrollo software.
Procedimientos de auditora.
DSL
Biblioteca de software definitivo
Plan de capacidad y de continuidad.
Figura 9.1.11. Elementos a considerar en el diseo de la DSL
La DSL y la CMDB deben estar cubiertas por el plan de continuidad de TI y con-

templadas como los primeros elementos a recuperar, pues sin ellas ser imposible
restaurar los servicios.
Tambin se deber realizar la gestin de la capacidad de la DSL, para almacenar
todas las actualizaciones de software que envan los fabricantes. No hay que pasar
por alto el espacio necesario en armarios para clasificar los DVD y CD, y los
manuales de los fabricantes, aunque la tendencia de la industria es ir reduciendo el
soporte fsico. El almacenamiento de los justificantes de las licencias para propsi-
tos de auditoras posteriores, tambin requiere su arte, debido a los diferentes
formatos en que se facilitan (un cdigo electrnico, una pegatina en la caja, un
documento impreso, etc.). La DSL debe almacenarse en un entorno seguro y es
conveniente que se realicen copias de seguridad peridicas de la parte digital.
En empresas de tamao medio o grande, lo lgico es utilizar un producto del mer-
cado para soportar la DSL. Para el control de los cdigos fuente de los aplicativos de
la empresa, lo habitual es utilizar para la DSL la misma instalacin de la herramienta

de control de versiones utilizada por los proyectos de desarrollo. Pero se debe man-
tener una rigurosa separacin lgica entre el control de las versiones del desarrollo y
el software instalado en produccin.
Control de la configuracin (registrar y actualizar)

Despista un poco que bajo el trmino de control se esconda toda la actividad de carga
y actualizacin de datos. Hay que leer un poco entre lneas para darse cuenta de este
aspecto, pues las Normas ISO/IEC 20000 se centran en especificar requisitos para
que la informacin se incorpore de una forma controlada a la CMDB y a la DSL.
La actividad de control de la configuracin realiza la carga y actualizacin de la
informacin sobre los CI en la CMDB y almacena los CI software en la DSL. Ade-
ms, debe garantizar que la informacin es fiable.
Hay que tener en cuenta que una correcta gestin de la configuracin necesita la
colaboracin de todo el personal de TI para mantener actualizada la informacin
almacenada. Para lograrlo, el gestor de la configuracin nombrar la figura de los
titulares de los elementos de configuracin, que son los responsables de que la infor-
macin de los CI est correctamente actualizada (servidores, elementos de red, etc.).
Las mejores prcticas recomiendan que los resultados de las herramientas de auto-
descubrimiento se almacenen en una base de datos temporal, y no se carguen direc-
tamente en la CMDB. As, se evita la introduccin de errores en la informacin.
Posteriormente, con un proceso supervisado se realiza la conciliacin de ambas
bases de datos y se analizan las inconsistencias.
UNE-ISO/IEC 20000-1
Los procedimientos de control de configuracin deben asegurar que se mantiene la

integridad de los sistemas, servicios y componentes de servicio.
UNE-ISO/IEC 20000-2
El proceso debera garantizar que slo los Ningn elemento de la configuracin se

elementos de la configuracin autoriza- debera aadir, modificar, reemplazar o
dos e identificables son aceptados y regis- eliminar/retirar sin la documentacin de
trados desde su recepcin hasta su baja. control apropiada, por ejemplo: apro-
CMDB
bacin de la solicitud de cambio, infor- b) proporcione algn medio de recu-

macin actualizada de la versin. peracin ante desastres;
Para proteger la integrad de los sistemas, c) permita la recuperacin contro-
servicios e infraestructura, los elementos lada de una copia del maestro
de la configuracin se deberan mantener controlado, por ejemplo: software.
en un entorno seguro y adecuado que:
a) los proteja de accesos no autori-
zados, cambios o corrupcin, por
ejemplo: virus;
La gestin de la configuracin debe estar puntualmente informada de todos los

cambios y adquisiciones de componentes para mantener actualizadas la CMDB y la
DSL. Igualmente debe estarlo en lo relativo a cualquier cambio realizado en todo
tipo de elemento instalado.
El registro de los componentes hardware se debe iniciar desde el mismo momento
de la aprobacin de su compra y debe mantenerse actualizado su estado en todo su
ciclo de vida. Debe haber un registro auditable de todas las actualizaciones. Espe-
cialmente, debe estar correctamente registrado y almacenado todo el software en
produccin y su documentacin.
Las tareas de control parten de CI ya etiquetados y deben centrarse en:
Registrar los CI nuevos y sus versiones, tanto en la CMDB como en la DSL.
Actualizar el registro de los CI.
Proteger la integridad de las configuraciones.
Asegurar que todos los componentes estn registrados en la CMDB.
Asegurar que todo componente software y su documentacin estn almace-
nado en la DSL.
Monitorizar el estado de todos los componentes.
Comprobar y actualizar las interrelaciones entre los CI.
Informar sobre el estado de las licencias.
En pequeas organizaciones a veces es conveniente combinar en una persona la

gestin de la configuracin con la gestin del cambio, para simplificar el bloque de
control. La coordinacin entre ambos procesos es una factor crtico para el xito y
sta unificacin puede resultar beneficiosa en aquellos casos en el que el volumen
de la infraestructura no justifica la designacin de funciones separadas.
Seguimiento del estado de configuracin e informes

(informar)
La actividad de seguimiento del estado enmascara la principal funcionalidad de este
proceso, que es ser consultado. As, la actividad se centra en proporcionar a toda
la organizacin la informacin disponible sobre los CI, bien sean las fichas de la
CMDB o los archivos de la DSL. El personal de la organizacin de TI podr obtener
datos de la configuracin, bien mediante peticin de informacin a gestin de la
configuracin, o bien mediante consulta directa de la CMDB. Normalmente, son las
propias herramientas de gestin (incidente, problema, cambio, nivel de servicio, etc.)
las que se integran con la CMDB para mostrar la informacin de configuracin de
forma integrada en sus pantallas de gestin.
Adems, esta actividad genera y distribuye, de forma regular, informes sobre el
estado de la configuracin, en los que se muestran el historial de cambios y la ver-
sin actual de cada uno de los CI bajo control. Tambin, en esta actividad se calcu-
lan las mtricas y se generan los informes necesarios para controlar el correcto fun-
cionamiento del proceso de gestin de la configuracin.
UNE-ISO/IEC 20000-1
La gestin de la configuracin debe proporcionar informacin al proceso de gestin

del cambio sobre el impacto de un cambio solicitado sobre la configuracin del ser-
vicio y de la infraestructura. Los cambios en los elementos de configuracin deben
ser fciles de identificar y auditables cuando sea apropiado, por ejemplo para cam-
bios y movimientos en el software y el hardware.
Antes de un paso al entorno real, debe establecerse una lnea de referencia de los
elementos de configuracin correspondientes.
UNE-ISO/IEC 20000-2
Los registros de la configuracin se debe- Esto debera permitir el seguimiento de

ran mantener actualizados y con la pre- los cambios en los elementos de la confi-
cisin adecuada para reflejar los cam- guracin a travs de sus diferentes esta-
bios en el estado, localizacin y versin dos, por ejemplo: solicitado, recibido, en
de los elementos de la configuracin. pruebas de aceptacin, activo, bajo cam-
bio, retirado y eliminado.
El seguimiento del estado debera propor-
cionar informacin sobre los datos actua- La informacin de la configuracin se
les e histricos de cada elemento de con- debera mantener actualizada y disponi-
figuracin a lo largo de su ciclo de vida. ble para: los planes, la toma de decisio-
CMDB
nes y la realizacin de cambios a las Los informes deberan cubrir:

configuraciones definidas.
a) las ltimas versiones de los ele-
Cuando sea requerida, la informacin mentos de la configuracin;
de la configuracin debera estar acce-
b) la localizacin del elemento de
sible a: usuarios, clientes, suministrado-
configuracin y, para el software,
res y socios para darles apoyo en sus
la localizacin de las versiones
planes y en la toma de decisiones. Por
maestras;
ejemplo, un proveedor externo de servi-
cios podra poner accesible su informa- c) interdependencias;
cin de la configuracin a los clientes y
d) historia de la versin;
a otras partes, para dar soporte a los
procesos de gestin del servicio del resto e) estado de los elementos de la
de las partes implicadas en un servicio configuracin que conjuntamente
completo extremo a extremo. constituyan:
Los informes de gestin de la configura- 1) la configuracin del servicio o
cin deberan estar disponibles para del sistema;
todas las partes correspondientes. Los
2) un cambio, una lnea de refe-
informes deberan cubrir: la identifica-
rencia, un paquete de instala-
cin y el estado de los elementos de la
cin o una entrega;
configuracin, sus versiones y la docu-
mentacin asociada. 3) una versin o una variante.
La informacin relativa a los indicadores de gestin del proceso permite evaluar el

volumen de objetos manejados, su grado de implantacin y efectividad, as como,
el cumplimiento de los acuerdos de nivel operativo (OLA) establecidos.
Es imprescindible elaborar informes que permitan evaluar el desempeo de la ges-
tin de la configuracin, tanto para conocer la estructura y adecuacin de la
CMDB y la DSL, como para aportar informacin a otras reas de TI.
Otra actividad que se debe realizar es la generacin de las lneas base, que permiten
obtener una fotografa del estado de la configuracin de un entorno en un
momento del tiempo (por ejemplo, antes de una entrega), con el objeto de facilitar
la marcha atrs en caso de que el paso a produccin no sea satisfactorio.
Verificacin y auditora de la configuracin

Se deben formalizar procedimientos de verificacin y auditora al objeto de asegurar
que el contenido de la CMDB y de la DSL son exactos y completos. Se compararn
los CI registrados en la CMDB con respecto a los componentes lgicos y fsicos en
la infraestructura, permitiendo as identificar las desviaciones respecto a la realidad.
UNE-ISO/IEC 20000-1
Los procedimientos de auditora de la configuracin deben incluir el registro de defi-

ciencias, el lanzamiento de acciones correctivas y la comunicacin de su resultado.
UNE-ISO/IEC 20000-2
Los procesos de verificacin y auditoria, Peridicamente se deberan realizar audi-

en sus aspectos fsicos y funcionales, se toras de la configuracin, antes y des-
deberan planificar y se debera realizar pus de un cambio importante, despus
una comprobacin para asegurar que de un desastre y a intervalos aleatorios.
los procesos y recursos adecuados estn
Las deficiencias y las no conformidades
establecidos para:
se deberan registrar, evaluar e iniciar
a) proteger las configuraciones fsi- una accin correctiva, actuar sobre
cas y el capital intelectual de la ellas; y se debera realimentar a las par-
organizacin; tes correspondientes as como estable-
b) asegurar que el proveedor del cer un plan de mejora del servicio.
servicio tiene el control de sus Nota: Normalmente hay dos tipos de auditoria
configuraciones, las copias maes- de la configuracin:
tras y las licencias; a) auditoria funcional de la configuracin:
c) garantizar que la informacin de un examen formal para verificar que un
elemento de configuracin ha alcan-
la configuracin est actualizada, zado el rendimiento y caractersticas
controlada y es visible; funcionales especificadas en sus docu-
mentos de configuracin;
d) asegurar que un cambio, una
entrega, un sistema o un entorno b) auditoria fsica de la configuracin: un
examen formal de la configuracin
es conforme a los requisitos con- segn sale de fbrica de un elemento
tratados o especificados y que los de configuracin para verificar su con-
registros de la configuracin son formidad con sus documentos de confi-
exactos. guracin del producto.
El objetivo de las auditoras es asegurar que la informacin registrada en la CMDB

y la DSL coincide con la configuracin real.
La informacin recopilada por las herramientas de gestin remota y de autodescu-
brimiento de los elementos de configuracin de hardware y software puede ser utili-
zada para verificar la CMDB y la DSL. No obstante, es necesario complementar
estos datos con auditoras manuales. stas deben realizarse con cierta frecuencia y
al menos:
Tras la implementacin de una nueva CMDB o DSL.
CMDB
Antes y despus de grandes cambios en la infraestructura.

Cuando existen sospechas de que la informacin almacenada es incorrecta o
incompleta.
Las auditoras deben dedicar especial atencin a aspectos como:

El uso correcto de la nomenclatura en los registros de los CI.
La comunicacin con la gestin del cambio: informacin sobre RFC, cam-
bios realizados, etc.
El estado actualizado de los CI.
El cumplimiento de los niveles de alcance y detalle predeterminados.
La actualizacin y grado de completitud de la DSL.
La adecuacin de la estructura de la CMDB con la de la estructura de TI real.
Entre la documentacin generada cabra destacar:

Las desviaciones entre la informacin almacenada (CMDB o DSL) y la obte-
nida de las auditoras de configuracin.
Los costes asociados al propio proceso.
Los sistemas de clasificacin y nomenclatura utilizados.
Los informes sobre la configuracin no autorizada y si estn amparadas por
licencias.
La calidad del proceso de registro y clasificacin.
La informacin estadstica.
Inconsistencias y no conformidades. Es la informacin relativa a las distintas

inconsistencias encontradas como resultado de las actividades de verificacin y
auditora del estado de la configuracin. Estas inconsistencias son provocadas fun-
damentalmente por la implementacin de CI no autorizados o que no van acom-
paados de la documentacin requerida.
Las inconsistencias se pueden detectar desde cualquier proceso, pero habitualmente
es en la gestin de incidentes y la operacin donde se suelen identificar el mayor
nmero de ellas. Es recomendable establecer un flujo de relacin entre estos proce-
sos, proveedores de mejoras, y el de configuracin para poder trazar una revisin
de cumplimiento, tanto los registros de inconsistencias detectados, como los meca-
nismos para obtenerlos.
Las auditoras fsicas y peridicas, tambin deben alimentar los registros de opor-
tunidades de mejora, y arrancar las consiguientes acciones correctivas.
La deteccin de inconsistencias debe llevar aparejada una concienciacin de todos
los implicados sobre la importancia y gravedad (impacto) que puede representar
una inexactitud en la informacin recogida. As, no slo se favorece la mejora con-
tinua, sino que adems, se garantiza la solvencia de la CMDB y la DSL, hacindo-
las cada vez ms robustas y fiables.
En esta actividad se evala el proceso en base a las mtricas e informes de gestin,

y consecuentemente se proponen mejoras al mismo. Tambin, se debe hablar con
todos los participantes para detectar mejoras al mismo.
Se debe poner foco en la automatizacin progresiva de las actividades de carga y
descubrimiento. Dado que la configuracin es un proceso que suministra informa-
cin a toda la organizacin, se debe ir completando progresivamente la integracin
de la CMDB con el resto de herramientas de gestin del proveedor de TI.
Si este proceso se ha implantado siguiendo las recomendaciones, se habr iniciado
de una forma sencilla, por tanto, habr que contemplar una mejora progresiva: en
primer lugar, del poblado de la CMDB y, en segundo lugar, incrementando el
alcance y la profundidad.
Todas estas actividades de mejora tienen un coste y un esfuerzo nada despreciable
que habr que contemplar en los presupuestos anuales del proveedor de TI. Los
beneficios de tener una informacin completa y fiable sobrepasan con creces el
coste necesario para alcanzarlo.
Como con el resto de los procesos, las propuestas de mejora de este proceso se
deben incorporar al plan general de mejora de gestin del servicio (vase el cap-
tulo 4), para ser analizadas y desplegadas en un programa nico de mejora.
Mtricas del proceso

Dado que la gestin de la configuracin es un proceso interno de TI, no visible
para el negocio, no suele aportar indicadores globales de TI (KGI de TI). En este
caso, las mtricas del proceso se centrarn en informar al CIO y al responsable del
proceso. Contemplarn aspectos como:
Calidad del dato: el nmero de cambios en la CMDB por CI incorrectos o el
porcentaje de CI que han pasado satisfactoriamente la ltima auditora.
CMDB
Volumen o actividad: nmero de CI, incremento de CI en el ltimo perodo,

el nmero medio de accesos a la CMDB, nmero de lneas base proporcio-
nadas, etc.
Eficiencia: el porcentaje de CI con actualizacin automtica.
Grado de cobertura y calidad del software por parte de la DSL.
En el grfico de la figura 9.1.12 se muestra el resumen de los indicadores ms rele-

vantes para este proceso seleccionados por un grupo de trabajo de itSMF Espaa.
de itSMF Espaa

Como en el resto de los procesos, los roles intervinientes en el proceso se estructu-
ran en los roles propios del proceso y los roles ajenos al proceso.
El gestor de la configuracin (gestor del proceso o process manager) es el res-
ponsable del da a da de la actividad del proceso. En este caso identifica,
aprueba y controla la actualizacin de los elementos de configuracin. Tiene
bajo su control la CMDB y la DSL, vela por el acceso a la informacin de

toda la organizacin, se encarga de las auditoras de la configuracin, etc.
Los administradores o las personas encargadas del soporte al proceso, ayu-
dan al gestor de la configuracin en toda la actividad.
El administrador de la CMDB y DSL, es un perfil tcnico que administra la
base de datos.
Los titulares de elementos de configuracin, personal de la organizacin de
TI que vela por la informacin de configuracin de los CI asignados.
Los roles ajenos que son relevantes en este proceso son los siguientes.
continua del mismo. Todo ello de una forma integrada con el modelo de ges-
tin del proveedor de TI incorporado en el SGSTI.
El responsable de la gestin del cambio debe proporcionar informacin
de todos los cambios en los CI a los que se ha asignado el control de uno
o varios elementos de configuracin. Ser un miembro de la organiza-
cin de TI especializado en un mbito tecnolgico, y con el conoci-
miento requerido para identificar y mantener los CI que estn bajo su
rea de control.
Los roles de mayor relevancia que participan en el proceso de gestin de la confi-

guracin se representan en la figura 9.1.13.
Resumen
Sin una buena informacin de la configuracin es imposible alcanzar una eficiencia
y madurez en la gestin de las TI. Una informacin fidedigna y completa sobre la
infraestructura de TI, sus servicios y la organizacin que los presta, son los cimien-
tos para reducir los incidentes, ser giles en la provisin de peticiones, evitar erro-
res en los cambios, etc.
De una forma paulatina pero constante, en la implementacin de la gestin del
servicio hay que dedicar esfuerzos importantes a aglutinar y organizar la informa-
cin sobre la configuracin de TI. Por ello, es uno de los primeros procesos que
CMDB
Roles del proceso
Responsable de la
gestin del servicio
Gestor de la
SGSTI configuracin
Administrador de
la CMDB y DSL
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
de configuracin
Titulares de elementos
de configuracin
Gestor del cambio
Figura 9.1.13. Roles del proceso de gestin de la configuracin
se suele implementar, aunque por su laboriosidad no se le puede calificar de xito

rpido.
La CMDB no se limita a una mera enumeracin del stock de piezas, sino que nos
brinda una imagen global de la infraestructura de TI de la organizacin, con todos
sus elementos.
En ISO/IEC 20000, al igual que en ITIL v3, la gestin de la DSL se encarga a la
gestin de la configuracin, a diferencia de ITIL v2, que estaba bajo la responsabi-
lidad de la gestin de la entrega.
Beneficios
Algunos de los beneficios de alcanzar una correcta gestin de la configuracin son
los siguientes:
Resolucin ms rpida de los incidentes y los problemas, que redunda en
una mayor calidad de servicio. Una fuente habitual de problemas es la
incompatibilidad entre diferentes CI (por ejemplo, drivers desactualizados,
etc.). La deteccin de estos errores sin una CMDB actualizada alarga consi-
derablemente el ciclo de vida de un incidente o de un problema.
Disponer de los fuentes precisos y actualizados cuando empieza un pro-
yecto de evolucin, as como, tener un correcto control de los mdulos
que cada equipo de desarrollo est modificando resulta esencial para aho-
rrar esfuerzos intiles y que varios equipos trabajen sobre software desac-
tualizado.
De la misma forma, no tiene precio la eficacia y seguridad que le otorga a un
equipo de desarrollo que comienza un proyecto, el conocer con precisin la
configuracin real del entrono de produccin en donde se explotar el apli-
cativo.
Una gestin del cambio ms eficiente. Es imprescindible para conocer la
estructura previa, analizar el impacto y disear un cambio que no genere
nuevas incompatibilidades o incidentes.
Reduccin de costes. El conocimiento detallado de todos los elementos de
configuracin permite, por ejemplo, eliminar duplicidades innecesarias y
ahorrar tiempo en repetidas bsquedas de informacin.
Control de licencias. Al contrario de lo que pasaba antao, que el control
de licencias acarreaba el descubrimiento de software ilegal, hoy da tener un
buen control de las licencias puede traer importantes ahorros en costes,
por licencias no utilizadas, por mantenimientos innecesarios, por duplici-
dades, etc.
Mayores niveles de seguridad. Una CMDB y DSL actualizadas permiten,
por ejemplo, detectar vulnerabilidades en la infraestructura.
Mayor rapidez en la restauracin del servicio. Si se conocen todos los ele-
mentos de configuracin y sus interrelaciones ser mucho ms sencillo recu-
perar la configuracin de produccin en el tiempo ms breve posible.
CMDB
Realice un esquema con los dos primeros niveles de una CMDB para
su organizacin.
Qu campos incluira en la ficha del CI tipo servicio?
Cmo se organiza en su empresa el paso de los componentes soft-
ware, que suelen mantener de los equipos de desarrollo (control de
versiones), a la DSL?
1
9.2. Gestin del cambio 661
9.2. Gestin del cambio
Figura 9.2.1. Esquema general del proceso de la gestin del cambio
Vivimos en una poca de continuos cambios. Es el propio mercado el que imprime

al negocio un ritmo constante de transformacin para sacar nuevos productos, para
ser competitivos en costes o para la excelencia en las formas de gestionar. Vemos
cmo la informtica, que inici su andadura automatizando tareas humanas, es
cada vez ms importante para la supervivencia del negocio.
La organizacin de TI debe ser capaz no slo de mantener este ritmo exigido por
el mercado al negocio, sino que adems debera situarse al frente de la batalla, pro-
poniendo nuevas soluciones a lo existente, nuevos productos y nuevas vas de inter-
accin con el mercado; para, en definitiva, encontrar la difcil senda de aportar
valor al negocio.
Pero, el ritmo acelerado de evolucin que debe mantener TI para responder a las
necesidades del negocio, tiene un severo lastre, los cambios son la fuente principal
de incidentes, de inconsistencias en la informacin y de trabajo. Los cambios en los
servicios provienen de numerosas fuentes: la incorporacin de nuevos servicios, la
mejora de los existentes, la resolucin de incidentes o de problemas, por necesidad
de cumplir un mandato legal, etc.
En este escenario, el proceso de la gestin del cambio se convierte en una pieza

estratgica esencial para imprimir la agilidad necesaria a la evolucin, mientras
se mantiene un control frreo sobre la estabilidad y robustez de los servicios.
Por esta razn, este proceso es uno de los primeros en implementarse (vase la
figura 9.2.1).
Formalmente, la gestin del cambio es el proceso con la responsabilidad sobre el
control y tratamiento de los cambios en cualquier elemento que forme parte de los
servicios de TI, minimizando el riesgo y velando por la eficacia. En la figura 9.2.2
se presenta una visin introductoria al proceso.
Proceso de gestin del cambio Qu aporta:
Mayor fiabilidad de los servicios, al

Definicin: minimizar el impacto sobre la calidad
del servicio por los cambios.
Proceso responsable del control y
tratamiento de los cambios en los Asegurar el empleo de mtodos para
servicios y en la infraestructura TI. manejar eficaz y eficientemente un
alto volumen de cambios.
Objetivo: Implantar una gestin integral que

proporcione una visin conjunta del
Asegurar que todos los cambios son impacto de los cambios en el negocio.
registrados, evaluados, aprobados,
implementados y revisados de una Realizar cambios en los servicios de
manera controlada. manera ordenada y estructurada,
coordinando la realizacin de
actividades.
Garantizar que todos los cambios son

registrados adecuadamente.
Figura 9.2.2. Introduccin al proceso de gestin del cambio
La gestin del cambio debe trabajar para asegurar que los cambios:
Son necesarios y estn justificados.
Se llevan a cabo sin perjuicio de la calidad del servicio de TI.
Estn convenientemente registrados, clasificados y documentados.
Cumplen los plazos acordados.
Han sido cuidadosamente probados en un entorno de prueba.
Se realizan con eficiencia.

Se ven reflejados en la CMDB.
Pueden deshacerse mediante planes de marcha atrs del cambio, en caso de
un incorrecto funcionamiento tras su implementacin.
Fiabilidad, agilidad y eficiencia, son quiz los tres principios directores que debe
regir la gestin del cambio. Fiabilidad para evitar errores y fallos, agilidad para ser
capaces de cambiar los servicios respondiendo al time to maket que requiere la
empresa, y eficiencia para realizar el proceso incurriendo en costes mnimos, como
se muestra en la figura 9.2.3.
Figura 9.2.3. Principios directores que deben regir la gestin del cambio
El equilibrio entre estos tres mandatos permitir que, el control y rigor que impone
este proceso en la organizacin para conseguir la fiabilidad y reducir el riesgo, se
pueda realizar incurriendo en el mnimo coste organizativo. Si se adoptan procedi-
mientos excesivamente restrictivos, se mejora la fiabilidad, pero se dificultan los
cambios y la organizacin se vuelve lenta. Si por el contrario el proceso de cambio
se trivializa, se provoca una falta de estabilidad en el servicio que infringir impor-
tantes costes a causa de incidentes y la imposibilidad de controlar su calidad.
En el diseo del proceso y de las tareas que incluye hay que tener en cuenta el volu-
men de cambios que se tendrn que gestionar, pues una organizacin grande (por
ejemplo, de 10.000 usuarios y 500 servidores) suele gestionar entre 70 y 100 peti-
ciones de cambio ya formalizadas a la semana (sin contar los cambios estndar pre-
autorizados), por lo que, gran parte de la actividad del proceso se centra en contro-
lar que todos los involucrados en este flujo sin fin de cambios cumplan las reglas.
Disponer de una herramienta para su soporte es esencial.
Tambin, es conveniente diferenciar las actividades propias de la gestin del cam-
bio de las actividades especficas de la gestin de los proyectos que se encargan de
la construccin de los grandes cambios. El primero hace referencia al proceso
de control de toda la actividad que pueda impactar en los servicios, y el segundo se
encarga de engranar la actividad necesaria para construir o modificar las aplicacio-
nes o plataformas que forman parte de un cambio especfico. La gestin del cam-
bio se rige por ISO/IEC 20000, mientras que la gestin de proyectos utiliza disci-
plinas como PMBOK o PRINCE2.
Adems, hay que considerar que la gestin del cambio es una parte esencial del pro-
ceso de creacin de servicios (planificacin e implementacin de servicios nuevos o
modificados; vase el captulo 5), pues da luz verde al inicio de la construccin y se
responsabiliza de la implantacin del nuevo servicio.
Gestin del cambio tiene una estrecha relacin con gestin de la entrega, pues cada
uno de los cambios aprobados debe ser implantado y desplegado por este ltimo
proceso.
En la figura 9.2.4 se recoge un resumen de los elementos que intervienen el pro-
Los elementos principales que componen el proceso de gestin del cambio son los
siguientes:
Cambio. Accin especfica y prevista que alterar o tendr un efecto sobre los ser-
vicios o la infraestructura de TI. En general, es cualquier adicin, eliminacin,
modificacin o movimiento de uno o ms CI (elementos de configuracin). En la
actividad habitual del proceso, los cambios se articulan en funcin de una serie de
criterios entre los que podemos considerar:
Atendiendo a su alcance, complejidad o impacto:
Gran cambio (macro).
Cambio significativo (mayor).
Cambio menor.
Atendiendo a la forma en que se ejecuta el cambio:

Cambio normal.
ACTORES SERVICIOS
CI
Documentacin
HW SLAs
Promotores Comit de cambios
de los cambios Gestor del cambio (CAB) SW
Solicitud de cambio
(RFC)
Lista de cambios Gestionar la
planificados (FSC) mejora del proceso
Plan de pruebas
Informe de Aprobacin Aprobacin Comprobacin

disponibilidad (PSA) construccin transicin post-implantacin
Figura 9.2.4. Elementos del proceso de gestin del cambio
Cambio estndar.
Cambio preautorizado.
Cambio urgente o de emergencia.
Realmente cada organizacin va a determinar los tipos de cambio ms adecuados a

sus necesidades. A continuacin, se describen los ms frecuentes:
Cambios macro y mayor. Habitualmente se gestionan bajo una estructura
de proyecto. Son complejos y requieren la dedicacin de bastantes recursos.
Suelen ser cambios que provienen del proceso de creacin o evolucin de
servicios. En estos casos, el cambio tiene gran importancia y suele tener un
impacto probable en otras partes de la organizacin, por lo que se aplica el
ciclo de vida del cambio hasta su ltimo requisito. Son ejemplos, implantar
un nuevo servicio con toda su infraestructura, realizar una consolidacin de
servidores, cambiar la arquitectura de los firewalls.
Cambio menor. De impacto bajo y que requiere pocos recursos. Suelen
recorrer un ciclo de vida mucho ms corto, eliminndose actividades de con-
trol que no tienen sentido para estos cambios menores. Por ejemplo, instalar
un servidor nuevo.
Cambio preautorizado. Cambio recurrente que se gestiona por delegacin
siguiendo unas reglas predeterminadas. Para cambios de escasa importancia,
recurrentes o que se repiten peridicamente, pueden acordarse procedimien-
tos estndar que no requieran la aprobacin expresa de la gestin del cambio
(cambios preautorizados). Una vez definida esta tipologa, permite una ges-
tin ms rpida y eficiente de cambios de bajo impacto en la organizacin de
TI. Por ejemplo, establecer los perfiles de acceso de un nuevo empleado,
generar una nueva contrasea o instalar una aplicacin en un PC.
Cambio de emergencia. Establecen la forma de actuar cuando es impres-
cindible introducir un cambio de forma inmediata para solucionar una crisis
grave.
Clasificacin de un cambio. Todo cambio debe ser clasificado para poder tratarlo
de la forma ms adecuada posible. De forma similar a los incidentes y los proble-
mas, se establecen dos tipos de clasificaciones: la categora que tipifica el contenido
del cambio y la prioridad con la que debe ser tratado:
Categora del cambio. Tipificacin de un cambio segn una clasificacin
predefinida, que tendr en cuenta el efecto del cambio en la organizacin
de TI en funcin de los recursos que se estimen necesarios para su implan-
tacin.
Prioridad del cambio. Valor que se asigna a la solicitud de cambio (RFC)
para indicar su importancia para la organizacin. Su objeto es el de asegurar
la adecuada asignacin de recursos y determinar el plazo en el que se requiere
su ejecucin. La prioridad depender de:
El impacto del cambio. Medida del efecto sobre el negocio.
La urgencia del cambio. Medida de plazo para la atencin de un cambio.
Comit de cambios (CAB, Change Advisory Board). Comisin o grupo repre-

sentativo de TI y de la empresa, con autoridad y competencia para valorar y acon-
sejar la implementacin de los cambios, desde los puntos de vista tcnicos y de
negocio. Se rene de forma regular para informar al gestor del cambio sobre la ido-
neidad de aprobar cada cambio. El CAB es convocado y liderado por el gestor del
cambio.
Gestor del cambio. Responsable de todo el proceso de gestin del cambio. Res-
ponsable ltimo de que toda la actividad de cambios no impacte en los servicios y
de que se realice segn lo establecido.
Herramienta de gestin del cambio. Es el conjunto de aplicaciones y bases de
datos necesarios para dar soporte informtico al proceso.
Informe de disponibilidad prevista del servicio (PSA, Projected Service Availa-
bility). Es el documento utilizado en la gestin del cambio para describir el efecto
de los cambios sobre los niveles de disponibilidad definidos en los acuerdos de
nivel de servicio. El PSA muestra detalles de las variaciones de la disponibilidad en
los acuerdos de nivel de servicio, motivadas por el cambio programado propuesto.
gramacin unificada de todos los cambios en curso, que recoge los detalles de los
cambios cuya implantacin haya sido aprobada, as como las fechas propuestas para
su implantacin. En ITIL v3 se ha pasado a denominar lista de cambios (change
schedule).
La FSC es controlada por el gestor del cambio y debe ser acordada con todas las
partes: los clientes, la gestin de nivel de servicio, el centro de servicio al usuario,
gestin de la disponibilidad, etc. Una vez acordada, el centro de servicio al usua-
rio debera comunicar a la comunidad de usuarios cualquier planificacin o
tiempo adicional de parada para la implantacin de cambios, utilizando para ello
los mtodos ms efectivos disponibles.
La FSC es una entrada esencial del proceso de gestin de la entrega.
Plan de pruebas del cambio. Documento que detalla todas las pruebas necesarias
que se realizarn en todas las etapas por las que pasa el cambio, desde las pruebas
durante la fase de construccin, las pruebas en la fase de implementacin, hasta las
pruebas de aceptacin final del cambio. El plan de pruebas se prepara en el mbito
del proyecto.
Promotores de los cambios. Personas de la organizacin de TI que, a partir de
una necesidad de realizar un cambio, desencadenan la solicitud del cambio. En
cambios grandes o complejos, el cambio se gestionara como un proyecto y el pro-
motor sera el jefe del proyecto.
Registro de cambios. Base de datos que contiene toda la informacin relativa a los
cambios en curso ya realizados o rechazados. Contiene las RFC, los detalles sobre
los elementos de configuracin afectados, la historia del cambio, etc. El cambio se

registra a partir de la aceptacin de la solicitud de cambio. Esta base de datos est
incluida en la herramienta para la gestin de cambios, que normalmente ser una
suite o producto informtico que cubra los procesos de resolucin y de control de
los servicios.
Solicitud de cambio (RFC, Request For Change). Formulario utilizado para pro-
poner un cambio en cualquier componente de una infraestructura de TI o en cual-
quier aspecto de un servicio de TI. Es un documento en el que se introducen la
naturaleza, los detalles, la justificacin y la autorizacin del cambio propuesto.
La RFC va actualizndose a lo largo de la vida del cambio.
Revisin postimplementacin (PIR, Post Implementation Review). Revisin
liderada por el gestor del cambio. Esta actividad, previa al cierre del cambio,
tiene como objetivo confirmar que el cambio ha cubierto sus objetivos, que los
clientes estn satisfechos con los resultados y que no se han producido efectos
colaterales.

Las interacciones y funcionalidades de la gestin del cambio se resumen sucinta-
mente en la figura 9.2.5.
El proceso se desencadena con la recepcin de una peticin de cambio (RFC) o
con la necesidad de realizar un cambio de emergencia. La peticin de cambio nor-
mal sigue el ciclo de vida del cambio, mientras que la necesidad de cambio de emer-
gencia sigue el procedimiento rpido de aprobacin, convocndose, si fuera nece-
sario, el CAB de emergencia. El proceso utiliza otras entradas para el soporte de su
actividad: la informacin existente en la CMDB, la lista vigente de cambios planifi-
cados (FSC), la base de datos de cambios con el registro de todos los cambios, el
plan del proyecto (en el caso de que el cambio se haya construido bajo un pro-
yecto), el plan de pruebas definido en el proyecto y el anlisis del impacto del cam-
bio realizado por el proyecto o promotor del cambio.
La primera actividad del proceso es precisamente la encaminada a planificar e
implementar la propia gestin del cambio. Una vez implementado, empieza a eje-
cutarse el ciclo de vida de cada cambio, que se inicia con la recepcin de la RFC y
concluye con su cierre. El responsable del proceso convoca y lidera las sesiones del
comit de cambios (CAB), mantenindose la lista con todos los cambios planifi-
cados (FSC). Se acta ante la necesidad de cambios de emergencia para que se
implementen lo ms rpido posible, supervisndose y monitorizndose estadsti-
camente todos los cambios preautorizados. Se realiza la supervisin de todo el
Desencadenantes 3 Planificacin e implementacin de Salidas principales:

del proceso: la gestin del cambio. Cambio implementado
RFC de diferentes 3 Gestionar el ciclo de vida Comunicacin usuario.
fuentes. completo de los cambios, desde
Actualizacin CMDB
Necesidad cambio de el RFC hasta su cierre:
y DSL.
emergencia. Registrar, evaluar el impacto
Actualizacin BD de
del cambio (PSA), planificar,
Entradas de soporte: cambios.
aprobar, seguir, comprobar
CMDB. (PIR) y cierre. Salidas secundarias:
Lista de cambios 3 Convocar y liderar el CAB. RFC cerradas.
programados (FSC) Aprobar los cambios.
Lista de cambios
anterior. 3 Mantener la lista de programados (FSC).
BD de cambios. cambios programados (FSC).
Informe de
Plan del proyecto. 3 Actuacin en cambios de disponibilidad
emergencia. prevista (PSA).
Plan de pruebas.
3 Monitorizacin de los cambios CMBD actualizada.
Anlisis del impacto del
preautorizados.
cambio. DSL actualizada
3 Supervisin del funcionamiento
Propuesta de actividades
del proceso. Mejora del proceso.
para la mejora del
3 Informes y anlisis sobre las proceso.
acciones de gestin del cambio.
3 Estar al da y conocer los
servicios: funcionalidad e
infraestructura.
Figura 9.2.5. Entradas, actividades y salidas del proceso de gestin del cambio
funcionamiento del proceso. Se emiten informes y anlisis sobre las acciones de

gestin del cambio. El gestor del cambio debe estar permanentemente informado
y al da de los servicios, la funcionalidad ofrecida y la infraestructura que utilizan,
ya que es la ltima autoridad responsable de la aprobacin de los cambios.
Como es lgico, la salida principal del proceso es el cambio implementado, con
calidad y dentro del plazo acordado. La implementacin lleva asociada que se ha
mantenido la comunicacin con el usuario, se ha actualizado la CMDB y la DSL,
as como, la base de datos de cambios. Las salidas secundarias del proceso son: las
RFC cerradas, la lista de cambios planificados (FSC) actualizada, el informe de dis-
ponibilidad prevista (PSA), la CMDB y DSL actualizadas, y las propuestas de
mejora del proceso.
De una forma especfica, las Normas ISO/IEC 20000 establecen unas directrices
concretas que el proceso de gestin del cambio debe cumplir y que se deben tener
en cuenta en la planificacin, definicin, implantacin y operacin habitual del pro-
ceso.
UNE-ISO/IEC 20000-1
Los cambios en los servicios y la infraestructura deben tener un mbito claramente

definido y documentado.
Todas las peticiones de cambio se deben registrar y clasificar, por ejemplo en urgen-
tes, de emergencia, importantes, menores. Se debe evaluar el riesgo, el impacto y
los beneficios para el negocio de las peticiones de cambio.
El proceso de gestin del cambio debe incluir la forma en que puede darse marcha
atrs o corregir cada cambio si no se realiza con xito.
Los cambios se deben aprobar y tras ello deben ser comprobados, y deben ser
implementados de una forma controlada.
Las fechas planificadas para la implementacin de los cambios se deben utilizar
como base para la planificacin de cambios y entregas. Se debe mantener y comu-
nicar a las partes correspondientes la planificacin que contenga los detalles de
todos los cambios aprobados para su implementacin y las fechas propuestas.
UNE-ISO/IEC 20000-2
Los procesos y procedimientos de ges- cambios es supervisado y mejo-

tin de cambio deberan garantizar que: rado;
a) los cambios tienen claramente defi- f) puede demostrarse cmo un cam-
nido y documentado su alcance; bio es:
b) slo son aprobados los cambios 1) generado, registrado y clasifi-
que proporcionan beneficios al cado (con las referencias a
negocio, por ejemplo: comerciales, los documentos que dieron
legales, regulatorios o estatutarios; origen al cambio);
c) los cambios son planificados en 2) evaluado en relacin al im-
base a la prioridad y al riesgo; pacto, la urgencia, el coste,
los beneficios y el riesgo del
d) los cambios a las configuraciones cambio en el servicio, en los
pueden ser verificados durante la clientes y en los planes de
implementacin del cambio; despliegue;
e) cuando sea requerido, el plazo 3) revertido o remediado, si no
para la implementacin de los tuvo xito;
4) documentado, por ejemplo, 9) planificado, supervisado e in-

la solicitud de cambio est cluido en un informe;
asociada a los elementos de 10) asociado a incidentes, proble-
configuracin afectados, a mas, otro cambio y a los regis-
la versin actualizada de la tros de elementos de configu-
implementacin y a los planes racin, cuando sea apropiado.
de despliegue;
5) aprobado o rechazado por El estado de los cambios y las fechas de
una autoridad de cambios, implementacin planificadas se debe-
dependiendo de su tipo, ran usar como base para la planifica-
tamao o riesgo; cin del cambio y del despliegue.
6) implementado por el respon- La informacin de planificacin debera
sable designado dentro de estar disponible para las personas afec-
los grupos responsables de los tadas por el cambio.
componentes a ser cambia-
Cuando se pueda ocasionar una per-
dos;
dida del servicio durante el horario nor-
7) probado, verificado y entre- mal del servicio, las personas afectadas
gado; deberan acordar el cambio antes de su
8) cerrado y revisado; implementacin.
Para garantizar una correcta gestin de los servicios, los procesos y procedimientos
de gestin de cambio debern garantizar que los cambios tengan su alcance clara-
mente definido y documentado. En coordinacin con la estrategia y la gestin del
porfolio de proyectos, la gestin del cambio tambin vela por que slo sean apro-
bados los cambios que proporcionan beneficios al negocio, por ejemplo, comercia-
les, legales, regulatorios o estatutarios.
En la planificacin del proceso, es recomendable definir y establecer los motivos
por los que se realizarn cambios, y quienes sern los promotores de estos cambios,
acotndose claramente los actores y la forma en la que se van a producir las entra-
das del proceso.
En la implementacin de una adecuada poltica de gestin del cambio en la
organizacin se deben superar algunos aspectos culturales crticos como los
siguientes:
Que los diferentes departamentos acepten la autoridad de la gestin del
cambio.
Que se sigan con rigor los procedimientos establecidos y, en particular, que
se actualice correctamente en la CMDB la informacin sobre los elementos
del servicio cambiados.
Que los encargados de la gestin del cambio conozcan a fondo las activida-
des, servicios, necesidades y estructura de la organizacin capacitndoles
para desarrollar correctamente su actividad.
Que los gestores del cambio dispongan de las herramientas adecuadas de soft-
ware para monitorizar y documentar adecuadamente el proceso.
Y por supuesto, el compromiso suficiente de la direccin por implementar
rigurosamente los procesos asociados.
En este aspecto, es recomendable que en las fases iniciales de la implementacin del

proceso se preste atencin en conseguir el consenso y la implicacin de todos los
involucrados, ya que promotores, gestores, supervisores, personal tcnico de des-
pliegues y titulares de los elementos de configuracin de la CMDB, se van a ver
envueltos en un proceso que seguramente les va a cambiar su forma de trabajar.
Tambin es importante que la figura del responsable del proceso tenga la autoridad
suficientemente reconocida en la organizacin para llevarlo a cabo, contando con la
participacin de todos y el apoyo de la direccin.
Es recomendable implantar de forma conjunta los dos procesos de control: la ges-
tin del cambio y la gestin de la configuracin. As, con el primero garantizamos
el control de todo cambio en los servicios, mientras que el segundo mantiene la
fidelidad de toda la informacin relacionada con los servicios. Implantando ambos
procesos se consigue que:
Los CI afectados por los cambios se hallen siempre registrados en la CDMB.
Los CI registrados en la CMDB estn sujetos al control del proceso de ges-
tin del cambio.
Debe existir tambin un procedimiento, medio de publicacin o notificacin de

cambios, en funcin de su relevancia que incluya: los medios de comunicacin, los
actores a comunicar, las confirmaciones de recepcin de notificacin o informacio-
nes (si se precisan), al nivel de autoridad definido por el proceso, que evidencie que
todas las partes implicadas (y especialmente el cliente) estn debidamente informa-
das de la activacin de un cambio.
El tratamiento de las descargas automticas a travs de Internet, que son conti-
nuas en el mbito de los ordenadores personales, es un tema que se debe analizar
de forma detallada en la organizacin y establecer las polticas de gestin adecua-
das. Estas descargas se despliegan autnomamente en el entorno productivo y
cambian la configuracin del puesto de trabajo. De una forma automtica tam-
bin se saltan varios procesos esenciales: la gestin del cambio, de la entrega y de
la configuracin.
Ciclo de vida completo de un cambio

La misin principal del proceso es poner orden y control, estableciendo unas etapas
y aprobaciones que deben seguir los cambios habituales. En el grfico de la figura
9.2.6 se muestra un esquema del ciclo de vida de un cambio.
Figura 9.2.6. Ciclo de vida completo de un cambio grande (macro o mayor)
El ciclo de vida de un cambio se resume en las siguientes tareas:

Registrar, evaluar y aceptar o rechazar las solicitudes de cambio (RFC) reci-
bidas. Se establece su categora y prioridad, y se analiza el informe de dispo-
nibilidad prevista (PSA) y el plan de pruebas del cambio.
Aprobar la construccin del cambio. Para ello, se convocan reuniones del
comit de cambios (CAB). En el caso que durante la construccin del cambio
se modificaran sustancialmente los acuerdos establecidos, el cambio deber

volver a ser tratado en el CAB.
Elaboracin y mantenimiento actualizado de la planificacin unificada de
todos los cambios en curso (FSC o lista de cambios planificados).
Coordinar la construccin e implementacin del cambio. El proceso de ges-
tin del cambio es el responsable tambin de coordinar toda la actividad de
construccin de los cambios. En cambios grandes o en la creacin de servi-
cios, que se estructuran en forma de proyecto, la coordinacin la realiza el
jefe de proyecto actuando como parte del proceso de gestin del cambio para
esta actividad. En cambios menos complejos, en que no existe la funcin de
jefe de proyecto, es el personal asignado al proceso quien deber realizar la
funcin de coordinacin.
Aprobar la implantacin del cambio. Una vez construido el cambio y acep-
tada la entrega por el jefe de proyecto, se solicita a este proceso que se res-
ponsabilice de los aspectos necesarios para coordinar la implantacin del
cambio.
Controlar la etapa implantacin, que comprende la integracin, pruebas y
despliegue del cambio. Es la responsabilidad nica del proceso de cambio
y todas las actividades restantes, desde la integracin y pruebas, hasta el paso
final al entorno de produccin. Aunque el proceso de cambio delega (pero
supervisa) los trabajos organizativos y tcnicos a realizar para implantarlo al
proceso de gestin de la entrega que a su vez utiliza a las reas tcnicas.
Aprobar el paso a produccin del cambio. Finalizada con xito la etapa de
integracin y pruebas por parte de gestin de la entrega, el gestor del cam-
bio autoriza el paso al entorno productivo en vivo. Tambin es el proceso de
entrega el que realiza esta labor. En esta etapa es importante la estrecha coor-
dinacin de todos los cambios a pasar al entorno productivo para minimizar
el impacto en el negocio con las paradas, as como mantener informados a
los clientes, usuarios y al centro de atencin al usuario.
Evaluar los resultados del cambio mediante la revisin postimplantacin
(PIR) para confirmar que se han cubierto sus objetivos definidos, que los
clientes estn satisfechos con los resultados, y que no se han producido efec-
tos colaterales. Posteriormente se procede al cierre del cambio y a la comuni-
cacin del mismo al cliente.
Gestionar la mejora del proceso. Como todos los procesos, se debe tener en
cuenta el proceso de mejora continua: monitorizar, informar, dirigir la cali-
dad y cumplimiento de lo establecido para el proceso de cambio, comunicar
resultados y establecer las mejoras que se deben realizar (que se incorporarn

en el plan unificado de mejora de la gestin del servicio).
En el caso de cambios normales o menores, este ciclo de vida puede resultar pesado
y poco eficiente, por lo que se debera aligerar eliminando las etapas que no apor-
ten valor.
La solicitud de cambio (RFC, Request For Change)

La solicitud de cambio es el desencadenante principal de la actividad del proceso
de gestin del cambio, y la persona que la realiza es el promotor del cambio.
En los cambios de emergencia, es posible que la RFC se tenga que formalizar a
posteriori, cuando se haya salido de la crisis.
El origen de una RFC puede ser muy distinto, por ejemplo:
La creacin de nuevos servicios o evolucin de los existentes. El desarrollo
de nuevos servicios normalmente requiere cambios en las aplicaciones y en la
infraestructura de TI. En este caso es importante coordinar todo el proceso
con las gestiones de capacidad, disponibilidad y nivel de servicio para asegu-
rar que estos cambios cumplen las expectativas previstas y no deterioran la
calidad de los otros servicios prestados.
La resolucin de incidentes. Gestin del incidente, en su actividad de restau-
rar el funcionamiento normal del servicio tan rpido como sea posible,
puede requerir cambios en la infraestructura de TI. En estos casos, la RFC
debe contener la informacin del incidente relacionado.
La resolucin de problemas. Gestin del problema se encarga de proponer
soluciones a errores conocidos. En la mayora de los casos esta solucin aca-
rrea un cambio en la infraestructura de TI. En este caso, la RFC debe ser
registrada con informacin del error conocido asociado para que, posterior-
mente, pueda ser evaluada correctamente la pertinencia del cambio.
La estrategia empresarial. La direccin puede decidir una nueva direccin
estratgica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o
a la implantacin de un nuevo servicio, etc., y que por regla general, requieren
cambios de hardware, software y/o procedimientos.
Las actualizaciones de software de terceros. Los proveedores pueden dejar de
soportar versiones anteriores de paquetes de software o introducir nuevas ver-
siones con grandes mejoras que recomienden la actualizacin.
El cumplimiento de un imperativo legal. Un cambio de legislacin (como

por ejemplo, la LOPD (Ley Orgnica de Proteccin de Datos de carcter
personal, en Espaa) puede exigir cambios en la infraestructura de TI.
Otro origen. En principio, cualquier empleado, cliente o proveedor puede
sugerir mejoras en los servicios que pueden requerir cambios en la infraes-
tructura.
Se debe definir una estructura y formato para la solicitud de cambio. Segn sea el
tamao del cambio, la informacin a incorporar a la RFC ser ms amplia cuanta
mayor complejidad tenga el cambio para tener un mejor control sobre l. As en
cambios grandes, el jefe de proyecto aadir a la RFC los siguientes documentos:
Una planificacin detallada.
Un estudio de rentabilidad o business case.
Un informe de disponibilidad prevista (PSA).
Un plan de pruebas del cambio.
En la figura 9.2.7 se muestra el contenido tpico de una RFC.

Es importante resaltar que los tipos de cambio pueden ser de muy diversa natura-
leza y complejidad, por lo que la RFC es un documento vivo y que dependiendo
del marco temporal, puede ir evolucionando y completndose con informacin
clave que se vaya obteniendo a lo largo del proceso.
Registro de la RFC
En todos los cambios, la solicitud de cambio es recibida por el proceso de cambio
y desencadena las actividades del ciclo de vida del cambio. La primera de ellas, es el
registro de la RFC que, normalmente, lo realizar el propio promotor del cambio
en la herramienta de gestin del proceso. En el registro se introduce la informacin
inicial de la RFC.
Aceptacin de la RFC
Tras el registro de la RFC se debe evaluar preliminarmente su pertinencia. Una
RFC puede ser rechazada si se considera que el cambio no est justificado o se
puede solicitar su modificacin si se considera que algunos aspectos de la misma
son susceptibles de mejora o mayor definicin. En este caso, la RFC debe ser
Solicitud de cambio (RFC)
Identificador de RFC.
Fecha de solicitud.
Intervinientes en el cambio.
Responsable del cambio/Solicitante del cambio - patrocinador del cambio.
Descripcin del cambio.
Agenda del cambio.
Fecha de implantacin y fechas intermedias relevantes.
Metas y objetivos.
Cul es el estado actual?, Por qu es necesario el cambio? Cul es el resultado
deseado del cambio? Cules son las consecuencias si el cambio es rechazado o
pospuesto?, etc.
Informacin econmica.
Informacin de costes y presupuesto.
Prioridad del cambio.
Planificacin del cambio.
Plan de proyecto de creacin del servicio.
Estimacin de recursos.
Tiempos/Utilizacin de recursos; por ejemplo, los tiempos necesarios para
probar/implementar el cambio.
Impacto del cambio.
Proveer informacin acerca del impacto del cambio (por ejemplo, en la empresa, el
departamento, el sistema). Esta descripcin debe marcar la importancia del cambio
y el riesgo asociado.
Documentacin.
Informacin relevante relacionada con las modificaciones provocadas por el cambio
solicitado.
Consideraciones clave y riesgos asociados.
Circunstancias bajo las que no se recomienda implementar el cambio. Requisitos
previos a la implementacin del cambio.
Riesgos asociados al cambio. Descripcin y aprobacin.
Aprobaciones.
Aprobacin o denegacin de la solicitud de cambio y fecha.
Responsables y firma de los integrantes del CAB intervinientes.
Observaciones/comentarios emitidos en el proceso.
Revisin post implantacin.
Resultado del cambio.
Fecha de la revisin.
Responsables y firma de los encargados de la revisin.
Observaciones/comentarios emitidos en el proceso.
Figura 9.2.7. Formato ejemplo de una solicitud de cambio

devuelta al departamento o persona que la solicit, para que se puedan realizar nue-
vas alegaciones o para que pueda ser modificada.
La aceptacin de la peticin de cambio no implica su posterior aprobacin por el
CAB, es slo indicacin de que se ha encontrado justificado su procesamiento.
Clasificacin del cambio

Tras su aceptacin, la RFC se debe clasificar para asignarla una categora y una
prioridad con el fin de gestionarla de la forma ms eficaz posible.
La categora determina la dificultad, riesgo e impacto del cambio y ser el parme-
tro relevante para determinar la asignacin de recursos necesarios, los plazos pre-
vistos y el nivel de autorizacin requerido para la implementacin del cambio. En
la figura 9.2.8 se describen las categoras habituales.
Categora
Descripcin
del cambio
Un impacto de gran importancia, y/o una cantidad muy grande de

Macro recursos necesarios, o un impacto probable sobre otras partes de la
organizacin.
Mayor Impacto significativo y/o bastantes recursos necesarios.
Menor Slo un impacto de poca importancia, y pocos recursos necesarios.
Un cambio recurrente, bien conocido, para el que existe un procedi-

Preautorizado
miento predefinido a seguir, con un riesgo relativamente bajo.
Figura 9.2.8. Ejemplo de tipos de categoras de un cambio
La categora de un cambio concreto puede ir evolucionando en el tiempo segn la

organizacin vaya adquiriendo experiencia en la ejecucin de ese cambio en parti-
cular. Por ejemplo, un cambio menor que se ha implantado en numerosas ocasio-
nes y para el que se ha desarrollado un procedimiento de implantacin puede ter-
minar convirtindose en un cambio estndar (preautorizado).
La prioridad es el valor dado al cambio (RFC) para indicar su importancia rela-
tiva, al objeto de asegurar la adecuada asignacin de recursos y para determinar el
intervalo de tiempo en el que se requiere una accin. La prioridad depender de:
El impacto. Medida del efecto sobre el negocio que el tiene cambio actual-
mente o podra tener potencialmente. Se relaciona con el grado de incumpli-
miento del SLA. Se puede valorar en funcin de la criticidad para el negocio
del/los servicio/s afectado/s, el nmero de usuarios afectados y su importan-
cia relativa en la organizacin.
La urgencia. Medida de la criticidad para la atencin de un cambio, en fun-
cin de los tiempos lmites que fueron pactados con el negocio. Puede iden-
tificarse con el tiempo disponible para su tratamiento antes de que se llegue
al incumplimiento del SLA. Se puede establecer mediante la estimacin del
tiempo necesario para la resolucin, tomando como referencia los tiempos
de respuesta establecidos en el SLA.
En cualquier caso, los criterios para definir el impacto y la urgencia deberan esta-
blecerse en coordinacin con los responsables del negocio y formalizarse en el SLA.
En la figura 9.2.9 se presentan los tipos de prioridad ms habituales y su corres-
pondencia con el procedimiento aplicable.
Tiempo de
Prioridad Descripcin Procedimiento
atencin
Se necesita una accin inmediata. Puede ser necesa-

rio convocar reuniones urgentes del Comit de cam-
Crtica bios (Comit de Cambios de Emergencia). Puede ser minutos Emergencia
necesario asignar recursos inmediatamente para desa-
rrollar tales cambios autorizados.
Ser asignada la ms alta prioridad en cuanto a

Alta horas Normal
recursos de desarrollo, pruebas e implementacin.
Ser asignada una prioridad media en cuanto a la

Media das Normal
asignacin de recursos.
El cambio es justificable y necesario, pero puede

esperar hasta la prxima entrega o actualizacin
Baja das Normal
programada. Sern asignados unos recursos de
acuerdo con esto.
Figura 9.2.9. Ejemplo de tipificacin de prioridades de un cambio
La clasificacin permite la ejecucin rpida del cambio, las evaluaciones del

impacto, la estimacin de la capacidad de las colas de trabajo y su posterior evalua-
cin del rendimiento y la gestin de la calidad en los resultados.
Reuniones del comit de cambios (CAB, Change Advisory

Board)
Segn se haya establecido en el sistema de gestin de TI (SGSTI) y en la implanta-
cin del proceso, el comit de cambios debe reunirse peridicamente para analizar
y eventualmente aprobar las solicitudes de cambio, y revisar la lista de cambios pla-
nificados (FSC). El papel del CAB es nicamente de asesor al gestor del cambio,
por lo cual la responsabilidad y la decisin final es siempre del gestor del cambio.
Las reuniones del comit de cambios las convoca y lidera el gestor del cambio. El
CAB tiene miembros permanentes (gestores de los procesos: nivel de servicio, dis-
ponibilidad, capacidad, problema, entrega, etc.) y miembros invitados relacionados
con los cambios a tratar (promotores de los cambios, gestor relaciones con el nego-
cio, rea cliente, etc.), tal y como se muestra en la figura 9.2.10.
Una agenda tipo del CAB:

RFC para que CAB la evale.
Lo convoca y lo lidera: Revisiones de los cambios realizados
y en curso. Cambios fallidos.
el gestor del cambio
Evolucin del proceso de gestin del
cambio.
Logros y xitos.
Miembros permanentes:
Gestin de nivel de servicio.
Gestin de la disponibilidad.
Gestin de la capacidad. Miembros invitados:
Gestin del problema. Promotores de los cambios.
Gestin entrega. Gestor relaciones con el negocio.
Gestin centro servicio al usuario. Comit de cambios reas cliente.
reas tcnicas. (CAB) Especialistas.
Figura 9.2.10. Composicin del comit de cambios
La frecuencia y el tipo de reuniones del comit de cambios (presnciales, telefni-

cas, etc.) se deben determinar en funcin del volumen y tipo de cambios que se
vayan a realizar. Estas reuniones representan un consumo de tiempo importante
para sus miembros. Por tanto, se deben establecer medidas para agilizar las reunio-
nes del CAB, como por ejemplo, facilitar el acceso a la documentacin a tratar
antes de la reunin, control estricto del tiempo de la reunin, permitir flexibilidad
para enviar a un representante si el titular no puede asistir, facilitar que algunos
miembros asistan de forma remota (especialmente los invitados que slo deban
participar en un cambio), realizar algunas reuniones por medios electrnicos
no presenciales. En cualquier caso, se recomienda tener peridicamente una reu-

nin presencial del CAB con los miembros permanentes.
El comit de cambios debe incluir representacin de todas las capas tecnolgicas
dentro de TI, adems de representacin de los principales clientes de TI.
En cualquier caso, la aprobacin de los cambios es responsabilidad nica del gestor
del cambio, ya que es el responsable de autorizar o denegar un cambio. De ah la
importancia de seleccionar un profesional adecuado para este rol, ya que debe
conocer con detalle la estructura de los servicios y su impacto en el negocio. Aun-
que parezca poco democrtica, la funcin del CAB es nicamente asesora.
Durante el ciclo de vida del cambio, y segn lo establezca cada organizacin en su
SGSTI, el cambio podr estar sometido a varias aprobaciones. As, en grandes
cambios (macro y mayores), se podra pasar por:
La aprobacin de la construccin del cambio, se debera consultar al CAB.
La aprobacin de la implementacin del cambio, para iniciar la integracin,
pruebas y despliegue a realizar por el proceso de gestin de la entrega, que
realiza tambin el CAB.
La aprobacin del paso a produccin del cambio tomada por el gestor del
cambio, se debera informar al CAB.
La revisin postimplementacin previa al cierre.
Para la aprobacin de la construccin del cambio el gestor del cambio debe eva-
luarlo minuciosamente, especialmente los grandes (de categora macro y mayor)
contemplando:
Cules son los beneficios esperados del cambio propuesto. Revisin del caso
de negocio (business case) presentado por el promotor del cambio.
Justificacin de esos beneficios frente a los costes asociados al proceso de
cambio.
Cules son los riesgos asociados. Revisin del informe de disponibilidad pre-
vista (PSA).
Si se dispone de los recursos necesarios para llevar a cabo el cambio, en forma
y plazo, con garantas de xito.
Prioridad asignada: urgencia, conocer si puede demorarse el cambio e
impacto, cul ser el impacto general sobre la infraestructura y la calidad de
los servicios de TI.
Puede el cambio afectar los niveles establecidos de seguridad de TI?
En el caso de cambios que tengan un alto impacto debe tambin consultarse a la

direccin (CIO), pues pueden entrar en consideracin aspectos de carcter estrat-
gico y de poltica general de la organizacin.
Una vez aprobada la implementacin del cambio (en caso contrario se seguira el
proceso para no aceptacin), la gestin de la entrega debe evaluar si se ha de imple-
mentar aisladamente o integrado en un paquete de cambios, que formalmente
equivaldran a un solo cambio. Esto tiene algunas ventajas:
Se optimizan los recursos necesarios.
Se evitan posibles incompatibilidades entre diferentes cambios.
Slo se necesita un plan de marcha atrs.
Se simplifica el proceso de actualizacin de la CMDB, la DSL y la revisin
postimplementacin.
Mantenimiento de la lista de cambios planificados

(FSC, Forward Schedule of Change)
La planificacin es esencial para una buena gestin de los cambios tanto individuales,
como de todo el proceso en su conjunto. Cada cambio debe tener asociada una pla-
nificacin, que en el caso de los menores puede bastar con una simple tabla de
fechas y duraciones incorporada en la RFC. Pero en cambios macro o mayores,
deben llevar una planificacin detallada de todas las etapas del mismo.
Con todas las planificaciones individuales, gestin del cambio mantiene actualiza-
das las listas unificadas de cambios en curso o lista de cambios planificados (FSC),
que sirve para que toda la organizacin del proveedor de TI conozca la actividad y
planifique sus recursos.
La FSC debera incluir detalles de todos los cambios autorizados, incluyendo los
planes claros a corto plazo y a ms largo plazo. Tambin deberan incluirse los gran-
des planes de transformacin ligados a la estrategia de evolucin prevista para los
prximos dos aos. La FSC debera distribuirse entre las reas cliente, los desarro-
lladores de aplicaciones, el personal de soporte, incluido el centro de servicio al
usuario, y cualquier otra parte interesada.
Construccin del cambio

La construccin del cambio (aplicacin e infraestructura) no la realiza el proceso de
gestin del cambio. Normalmente la realiza el equipo de desarrollo de aplicaciones
y/o la gestin de infraestructuras de TI. Pero el proceso de gestin del cambio debe
realizar una supervisin de esta actividad.
En la fase de construccin del cambio se deber supervisar el proyecto para asegu-
rar que:
Tanto el software desarrollado como el hardware adquirido se ajustan a las
especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignacin de recursos es la adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de pro-
duccin.
Los planes de marcha atrs permitirn la rpida recuperacin de la ltima
configuracin estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de
pruebas para que realicen una valoracin preliminar de los nuevos sistemas
en lo que respecta a su funcionalidad, usabilidad y accesibilidad.
Implementacin de un cambio
La etapa de implementacin corresponde a la integracin del cambio en la infraes-
tructura, a las pruebas finales y al paso al entorno productivo.
Aunque la gestin del cambio no es la encargada directa de implementar el cambio,
algo de lo que se encarga habitualmente la gestin de la entrega (con recursos de
infraestructuras y del propio proyecto) o directamente los equipos tcnicos, s es la
encargada de supervisar y coordinar todo el proceso. Mientras que en ISO/IEC
20000 y en ITIL v2 es el proceso de gestin de la entrega (release management), en
ITIL v3 la implementacin de cambio se realiza bajo el proceso denominado ges-
tin de versiones y despliegues (release and deployment management).
Evaluacin de resultados, revisin postimplantacin (PIR)

y cierre del cambio
Cuando todos los trabajos de implantacin y despliegue se dan por finalizados por
el proceso de gestin de la entrega, se procede a la evaluacin de los resultados del
cambio.
Antes de proceder al cierre del cambio es necesario realizar una evaluacin que permita
valorar realmente si se han cubierto los objetivos establecidos y cul ha sido el impacto
del mismo en la calidad del servicio y en la productividad de la organizacin. Para ello,

se procede a la revisin postimplementacin (PIR, Post Implementation Review).
UNE-ISO/IEC 20000-1
Se debe revisar el xito de todos los cambios y, en caso contrario, se deben decidir y
llevarse a cabo acciones correctivas tras la implementacin.
UNE-ISO/IEC 20000-2
Todos los cambios se deberan revisar c) no ha habido efectos colaterales

en relacin a su xito o fallo despus de inesperados.
la implementacin y cualquier mejora
Toda no conformidad se debera regis-
debera ser registrada. Se debera reali-
trar y tomarse las acciones pertinentes.
zar una revisin despus de la imple-
mentacin en los cambios principales Cualquier debilidad o deficiencia identi-
para comprobar que: ficada en la revisin del proceso de ges-
a) el cambio cumple sus objetivos; tin del cambio, debera alimentar los
planes de mejora del servicio.
b) los clientes estn satisfechos con
los resultados;
La gestin del cambio se encarga de realizar su propia revisin postimplementa-

cin consultando a las partes implicadas, para asegurar que los cambios realmente
han sido satisfactorios. Los aspectos fundamentales que debe tener en cuenta el
PIR son los siguientes:
Se cumplieron los objetivos previstos?
En qu medida se apart el proceso de las previsiones realizadas por la ges-
tin del cambio.
Provoc el cambio problemas o interrupciones del servicio imprevistas?
Cul ha sido la percepcin de los usuarios respecto al cambio?
Se pusieron en marcha los planes de marcha atrs en alguna fase del pro-
ceso? y por qu?
Si la evaluacin final determina que el proceso y los resultados han sido satisfacto-
rios, se proceder al cierre de la RFC.
Marcha atrs de un cambio

Los servicios de TI son muy susceptibles a los cambios en su configuracin, debido
a las sofisticadas interrelaciones entre todos los elementos involucrados. Un cam-
bio aparentemente menor, puede desencadenar una reaccin en cadena con resulta-
dos catastrficos. Es imprescindible, como mnimo, disponer siempre de planes de
marcha atrs (back out) que permitan la recuperacin de la ltima configuracin
estable antes del cambio.
La gestin de la entrega es responsable de definir las polticas de implantacin y des-
pliegue de cambios, y tambin de qu forma se han de realizar los planes de marcha
atrs. La gestin del cambio debe garantizar que todos los cambios son aprobados
con la suficiente documentacin, infraestructura y recursos para que el cambio se eje-
cute con xito. En el caso en que los resultados sean desfavorables, se tendran que
ejecutar los planes de marcha atrs, dentro de la ventana horaria ms favorable al
cumplimiento del plan de disponibilidad y dentro de los lmites concertados.
Una marcha atrs sin un procedimiento especifico o con un cronograma abierto es
muy desaconsejable.
Una vez cerrado el cambio, no se debe realizar una accin de marcha atrs, por el
impacto en otros servicios y en la informacin que manejan. Muy posiblemente,
los datos hayan cambiado y se pierda informacin del negocio. En este caso se
deber realizar una accin correctiva, y posteriormente analizar que fall en la acti-
vidad PIR.
La opinin de los usuarios se debe tener en cuenta, y el cambio debe revisarse en el
caso en el que se encuentren objeciones justificadas (debe tenerse en cuenta tam-
bin la resistencia habitual al cambio).
Cambios de emergencia
Cualquier interrupcin del servicio de alto impacto, ya sea por el nmero de usuarios
afectados o porque se han visto involucrados sistemas o servicios crticos para la orga-
nizacin, debe encontrar una respuesta inmediata adecuada. Es frecuente que la solu-
cin al incidente requiera un cambio urgente, pero hasta las urgencias y las situacio-
nes de crisis, deben estar reguladas mediante un procedimiento de emergencia.
El procedimiento que se debe seguir en estos casos de crisis debe estar debidamente
previsto. Como el objetivo prioritario en estas situaciones crticas es restaurar el
servicio, es a menudo frecuente que los procesos asociados sigan un orden inverso
al usual, realizndose a posteriori tanto en los registros en la CMDB, como en la
documentacin asociada al cambio.
Sin embargo, es esencial que al cierre del cambio de emergencia se disponga de la

misma informacin de la que dispondramos tras un cambio normal.
UNE-ISO/IEC 20000-1
Deben existir polticas y procedimientos para controlar la autorizacin e implemen-

tacin de cambios de emergencia.
UNE-ISO/IEC 20000-2
En ocasiones se requiere la realizacin cambio, el cambio debera cumplir estos

de cambios de emergencia, y cuando requisitos tan pronto como sea posible.
sea posible, se debera seguir el proceso Los cambios de emergencia se deberan
de cambio, aunque algunos detalles se justificar por quien los implementa y
documenten a posteriori. Cuando el pro- deberan ser revisados despus del
ceso de emergencia se salte algunos cambio para verificar que era una ver-
requisitos del proceso de gestin del dadera emergencia.
Un cambio de emergencia requiere, como su nombre indica, una actuacin inme-

diata. Estos cambios provocan trastornos en el ritmo de trabajo de toda la organi-
zacin, desplazamientos de otros cambios y replanificaciones encadenadas, etc. Por
ello, es extremadamente importante reducir el volumen de los cambios de emer-
gencia. Habitualmente muchos de los cambios de emergencia surgen como resul-
tado de una planificacin deficiente o de una organizacin trastabillada. As, una
cuidada planificacin y programacin de los cambios y una buena gestin de los
plazos que necesita el negocio son las palancas de reduccin de este factor.
En un cambio de emergencia, normalmente el CAB no se rene fsicamente, sino
que estn identificados los participantes (normalmente de alto nivel) que asesoran
si se debera llevar a cabo o no. Este subgrupo del comit de cambios, se le suele
denominar CAB de emergencia. Pero como siempre, convocarlo y la aprobacin
es responsabilidad del gestor del cambio.
Informes, anlisis y acciones de mejora

En este caso, la norma nos recuerda la necesidad de medir, analizar y registrar las
conclusiones. Indica que las acciones de mejora del proceso se incorporen en el
plan general de mejora de la gestin del servicio.
UNE-ISO/IEC 20000-1
Los registros de cambios se deben analizar regularmente para detectar incrementos

en el volumen de cambios, tipos recurrentes frecuentemente, tenencias emergentes y
cualquier otra informacin relevante. Los resultados y conclusiones obtenidos a par-
tir del anlisis de los cambios se deben registrar.
Las acciones de mejora identificadas para la gestin del cambio se deben registrar y
debe proporcionar informacin de entrada al plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Los registros de los cambios se deberan informacin relevante. Los resultados y

analizar de forma peridica, para las conclusiones derivados del anlisis
detectar incrementos en el nivel de cam- de los cambios se deberan registrar y
bios, frecuencia de los tipos recurrentes, actuar sobre ellos.
tendencias emergentes y cualquier otra
Es imprescindible elaborar informes que permitan conocer el rendimiento de la

gestin del cambio. Para que estos informes ofrezcan una informacin precisa y
que permita conocer la evolucin a lo largo del tiempo del proceso y de su con-
tribucin al xito de los servicios de TI, es imprescindible elaborar indicadores o
mtricas.
Mtricas del proceso

Las mtricas se deben adaptar a las necesidades de control o de conocimiento que
tenga cada organizacin, aportando informacin sobre el funcionamiento interno
del proceso, cmo el proceso contribuye al xito de los servicios de TI, o el valor
aportado por TI al negocio. Suelen cubrir aspectos tales como por ejemplo, los
siguientes:
El volumen de RFC gestionados, el porcentaje de RFC aceptados y aprobados.
El nmero de cambios realizados distinguiendo entre su prioridad y su cate-
gora.
El tiempo medio de implementacin del cambio dependiendo de su priori-
dad y su categora (plazos de cambios).
El nmero de cambios de emergencia realizados.
El porcentaje de cambios con xito en una primera instancia, en una segunda

instancia, etc.
El nmero de operaciones de marchas atrs que se han tenido que realizar,
con una detallada explicacin de las mismas.
Los resultados de las evaluaciones postimplementacin.
El porcentaje de cambios cerrados sin incidencias posteriores.
La cantidad de incidencias asociadas a cambios realizados.
El nmero de reuniones realizadas por el CAB, con informacin estadstica
asociada: nmero de asistentes, duracin, nmero de cambios aprobados por
reunin, etc.
En el grfico de la figura 9.2.11 se muestra una visin muy parecida a la anterior,

proveniente de un resumen de los indicadores ms relevantes para este proceso
seleccionados por un grupo de trabajo de itSMF Espaa.
de itSMF Espaa
Roles participantes en la gestin del cambio

Como en el resto de los procesos, los roles intervinientes en la gestin del cambio
se estructuran en: los roles propios del proceso y los roles ajenos al proceso.
El gestor del cambio (gestor del proceso o process manager), que es el respon-
sable del da a da de la actividad del proceso. En este caso, aprueba los cam-
bios, convoca y lidera el CAB, etc.
Los promotores de los cambios son el personal de desarrollo, el de infraes-
tructuras y los tcnicos o gestores de los procesos que realizan la solicitud del
cambio.
Los administradores o el personal de soporte al proceso, ayudan al gestor
del cambio en el control de toda la actividad.
Los jefes de los proyectos de desarrollo o de infraestructuras que controlan
todas las actividades asociadas a los cambios grandes.
Los especialistas tcnicos.
se representan en el grfico de la figura 9.2.12.
Resumen
La necesidad de continua evolucin de las tecnologas de la informacin requiere
una actividad constante de cambios en las infraestructuras y en los desarrollos para
permanecer actualizado y evitar que los servicios se queden obsoletos.
El proceso de gestin del cambio es clave para mantener la estabilidad de los
servicios, pues regula y controla toda actuacin sobre ellos. El proceso necesita
Roles del proceso
Responsable de la
gestin del servicio
Promotores
Gestor
o solicitantes
del cambio
SGSTI de los cambios
Propietario del
modelo (SGSTI)
Comit de cambios
(CAB)
Administrador y
Especialistas soporte del proceso
tcnicos del cambio
Figura 9.2.12. Roles del proceso de gestin del cambio
la informacin de la gestin de la configuracin para determinar con precisin

el impacto del cambio, y por otra parte, garantiza que la informacin sobre los
servicios modificados permanece actualizada.
El proceso mantiene la fiabilidad de los servicios. Debe velar por que la actividad
evolutiva o correctiva de los mismos se realice con un consumo de recursos ade-
cuado, y debe contribuir a la agilidad evolutiva de la organizacin y al cumpli-
miento de los plazos de los cambios.
Los principales elementos que intervienen en el proceso son el responsable de cam-
bios, la solicitud de cambio (RFC), el comit de cambios (CAB), la lista de cambios
planificados (FSC), la clasificacin de un cambio, los cambios de emergencia y la
revisin postimplementacin (PIR).
El proceso controla y supervisa tanto la construccin del cambio como su imple-

mentacin, pero no realiza este trabajo, que lo asumen los equipos tcnicos
actuando bajo el proceso de la gestin de la entrega.
Beneficios
Los principales beneficios derivados de una correcta gestin del cambio son los
siguientes:
Se reduce el nmero de incidentes y problemas potencialmente asociados a
todo cambio. Por lo tanto, se reduce el riesgo asociado a los cambios.
Se reducen los plazos medios en la implantacin de los cambios.
La organizacin realiza los cambios con ms eficiencia.
Se reduce el impacto en el negocio debido a las paradas asociadas a los
cambios.
Se puede retornar a configuraciones estables de manera sencilla y rpida en el
caso en el que el cambio tenga un efecto negativo.
Se reduce el nmero de operaciones de marcha atrs necesarias.
Los cambios son mejor aceptados y se evitan tendencias inmovilistas.
Se evalan los verdaderos costes asociados al cambio y, por tanto, es ms sen-
cillo valorar el retorno real de la inversin.
La CMDB y la DSL estn correctamente actualizadas, algo imprescindible
para la correcta gestin del resto de los procesos de TI.
Se reducen las actuaciones de emergencia y el trastorno que ocasionan en el
trabajo diario.
Se desarrollan procedimientos de cambio estndar que permiten la rpida
actualizacin de sistemas no crticos.
Cite tres ejemplos en su organizacin de cambios pre-autorizados, de
cambios mayores y de cambios de emergencia.
Por limitacin de recursos, debe escoger slo 3 procesos para imple-
mentar en primer lugar. Si uno de ellos es gestin del cambio, qu
otros dos procesos implementara en su organizacin?
Qu aspectos de lo descrito en este apartado no se adaptan bien a
su organizacin? Por qu?
1
10 Proceso de gestin
de la entrega
Captulo 10
10.1. Gestin de la entrega


10. Procesos de gestin de la entrega 695
La mayor cantidad de fallos en los servicios viene generada por errores en los cam-
bios e implantaciones, tanto por defectos en su construccin como por errores en
las operaciones que conlleva la puesta en explotacin. Pero las organizaciones de TI
deben mantener un ritmo constante de cambios y de creacin de nuevos servicios
para responder de una forma gil a las necesidades del negocio.
Realizar cambios en los servicios no es tarea sencilla, tanto por la cantidad de com-
ponentes hardware y software, como por el nmero de suministradores que entran
en escena para mantener los servicios de TI. Adems, se requiere que los servicios
evolucionen sin interferir en la produccin normal, manteniendo los niveles de servi-
cio acordados y garantizando los tiempos comprometidos, no slo para las tareas
identificadas del despliegue, sino tambin para los plazos que marca el negocio
(time to market).
La importante misin de introducir cambios se realiza mediante dos procesos: la
gestin del cambio y la gestin de la entrega. Si la gestin del cambio pone control
y orden en todas las peticiones de cambio, bajo el concepto del proceso de entrega,
se agrupan las actividades operativas necesarias para que el cambio se ponga en el
entorno productivo, minimizando el riesgo de fallos y maximizando la eficiencia de
las tareas que se deben llevar a cabo.
Las Normas ISO/IEC 20000 dedican la mayor extensin de requisitos y recomen-
daciones a este proceso. El xito en este proceso de entrega vendr dado por la uti-
lizacin de unos procedimientos y tareas bien desarrollados y controlados, que per-
mitan una gestin correcta de los recursos puestos a disposicin del proceso, y la
optimizacin y mejora del mismo.
Un proveedor de TI de tamao medio suele realizar entre 70 y 100 cambios sema-
nales en sus servicios. Adems de esto, cada servicio operativo suele tener dos o tres
grandes versiones al ao. Para complicarlo an ms, muchos estos cambios se debe-
rn realizar fuera de la jornada laboral. Por tanto, la realizacin de una forma segura
y eficiente de las tareas de implementacin de los cambios resulta esencial para la
calidad de los servicios y para la tranquilidad de todos. En este captulo encontrar
las prcticas ms avanzadas para lograrlo.
10. Procesos de gestin de la entrega
10.1. Gestin de la entrega 697
10.1. Gestin de la entrega
Figura 10.1.1. Esquema general del proceso de la gestin de la entrega
El nombre del proceso de gestin de la entrega, del trmino ingls release manage-
ment, ha tenido mltiples traducciones al castellano. Tambin se le conoce como
gestin de despliegues, gestin de versiones, gestin de lanzamientos, gestin de
despliegue de versiones, etc. En ISO/IEC 20000 e ITIL v2 se ha traducido como
gestin de la entrega, mientras que en ITIL v3 adopta el nombre de gestin de des-
pliegues y versiones (release and deployment management) 1.
La gestin de la entrega ejecuta las acciones a realizar para producir el cambio auto-
rizado.
Los cambios se convierten en entregas una vez que han sido construidos y ha sido
aprobada su transicin, por ello, toda entrega ha tenido que pasar primero por la
gestin del cambio. El proceso se activa con la recepcin de la peticin de cambio
aprobada (RFC) y de los elementos a instalar. Desde este momento hasta que el
cambio ha sido incorporado a la produccin normal, es necesaria la intervencin
1
Vase la terminologa acordada por el sector en www.itsmf.es
de numerosas reas y especialidades diferentes. En entregas grandes, el proceso

involucra a casi toda la organizacin, inicindose en las reas clientes, pasando por
desarrollo y terminando en las diversas especialidades tcnicas necesarias, sin olvi-
darse de los suministradores que deben intervenir.
Lo primero que se debe tener en cuenta a la hora de planificar este proceso, es la com-
plejidad de los sistemas y servicios que se utilizan en las organizaciones. La consolida-
cin de servidores, la virtualizacin o las arquitecturas orientadas a servicios (SOA),
promueven una sana reutilizacin de infraestructuras y componentes, para aumentar
la eficiencia y agilidad del proveedor de TI, pero hacen ms compleja la implementa-
cin de los cambios. Un componente puede formar parte de muchos servicios, intro-
ducir un cambio en l se hace ms complejo, tanto por tener que comprobar su
impacto en todos los servicios que lo utilizan como por evitar paradas en los mismos.
La gestin de la entrega es el proceso, dentro de la gestin de servicios TI, con la res-
ponsabilidad de la puesta en produccin de los cambios, minimizando el riesgo. En la
figura 10.1.2 se presenta una visin introductoria al proceso de gestin de la entrega.
Sin una correcta coordinacin de la entrega y sin un proceso fiable y gil que lo
soporte, el riesgo de fracaso es alto. Esto se traduce en la no disponibilidad de las

entrega Orden y eficiencia en el trabajo
continuo de implementar los cambios.
Planificacin actualizada de todas los
Definicin:
entregas a implementar.
Proceso que organiza y controla los Integracin de los desarrollos en el
pasos al entorno de produccin de los entorno productivo.
cambios aprobados.
Mayor control de la calidad de los
cambios implementados, mediante
Objetivo: pruebas.
Entregar, distribuir y realizar el Informacin actualizada sobre lo

seguimiento de uno o ms cambios en el instalado en produccin.
entorno de produccin real. Colabora en el control de las versiones
del software instalado.
Calidad en las actuaciones al disponer
de informacin precisa.
Control del almacn de componentes
hardware.
Figura 10.1.2. Introduccin al proceso de gestin de la entrega

aplicaciones en explotacin, en el descontrol en los trabajos internos en TI y en las

consiguientes prdidas econmicas para el negocio al que se presta el servicio.
Para conseguir el objetivo del proceso, se debe controlar mediante pruebas todo lo
construido, velar por la eficiencia en la actividad de implementacin, mantener una
planificacin y orden en las actuaciones, gestionar con rigor el almacenamiento de
hardware y velar por que la informacin sobre la configuracin no se desactualice
con los cambios. La figura 10.1.3 muestra estos principios bsicos en los que se
sustenta el proceso.
El primer principio del proceso es el control de lo que se ha construido y que se va a

proceder a implantar. Es fundamental controlar y gestionar todos los componentes
que forman parte de una entrega, adems de identificar qu poltica y periodicidad
se va a aplicar en el proceso. Tambin es necesario dejar definido el procedimiento
para la gestin de entregas de emergencias (procedentes de cambios de emergencia).
Con el fin de controlar todos los cambios construidos, la gestin de la entrega lleva
a cabo la planificacin, diseo, configuracin y pruebas del hardware y software para
crear un conjunto de componentes funcionando en produccin.
El orden y la planificacin son esenciales debido a que en el ciclo de cada entrega
se debe movilizar personal de diversas reas de la empresa y de los suministradores,
como el cliente, el jefe de proyecto, el equipo de desarrollo, el grupo de soporte al

desarrollo, el grupo de pruebas, los tcnicos de producto, los tcnicos de middle-
ware, los tcnicos de sistemas operativos, los tcnicos de servidores, los tcnicos de
almacenamiento, los expertos de las redes del centro de datos, los expertos en segu-
ridad, los encargados de la distribucin fsica del centro de datos, los suministrado-
res de servicios y productos relacionados, etc.
La eficiencia en las implantaciones es otro de los principios bsicos en los que se
debe sustentar el proceso, pues el proceso de la implantacin de los cambios, junto
con el de la resolucin de incidentes, es uno de los procesos que ms recursos
demandan de la organizacin de produccin. Tiene un impacto directo en la agili-
dad de TI ante el ritmo del negocio y en la credibilidad por el cumplimiento de los
plazos comprometidos.
Este proceso tambin es responsable de que toda la informacin relativa a las modi-
ficaciones est correctamente actualizada, principalmente en la CMDB y en la
DSL, encargndose de que se actualice en el resto de soportes de informacin
(manuales para el centro de atencin al usuario, manuales de usuario, manuales tc-
nicos, etc.).
Hasta que alguien no se haya pasado horas, e incluso das, buscando, por ejemplo,
una simple tarjeta fiber channel, en una catica sala de almacn de 200 m2, repleta
de cajas semivacas, de equipos nuevos a instalar, de equipos retirados, de repues-
tos, de pals, etc., no apreciar la importancia de mantener organizado el almacn
de componentes de hardware. Por ello, el ltimo de los pilares de este proceso es el
rigor en la gestin del almacn de componentes de hardware para que est siempre
ordenado y su contenido identificado e inventariado, con el fin de suministrar
los componentes necesarios y gestionar la recepcin de las mercancas asociadas a los
proyectos.
La gestin de la entrega interviene en todos los cambios que se vayan a implantar,
ya sean grandes o pequeos, urgentes o planificables, como son:
Cambios grandes o crticos de plataformas hardware.
Despliegues de cambios en las plataformas de los usuarios: PC, PDA, telfo-
nos inteligentes, etc.
Despliegues de cambios en las plataformas de servidores. Actualizacin
de versiones del sistema operativo o de productos software. La instalacin de
parches de seguridad en la plataforma de servidores es una actividad cada
vez ms frecuente y que requiere una dedicacin importante de recursos.
Cambios importantes en el software.
Multitud de cambios pequeos, que se tendern a agrupar o asociar en uni-

dades de un tamao manejable.
Cambios urgentes.
Despliegue
(automatizacin)
Poltica
de entregas
Planificacin
de la entrega
Metodologa
de pruebas
Plataformas
de pruebas
e integracin
Entrega
CMDB DSL
Lista de cambios Base de datos Biblioteca de Almacn definitivo
planificados (FSC) de gestin de software definitivo de hardware
la configuracin
Figura 10.1.4. Componentes principales del proceso de gestin de la entrega

Los componentes que intervienen en el proceso de gestin del incidente son los
siguientes.
Almacn de Hardware Definitivo (DHS). Uno o varios emplazamientos dis-
puestos para el almacenamiento seguro de componentes y repuestos de hardware.
Estos componentes se gestionan con el mismo nivel que los elementos de configu-
racin hardware equivalentes del entorno de produccin. El mantenimiento com-
pleto del DHS es responsabilidad directa del proceso de gestin de la entrega. En
ITIL v3, en el proceso de gestin de la configuracin se habla del almacenamiento
de los recambios o repuestos definitivos (DS, Definitive Spares).
Base de Datos de Gestin de la Configuracin (CMDB). Base de datos gestio-
nada por el proceso de gestin de la configuracin y que el proceso de gestin de la
entrega debe actualizar con los cambios a los elementos de configuracin (CI) que
realice de forma coordinada con gestin de la configuracin.
Biblioteca de Software Definitivo (DSL). La gestin de la entrega debe actuali-
zar este repositorio con las ltimas versiones del software implementado en produc-
cin, as como con la parametrizacin realizada y la documentacin asociada. En
ISO/IEC 20000 la responsabilidad de este repositorio recae en gestin de la confi-
guracin. Por tanto, al igual que en el caso de la CMDB, cualquier actualizacin en
esta biblioteca debe estar coordinada con el proceso de gestin de la configuracin.
Despliegue. Es la accin de poner en produccin el conjunto de cambios que con-
tiene una entrega. Es importante poner foco en la automatizacin de este proceso
mediante el uso de las herramientas tcnicas adecuadas.
Entrega. Es un conjunto de cambios aprobados en un servicio TI, que se prueban
e introducen como conjunto en el entorno de produccin. Consta del software
nuevo o modificado y del hardware nuevo o modificado. Se define por las RFC que
implementa. La entrega se caracteriza por:
Unidad de entrega. Porciones de los servicios que normalmente se imple-
mentan a la vez. Generalmente, esta unidad es variable, dependiendo de los
tipos de elementos de software y hardware implicados
Tipo de entrega. Se definen varias categoras de entregas en funcin del
impacto (mayores y menores), la urgencia (normales y emergencia) y la tasa de
renovacin de elementos de configuracin (completas, delta y empaquetadas).
Identificacin de la entrega. Las entregas deben estar identificadas unvo-
camente de acuerdo a un esquema definido en la poltica de entregas. Debe
incluir una referencia al servicio o elemento de configuracin que representa
y un nmero de versin de hasta tres niveles (por ejemplo, servicio_
nomina_V2.3.6).
Herramienta de gestin de la entrega. Es la aplicacin y bases de datos que dan

soporte informtico al proceso. Muchas veces se integra con la herramienta de ges-
tin del cambio.
gramacin unificada de todos los cambios en curso, que recoge los detalles de los
cambios cuya implantacin haya sido aprobada, as como, las fechas propuestas
para tal implantacin. La responsabilidad del mantenimiento de esta lista es del
proceso de gestin del cambio, pero gestin de la entrega debe responsabilizarse de
su actualizacin segn se vaya avanzando en las entregas. En ITIL v3 se ha supri-
mido la palabra forward denominndose ahora change schedule.
Metodologa de pruebas. Sistemtica de trabajo documentada que detalla todas las
pruebas necesarias que se deben realizar en todas las etapas por las que pasan los
cambios que contiene una entrega, desde las pruebas durante la fase de construc-
cin, las pruebas en la fase de implementacin (integracin o transicin) hasta las
pruebas de aceptacin final del cambio. La metodologa de pruebas es un docu-
mento nico utilizado tanto para las pruebas en construccin, como para la entrega.
La gestin de la entrega es la encargada de la implementacin y control de calidad
de todo el software y hardware instalado en los entornos de desarrollo, preproduc-
cin y produccin.
Una alternativa, utilizada en ocasiones para validar el correcto funcionamiento
antes de desplegar y abrir el servicio a todos los usuarios, es la puesta en marcha de
lo que se denomina piloto en produccin. Este piloto estara formado por un redu-
cido grupo de usuarios reales durante un corto espacio de tiempo. Esto ser posi-
ble siempre que los sistemas en explotacin y el que se est probando, permitan una
conciliacin de los datos y resultados.
Planificacin de una entrega. Cada entrega lleva una planificacin especfica y
detallada, que se va completando segn avanza el conocimiento de las actividades
que se van a realizar. La planificacin de la entrega recoge todas las actividades que
se van a realizar con el conjunto de cambios (RFC) que contiene. En el caso de
grandes proyectos (nuevos o modificaciones), la planificacin de la entrega es una
parte de la planificacin global del proyecto. La planificacin tambin recoge minu-
ciosamente la etapa crtica del paso a produccin, en la que se debe reflejar hasta el
ms mnimo detalle de las acciones que se van a realizar, las personas que intervie-
nen y la franja horaria de cada intervencin.
Plataformas de pruebas e integracin. Equipamientos informticos que replican
las condiciones del entorno productivo en vivo. Dependiendo de la criticidad y
complejidad de los servicios, la plataforma de pruebas y la de integracin sern dis-
tintas o las mismas. En la plataforma de integracin (o preproduccin) se realizan
la conexin del aplicativo software con el entorno real (reglas del firewall, segmenta-
cin de VLAN, integracin con el middleware, automatizacin de tareas batch, inte-
gracin en la monitorizacin, integracin en el backup, etc.) para poder comprobar
su correcto funcionamiento antes del paso a produccin regular.
Poltica de entrega. Define las funciones y responsabilidades principales de la ges-
tin de la entrega. Establece las pautas en toda la organizacin para la implementa-
cin de los cambios. Normalmente se suelen definir tres o cuatro grandes ciclos de
entrega anuales, que regula todo el mantenimiento evolutivo y correctivo de las
aplicaciones. Los cambios que no pueden asociarse a estos ciclos anuales, se gestio-
nan al detalle intentando agruparlos o empaquetarlos. La poltica de entrega debe
incluir tambin la numeracin, frecuencia de las entregas y el nivel de infraestruc-
tura TI comprendido en las entregas. La poltica de entrega es parte del plan del
proceso de gestin de la entrega.
Revisin (PIR, Post Implementation Review). Comprobacin tcnica y funcional
que se realiza transcurrido un determinado perodo de tiempo tras la implantacin
de la entrega y cuyo objetivo es el de validar si los efectos de los cambios han sido
los deseados, para proceder al cierre definitivo de la entrega y, consecuentemente,
de los cambios que alberga. La realiza el proceso de gestin de la entrega, la lidera
el gestor del cambio.

Las interacciones y funcionalidades de la gestin de la entrega se resumen en la
figura 10.1.5.
El inicio de la actividad de una entrega viene desencadenado por la aprobacin de
la etapa de transicin de una o varias RFC, lgicamente las peticiones de cambio a
implantar van acompaadas de los elementos que componen el cambio. Adems, el
proceso utiliza como entradas de soporte la FSC, la CMDB, la DSL y la base de
datos de gestin del cambio.
Las principales actividades de la gestin de la entrega se resumen en:
Establecer una poltica de implementacin de las entregas, que marque el
ritmo con el que toda la organizacin construya y evolucione los servicios,
definiendo la frecuencia y el tipo de las entregas.
Gestionar el ciclo de vida completo de las entregas, desde su planificacin
detallada, pasando por las pruebas, hasta el despliegue en produccin.
Actualizar la lista de cambios planificados (FSC).
Desencadenantes 3 Definicin de la poltica de Salida principal:

del proceso: entrega. Entrega implementada:
RFC con la transicin 3 Gestionar el ciclo de vida FSC actualizado.
autorizada por completo de las entregas, desde
DSL actualizada.
gestin del cambio. el RFC aprobado hasta su cierre.
CMDB actualizada.
Los elementos que Actualizar la lista de cambios
componen el cambio planificados (FSC). PIR enviado a gestin
construido. del cambio.
Actualizar la CMDB y la DSL.
Almacn de HW
Entradas del soporte: 3 Actuacin en entregas de gestionado (DHS).
FSC anterior. emergencia.
Salidas secundarias:
DSL. 3 Gestionar el almacn de
hardware (DHS). Informes de errores en
CMDB.
las pruebas.
DHS. 3 Supervisin funcionamiento del
proceso. Mejora del proceso. Propuesta de actividades
BD de gestin para la mejora del
del cambio. 3 Informes y anlisis sobre las
servicio.
actividades del proceso.
Asegurar, en colaboracin con la gestin del cambio y gestin de la configu-

racin, que todos los cambios se ven correctamente reflejados en la CMDB.
Archivar copias idnticas al software en produccin, as como, de toda su
documentacin asociada, en la biblioteca de software definitivo (DSL).
Actuacin ante las entregas de emergencia, provenientes de cambios de
emergencia.
Gestionar y mantener actualizado el almacn de repuestos hardware o Alma-
cn de hardware definitivo (DHS).
Supervisin del correcto funcionamiento de todo el proceso. Realizacin de
las propuestas de mejora al plan unificado de mejora del servicio (vase el
captulo 4).
Realizacin de informes y anlisis sobre las actividades del proceso.
La salida principal del proceso es la implementacin de la entrega con xito y

cerrada mediante la revisin postimplementacin (PIR) que se enva a la gestin
del cambio. Tambin se obtiene el almacn de hardware gestionado y actualizado,
la planificacin de cambios (FSC), la biblioteca de software definitivo (DSL) y la

base de datos de gestin de la configuracin (CMDB).
Como otras salidas se obtienen:
Plan de gestin de la entrega.
Plan detallado de la poltica de entrega, procedimientos, responsables, res-
tricciones y dependencias, etc.
Comunicacin al proceso de gestin de la configuracin.
Comunicacin al proceso de gestin del cambio.
El contenido del registro de la entrega: resultados de las pruebas, aceptacio-
nes, implementacin, etc.
Comunicacin a gestin de la capacidad.
Informes que se soliciten.
Informes de errores en las pruebas.
Informes para la evaluacin y mejora continua del proceso y para el segui-
miento y monitorizacin peridico del proceso.
Y una propuesta de actividades para la mejora del servicio.
La entrega
Se define como entrega a una coleccin de hardware, software, documentacin,
procesos u otros componentes requeridos para implementar uno o ms cambios
aprobados a los servicios de TI. Los contenidos de cada entrega son administrados,
probados e implementados como una nica entidad (Glosario ITIL v3, OGC).
Las entregas se suelen clasificar segn su impacto en la infraestructura TI, en las
siguientes categoras:
Entregas mayores. Representan importantes despliegues de software y hard-
ware, y que introducen modificaciones importantes en la funcionalidad,
caractersticas tcnicas, etc.
Entregas menores. Suelen implicar la correccin de errores conocidos pun-
tuales. Su tamao reducido no exime que se implementen de una manera
procedimentada y correctamente documentada.
En funcin de la urgencia para su implantacin:

Entregas normales. Siguen el ciclo de vida de la entrega y van ordenadas
por su categora y prioridad.
Entregas de emergencia. Modificaciones muy urgentes que reparan de

forma inmediata un error conocido grave. Estas entregas se caracterizan por
la rapidez de actuacin necesaria, lo cual no exime de obtener los permisos y
aprobaciones establecidos para los cambios de emergencia/urgencia. Una vez
pasada la urgencia, se proceder a adecuar y completar la documentacin y
el resto de acciones que hubiera que haber realizado si no se hubiera actuado
de emergencia (CMDB, DSL, etc.).
Atendiendo a la tasa de renovacin de los elementos de configuracin de un servi-

cio, las entregas se dividen en los tipos siguientes:
Entregas completas. Renuevan todos los elementos de configuracin a la
vez, por lo que no hay problemas de inconsistencias entre los componentes
nuevos o modificados y los antiguos del servicio.
Entregas delta. nicamente se renueva una parte de la funcionalidad, y slo
se incluyen en la entrega los elementos de configuracin afectados para la
modificacin realizada.
Entregas empaquetadas. Son agrupaciones de cambios (completos o delta)
con el fin de reducir el nmero de veces que se realizan cambios en el entorno
productivo. En algunos casos esta opcin es obligada por incompatibilidades
entre una nueva versin con software o hardware previamente instalado. Por
ejemplo, en la migracin a un nuevo sistema operativo que requiriese hard-
ware ms avanzado y/o nuevas versiones de los programas ofimticos.
Es necesario establecer unas reglas de numeracin de las diversas versiones de los

elementos de configuracin. El sistema universalmente aceptado es, utilizar una
codificacin alfabtica para identificar el elemento de configuracin y una num-
rica de tres niveles para la secuencia de versiones por las que pase el elemento.
En un instante determinado un elemento de configuracin puede tener simultne-
amente varias versiones en diversas fases de su ciclo de vida: desarrollo, pruebas,
produccin y archivado.

La planificacin e implementacin del proceso de la entrega la realizar el mismo
equipo especialista en procesos TI que se encarga de la definicin de las formas de
trabajar en toda la organizacin. La implementacin del proceso forma parte de la
implementacin de sistema de gestin de TI (SGSTI, vase el captulo 3). La imple-
mentacin del SGSTI y, por ende de este proceso, se realizar siguiendo el rigor del
ciclo PDCA establecido en el proceso de implementacin de la gestin del servi-

cio (vase el captulo 4). Este equipo de procesos colaborar estrechamente con el
futuro responsable de gestin de la entrega. A este respecto, las Normas ISO/IEC
20000 establecen un marco de actuacin.
UNE-ISO/IEC 20000-1
Nota: El proceso de gestin de la entrega se debera integrar con los procesos de gestin de la configu-
racin y de gestin del cambio.
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cmo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
UNE-ISO/IEC 20000-2
La gestin de la entrega debera coordi- entrega, por ejemplo: procesos de

nar las actividades del proveedor del negocio, documentos de soporte y
servicio, los diferentes proveedores y el acuerdos de nivel de servicio.
negocio para planificar y desplegar una Se debera evaluar el impacto de todos
entrega a lo largo de un entorno distri- los elementos de configuracin nuevos
buido. o cambiados requeridos para efectuar
Son esenciales una buena planificacin los cambios autorizados.
y gestin para empaquetar y distribuir El proveedor del servicio se debera ase-
una entrega con xito, y para gestionar gurar de que los aspectos tcnicos y no
los impactos y riesgos asociados para el tcnicos de la entrega son considerados
negocio y para TI. Se debera planificar conjuntamente.
con el negocio la entrega de los siste-
Los elementos de la entrega se deberan
mas de informacin, infraestructuras,
poder ser trazables y no modificables.
servicios y documentacin afectados.
Solo se deberan aceptar en el entorno
Todas las actualizaciones asociadas a la de produccin las entregas adecuadas,
documentacin se deberan incluir en la probadas y aprobadas.
Los principales aspectos que se deben tener en cuenta en la implementacin del

proceso son los siguientes:
Un firme compromiso de la organizacin con la gestin de la entrega y sus
responsables.
Una clara asignacin de responsabilidades para que la organizacin de TI

acepte sin dudas la figura del gestor de la entrega dominante en todo el pro-
ceso de implementacin del cambio.
La adopcin de una metodologa de desarrollo que regule todo el ciclo de
construccin.
La adopcin de una metodologa de gestin de proyectos eficiente que
armonice las actividades de desarrollo de software y de construccin de
infraestructuras.
La adopcin de un modelo de documentacin estructurado que se convierta
en una ayuda online para toda la organizacin.
La necesidad de definir una poltica de entrega que marque el ritmo de cons-
truccin en toda la organizacin.
La existencia de entornos de pruebas e integracin reales y vlidos que per-
mitan la extrapolacin de datos de forma emprica, para garantizar el com-
portamiento del despliegue en produccin.
La realizacin de pruebas de capacidad y de regresin en las nuevas versio-
nes de software y hardware, para lo cual es necesario el soporte de las herra-
mientas tcnicas adecuadas.
La posible necesidad de crear un almacn organizado de hardware.
Las herramientas de soporte a la gestin de la entrega. Habitualmente se uti-
liza integrada con la herramienta de gestin del cambio.
La necesidad de herramientas tcnicas para automatizar los despliegues en la
plataforma de PC, en los dispositivos de mano de los usuarios y en los servi-
dores.
La resistencia de la organizacin a cumplir la poltica de entrega, introdu-
ciendo los cambios por el procedimiento de emergencia.
Un adecuado plan de comunicacin que informe a todos los responsables y
usuarios de la organizacin TI de las ventajas de una correcta gestin de todo
el proceso de cambio.
La implementacin sincronizada de versiones en entornos altamente distri-
buidos.
Los costes originados para la gestin habitual del proceso:
De personal y servicios para mantener los entornos, integracin, prepro-
duccin o pruebas.
Del almacn definitivo de hardware (DHS).

Coste de hardware y herramientas software, as como su soporte.
En la implementacin del proceso hay que considerar las relaciones con otros pro-
cesos. La gestin de la entrega, est estrechamente ligada con la gestin de la confi-
guracin y la gestin del cambio:
Gestin de la configuracin, para asegurar que toda la informacin relativa a
las nuevas versiones se integra adecuadamente en la CMDB, de forma que
sta se halle correctamente actualizada y ofrezca una imagen real de la confi-
guracin de la infraestructura TI.
Gestin del cambio: la gestin de la entrega tiene la responsabilidad de
implementar las entregas acordadas por el comit de cambios. La gestin del
cambio es la encargada de aprobar y supervisar todo el proceso, pero es tarea
especfica de la gestin de la entrega el disear, poner a prueba e instalar en
el entorno de produccin los cambios preestablecidos.
La gestin de la entrega tambin debe mantener actualizada la Biblioteca de soft-

ware definitivo (DSL), donde se guardan copias de todo el software en produccin,
y el Almacn de hardware definitivo (DHS), donde se almacenan los equipos a ins-
talar y las piezas de repuesto para la rpida reparacin de problemas de hardware en
el entorno de produccin.
Tambin se relaciona con otros procesos, como con el proceso de gestin de sumi-
nistradores que tiene como objetivo gestionar los suministradores para garantizar
la provisin sin interrupciones de servicios de calidad.
Poltica de entrega
La principal misin de la poltica de entrega es que toda la organizacin entienda y
asuma la funcin de la entrega y su alto nivel de implicacin y responsabilidad en la
construccin y evolucin de los servicios, una vez aprobados por la gestin del
cambio. La poltica de entrega se debe realizar alineada con la poltica de construc-
cin de servicios y la estrategia de TI.
UNE-ISO/IEC 20000-1
Se debe documentar y acordar la poltica de entrega que establezca la frecuencia y

el tipo de las entregas.
UNE-ISO/IEC 20000-2
Debera existir una poltica de entrega

que incluya: e) una aproximacin en torno a la
agrupacin de los cambios en
a) la frecuencia y tipos de entregas; una entrega;
b) los roles y las responsabilidades f) una aproximacin para la auto-
para la gestin de la entrega; matizacin de los procesos de
c) la autoridad para pasar la entrega construccin, instalacin, y distri-
a los entornos de pruebas de acep- bucin de la entrega para ayudar
tacin y de la produccin; a su repetibilidad y a su eficiencia;
d) una identificacin y descripcin g) la verificacin y la aceptacin de
nica para todas las entregas; una entrega.
La poltica de entrega define para toda la organizacin la forma en que se construi-

rn e implementarn los cambios correctivos y evolutivos de los servicios. La pol-
tica de entregas contiene las directrices que se deben cumplir, tanto por los partici-
pantes en el proceso, como por el resto de la organizacin. Tambin define la
numeracin y frecuencia de las entregas, los criterios para las entregas de emergen-
cia, etc.
La poltica de entrega forma parte de la planificacin e implementacin del proceso
de entrega. Vela especialmente por el equilibrio entre la necesidad de unos plazos
adecuados de evolucin, la estabilidad de los servicios, la carga de trabajo de la
organizacin de TI y los costes.
Las organizaciones ms avanzadas definen tres o cuatro ciclos anuales de puesta en
produccin en los que se agrupa toda la entrega del software y hardware evolutivo y
correctivo. En un momento determinado del tiempo, puede existir un ciclo en fase
de diseo, otro en construccin y otro en pruebas. As, los grandes pasos a produc-
cin slo se realizan en tres o cuatro momentos pactados del ao. Con esto se con-
sigue que la organizacin de TI trabaje de una forma sncrona.
En la figura 10.1.6 se presentan las directrices para el diseo de la poltica de
entrega.
Ciclo de vida completo de una entrega

La gestin de la entrega ejecuta todas las actividades necesarias para llevar a cabo
con xito y eficiencia la implantacin de los cambios.
Poltica de entrega
Objetivo del proceso.

Alcance dentro de la organizacin de TI.
Requisitos esperados del proceso.
Alineamiento con la estrategia de TI y la
poltica de construccin de servicios.
Relacin con desarrollo y gestin del cambio.
Metodologa de pruebas.
Frecuencia y tipos de entregas.
Poltica de numeracin de entregas.
Calendario anual de entregas mayores.
Implant.
Dis. Constr. Pru.
Dis. Constr. Pru.
Dis. Constr. Pru.
Gestin y agrupacin de las entregas menores.

Criterios para las entregas de emergencia.
Etc.
Figura 10.1.6. Esquema de una poltica de entrega
El ciclo de vida completo de una entrega comienza una vez que el cambio ha sido
construido, aceptado por el equipo tcnico y aprobada su implementacin por la
gestin del cambio. En la figura 10.1.7 se presenta el ciclo tpico de una entrega.
El ciclo de vida completo de una entrega se resume en:
La gestin del cambio (el gestor o el CAB) aprueba la implantacin del cam-
bio construido. La aprobacin acta como desencadenante del proceso de
gestin de la entrega.
Se realiza la aceptacin y revisin preliminar del cambio construido. Se rea-
liza la primera planificacin, acorde con lo previsto en el proyecto de cons-
truccin.
Figura 10.1.7. Ciclo de vida de una entrega
Se realizan las pruebas de instalacin, las funcionales, las tcnicas, las de

explotacin y se revisa la documentacin. En esta etapa se realizan las prue-
bas de carga para garantizar la escalabilidad de lo construido y comprobar la
capacidad necesaria prevista.
Superadas las pruebas y subsanados los defectos se realizara, si procede, la
integracin en el entorno de preproduccin.
Se solicita a la gestin del cambio la autorizacin para la implementacin en
produccin.
Desplegar las nuevas versiones de los elemento de configuracin de software
y de hardware en el entorno de produccin. Garantizar que las entregas no
sufren manipulacin, fuera de su configuracin especfica, en el proceso de
despliegue por los diferentes entornos.
Realizar la formacin necesaria a los usuarios y tcnicos para que sean capa-
ces de gestionar los nuevos servicios.
Garantizar y ejecutar un plan de marcha atrs a un punto consistente si la
entrega no tuviera xito.
Comunicar y formar a los clientes y usuarios sobre las funcionalidades de
la nueva versin.
Comunicar y formar a los tcnicos y responsables de produccin sobre la
operacin de la nueva versin, errores conocidos o cambios en los niveles
de servicio.
Actualizar la CMDB, DSL y DHS. Es fundamental garantizar que se han
actualizado correctamente estos repositorios.
Realizar la verificacin postimplementacin de la entrega y comunicrselo a
la gestin del cambio.
Planificacin de una entrega. Lo primero para decidir cundo y cmo realizar

una entrega es analizar la categorizacin del cambio, evaluando si es de emergencia
o es un cambio normal dentro de la planificacin pactada de antemano. En
segundo lugar, las entregas vienen con la categora y prioridad asignadas en la ges-
tin del cambio.
Cada entrega debe tener una planificacin que comprenda todas las etapas del
ciclo de vida: la pruebas, la integracin, la preparacin del despliegue, el paso al
entorno productivo (incluyendo los planes de marcha atrs) y la revisin postim-
plementacin.
Es necesario establecer un marco general para planificar las entregas que fije una
sistemtica rpida de trabajo. Esto es especialmente importante para los casos de
entregas menores y de emergencia, pues en el caso de entregas de gran enverga-
dura, se deben desarrollar planes especficos que tomen en cuenta las peculiarida-
des de cada caso.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cmo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
El proceso debe incluir la forma en que se de marcha atrs o se corrija la entrega si
no se realiza con xito.
Los planes deben registrar los entregables y las fechas de la entrega, y hacer refe-
rencia a las peticiones de cambio, errores conocidos y problemas relacionados.
El proceso de gestin de la entrega debe proporcionar la informacin adecuada al
proceso de gestin del incidente.
Las peticiones de cambio se deben evaluar en cuanto a su impacto en los planes de
entregas. Los procedimientos de gestin de la entrega deben incluir la actualizacin
y el cambio de la informacin de configuracin y los registros de cambio. Las entre-
gas de emergencia se deben gestionar de acuerdo a un proceso definido que rea-
lice la interfaz con el proceso de gestin del cambio de emergencia.
ISO/IEC 20000-2 detalla los contenidos que se deben contemplar en la planifica-

cin de una entrega.
UNE-ISO/IEC 20000-2
El proveedor del servicio debera traba- errores conocidos que hayan sido
jar conjuntamente con el negocio para identificados durantes las pruebas
asegurar que los elementos de configu- de la entrega;
racin que se van a desplegar en una c) los procesos relacionados para la
entrega son compatibles entre s y con implementacin de una entrega a
los elementos de configuracin del lo largo de todo el negocio y las
entornode destino.
diferentes unidades geogrficas;
La planificacin de la entrega debera
d) el modo en el que se dar mar-
asegurar que los cambios de los siste-
cha atrs de la entrega o en que
mas de informacin, infraestructuras,
esta se remediar si no se con-
servicios y documentacin afectados
cluye con xito;
son acordados, autorizados, planifica-
dos, coordinados y que se realiza un e) los procesos de verificacin y acep-
seguimiento de los mismos. tacin;
La entrega y el despliegue se deberan f) la comunicacin, preparacin,
planificar en etapas ya que los detalles documentacin y formacin para
del despliegue podran no ser conoci- los clientes y personal de apoyo;
dos inicialmente. g) la logstica y los procesos implica-
La planificacin de una entrega y del dos para realizar la compra, el
despliegue normalmente debera incluir: almacenamiento, la expedicin, la
a) las fechas de la entrega y la desconexin, la aceptacin y la puesta
cripcin de los entregables; a disposicin de los bienes;
b) los cambios y problemas relacio- h) los recursos de apoyo necesarios
nados, errores conocidos cerra- para asegurar el mantenimiento
dos o resueltos por esta entrega y de los niveles de servicio;
i) la identificacin de las dependen- k) el calendario de auditoras del

cias, los cambios relacionados y entorno de produccin cuando
los riesgos asociados que pueden sea necesario asegurar, para
perjudicar el paso sin complica- actualizaciones de gran tamao,
ciones de una entrega a los entor- que el entorno de produccin
nos de pruebas de aceptacin y est en el estado esperado en el
de produccin; momento de instalar la entrega.
j) la autorizacin de la entrega;
De todas las etapas planificadas en la entrega, el paso al entorno productivo es la

ms crtica, pues debe minimizar los tiempos de parada del servicio y orquestar
la participacin de los tcnicos y reas cliente. Con frecuencia, el paso a produccin
se realizar fuera del horario del servicio (nocturno o fin de semana), por lo que es
necesario detallar en cada actividad quin la realizar y en qu momento. Hay que
comunicar anticipadamente a los tcnicos y al rea cliente su participacin y hora-
rio previsto de intervencin. Tambin es necesario disponer del telfono de con-
tacto de cada participante, para poder engranar las actividades en el caso de inter-
venciones remotas.
Estos factores cobran una especial relevancia en situaciones en las que no se dis-
pone de una ventana temporal prefijada para el mantenimiento, o esta es ms
pequea que el tiempo estimado para intervencin. Aplicando estas acciones el
impacto negativo en el servicio se puede mitigar, para que afecte lo menos posible
a los usuarios y al negocio.
A la hora de planificar correctamente el lanzamiento de una nueva entrega se deben
tomar en cuenta los siguientes factores:
Cmo puede afectar la nueva versin a otras reas del entramado de TI.
Qu CI se vern directa o indirectamente implicados durante y tras el lanza-
miento de la nueva versin.
Cmo ha de construirse el entorno de pruebas para que ste sea fiel reflejo
del entorno de produccin.
Qu planes de marcha atrs son necesarios.
Cmo y cundo se deben implementar los planes de marcha atrs para mini-
mizar el posible impacto negativo sobre el servicio y la integridad del sistema.
Cules son los recursos humanos y tcnicos necesarios para llevar a cabo la
implementacin de la nueva versin con garantas de xito.
Quines sern los responsables directos en las diferentes etapas del proceso.
Qu planes de comunicacin y/o formacin deben desarrollarse para que los

usuarios estn puntualmente informados y puedan percibir la nueva versin
como una mejora.
Qu tipo de despliegue es el ms adecuado: completo, delta, sincronizado en
todos los emplazamientos, gradual.
Cul es la vida media til esperada de la nueva versin.
Qu planes de comunicacin y/o formacin deben desarrollarse para que los
tcnicos y responsables de produccin puedan operar y explotar esta nueva
versin.
Qu impacto puede tener la entrega en la calidad del servicio y en los niveles
de servicio acordados.
Informar del modelo de operacin, para la resolucin de errores conocidos,
o posibles incidentes en la produccin.
Si es posible establecer mtricas precisas que determinen el grado de xito
del lanzamiento de la nueva versin.
Los elementos de configuracin principales que se deben controlar en la entrega

son:
Software:
Software desarrollado independientemente de su naturaleza: propio, estn-
dar, desarrollado a medida, etc.
Utilidades, sistemas y herramientas software. Todo aquello que se deno-
mina software de base.
El soporte y mantenimiento de los productos, bien por los fabricantes o
bien por un tercero que proporcione el soporte a toda la solucin defi-
niendo un servicio a tal fin.
Hardware:
Las especificaciones del hardware.
Las instrucciones de ensamblaje y los manuales de instalacin.
Documentacin, manuales de uso de configuracin, soporte y manteni-
miento.
Contrato de mantenimiento, garantas, soportes, relacin de proveedores
y fabricantes, etc.
Comunicaciones y elementos de seguridad:

Redes de comunicaciones que intervienen. Segmentacin interna de redes
necesaria (VLAN).
Configuracin de los elementos de seguridad (firewalls, etc.).
Documentacin:
Aplicaciones, sistemas, herramientas, utilidades, hardware, etc.
Control y gestin:
Inclusin en los sistemas de monitorizacin y alertas.
Inclusin en los sistemas de gestin del servicio.
Personas:
Tcnicos que debern intervenir.
Personas del rea cliente o usuarios que debern participar para validar los
resultados.
Pruebas e integracin de la entrega. Se debe disponer de un entorno indepen-

diente para realizar las pruebas y la integracin de los desarrollos en un entorno
idntico al productivo real. En ocasiones, el entorno de integracin es indepen-
diente del de prueba; en este caso se le suele denominar preproduccin.
Un protocolo bien planificado de pruebas es absolutamente indispensable antes de
lanzar al entorno de produccin una nueva versin con garantas de xito.
Las pruebas no slo deben limitarse a una validacin de carcter tcnico (ausencia
de errores), sino que tambin, deben realizarse pruebas funcionales con usuarios
reales, para asegurarse de que la versin cumple los requisitos establecidos y es
razonablemente utilizable.
Las arquitecturas de desarrollo normalizadas juegan un papel clave para garanti-
zar que se utilizan soluciones y servicios estandarizados en las organizaciones,
permitiendo la integracin de productos de terceros y facilitando que no se pro-
duzcan duplicidades de una misma funcionalidad, lo que redunda en una crea-
cin y mantenimiento de servicios mucho ms rpida y eficiente. Gracias a este
tipo de arquitecturas se pueden crear entornos de pruebas de integracin efi-
cientes que permiten el enganche de los nuevos desarrollos con los servicios
estndar ya existentes, facilitando su prueba y certificacin de un funciona-
miento adecuado.
UNE-ISO/IEC 20000-1
Se debe establecer un entorno controlado de pruebas de aceptacin para construir

y probar todas las entregas previamente a su distribucin.
UNE-ISO/IEC 20000-2
Se deberan verificar en el momento de El proceso completo se debera docu-

la recepcin, las entregas de sistemas mentar en el plan de gestin de la con-
de informacin y de software provenien- figuracin.
tes de equipos de desarrollo propios,
desarrolladores de sistemas, integrado-
res u otras organizaciones.
Es importante que los planes de pruebas incluyan tambin la prueba de los planes
de marcha atrs, para asegurar la posibilidad de volver a la ltima versin estable
de una forma rpida, ordenada y sin prdida de informacin valiosa.
Las principales actividades realizadas en el proceso de prueba deben incluir:
Pruebas del correcto funcionamiento de la versin en un entorno realista.
Pruebas de integracin con la versin en produccin. Si se realiza un desplie-
gue fragmentado en el entorno de produccin, ser necesario realizar las
pruebas con las versiones operativas.
Pruebas de regresin si fueran necesarias en preproduccin.
Pruebas de capacidad en el entorno de preproduccin.
Pruebas de los procedimientos automticos o manuales de instalacin.
Listas de errores detectados, si se diera el caso.
Pruebas de los planes de marcha atrs.
Documentacin para usuarios, tcnicos de soporte y desarrolladores.
Disear, construir, documentar y configurar una entrega. Dependiendo del

tipo de entrega, puede ser necesario el empaquetado para la distribucin de una
entrega. Tambin puede ser necesaria la preparacin de programas o scripts que eje-
cuten secuencias de comandos para la instalacin. Se suelen utilizar herramientas
que automatizan el despliegue de las versiones de los productos software. Tanto la
entrega, como su empaquetado y distribucin se debe preparar para que se man-

tenga la integridad de los servicios.
UNE-ISO/IEC 20000-1
Las entregas y su distribucin se deben disear e implementar de forma que la inte-

gridad del hardware y del software se mantenga a lo largo de la instalacin, la mani-
pulacin, el empaquetado y la provisin.
UNE-ISO/IEC 20000-2
Los procesos de gestin de la entrega y la plataforma de destino satisface

distribucin se deberan disear e imple- los requisitos previos;
mentar para: f) habilitar verificaciones que com-
a) asegurar que existe conformidad prueben que una entrega est
con la arquitectura de sistemas, la completa cuando llega a su des-
gestin del servicio y las normas tino.
de infraestructura del proveedor
del servicio; Las salidas de este proceso deberan
incluir las notas de la entrega, las ins-
b) mantener la integridad durante la
trucciones de instalacin y el software
construccin, instalacin, manipu-
y hardware ya instalados, en relacin
lacin, empaquetado y entrega;
a la lnea de referencia de la configu-
c) usar bibliotecas de software y repo- racin.
sitorios relacionados para gestio-
nar y controlar los componentes Las salidas de la entrega se deberan
durante los procesos de construc- entregar al grupo responsable de las
cin y de entrega; pruebas.
d) asegurar que los riesgos estn Los procesos de construccin, gestin
claramente identificados y que se de la entrega y distribucin se deberan
pueden llevar a cabo acciones de automatizar para reducir errores, ase-
recuperacin si se requieren; gurando que el proceso es repetible y
e) habilitar verificaciones antes de la que se pueden desplegar rpidamente
instalacin para comprobar que las nuevas entregas.
La construccin de la entrega debe incluir todos los scripts de instalacin impres-

cindibles para el despliegue de la versin. Los scripts encadenaran secuencias de
actuaciones, que evitarn errores humanos. Estos scripts debern tener en cuenta
aspectos tales como:
Recuperacin automtica de datos a un punto de retorno estable.
Actualizaciones necesarias de las bases de datos asociadas.

Instalacin de las nuevas versiones en diferentes sistemas o emplazamientos
geogrficos.
Creacin de registros de actividad asociados al proceso de instalacin (logs
del proceso).
Herramienta para la distribucin de software utilizada por la organizacin.
Destacar que tambin debe ser parte integrante del desarrollo los planes de marcha
atrs asociados. Estos tendrn que tomar en cuenta la disponibilidad acordada con
los clientes en el SLA.
Es necesario que todo procedimiento de entrega, genere un histrico de su resultado.
La documentacin de las entregas debe seguir un patrn uniforme definido. La
metodologa de desarrollo o construccin utilizada, debe contemplar la descripcin
de la documentacin a utilizar. Los modelos de documentacin debern adecuarse
al tipo de entrega, centrndose en que la documentacin de la entrega contenga
todos los apartados de utilidad. Con frecuencia se utiliza el mismo patrn de docu-
mentacin para una gran entrega que para cambios sencillos, resultando bastante
pesada e intil.
La documentacin va evolucionando desde archivos de texto aislados, hacia siste-
mas documentales integrados. Cada vez es ms frecuente, que la documentacin de
los servicios y sus evoluciones se estructuren en un sistema web que se convierte en
una ayuda o consulta online accesible de forma selectiva por todas las partes de la
organizacin.
UNE-ISO/IEC 20000-2
La documentacin apropiada debera los procedimientos de instalacin

estar disponible en su totalidad y alma- y de soporte, las ayudas para el
cenada segn la gestin de la configu- diagnstico y las instrucciones de
racin en referencia al elemento de operacin y administracin;
configuracin desplegado. Esta docu- c) los procesos de construccin,
mentacin debera incluir: despliegue de versiones, instala-
cin y distribucin;
a) la documentacin de apoyo, por
ejemplo, los acuerdos de nivel de d) los planes de contingencia y mar-
servicio; cha atrs;
b) la documentacin de apoyo, por e) la planificacin de la formacin
ejemplo, el esquema del sistema, para los responsables del servi-
cio, el personal de apoyo y los relacionadas de la verificacin y

clientes; la aceptacin.
f) una lnea de referencia de la confi- Si un sistema o servicio no cumple com-
guracin para la entrega, inclu- pletamente con los requisitos especifica-
yendo elementos de configuracin dos para l, antes de pasar a produc-
asociados tales como documentacin se debera identificar y registrar
cin del sistema, entornos de prue- mediante la gestin de la configuracin
bas, documentacin de pruebas y y la gestin del problema.
versiones de las herramientas de La informacin sobre errores conocidos
construccin y desarrollo; se debera comunicar a la gestin del
g) los cambios, problemas y errores incidente.
conocidos relacionados; Si la entrega es rechazada, retrasada o
h) las evidencias de la autorizacin cancelada, se debera informar a la
de la entrega y las evidencias gestin del cambio.
Verificacin y aceptacin de la entrega. Antes de proceder a su implementacin

en el entorno productivo, la entrega pasa por un proceso formal de verificacin de
que se han cumplido todos los requisitos establecidos, para solicitar posteriormente
a gestin del cambio su autorizacin para proceder al despliegue en el entorno de
produccin de la explotacin regular. Las comprobaciones que requiere ISO/IEC
20000-2 son las que se muestran a continuacin:
UNE-ISO/IEC 20000-2
El resultado final debera ser una apro- usando el proceso de produccin

bacin basada en el grado en el que el planificado;
paquete completo de la entrega recoge c) verificar que se ha completado el
la totalidad de los requisitos. nivel adecuado de pruebas, por
Los procesos de verificacin y acepta- ejemplo, pruebas funcionales y no
cin deberan: funcionales, pruebas de acepta-
a) verificar que el entorno contro- cin por el negocio, pruebas en
lado de las pruebas de acepta- los procedimientos de construc-
cin se ajusta a los requisitos del cin, despliegue de versiones, dis-
entorno de produccin de des- tribucin e instalacin;
tino; d) asegurar que la entrega es pro-
b) asegurar que la entrega se ha cre- bada a la satisfaccin de los
ado a partir de versiones bajo el clientes del negocio y del perso-
control de gestin de la configura- nal del proveedor del servicio;
cin y que se han instalado en el e) asegurar que la autoridad apro-
entorno de pruebas de aceptacin piada en cuanto a la gestin de la
entrega aprueba cada etapa de los requisitos previos de software y

las pruebas de aceptacin; hardware;
f) verificar antes de la instalacin que g) verificar que la entrega est com-
la plataforma de destino satisface pleta cuando llega a su destino.
Despliegue, distribucin e instalacin. Superada la fase de validacin o las prue-

bas, la gestin del cambio ser la encargada de proporcionar la autorizacin final a
la entrega para que se proceda a su instalacin.
La distribucin de la nueva versin, tambin conocida como rollout, puede ser de
varios tipos:
Completa y sincronizada: se realiza de manera integral y simultnea en todos
los emplazamientos.
Fragmentada: ya sea bien espacial o temporalmente. Por ejemplo, introdu-
ciendo la nueva versin por grupos de trabajo o incrementando progresiva-
mente la funcionalidad ofrecida.
UNE-ISO/IEC 20000-2
Se debera revisar el plan de despliegue laciones fsicas, el entorno, las

y se deberan aadir detalles, si es nece- instalaciones elctricas y otros
sario, para asegurar que se van a llevar servicios;
a cabo todas las actividades necesarias. d) se notifican las nuevas entregas al
personal del negocio y del prove-
Es importante que la entrega sea pro-
edor del servicio;
porcionada de un modo seguro para su
e) se eliminan los productos, servi-
destino en el estado esperado. Los pro-
cios y licencias que quedan sin
cesos de despliegue, distribucin e ins-
utilidad tras la nueva entrega.
talacin deberan asegurar que:
a) todas las zonas de almacena- Despus de una distribucin de software
miento de hardware y software son en una red es esencial comprobar que
seguras; la entrega est completa y es operativa
b) existen procedimientos adecuados cuando llega a su destino.
para el almacenamiento, expedi- Los registros de activos y de la gestin
cin, recepcin y eliminacin de de la configuracin se deberan actuali-
bienes; zar con la ubicacin y el propietario del
c) se planifican y completan las software y el hardware tras una instala-
comprobaciones sobre las insta- cin llevada a cabo con xito.
Se debera usar un cuestionario de satis- Todos los resultados de las encuestas de

faccin y aceptacin por parte del satisfaccin de los clientes deberan
cliente de la instalacin para registrar el constituir una realimentacin para la
xito o el fracaso de dicha instalacin. gestin de las relaciones con el negocio.
El procedimiento de rollout debe ser documentado y comunicado a todas las partes

implicadas para que conozcan sus tareas y responsabilidades especficas. En parti-
cular los usuarios finales deben estar puntualmente informados del calendario de
despliegue y de cmo ste puede afectar a sus actividades diarias, y en algunos
casos, en funcin de su complejidad, puede ser necesario establecer un plan de for-
macin especfico.
Es imprescindible determinar claramente:
Los CI que deben borrarse e instalarse y en qu orden debe realizarse este
proceso.
Cundo debe realizarse este proceso para diferentes grupos de trabajo y/o
localizaciones geogrficas.
Que mtricas o eventos determinan la puesta en marcha de los planes de
marcha atrs y si estos deben ser completos o parciales.
Tras la distribucin, la gestin de la entrega debe asegurarse de que:

Se incluya una copia de la versin en la DSL.
El DHS incorpore repuestos esenciales de los nuevos CI.
La CMDB est correctamente actualizada.
Los usuarios estn debidamente informados de las nuevas funcionalidades y
hayan recibido la formacin necesaria para poder sacar el adecuado prove-
cho de las mismas.
Los tcnicos y responsables de produccin estn correctamente informados
y formados para garantizar la operacin.
Tras la implementacin, la gestin de la entrega debe ser puntualmente informada

por el centro de servicio al usuario de los comentarios, quejas, incidentes, etc. que
la nueva versin haya podido suscitar.
Toda informacin obtenida deber ser analizada para asegurar que las prximas ver-
siones incorporen las sugerencias recibidas y que se tomen las medidas correctivas
necesarias para minimizar el impacto negativo que puedan tener futuros cambios.
Comunicacin y formacin. Salvo contadas excepciones, es necesaria la interac-

cin usuario-aplicacin y sta suele representar el eslabn ms dbil de la cadena.
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carc-
ter tcnico se obvie el factor humano. Es intil disponer de un sofisticado servicio
TI si los usuarios, debido a una incompleta formacin, no se encuentran en dispo-
sicin de aprovechar sus ventajas.
En cambios menores, ser suficiente con informar a los usuarios.
En nuevos servicios o cambios radicales, la formacin adquiere una relevancia
importante y debe estructurarse en distintos niveles:
Los usuarios deben conocer las entregas que se van a implementar y conocer
con anterioridad la nueva funcionalidad planificada o los errores que se pre-
tenden resolver para participar, a su discrecin, en el proceso.
Siempre que sea posible, las pruebas de carcter funcional deben ser realiza-
das por un grupo de usuarios finales (conviene seguir disciplinas tipo focus
group para captar la opinin de los usuarios). Durante este proceso de
prueba se documentarn y analizarn:
La experiencia subjetiva de usuario.
Los comentarios y sugerencias sobre usabilidad y funcionalidad.
Las dudas que hayan surgido durante el uso de la nueva versin.
La claridad de la documentacin que se pondr a disposicin del usuario
final.
Cuando se considere oportuno se impartirn cursos presenciales o remotos

mediante mdulos de e-learning, sobre el funcionamiento de la nueva versin.
Generar un documento en el soporte ms adecuado (pagina web, nota infor-
mativa en tabln de anuncios, etc.) con preguntas frecuentes (FAQ), en
donde los usuarios puedan aclarar las dudas ms habituales y puedan solici-
tar ayuda o soporte tcnico en el uso de la nueva versin.
Se formar a los tcnicos responsables de la explotacin de nuevos modelos
de operacin o de nuevas tecnologas si fuera necesario.
Evaluar resultados y Revisin postimplantacin. Una vez implantada la entrega,

se debe realizar la revisin postimplantacin (PIR) con los clientes y usuarios, para
garantizar que la entrega y los cambios que contiene funcionan a la perfeccin. Una
vez obtenida la aceptacin por el rea cliente y los usuarios, se procede al cierre de
la entrega y de las RFC que contiene.
La revisin postimplantacin es ejecutada por la gestin de la entrega, y comuni-

cada a gestin del cambio.
En cambios importantes, se suele dejar un plazo de un par de semanas para realizar
el PIR.
UNE-ISO/IEC 20000-2
Se debera medir y analizar el nmero de El proceso de gestin del cambio debe-

incidentes relacionados con una entrega ra incluir una revisin post-implantacin.
en el periodo inmediatamente posterior a
Las recomendaciones se deberan incluir
un despliegue para evaluar su impacto
en un plan de mejora del servicio.
en el negocio, en las operaciones y en
los recursos de personal de apoyo.
Mtricas del proceso

Es necesario elaborar informes que permitan evaluar el rendimiento del proceso de
la gestin de la entrega. Para que estos informes ofrezcan una informacin precisa
y de sencilla evaluacin es necesario elaborar mtricas de referencia que cubran
aspectos tales como:
Nmero de entregas realizadas.
Nmero de marchas atrs ejecutadas y razones de las mismas.
Nmero de incidentes causados por las entregas, de forma directa o colateral.
Porcentaje de cumplimiento de los plazos previstos para cada entrega.
Recursos utilizados. Nmero medio de horas/hombre dedicadas por entrega.
Correccin y alcance de la CMDB, la DSL y la DHS.
Informacin relacionada con versiones ilegales de software.
Adecuado registro de las nuevas versiones en la CMDB.
Incidentes provocados por uso incorrecto (formacin inadecuada) de la
nueva versin por parte de los usuarios.
Incidentes provocados por la operacin incorrecta (formacin inadecuada)
de la nueva versin y componentes por parte de los tcnicos y responsables
de la operacin.
Desviacin de la disponibilidad del servicio respecto al nivel planificado

(PSA). Esta desviacin se mide tanto durante el proceso de despliegue como
despus de la implantacin.
Satisfaccin del cliente y usuario final con el proceso de la entrega del servicio.
En la figura 10.1.8 se muestra un resumen de los indicadores ms relevantes para

este proceso seleccionados por un grupo de trabajo de itSMF Espaa.
de itSMF Espaa
Roles participantes en la gestin de la entrega

Los roles involucrados en la gestin de la entrega se estructuran en los roles pro-
pios del proceso y los roles ajenos al proceso.
El gestor de la entrega (gestor del proceso o process manager), que es el res-
ponsable del da a da de la actividad del proceso. En este caso realiza la pla-
nificacin de las entregas, supervisa las pruebas, solicita a la gestin del cam-
bio la autorizacin para implantar, etc.
Los administradores o el personal de soporte al proceso, ayuda al gestor de
la entrega en el control de toda la actividad.
Los especialistas en tecnologas, aplicaciones y formacin, que realizan las

pruebas tcnicas y funcionales, realizan la implantacin y despliegue y reali-
zan la formacin a los usuarios sobre los nuevos servicios.
El propietario del modelo SGSTI acta como propietario del proceso (pro-
cess owner). Define las actividades del proceso y se encarga de la mejora con-
tinua del mismo. Todo ello, de una forma integrada con el modelo de ges-
tin del proveedor TI incorporado en el SGSTI.
El responsable de la gestin del cambio, que debe autorizar el inicio de las
pruebas e integracin, la implantacin en produccin y el cierre de la entrega.
Los roles de mayor relevancia que participan en el proceso de gestin de la entrega

Resumen
El proceso de la gestin de la entrega proporciona control sobre la implementacin
de los cambios, garantiza la calidad de lo construido y vela por minimizar el
impacto de las paradas en los entornos productivos. Junto con la gestin del inci-
dente, es uno de los procesos que ms recursos consume de TI y ms tensin
genera, por lo que deber tenerse en cuenta en su primera implementacin y en el
ciclo de mejora continua.
Por tanto, la gestin de la entrega:
Proporciona confianza, en cuanto a robustez de la solucin, al haber sido
certificada en los entornos y modelos de pruebas.
Aporta eficiencia a la organizacin, al ofrecer una sistemtica para el desplie-
gue de componentes, optimizado y monitorizado, que reduce el tiempo nece-
sario para realizar estas tareas. Automatizando aquellas que sean repetitivas.
Pone orden manteniendo un listado de cambios planificados (FSC).
Ejerce control sobre los servicios, al disponer de una sistemtica para instalar
cualquier versin de estos.
Garantiza, de forma coordinada con el proceso de la gestin del cambio, la
disponibilidad y estabilidad de la operacin diaria de los servicios con una
Roles del proceso
Responsable de la
gestin del servicio
SGSTI
Gestor de Administrador y
la entrega soporte del proceso
de entrega
Propietario del
modelo (SGSTI)
Especialista Especialista Especialista

en tecnologas en aplicaciones en formacin
Gestor del cambio
Figura 10.1.9. Roles del proceso de gestin de la entrega
poltica de entregas pactadas, con fechas para los pasos a explotacin acorda-
dos. Esto permite hacer un calendario junto con los responsables de los servi-
cios, que posibilita el no hacer coincidir en el tiempo despliegues y puntas
de negocio, o fechas crticas para la correcta prestacin del servicio.
Prev con anterioridad la necesidad de recursos para el proceso, lo que per-
mitir una correcta planificacin de las personas y los componentes.
Controla a los proveedores en cuanto a la validez de sus entregas.
Garantiza de que la CMDB esta correctamente actualizada.
Controla el software instalado en produccin, su parametrizacin y documen-
tacin, a travs de una DSL actualizada. Esto incluye no slo sistemas ope-
rativos y aplicaciones sino tambin controladores de dispositivos y documen-
tacin asociada.
Control de forma rigurosa y eficiente del almacn de hardware (DHS). Los

activos almacenados deben incorporarse a la CMDB en el caso de que los CI
correspondientes se hallen registrados en la misma (esto puede depender del
alcance y nivel de detalle de la CMDB).
Beneficios
Los principales beneficios aportados por el proceso de gestin de la entrega son los
siguientes:
Los cambios en los servicios se realizan sin deterioro de la calidad de servicio.
Las nuevas versiones cumplen los objetivos propuestos.
Se reduce el nmero de incidentes por incompatibilidades con otro software
o hardware instalado.
Se establece un orden lgico para el paso a produccin, que permite la inte-
gracin no traumtica de las diferentes soluciones, evitando los incidentes
por efectos colaterales en produccin.
El proceso de pruebas asociado, no slo permite asegurar la calidad del software
y hardware que se va a instalar, sino que tambin permite conocer la opinin de
los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
Tambin permite detectar posibles problemas de capacidad, en las pruebas
realizadas, y actuar con la gestin de la capacidad, para garantizar las necesi-
dades en produccin.
El correcto mantenimiento de la DSL impide que se pierdan las valiosas
copias de los archivos fuente.
Se reduce el nmero de copias de software ilegales.
Control centralizado del software y hardware desplegado.
Se garantiza la existencia de un plan de marcha atrs a un punto estable, que
garantiza la posibilidad de continuidad de la explotacin, todos los despliegues
son controlados en cuanto un nivel de impacto y riesgo sobre la produccin.
Proteccin contra virus y problemas asociados a versiones de software incon-
troladas.
Se garantiza la existencia de los procedimientos de gestin y monitorizacin,
que permiten la correcta operatividad en produccin, del software y hardware
desplegado.
El cumplimiento de los requisitos de continuidad acordados, y prueba de su

correcto funcionamiento.
Reduccin del tiempo de puesta en produccin.
Cmo encaja la metodologa de pruebas en el proceso de entrega?
El equipo de desarrollo de software, qu papel juega en este pro-
ceso?
Cite dos mejores prcticas en su organizacin relativas al proceso de
entrega.
2
11
Captulo 11
La certificacin de la
gestin del servicio de TI
conforme a ISO/IEC 20000
11.1. La primera certificacin conforme a ISO/IEC 20000
11.2. Evidencias y registros importantes en una certificacin


11. La certificacin de la gestin del servicio de TI conforme a ISO/IEC 20000 735
El presente captulo introduce los aspectos prcticos sobre el conjunto de activida-

des necesarias para obtener la certificacin del cumplimiento de los requisitos de
ISO/IEC 20000-1.
En primer lugar, es importante resaltar que la certificacin no debera ser un fin en
s misma, sino ms bien un medio. Es un medio que aporta un reconocimiento por
una entidad ajena al proveedor de TI, independiente, imparcial y con la credibili-
dad necesaria. El hecho de recorrer el camino de la certificacin obliga a aplicar con
rigor los requisitos de la norma, por lo que tambin se conseguir una mejora sig-
nificativa en la prestacin de los servicios.
La certificacin declara pblicamente a las partes interesadas (organizacin, clien-
tes, proveedores, competencia) y a toda la sociedad en general, que dicha organiza-
cin gestiona sus servicios mediante procesos de acuerdo a esta normativa.
Aunque la certificacin frente a ISO/IEC 20000 es voluntaria, observamos cmo
el mercado est exigindola cada vez ms, hoy se requiere en los contratos a sumi-
nistradores de TI, pero en poco tiempo se ir extendiendo a los departamentos
internos. Adems, la certificacin de la gestin de los servicios de TI aporta una
herramienta de marketing, interna y externa, a las organizaciones que la han alcan-
zado.
A lo largo de este captulo se explicar todo el recorrido necesario para certificarse
en ISO/IEC 20000, desde la solicitud inicial hasta la ejecucin de la primera audi-
tora y en su caso la obtencin de la certificacin. La descripcin del proceso se ha
realizado tomando como referencia los procedimientos del rea de certificacin de
AENOR, y aunque los conceptos son generalizables, algunas actividades pueden
variar en la certificacin con otras entidades certificadoras.
Antes de iniciar la lectura del captulo se recomienda revisar el apartado 1.3
Entender los entornos de normalizacin y certificacin de este libro, pues pre-
sentan una visin bastante completa de los actores en este mbito.
De forma complementaria, en el apartado 11.2 se proponen una serie de eviden-
cias esenciales obtenidas de la experiencia prctica de la certificacin.
11. La certificacin de la gestin del servicio de TI conforme a ISO/IEC 20000
11.1. La primera certificacin conforme a ISO/IEC 20000 737
11.1. La primera certificacin conforme

a ISO/IEC 20000
Figura 11.1.1. Etapas de un ciclo de certificacin genrico
De forma paulatina, se observa que la alineacin con ISO/IEC 20000 es cada vez
ms un criterio empleado en la toma de decisiones relevantes en la contratacin de
recursos de TI, dado que la aplicacin de estas normas permite a cualquier provee-
dor de servicios de TI acreditar la calidad en la prestacin de sus servicios. Esto
quiere decir que estn alineados con el negocio, que se aplican criterios de eficien-
cia, que se reducen los riesgos de operacin del servicio, que se satisfacen los requi-
sitos de sus clientes, que se vela por el cumplimiento de los suministradores, etc.
Para obtener la certificacin ISO/IEC 20000 es necesario tener implementado el
sistema de gestin del servicio de TI (SGSTI) y tambin haber evolucionado en las
formas de trabajar para incorporar las prcticas y los requisitos de estas normas.
A partir de este momento, se est en disposicin de cubrir una serie de etapas nece-
sarias para la obtencin de la certificacin.
El ciclo de certificacin no es un recorrido lineal que empieza y termina. Ms
bien, es parecido a un crculo de mejora, que comienza con la certificacin inicial
y que culmina con el mantenimiento y mejora en la calidad de la gestin de los
servicios. Este aspecto es clave en ISO/IEC 20000-1. Por ello, en las normas se
ha definido un apartado especfico denominado: 4. Planificacin e implementa-

cin de la gestin del servicio y el ciclo PDCA, que se convierten en los instru-
mentos fundamentales, tanto para la realizacin de las auditoras de seguimiento
anual, como en la renovacin del certificado que se realiza cada 3 aos.
Para iniciar este camino se necesitan dos actores: el solicitante (empresa u organi-
zacin que aspira a conseguir la certificacin conforme a la norma) y la entidad de
certificacin (empresa u organizacin que tras la etapa de auditora y evaluacin de
conformidad de la organizacin solicitante respecto a la norma, concede o deniega
la certificacin).
En la figura 11.1.2 se muestran las etapas del ciclo de certificacin.
Las 9 etapas del ciclo de certificacin se explican a continuacin. Estas etapas estn
en conformidad con ISO/IEC 17021.
1. Determinar el alcance de la certificacin

Los proveedores de TI que aspiren a obtener la certificacin ISO/IEC 20000-1
deben realizar, como primera tarea, la definicin del alcance de su certificacin.
En esta actividad, el proveedor debe concretar y delimitar el alcance o mbito de
aplicacin del sistema de gestin (SGSTI). Dicho alcance se refiere a los servicios
incluidos en su catlogo y que son gestionados de acuerdo al modelo. Asimismo,
es conveniente identificar el conjunto de clientes objeto de prestacin de dichos
servicios. Finalmente, es necesario identificar las localizaciones de los centros y uni-
dades organizativas desde donde se prestan los servicios considerados.
El alcance viene a ser la foto que la organizacin de TI quiere mostrar al sector
de sus competencias y calidad en la gestin de servicios de TI. Para la realizacin de
esta foto por un tercero ajeno a la organizacin, de forma independiente e impar-
cial, es clave decidir qu elementos van a formar parte de esta imagen, de forma
que permita dejar muy claro, sin dudas ni ambigedades, los servicios de TI, los
clientes y las ubicaciones, centros y organizaciones donde se prestan.
Determinar el alcance de la certificacin es uno de los temas ms difciles de acor-
dar entre la entidad certificadora y el proveedor de TI. Es el primer tema a tratar
con el equipo auditor. Un alcance muy reducido permitir obtener la certificacin
con un esfuerzo reducido, mientras que un alcance que comprenda a toda la orga-
nizacin de TI requerir un gran esfuerzo de transformacin. Por ello, el inters de
los aspirantes a la certificacin de limitar el alcance.
Parece claro que el alcance debe contemplar los 13 procesos tratados en la
norma, adems, del sistema de gestin del servicio y del ciclo de mejora continua
1. Determinar alcance
2. Solicitud de certificacin
3. Auditora fase I:
Anlisis de documentacin
4. Auditora fase I:
Visita previa
5. Auditora fase II
La primera
certificacin Existen S
no conformidades?
Plan de acciones
correctivas
6. Evaluacin y decisin
Cumple No Auditora extraordinaria

requisitos? (a los 6 meses)
7. Emisin del certificado
8. Auditoras de seguimiento
Mantenimiento de (aos 1 y 2)
la certificacin
9. Auditora de renovacin Responsabilidad proveedor TI
(cada tercer ao) Lidera el certificador
Fuente: AENOR.
Figura 11.1.2. Ciclo tpico de certificacin utilizado para ISO/IEC 20000-1

PDCA. Pero no est tan claro si se deben certificar todos los servicios, todas las
localizaciones, todos los clientes a la vez. De aqu, la importancia en consensuar el
alcance.
Es frecuente acometer el alcance completo en varias certificaciones sucesivas, ms
pequeas, ms rpidas y con menos riesgo de fracaso. Es importante que los servi-
cios seleccionados para la certificacin sean lo suficientemente representativos para
el proveedor de TI, ya sea por volumen de actividad, impacto en la cuenta de resul-
tados, etc.
Una vez identificados los servicios hay que determinar las ubicaciones en las que se
prestan. Es necesario identificar qu ubicaciones entrarn a formar parte de la cer-
tificacin. En este punto, lo deseable es que las ubicaciones elegidas sean todas en
las que se prestan los servicios seleccionados y, en el caso de certificaciones con el
alcance reducido deben ser lo suficientemente representativas. Adems, las exclu-
siones deben estar perfectamente justificadas.
Llegados a este punto es recomendable que el proveedor de TI realice una evalua-
cin de la situacin actual del alcance definido para la certificacin (vase la evalua-
cin o assessment descrito en el captulo 4). De esta forma, podr determinar su
situacin respecto a los requerimientos de la norma. En el caso de necesitar acome-
ter mejoras en el sistema de gestin del servicio de TI, evaluar su viabilidad, y
tomar la decisin de si se inicia el proceso de certificacin.
Hasta este momento el proveedor de TI no ha tenido contacto con el equipo de
auditora de la certificacin, por lo que la definicin del alcance y la evaluacin rea-
lizados son internas y no estn validadas por el certificador.
2. Solicitud de certificacin
El siguiente paso cubre la confeccin del formulario de solicitud de certificacin,
que la entidad de certificacin remite al proveedor de TI previa solicitud.
En la solicitud se incluye informacin, como por ejemplo, el alcance de la certifica-
cin, contactos, direcciones, nmero de personas de la organizacin, nmero de
emplazamientos, etc. (vase la figura 11.1.3).
Esta informacin es importante, ya que proporciona una idea de la dimensin del
sistema de gestin de servicios que se pretende certificar y que ser una de las varia-
bles que se deben tener en cuenta a la hora de planificar la auditora. Esta planifica-
cin determina el volumen de las actividades que se van a realizar y la estimacin
de carga de trabajo, que dar como resultado una oferta de la entidad de certifica-
cin con un presupuesto.
Fuente: AENOR.
Figura 11.1.3. Ejemplo de una solicitud de certificacin

Tras la aceptacin de la oferta por el proveedor de TI, la entidad de certificacin le

asigna un nmero de expediente que le identificar durante toda la vida del certifi-
cado. El certificador designa un tcnico experto en el sector y que se podra definir
como el gestor del expediente. A esta figura se la denomina TRE (Tcnico Respon-
sable del Expediente).
El TRE ser quien, partiendo de la informacin recibida y, junto con el responsa-
ble definido por la organizacin de TI, planificar la certificacin: visitas, horarios,
servicios, emplazamientos, etc. Tambin es el responsable del equipo auditor.
Para cada una de las visitas, y de forma previa, se enva al proveedor de TI, por
parte del equipo auditor, un plan de auditora en el que, como mnimo, se reflejar
la siguiente informacin:
Composicin del equipo auditor.
Representante de la organizacin.
Centros que se deben visitar.
Actividades objeto de la visita.
Fecha, horario y planificacin detallada.
3. Auditora fase I: Anlisis de documentacin

Esta actividad constituye el primer contacto operativo de la auditora. Su objetivo es el
estudio de la documentacin del sistema de gestin de TI (SGSTI). La finalidad de esta
actividad es determinar si la documentacin del sistema se corresponde con los requisi-
tos de gestin del servicio establecidos, ya sean por la propia norma de referencia, los de
sus clientes, los legales y reglamentarios, o los propios del sistema de gestin.
En esta actividad se revisan los documentos principales del SGSTI (vase el cap-
tulo 3):
Manual del SGSTI.
Manual de procesos y procedimientos del SGSTI.
Registros de los procesos.
La gestin del propio SGSTI: el manual sobre la propia organizacin del sis-
tema de gestin.
El resultado de esta actividad quedar reflejado en un informe con las observacio-

nes detectadas (IOM, Informe de Observaciones al Manual). Estas consideraciones
sern tenidas en cuenta por el equipo auditor en la siguiente actividad, que se deno-
mina visita previa.
Este anlisis se puede realizar tanto en las instalaciones de la organizacin de TI,
como en las instalaciones de la entidad certificadora. En ocasiones se realiza
de forma conjunta con la visita previa que se detalla a continuacin. El anlisis de
documentacin y la visita previa forman parte de la auditora fase I.
4. Auditora fase I: Visita previa

El siguiente paso es la visita previa (VPR, Visita Previa). En ella, los auditores visi-
tan la organizacin con los siguientes objetivos principales:
Revisar y analizar el alcance de la certificacin.
Comprobar el grado de implantacin y adecuacin del SGSTI.
Revisar el plan de auditora fase I y aclarar las dudas que se puedan tener
sobre el procedimiento de certificacin.
Coordinar y cerrar el plan de la siguiente fase, la auditora fase II.
En relacin a la revisin y anlisis del alcance de la certificacin, es importante des-

tacar que el papel de la entidad de certificacin consiste en garantizar la consisten-
cia necesaria y asegurar que las organizaciones no excluyen del alcance ningn
elemento (ubicaciones fsicas de la empresa solicitante, servicios prestados, infraes-
tructura, clientes, recursos) que deba ser incluido.
La entidad de certificacin comprobar, por tanto, que el alcance solicitado sea lo
suficientemente representativo del negocio, refleje correctamente sus actividades y
que los planes de mejora se extiendan a los lmites de sus actividades, segn lo defi-
nido en la documentacin del sistema de gestin.
La auditora fase I es una versin reducida de la siguiente actividad. La auditora
fase II, revisa el grado de implantacin y funcionamiento del sistema de gestin del
proveedor de servicios de TI contenido en el manual de gestin SGSTI y de sus
procesos.
En esta visita, aunque s se revisa el funcionamiento de los procesos, no se suelen
pedir evidencias formales de sus resultados. Cubre entre el 30% y el 50% del total
del trabajo que se debe realizar.
Como conclusin a la visita previa, se emite un informe con las observaciones
detectadas respecto a la implantacin del SGSTI. Estas observaciones y no confor-
midades sern tenidas en cuenta en la auditora fase II.
Resulta interesante destacar que la auditora fase I es sumamente til, y podemos

considerarla como una buena prctica que contribuye de forma importante al
xito del proceso de certificacin.
El siguiente paso que se debe realizar es la auditora fase II. Antes de realizarla,
debera transcurrir el tiempo suficiente que permita a la organizacin de TI la
correccin de aquellos aspectos ms significativos detectados en la auditora fase I.
5. Auditora fase II
La auditora fase II es la actividad clave en el proceso de certificacin. En ella el
equipo auditor evala al completo el sistema de gestin de servicios de TI
(SGSTI). Analiza su conformidad con relacin a los requisitos de la norma y com-
prueba su implantacin y funcionamiento operativo.
Para ello, la entidad certificadora confecciona un plan de auditora especfico para
el cliente (vase la figura 11.1.4).
La auditora fase II comienza con una reunin en la que se presenta el plan de tra-
bajo de la auditora y se concretan las entrevistas con las personas de las reas que
sern objeto de la visita. Esta etapa, dependiendo del alcance de la certificacin
acordado, puede durar entre 3 y 6 jornadas.
Para cada uno de los servicios y centros incluidos en el alcance de la certificacin, se
revisar el cumplimiento del manual de gestin de servicios y su adecuacin a la
norma objeto de certificacin. Para realizar esta labor, el equipo auditor revisar el
cumplimiento de la norma mediante comprobaciones in situ y evidencias formales
de su cumplimiento.
El resultado de la auditora fase II se plasma en un informe, en cuyo contenido se
reflejarn las no conformidades o incumplimientos detectados por el equipo
auditor. Dichos incumplimientos estarn contrastados frente a los requisitos espe-
cificados por la norma, los legales o reglamentarios, los de los clientes de la organi-
zacin o los propios del SGSTI.
El informe ser entregado y comentado en la reunin final de auditora.
Plan de acciones correctivas. En el caso que el informe de la auditora refleje no
conformidades, el proveedor de TI debe confeccionar un documento especfico: el
Plan de Acciones Correctivas (PAC).
Para ello, la organizacin dispone de un plazo de tiempo establecido para presentar
a la entidad de certificacin el plan de acciones correctivas dirigido a subsanar las no
conformidades detectadas en la auditora. En dicho plan se debe incluir un anlisis
Plan de la auditoria fase II
Nombre de la empresa.
Domicilio.
Alcance de la auditora.
Normas de referencia que aplican.
Composicin del equipo auditor.
Programa de trabajo, detallando:
Reunin inicial:
Fechas y horarios.
Auditores y asistentes.
Agenda.
Reuniones de auditoria:
Fechas y horarios.
Servicios de TI y apartados de la
norma a auditar en cada reunin.
Reunin final:
Fechas y horarios.
Fuente: AENOR.
Figura 11.1.4. Contenido tipo del plan para la auditora fase II
de las causas que motivaron cada uno de los incumplimientos y, tambin, deben
quedar reflejados los responsables de la implantacin de dichas acciones.
Una vez emitido el plan de acciones correctivas, puede ocurrir que se necesiten
aclaraciones relacionadas con las acciones enviadas, por lo que podra ser necesario
efectuar ampliaciones del PAC.
6. Evaluacin y decisin
Cuando se ha cerrado el plan de acciones correctivas, el responsable de la auditora
enva un informe a la entidad de certificacin con una recomendacin sobre la con-
veniencia de conceder, o no, la certificacin al proveedor de TI solicitante.
En este punto, el comit de certificacin (de la entidad de certificacin) decide otor-

gar o no la certificacin, basndose en el anlisis del informe de la auditora fase II y
en el plan de acciones correctivas, si se cumplen los requisitos de certificacin.
Auditora extraordinaria. En el caso que no se cumplan los requisitos de certifica-
cin, sera necesaria una visita adicional, llamada auditora extraordinaria, que nor-
malmente se planifica a seis meses despus de la auditora fase II. Su objetivo es com-
probar la implantacin de los incumplimientos que motivaron la visita extraordinaria.
7. Emisin del certificado

Si la decisin es positiva, la entidad certificadora proceder a la concesin del certi-
ficado ISO/IEC 20000-1, que entra en la categora de certificado de registro de
empresa. Adems, gestionar el Certificado IQNet (vase la figura 11.1.5).
El certificado de IQNet, le otorga al certificado de registro de empresa un carc-
ter internacional. Mediante este certificado adicional se consigue el reconoci-
miento internacional de los certificados concedidos en un pas.
8. Auditoras de seguimiento
El certificado tiene una validez de tres aos. A lo largo de los cuales la entidad cer-
tificadora realizar auditoras de seguimiento para comprobar que el sistema de
gestin contina cumpliendo con los requisitos indicados en la norma y que cada
ao el SGSTI se mantiene y mejora dentro del ciclo de mejora continua.
De este modo, transcurrido un ao desde la certificacin, se planifica la primera
auditora de seguimiento (AS1) y, al ao de sta, se planifica la segunda auditora
de seguimiento (AS2).
9. Auditora de renovacin
Una vez cumplidos los 3 aos de validez, la certificacin expira (caduca) y se debe
realizar una auditora de renovacin de la certificacin (muy similar a la auditora
de certificacin fase II).
Tanto en las auditoras de seguimiento como en la de renovacin, tambin se emite
un informe en el que quedan reflejadas las no conformidades o incumplimientos. El
proceso de respuesta a las no conformidades mediante el plan de acciones correctivas
(PAC) se repite, as como, el de evaluacin y decisin.
Fuente: AENOR.
Figura 11.1.5. Ejemplo de certificado de Registro de Empresa ISO/IEC 20000
Si se siguen cumpliendo con los requisitos de certificacin, se otorga el manteni-

miento (en el caso de auditoras de seguimiento) o la renovacin (en el caso de
auditora de renovacin) del certificado. Al igual que en la auditora fase II, tam-
bin podra darse el caso que se necesitase de una auditora extraordinaria para
estos mantenimientos o renovaciones.
Resumen del ciclo de certificacin

El proceso de certificacin se puede esquematizar en los siguientes puntos:
1. Determinar el alcance de la certificacin. Definir los servicios y centros
sobre los que se aplicar el procedimiento de certificacin. En este punto, es
importante que la organizacin de TI solicitante realice un anlisis de su

situacin actual respecto a ISO/IEC 20000-1 para determinar el momento
adecuado de realizar la solicitud.
2. Solicitud de certificacin. La empresa que aspira a obtener la certificacin
realiza una solicitud de certificacin a una entidad acreditada, y esta entidad
confecciona una propuesta que enva al proveedor de TI solicitante para su
estudio, aprobacin y contratacin.
3. Auditora fase I: Anlisis de documentacin. La entidad de certificacin
estudia la documentacin del sistema de gestin de la empresa solicitante.
4. Auditora fase I: Visita previa. La entidad de certificacin realiza su tra-
bajo in-situ en el proveedor solicitante, con el objetivo de conocer la empresa
y evaluar la idoneidad del alcance solicitado de la certificacin; y analizar
cmo est implantado el sistema de gestin SGSTI. Esta etapa es el punto
idneo para resolver cualquier duda que surja por parte del proveedor de TI
solicitante o de la entidad de certificacin. Realmente la experiencia indica
que la visita previa es una activad clave para el xito del procedimiento de
certificacin.
La entidad de certificacin prepara el plan de auditora, que debe incluir pla-
nificacin de fechas y miembros del equipo de auditora, contenidos a audi-
tar, etc., que se entrega al proveedor de TI solicitante para su revisin y apro-
bacin.
5. Auditora fase II. La entidad de certificacin lleva a cabo la auditora fase II
de certificacin, sobre los servicios e instalaciones acordadas, del proveedor
solicitante. En el caso que existan no conformidades se emite un informe de
no conformidades, sealando las no conformidades o desviaciones detectadas.
Si es necesario, la organizacin solicitante debe realizar un plan de acciones
correctivas, que se pone en prctica para corregir las desviaciones detectadas,
y debe evidenciar la correccin de dichas desviaciones ante la entidad de cer-
tificacin.
6. Evaluacin y decisin. La entidad de certificacin, mediante un comit de
decisin, analiza y valora dichas acciones y en caso de valoracin positiva
concede el certificado.
7. Emisin del certificado. Con la decisin positiva se emite el certificado, con
el alcance establecido, a favor del proveedor de TI solicitante.
8. Auditoras de seguimiento. La entidad de certificacin, anualmente, realiza
auditoras de seguimiento del sistema de gestin certificado (AS1 y AS2),
normalmente seleccionando partes de dicho sistema y no la totalidad del

mismo, para comprobar su efectividad, levantando, en caso de encontrar
incumplimientos, las no conformidades necesarias que la organizacin ya
acreditada debe resolver mediante un nuevo plan de acciones correctivas.
9. Auditora de renovacin. Pasados tres aos desde la consecucin del certifi-
cado, la entidad de certificacin realiza una nueva auditora, en este caso muy
parecida a la auditora fase II, con el objetivo de prorrogar o cancelar la cer-
tificacin concedida.
11.2. Evidencias y registros importantes en una certificacin 751
11.2. Evidencias y registros importantes

en una certificacin
Figura 11.2.1. Esquema general de los registros y evidencias
En el presente apartado se recopilan los registros y evidencias considerados ms

importantes que ser necesario ir recopilando, como consecuencia de la implanta-
cin de cada uno de los procesos exigidos por la norma.
En el captulo 3 se aclaraba la diferencia entre estos conceptos de registro y evi-
dencia:
Un registro es el resultado tangible de la actividad de TI y de los procesos, por
ejemplo: el incidente registrado en la herramienta de gestin del incidente, una
encuesta de satisfaccin del cliente, una solicitud de cambio (RFC), unas medidas,
un informe del servicio, un SLA, un elemento en la base de datos de configuracin,
etc. Tambin son registros la documentacin del sistema y sus evoluciones.
Una aplicacin importante de los registros es la de proporcionar evidencias de
la conformidad del proveedor de TI con los requisitos de estas normas.
Las evidencias son cualquier documento o prueba que proporcione una demos-
tracin objetiva del cumplimiento de las normas por el proveedor de TI. Las
evidencias se obtienen de los registros y de cualquier otra forma que permita

probar que se cumplen los requisitos (por ejemplo, un documento, una com-
probacin, etc.).
Por tanto, las evidencias son el medio por el que se demuestra al resto de la organi-
zacin, a los clientes y a los auditores, el cumplimiento de los requisitos expresados
en la parte 1 de las normas ISO/IEC 20000. Las evidencias tambin demuestran
que se siguen los procesos y procedimientos que integran el sistema de gestin
de TI. El objetivo es poder mostrar de manera fehaciente la orientacin al servicio del
proveedor de TI, as como, el alineamiento con el negocio.
La generacin de evidencias no debe tener como fin satisfacer al auditor. No se
debe olvidar que la auditora ser mucho ms fcil de superar si el sistema de ges-
tin est adecuadamente implantado y afianzado. Cuando las evidencias son pro-
porcionadas por el trabajo diario surgen de forma natural, as, nadie debera estar
pensando en temas como:
ahora toca preparar el informe de seguimiento del proceso porque me lo piden para
la auditora,
sino que ms bien pensara en:

tengo que preparar el informe de seguimiento del proceso para presentarlo en el
comit de gestin del servicio de TI e informar de cmo est funcionando mi proceso y
cmo podemos mejorar su desempeo.
En la primera situacin, la evidencia se percibe como una carga (ms burocracia),

mientras que en el segundo, se ve como un instrumento que ayuda en el trabajo. Si
el sistema de gestin se ha planteado con sentido comn, pensando en las necesi-
dades de la organizacin, en el negocio y en los clientes, en ningn caso deberan
acudir a nuestra cabeza planteamientos similares al primer caso y, si es as, sera
mejor dejar de generar ese informe y buscar otra evidencia con verdadera utilidad.
Las evidencias muestran cmo los procesos generan resultados que al final, directa
o indirectamente, son necesarios para poder prestar el servicio de TI a los clientes.
Mediante las evidencias se demuestra que los procesos estn implantados, se ejecu-
tan segn lo previsto y los resultados son los adecuados. Es decir, las evidencias tie-
nen un valor intrnseco para los procesos y ayudan a satisfacer las necesidades de
los clientes.
En este captulo se proponen una serie de evidencias obtenidas de la experiencia
prctica de la certificacin, que se entienden como las ms comunes para demos-
trar el cumplimiento de los requisitos de la Norma ISO/IEC 20000-1. No quiere
decir que sea un listado exhaustivo o excluyente, pero s til, y en algunos casos
suficiente para determinadas organizaciones.
Por tanto, esta relacin no se puede considerar como obligatoria, simplemente pre-
tende ser una ayuda. Ser el auditor, en cada caso, el que determine cules son las
evidencias ms adecuadas para cada situacin. Dado que las evidencias son el modo
por el que la organizacin muestra que tiene control sobre cada uno de los proce-
sos que integran el sistema de gestin, habr que adaptar el nmero y el tipo de
evidencias que se van a recopilar a la realidad de cada organizacin y cmo stas
se asocian a cada proceso.
A continuacin se detallan, para cada uno de los procesos definidos en la Norma
ISO/IEC 20000-1 las evidencias asociadas.
Evidencias para 3. Requisitos de un sistema de gestin

Evidencias para 3.1. Responsabilidades de la direccin:
Acta de revisin del sistema por la direccin. Evidencia el compromiso de
la direccin con el sistema de gestin al comprobar el grado de despliegue,
as como las necesidades y propuestas de mejora. Al menos se realizar una
reunin al ao y siempre que a juicio del responsable del sistema de gestin
o de la direccin se estime necesaria.
Planificacin y seguimiento de objetivos. Expresa el compromiso de mejora
de la direccin. Los objetivos deben ser realistas pero retadores, cuantificables
y medibles. Es muy recomendable su desglose en acciones concretas que per-
mitan su ejecucin, as como asignar responsables de su consecucin.
Evidencias para 3.2. Requisitos de la documentacin:

Listado de documentacin del SGSTI. Contiene informacin sobre la ela-
boracin, aprobacin, mantenimiento, archivo y destruccin de la documen-
tacin (incluye evidencias del SGSTI).
Evidencias para 3.3. Competencia, concienciacin y formacin:

Responsables de los procesos, del SGSTI y de la gestin de los servi-
cios. Organigrama, definicin de los puestos y designacin de las personas a
los roles principales necesarios.
Currculum Vtae (CV). Registros de la educacin, formacin, habilida-
des y experiencia de empleados incluidos dentro del alcance. Currculum
firmado o declaracin de que la informacin que en l se contiene es

cierta.
Plan de formacin. Documento con el plan, que debe contener actividades
especficas de formacin en la gestin del servicio de TI especficas de estas
normas. Formacin en ITIL e ISO/IEC 20000. Con cursos en varios nive-
les, de fundamentos para la mayora de la organizacin de TI, de especialista
para los responsables de los procesos y de Service Manager para los gestores
de los servicios y para el responsable del SGSTI.
Cuestionario de evaluacin de la accin formativa. Cumplimentado por
parte de los asistentes a la accin de formacin.
Certificaciones profesionales. Certificaciones en ITIL e ISO/IEC 20000
acordes con las funciones que desempeen los profesionales.
Informe de evaluacin de la eficacia de la formacin. Cumplimentado
por la persona de la que dependen los asistentes a la formacin indicando
cmo la formacin recibida ha ayudado a los asistentes a mejorar el desem-
peo de su trabajo. Certificaciones obtenidas.
Evidencias relacionadas con el reclutamiento y seleccin de personal. Aqu pue-

den englobarse desde planes para la provisin de puestos de trabajo, a solicitudes de
incorporacin de personal, o los CV recopilados para un proceso en concreto.
Evidencias para 4. Planificacin e implementacin de la

gestin del servicio
Evidencias para 4.1. Planificacin de la gestin del servicio (plan). La evi-
dencia de su cumplimiento es el propio manual de gestin del SGSTI. Adems, el
alcance y el catlogo de servicios vigente.
Evidencias para 4.2. Implementacin de la gestin del servicio y la provisin
de los servicios (hacer). La evidencia de su cumplimiento es el manual de ges-
tin del SGSTI.
Evidencias para 4.3. Monitorizacin, medicin y revisin:
Informe de no conformidad.
Plan de acciones correctivas.
Plan anual de auditoras internas. Recoge la planificacin de auditoras
internas que se deben realizar. El nico requisito, es que en el plazo de un
ao se haya auditado todo el sistema de gestin, siempre antes de la audito-

ra de certificacin. Estas auditoras pueden ser realizadas por auditores que
pertenezcan a la compaa o, en su defecto, por un tercero independiente.
En cualquier caso debe respetarse el principio: No tener responsabilidad
directa sobre el trabajo que se va a auditar.
Informe de auditora interna.
Ficha de indicador. Proporciona informacin relativa al proceso, la descrip-
cin del indicador, el tipo de anlisis que se debe realizar, el lmite admisible, el
responsable del indicador, la frecuencia del anlisis, la recogida de resultados.
Cuadro de seguimiento del sistema de gestin. Recopila todos los indica-
dores, agrupados por procesos y en l se van reflejando los resultados de cada
uno de los indicadores, segn la periodicidad establecida. Proporciona una
fotografa del desempeo y eficacia del sistema de gestin. Habitualmente
es mantenido por el responsable del sistema. Estos indicadores deben tener
un valor objetivo a alcanzar o un umbral de control.
Cuadro de gestin de la mejora. Al igual que ocurre con los indicadores,
consolida todas las propuestas de mejora realizadas por cualquier actor del
sistema de gestin, una vez que han sido aprobadas por el responsable del
sistema o la direccin (segn proceda). Facilita el seguimiento de las mejoras
y su gestin.
Evidencias para 5. Planificacin e implementacin de

nuevos servicios o de servicios modificados
Requisitos de nivel de servicio (SLR). Documento que describe de forma
detallada las necesidades del cliente.
Documento de concepto (especificaciones del servicio SLS). Documento
que describe la relacin entre la funcionalidad requerida por el cliente y la
tecnologa empleada para implementarla.
Plan de calidad del servicio. Documento donde la organizacin TI especi-
fica la forma en la que ser entregado un servicio. Es el plan de proyecto de
creacin del servicio.
SLA asociados al servicio. Documentos que recogen los compromisos
acordados entre el cliente y la organizacin TI, para la provisin del servicio
requerido.
Documentacin del servicio (tcnica, comercial, econmica).
Evidencias para 6. Procesos de provisin de servicio

Evidencias para 6.1. Gestin de nivel de servicio:
Catlogo de servicios. Documento que elabora la organizacin TI para
informar a clientes y usuarios.
Catlogo de SLA.
Acuerdos de nivel operativo (OLA). Documentos que formaliza acuerdos
de colaboracin entre departamentos internos de la organizacin TI para la
provisin y entrega de un servicio.
Contratos de soporte (UC). Documentos contractuales entre la organiza-
cin TI y los proveedores externos de servicios.
Evidencias para 6.2. Generacin de informes del servicio:

Informes de servicio. Informes de cumplimiento de SLA, informes de inci-
dentes, informes de disponibilidad, informes de capacidad, etc.
Evidencias para 6.3. Gestin de la continuidad y disponibilidad del servicio:

Plan de disponibilidad. Recoge los elementos de la infraestructura de TI
que deben ser monitorizados para medir la disponibilidad, comparando los
valores obtenidos con los de referencia. Sirve como base para determinar el
cumplimiento de los niveles de servicio en los SLA.
Informes de disponibilidad. Informes peridicos que muestran el cumpli-
miento de los niveles de disponibilidad acordados.
Documentos de requisitos de nivel de servicio (SLR). Deben recoger los
requisitos de disponibilidad del servicio demandados por los clientes.
Plan de continuidad de TI. Identifica los activos del sistema de gestin de
servicios de TI, las situaciones de contingencia que pueden producirse, as como,
la probabilidad de que stas se produzcan. Muestra cmo cada una de estas
situaciones de contingencia pueden afectar a los activos; por tanto, proporciona
informacin de cmo afectan las contingencias a los servicios prestados.
Proporciona informacin sobre los siguientes aspectos:
Objetivo y alcance del plan de continuidad.
Descripcin de la situacin a controlar (informacin sobre el suceso y los
parmetros que se quieren mantener).
Suceso.
Riesgo a controlar y nivel.

Activos que intervienen.
Nivel de servicio exigido.
Tiempos para cada respuesta.
Criterio/s disparador (a partir del cual se activa el plan de continuidad).
Plan de respuesta.
Plan de respaldo.
Plan de recuperacin.
Plan de anlisis y mejora.
Plan de prueba.
Plan de pruebas de continuidad. Identifica el tipo de pruebas a realizar

para verificar la adecuacin de los planes de continuidad.
Informes de los resultados de las pruebas.
Evidencias para 6.4. Presupuestar y contabilizar servicios TI:

Presupuesto.
Informes de ejecucin del presupuesto.
Informes de gestin del presupuesto, como resultado de la contabilizacin
y tratamiento de desviaciones del presupuesto.
Evidencias para 6.5. Gestin de la capacidad:

Plan de capacidad.
Informacin de seguimiento de la capacidad. Base de datos de capacidad
y otras herramientas.
Evidencias para 6.6. Gestin de seguridad de la informacin:

Poltica de seguridad.
Anlisis de riesgos. Identifica los activos del SGSTI, necesarios para la pres-
tacin de los servicios; asocia amenazas a los activos y determina su nivel de
riesgo. Muestra el riesgo que soporta la organizacin.
Declaracin de riesgos.
Plan de tratamiento de riesgos de seguridad. Identifica los controles a

implantar para reducir el riesgo soportado de la organizacin.
Registros de seguridad.
Informes de seguridad.
Evidencias para 7. Procesos de relacin

Evidencias para 7.2. Gestin de relaciones con el negocio:
Muestra los documentos que se generan en las distintas fases, desde la identifica-
cin de las necesidades del cliente hasta la prestacin del servicio:
Propuestas de servicio al cliente (SLR).
Acuerdos de nivel de servicio firmados (SLA).
Informes de servicio.
Actas de seguimiento de clientes y resultados de encuestas de satisfaccin.
Evidencias para 7.3. Gestin de suministradores:

Poltica de gestin de suministradores y estrategia de sourcing.
Base de datos de suministradores y contratos (SCD). Conteniendo una
relacin de los servicios contratados, empresas y responsables.
Documentacin contractual del servicio (UC). Contrato, RFP, pedido o
documento similar.
Resmenes de los servicios contratados a los suministradores.
Informes del servicio de los suministradores.
Propuesta de resolucin anticipada del servicio.
Actas de reuniones con suministradores.
Evidencias para 8. Procesos de resolucin

Evidencias para 8.2. Gestin del incidente. Establecen los soportes en los que
registrar incidentes as como la explotacin de dichos soportes.
Base de datos de incidentes. Registro adecuado de la informacin. Histo-
rial de resolucin de los incidentes graves.
Relacin de soluciones temporales implantadas (workarounds).

Informes de incidentes. Cumplimiento de los niveles de servicio (atencin
y resolucin) pactados con el negocio.
Herramienta para la monitorizacin y gestin de eventos. Herramienta
que permite detectar incidentes de manera automtica, integrada con la base
de datos de incidentes.
Mejoras y formacin de la primera lnea de atencin. Identificacin de la
tasa de incidentes resueltos en primera lnea, registros de estos incidentes.
Evidencias para 8.3. Gestin del problema. Establece los soportes en los que
registrar problemas, adems de la documentacin asociada al mismo.
BD de problemas. Recoge los problemas identificados, proporcionando
informacin del estado en que se encuentran.
Documentacin de la resolucin asociada al problema. Accesible por las
lneas de soporte.
Comunicacin entre la gestin del incidente y del problema.
Evidencias para 9. Procesos de control

Evidencias para 9.1. Gestin de la configuracin. Incluye las evidencias que
se generan a la hora de planificar la configuracin y la definicin de la estructura de
la CMDB. La relacin entre los elementos de configuracin y su uso. Informacin
de auditora de la CMDB.
Plan de gestin de la configuracin, elaborado antes de crearse por pri-
mera vez la CMDB, o ante un cambio significativo en la misma. Contiene
informacin relativa a:
Propsito.
Objetivo.
Alcance.
Planificacin de actividades.
Organizacin.
Herramientas de soporte.
Anlisis de la Informacin disponible y sus fuentes.
Elementos de configuracin (CI). Informacin correcta sobre los compo-

nentes de los servicios en la CMDB.
Base de datos de gestin de la configuracin (CMDB). Actualizada.
Biblioteca de software definitivo (DSL). Actualizada.
Informes de la gestin de la configuracin.
Resultados de auditoras de la configuracin.
Evidencias para 9.2. Gestin del cambio:

Solicitudes de cambio (RFC). Debe poder diferenciarse qu RFC corres-
ponden a cambios urgentes frente al resto. Datos de las RFC correctamente
cumplimentados. Existencia de planes de marcha atrs.
Informes de disponibilidad prevista (PSA).
Informes de los resultados de las pruebas.
Informes de intervenciones.
Lista de cambios planificados (FSC).
Informes de revisiones post implementacin (PIR).
Lista de notificacin de intervencin sin registrar.
Actas del comit de cambios (CAB).
Evidencias para 10. Proceso de entrega de versiones

Evidencias para 10.1. Proceso de gestin de la entrega:
Poltica de entregas.
Hoja de control de entregas.
Documentacin tcnica de las entregas.
Planificacin de las entregas. Proporciona, al menos, informacin relativa
a: tareas, responsables, fechas y entregables.
Documentacin de compras asociadas a la entrega.
RFC aprobados asociados a las entregas. Las entregas deben ser controla-
das por el proceso de gestin del cambio.
Actualizacin de la informacin en la DSL y CMDB por este proceso.
Almacn definitivo de hardware (DHS). Existencia (si es necesario),

orden y etiquetado del almacn, y listado del control de su contenido.
Realizacin del PIR de las entregas. Informes que recogen los resultados
de la entrega y los compara con los previstos. Al final permite concluir si la
entrega ha cubierto las expectativas generadas o no.
Bibliografa y referencias
Publicaciones sobre ISO/IEC 20000

ISO 20000 Gua de Bolsillo (Spanish Version). Van Haren Publishing. ISBN:
9077212795.
ISO/IEC 20000 Una introduccin. Van Haren Publishing. ISBN: 978 90 8753
293 2.
Implementing ISO/IEC 20000 Certification. The Roadmap. ITSM LIBRARY.
Van Haren Publishing. ISBN: 978 90 8753 082 2.
Publicaciones sobre ITIL v2

Soporte de Servicio. OGC/HMSO. ISBN: 0 11 330981 3.
Provisin de Servicio. OGC/HMSO. ISBN: 0 11 330983 X.
Gestin de Servicios TI, basado en ITIL, una introduccin (Spanish Version), Van
Haren Publishing. ISBN: 9077212183.
Service Support. OGC/HMSO. ISBN: 0 11 330015 8.
Service Delivery. OGC/HMSO. ISBN: 0 11 330017 4.
ICT Infraestructure Management. OGC/HMSO. ISBN: 0 11 330865 5.
Planning to Implement Service Management. OGC/HMSO. ISBN: 0 11 330877 9.
Security Management. OGC/HMSO. ISBN: 0 11 330014 X.
Software Asset Management. OGC/HMSO. ISBN: 0 11 330943 0.
Application Management. OGC/HMSO. ISBN: 0 11 330866 3.
Business Perspective. OGC/HMSO. ISBN: 0 11 330894 9.
Publicaciones sobre ITIL v3

Introduction to ITIL 3 Service Lifecycle (English Version). OGC/HMSO. ISBN:
978 0 11 331061 6.
Estrategia del Servicio. OGC. ISBN: 978 0 11 331158 3
Diseo del Servicio. OGC. ISBN: 978 0 11 331226 9
Transicin del Servicio. OGC. ISBN: 978 0 11 331227 6
Operacin del Servicio. OGC. ISBN: 978 0 11 331150 7
Mejora Continua del Servicio. OGC. ISBN: 978 0 11 331146 0
Service Strategy. OGC/HMSO. ISBN: 978 0 11 331045 6.
Service Design. OGC/HMSO. ISBN: 978 0 11 331047 0.
Service Transition. OGC/HMSO. ISBN: 978 0 11 331048 7.
Service Operation. OGC/HMSO. ISBN: 978 0 11 331046 3.
Continual Service Improvement. OGC/HMSO. ISBN: 978 0 11 331049 4.
Foundations of IT Service Management Based on ITIL V3. ITSM LIBRARY, Van
Haren Publishing. ISBN: 978 90 8753 057 0.
Otras publicaciones de inters

IT Services Organisation. OGC/HMSO. ISBN: 0 11 330563 X.
Planning and Control for IT Services. OGC/HMSO. ISBN: 0 11 330548 6.
Quality Management for IT Services. OGC/HMSO. ISBN: 0 11 330555 9.
IT Service Management Case Studies. OGC/HMSO. ISBN: 0 11 330676 8.
Practices in Small IT Units. OGC/HMSO. ISBN: 0 11 330674 1.
World Class IT Service Management Guide, ten Hagen & Stam. ISBN: 90 76383 46 4.
The Guide to IT Service Management. Addison Wesley. ISBN: 0 20 173792 2.
Frameworks for IT Management. Van Haren Publishing. ISBN: 9077212906.
Metrics for IT Service Management. Van Haren Publishing. ISBN: 9077212698.
Vivek Nanda: ISO 9001:2000 Lograr la conformidad y la mejora continua en
empresas de desarrollo de software. AENOR Ediciones. ISBN: 978 84 8143 416 3
Bibliografa y referencias 765
Managing Successful Projects with PRINCE 2. The Stationary Office. ISBN: 0 11

330055 8.
Process Innovation, Davenport. HBS. Boston, Massachusetts (EEUU), 1993.
ISBN: 0 87584 366 2.
Normativa
UNE-ISO/IEC 20000-1:2007 Tecnologa de la informacin. Gestin del servicio.
Parte 1: Especificaciones.
UNE-ISO/IEC 20000-2:2007 Tecnologa de la informacin. Gestin del servicio.
Parte 2: Cdigo de buenas prcticas.
UNE-ISO/IEC 17021:2006 Evaluacin de la conformidad. Requisitos para los
organismos que realizan la auditora y la certificacin de sistemas de gestin.
UNE-ISO 10005:2005 Sistemas de gestin de la calidad. Directrices para los planes
de la calidad.
UNE-ISO/IEC 17799:2002 Tecnologa de la informacin. Cdigo de buenas prc-
ticas para la Gestin de la Seguridad de la Informacin.
UNE-ISO/IEC 27001:2007 Tecnologa de la informacin. Tcnicas de seguridad.
Sistemas de Gestin de la Seguridad de la Informacin (SGSI). Requisitos.
UNE 71044:1999 Tecnologa de la informacin. Procesos del ciclo de vida del soft-
ware.
UNE-EN ISO 9001:2008 Sistemas de gestin de la calidad. Requisitos.
ISO/IEC 15288:2008 Systems and software engineering System life cycle processes.
ISO/IEC 15504-1:2004 Information technology Process assessment Part 1: Con-
cepts and vocabulary.
ISO/IEC 15504-2:2003 Information technology Process assessment Part 2: Per-
forming an assessment.
ISO/IEC 15504-3:2004 Information technology Process assessment Part 3:
Guidance on performing an assessment.
ISO/IEC 15504-4:2004 Information technology Process assessment Part 4: Gui-
dance on use for process improvement and process capability determination.
ISO/IEC 15504-5:2006 Information technology Process Assessment Part 5: An
exemplar Process Assessment Model.
ISO/IEC TR 24774:2007 Software and systems engineering Life cycle manage-

ment Guidelines for process description.
Pginas web relacionadas

AENOR:
http://www.aenor.es
itSMF Espaa:
http://www.itsmf.es
itSMF International:
http://www.itsmf.org
ISO (Organizacin Internacional de Normalizacin):
http://www.iso.net
JTC1/SC7, subcomit perteneciente al comit tcnico conjunto entre ISO e
IEC denominado JTC1 Tecnologas de la informacin, responsable del desarrollo
de las normas en el rea de ingeniera del software y de los sistemas.
http://www.jtc1-sc7.org
ISO 20000 Central (antes BS15000 Central)
http://20000.fwtk.org
Portal de Soporte de ITIL e ISO 20000
http://www.15000.net
EXIN (Certificacin de profesionales en el mbito de ISO 20000)
http://www.exin.org
APMG (Certificacin de profesionales en el mbito de ISO 20000)
http://www.apmgroup.co.uk
CMMI (Capability Maturity Model Integration)
http://www.sei.cmu.edu/cmmi/
eSCM (eSourcing Capability Model)
http://itsqc.cmu.edu/models/index.asp
COBIT (Control Objectives for Information and related Technology)
http://www.isaca.org/cobit.htm
ISPL (Information Services Procurement Library)
http://projekte.fast.de/ISPL/
eTOM (enhanced Telecom Operations Map)
http://www.tmforum.org
Trminos y definiciones
Activo (Asset): Componente de un servicio de TI. Los activos pueden incluir per-
sonas, alojamiento, sistemas de ordenadores, redes, registros manuales, fax, etc.
Acuerdo de nivel de servicio (SLA): Un acuerdo escrito entre el proveedor de
servicio y cliente, que documenta niveles de servicio acordados por un servicio.
Acuerdos de colaboracin operacional (OLA): Un acuerdo interno que da
cobertura a los servicios que soporta la organizacin de TI en su prestacin
de servicios al cliente.
Anlisis del impacto (impact analysis): La identificacin de procesos de negocio
crticos, y el dao potencial o la prdida que se puede causar a la organizacin
como resultado de una interrupcin a estos procesos.
Anlisis del riesgo: La identificacin y evaluacin del nivel (medida) de los ries-
gos, calculado a partir del valor de los activos y de los niveles evaluados de ame-
nazas y vulnerabilidades a los que estn expuestos dichos activos.
Autoridad de cambios (Change authority): Grupo al que se delega autoridad de
aprobacin de los cambios, por ejemplo por un comit de proyectos. Algunas
veces tambin se le conoce como comit de configuracin.
Base de datos de la gestin de la configuracin (CMDB): Una base de datos
que contiene todos los detalles relevantes de cada CI y detalles de relaciones
importantes entre los CI.
Biblioteca de software: Una coleccin controlada de CI software designada para
mantener juntos esos que tienen estados o gneros similares y segregados de
esos que no se parecen, para ayudar en desarrollo, operacin y mantenimiento.
Biblioteca de software definitivo (DSL): Repositorio en el que se almacenan y
protegen las versiones autorizadas definitivas de todos los CI software. Se trata
de un espacio fsico o de un repositorio de almacenamiento donde se sitan las

copias master de las versiones de software.
Cambio (Change): Adicin, modificacin o eliminacin referida a hardware,
redes, software, aplicaciones, entornos, sistemas, implementaciones o documen-
tacin relacionada, previamente aprobados, de apoyo o base.
Catlogo de servicios (Service catalogue): Documento que elabora la organiza-
cin TI para informar a clientes y usuarios. Proporciona una visin esquem-
tica, en trminos de negocio, de todos los servicios de negocio y de la infraes-
tructura ofrecidos por el proveedor TI, pudiendo reflejar los precios de los
servicios. Esta informacin, acompaada de un nivel ms detallado de conoci-
mientos tcnicos ha de ser mantenida para su uso interno.
Categora (Category): Clasificacin de un grupo de CI, documentacin de cam-
bios y/o problemas.
Centro de servicio al usuario (Service desk): El punto nico de contacto dentro
de la organizacin de TI, para los usuarios de servicios informticos.
Ciclo de vida (Life-cycle): Serie de estados interrelacionados, con pasos entre los
mismos, definidos y estipulados segn la metodologa de Procesos. El ciclo de
vida comprende el proceso de aprobacin para CI, informes de problemas y
documentacin del cambio.
Cierre (Closure): Cuando el cliente est satisfecho de la resolucin de un inci-
dente.
Clasificacin (Classification): Proceso de agrupacin formal de CI segn su tipo,
por ejemplo: software, hardware, documentacin, entorno, aplicacin.
Cliente (Customer) El receptor de un servicio. Habitualmente Gestin de clientes
tiene bajo su responsabilidad el coste del servicio, bien sea por su facturacin o
indirectamente en trminos imputables a necesidades del negocio.
Comit de cambios (Change Advisory Board): Grupo con experiencia en aseso-
ramiento de gestin de cambios, que puede valorar y aconsejar la implementa-
cin de los cambios propuestos. Este rgano suele estar formado por represen-
tantes de todas las reas de tecnologas de la informacin y por representantes
de las unidades de negocio.
Contrato de soporte (Underpinning contract): Un contrato con un proveedor
externo que cubre la entrega de servicios que dan soporte a la organizacin de
TI, en la provisin de servicios a los clientes.
Control de configuracin (Configuration control): Actividad cuyo objetivo es
garantizar que slo los CI autorizados e identificables se registran en la CMDB.
Trminos y definiciones 769
Esta actividad est enfocada a proteger la integridad de los datos, sistemas y

procesos de la compaa, manteniendo una relacin muy estrecha con gestin
del cambio.
Control del cambio (Change control): Procedimiento utilizado para garantizar
que todos los cambios estn controlados, incluido el envo, anlisis, toma de
decisiones, aprobacin, implementacin y postimplementacin de un cambio.
Control del proceso (Process control): El proceso de planificacin y regulacin,
con el objetivo de realizar un proceso de una manera eficaz y eficiente.
Coste (Cost): La cantidad del gasto (real o terico) incurrido, o atribuido a una
actividad especfica o unidad de negocio.
Coste directo (Direct cost): Un coste incurrido que puede ser asignado de forma
especfica y exclusiva a un servicio, centro de coste o departamento. Los costes
directos son los directamente relacionados con materiales, salarios y gastos espe-
cficos.
Coste indirecto (Indirect cost): El coste incurrido en el transcurso de la fabrica-
cin de un producto que proporciona un servicio, o un coste de gestin global
o departamental, pero que no puede ser relacionado directamente y por com-
pleto al producto, el servicio o el departamento, porque ha sido incurrido para
diferentes centros/ unidades de coste. Estos gastos son repartidos entre las uni-
dades/centros de coste. Los costes indirectos tambin son gastos generales.
Coste marginal (Marginal cost) El coste de proporcionar el servicio actual,
creado por una inversin ya realizada.
Coste total (Full cost): El coste total de todos los recursos usados en suministro
de un servicio, por ejemplo, la suma de los gastos directos de producir el pro-
ducto, una parte proporcional de los costes de estructura y cualquier gasto de
venta y distribucin. Tantos gastos en efectivo como los gastos tericos (no
monetarios) deberan ser contemplados, incluido el coste de capital.
Coste total de propiedad (TCO, Total Cost of Ownership): Clculo que incluye
depreciacin, mantenimiento, costes del personal de apoyo a la direccin, aloja-
miento, y la revisin de planificaciones.
Costes de produccin: El coste total de los recursos directos: materiales, mano
de obra y gastos. El trmino costes de produccin normalmente se reserva para
aplicarlo a los costes directos de produccin, y por ello, habitualmente, no
incluye los costes directos de marketing o I + D.
Costes operacionales: Los costes incurridos por el funcionamiento diario de
los servicios de TI, por ejemplo los costes de personal, los de electricidad y
mantenimiento del hardware, y los atribuibles a los pagos continuados cuyo

efecto se puede medir dentro de un perodo corto de tiempo, normalmente
menor a los doce meses del ao financiero.
Costes unitarios (Unit costs): Costes distribuidos por el uso de un componente
individual. Por ejemplo, puede asumirse que, si una caja de papel con 1.000
hojas cuesta 10 euros, entonces cada hoja cuesta 0,01 euros. De la misma manera
si el coste de una CPU es 1 euro al ao y se utiliza para procesar 1.000 trabajos
en ese ao, cada trabajo cuesta una media de 1.000 euros.
Cuadro de mando (BSC, Balanced Scorecard): Es una ayuda a la gestin del
rendimiento de la organizacin. Permite poner foco no slo en los objetivos
financieros, si no tambin en los procesos internos, clientes y los aspectos de
crecimiento y conocimiento.
Disponibilidad (Availability): Capacidad y accesibilidad de un componente o
servicio para realizar su funcin en un momento definido o durante un perodo
de tiempo establecido; normalmente expresada como ratio de disponibilidad,
esto es, la proporcin del tiempo en que el servicio est disponible para ser utili-
zado por los clientes dentro del horario de servicio acordado.
Documento de cambio (Change document): Solicitud de cambio, orden de con-
trol de cambio, orden de cambio, registro de cambio.
Elemento de configuracin (CI): Componente de una infraestructura, o de un
elemento, como una peticin de cambio, relacionado con la infraestructura, que
est (o vaya a estar) bajo el control de la gestin de la configuracin. Los CI
pueden ser muy diferentes en complejidad, tamao y tipo, desde un sistema
completo (incluyendo todo el hardware, software y documentacin) hasta un
nico mdulo o un simple componente hardware.
Entorno (Environment): Coleccin de hardware, redes de comunicacin y proce-
dimientos que funcionan de manera conjunta para proporcionar un servicio
informtico. Pueden existir uno o ms entornos diferentes en una plataforma
fsica, por ejemplo pruebas, produccin, etc. Un entorno tiene unas caractersti-
cas nicas que determinan su modo de administracin.
Entrega (Release): Una serie de CI nuevos y/o modificados que se prueban e
introducen en el entorno de produccin de manera conjunta.
Entrega completa (Full release): Contiene todos los componentes de la unidad
de entrega, que se desarrollan, prueban, distribuyen e implementan a la vez.
Entrega delta (Delta release): Una entrega delta, o parcial, slo incluye aquellos
CI de la unidad de entrega que se hayan modificado o renovado desde la ltima
entrega realizada. Por ejemplo, si la unidad de entrega es el programa, una
entrega delta contendr slo aquellos mdulos que hayan sido modificados o
renovados desde la ltima entrega.
Error conocido (KE, Known Error): Aquel incidente, o aquel problema, cuya causa
raz se conoce y para la que se ha identificado un arreglo provisional o una alterna-
tiva permanente. Ante un caso con impacto en el negocio se realizar una solicitud
de cambio (RFC), pero siempre seguir considerndose como error conocido
hasta su solucin permanente mediante el correspondiente cambio.
Estructura de la configuracin (Configuration structure): Jerarqua de todos
los CI que conforman una configuracin.
Externalizacin: El proceso mediante el cual las funciones realizadas por la orga-
nizacin son contratadas externamente para la operacin por terceros en nom-
bre de la organizacin.
Funcin de negocio (Business function): Una unidad de negocio en la organiza-
cin, por ejemplo, un departamento, divisin, oficina, etc.
Gestin de la configuracin (Configuration management): Proceso que se
ocupa de la identificacin y definicin de los CI de un sistema, registrando e
informando sobre el estado de los CI y las RFC (solicitudes de cambio), y veri-
ficando la exactitud y correccin de dichos CI.
Gestin de nivel de servicio (Service level management): El proceso encargado
de definir, acordar, documentar y gestionar los niveles de servicio al cliente,
segn sus requerimientos y con unos costes justificados.
Gestin de servicios (Service management): Gestin de los servicios segn los
requisitos del cliente.
Gestin del cambio (Change management): Proceso de control de los cambios
de cualquier aspecto de los servicios, o en la infraestructura, de un modo con-
trolado, permitiendo llevar a cabo los cambios aprobados con el mnimo
impacto en el servicio.
Gestin del coste (Cost management): Todos los procedimientos, tareas y entre-
gables necesarios para satisfacer el coste de una organizacin y los requerimien-
tos de precio.
Herramienta de gestin de la configuracin (Configuration management tool):
Un producto software que proporciona asistencia automatizada para el control
de cambios, configuracin y versiones.
Hoja de especificaciones (SS, SpecSheet): Especifica detalladamente lo que el
cliente quiere (externo) y que consecuencias tiene para el proveedor de servicio
(interno), como recursos requeridos y habilidades.
Identificador de versin: Un nmero de versin; da de versin; o da de versin

y marca de hora.
Impacto (Impact): Medida de la criticidad que tiene para el negocio un incidente,
problema o solicitud de servicio. Usualmente se identifica con el plazo temporal
en el que no son respetados los acuerdos o los SLA esperados.
Incidente (Incident): Cualquier suceso que no forme parte del funcionamiento
estndar de un servicio y que motive, o pueda motivar, una interrupcin o una
reduccin de la calidad de dicho servicio.
ISO 9001: Conjunto de normas internacionalmente aceptado en relacin a la cali-
dad de la gestin de sistemas.
ITIL: Biblioteca de la Infraestructura de TI de la OGC, un conjunto de guas
sobre la gestin y provisin de servicios TI operativos.
Lnea base o de referencia (Configuration baseline): La configuracin de un
producto o sistema establecida en un momento determinado, que recoge tanto
la estructura como los detalles de ese producto o sistema; y que permite que ese
producto o sistema pueda reimplantarse posteriormente.
Lista de cambios planificados (FSC, Forward Schedule of Changes): Lista que
recoge en detalle todos los cambios cuya implantacin ha sido aprobada, as
como las fechas planificadas para tal implantacin. Debe ser acordada con los
clientes y el negocio, gestin de niveles de servicio, el servicio de atencin tc-
nica y gestin de la disponibilidad. Una vez acordada, el centro de servicio al
usuario deber comunicar de forma exhaustiva a los usuarios los cambios plani-
ficados y cualquier parada que se presente en la implantacin de los cambios,
utilizando para ello los mtodos disponibles ms eficaces.
Mtrica (Metric): El elemento de medida de un servicio, proceso o funcin.
Peticin de servicio (Service request): Todo incidente que no se considera un fallo
propio de la infraestructura TI.
Plan de calidad de servicio (SQP, Service Quality Plan): El plan escrito y espe-
cificado de objetivos internos diseados para garantizar los acuerdos de nivel de
servicio.
Plan de gestin de configuracin (Configuration management plan): Docu-
mento que define la organizacin y los procedimientos de gestin de la configura-
cin para un producto, proyecto, sistema, grupo de soporte o servicio especfico.
Plan de recuperacin/contingencia (DRP, Disaster Recovery Planning): Serie
de procesos orientados especficamente a la recuperacin ante desastres,
principalmente de naturaleza fsica, y que son materia de la gestin de la con-

tinuidad del negocio.
Prioridad (Priority): La secuencia en la que es necesario resolver un incidente o
un problema, basndose en su impacto y urgencia.
Problema (Problem): La causa desconocida que subyace a uno o ms incidentes.
Proceso (Process): Una serie de acciones, actividades, cambios, etc., conectados
entre s y realizados por agentes determinados, con la intencin de lograr un
propsito o alcanzar un objetivo.
Proceso de negocio (Business process): Un grupo de actividades asumidas por la
organizacin en la bsqueda de un objetivo comn. Los procesos tpicos de
negocio incluyen la recepcin de pedidos, servicios de marketing, venta de pro-
ductos, provisin de servicios, distribucin de productos, facturacin de servi-
cios, contabilidad de los ingresos. Un proceso de negocio habitualmente soporta
varias funciones de negocio diferentes, por ejemplo, TI, personal, alojamiento.
Un proceso de negocio difcilmente funciona aislado, es decir, otros procesos de
negocio dependern de l y l depender de otros procesos.
Programa: Un conjunto de actividades y proyectos que implementan de forma
conjunta un nuevo requerimiento o funcin corporativa.
Programa de mejora de servicio (SIP, Service Improvement Programme): Un
proyecto formal emprendido dentro de una organizacin para identificar e
introducir mejoras medibles dentro de un rea o proceso de trabajo.
Proveedor de servicio (Service provider): Organizacin de terceros que suminis-
tra servicios o productos a clientes.
Proveedor tercero (Third-party supplier): Una empresa o grupo, externo a la
empresa del cliente, que proporciona servicios y/o productos a la empresa de
aquel.
Registro del cambio (Change record): Registro que contiene detalles sobre los
CI afectados por un cambio autorizado (planificado o implementado) y cmo
resultan afectados.
Repositorio de software (Software library): Una serie controlada de CI de soft-
ware designado para mantener juntos los que tengan un estado y tipo similares,
y separados de los que sean distintos, sirviendo as de ayuda para el desarrollo,
las operaciones y el mantenimiento.
Riesgo: Una medida de la exposicin a un evento inesperado a la que puede estar
sujeta una organizacin. Es una combinacin de la probabilidad de ocurrencia
de una interrupcin del negocio y de las posibles prdidas que pueda ocasionar
dicha interrupcin.
Rol (Role): Una serie de responsabilidades, actividades y autorizaciones.
Servicios (Services): Entregables de la organizacin de servicios informticos que
son percibidos por los clientes; los servicios no consisten simplemente en hacer
disponibles los recursos de ordenadores para el uso de los clientes.
Sistema (System): Conjunto integrado de uno o ms procesos, hardware, software,
utilidades y personal, que proporciona la capacidad de satisfacer una necesidad
o un alcanzar objetivo determinado.
Solicitud de cambio (RFC, Request For Change): Formulario o pantalla usada
para registrar los detalles de una solicitud para un cambio a cualquier CI dentro
de la infraestructura o para procedimientos y elementos asociados con la infraes-
tructura.
Solucin temporal (Workaround): Mtodo para evitar un incidente o un pro-
blema, bien mediante un arreglo provisional o mediante una tcnica que impli-
que que el cliente no dependa de un aspecto especfico del servicio del cual se
sepa que presenta un problema.
TIC (ICT) / TI (IT): La convergencia de Informacin Tecnolgica, Comunica-
ciones y Datos.
Unidad de negocio: Una divisin de una entidad de negocio en la que los ingre-
sos son registrados y los gastos incurridos se controlan, de forma que los ingre-
sos y gastos se usan para evaluar el rendimiento de la divisin.
Urgencia (Urgency): Medida de la criticidad para el negocio de un incidente o
un problema, basada en su impacto sobre las necesidades de negocio de los
clientes.
Usuario (User): La persona que utiliza los servicios de manera habitual.
Usuario final (End-User): Vase Usuario.
Versin (Version): Elemento identificado de un CI, dentro de la estructura des-
glosada de un producto o en la estructura de configuracin, que sirve de refe-
rencia para el seguimiento y auditoria del historial de cambios. Tambin se uti-
liza en los SCI, definindose una referencia especfica en el desarrollo para el
diseo, revisin, modificacin, pruebas o produccin.
Versin completa (Full release): Todos los componentes de la unidad de entrega
que se desarrollan, prueban, distribuyen e implementan a la vez. Vase tambin
versin delta.
Versin delta (Delta release): Una versin delta o parcial, es aqulla que sola-
mente incluye los CI de la unidad de entrega que se hayan modificado o reno-
vado desde la ltima entrega completa o parcial (delta). Por ejemplo, si la uni-
dad de versin es el programa, una versin delta contendr solo aquellos
mdulos que hayan sido modificados o renovados desde la ltima entrega com-
pleta del programa o desde la ltima versin delta de determinados mdulos.
Vase tambin Versin completa.

ISO20000 GuiaCompletadeAplicacion LuisMoran

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ISO20000 GuiaCompletadeAplicacion LuisMoran

Caricato da

Copyright:

Formati disponibili

ISO/IEC 20000.

Gua completa de aplicacin

AENOR (Asociacin Espaola de Normalizacin y Certificacin), 2009

Autores principales (Telefnica):

Toms Hernndez Lpez (Telefnica)

El control independiente de idoneidad tcnica de los contenidos est avalado

Agradecer tambin a la direccin de Sistemas de Informacin de Telefnica que de

Captulo 1. El camino a la excelencia ya existe . . . . . . . . . . . . . . . . . . . . . 21

Captulo 2. Entender las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . 51

Captulo 3. El Sistema de Gestin del Servicio de TI (SGSTI) . . . . . . . . . . . . 79

Captulo 4. Planificacin e implementacin de la gestin del servicio . . . . . 107

Captulo 5. Planificacin e implementacin de nuevos servicios o de

Captulo 6. Procesos de provisin de servicio . . . . . . . . . . . . . . . . . . . . . . . 191

Captulo 7. Procesos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

Captulo 8. Procesos de resolucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

Captulo 9. Procesos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Captulo 10. Procesos de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Captulo 11. La certificacin conforme a ISO/IEC 20000 de la gestin

Bibliografa y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

Trminos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Las tecnologas de la informacin son cada da ms necesarias en la gestin de las

Por ello, no es de extraar que encontremos frecuentemente que los departamentos

La dinmica industria de tecnologas de la informacin y las comunicaciones

Objeto del libro

cualquier tipo de organizacin que provea servicios de tecnologa, tanto interna-

Estructura del libro

El captulo 2 Entender las Normas ISO/IEC 20000 las posiciona en el mbito

1 Objeto y campo de aplicacin 0 Introduccin

2 Trminos y definiciones 1 El camino de la excelencia ya exite

2 Entender las normas ISO/IEC 20000

3 Requisitos de un sistema de gestin 3 El Sistema de Gestin del Servicio de TI (SGSTI)

4 Planificacin e implementacin de la gestin del servicio

5 Planificacin e implementacin de nuevos servicios o de servicios modificados

6 Procesos de la provisin del servicio

11 La certificacin conforme a ISO/IEC 20000

Bibliografa 12 Bibliografa y referencias

Figura I.1. La estructura del libro transcurre paralela

Recorrido 2: lectura secuencial y a fondo. De principio a fin, que es la

1. El camino a la excelencia ya existe 23

1.1. Las Normas ISO/IEC 20000 son parte del

1.2. Normas, estndares, marcos de referencia

1. El camino a la excelencia ya existe 25

9001 ISO ITIL v2 ISO TOGAF

Fuente: Gartner y e.p.

Figura 1.1. Mapa de las diferentes normas y marcos de referencia

La gestin de la seguridad de los sistemas de informacin ha sido una de las reas

1. El camino a la excelencia ya existe 27

1.3. Entender los entornos de normalizacin y

marcos de mejores prcticas (organismos de normalizacin internacional, organis-

USA: ANSI Mellon

Gobiernos Gobierno del pas OGC DoD ISACA PMI

(UK) (USA) (USA) (USA)

ISO/IEC ISO 17799-

ISO/IEC ISO/IEC BS 25999 Prince2

Figura 1.2. Actores en el mbito de la normalizacin relacionados con las TI

En el mbito de la normalizacin internacional, los organismos de normalizacin

1. El camino a la excelencia ya existe 29

En la etapa 2, o preparatoria, se emite el borrador de la norma en fase CD. En la

Proceso de elaboracin de una Proceso de elaboracin de una

1. Etapa de propuesta 1. Trabajos preliminares

Fuente: ISO y e.p. Fuente: AENOR

Figura 1.3. Procedimientos de creacin de normas internacionales y nacionales

A continuacin, se presenta una visin general de los principales actores en este