Entender ITIL 2011normas y Mejores Prácticas para Avanzar Hacia ISO 20000

Entender ITIL
2011Normas y
mejores prcticas para
avanzar hacia ISO 20000
Prefacio de Martin CROSS - General
Manager
MCS
Associates
El objetivo de este libro sobre ITIL es
proporcionar al lector todas las claves para
un correcto entendimiento de los procesos
ITIL
2011 y
su
organizacin.
El libro est estructurado a partir de la
nocin de ciclo de vida de los servicios .
El libro servir de hilo conductor para
aquellos
que
ya
hayan
seguido
una formacin
ITIL
Foundation
(Versin 3 o 2011) y permitir, a todos
los que an no tienen ningn conocimiento
sobre la materia, descubrir y entender
las contribuciones de ITIL en la gestin
de
los
servicios,
as
como
la metodologa para tener xito en la
implantacin
ITIL
en
la
empresa,
independientemente
de
su
tamao.
A lo largo de todo el libro, el autor utiliza su
experiencia profesional como Consultor y
Formador ISO 9001 e ITIL, y presenta las
diferentes normas que permiten situar
correctamente a ITIL 2011 y a considerar
una posiblecertificacin ISO 20000. Para
ello, se dedica una serie de captulos a
lasnormas, mtodos y herramientas que
facilitan la puesta en marcha y gestin de
un
entorno
ITIL.
En cada una de las secciones dedicadas a
un proceso ITIL, el autor destaca
las principales
relaciones entre
los
diferentes procesos ITIL, as como los
posibles beneficios y principales dificultades
que pueden aparecer. Esto permite al lector
entender la anidacin de los procesos y las
implicaciones
que
esto
tiene.
El ltimo captulo presenta un caso
prctico de puesta en marcha de un
proyecto ITIL en una empresa y permite
entender mejor el desarrollo de este tipo de
proyectos.
Los
captulos
del
libro:
Prefacio Prlogo ITIL y las normas El
ciclo de vida de la gestin de los servicios
Material de
descargaArchivos
adicionales
Publicacin: octubre
2012
Ref. ENI : DPT11ITI
ISBN : 9782746076181
Share on facebookShare
on email
Los procesos de la estrategia de servicios

Los procesos del diseo de los servicios
Los procesos de la transicin de los
servicios Los procesos de la explotacin
de servicios Mejora continua de servicios
(CSI) Puesta en marcha de un proyecto
ITIL Anexos
Jacques QUESNEL
Jacques QUESNEL est cerficado en ITIL
Foundation V2 y V3 - Trainer Accredited ITIL
Foundation V2 y V3 Experto en Calidad ISO 9001.
Aplica los procesos ITIL desde hace muchos aos en
los proyectos de Experto en Calidad que ha
desarrollado en diferentes empresas. Es toda esta
experiencia, tanto tcnica como pedaggica, la que hoy
le permite proponer un libro claro y prctico de la
puesta en marcha del referencial ITIL.
Prefacio
En el mundo actual, la gestin de una empresa obliga a tener mltiples competencias,
conocimientos y herramientas adaptadas. Al mismo tiempo, la empresa se debe enfrentar a
retos y restricciones importantes. En este contexto, los sistemas de informacin juegan un
papel estratgico principal, que tienen influencia incluso sobre la supervivencia de la
empresa. De esta manera, la correcta gestin de los sistemas de informacin y las
elecciones organizativas determinan, de una manera importante, el buen funcionamiento
de la empresa.
En el momento actual las empresas dependen, cada vez en mayor medida, de sus sistemas
de informacin, cuyos requerimientos se hacen sentir tanto a nivel financiero como a nivel
de la rapidez con la que la direccin de los sistemas de informacin debe responder a las
necesidades de las empresas, siempre cambiantes, con una complejidad de los sistemas de
informacin cada vez ms importante. Si adems de todo esto consideramos las nuevas
tecnologas, movilidad, distribucin geogrfica, externalizacin de los servicios y
conectividad, entenderemos con facilidad que la direccin de los sistemas de informacin
tengan obligatoriamente que hacer malabares con todos estos elementos para poder
ofrecer servicios de calidad para los negocios.
As, cada vez ms las empresas y su direccin de sistemas de informacin tienen en
consideracin el uso de estndares, mtodos y marcos de trabajo de dominio pblico, con
el objetivo de mejorar la gestin de su sistema de informacin. Pero existen muchas
opciones y es fcil perderse en este laberinto.
Entre las diferentes opciones relacionadas con la gestin de los servicios, hoy en da ITIL
representa una de las maneras ms habituales para estructurar las direcciones de los
sistemas de informacin de una forma clara y efectiva, basndose en las buenas prcticas
reconocidas a travs de todo el mundo. En la actualidad, ITIL est reconocido como un
estndar de facto para la gestin de los servicios informticos. Pero hay que reconocer que
ITIL, debido a su actual evolucin, sigue siendo una materia complicada para un nefito y
es fcil perderse entre las innumerables posibilidades que ofrece.
El presente libro propone, de una manera concisa y precisa, una visin de conjunto de ITIL,
cubriendo todos los procesos, y presenta varias facetas de su aplicacin. De esta manera,
es un placer para m felicitar a Jacques Quesnel por haber tenido xito en la presentacin
del conjunto de conceptos ITIL en un nico libro, bien estructurado y de lectura agradable.
Jacques Quesnel, al que tengo el placer de conocer personal y profesionalmente, acumula
una amplia experiencia en esta rea, que le permite documentar sus conocimientos en la
puesta en marcha de los conceptos ITIL, as como en su gestin. Puesto que una buena
receta no hace al buen cocinero, es necesario saber mezclar los componentes de manera
correcta, para obtener un buen resultado. A travs de las mltiples puestas en marcha de
ITIL que he visto en todo el mundo, puedo comprobar con tristeza que, de manera
habitual, las empresas no aprovechan al mximo los beneficios que ofrece ITIL, ya sea por
falta de entendimiento de los conceptos o por una incorrecta aplicacin de estos. Por este
motivo, la experiencia de Jacques Quesnel representa una mina importante de informacin
y recomendaciones propuestas en el libro. Esto representa un enorme beneficio para el
lector que busque respuestas claras en esta rea, tan fascinante como compleja.
Tambin es importante observar que el libro proporciona una vista de varios mtodos,
estndares y marcos de trabajo que permiten aprender la gestin de los sistemas de
informacin con un enfoque ms global, y posicionar ITIL entre sus compaeros de viaje.
Permtanme una ltima reflexin: poco importan los esfuerzos realizados para emprender
algo; si no hacemos las elecciones correctas, los resultados no sern los esperados.
Este libro permitir al lector tomar las elecciones correctas para obtener los beneficios que
puedan aportar un enfoque ITIL bien entendido y gestionado.
Martin Cross
General Manager MCS Associates
Coparticipante de la creacin del mtodo TIPA
Participante de los grupos de trabajo ISO 20 000 y 15 504
PROLOGO
Una nueva versin de este libro
Las buenas prcticas ITIL evolucionan.
En 2011, la OGC ha publicado una nueva versin de ITIL.
Una de las primeras novedades de ITIL 2011 est en la nomenclatura de las versiones.
Para estar alineado con las reglas de nomenclatura de las versiones de las normas ISO, a
partir de ahora el nivel de versin se indica por el ao de publicacin, lo que simplifica la
identificacin de las versiones.
Por lo tanto, la nueva versin de ITIL es ITIL 2011.
Sin ser una versin principal, esta versin aade cambios, fundamentalmente en la fase
estratgica del servicio, y explica algunos puntos que no estaban lo suficientemente claros
en la versin ITIL V3.
Por lo tanto, era importante hacer que este libro evolucionara para que permaneciera
actualizado.
ITIL Y LAS NORMAS
ITIL
ITIL (Information Technology Infrastructure Library, que traducido literalmente significa
Librera de infraestructura de las tecnologas de informacin), es un conjunto de libros en
los que se presentan numerosas prcticas, procedimientos y mtodos utilizados en la
gestin de servicios informticos.
ITIL es una recopilacin de las mejores prcticas aplicadas desde hace aos en
organizaciones de tamao ms o menos importante.
Por tanto, ITIL se utiliza como lnea directriz en la implantacin de una gestin de servicios
en un entorno informtico.
Los procesos descritos en ITIL se ponen en marcha, en su totalidad o parte de ellos, en
funcin de su empresa, actividad, tamao y objetivos estratgicos.
1. Histrico
1972: comienzo de los trabajos de desarrollo de las prcticas por la CCTA (Central
Computing and Telecommunication Agency).
1990: publicacin de los primeros elementos por el organismo gubernamental

britnico CCTA.
1991: primer examen de certificacin ITIL.
2001: publicacin de la segunda versin de ITIL (ITIL V2).
2005-2006: evolucin importante en el mbito de las certificaciones.
Finales de 2005: adopcin de la norma ISO/CEI 20000 para las empresas, basadas
en el marco ITIL.
2007: publicacin de ITIL-Refresh (ITIL V3).
2011: publicacin de la nueva versin (ITIL 2011).
a. Qu no es ITIL?
ITIL no es:
Un lenguaje.
Un proceso.
Un mtodo.
Una norma.
b. Qu es ITIL?
Un conjunto de manuales que describen los procesos integrados de gestin de las TI
(tecnologas de la informacin).
Un marco de referencia global que:
Describe las mejores prcticas de gestin de los servicios de TI.
Pertenece al dominio pblico.
Es independiente de los fabricantes de TI (software y hardware) y de las empresas

de consultora, aunque ampliamente reconocido por estas ltimas.
2. Los actores
El principal actor es el OGC (Office of Government Commerce), que es el propietario de los
derechos de ITIL.
Otro actor importante es el itSMF (it Service Management Forum). Existen foros en la
mayora de los pases, tambin en Espaa (http://www.itsmf.es).
Hay ocho organismos de certificacin (Examination Institutes):
APMG-UK
EXIN
ISEB
Loyalist College (LCS)
Dansk IT
DF Certifiering
TUV SUD
CSME
Estos son los nicos organismos que pueden entregar certificaciones. Las certificaciones
ITIL solo se conceden a las personas. Las empresas se pueden certificar en el marco de
ISO 20000.
Puede encontrar las direcciones de estos organismos en el sitio Web
ITIL: http://www.itil-officialsite.com/ExaminationInstitutes/ExamInstitutes.aspx
oficial
A raz de los trabajos de la organizacin britnica de normalizacin, ha visto la luz la norma

BS15000, que recoge la mayor parte de las prcticas ITIL.
Desde 2005, esta norma se ha convertido en una norma internacional: ISO/IEC 200002011 (ver la siguiente seccin).
Atencin: el programa de certificacin puesto en prctica actualmente por APMG y OGC ha

permitido certificar las primeras herramientas. Sin embargo, varios fabricantes de software
han optado por tener en cuenta las recomendaciones ITIL para que sus herramientas
respeten de manera ms fiable las mejores prcticas de ITIL. El trmino Compliant ITIL
no es en absoluto una garanta de que la herramienta le permita realizar el conjunto de
operaciones descritas en ITIL 2011. Por ejemplo, podemos observar que ciertos programas
de software solo tienen en cuenta los servidores en la CMS (Configuration Management
System - Sistema de Gestin de la Configuracin); cmo se gestiona en este caso la

nocin de CI (Configuration Item - Elemento de Configuracin) a nivel de los puestos de
trabajo o del software?
3. Las versiones de ITIL

a. ITIL V2
Un determinado nmero de empresas todava estn bajo ITIL V2, aunque podemos pensar
que van a evolucionar hacia ITIL 2011 antes o despus.
Presentacin de la estructura de ITIL V2

La versin ITIL V2 est formada por 10 libros. Los dos ms importantes son:
El suministro de servicios (Service Delivery), que se refiere a los procesos necesarios

para el diseo y suministro de servicios.
Los servicios de soporte (Service Support), que se refiere a los procesos necesarios
para el mantenimiento y la asistencia tcnica de los servicios.
b. Los procesos ITIL V2

Procesos tcticos
Gestin de niveles de servicios
Gestin financiera
Gestin de la capacidad
Gestin de la continuidad de los servicios
Gestin de la disponibilidad
Gestin de la seguridad
Procesos operativos
Gestin de cambios
Gestin de incidencias
Gestin de problema
Gestin de configuraciones
c. ITIL V3
Esta versin de ITIL se public en 2007 y representa una evolucin importante respecto a
la V2. Los conceptos de la versin anterior se conservan en lo fundamental; sin embargo,
esta versin aade cambios importantes y, en particular, sobre la estructura global.
Esta versin se basa en una nocin nueva: el ciclo de vida de la gestin de los servicios.
La versin ITIL 2011 tambin se basa en esta nocin.
Esta nocin se detallar en el captulo El ciclo de vida de la gestin de los servicios.
Presentacin de la estructura de ITIL V3

El ncleo de ITIL V3 se compone de cinco libros principales:
Estrategia de servicios
Diseo de servicios
Transicin de servicios
Operacin de servicios
Mejora continua de servicios
d. Los procesos ITIL V3

Nivel decisional: Mejora continua de servicios
Mejora continua de servicios
Nivel decisional: Estrategia de servicios (Procesos estratgicos)
Estrategia de servicios
Gestin del porfolio de servicios
Gestin financiera
Gestin de la demanda
Nivel decisional: Diseo de servicios (Procesos estratgicos y tcticos)
Gestin del catlogo de servicios
Gestin del nivel de servicios
Gestin de la continuidad de los servicios informticos
Gestin de la seguridad informtica
Gestin de proveedores
Nivel decisional: Transicin de servicios (Procesos tcticos y operativos)
Gestin de cambios
Gestin de los activos de servicios y configuraciones
Gestin de los despliegues y de las entradas en produccin
Validacin y prueba de los servicios
Evaluacin
Gestin del conocimiento
Nivel decisional: Explotacin de los servicios (Procesos operativos)
Gestin de eventos
Ejecucin de consultas
Gestin de problemas
Gestin de la evaluacin
e. ITIL 2011
Esta nueva versin de ITIL se presenta como una evolucin de la versin V3.
Los puntos ms importantes que se tienen en cuenta son:
Estandarizacin de cada proceso
Objetivos
Permetro
Valor para las empresas
Estandarizacin de los procesos
Objetivos
Permetro
Valor para las empresas
Polticas, principios y conceptos bsicos
Actividades del proceso
Activadores, entradas, salidas e interfaces
Factores de xito crticos
Informacin
Riesgos y oportunidades (cuando se implementan)
f. Los procesos ITIL 2011

Nivel decisional: Mejora continua de los servicios
Mejora de los procesos en siete etapas
Nivel decisional: Estrategia de servicios (Procesos estratgicos)
Gestin de la estrategia de servicios
Gestin financiera
Gestin de la relacin comercial
Nivel decisional: Diseo de servicios (Procesos tcticos)
Coordinacin del diseo
Gestin de los niveles de servicios
Gestin de la continuidad de los servicios informticos
Nivel decisional: Transicin de servicios(Procesos tcticos y operativos)
Planificacin y soporte de la transicin de servicios
Gestin de cambios
Gestin de los activos de servicios y configuraciones
Gestin de los despliegues y de las entradas en produccin
Validacin y prueba de servicios
Evaluacin de los cambios
Nivel decisional: Explotacin de los servicios (Procesos operativos)
Gestin de eventos
Gestin de problemas
Gestin de los accesos
4. La filosofa de ITIL
La filosofa de ITIL se basa en cuatro principios:
Considerar que la organizacin TI est estrechamente unida al negocio y que el

uno no funciona sin el otro.
Proponer una estructura basada en los procesos que se debe adaptar a cada
organizacin, ya sea esta grande o pequea, y a todas las tecnologas.
Los servicios de TI se definen para ajustarse a lo esperado por parte de los usuarios
y los clientes, es decir, al negocio, y se basan en un conjunto de procesos.
Identificar las prcticas ms eficaces para utilizar los recursos humanos y tecnologas
necesarias para ejecutar procesos y entregar los servicios esperados.
a. Los objetivos de ITIL

El objetivo de ITIL es responder a estos cuatro puntos:
Alinear los servicios ITIL a las necesidades del negocio de los clientes actuales y
futuros.
Mejorar la calidad de los procesos proporcionados.
Mejorar la eficacia y aspirar a la eficiencia de la organizacin TI.
Reducir los costes de entrega de los servicios TI a ms largo plazo.
Esto implica:
Una transicin, desde una cultura generalmente orientada a la tecnologa, hasta una
cultura orientada alrededor del negocio y de los servicios.
Gestionar la organizacin TI como una unidad de negocio.
b. Algunas definiciones importantes
Para entender correctamente los objetivos de la puesta en prctica de ITIL, es necesario

definir algunos trminos que se utilizarn en este libro, para que tenga una comprensin
clara de su significado.
TI: Tecnologas de la informacin. Con frecuencia, es el trmino utilizado para definir la
organizacin TI, ya sea el servicio informtico o la direccin informtica, en funcin del
tamao de la empresa o de su organizacin. Algunas veces, la sigla TI se traduce al ingls
y se convierte en IT.
Es la organizacin que proporciona el servicio al cliente (interno o externo).
Negocio: los trminos profesin, negocio o tarea tienen el mismo significado.
Segn la organizacin de la empresa cliente, podemos utilizar un trmino u otro.
El negocio es una denominacin de la entidad que utiliza el servicio proporcionado por la
organizacin TI.
Si tomamos el ejemplo de un banco, el cliente es el banco. En el seno de esta empresa,
existen varios negocios (finanzas, seguros, bolsa...), que utilizan todos los servicios
proporcionados por las TI. Sin embargo, cada negocio utiliza uno o varios servicios
especficos que le son propios y para los que se han definido y validado los niveles de
servicio especficos, entre el negocio y la organizacin TI.
Servicio: medio de proporcionar un valor aadido a los clientes, facilitndoles la obtencin
de los resultados esperados, respetando las restricciones de costes y riesgos (ver la
siguiente seccin).
Cliente: persona o grupo que define los objetivos de los niveles de servicio para cada
servicio. En general, es quien da la orden. Aprueba y firma los acuerdos de niveles de
servicio; generalmente, tambin es responsable de la financiacin de los servicios.
Usuario: persona que utiliza diariamente los servicios proporcionados por la organizacin
TI.
Proveedor de servicios: organizacin que proporciona servicios a uno o varios clientes
internos o externos. Existen tres tipos de proveedores de servicios:
Tipo I - Proveedor interno: proporciona servicios internos que forman parte de la

unidad de negocio. Puede haber varios proveedores de tipo I en la organizacin.
Tipo II - Proveedor de servicios compartidos: proveedor de servicios internos

que proporciona servicios a una o varias unidades de negocio.
Tipo III - Proveedor externo: proveedor de servicios externos, que proporciona

servicios para un cliente.
Proceso: un proceso est formado por una o varias actividades relacionadas (ver la
siguiente seccin).
Propietario de proceso: el propietario de uno o varios procesos es responsable de los
resultados del proceso y rinde cuentas a su direccin.
Responsable de procesos: el responsable de un proceso est encargado de la realizacin
de un proceso y rinde cuentas al propietario del proceso.
CMS (Configuration Management System): sistema de gestin de configuraciones. En ITIL
V2 hablamos de CMDB (Configuration Management Data Base).
CMDB (Base de datos de gestin de configuraciones): modelo fsico que refleja la
infraestructura que contiene todos los CI, su estado y las relaciones entre ellos.
Actualmente, todava muchas personas hablan de CMDB en lugar de la CMS, por motivos
de comprensin o facilidad.
CI (Elemento de Configuracin), componente de la infraestructura o elemento asociado a
una infraestructura, bajo el control de la gestin de configuraciones.
Incidencia: todo evento que no forma parte de las operaciones estndares de un servicio
y que cause o pueda causar una interrupcin o reduccin de la calidad del servicio.
Peticin de servicio: peticin que no refleja un mal funcionamiento de un servicio de TI y
que no altera el estado de la infraestructura de un servicio.
Problema: causa subyacente desconocida para una o varias incidencias.
c. Qu es una buena prctica?

Una buena prctica se define por varios elementos:
Se desarrolla a partir de elementos generales aplicables a mltiples contextos del

negocio u organizativos.
Es ampliamente reconocida por la industria como modelo de referencia.
Constituye un xito comprobado, ha sido implementada en las organizaciones y

aporta un valor para el servicio proporcionado.
Las mejores prcticas ms utilizadas en el entorno informtico son las siguientes:
ITIL, COBIT, CMMI, PRINCE2, PMBOK y Six Sigma.
Las normas ms utilizadas en el entorno informtico son las siguientes:
ISO 9001-2008
ISO 20000-2011
IS0 27000
d. Qu es un servicio?
Un servicio es el resultado de las acciones realizadas por un proveedor para entregar

lo que ha sido acordado.
El servicio se proporciona a travs de una interaccin entre cliente, usuarios y

proveedor.
El cliente y el proveedor pueden ajustar el servicio durante su entrega.
La satisfaccin con un servicio depende, de manera decisiva, de las experiencias

anteriores del cliente, los usuarios, sus expectativas y de una buena gestin de estas
ltimas.
Ejemplos de servicios TI:
Servicio de mensajera electrnica
Servicio de impresin
Servicio de utilizacin de un sistema financiero
e. Enfoque a procesos
Para que un organismo (estructura, empresa, conjunto de actividades...) funcionen
eficazmente, es necesario identificar y gestionar muchas actividades estructuradas y
relacionadas.
La norma ISO 9001:2008 fomenta la adopcin de un enfoque a procesos durante el
desarrollo y puesta en prctica de un sistema de gestin de la calidad, en el seno de la
organizacin. La exigencia de mejora continua de la calidad permite aumentar la
satisfaccin de los clientes en relacin con sus requerimientos.
ITIL tambin se basa en un conjunto de procesos relacionados.
El enfoque a procesos representa la puesta en marcha de un sistema de procesos en el
seno de un organismo, as como la identificacin de las interacciones entre los diferentes
procesos.
Un proceso est formado por una o varias actividades estructuradas y relacionadas.
Un proceso proporciona resultados especficos.
Definicin de un proceso
Un proceso es un conjunto de actividades estructuradas y relacionadas para proporcionar

un resultado especfico.
Un proceso incluye uno o varios elementos de entrada, que transforma en uno o varios
elementos de salida.
De manera habitual, el elemento de salida de un proceso es el elemento de entrada del
proceso siguiente.
Los procesos deben estar documentados y controlados.
Un proceso se debe poder medir. Para esto, usaremos indicadores. Algunos de estos
indicadores se llaman KPI (Key Performance Indicator). Un KPI es un indicador que permite
medir el rendimiento de una actividad.
Descripcin de un proceso
Para obtener un funcionamiento ptimo del sistema de calidad, es necesario vigilar, medir y
analizar estos procesos.
La gestin de estos procesos se realiza para obtener el resultado deseado.
Cuando se utiliza en un sistema de gestin de la calidad, este enfoque destaca la
importancia de:
Entender y cumplir los requerimientos.
Considerar los procesos en trminos de valor aadido.
Medir el rendimiento y la eficacia de los procesos.
Mejorar continuamente los procesos, basndose en mediciones objetivas.
La mejora continua de los procesos se basa en la Rueda de Deming.
f. Definicin de los objetivos

La definicin de un objetivo debe responder obligatoriamente al acrnimo SMART.
S de Sencillo. Cada objetivo se debe expresar de manera clara y concisa para que los
encargados de implementar el proceso puedan entenderlo.
M de Medible. Para cada objetivo, hay que poder medir el nivel alcanzado. Es el nico
medio para evaluar su evolucin.
A de Alcanzable. No sirve para nada fijar objetivos demasiado ambiguos. Esto

tambin implica que la(s) persona(s) encargada(s) de implementar el proceso
haya(n) aceptado este nivel de objetivo.
R de Realista. Para esto, el objetivo debe ser compatible con la cultura y la estructura
de la empresa.
T de Temporal. Para esto, es imprescindible definir en qu periodo de tiempo se debe

medir el objetivo.
Atencin: tener multitud de objetivos diferentes para un mismo proceso no es acertado.

De manera ideal, un proceso no debera tener ms de 5 a 7 objetivos.
g. El principio de la Rueda de Deming

El principio de la Rueda de Deming se descompone en cuatro actividades consecutivas,
dentro de un ciclo de funcionamiento (en general, la duracin de un ciclo es de un ao).
Este principio tambin se denomina PDCA.
La Rueda de Deming
Habitualmente, estos cuatro ciclos se definen de la siguiente manera:
P de Plan (Planificar)
En esta fase vamos a:
Identificar la estrategia de mejora.
Planificar, decidir los objetivos, el calendario, las responsabilidades y los recursos,

basndonos en lo que hemos definido durante la actividad Act.
Definir los indicadores que permitirn medir la mejora real.
D de Do (Hacer)
Realizar las acciones que se definen en el plan, respetando los objetivos y el

calendario.
C de Check (Controlar)
Realizar el control o los controles para verificar los resultados obtenidos durante la
fase Do.
Verificar los resultados de los indicadores.
A de Act (Definir los ejes de mejora)

A partir de los resultados del Check, vamos a identificar las direcciones de mejora. Estas
direcciones de mejora se validarn durante el prximo ciclo en el Plan.
h. La calidad
La calidad representa la totalidad de caractersticas de un servicio, que le permiten
satisfacer las necesidades identificadas e implcitas.
Cmo influye la calidad en el servicio?
La calidad del servicio refleja la consecucin de las expectativas del cliente y de los
usuarios, de manera constante.
La puesta en marcha de medidas de control del proceso de entrega de los servicios

permite conseguir una mayor consistencia.
El control de la calidad requiere un dilogo continuo entre el cliente, los usuarios y el

proveedor.
Las medidas de control permiten un mayor conocimiento del coste de los servicios y
establecer mejor cul es el precio razonable asociado a los servicios esperados.
La calidad del servicio no se puede evaluar de manera anticipada.
Las normas
Ms adelante encontrar las diferentes normas, modelos y mejores prcticas utilizadas en
la actualidad en el entorno de los servicios informticos.
1. ISO 9001:2008
La norma ISO 9001 tiene por objetivo la certificacin de las empresas, No obstante,
tambin existe una certificacin para las personas: Auditor certificado ISO 9001.
La norma ISO 9001 forma parte de la serie de normas ISO 9000, relativas a los sistemas
de gestin de la calidad, y establece los requisitos exigidos para la existencia de un sistema
de gestin de la calidad.
Estos requerimientos servirn como base a la certificacin del organismo. Las otras normas
de la serie 9000: vocabulario (ISO 9000), lneas directrices (ISO 9004)... no contienen
requisitos y no pueden servir de base para la certificacin.
La versin en vigor de ISO 9001 es la versin de 2008 (aparecida en noviembre de 2008).
La versin ISO 9001:2000 tuvo validez hasta noviembre de 2010.
En relacin con la documentacin sustituida (ISO 9001:2000), la norma NF EN ISO
9001:2008 no aade ningn requisito nuevo. nicamente introduce aclaraciones a los
requisitos existentes de la norma NF EN ISO 9001:2000. Tambin aade las modificaciones

destinadas a mejorar la coherencia con la norma NF EN ISO 14001:2004.
a. Enfoque a procesos
La norma ISO 9001:2008 fomenta la adopcin de un enfoque a procesos en el momento
del desarrollo y puesta en prctica de un sistema de gestin de la calidad, en el seno del
organismo.
La exigencia de mejora continua de la calidad permite incrementar la satisfaccin de los
clientes en relacin con sus requerimientos.
El enfoque a procesos se refiere a la puesta en marcha de un sistema de procesos en el
seno de un organismo, as como a la identificacin de las interacciones entre los diferentes
procesos (ver la seccin El enfoque a procesos).
Para obtener un funcionamiento ptimo del sistema de calidad, es necesario hacer un
seguimiento, medir y analizar estos procesos.
La gestin de estos procesos se realiza con el objetivo de obtener el resultado deseado.
Cuando se utiliza en un sistema de gestin de la calidad, este enfoque destaca la
importancia de:
Entender y cumplir los requerimientos.
Considerar los procesos en trminos de valor aadido.
Medir el rendimiento y la eficacia de los procesos.
Mejorar constantemente los procesos basndose en medidas objetivas.
b. Los requerimientos de la norma *

* Una parte del texto est extrada del sitio de Wikipedia (http://es.wikipedia.org/wiki).
Este
texto
se
encuentra
bajo
licencia
CC-BY-SA
3.0
(http://creativecommons.org/licenses/by-sa/3.0/).
Los requerimientos de la norma estn relacionados con cuatro grandes reas:
La responsabilidad de la direccin: exigencia de hechos por parte de la direccin,

como actor principal y permanente de la actividad.
El sistema de calidad: requisitos administrativos que permiten conservar los activos.

Necesidad de tener en cuenta la nocin de sistema.
El proceso: requerimientos relativos a la identificacin y gestin de los procesos, que

contribuyen a la satisfaccin de las partes interesadas.
La mejora continua: requerimientos de medida y registro del rendimiento, a todos los

niveles tiles, as como el inicio de acciones de progreso eficaces.
Detalle de la norma ISO 9001 - versin 2008

La puesta en marcha de un sistema de gestin de la calidad segn los requerimientos de la
norma ISO 9001-Versin 2008 consiste en:
Demostrar la capacidad de proporcionar de manera regular un producto, conforme a

los requerimientos del cliente y a las exigencias reglamentarias aplicables.
Tratar de aumentar la satisfaccin de los clientes mediante la aplicacin eficaz del

sistema y, en particular, poner en prctica un proceso de mejora continua (segn el
principio PDCA o Rueda de Deming).
Los requerimientos de la norma

Los requerimientos de la norma ISO 9001 se presentan en ocho artculos:
Artculo 1: dominio de la aplicacin
Artculo 2: referencias normativas
Artculo 3: trminos y definiciones
Artculo 4: sistema de gestin y de calidad
Artculo 5: responsabilidad de la direccin
Artculo 6: gestin de recursos
Artculo 7: realizacin del producto
Artculo 8: medida, anlisis y mejora
La norma se basa en ocho principios de gestin:
Orientacin a cliente
Liderazgo
Implicacin del personal
Enfoque a procesos
Gestin mediante el enfoque a sistemas
Mejora continua
Enfoque real para la toma de decisiones
Relaciones mutuamente beneficiosas con los proveedores
Fuente: http://es.wikipedia.org/wiki/ISO_9001
2. COBIT *
COBIT es un modelo de organizacin; no es una norma internacional reconocida.
COBIT (Control Objectives for Information and related Techonology - Objetivos de control
para la Informacin y Tecnologa relacionadas) es una herramienta unificadora que permite
establecer un lenguaje comn para hablar de la gestin de los sistemas de informacin,
integrando al mismo tiempo otros repositorios, tales como ISO 9000 o ITIL.
COBIT fue desarrollada en 1994 por el ISACA (Information Systems Audit and Control
Association) y publicada en 1996 (http://www.isaca.org/bookstore).
ISACA est presente en diferentes ciudades espaolas, as como en Internet en sitios Web
comohttp://www.isacamadrid.es o http://www.isacabcn.org.
Ampliamente utilizada como herramienta de conformidad con Sarbanes-Oxley y otras
numerosas normas mundiales, COBIT es anterior a la legislacin de control adoptada en
todo el mundo. Es el resultado de 15 aos de bsqueda y cooperacin por parte de los
expertos en TI y comerciales internacionales. Es un repositorio unificador internacional que
integra a todas las normas principales mundiales de la tecnologa de la informacin, como
ITIL, CMMI e ISO 17799. La nueva versin de este repositorio se puede descargar
gratuitamente en el organismo ITGI independiente, sin nimo de lucro, en la
direccin http://www.itgi.org.
Es un marco de control que tiene como objetivo ayudar en el manejo de la gestin del
riesgo (seguridad, fiabilidad, conformidad) y de las inversiones. COBIT ha evolucionado y la
versin 4 apareci en Espaa en el ao 2007.
COBIT es un enfoque orientado a procesos.
Fuente: http://es.wikipedia.org/wiki/CobiT
COBIT descompone los sistemas informticos en cuatro reas principales, que engloban un
conjunto de 34 procesos. A su vez, estos procesos se dividen en 215 actividades.
a. Los cuatro dominios

Los cuatro dominios principales de COBIT:
Planificacin y organizacin (10 procesos)
Adquisicin y puesta en prctica (7 procesos)
Proveedor del servicio (13 procesos)
Seguimiento y evaluacin (4 procesos)
b. Los seis niveles

Para medir la madurez de los procesos, CobiT utiliza una evaluacin basada en seis niveles:
Inexistente
Inicializada, caso a caso
Reproducible aunque intuitivo
Proceso definido
Gestionable y medible
Optimizado
En resumen, COBIT es un marco de referencia para controlar el buen gobierno de los SI a

lo largo del tiempo. Se basa en un conjunto de buenas prcticas recogidas por los expertos
de SI.
Hoy en da, un nmero creciente de empresas importantes ponen en prctica el modelo
COBIT para poder proporcionar informacin clara y comprensible, no solo a sus accionistas,
sino tambin a las autoridades oficiales de sus pases o con los que tienen una actividad o
mantienen relacin.
3. CMMI *
CMMI es un modelo de organizacin, no es una norma internacional reconocida.
CMMI, siglas para Capability Maturity Model + Integration, es un modelo de referencia, un
conjunto estructurado de buenas prcticas, destinado a entender, evaluar y mejorar las
actividades de las empresas de ingeniera.
CMMI fue desarrollado por el SEI (Software Engineering Institute) de la universidad
Carnegie Mellon, inicialmente para entender y medir la calidad de los servicios
proporcionados por los proveedores de software informtico del Departamento de Defensa
de los Estados Unidos (DoD). En la actualidad se usa ampliamente en las empresas de
ingeniera informtica, por los directores de sistemas informticos e industriales, para
evaluar y mejorar sus propios desarrollos de productos.
Histrico
En los aos ochenta, el departamento de defensa de los Estados Unidos solicit la
elaboracin de un repositorio de criterios que le permitieran evaluar a sus proveedores de
software.
Despus de una lenta maduracin, el SEI (Software Engineering Institute), financiado por
el DoD, present en 1991 el CMM (Capability Maturity Model). Este modelo de referencia
solo se aplica a las buenas prcticas de la ingeniera de software.
Despus de un importante entusiasmo por este modelo, vieron la luz otros modelos
similares, tales como:
SE-CMM (System Engineering)
SA-CMM (Software Acquisition)
IPD-CMM (Integrated Product Development)
People CMM (para la gestin de los recursos humanos)
SS-CMM (Supplier Sourcing)
Fue necesario cambiar el nombre CMM inicial por SW-CMM (SW para SoftWare).
En 2001, el SEI propuso una nueva versin de su modelo, el CMMI ( Capability Maturity
Model Integration), que engloba las buenas prcticas de los otros modelos, salvo la gestin
de recursos humanos, que ya no lo tuvo en cuenta (versin 1.1).
En 2006, se actualiz la versin del modelo (versin 1.2). Esta ltima versin del CMMI, la
actual, tiende a simplificar el modelo y a mejorar la consideracin de los componentes de
tipo hardware.
El modelo CMMI define una escala de medida de la madurez de cinco niveles y los
indicadores necesarios para evaluar las actividades dirigidas por un equipo, en relacin con
esta escala; el equipo puede ser un grupo de trabajo, uno o varios proyectos, una sociedad
e incluso una institucin del Estado.
CMMI es un marco genrico de procesos que se declina en tres modelos (llamados
constelaciones).
a. Los tres modelos
CMMI-DEV para el desarrollo de sistemas (software u otros).
CMMI-ACQ para las actividades en el mbito de las adquisiciones (versin publicada

en 2007).
CMMI-SVC para el suministro de servicios (publicacin en febrero de 2009).
La particularidad de estos tres modelos es que tienen una parte comn (el ncleo o core
en ingls), que representa alrededor del 60% de las prcticas.
De un modelo a otro, las diferencias se centran en la categora de ingeniera, cuyas
prcticas varan segn la actividad implicada.
El modelo CMMI se utiliza mayoritariamente en las sociedades informticas; sin embargo,
los principios de CMMI se aplican a cualquier actividad de ingeniera: arquitectura,
mecnica, electrnica...
Madurez
De acuerdo con la definicin dada en el CMMI, la madurez de una organizacin es el grado
con el que esta despliega los procesos explcitamente y de manera coherente, procesos que
se documentan, gestionan, miden, controlan y mejoran continuamente.
Un nivel de madurez (Maturity Level) corresponde a la consecucin de un nivel de
capacidad uniforme para un grupo de procesos. Un nivel de capacidad (Capability Level)
mide la consecucin de los objetivos de un proceso para el nivel dado.
b. Descriptivo de un modelo
Las buenas prcticas recomendadas por el modelo (versin 1.2), se renen en 22 reas de
proceso, agrupadas a su vez en cinco niveles de madurez.
Inicial (Initial), nivel de madurez 1
No hay procesos establecidos o bien estn documentados, pero no se utilizan. No hay
supervisin (monitoring), ninguna evaluacin de rendimiento y no existe comunicacin.
En este nivel, tanto las soluciones como los proyectos son decididos, desarrollados e
instaurados por un individuo.
No hay descripcin del nivel 1 de madurez en el modelo.

Reproducible (Managed), nivel de madurez 2
Los planes de proyecto (plan de desarrollo, control de calidad, gestin de configuracin...)
se definen para cada proyecto.
El jefe de proyecto tiene una fuerte responsabilidad en el nivel 2: debe definir, documentar,
aplicar y mantener actualizados sus planes. De un proyecto a otro, el jefe de proyecto se
beneficia y mejora sus prcticas de gestin de proyectos de ingeniera.
Estndar (Defined), nivel de madurez 3
En este nivel, se pone en prctica una estandarizacin adecuada, una capitalizacin
centralizada (en particular, sobre las medidas realizadas en los proyectos) y un repositorio
de control interno (o sistema de calidad). Existen lneas directrices, un plan estratgico y
una planificacin de mejora de procesos.
Controlado (Quantitatively managed), nivel de madurez 4
Los procesos se basan en objetivos cuantitativos de calidad. Se tiene en cuenta la
expresin de la calidad solicitada por el cliente para cuantificar los objetivos del proyecto y
establecer los planes, segn la capacidad de los procesos de la organizacin.
Optimizado (Optimizing), nivel de madurez 5
Los procesos que se gestionan cuantitativamente para el seguimiento del proyecto (nivel 4
de madurez) estn en continua optimizacin con el objetivo de anticipar las evoluciones
previstas (necesidades de clientes, nuevas tecnologas...).
Fuente: http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration
4. PRINCE2
PRINCE es un mtodo, no es una norma internacional reconocida. La certificacin PRINCE
se destina a las personas, y no a las organizaciones informticas.
PRINCE es un mtodo y una gua de mejores prcticas en trminos de gestin de
proyectos.
PRINCE, originariamente llamado PROMPT, fue adoptado por la OGC en 1989 y aplicado en
los proyectos del gobierno britnico.
En 1996, la ltima versin del mtodo (PRINCE2) fue ampliada y se hizo ms flexible para
poder gestionar proyectos de todo tipo y tamao.
El OGC es el propietario y depositario del mtodo PRINCE2 y, en los orgenes de ITIL,
recoge las mejores prcticas de gestin de servicios informticos. PRINCE2 es de dominio
pblico.
Mtodo
Un proyecto es un proceso con un inicio y un fin claramente definidos.
Los proyectos siempre se deben controlar para que tengan xito.

El mtodo tiene en cuenta los factores de cambio del entorno del proyecto, susceptibles de
influir en su xito.
Los procesos
PRINCE2 est divido en ocho procesos definidos por las claves de entrada y de salida, los
objetivos esperados y las actividades que se deben realizar. Cada proceso se designa
mediante una abreviatura:
(SU) - Elaborar el proyecto (EP)
(IP) - Inicializar el proyecto (IP)
(DP) - Dirigir el proyecto (DP)
(CS) - Controlar una secuencia (CS)
(MP) - Gestionar la entrega de productos (EP)
(SB) - Gestionar los lmites de secuencia (LS)
(CP) - Cerrar un proyecto (CP)
(PL) - Planificar (PL)
Podemos agrupar estas etapas en cuatro fases:
Arranque (SU)
Iniciacin (IP)
Ejecucin (CS, MP, SB)
Cierre (CP)
Los procesos (DP) se aplican a lo largo de todo el proyecto.
Fuente: http://es.wikipedia.org/wiki/PRINCE2
5. ISO 20000-2011
La norma ISO 20000 tiene como objetivo la certificacin de empresas. No obstante,
tambin existe una certificacin para las personas: Auditor certificado ISO 20000.
En el origen de la norma ISO 20000, se encuentra la norma britnica BS 15000, que se
basa en las buenas prcticas ITIL.
La versin ISO 20000-2011 es la nueva versin publicada.
La norma ISO 20000 se presenta en dos volmenes.
El primer volumen contiene los requerimientos de la norma, es decir, aquello que se debe
demostrar en el proceso de la auditora de certificacin.
El segundo contiene las mejores prcticas y las recomendaciones.
De manera habitual, se dice que el primero contiene los Shall o What (aquello que es
obligatorio) y el segundo los Should o How (aquello que sera conveniente hacer o
cmo hacerlo).
ISO 20000 se basa, en parte, en los principios de ITIL V2 (origen de la BS 15000) e
igualmente en algunos principios y procesos de la norma ISO 9001.
ISO 20000, a diferencia de ISO 9001, que se aplica a todos los sectores de actividad, est
destinado nicamente a la gestin de los organismos informticos en el seno de las
empresas.
Se puede facilitar la puesta en prctica de una certificacin ISO 20000 si la empresa ya
est llevando a cabo un proceso de calidad (ha adquirido la certificacin ISO 9001 o
simplemente tiene establecido un enfoque a procesos), o si ya se ha realizado un enfoque
ITIL.
Los procesos de gestin de los servicios

ISO 20000-11 hace referencia a 13 procesos.
ISO 20000-2011
Estos 13 procesos se describen en los artculos 3 a 10 de la norma.
El artculo 3 trata de los requerimientos de un sistema de gestin.
El artculo 3.1 trata de la responsabilidad de la Direccin.
El artculo 3.2 trata de los requerimientos relativos a la documentacin.
El artculo 3.3 trata de la competencia, sensibilizacin y formacin del personal.
El artculo 4 trata de la planificacin y de la puesta en marcha de la gestin de los

servicios.
La siguiente figura ilustra los procesos y relaciones entre los procesos presentes en los
artculos 4 a 10 de la norma.
Rueda de Deming aplicada a los procesos de gestin de servicios
El artculo 4.1 trata de la planificacin de la gestin de los servicios (Planificar).
El artculo 4.2 trata de la puesta en marcha de la gestin y suministro de los

servicios (Hacer).
El artculo 4.3 trata del seguimiento, medicin y revisin (Verificar).
El artculo 4.4 trata de la mejora continua (Actuar).
El artculo 5 trata de la planificacin y puesta en marcha de las modificaciones o creacin

de servicio.
El artculo 6 trata de los procesos de suministro de los servicios.
El artculo 6.1 trata de la gestin de los niveles de servicio.
El artculo 6.2 trata de los informes de servicio.
El artculo 6.3 trata de la gestin de la continuidad y disponibilidad de los servicios.
El artculo 6.4 trata de la dotacin presupuestaria y contabilidad de los servicios

informticos.
El artculo 6.5 trata de la gestin de la capacidad.
El artculo 6.6 trata de la gestin de la seguridad de la informacin.
El artculo 7 trata de los procesos de gestin de las relaciones.
El artculo 7.1 trata de las generalidades.
El artculo 7.2 trata de la gestin de las relaciones comerciales.
El artculo 7.3 trata de la gestin de los proveedores.
El artculo 8 trata de los procesos de resolucin de problemas.
El artculo 8.1 trata del contexto.
El artculo 8.2 trata de la gestin de incidencias.
El artculo 8.3 trata de la gestin de problemas.
El artculo 9 trata de los procesos de control.
El artculo 9.1 trata de la gestin de las configuraciones.
El artculo 9.2 trata de la gestin de los cambios.
El artculo 10 trata de los procesos de la puesta en produccin.
El artculo 10.1 trata de los procesos de gestin de la puesta en produccin.
EL CICLO DE VIDA DE LA GESTION DE SERVICIOS

Enfoque
En este captulo vamos a ver cmo se representa la estructura del ciclo de vida de la
gestin de los servicios en ITIL V3 y cules son las relaciones entre las diferentes fases del
ciclo y los diferentes procesos y funciones.
El contexto del ciclo de vida de la gestin de los servicios es un contexto organizativo.

Es importante entender correctamente el objetivo del ciclo de vida de la gestin de los
servicios antes de poner en prctica una estrategia ITIL. De su comprensin depender, en
parte, el xito de su proyecto ITIL.
Este ciclo de vida de la gestin de los servicios, desglosado en fases, es permanente y
continuo. Se considera que, para el proceso de mejora continua de los servicios (CSI), es
necesario ejecutar un ciclo de gestin al menos una vez cada ao.
En cada fase del ciclo de vida de la gestin de los servicios, se efectan los controles y se
analizan los retornos de la experiencia. Las mejoras se pondrn en prctica en el curso del
ciclo siguiente.
Enfoque del ciclo de vida de la gestin de los servicios

El ciclo de vida de la gestin de los servicios se presenta a partir de la estrategia de
servicios (Service Strategy - SS), que se encuentra en el centro del diagrama. Esto es
lgico, ya que los otros procesos se ponen en prctica a partir de las decisiones tomadas y
estrategias definidas por la Direccin informtica o la Direccin General de la empresa.
Los otros tres grupos de procesos se representan alrededor de la estrategia de servicios. Se
comienza por el diseo de servicios (Service Design - SD), seguido por la transicin de
servicios (Service Transition - ST), para terminar con la explotacin de los servicios
(Service Operation - SO).
Finalmente, el conjunto de estos procesos se rodea por los procesos de mejora continua de
servicios (Continual Service Improvement - CSI).
Las fases del ciclo de vida

El ciclo de vida de la gestin de los servicios est formado por las siguientes fases:
Definir la estrategia de gestin de servicios (Service Strategy - SS).
Disear los servicios con el fin de soportar la estrategia (Service Design - SD).
Poner en prctica los servicios con el fin de satisfacer las exigencias del diseo
(Service Transition - ST).
Soportar los servicios de gestin de las actividades operativas (Service Operation SO).
Fases del ciclo de vida de la gestin de los servicios

La interaccin entre las fases se gestiona mediante el enfoque de mejora continua de
servicios (Continual Service Improvement - CSI), que permite medir y mejorar el nivel de
madurez de los procesos y, por lo tanto, de los servicios.
Despus de la realizacin de todas las fases del ciclo de vida de la gestin del servicio,
termina un periodo de servicio y comienza otro.
En la fase inicial de estrategia de los servicios (Service Strategy - SS), el proveedor de los
servicios informticos establece una estrategia:
Gestionando las exigencias del negocio (proceso de gestin de peticiones).
Traducindola en una estrategia de entrega de servicios (estrategia de servicios).
Validando la sostenibilidad de los costes (proceso de gestin financiera).
Introduciendo el servicio en el porfolio de servicios (proceso de gestin del porfolio
de servicios).
En este estado, la organizacin TI debe utilizar los recursos, lo que tiene un coste, en los
proyectos de consultora en un nivel estratgico. Durante este periodo, esta estructura no
proporciona valor a la empresa.
Durante la segunda fase, fase de diseo de servicios (Service Design - SD), cuando ya se
ha definido una estrategia, la organizacin TI comienza a disear el servicio:
Estableciendo las exigencias de nivel de servicio de este servicio (proceso de
gestin de nivel de servicio).
Estudiando la disponibilidad (proceso de gestin de la disponibilidad).
La capacidad necesaria (proceso de gestin de la capacidad).
Seleccionando los proveedores que van a soportar el servicio (proceso de gestin de
proveedores).
Definiendo las disposiciones adecuadas para la continuidad de los servicios (proceso
de gestin de la continuidad de servicios informticos).
Validando y estableciendo las exigencias de seguridad (proceso de gestin de
seguridad de la informacin).
Aadiendo el servicio al catlogo de servicios (proceso de gestin del catlogo de
servicios).
Durante la tercera fase, fase de transicin de servicios (Service Transition - ST), el servicio
est preparado para ponerse en marcha en el entorno real. El proveedor de servicios:
Define el plan de transicin (planificacin y soporte en la transicin).
Evala, aprueba, pone en marcha y planifica los cambios (proceso de gestin de
cambios).
Antes de la puesta en marcha de estos cambios, el servicio se prueba (proceso de
validacin y prueba de servicios) en un entorno lo ms parecido posible al futuro entorno
de explotacin, pero nunca en el propio entorno de explotacin.
Si la prueba tiene xito, el servicio se documenta (proceso de gestin del conocimiento) y
sus componentes se aaden a la base de datos de los activos y configuraciones (proceso de
gestin de activos de servicio y configuraciones).
La ltima actividad consiste en poner el servicio en produccin en un entorno real (proceso
de gestin de despliegues y entradas en produccin).
Para terminar, la ltima etapa consiste en la satisfaccin del cliente, que se mide antes de
cerrar el cambio.
Durante la cuarta fase, fase de explotacin de servicios (Service Operation - SO), el
servicio se gestiona y soporta para atender los niveles de servicios acordados:
Gestionando las peticiones de soporte de los usuarios (funcin de centro de servicios

y procesos de tratamiento de consultas).
Haciendo seguimiento de los eventos y alertas del servicio (proceso de gestin de los
eventos).
Restaurando el servicio despus de un problema (proceso de gestin de incidencias).
Buscado las causas de las incidencias y reduciendo la duracin de estas (proceso de
gestin de problemas).
Gestionando de manera segura el uso del servicio (proceso de gestin del acceso).
Manteniendo el software (funcin de gestin de aplicaciones).
Ejecutando las actividades diarias (funcin de gestin de operaciones).
Soportando la infraestructura (funcin de gestin tcnica).
La fase de mejora continua de los servicios (Continual Service Improvement) se realiza
durante todas las fases del ciclo de vida de la gestin del servicio. Est encargada de medir
el servicio y los procesos (medicin de los servicios) y de documentar los resultados
(realizacin de informes de los servicios) con el objetivo de mejorar la calidad del servicio y
la madurez de los procesos (mejora de los servicios).
Estas mejoras se pondrn en prctica durante el prximo periodo del ciclo de vida de la
gestin del servicio, comenzando de nuevo por la estrategia de servicios, seguida del
diseo de servicios y la transicin de servicios. La fase de explotacin de servicios contina
gestionando las operaciones durante todos los periodos del servicio.
Los niveles decisionales

En la toma de decisiones en el seno de una organizacin, se definen tres niveles
decisionales en la versin 3 de ITIL:
Nivel estratgico: decisiones a largo plazo, que normalmente se toman para
atender ciertas metas y objetivos. Una decisin incorrecta en este nivel tiene a
menudo consecuencias importantes o puede suponer un coste muy elevado. Estas
decisiones se toman a nivel de la Direccin informtica o la Direccin General de la
empresa.
Nivel tctico: decisiones a medio plazo, a menudo destinadas a ser proactivas y a
un nivel intermedio entre las decisiones estratgicas y operativas.
Nivel operativo: decisiones a corto plazo, a menudo decisiones reactivas, que
tendrn un impacto sobre las operaciones diarias.
Los niveles decisionales

Estos niveles se utilizan para identificar las decisiones tomadas. Tambin permiten
identificar las lneas de comunicacin entre los diferentes niveles. El nivel de comunicacin
estratgico generalmente es responsabilidad de la Direccin informtica de ms alto nivel,
o de la Direccin General de la empresa. Esto depende del tamao y la estructura de la
organizacin.
La fase de diseo de los servicios se sita entre el nivel tctico y el estratgico. La fase de
transicin de servicios se sita entre el nivel tctico y el operativo. La fase de mejora
continua de los servicios es transversal a todos los niveles decisionales.
Rol y funciones
Hemos explicado que la estructura de ITIL 2011 se basa en los procesos.
Sin embargo, para entender correctamente esta estructura hay que definir la nocin de
proceso, rol y funcin.
Ya hemos visto lo que es un proceso:
Un proceso est formado por una o varias actividades relacionadas.
Un proceso incluye uno o varios elementos de entrada y uno o varios elementos de
salida.
Una funcin es una unidad, equipo o grupo de personas, junto con los recursos y
herramientas funcionales especficas, para ejecutar un determinado tipo de trabajo y que
sern responsables de resultados concretos. Por ejemplo, el centro de servicios.
Es imprescindible que los roles y responsabilidades se definan claramente para todos los
procesos y actividades de la organizacin de los TI.
Un rol es un conjunto de responsabilidades, actividades y

asignadas a las personas de la organizacin (un grupo o equipo).
autoridades
especficas
Un rol se define en un proceso o funcin.

Una misma persona o equipo puede tener varios roles.
La nocin de rol se usa en la implementacin del modelo RACI.
Atencin con no mezclar la nocin de rol con un ttulo o el nombre de un puesto.
Los procesos y funciones de ITIL 2011

La imagen siguiente ofrece una visin del conjunto de los procesos (representados por
medio de rectngulos) y funciones (representadas por medio de valos) presentes en ITIL
2011.
Vista global de los procesos y funciones ITIL 2011

Cada fase del ciclo de vida de la gestin de servicios est compuesta por un determinado
nmero de procesos y funciones.
Fase de mejora continua de los servicios
La fase de mejora continua de servicios incluye los modelos y procesos para la
mejora continua de servicios, principalmente el proceso de mejora en siete etapas,
el Ciclo de Deming y elmodelo CSI.
Fase estratgica de servicios
La estrategia de servicios comienza con el proceso de creacin de la estrategia de
servicios genricos (creacin de la estrategia) y contina con los procesos de
gestin de la relacin comercial, del porfolio de servicios, de los servicios

financieros y de la demanda.
Fase de diseo de servicios
El diseo de los servicios se aplica a los procesos de:
Gestin de los niveles de servicio
Gestin de la continuidad de servicios informticos
Fase de transicin de servicios

La transicin de los servicios se aplica a los procesos de:
Gestin de cambios
Gestin de activos de servicio y configuraciones
Gestin de despliegues y entradas en produccin
Validacin y prueba de servicios
Evaluacin
Fase de explotacin de servicios

La explotacin de los servicios se aplica a los procesos de:
Gestin de eventos
Gestin de problemas
Gestin de la evaluacin
Tambin explica las cuatro funciones a travs de ITIL: centro de servicios,
gestin tcnica, gestin de operaciones informticas y gestin de aplicaciones.
Campo de aplicacin de los procesos ITIL 2011
LOS PROCESOS DE LA ESTRATEGIA DE SERVICIOS

La fase de la estrategia de servicios
1. Los niveles decisionales
Como hemos visto en el captulo de presentacin de la norma, ITIL est compuesto por
procesos estratgicos, tcticos y operativos.
Los niveles decisionales de la estrategia de servicios

Los procesos de la estrategia de servicios se sitan en la parte superior de la organizacin
IT.
El primer objetivo de la estrategia de servicios es definir la estrategia de la organizacin en
trminos de servicios.
2. Los procesos de la estrategia de servicios
Generacin de la estrategia de servicios
Gestin financiera
Gestin de la relacin comercial
Generacin de la estrategia
1. Enfoque
En esta seccin vamos a ver cmo se definen y ponen en prctica las estrategias de
servicios.
2. Por qu una estrategia de servicios?

La estrategia consiste en tomar una decisin sobre cmo aportar valor a un cliente, en
funcin de nuestras capacidades y aptitudes (la nuestra y la de nuestros proveedores).
Esto resulta complicado porque la negociacin es compleja e incierta. Se basa en

probabilidades; existe la necesidad de discernir las tendencias y los modos, en constante
interaccin.
3. Objetivos del proceso

Los objetivos de la estrategia de servicios son los siguientes:
Permitir la comprensin de la estrategia que se pone en marcha.
Proporcionar una definicin clara de los servicios que usa el cliente.
Tener la capacidad de definir cmo se crea y entrega el valor del servicio.
Identificar las oportunidades de servicios y cmo explotarlos.
Proponer un modelo de prestacin de servicios claro, que establezca cmo se

entregan y financian los servicios, a quin se entregan y con qu propsito.
Tener las capacidades organizativas necesarias para la ejecucin de la estrategia.
Documentar y coordinar el uso de los activos de servicio para ofrecer un servicio y

cmo optimizar su rendimiento.
Proporcionar los procesos que definen la estrategia de la organizacin, los servicios

que permitirn alcanzar la estrategia, qu nivel de inversin ser necesario, a qu
nivel de peticiones y los medios de asegurar una relacin de trabajo entre el cliente y
el proveedor de servicios.
Para esto, la direccin de la empresa dar la direccin, definir las polticas, identificar los
proyectos y asignar los recursos.
La estrategia tambin definir la priorizacin de las inversiones.
Para hacer frente a la evolucin de la empresa y de su entorno, ser necesario revisar esta
estrategia al menos una vez al ao.
4. Definiciones
Aptitud: capacidad de una organizacin, persona, proceso, aplicacin, elemento de
configuracin o servicio TI para realizar una actividad.
Recursos: trmino genrico que incluye la infraestructura, personas, medios financieros o
todo aquello que ayude a liberar el servicio.
5. Permetro
La gestin de la estrategia es responsable de proporcionar varios entregables:
Los requerimientos para el diseo de servicios.
Los requerimientos para la transicin de servicios.
Los requerimientos para la explotacin de servicios.
6. Conceptos bsicos
a. Entender los valores del servicio para los clientes
Para entender las necesidades de los clientes, es necesario entender la manera de
proporcionar un valor aadido a estos y cmo diferenciarse de otros proveedores de la
competencia.
La estrategia de servicio se basa en:
Un mejor entendimiento de las necesidades de los clientes.
Las oportunidades en trminos de servicio:

nuevos servicios,
servicios mejorados,
servicios obsoletos.
Para estar en disposicin de responder correctamente a las necesidades de los clientes y

hacerlo en plazos aceptables, la estrategia de servicios debe aplicar un porfolio de
servicios.
b. Definicin del valor aadido

El valor aadido de un servicio se debe demostrar centrndose en la utilidad y la garanta.
Es este valor aadido el que permitir a la organizacin TI y al cliente distinguir el servicio
frente a la competencia.
Utilidad del servicio

La utilidad del servicio se demuestra por la capacidad del servicio de proporcionar
resultados en consonancia con los objetivos del cliente. Esto demuestra que el servicio
se adapta a las necesidades.
Esto se percibe por parte del cliente como un valor aadido, que ofrecer mejores
rendimientos. Podemos poner como ejemplo un banco que utiliza un servicio para conceder
prstamos a sus clientes.
Si la organizacin TI le ofrece un servicio que permite la aprobacin de un prstamo en 24
horas, mientras que otros bancos requieren 48 horas para hacerlo, es evidente que esta
diferencia en el tiempo de tratamiento de una peticin es una utilidad del servicio, que
permitir proporcionar un valor aadido al cliente.
Garanta del servicio

La garanta del servicio proporciona al cliente un compromiso para prestar un servicio
que respete y garantice sus requerimientos de servicio. Esto demuestra que el servicio
se adapta al uso.
La garanta del servicio se puede expresar asegurando que se respeten los siguientes
puntos:
Nivel de disponibilidad conforme a lo acordado.
Capacidad conforme a lo acordado.
Nivel de seguridad conforme a lo acordado.
Nivel de continuidad conforme a lo acordado (si se ha aplicado el proceso de gestin

de la continuidad para este servicio).
La organizacin TI debe ser capaz de proporcionar el servicio de manera continua, con un

nivel de calidad estable y permanente.
c. Actividades principales
Las cuatro actividades principales
Las cuatro actividades principales

Las cuatro actividades principales del proceso de generacin de servicios son:
Definir el mercado: se trata de entender las necesidades de los clientes y las

oportunidades en trminos de servicios.
Desarrollar las ofertas: a partir del anlisis hecho en la etapa anterior, se definen
cules son los servicios que sern ofrecidos por la organizacin TI.
Desarrollar los activos estratgicos: como hemos visto en la seccin de

definicin del valor aadido, conviene identificar los medios que se deben aplicar
para proporcionar un valor aadido a los clientes, a travs de los servicios ofrecidos
por la organizacin TI.
Preparar la ejecucin: el objetivo es definir el contenido del porfolio de servicios y

del catlogo de servicios, as como definir cules sern los requerimientos para el
diseo, la transicin y la explotacin de servicios.
Estas actividades se ven limitadas por factores internos (organizacin, competencias de los
empleados, elecciones estratgicas de la empresa...) y por factores externos (evolucin del
mercado,
estado
de
la
competencia,
evolucin
tecnolgica,
requerimientos
reglamentarios...).
7. Roles
Los principales roles son los siguientes:
Los miembros de la Direccin de la empresa.
El responsable de la generacin de la estrategia.
El propietario del proceso.
8. Descripcin del proceso
El proceso de Generacin de la estrategia
9. Los entregables de la estrategia de servicios

La estrategia debe proporcionar varios entregables:
El porfolio de servicios.
Los requerimientos para el diseo de servicios.
Los requerimientos para la transicin de servicios.
Los requerimientos para la explotacin de servicios.
Los requerimientos para la mejora continua.
Las otras fases del ciclo de vida de los servicios pondrn en marcha soluciones que
garanticen los requerimientos en este proceso.
Gestin financiera
1. Enfoque
En esta seccin vamos a ver cmo se pone en prctica la gestin financiera.
Este proceso es importante para el correcto funcionamiento de la organizacin TI, ya que
permite conocer exactamente los costes del conjunto de servicios proporcionados al cliente
y determinar los modos de facturacin.
Este proceso tambin permite asegurar que se aplican los procedimientos y las prcticas
definidas por la gestin financiera para el conjunto de equipos de la organizacin TI.
Fundamentalmente, veremos su importancia en la forma de determinar los costes para
cada servicio.
2. Por qu una gestin financiera?

Los costes de los servicios informticos estn en continuo aumento para responder a las
necesidades, en constante evolucin, de los clientes y las empresas.
En ausencia de una gestin financiera, es difcil conocer el verdadero coste de los servicios
informticos.
Esto explica que frecuentemente haya insatisfaccin por parte de los clientes o de las
empresas, respecto a la relacin calidad/precio de los servicios que se les proponen.
La aplicacin de un proceso de gestin financiera permite identificar de manera precisa los
costes de los servicios, lo que implica que la contabilidad no resulte simple, aunque esta
sea precisa.
La versin 3 de ITIL introduce el concepto de Valorizacin del servicio.

Qu es la valorizacin?
Podemos definir este trmino de las siguientes maneras: Reconocimiento del valor de
cualquier cosa para sacar de ella ms recursos. Desde un punto de vista econmico:
Aumento del valor de mercado de un producto o servicio por medios legales o una accin
voluntaria.
En el caso de ITIL se trata de valorizar, en trminos financieros, las inversiones realizadas
por la empresa y la organizacin TI. Esta valorizacin se basa en el valor acordado de los
servicios ofrecidos por la organizacin TI.
La valorizacin del servicio es una media del coste total de entrega de un servicio
informtico y del valor total para la empresa de ese servicio. La estimacin del valor del
servicio se utiliza para permitir a la empresa y al proveedor del servicio informtico llegar a
un acuerdo sobre el valor de este.
La valorizacin del servicio se basa en factores clave:
La prestacin de valor.
El valor potencial del servicio.
La prestacin de valor determina la base de referencia mnima del coste para proporcionar
el servicio. Es decir: cul es el coste total de entrega de este servicio?
Desde el comienzo de este libro, hemos dicho que el objetivo era proporcionar un valor
aadido al servicio prestado. El valor potencial del servicio es la componente de este valor
aadido, basado en la percepcin de valor que tiene el cliente. Este valor se calcula en
funcin de la utilidad y la garanta.
a. Otros conceptos
La modelizacin de la demanda es la identificacin de los costes de uso de un servicio y la
previsin de las implicaciones financieras de la demanda de servicios en el futuro. Se
identifican las necesidades de financiacin, las variaciones y las causas o razones de esta
variacin. La demanda del servicio se puede gestionar a travs de la tarificacin y de los
ajustes de bonus susceptibles de influir en la demanda del cliente.
La gestin del porfolio de servicios utiliza los datos proporcionados por la gestin
financiera, para comparar las unidades organizativas entre ellas o en relacin con los
proveedores externos. Esto permite decidir cmo y dnde se obtiene un servicio.

El objetivo principal del proceso de gestin financiera para un servicio interno es asegurar
una gestin econmica de los recursos TI, utilizados para proporcionar los servicios de las
TI.
Para obtener un resultado satisfactorio, es necesario poner en prctica tres actividades,
entre las cuales una es opcional:
Presupuestacin (obligatoria).
Contabilidad de las TI (obligatoria).
Imputacin (opcional).
Para una organizacin TI, la gestin financiera tambin permite poder justificar los gastos
informticos y establecer la relacin con los servicios suministrados.
Esto tambin permite participar en las decisiones de gestin en trminos de inversin
informtica.
Para esto, la gestin financiera necesita tener informacin detallada de los cambios.
4. Definicin
Presupuestacin (Budgeting): es un proceso de previsin y control de los gastos
informticos.
Contabilidad (Accounting): es el proceso habitual que permite conocer y verificar los
costes por cliente, servicio o actividad.
Imputacin (Charging): es el proceso que permite facturar los costes de un servicio a un
cliente. Tambin se conoce como facturacin.
5. Permetro
La gestin financiera es responsable de:
Prever la financiacin.
Establecer un plan operativo.
Realizar el anlisis de costes.
Definir las polticas de facturacin.
La gestin financiera cubre la totalidad de los costes de la organizacin TI necesarios para

poner en marcha los servicios que ofrece a sus clientes.
6. Roles
Los roles principales son:
Propietario del proceso
Responsable de la gestin financiera
Responsable de la relacin comercial
Responsable de los niveles de servicios
Responsable de la capacidad
Responsable de la gestin de configuraciones
7. Indicadores
Se pueden aplicar varios indicadores para elaborar un cuadro de mando. Este cuadro de
mando se deber proporcionar a la Direccin:
Importe de los gastos de las TI durante el ejercicio
Importe de las facturas
Importe de las ganancias
Perspectivas de coste
Perspectivas de ganancias
Inversiones futuras...
En funcin de los modos de puesta en marcha, ser el cliente o la actividad quien

proporcione estos indicadores.
Esta lista no es exhaustiva; conviene definir los indicadores en funcin de la estructura que
se ponga en marcha.
El proceso de Gestin financiera
9. Conceptos bsicos
a. El ciclo de vida de la gestin financiera
El ciclo de vida de la gestin financiera
b. Las relaciones con los otros procesos

La gestin de activos y configuraciones
La gestin financiera necesita informacin de los activos de la organizacin TI.
Esta informacin est disponible y actualizada continuamente por la gestin de activos y
configuraciones (gestin de los CI, su estado, coste y las relaciones entre estos activos).
La gestin de la demanda
La gestin de la demanda es un punto de entrada para la gestin financiera, ya que
permite conocer los costes de la puesta en marcha de un servicio.
La gestin de la relacin comercial

La gestin de la relacin comercial necesita la informacin financiera relativa a los costes
de las soluciones e inversiones necesarias, principalmente en trminos de activos de
servicios. Este proceso tambin tendr que proporcionar informacin a la gestin
financiera.
La gestin del porfolio de servicios

La gestin del porfolio de servicios necesita informacin de la gestin financiera para
comparar los costes de las entidades organizativas entre ellas o con los proveedores
externos, con objeto de decidir cmo se proporcionarn los servicios.
La gestin de la capacidad
La informacin de costes es imprescindible para evaluar los costes de la gestin de la
capacidad.
La informacin conseguida para determinar los costes tambin ser til para las diferentes
evaluaciones de recursos e inversiones.
La gestin de los niveles de servicios

El SLR y despus el SLA definen las expectativas del cliente.
El coste del servicio puede tener un impacto importante en la forma y alcance de los
servicios ofrecidos por la organizacin TI.
La gestin financiera trabaja en estrecha colaboracin con la gestin de los niveles de
servicio, para definir los modos de facturacin que se utilizarn para el cliente.
Atencin! No hay que olvidar que, si bien es necesario tener en cuenta los costes
relacionados directamente con la produccin del servicio, tambin hay que tener en cuenta
los diferentes costes generales necesarios para el funcionamiento de la organizacin TI.
c. Planificacin de la gestin financiera

La puesta en marcha de la gestin financiera se basa en tres subprocesos: la
presupuestacin, la contabilidad y la facturacin.
La puesta en marcha de estos tres procesos se puede hacer por etapas.
Este debe ser un proyecto de empresa y formar parte del proyecto de implantacin de la
estrategia ITIL.
Ser necesario establecer un plan de aplicacin, definir las polticas de facturacin e
identificar los costes y los beneficios esperados.
Una vez ms, es mejor ser modestos y comenzar por un permetro restringido para validar
las opciones tomadas, antes de hacer un despliegue generalizado.
Poner en marcha la gestin financiera implica un fuerte compromiso de la direccin de la

empresa en el proyecto.
d. La presupuestacin
El objetivo de la presupuestacin es asegurar la concordancia entre el presupuesto
provisional y el coste real de servicios.
La creacin del presupuesto permite asegurar que la financiacin prevista es suficiente para
proporcionar los servicios.
El presupuesto se hace a partir de las previsiones de beneficios y los gastos necesarios
para proporcionar los servicios. Se establece anualmente.
Los gastos necesarios y planificados son los siguientes:
Compra de hardware
Compra de software
Contratos de mantenimiento (software y hardware)
Recursos humanos
Instalaciones
Servicios externos
Servicios internos
Todos los dems costes relacionados con la prestacin del servicio
La presupuestacin permite:
Prever la financiacin necesaria para gestionar la organizacin TI durante un periodo

dado.
Tener la seguridad de que los ingresos estarn disponibles para soportar los gastos
previstos.
Asegurar que los gastos reales se mantienen conforme a las previsiones.
Para ser eficaz, la presupuestacin implica una revisin peridica con objeto de tener en
cuenta los cambios y controlar la coherencia entre el presupuesto y lo realizado.
e. La contabilidad
Es el proceso contable habitual el que permite conocer y verificar los costes por cliente,
servicio o actividad.
La organizacin TI se puede ver como un centro de coste o, por el contrario, como un

centro de beneficios.
El hecho de poner en marcha ITIL facilita la transicin de la contabilidad al centro de
beneficio de la gestin de la organizacin TI.
Cuando es necesario tomar decisiones de inversin o renovacin, el hecho de disponer de
una contabilidad de los servicios informticos puede ayudar a tomar una decisin.
La contabilidad permite:
Identificar los coses en funcin de su clasificacin: costes de inversin o de

funcionamiento.
Contabilizar los gastos para el suministro del servicio.
Evaluar el coste de los cambios.
Calcular el coste del suministro de los servicios.
La contabilidad requiere competencias especiales y un conocimiento perfecto de las reglas

de contabilidad espaola, incluidas contabilidades extranjeras para algunas empresas. Por
lo tanto, es necesario tener recursos capaces de controlar estas normas.
f. La categorizacin de los costes

La contabilidad debe diferenciar la categorizacin de los costes:
Los costes de inmovilizacin.

Por ejemplo: adquisicin de un servidor.
Los costes de explotacin.

Por ejemplo: contrato de mantenimiento.
g. La facturacin
Es el proceso que permite facturar los costes de un servicio a un cliente, ya sea interno o
externo.
Es habitual que la facturacin se concrete en una factura, correspondiente a una fraccin
de la cantidad de la facturacin anual, por ejemplo 1/12 cada mes.
Sin embargo, la facturacin se puede basar en varios modelos:
Precio de coste
Coste mximo
Tarifa interna vigente
Tarifa del mercado
Precio fijo negociado con el cliente
h. La imputacin
La imputacin es opcional en el caso del suministro de servicios internos; sin embargo es
preferible ponerla en marcha desde el comienzo de la gestin financiera.
El proceso de gestin de los niveles de servicio se debe poner en marcha al mismo tiempo
que la gestin financiera si se quiere obtener un reparto justo y simple de los costes.
En este marco, es necesario distinguir varias opciones que permitirn definir las reglas de
imputacin.
Modelos de costes
Es posible definir el clculo de los costes siguiendo tres modelos:
Coste por cliente; en este caso se tiene en cuenta el conjunto de costes de los
diferentes servicios ofrecidos al cliente.
Coste por servicio; en este caso se tienen en cuenta los diferentes costes del servicio
ofrecido.
Coste por localizacin; en este caso se tienen en cuenta los diferentes costes
relacionados con el suministro del servicio, en una ubicacin particular.
Tipos de coste
Es posible repartir los costes en funcin de su tipo:
Hardware (adquisicin, ubicacin)
Software (adquisicin, ubicacin, modo ASP)
Mantenimiento (software, hardware)
Personal (salarios, formacin)
Inmuebles
Servicios externos
Transferencia de cargas
Categorizacin de los costes

Es preciso hacerse cargo de la categorizacin de los costes y diferenciar:
Las inmovilizaciones o la explotacin.

Por ejemplo: adquisicin de un servidor (inmovilizacin), frente a los contratos de
mantenimiento (explotacin).
Directos o indirectos.
Los costes directos corresponden a los costes directamente imputables a un cliente o

a un servicio.
Fijos o variables.
Por ejemplo: contrato de mantenimiento, frente a la capacidad de almacenamiento
en disco.
i. El modelo de costes para un servicio

El siguiente esquema muestra el reparto de los costes para un servicio.
Modelo de costes para un servicio

Identificamos el conjunto de elementos que forma parte de los costes de un servicio.
A partir de estos elementos, es posible definir los costes directos e indirectos.
Los costes directos son claramente identificables y directamente imputables a un servicio.
En la imagen, el servicio entregado al cliente es una prestacin de tipo centro de servicios,
para una parte del hardware, software y recursos humanos.
Los costes indirectos son los costes que no son directamente imputables a un servicio.
Por ejemplo, las instalaciones no son directamente imputables a un servicio, pero, si se
define un coste asignado a cada empleado, entonces es posible asig-nar un coste indirecto
para cada servicio, en funcin del nmero de empleados. En este caso se habla de costes
indirectos absorbidos.
En el ejemplo, vamos a poder asignar un coste al centro de servicios para las instalaciones
que ocupa.
Los otros costes son no imputables directamente. En este caso, se habla de costes
indirectos no absorbidos.
La recuperacin de estos costes se puede realizar por medio del aumento de un
determinado porcentaje a todos los costes.
Estos son, por ejemplo, los costes de energa, conserjera de los locales.
El acumulado de los costes directos e indirectos absorbidos va a permitir obtener los costes
absorbidos.
El hecho de aadir el incremento generado por los costes indirectos no absorbidos permitir
obtener un coste real del centro de servicios.
Se deber realizar el mismo clculo para cada servicio.

1. Enfoque
En esta seccin vamos a ver cmo se gestiona el porfolio de servicios.
Veremos que este proceso es importante para la gestin de los servicios proporcionados
por la organizacin TI.
2. Por qu una gestin del porfolio de servicios?

La organizacin TI debe conocer constantemente los servicios que ofrece a sus clientes,
pero tambin aquellos que son susceptibles de ser ofrecidos o que se han eliminado.
Este proceso debe ayudar a responder a las siguientes preguntas estratgicas:
Por qu un cliente comprara este servicio?
Por qu nos comprara a nosotros?
Cul es el modelo de precios o facturacin?
Cules son nuestras fuerzas, debilidades, prioridades y riesgos?
Cules son nuestros recursos y nuestra capacidad para ponerlos en marcha?

Para responder a las preguntas anteriores, los objetivos del proceso son los siguientes:
Proporcionar un proceso y los mecanismos para permitir a la organizacin estudiar y

decidir cules son los servicios que se tienen que proporcionar, teniendo en cuenta el
nivel potencial de retorno y los riesgos asumibles.
Mantener un porfolio de servicios actualizado, basado en las necesidades de negocio

de cada servicio y los beneficios esperados por el cliente.
Proporcionar un mecanismo a la organizacin para evaluar cmo estos servicios le

permitirn responder a sus estrategias y a los cambios de su entorno interno o
externo.
Controlar qu servicios se ofertan, en qu condiciones y con qu nivel de inversin.
Seguir las inversiones en servicios a lo largo de su ciclo de vida, permitiendo de esta

manera a la organizacin evaluar su estrategia, as como su capacidad de aplicacin.
Analizar los servicios para identificar aquellos que ya no son viables con objeto de
eliminarlos del porfolio de servicios.
4. Definicin
Porfolio de servicios: expresin de la estrategia de los servicios de la organizacin TI.
Contienen el conjunto de servicios (pipeline, catlogo de servicios y servicios eliminados).
Catlogo de servicios: es un subconjunto del porfolio de servicios. Contiene todos los
servicios operativos.
5. Permetro
La gestin del porfolio de servicios es responsable de:
La identificacin de todos los servicios.
Control de las inversiones en servicios.
Maximizar el valor de los servicios.
La construccin del paquete de servicios (SDP - Service Design Package).
6. Roles
Los roles principales son los siguientes:
Responsable del porfolio de servicios.
Responsable del catlogo de servicios.
Responsable de la relacin comercial.
Propietario del servicio.
7. Indicadores
Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:
Nmero global de servicios en el pipeline.
Nmero global de servicios en el catlogo de servicios.
Nmero global de servicios retirados del porfolio de servicios.
Nmero de servicios que se han movido en un periodo:

del pipeline al catlogo de servicios.
del catlogo de servicios a los servicios retirados.
se establezca.
El proceso de gestin del porfolio de servicios
9. Conceptos bsicos
a. El ciclo de vida de un servicio
El ciclo de vida de un servicio
b. El pipeline de servicios
El pipeline de servicios es un subconjunto del porfolio de servicios.
El pipeline de servicios contiene todos los servicios en fase de desarrollo.
Este servicio puede estar destinado a un cliente en particular o responder a un mercado
potencial.
c. El catlogo de servicios
El catlogo de servicios debe contener todos los detalles de todos los servicios operativos:
Sus caractersticas (vienen del porfolio de servicios).
Los detalles relativos a los clientes.
Sus atributos.
Su estado.
d. Servicios eliminados
Este subconjunto del porfolio de servicios contiene todos los servicios eliminados.
La organizacin TI necesita conservar los diferentes elementos relativos a los servicios
eliminados.
De hecho, stos se podran reactivar en caso de que un cliente lo solicite.
Estos servicios forman parte de los activos de la empresa.
e. El porfolio de servicios y el catlogo de servicios

La organizacin TI necesita conocer cada uno de los servicios operativos e identificar a
todos los clientes de un mismo servicio.
Para responder a esta necesidad, es aconsejable poner en prctica un porfolio de servicios
que debe contener el catlogo de servicios.
El porfolio de servicio se disea en el diseo de los servicios, pero se produce y actualiza en
la gestin del porfolio de servicios.
El porfolio de servicios debe contener un conjunto de informacin relativa a cada servicio:
Sus caractersticas (descripcin detallada).
Su valor aadido.
Los riesgos asociados.
Su coste.
Su estado.
Las opciones de estado en el porfolio de servicios contienen, al menos:
Requerimientos: la empresa o el diseo de servicios establece un conjunto de

requerimientos para un servicio nuevo o modificado.
Definido: se ha evaluado, definido y documentado el conjunto de requerimientos

para el nuevo servicio y se ha producido el SLR.
Aprobado: ha finalizado y se ha autorizado el conjunto de requerimientos para el

nuevo servicio.
Aceptado: los requerimientos del nuevo servicio se comunican y se le asig-nan los

recursos y presupuestos.
Construido: estn construidos el servicio y los componentes que forman parte de l.
Probado: estn probados el servicio y los componentes que forman parte de l.
Los servicios proporcionados por los proveedores de servicios tambin son elementos clave
del porfolio de servicios y del catlogo de servicios.
La organizacin debe definir una poltica relativa a la gestin del porfolio de servicios y al
catlogo de servicios. Esta poltica debe, en particular, definir los detalles de las
responsabilidades de cada servicio.
El diseo de servicios disea el porfolio de servicios, y la estrategia de servicios lo produce
y publica. Es un elemento de la estrategia de servicios.
Normalmente, el porfolio de servicios se divide en secciones que contienen los servicios en
funcin de las reas del negocio implicadas.
Lo ideal sera que la gestin del porfolio de servicios se hiciera con la colaboracin de
diseo, transicin de servicios, explotacin y mejora continua de servicios.
Una vez que el servicio se transfiere a la transicin de servicios, se debe incluir en el
catlogo de servicios.
El proceso de gestin de cambios debe validar todos los cambios en el porfolio de servicios
o en el catlogo de servicios.
f. El empaquetado de los servicios

La gestin del porfolio de servicios es responsable de la construccin del empaquetado de
los servicios (SDP - Service Design Package).
Este empaquetado de servicios se utilizar en las fases de diseo y transicin de servicios.
Normalmente, un servicio est compuesto por un conjunto de componentes o servicios
que, una vez ensamblados, darn lugar a un paquete de servicios.
Un paquete de servicios puede contener:
Una carta que incluye una descripcin del uso y la garanta.
Las especificaciones del servicio.
Los criterios de aceptacin del servicio.
Los modelos que se usan en la prestacin del servicio.
La arquitectura definida para entregar el servicio y las restricciones relacionadas.
Los planes de despliegue previstos.
Un paquete de servicios se puede componer de los siguientes elementos:
Un servicio bsico.
Uno o varios servicios de apoyo, que proporcionarn un valor aadido.
Mdulos complementarios.
Mdulos de extensin del servicio.
Construccin de un paquete
Para este ejemplo, podemos tomar un servicio de tipo centro de servicios.
Vamos a definir un servicio bsico; por ejemplo, un soporte de 09:00 a 17:00 h, de lunes a
viernes.
Para incluir este servicio bsico en el porfolio de servicios, debemos definir e identificar
todos los componentes de este servicio para determinar su coste.
A este servicio bsico se le podrn aadir servicios adicionales, para obtener un servicio
diferenciado para cada cliente.
Podemos hablar de la construccin de un servicio a partir de piezas, como se hace con las
piezas de LEGO.
En funcin de las necesidades del cliente, vamos a aadir una o varias piezas especficas,
correspondientes a dichas necesidades.
Podemos definir las piezas correspondientes a una extensin del servicio:
Extensin de 07:00 a 09:00 h.
Extensin de 17:00 a 19:00 h.
Extensin para el sbado.
Extensin para el domingo...
Tambin podemos definir las piezas complementarias:
Complemento para un idioma extranjero.
Complemento para un soporte de tipo penalizacin, fuera de los horarios de

apertura...
Es el conjunto de todas las piezas lo que permitir ofrecer al cliente un servicio a medida,
que corresponda a sus necesidades.
Tambin ser necesario definir los niveles de servicio asociados a cada uno de estos
mdulos y cada paquete.
Es evidente que se deber evaluar el coste de cada una de estas piezas, para poder
integrarla en un paquete antes de ofrecerlo al cliente.
Gestin de las peticiones

1. Enfoque
En esta seccin vamos a ver cmo se gestionan las peticiones de los clientes, en trminos
de peticiones de nuevos servicios.
Veremos que este proceso es muy importante para la generacin de la estrategia de
servicios.
2. Por qu una gestin de peticiones?

Los clientes expresan regularmente nuevas necesidades en forma de peticiones. La
direccin de la organizacin necesita conocer el conjunto de estas peticiones para definir su
estrategia de servicio.

Los principales objetivos del proceso de gestin de las peticiones son los siguientes:
Minimizar al mximo la incertidumbre de la peticin del cliente.
Proporcionar datos fiables para la gestin de la capacidad, con objeto de obtener una
capacidad eficiente.
4. Definicin
Pattern Business activity: esquema de actividad de negocio que ayuda al proveedor de
servicios a entender y planificar las variaciones de actividades relacionadas con el negocio.
5. Permetro
La gestin de las peticiones es responsable de:
La identificacin de las peticiones de los clientes.
La identificacin de los diferentes componentes de un servicio.
6. Roles
Responsable de las peticiones.
Responsable de la relacin comercial.
Responsable de la gestin del porfolio de servicios.
Responsable de los niveles de servicios.
Propietario del proceso.
7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Nmero de peticiones de cliente.
Nmero de peticiones tenidas en cuenta.
Nmero de peticiones planificadas a corto plazo.
Nmero de peticiones rechazadas.
Esta lista no es exhaustiva; convendr definir los indicadores en funcin de la estructura

que se establezca.
El proceso de gestin de peticiones
9. Conceptos bsicos
Minimizar la incertidumbre de la peticin
La gestin de la demanda es importante para la estrategia de servicios.
La organizacin TI necesita conocer la tendencia de evolucin de las necesidades del
cliente, para adaptar su oferta.
La organizacin TI debe ser capaz de responder a las peticiones de sus clientes, cuando
necesite la disponibilidad del servicio correspondiente a su peticin.
Para poder responder correctamente a la peticin, el proceso de gestin de la capacidad
requiere conocer la tendencia de evolucin de los servicios.
Esta tendencia de evolucin puede ser de tipo capacidad, al alza o a la baja, o de
tipo tecnologa(integracin de nuevas tecnologas o eliminacin de tecnologas obsoletas).
La adaptacin de la capacidad tendr un impacto en la calidad del servicio que se
proporcionar.
Esta medicin de la evolucin de la peticin se debe hacer escuchando al cliente y en
estrecha coordinacin con l, fundamentalmente a travs de la gestin de la relacin
comercial.
Sin embargo, en la vida real, es necesario ser realista y no creer que esto eliminar
todas las incertidumbres relacionadas con la evolucin de las necesidades de las empresas.
10. Las actividades de la gestin de peticiones

Las actividades de la gestin de peticiones implican al conjunto de fases del ciclo de vida.
Estrategia de servicios: identificar los servicios y expectativas en trminos de

resultados del cliente, as como los PBA (Patterns of Business Activity) que generan.
Previsin de peticiones en funcin de los escenarios de uso.
Soporte de la gestin del porfolio de servicios.
Diseo de servicios: confirmar los requerimientos del cliente en trminos de

disponibilidad y rendimiento, as como asegurar que los activos de los servicios
necesarios estn disponibles.
Los procesos principales en esta fase son la gestin de la capacidad y la gestin de la
disponibilidad.
La gestin de peticiones tambin permitir definir las opciones de la gestin de la
continuidad de los servicios.
Transicin de los servicios: implicacin en las pruebas y validacin del servicio, en

previsin de la explotacin y validacin de los PBA.
Explotacin de los servicios: las funciones de gestin de aplicaciones, gestin tcnica

y gestin de operaciones de supervisin del uso de los activos de servicio, en los
diferentes niveles definidos.
11. Fuentes de informacin para la gestin de peticiones

Las principales fuentes de informacin que utiliza el proceso de gestin de peticiones son:
Los Business Plan.
Los planes y previsiones de comercializacin.
Las previsiones de venta.
El lanzamiento de nuevos productos.
12. Pattern of Business Activity

El PBA o esquema de actividad de negocio ayuda al proveedor de servicios a entender y
planificar las variaciones de actividad relacionadas con el negocio. Es necesario documentar
los siguientes puntos:
Clasificacin: permite indicar cul es el tipo de cada PBA.
Atributos: frecuencia, volumen, ubicaciones y duracin.
Necesidades: rendimiento, seguridad, disponibilidad y plazo.
Activos de servicios: equipos de diseo que redactarn los perfiles de usuario para
cada PBA.
Los PBA pueden ser diarios, semanales, mensuales o anuales, en funcin de las
necesidades.
LOS PROCESOS DEL DISEO DE SERVICIOS

La fase de diseo de servicios
1. Por qu un diseo de servicios?
Como hemos visto en el captulo de presentacin de la norma, ITIL se compone de
Los niveles decisionales de gestin de los servicios

La fase de diseo de servicios se encuentra entre el nivel estratgico y el tctico.
Los procesos del diseo de servicios se sitan despus de los procesos de estrategia de
servicios.
El primer objetivo del diseo de servicios es elaborar los servicios que se explotarn a
travs de la transicin de servicios.
2. Los procesos de diseo de servicios
Gestin de la continuidad
3. Consideraciones sobre el diseo de los servicios

a. Enfoque
Las actividades de diseo de los servicios se pueden definir y analizar a partir de los cinco
aspectos principales siguientes.
Enfoque del diseo de servicios
b. El diseo de las soluciones de servicios

Durante la fase de diseo de los servicios (Service Design - SD), se deben realizar
numerosas actividades para crear un nuevo servicio o para modificar un servicio existente.
Es necesario un enfoque estructurado para desarrollar el nuevo servicio con un coste
adecuado, respondiendo a las exigencias de funcionalidad y calidad previstas, y en los
plazos acordados.
En el diseo de una solucin de servicio, se debe tener en cuenta:
El diseo de los servicios informticos y las infraestructuras existentes.
Disear las soluciones de servicios para los nuevos requerimientos.
Revisar los servicios informticos existentes.
c. El diseo de los sistemas de gestin de los servicios y las herramientas

El uso de sistemas de gestin y herramientas apropiadas permite gestionar eficazmente
todos los aspectos de los servicios a lo largo de su ciclo de vida.
El proceso de gestin del porfolio de servicios ocupa un lugar particular en la organizacin

ITIL.
El porfolio de los servicios se utiliza para dar soporte a todos los procesos y describir los
servicios de un proveedor, en trminos de valor de negocio. Define las necesidades de la
empresa y valida la adecuacin de la respuesta de los proveedores a estas necesidades.
El porfolio de servicios permite responder a las siguientes preguntas estratgicas:
Por qu un cliente debera comprar estos servicios?
Por qu debera comprarnos estos servicios a nosotros?
Cules son las tarifas y el sistema de facturacin?
Cules son mis puntos fuertes y dbiles, las prioridades y los riesgos?
Cmo se deben asignar nuestros recursos y nuestras aptitudes?
d. El diseo de las arquitecturas tcnicas

El desarrollo y despliegue de una infraestructura informtica, compuesta por un conjunto
de aplicaciones y datos, son las actividades del diseo de las arquitecturas tcnicas. Este
desarrollo se realiza con el objetivo de satisfacer las necesidades de negocio actuales y
futuras.
Tambin se deben tener cuenta los aspectos relativos a las personas, procesos y socios o
proveedores que rodean a estos componentes tcnicos.
e. El diseo de los procesos

Como recordatorio, la definicin de proceso es: conjunto estructurado de actividades
diseadas para lograr un objetivo especfico.
Para lograr este objetivo, el proceso parte de una o varias entradas y, a travs de las
diferentes actividades predefinidas, las transforma en elementos de salida.
Las actividades de planificacin y de regulacin de un proceso son las actividades de
control que van a permitir la realizacin de un proceso de manera eficiente y eficaz.
Un modelo de proceso incluye todos los roles, responsabilidades, herramientas y controles.
f. El diseo de los sistemas de medicin

El funcionamiento normal de un proceso obliga a que tenga mediciones y controles.
Esto es vlido para todos los aspectos de los procesos de diseo.
Se pueden definir y utilizar cuatro tipos de mtricas para medir la capacidad y el
rendimiento de los procesos:
Mtricas de progreso: hitos y entregables en la capacidad del proceso.
Mtricas de conformidad: conformidad de

requerimientos gubernamentales y reglamentarios.
un
proceso
respecto
los
Mtricas de eficacia: la precisin y exactitud del proceso y su capacidad de

entregar un resultado conforme a los trminos de eficacia.
Mtricas de eficiencia: la productividad del proceso, velocidad, capacidad de

tratamiento y el uso de sus recursos.
4. Las 4 P
Muchos diseos, planes y proyectos fracasan debido a diferentes motivos.
Sin embargo, muchos de estos fracasos se deben a una ausencia de preparacin de la
gestin.
La puesta en marcha de la gestin de servicios ITIL como una prctica hace referencia a la
preparacin y planificacin de un uso efectivo y eficiente de las 4 P (del
ingls People, Product,Process y Partners).
a. Personas
En esta categora incluimos a los usuarios, los clientes y al personal informtico y
responsables. Entre los elementos importantes, estn la comunicacin, la formacin y una
definicin clara de los roles y responsabilidades de todas las partes implicadas.
b. Procesos
En esta categora se encuentran los procesos ITIL, que se integran en el ciclo de vida de la
gestin de servicios:
Estrategia de servicios (Service Strategy - SS).
Diseo de servicios (Service Design - SD).
Transicin de servicios (Service Transition - ST).
Explotacin de servicios (Service Operation - SO).
Mejora continua de servicios (Continual Service Improvement - CSI).
c. Productos
Hoy en da, las organizaciones informticas disponen de un determinado nmero de
herramientas, que se anuncian como Compliant ITIL o Conforme ITIL.
Por supuesto, salvo si tiene la certificacin ITIL por la OC, estas herramientas no ofrecen
realmente una garanta de conformidad.
No hay que creer que el uso de estas herramientas va a garantizar que la organizacin TI
trabaje conforme a ITIL. Para que la organizacin TI trabaje conforme a ITIL, ser
necesario poner en prctica todos los procesos descritos en este libro, as como una
organizacin que permita este modo de funcionamiento.
d. Asociaciones
Para suministrar servicios informticos de calidad, la organizacin debe poner en marcha
un proceso de gestin de proveedores (socios, fabricantes, empresas de servicios...).
5. Los enfoques para el suministro de los servicios

La organizacin TI puede definir las estrategias para el suministro de los servicios.
No hay buena o mala estrategia, sino que todas tienen sus beneficios e inconvenientes, y
todas necesitan un cierto nivel de adaptacin y personalizacin.
En realidad, existe una buena estrategia para cada empresa. Esta estrategia debe estar en
relacin con las capacidades de la organizacin TI.
La estrategia de suministro de los servicios es responsabilidad del proceso de generacin
de la estrategia.
La organizacin no tiene necesariamente la capacidad de ofrecer el conjunto de servicios
solicitados por sus clientes. En este caso, la organizacin buscar una solucin alternativa
para responder positivamente a estos.
Esta solucin deber garantizar la continuidad del suministro y la calidad de los servicios
suministrados.
Esta solucin alternativa pasa a menudo por la externalizacin de una parte o del servicio
completo.
Lo primero de todo es que la organizacin TI se debe formular las siguientes preguntas:
Por qu externalizar?
Qu se debe externalizar?
A qu se debe parecer la relacin?
Cmo llegar?
Las principales estrategias para el suministro de servicios se describen ms adelante.
a. Internalizacin
Esta estrategia se basa en el uso de los recursos organizativos internos de la organizacin
TI.
Estos recursos se asignan al diseo, desarrollo, transicin, mantenimiento y explotacin.
Estos recursos garantizan el soporte de los servicios nuevos, modificados o revisados.
b. Externalizacin
Esta estrategia se basa en el uso de los recursos de una o varias organizaciones externas
para proporcionar una parte claramente definida del diseo, desarrollo, mantenimiento,
explotacin o soporte de un servicio.
Los servicios de aplicaciones de tipo ASP pueden estar en esta categora.
La firma de un acuerdo oficial entre la organizacin TI y el proveedor externo se debe hacer
en forma de contrato de tipo UC (Underpinning Contract).
c. Cosourcing
Esta estrategia consiste en una combinacin de recursos internos y externos que colaboran
para suministrar en comn los elementos claves del ciclo de vida.
Normalmente, esto implica el uso de varias organizaciones externas que colaboren en el

diseo, desarrollo, transicin, explotacin y soporte de una parte de un servicio.
d. Asociacin o multisourcing
En esta estrategia, los acuerdos oficiales se establecen entre dos o ms organizaciones
para colaborar en el diseo, desarrollo, transicin, explotacin o soporte de los servicios
informticos.
Se debe prestar una atencin especial a las asociaciones estratgicas que favorezcan la
competencia y las oportunidades comerciales.

1. Enfoque
En esta seccin vamos a ver cmo se gestiona el diseo de los servicio para nuevos
servicios o para modificar los existentes.
Para alcanzar los objetivos definidos en la fase de la estrategia, es necesaria una buena
coordinacin entre los diferentes procesos y actores de esta fase del ciclo de vida de los
servicios.
El objetivo de este proceso es asegurar que se alcanzan los objetivos de la fase de diseo
de los servicios, manteniendo un nico punto de coordinacin y control para todas las
actividades y procesos de esta fase.

Los objetivos de este proceso son los siguientes:
Asegurar un diseo coherente de los servicios para responder a los requerimientos y

expectativas del cliente, fundamentalmente en trminos de resultados.
Evidentemente, esto implica a la gestin del sistema de informacin, arquitectura,
tecnologa, procesos, informacin y mtricas. Esto debe responder a las necesidades
actuales del cliente y su evolucin en un entorno cambiante.
Coordinar todas las actividades de diseo a travs de los proyectos, cambios,

proveedores y equipos de soporte, gestin de planificaciones, recursos y conflictos.
Planificar y coordinar los recursos y las capacidades necesarias para disear o

modificar los servicios.
Producir los SDP (Service Design Packages), basados en la carta de servicios y las
peticiones de cambio.
Asegurar que el diseo de los servicios y SDP se produce y transmite a la fase

transicin de servicios.
Gestionar los criterios de calidad, requerimientos entre las fases de estrategia y

Asegurar que todos los modelos de servicios y soluciones diseadas estn de acurdo
con la estrategia, la gestin y el resto de los requerimientos de la empresa.
Mejorar la eficacia y efectividad de las actividades y procesos.
Asegurar que todas las partes adoptan los estndares comunes, las prcticas de
reutilizacin de las actividades y los procesos y sistemas de soporte apropiados.
Mejorar el rendimiento de la fase de diseo de los servicios.
Proceso de coordinacin del diseo
4. Conceptos bsicos
a. Polticas de diseo
El proveedor del servicio debe definir las polticas que permitirn identificar el tipo de
diseo sobre el que la coordinacin debe prestar ms atencin.
Por ejemplo, este puede ser el caso para los cambios importantes, y el resto de los cambios
tendrn que corresponder a las normas de diseo definidas en este proceso.
Tambin se debe definir los niveles de documentacin. Para un cambio importante, puede
ser necesario tener un paquete de diseo (SDP - Service Design Package) completo,
mientras que para los cambios menos importantes ser suficiente con una documentacin
simplificada.
Las polticas de diseo deben incluir:
El respeto de los estndares y convenciones de la empresa.
El respeto de las reglas de gestin en todas las actividades.
La puesta en marcha de estndares para asegurar una buena comprensin de las

actividades de diseo:
Modelos de documento
Planes de documentacin
Planes de formacin
Planes de marketing y comunicacin
Planes de medida y mtricas
Planes de prueba
Planes de despliegue
Criterios para resolver los posibles conflictos de asignacin de recursos.
Modelos de coste estndares.
5. Indicadores
Evolucin del porcentaje de los servicios (diseo o cambio) exitosos, en trminos de

calidad, coste y respeto de los plazos.
Reduccin del nmero de cambios urgentes que se crean como consecuencia del
diseo de los servicios.
Satisfaccin del cliente para cada servicio nuevo o modificado.
se ponga en marcha.

1. Enfoque
En esta seccin vamos a ver cmo se gestiona el catlogo de servicios.
Veremos que este proceso es importante para la gestin de los servicios proporcionados
por la organizacin TI, y principalmente para la gestin de la relacin comercial, la gestin
de los niveles de servicios y el centro de servicios.
2. Por qu una gestin del catlogo de servicios?

La organizacin informtica necesita conocer cada uno de los servicios operativos e
identificar todos los clientes de un mismo servicio.

Los objetivos principales del proceso de gestin del catlogo de servicios son:
Mantener el conocimiento y comprensin de los servicios operativos establecidos por

la organizacin TI.
Mantener la informacin contenida en el catlogo de servicios.
Asegurar la coherencia de la informacin entre el porfolio de servicios y el catlogo

de servicios.
Asegurar la coherencia de la informacin contenida en el catlogo de servicios,

principalmente de todos los detalles, los estados, las interfaces y las dependencias.
4. Definicin
Porfolio de servicios: expresin de la estrategia de servicios de la organizacin TI.
Catlogo de servicios: contiene todos los servicios operativos o listos para usar.
5. Permetro
La gestin del catlogo de servicios, que es un subconjunto del porfolio de servicios, es
responsable de todos los servicios operativos.
La gestin del catlogo de servicios cubre:
La contribucin a la definicin de los servicios y paquetes de servicios (SDP).
El desarrollo y mantenimiento de la descripcin de los servicios y paquetes de

servicios (SDP).
La produccin y mantenimiento de un catlogo de servicios actualizado.
Asegurar la coherencia de la informacin relativa a las interfaces y las dependencias

con el porfolio de servicios.
6. Roles
Responsable del catlogo de servicios
Responsable del porfolio de servicios
7. Indicadores
Nmero de servicios en el catlogo de servicios.
Nmero de servicios retirados en el periodo.
Nmero de servicios movidos en un periodo:

Del pipeline al catlogo de servicios.
O del catlogo a los servicios retirados.
Esta lista no es exhaustiva; convendra definir los indicadores en funcin de la estructura

que se ponga en marcha.
El proceso de gestin del catlogo de servicios
9. Conceptos bsicos
a. El catlogo de servicios
La organizacin informtica necesita conocer cada uno de los servicios operativos e
identificar a todos los clientes de un mismo servicio.
Para dar respuesta a esta necesidad, es aconsejable poner en marcha un catlogo de
servicios.
El catlogo de servicios es un subconjunto del porfolio de servicios.
El catlogo de servicios debe contener todos los detalles de todos los servicios operativos:
Sus caractersticas
Sus interfaces
Sus dependencias
Los procesos relacionados
Sus atributos
Su estado (le que debe ser nico)
Su precio
Los soportes...
El catlogo de servicios est compuesto por dos secciones:
El catlogo de servicios profesionales. Solo los clientes o posibles clientes pueden ver
este catlogo.
El catlogo de servicios tcnicos.
Todos los cambios en el porfolio de servicios o en el catlogo de servicios se deben validar

por el proceso de gestin de cambios.
Relaciones entre los componentes del catlogo
Relaciones entre los componentes del catlogo de servicios
El catlogo de servicios profesionales

El catlogo de servicios de negocio contiene detalles de todos los servicios informticos
entregados a los clientes.
Deben estar descritas las relaciones entre los procesos profesionales y los servicios.
El catlogo de servicios tcnicos

El catlogo de servicios tcnicos contiene los detalles de todos los servicios informticos
entregados a los clientes.
Se deben describir las relaciones entre los servicios, los servicios compartidos, los
componentes y los CI necesarios para soportar los servicios.
b. Porfolio de servicios y catlogo de servicios

El diseo de servicios disea el porfolio de servicios, pero este se actualiza en gestin del
porfolio de servicios.
Los servicios proporcionados por los proveedores de servicios tambin son los elementos
clave del porfolio de servicios y del catlogo de servicios.
La organizacin debe definir una poltica relativa a la gestin del porfolio y catlogo de
servicios. En particular, esta poltica debe definir los detalles de las responsabilidades para
cada servicio.
La gestin del porfolio de servicios se deber realizar, de manera ideal, con la colaboracin
de diseo, transicin, explotacin y mejora continua de servicios.
Tan pronto como se transfiere un servicio a transicin de servicios, este se debe incluir en
el catlogo de servicios.

1. Enfoque
En este apartado vamos a ver cmo se gestionan los diferentes contratos de servicio.
Veremos que este proceso es especialmente importante para la gestin de los servicios
proporcionados por la organizacin TI.
Esto implica tanto a las relaciones entre el cliente como a las diferentes entidades de la
organizacin TI y la gestin de los contratos con los subcontratistas.
2. Por qu una gestin de los niveles de servicio?

Es imprescindible verificar y validar las necesidades y requerimientos del cliente, y definir
cules sern los compromisos que se deben aplicar entre los diferentes actores del entorno
TI y, en particular, entre los clientes y la organizacin TI. Estos compromisos deben estar
definidos obligatoriamente en los contratos firmados por las diferentes partes implicadas en
los acuerdos de servicio.
Una vez establecidos, los contratos de servicio permiten identificar los objetivos especficos
y medir sus logros.

El proceso de gestin de los niveles de servicios debe responder a varios objetivos. El
principal es definir, documentar, acreditar, vigilar y medir los niveles de servicio
proporcionados y, si es necesario, tomar medidas correctivas.
Hay otros objetivos importantes, como proporcionar informes del nivel alcanzado de los
objetivos definidos en los compromisos y el mantenimiento y la mejora de la relacin con el
cliente, en coordinacin con el proceso de gestin de la relacin comercial; estos elementos
van a ayudar a mantener y mejorar la calidad de los servicios y vigilar y mejorar la
satisfaccin del cliente, respecto a los servicios proporcionados.
En ltimo lugar, pero igualmente importante, es necesario asegurar la comprensin clara y
no ambigua de los compromisos de niveles de servicios entre la organizacin TI y el cliente.
4. Definicin
Service Level Requirement (SLR): es la expresin de las necesidades del cliente.
Service Level Manager (SLM): es el responsable de la gestin de los niveles de servicio.
Service Level Agreement (SLA): acuerdo de niveles de servicio alcanzado entre el
cliente y la organizacin TI.
Operationnal Level Agreement (OLA): acuerdo de niveles de servicio entre las
diferentes entidades o servicios de la organizacin TI.
Underpinning Contract (UC): contrato que establece las relaciones entre la organizacin
TI y los subcontratistas o proveedores.
Catlogo de servicios: documento que presenta el conjunto de servicios proporcionados
por la organizacin de los TI.
Service Improvement Program (SIP): programa de mejora de servicios. Es un
documento que presenta las acciones de mejora de la gestin de los TI y de la relacin con
el cliente.
Auto-conmutador: equipamiento que permite el enrutamiento de las comunicaciones
telefnicas.
ACD: equipamiento que permite el enrutamiento de las comunicaciones telefnicas, segn
un programa que tiene en cuenta los diferentes parmetros predefinidos por la
organizacin TI.
5. Permetro
La gestin de los niveles de servicio es responsable de las siguientes acciones:
Cooperar con la gestin de la relacin con el cliente.
Establecer y negociar los requerimientos de niveles de servicios solicitados por el

cliente.
Establecer los requerimientos de los niveles de servicio entre las diferentes entidades
de la organizacin TI y gestionarlos (OLA).
Establecer contratos de servicios con proveedores externos (UC) y asegurar que

estn alineados con los SLA y OLA.
Proporcionar un punto de contacto regular y comunicarse con el cliente o los

profesionales.
Proporcionar seguimiento e informes de la realizacin de los servicios, en particular

de los ausentes.
La gestin de los niveles de servicios cubre la totalidad de los servicios ofrecidos por la
organizacin TI, as como la totalidad de servicios proporcionados por los subcontratistas o
los proveedores de servicios.
6. Roles
Responsable de los cambios
Responsable de los activos y configuraciones
Responsable de los niveles de servicios
7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso. Deben
estar definidos en el SLA y sern especficos para cada servicio implicado en un contrato.
Por lo tanto, no es posible dar aqu ejemplos, ya que dependen mucho del servicio ofrecido
al cliente.
El proceso de gestin de los niveles de servicios
9. Conceptos bsicos
a. Relaciones entre la gestin de la relacin y la gestin de los niveles de servicio
El objetivo principal de la gestin de los niveles de servicio es asegurar la consecucin de
los niveles de servicio definidos. Es una gestin diaria.
El objetivo de la gestin de la relacin comercial tiene una orientacin a medio o largo
plazo. Se trata de identificar las necesidades del cliente y asegurar la capacidad de la
organizacin TI para responder a estas necesidades. Este proceso se centra en la relacin
global entre el proveedor de servicios y su cliente.
b. El ciclo de vida de un contrato de niveles de servicio
El ciclo de vida de un acuerdo de niveles de servicio
c. Expresin de la peticin del cliente

La expresin de la peticin del cliente se debe realizar a travs de un documento
llamado SLR (Service Level Requirement).
Este documento deber tener en cuenta las necesidades del cliente y, en particular, los
objetivos e indicadores deseados por este.
A partir de este documento, el SLM (Service Level Manager) va a establecer su peticin de
cambios (RFC - Request For Change).
El examen de esta peticin por la gestin de cambios permitir identificar los diferentes
equipos que contribuirn al suministro del servicio y a la construccin del acuerdo de
niveles de servicio, que se firmar con el cliente (SLA).
En este marco, el responsable de los cambios transmitir a los diferentes miembros del
CAB (Change Advisory Board - grupo de personas encargadas de aconsejar al responsable
de los cambios) los documentos relativos a este cambio.
d. Estudio y puesta en marcha de un contrato SLA

El SLM asegura la negociacin entre el cliente y el proceso de cambios, con el objetivo de
encontrar un equilibrio entre las necesidades del cliente y aquello que la organizacin TI
est en disposicin de suministrar.
Esta negociacin puede requerir varios ciclos de ida y vuelta entre el cliente y el SLM, y el
SLM y los propietarios/responsables de los procesos implicados en el servicio (proceso de
gestin de la capacidad, proceso de gestin de la disponibilidad, proceso de gestin de la
continuidad, proceso de gestin de la seguridad, proceso de gestin de incidencias, centro
de servicios...). El SLM volver entonces a dirigirse hacia el proceso de gestin de cambios,
para encontrar la adecuacin entre la peticin del cliente, expresada en el SLR, y lo que
ofrece la organizacin TI.
Ser necesario definir paralelamente los contratos de niveles de servicio entre las
diferentes entidades de la organizacin TI (OLA - Operationnal Level Agreement) y
tambin, si fuera necesario, entre la organizacin TI y los subcontratistas o proveedores
(UC - Underpinning Contract).
Cuando se alcance un acuerdo con el cliente, ser necesario establecer un contrato entre
las dos partes, el SLA (Service Level Agreement), antes de que el servicio se pueda poner
en marcha.
Los diferentes acuerdos de servicio se debern registrar en la CMS, a partir del porfolio y
del catlogo de servicios (ver los captulos correspondientes a estos procesos).
Un SLA debe ser un documento escrito, firmado por las dos partes, en trminos no tcnicos
y comprensible para todos. Debe contener un determinado nmero de elementos que
describan de manera precisa los compromisos y los indicadores, lo que permitir asegurar
que se respetan los compromisos. Estos acuerdos deben, por supuesto, definir los derechos
y deberes de las dos partes.
Para ser eficaz, el SLA debe ser un acuerdo real entre la organizacin TI y el cliente. Un
acuerdo desequilibrado provocar, tarde o temprano, una situacin de difcil manejo y la
insatisfaccin del cliente.
Con frecuencia, en la actualidad, al menos en el mbito de los acuerdos de servicio con
grandes empresas, son estas las que imponen sus propios contratos a la organizacin TI.
Muy a menudo, las razones dadas por estas empresas estn basadas en cuestiones
jurdicas.
En este caso, la organizacin TI debe tomar todas las precauciones para que el contrato
que se le ofrece rena todos los elementos correspondientes al servicio propuesto.
Lo que debe contener un SLA

A continuacin encontrar un ejemplo de los elementos que deber contener, como
mnimo, un SLA para un centro de servicios.
Es necesario indicar que este ejemplo solo es vlido para este tipo particular de servicio.
Se deber adaptar al servicio realmente proporcionado por la organizacin TI.
Descripcin del servicio.
Duracin del contrato.
Permetro del servicio.
Horarios de suministro del servicio (de 08:00 a 18:00).
Disponibilidad del servicio (de lunes a viernes).
Fiabilidad del servicio (90% de las llamadas entrantes deben ser atendidas).
Soporte del servicio (nivel de competencias exigidas a los tcnicos).
Rendimiento del servicio:

Volumen de llamadas entrantes.
Plazo en el que se deben atender las llamadas (90% de las llamadas entrantes
atendidas en menos de 30 segundos).
Plazo de suministro de una solucin (2 horas para una llamada de prioridad 2)...
Condiciones de puesta en marcha de un cambio o evolucin del servicio.
Continuidad de los servicios de la organizacin TI.
Seguridad de los servicios de la organizacin TI.
Seguridad de
disponibilidad).
Responsabilidades de TI y del cliente.
Informes y revisiones de los servicios (planificacin de los comits de control).
Incentivos/penalizaciones de rendimiento...
la
informacin
de
los
clientes
(confidencialidad,
integridad,
Todos los indicadores u objetivos definidos en los acuerdos deben ser medibles.
La aplicacin de penalizaciones financieras deber estar acompaada de la aplicacin de
incentivos financieros. Estos incentivos se debern poner en marcha tan pronto como la
calidad del servicio est por encima del umbral predefinido.
Definicin de los indicadores y objetivos en el mbito de un SLA

En el mbito de la puesta en marcha de un acuerdo de tipo SLA, es necesario estar atentos
a la definicin de los objetivos e indicadores.
Definicin de los indicadores

En el ejemplo anterior, para estar seguros de no sobrepasar un objetivo de llamadas no
respondidas superior al 15% de las llamadas entrantes, ser necesario fijar objetivos ms
ambiciosos para las diferentes entidades implicadas en la realizacin del servicio.
Se dar el objetivo del 12% a los tres equipos, y se deber firmar un acuerdo de niveles de
servicio de tipo OLA con cada uno de los 3 equipos.
De esta manera, aunque uno de los equipos no alcance su objetivo, esto permitir
mantener la consecucin del objetivo final.
Si uno de los equipos (por ejemplo: equipo A) subcontrata una parte de su actividad, ser
prudente a la hora de fijar al subcontratista un objetivo superior, por ejemplo, menos del
10% de llamadas no atendidas, con el objetivo de mantener el objetivo inicial fijado para el
equipo A, en caso de dificultades leves del subcontratista.
Ejemplos:
El centro de servicios recibe 1.000 llamadas al mes, y el objetivo est fijado en el 15%.
El objetivo de llamadas no respondidas o perdidas es equivalente a menos de 150
llamadas/mes.
A los 3 equipos se les ha fijado un objetivo del 12% mximo de llamadas no respondidas,
es decir, 120 llamadas/mes como mximo.
El equipo A recibe
300 llamadas/mes.
400
llamadas/mes
los
otros
equipos
reciben
cada
uno
Esto significa que el equipo A no debe perder ms de 48 llamadas por mes y que los otros
no deben perder ms de 36 llamadas/mes.
El equipo A subcontrata la mitad de su actividad, es decir, 200 llamadas/mes.
Deber firmar un acuerdo de tipo UC que prevea un objetivo inferior al 10% de las
llamadas, es decir, un mximo de 20 llamadas/mes.
Caso 1
Si los resultados del subcontratista no son los correctos, por ejemplo, 30 llamadas
perdidas, y el equipo A se encuentra justo en el lmite del objetivo de la parte que l
realiza, es decir, 24 llamadas perdidas, el objetivo global fijado para el equipo A se
sobrepasa: 30 + 24 = 54 llamadas perdidas.
En la hiptesis de que los otros dos equipos estn tambin en el lmite de sus objetivos, el
nmero de llamadas perdidas por el conjunto del centro de servicios ser entonces de 36 +
36 + 54 = 126 llamadas perdidas.
Esto significa que, aunque el conjunto de los equipos no ha sido especialmente eficaz, los
objetivos del SLA sin embargo son correctos: 126 llamadas perdidas para un objetivo
mximo de 150 llamadas.
Caso 2
El equipo B tiene dificultades serias y pierde 50 llamadas.
Los otros equipos estn en el lmite de sus objetivos.
El nmero total de llamadas perdidas ser entonces de: 48 + 36 + 50 = 134 llamadas
perdidas para un objetivo mximo de 150 llamadas.
Los objetivos del SLA sern, sin embargo, correctos.
Estos dos ejemplos muestran que la fijacin de objetivos superiores permite mantener el
objetivo fijado en el SLA, incluso en caso de que un equipo falle.
e. Estudio y puesta en marcha de un acuerdo OLA

Normalmente, el suministro de un servicio al cliente implica actividades para varias
entidades de la organizacin TI.
Es necesario definir en qu mbito debern proporcionar sus servicios estas diferentes
entidades.
Para ello, se debe establecer un acuerdo de niveles de servicios especfico.
Este acuerdo se llamada OLA (Operational Level Agreement).
Este acuerdo se firma entre la entidad responsable de proporcionar el servicio al cliente y
cada una de las otras entidades que contribuye al suministro del servicio.
Lo que debe contener un OLA

Ms adelante encontrar un ejemplo de los elementos que debera contener, como mnimo,
un OLA para una prestacin de centro de servicios. Describe los compromisos entre el
centro de servicios y el equipo de informtica interna.
Es necesario indicar que este ejemplo slo es vlido para este tipo particular de servicio. Se
debe adaptar al servicio realmente proporcionado por la organizacin TI.
Descripcin del servicio.
Permetro del servicio.
Horario de suministro del servicio (de 7:00 a 19:00).
Disponibilidad del servicio (de lunes a viernes).
Fiabilidad del servicio (100% en los horarios de suministro del servicio al cliente).
Soporte del servicio (nivel de competencias exigido para los tcnicos que intervienen
en la plataforma del centro de servicios).
Rendimiento del servicio:

Plazos de intervencin sobre un puesto de trabajo.
Plazos de intervencin sobre un puesto telefnico.
Plazos de restablecimiento en caso de incidencia sobre un autoconmutador.
Plazos de restablecimiento en caso de una incidencia sobre el ACD.
Plazos de suministro para la instalacin de un nuevo puesto de trabajo.
Flujo de ancho de banda...
Condiciones de puesta en marcha de un cambio o evolucin del servicio.
Continuidad de los servicios de la organizacin TI.
Seguridad de los servicios de la organizacin TI.
Seguridad de la informacin de cliente (confidencialidad, integridad y disponibilidad).
Responsabilidades del centro de servicios y del equipo de informtica interna.
Informes y revisiones del servicio (planificacin de los comits de control).
Coste interno de los diferentes elementos del servicio.
Imputacin de los diferentes elementos del servicio...
f. Estudio y puesta en marcha de un acuerdo UC (Underpinning Contract)

En algunos casos, la organizacin puede tener una estrategia de externalizacin, para
ciertos servicios o parte de los servicios.
Esta estrategia se basa en el uso de los recursos de una o varias organizaciones externas,
para suministrar una parte claramente definida del diseo, desarrollo, mantenimiento,
explotacin y/o soporte de un servicio.
Los servicios de aplicaciones de tipo ASP pueden estar dentro de esta categora.
La firma de un acuerdo oficial entre la organizacin TI y el proveedor externo se hace en
forma de contrato de tipo UC (Underpinning Contract).
Los objetivos que se definirn con el subcontratista o el proveedor deben estar adaptados
para responder a los objetivos fijados en los acuerdos de niveles de servicio firmados con el
cliente (SLA).
En este tipo de contrato, la organizacin TI es cliente del proveedor.
Atencin, hay que diferenciar entre los acuerdos (tipos SLA y OLA) y el contrato (tipo
UC).
10. Beneficios y dificultades

a. Beneficios
La gestin de los niveles de servicio permite una buena relacin con el cliente.
Permite poner en prctica los contratos que servirn de base para medir la efectividad y
eficacia de los procesos a travs de los diferentes indicadores que se aplicarn.
La validacin de los acuerdos por el proceso de cambios garantizar la adecuacin entre las
necesidades del cliente y las capacidades de la organizacin TI.
b. Dificultades potenciales
Es imprescindible que los contratos sean claros y precisos.
Un error comn es la definicin de los indicadores.
Es necesario prestar atencin a lo que se desea medir y tambin al volumen de los
elementos medibles. Si toma un indicador con un umbral muy elevado y un volumen bajo,
corre el riesgo de sobrepasar este umbral aunque solo est fallando un nico elemento.
Por ejemplo
Nmero de incidencias principales tratadas en menos de 1 hora, con un umbral del 90%.
Si slo tiene 10 incidencias principales por mes, es suficiente una nica incidencia tratada
en 1 hora para sobrepasar el umbral.
Por lo tanto, este no es un buen indicador!
Atencin tambin al seguimiento de los contratos y acuerdos de servicios.

Las reuniones de seguimiento se deben realizar en los plazos previstos en el contrato o los
acuerdos de servicio. Tambin se deben elaborar y distribuir los informes.
1. Enfoque
En esta seccin vamos a ver cmo se gestiona la capacidad de la organizacin TI.
Veremos que el suministro de servicios y su calidad dependen mucho de la eficacia del
proceso.
2. Por qu una gestin de la capacidad?

En un entorno actual, donde los presupuestos estn impuestos en general, es importante
asegurar que los costes en inversin y funcionamiento estn perfectamente justificados y,
sobre todo, que estos costes permiten proporcionar los medios necesarios para entregar los
servicios, respetando los compromisos que figuran en los SLA.
Es imprescindible adaptar las actividades de la organizacin TI para utilizar eficientemente
los recursos.
Para esto, es indispensable controlar el rendimiento y la rentabilidad de los servicios
ofrecidos por la organizacin TI.
Es imprescindible comprender las peticiones actuales de servicios informticos de los
clientes para prever los requerimientos futuros.
Igualmente, es necesario ajustar el uso de los recursos teniendo en cuenta otros procesos
de gestin de servicios.
ltimo punto: es necesario elaborar un plan de la capacidad que prevea los recursos de la
organizacin TI, necesarios para atender los niveles de servicio pactados en los acuerdos
de servicios (SLA).
La gestin de la capacidad y de la disponibilidad son esenciales para asegurar la parte de

Garanta en el valor del servicio (Valor del servicio = Utilidad + Garanta).

Los objetivos principales del proceso de gestin de la capacidad son los siguientes:
Producir y mantener un plan de capacidad, apropiado y actualizado, que refleje las

necesidades actuales de la organizacin TI.
Garantizar que el rendimiento de servicios corresponde o excede los objetivos de

rendimiento acordados en los SLA, gestionando el rendimiento y la capacidad de
servicios y los recursos de la organizacin TI.
Proporcionar los consejos y servir de gua, para todos los problemas relacionados con
la capacidad y el rendimiento, al resto de los sectores de la organizacin TI y de la
empresa.
Evaluar el impacto de todos los cambios solicitados, en trminos de plan de

capacidad, recursos y rendimiento.
Tomar medidas proactiva para mejorar el rendimiento de los servicios, siempre que
tenga justificacin financiera.
El proceso de gestin de la capacidad tambin tiene la responsabilidad de asegurar el

sistema de alertas de novedades tecnolgicas para la organizacin TI.
4. Definicin
BCM (Business Capacity Management): subprocesos cuyo objetivo es garantizar que se
tienen en cuenta los requerimientos futuros.
SCM (Service Capacity Management): subprocesos cuyo objetivo es identificar y entender
los servicios informticos.
CCM (Component Capacity Management): subprocesos cuyo objetivo es la gestin, el
control y la previsin del rendimiento, el uso y la capacidad de los componentes.
5. Permetro
La gestin de la capacidad debe ser un punto central para el rendimiento de la organizacin
TI, en trminos de rendimiento y capacidad.
La gestin de la capacidad tiene en cuenta el conjunto de componentes de la
infraestructura informtica (hardware y software). Tambin se debe tener en cuenta la
gestin de los recursos humanos, ya que una falta de personal cualificado puede ser origen
de un funcionamiento incorrecto en el suministro de los servicios.
La gestin de los PBA (Pattern Business Activity), proporcionados por el proceso de gestin
de la demanda, se debe tener en cuenta en la gestin de la capacidad.
La gestin de la capacidad, junto con proceso de gestin financiera, va a influir en el
proceso de la gestin de la demanda.
La gestin de la capacidad debe ayudar al diagnstico y resolucin de los incidentes y
problemas asociados a un componente o servicio.
La gestin de la capacidad tambin se debe hacer cargo de todos los cambios
proporcionados por la gestin de cambios relativos a la infraestructura.
Cuando en la organizacin TI existe un sistema de alertas de novedades tecnolgicas, es
oportuno que est unido a la gestin de la capacidad.
6. Roles
Responsable de la capacidad
7. Indicadores
Conformidad con la capacidad prevista.
Evolucin de la capacidad de almacenamiento.
Evolucin de la potencia de procesamiento de CPU.
Evolucin de la banda ancha...
Interrupcin en el suministro del servicio, como consecuencia de una falta de medios

o recursos.
Reduccin del nmero de incidentes o problemas debidos a un bajo rendimiento.
...

El proceso de gestin de la capacidad
9. Conceptos bsicos
Equilibrio de la gestin de la capacidad

La imagen anterior simboliza la gestin de la capacidad.
Hay que ser capaz de encontrar el correcto equilibrio, entre los costes por un lado y la
capacidad por otro, entre la oferta y la demanda.
a. El ciclo de vida de la gestin de la capacidad

El ciclo de vida de la capacidad se puede definir con tres actividades principales, que se
detallan a continuacin.
El punto de entrada de estas actividades est relacionado con el proceso de estrategia de
servicios.
El ciclo de vida de la gestin de la capacidad
b. Los diferentes subprocesos

La gestin de la capacidad est compuesta de tres subprocesos.
Algunas actividades de estos subprocesos son similares, aunque cada subproceso tiene un
objetivo muy diferente.
Gestin de la capacidad de negocio (BCM)

El objetivo principal del subproceso de gestin de la capacidad de negocio es garantizar que
los requerimientos de negocio futuros para los servicios informticos se tienen en cuenta y
estn incluidos, y que se planifica y pone en marcha dentro de plazo una capacidad
informtica suficiente para soportar los servicios nuevos o modificados.
Para esto, es necesario transformar las necesidades y los planes de negocio en
requerimientos para los servicios y la infraestructura informtica.
Los requerimientos de negocio futuros para los servicios informticos se cuantifican,
disean, planifican y ejecutan en plazos.
Gestin de la capacidad de servicio (SCM)

El objetivo principal del subproceso es garantizar que el rendimiento de todos los servicios
se corresponde con los objetivos definidos en los SLA.
Este subproceso tambin tiene como objetivo garantizar que este rendimiento se supervisa
y se mide, y que los datos obtenidos se registran, analizan y reportan.
Por ltimo, este subproceso tiene como objetivo la gestin, el control y la previsin:
Del rendimiento de principio a fin.
Del uso de los servicios informticos operativos.
De la produccin y de las cargas de trabajo.
Gestin de la capacidad de los componentes (CCM)

El objetivo principal de este subproceso es la gestin, el control y la previsin del
rendimiento, del uso y la capacidad de los componentes tecnolgicos de la infraestructura
informtica.
Este subproceso tambin tiene como objetivo garantizar que todos los componentes de la
infraestructura informtica que tienen un recurso limitado sean supervisados y medidos y
que los datos obtenidos se registren, analicen y reporten.
c. Produccin del plan de capacidad

El plan de capacidad se construye a partir de los elementos que provienen de las diferentes
actividades de la gestin de la capacidad.
Produccin del Plan de capacidad

La gestin de la capacidad proporciona un plan de capacidad que engloba:
Los recursos informticos.
La financiacin necesaria.
La justificacin del coste de este gasto.
El plan de capacidad se establece teniendo en cuenta las necesidades expresadas por el

proceso de gestin del porfolio de servicios, as como por los PBA (Pattern Business
Activity).
Cuando se aplica el proceso de gestin de la continuidad, las necesidades particulares de
este proceso se deben tener en cuenta en el proceso de gestin de la capacidad.
El plan de capacidad tambin tiene como objetivo soportar el plan de la empresa.
La produccin y el mantenimiento de la capacidad se debe efectuar en los intervalos
predefinidos.
Es esencialmente un plan de inversiones y, por lo tanto, se debe publicar cada ao y servir
de base para las negociaciones de los presupuestos futuros.
El plan de capacidad se utiliza en todos los dominios de la empresa y de la gestin
informtica. Los proveedores de servicios informticos y la direccin de la organizacin TI
actan sobre este ltimo para planificar la capacidad de la infraestructura informtica.
El plan de capacidad contiene la informacin sobre el uso actual de los servicios y los
componentes.
Tambin contiene los planes para el desarrollo de la capacidad informtica, con el objetivo
de responder a las necesidades del crecimiento de los servicios existentes y de los nuevos
servicios acordados en el marco del SLA.
El plan de capacidad se debe utilizar de manera activa, como base en la toma de

decisiones.
Contenido de un plan de capacidad

A continuacin encontrar un ejemplo de lo que puede contener un plan de capacidad:
Introduccin
Permetro del plan
Mtodo de recogida de informacin
Hiptesis
Escenarios de negocios
Resumen de servicios
Resumen de los recursos
Tasa de utilizacin actual
Previsiones del uso de servicios y recursos
Opciones de mejora de los servicios
Modelo de costes
Recomendaciones
d. Gestin de la demanda
El proceso de gestin de la peticin debe permitir a la gestin de la capacidad influir en las
peticiones de servicios de los clientes y de los usuarios.
Esta actividad permitir gestionar el impacto de estas peticiones sobre los componentes de
la infraestructura informtica.
La modelizacin se realiza a partir de estas peticiones.
e. Modelizacin
El objetivo principal del proceso de la gestin de la capacidad es predecir el
comportamiento de los sistemas informticos, respecto a un volumen y variedad de tareas
dadas.
El objetivo de la modelizacin es beneficiarse de la ejecucin de los subprocesos de la
gestin de la capacidad.
La modelizacin se puede basar en estimaciones que son resultado de la experiencia, en la
informacin actualizada, relativa al uso de los componentes, o en estudios piloto.
Tambin se puede realizar basndose en prototipos o benchmarks.
Algunas opciones pueden ser costosas, pero se recomiendan, especialmente en el caso de
que se pongan en marcha nuevos servicios.
Base de referencia
En primer lugar, para realizar una modelizacin, es necesario crear un modelo de referencia
que refleje exactamente el rendimiento en curso.
Solo despus se puede realizar la modelizacin. Para esto vamos a hacernos, por ejemplo,
la siguiente pregunta: qu pasara si?.
Esta pregunta puede estar relacionada con los fallos, los cambios planificados efectuados,
los volmenes y la variedad de las cargas de trabajo.
Anlisis de las tendencias

Es posible efectuar un anlisis de las tendencias sobre el uso de los componentes a partir
de la informacin del rendimiento de los servicios que se ha recogido en el proceso de
gestin de la capacidad.
El anlisis de la tendencia solo proporciona las estimaciones sobre el uso futuro de los
recursos.
Este anlisis puede ayudar en la toma de decisiones y en la definicin del plan de
capacidad.
Modelos analticos
Existen modelos analticos que son representaciones del comportamiento de los sistemas
informticos.
Estos modelos utilizan tcnicas matemticas; por ejemplo, teora de la cola de espera de
red de clase mltiple.
El modelo se construye normalmente a travs de un paquete de software, especificando en
el paquete los componentes y la estructura de la configuracin que se necesita modelizar.
Tambin conviene precisar el uso del componente, por ejemplo: CPU, memoria, disco o red,
para numerosas tareas o aplicaciones.
Dimensionamiento de la aplicacin
El objetivo principal del dimensionamiento de la aplicacin es estimar los requerimientos de
recursos, para soportar un cambio propuesto en un servicio existente o la puesta en
marcha de un servicio nuevo.
El objetivo tambin es asegurar que el dimensionamiento obtenido va a garantizar que se
satisfacen los niveles de servicio requeridos.
La modelizacin se puede utilizar en el proceso de dimensionamiento de la aplicacin.
f. Las actividades iterativas de la gestin de la capacidad

Estas actividades, como para todo proceso, se basan en el funcionamiento de la Rueda de
Deming.
Las actividades iterativas de la gestin de las capacidades

A partir de los datos obtenidos por un determinado nmero de controles y entradas de
informacin (accin de Check), se podr realizar una accin de anlisis (accin de
Act).
A partir de este anlisis, ser posible definir las acciones que se deben poner en marcha
(accin de Plan).
En ese momento, solo faltar implementar las acciones definidas (accin de Do).
g. El contenido de las bases de datos de la capacidad
El contenido de la base de datos de la capacidad

La base de datos de la capacidad contiene informacin muy variada:
Datos tcnicos.
Financieros.
De uso.
de negocio.
De servicios.
A partir de estos datos, el responsable de la capacidad estar en disposicin de

proporcionar los informes de gestin y, sobre todo, el plan de capacidad.
1. Enfoque
En esta seccin vamos a ver cmo se asegura la disponibilidad de los servicios por parte de
la organizacin TI.
Veremos que la disponibilidad de los servicios y su calidad dependen mucho de la eficacia
de este proceso.
2. Por qu una gestin de la disponibilidad?

Hoy en da, las empresas son cada vez ms dependientes de las tecnologas de la
informacin.
La disponibilidad y fiabilidad de los servicios informticos dependen de la fiabilidad de los
componentes, de la infraestructura puesta en marcha para responder a las expectativas del
cliente, como las que se formulan en el SLA.
La no disponibilidad de un servicio o de un componente puede tener un impacto financiero

ms o menos importante para la empresa y el cliente.
Por esta razn hoy en da la gestin de la disponibilidad resulta esencial para garantizar que
la organizacin TI libere los niveles de disponibilidad de servicios, tal y como fueron
definidos en los SLA.
La satisfaccin del cliente y los usuarios depende directamente de la disponibilidad del

servicio. En este sentido, la gestin de la disponibilidad tiene un papel primordial en la
puesta en marcha y seguimiento de los servicios.

Los objetivos principales del proceso de gestin de la disponibilidad son los siguientes:
Producir y mantener un plan de disponibilidad, adecuado y actualizado, que refleje

las necesidades actuales y futuras de la organizacin TI y de sus clientes.
Garantizar que la disponibilidad de los servicios cumple o excede los objetivos de

disponibilidad acordados en los SLA, gestionando los servicios y recursos
relacionados con el rendimiento de la disponibilidad.
Proporcionar consejos y servir de gua en todos los problemas relacionados con la

disponibilidad para el resto de los sectores de la organizacin TI y de la empresa.
Evaluar el impacto de todos los cambios solicitados, en trminos de plan de

capacidad, recursos y rendimiento.
Asegurar que las medidas proactivas se implementan cuando es necesario y tienen

justificacin financiera.
4. Definiciones
Disponibilidad: aptitud de un servicio TI o un componente para cumplir la funcin
esperada en un momento dado o durante un periodo de tiempo definido.
Fiabilidad: capacidad de un servicio TI para funcionar sin fallos operativos.
Facilidad de mantenimiento: facilidad de un servicio para ser mantenido o restaurado a
un estado operativo.
Facilidad de servicio: respeto de los acuerdos contractuales alcanzados con terceros para
asegurar la disponibilidad de los servicios de las organizaciones TI. Tambin se conocen
como capacidad de soporte exterior.
Resistencia: capacidad de un servicio TI para continuar funcionando correctamente a
pesar de un fallo de uno o varios de sus subsistemas.
Seguridad: puesta en marcha de controles justificables con el objetivo de asegurar un
servicio informtico continuo (sistemas y datos que residen en l), respetando los
parmetros de confidencialidad, integridad y disponibilidad (ver seccin Seguridad Concepto CIA).
Funcin vital de negocio (VBF): elementos de negocio crticos de un proceso de negocio
o de un servicio TI.
Plan de disponibilidad: plan a largo plazo de mejoras proactivas de la disponibilidad de

las organizaciones TI, en funcin de las restricciones presupuestarias.
5. Permetro
La gestin de la capacidad tiene a su cargo el conjunto de la infraestructura informtica.
La gestin de la capacidad tambin se debe hacer cargo de todos los cambios
proporcionados por la gestin de los cambios y que conciernen a la infraestructura.
La gestin de la disponibilidad se centra en dos tipos de actividades: las actividades
reactivas y las actividades proactivas.
Estas actividades se desarrollan ms extensamente en la seccin sobre conceptos bsicos.
6. Roles
Responsable de la disponibilidad
7. Indicadores
Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se
pueden aplicar al conjunto de la produccin informtica o a nivel de cada servicio:
Conformidad de la disponibilidad prevista.
Tiempos de no disponibilidad.
Nmero de no disponibilidades.
MTTR (Mean Time To Repair), MTBSI (Mean Time Before Service Incidents), MTBF
(Mean Time Before Failure)...

El proceso de gestin de la disponibilidad
9. Conceptos bsicos
El proceso de gestin de la disponibilidad incluye dos elementos clave:
a. Las actividades reactivas

Se debe supervisar, medir y analizar todos los eventos, incidencias y problemas que
implican la no disponibilidad de un servicio.
Estas actividades estn implicadas fundamentalmente en los roles operativos. Entre las
actividades reactivas de la gestin de la disponibilidad, podemos identificar la medida, el
anlisis y la gestin de todos los eventos encontrados durante el periodo de suministro del
servicio (evento, incidente o problema), generando una disminucin de la disponibilidad o
la no disponibilidad parcial o total.
Como sucede con cualquier proceso, la gestin de la disponibilidad debe proporcionar
informes de la disponibilidad de los servicios y componentes.
b. Las actividades proactivas

Para ser eficaz, la gestin de la disponibilidad debe tener actividades proactivas.
Estas actividades se centran en una planificacin proactiva, una implicacin en el diseo y
la mejora de la disponibilidad.
Estas actividades estn implicadas fundamentalmente en los roles de diseo y planificacin.
Las actividades proactivas de la gestin de la disponibilidad son:
Identificar las funciones vitales de negocio (VBF - Vital Business Functions).
Diseo con vistas a la disponibilidad.
Anlisis del impacto del fallo de un componente.
Anlisis del punto de fallo nico.
Anlisis por rbol de fallos.
Modelizacin.
Anlisis y gestin de los riesgos.
Calendario de pruebas de la disponibilidad.
Mantenimiento preventivo y planificado.
Produccin de documentos de la
(PSA - Projected Service Availability).
Revisin y mejora continua.
disponibilidad
proyectada
del
servicio
c. Seguridad - Concepto CIA

La seguridad es un punto importante en el proceso de gestin de la disponibilidad.
La disponibilidad tambin refleja cmo los usuarios acceden a los sistemas de informacin y
a la informacin que contienen.
La gestin de la disponibilidad tiene la responsabilidad de asegurar que los requerimientos
de seguridad se definan de forma conjunta con los usuarios y se incorporen al diseo de la
disponibilidad, especialmente para:
El acceso lgico y fsico a los datos, componentes o servicios de las TI disponibles

nicamente para las personas autorizadas.
El retorno al servicio de los componentes y servicios, sin comprometer las directivas

de seguridad de las TI.
En este objetivo, la gestin de la disponibilidad pone en marcha el concepto de CIA.

Este concepto tiene que ver con la seguridad de datos.
Confidencialidad, Integridad, Disponibilidad = Confidentiality, Integrity, Availability
La sigla CIA significa:
Confidentiality: solo las personas autorizadas pueden acceder a los datos.
Integrity: los datos deben estar ntegros en el momento en que se entregan.
Availability: los datos deben estar disponibles en el momento en que se necesitan.
La gestin de la seguridad es responsable de definir las polticas de seguridad de la

empresa y asegurar la conformidad con las directivas de seguridad en el seno de la
organizacin TI. Sin embargo, el proceso de gestin de la disponibilidad debe poner en
prctica las polticas de seguridad definidas por la gestin de la seguridad.
d. Los diferentes tipos de disponibilidad

Alta disponibilidad: caracterstica de un servicio TI que minimiza u oculta a ojos del
usuario los efectos de los errores de un componente TI.
Operacin continua: caracterstica de un servicio TI que minimiza u oculta a ojos del
usuario los efectos de un periodo de no disponibilidad planificado.
Disponibilidad continua: caracterstica de un servicio TI que minimiza u oculta a ojos del
usuario los efectos de todos los errores y todos los periodos de no disponibilidad
planificados.
Vista global de los diferentes niveles de disponibilidad
e. Clculo de los tiempos de no disponibilidad

Los tiempos de disponibilidad y no disponibilidad se calculan con la ayuda de tres
indicadores,MTTR, MTBSI y MTBF.
El esquema siguiente muestra cmo se definen estos diferentes indicadores.
Modo de clculo de los indicadores

El MTTR, duracin media de reparacin o tiempo de no disponibilidad, tambin llamado
Down Time o tiempo de no disponibilidad, es el tiempo transcurrido entre el momento en
que se produce una incidencia y el momento en que el servicio se restaura. Incluye el
tiempo de deteccin, diagnstico (o tiempo de respuesta), reparacin, restauracin y
recuperacin.
El MTBF es la duracin media durante la cual el servicio est disponible. Tambin se llama
Up Time o tiempo disponible.
El MTBSI es el tiempo medio entre dos incidencias.
Es importante que el indicador MTBF sea lo ms elevado posible. Tambin es importante

que el indicador MTBSI sea, del mismo modo, lo ms elevado posible. En caso contrario,
esto provocar la aparicin de mltiples periodos de no disponibilidad, lo que perjudicar la
calidad percibida por el cliente, aunque el indicador MTBF est en los lmites definidos en el
SLA.
f. El Plan de disponibilidad
Es imprescindible elaborar un plan de disponibilidad, ya que servir para estructurar el
conjunto de acciones que permitan mejorar el proceso de gestin de la disponibilidad.
Este plan debe contener:
Los fines.
Los objetivos.
Los elementos de gestin (personal, herramientas tcnicas...).
Para elaborar el plan de disponibilidad, es deseable

propietarios/responsables de los siguientes procesos:
La gestin de los niveles de servicios.
La gestin de la continuidad de los servicios.
La gestin de la capacidad.
La gestin financiera.
poner
en
contacto
los
El plan de disponibilidad debe cubrir un periodo de 1 a 2 aos y se deber hacer una

revisin regular 3 o 4 veces por ao.
El plan de capacidad y el plan de disponibilidad son complementarios.
g. El coste de la no disponibilidad
La aplicacin del proceso de gestin de la disponibilidad tiene un coste.
Algunas veces es necesario justificar este coste.
Una buena manera de justificar esta inversin es presentar los costes de no disponibilidad.
La tabla siguiente aporta una buena metodologa de presentacin de los costes de no
disponibilidad y sus consecuencias en la relacin con el cliente.
Coste de la no disponibilidad

a. Beneficios
El inters de la puesta en marcha del proceso de gestin de la disponibilidad reside en que
permite identificar un responsable nico de la disponibilidad del conjunto de servicios
operativos.
Esto tambin permite tener una persona responsable capaz de responder a las necesidades
expresadas por las diferentes reas de negocio.
La principal dificultad que puede surgir se relaciona con el volumen y la complejidad de los
elementos que hay que manejar.
La dificultad ms frecuente es determinar las necesidades del negocio o del cliente.
Es necesario garantizar una disponibilidad que sea eficiente, es decir, de un nivel
ligeramente superior al nivel normal demandado por el negocio.
Pero no es necesario que este nivel sea demasiado elevado, ya que se puede incurrir en un
coste adicional.
Gestin de la continuidad de los servicios

1. Enfoque
En esta seccin vamos a ver cmo la organizacin TI se asegura de la continuidad de
servicios informticos.
En el vocabulario que se usa en la continuidad de los servicios, se utiliza de manera
habitual el trmino ITSCM (IT Services Continuity Management).
Veremos que la supervivencia de la empresa, en caso de un fallo grave, depende de la
eficacia de este proceso.
2. Por qu una gestin de la continuidad?

Las empresas cada vez dependen ms de sus equipos informticos. Un fallo grave puede
tener consecuencias desastrosas para la empresa.
En un nmero importante de casos, un fallo informtico grave conduce a la desaparicin de
la empresa.
Sin embargo, an hoy en da, un gran nmero de empresas nunca ha puesto en prctica un
plan de continuidad de servicios.
La crisis econmica ha obligado a muchas empresas a reducir sus presupuestos
informticos, incluidos los destinados a copias de seguridad y a la no interrupcin de las
actividades. Sin embargo, deben encontrar el equilibrio adecuado entre los costes y los
riesgos, evaluando las prdidas potenciales en caso de desastre y, sobre todo, el tiempo
que se necesitara para devolverlo todo a un estado normal de funcionamiento.
La gestin de la continuidad de los servicios es un elemento esencial de la nocin de

garanta en la definicin del valor del servicio.
Cuanto ms complejas son las aplicaciones, ms graves son las consecuencias en caso de
avera.

Los objetivos principales del proceso de gestin de la continuidad de servicios informticos
son los siguientes:
Sostener el proceso global de gestin de la continuidad de la empresa, asegurando el

suministro de los servicios agregados en el marco del BCM (Business Continuity
Management) y los niveles definidos.
Producir y mantener un conjunto de planes de continuidad.
Asegurar la capacidad para poner en prctica los planes de continuidad, respetando

los niveles de servicio, principalmente en trminos de disponibilidad de seguridad.
Asegurar de manera regular que los planes de continuidad responden a las

evoluciones de los BIA (impactos y requerimientos).
Proporcionar consejos a todas las reas del negocio y a la organizacin TI sobre la

puesta en marcha del proceso de la continuidad.
Asegurar que se tienen en cuenta todos los cambios en el plan de continuidad.
Asegurar que se toman medidas proactivas para mejorar la disponibilidad de los

servicios, dentro de los lmites de un coste justificable.
4. Definiciones
BCP (Business Continuity Plan): plan de continuidad del negocio.
BCM (Business Continuity Management): proceso que se ocupa del anlisis y gestin del
riesgo, con el objetivo de que la organizacin pueda asegurar, en todo momento, la
capacidad de produccin o el suministro de los servicios mnimamente requeridos.
BIA (Business Impact Analysis): mtodo de anlisis del impacto en el negocio que permite
evaluar las prdidas potenciales durante un siniestro.
DRP (Disaster Recovery Plan): plan de restablecimiento o recuperacin informtica.
5. Permetro
La gestin de la continuidad tiene a su cargo toda la infraestructura informtica o parte de
ella.
El proceso de continuidad de los servicios (ITSCM) se encarga de:
Lo que est en el permetro del proceso y las reglas que tiene asociadas.
Los BIA (existentes y actualizados), para identificar el impacto en caso de

funcionamiento incorrecto.
La identificacin y la gestin de los riesgos.
Una estrategia de continuidad que se integrar en el proceso BCM.
Uno o varios planes de continuidad.
Los planes de prueba para asegurar la capacidad para poner en prctica los planes
de continuidad.
6. Roles
Responsable de la continuidad de servicios.
7. Indicadores
ndice de formacin de los equipos.
Tiempo de puesta en marcha del plan.
Tiempo de recuperacin.
Tiempo de retorno a un servicio normal.
Tiempo para adoptar los nuevos servicios...

8. Aspectos identificables en un BIA (Business Impact

Analysis)
La introduccin de un BIA debe permitir la identificacin y posterior prevencin de un cierto
nmero de riesgos, como por ejemplo:
Prdida de la capacidad operativa.
Prdida de ventajas competitivas.
Prdida de beneficio.
Gastos adicionales.
Reputacin daada.
No respetar las obligaciones legales.
Riesgo para la seguridad del personal.
Prdida inmediata a largo plazo de partes de mercado.
El proceso de gestin de la continuidad
10. Conceptos bsicos

a. Ciclo de vida de la gestin de la continuidad de servicios
Ciclo de vida de la gestin de la continuidad
Fase 1 - Iniciacin
Durante esta fase, la primera etapa es determinar cules son las polticas puestas en
marcha.
La segunda etapa consiste en determinar cul ser el permetro que se tendr en cuenta en
el plan de continuidad de servicios.
La ltima etapa consiste en poner en prctica el proyecto.
Fase 2 - Requerimientos y estrategias

La primera etapa consiste en hacer un anlisis de impactos en el negocio, rea por rea y
servicio por servicio.
La segunda etapa consiste en una evaluacin de los riesgos. Para ello es posible utilizar el
mtodo CRAMM (ver la seccin El mtodo CRAMM).
La ltima etapa consiste en definir la estrategia de continuidad de servicios informticos.
Fase 3 - Puesta en marcha

La primera etapa de esta fase es desarrollar los planes de continuidad de servicios
informticos.
La segunda etapa es desarrollar los planes informticos, los planes de recuperacin y los
procedimientos relacionados con estos planes.
La tercera etapa consiste en la planificacin de la organizacin.
Para terminar esta fase, la ltima etapa consiste en la puesta en prctica de la estrategia
de pruebas.
Fase 4 - Gestin operativa

Para esta ltima fase, en la primera etapa, es necesario formar, educar y sensibilizar a los
empleados.
Durante la segunda etapa, tambin es necesario poner en prctica las auditoras y revisar
de manera regular los planes elaborados.
La tercera fase consiste en poner en marcha la estrategia de pruebas. Las pruebas se
deben realizar en funcin de la planificacin elaborada en el plan de pruebas.
La ltima etapa consiste en tener en cuenta la gestin de los cambios.
Resumen de las actividades de puesta en marcha
b. El mtodo CRAMM
El mtodo CRAMM fue creado en 1987 por la agencia central de informtica y
telecomunicaciones del gobierno del Reino Unido, el CCTA, de donde viene su nombre de
CRAMM (CCTA Risk Analysis and Management Method).
CRAMM es un mtodo de anlisis de riesgos conforme a las normas BS 7799 e ISO 17799.
El mtodo CRAMM est estructurado en las tres fases siguientes:
1 - Definicin de los valores de riesgo.
2 - Anlisis de los riesgos y de vulnerabilidad.
3 - Definicin y eleccin de las medidas de seguridad.
Definicin de los valores

Esta primera fase consiste inicialmente en determinar el permetro de estudio y organizar
las actividades. Seguidamente se procede a la definicin de los valores (los activos de la
organizacin TI) y su importancia relativa.
Anlisis de los riesgos y de la vulnerabilidad

Durante esta fase, se agrupan los valores en funcin de las necesidades relativas a
disponibilidad, integridad y confidencialidad de los datos (ver Gestin de la disponibilidad Conceptos bsicos).
Seguidamente se establecer la gravedad de los riesgos y la vulnerabilidad de las defensas.
Para terminar, se precisar el nivel de importancia de los principales riesgos.
Definicin y eleccin de las medidas de seguridad

Durante esta fase ser necesario definir las necesidades en trminos de medios de
seguridad y compararlas con la seguridad existente.
Seguidamente se debe disear el plan de medidas de correcciones que se deben aplicar
para reducir los riesgos a un nivel aceptable.
Gestin de los riesgos
11. Las soluciones de continuidad de servicios

Es til recordar que, cualquiera que sea la solucin aplicada, el plan de continuidad de
servicios solo prev asegurar la continuidad de las actividades vitales de la empresa.
Por ejemplo, el servicio de pagos no se tendr en cuenta en el plan de continuidad, ya que
es posible que la empresa solicite a su banco que efecte unas transferencias de salario
equivalentes a las del mes anterior.
En cambio, los servicios relacionados con la produccin formarn parte del plan de
continuidad de servicios.
a. No hacer nada
Paradjicamente, esta es la solucin adoptada por la gran mayora de las empresas.
Las razones de esta eleccin son, esencialmente, el coste estimado de la puesta en marcha
de un plan de continuidad de servicios y la dificultad de esa puesta en marcha.
Esto tambin significa que la empresa no ha realizado un estudio de los costes efectivos de
un siniestro, y que estos costes no se han cotejado con los costes de puesta en marcha de
un plan de continuidad de servicios.
b. Solucin temporal manual

Esta solucin se utiliza en empresas pequeas.
Normalmente consiste en almacenar las copias de seguridad en una ubicacin ms o menos
segura.
Si no hay disponible ningn equipamiento informtico, se prev volver al trabajo
directamente en papel.
No hay plan de continuidad de servicios.
Esto tambin significa que, como en la solucin anterior, la empresa no ha estudiado
realmente los costes efectivos de un siniestro y que estos costes no se han cotejado con los
costes de puesta en marcha de un plan de continuidad de servicios.
c. Acuerdos recprocos
Esta solucin se usa por los PME y consiste en acuerdos, formalizados o no, entre dos
empresas prximas la una a la otra.
Estas empresas tienen tamaos relativamente similares y utilizan, en parte, software
similar.
Esta solucin se puede poner en prctica de manera sencilla, pero no responde realmente a
una necesidad de continuidad de servicios.
De hecho, solo tiene valor en el contexto de un siniestro puramente informtico.
Si hablamos de siniestro de tipo natural (geogrfico o climtico), esta solucin no tiene
ningn valor, ya que no se podr aplicar.
Por ejemplo, en las inundaciones sufridas en la ciudad de Nueva Orleans, provocadas en el
ao 2005 por el huracn Katrina, toda la zona de actividad estaba inundada, lo que haca
imposible la puesta en marcha de esta solucin.
La situacin ser la misma en caso de siniestro elctrico, salvo que el acuerdo se realizara
con una empresa fsicamente distante.
d. Soluciones comerciales de continuidad

Existen varias soluciones comerciales que permiten la puesta en marcha de un plan de
continuidad de servicios.
Algunas empresas, debido a su tamao, pueden poner en marcha un plan de continuidad

de servicios de manera interna, ya que disponen de varios centros informticos en regiones
diferentes.
En los dos casos, se pueden poner en prctica los siguientes modelos.
Soluciones de hardware
Existen varias ofertas de soluciones de hardware:
Alquiler de camin con un equipamiento bsico, que se pone a disposicin bajo

demanda.
Alquiler de salas blancas compartidas: en este tipo de contrato, varias empresas

comparten una sala blanca. Actualmente, lo normal es que haya cuatro o cinco
empresas por contrato. En este tipo de contrato, es la primera empresa que la
solicita la que se podr beneficiar de esta sala. Normalmente, la empresa continuar
utilizando esta sala durante un mximo de 21 das. Si otra empresa necesita la sala,
deber esperar el fin del periodo de 21 das para poder disponer de ella.
Estadsticamente, la posibilidad de ver dos empresas solicitando la sala al mismo
tiempo es muy baja, casi improbable. Por lo tanto, esta solucin es aceptable.
Alquiler de sala blanca asignada: en este caso, la empresa alquila una sala
blanca a una empresa especializada. Esta empresa dispone de esta sala
permanentemente y, de esta manera, puede equiparla de forma anticipada, para
reducir el plazo de puesta en marcha con posterioridad a un siniestro. Esta solucin
es muy costosa, lo que explica las reticencias de muchas empresas.
Ubicacin de seguridad propiedad de la empresa: en este caso la empresa

decide equipar una sala en una ubicacin distante para hacer de ella una ubicacin
de respaldo. De nuevo, la empresa podr equipar con antelacin la ubicacin de
respaldo.
Ubicacin espejo: en este caso, la empresa va a poner en marcha una solucin de

redundancia/mirroring entre dos ubicaciones. Si una de las ubicaciones cae, la otra
puede responder a las operaciones sin demora. Hoy en da, solo los grandes grupos
son capaces de poner en prctica una solucin como esta.
e. Los diferentes tipos de recuperacin

Recuperacin gradual
Tambin llamada recuperacin progresiva o Cold stand-by, esta solucin prev una
recuperacin en un plazo de ms de 72 horas.
Esta solucin suele estar vinculada con un tipo de plataforma de seguridad: alquiler de
camin equipado o alquiler de sala blanca compartida.
Recuperacin intermedia
Llamada recuperacin intermedia o Warm stand-by, esta solucin prev una recuperacin
en un plazo comprendido entre 24 y 72 horas.
Con esta solucin, la empresa se va a organizar para poner en marcha su ubicacin de
respaldo lo ms rpidamente posible. Es necesario tener en cuenta que, aunque la sala
blanca est equipada con anterioridad, esta no podr estar operativa de manera inmediata.
Esto incluye la actualizacin del sistema de informacin con los datos de la ltima versin
de la copia de seguridad, lo que requiere tiempo.
Recuperacin inmediata
Llamada tambin Hot stand-by, esta solucin prev una recuperacin en un plazo de
menos de 24 horas.
Con esta solucin la empresa se va a organizar para poner en marcha su ubicacin de
respaldo lo ms rpidamente posible, en menos de 24 horas. Esto implica que se debe
realizar una actualizacin diaria de los datos de la ubicacin de respaldo.
f. Plan de recuperacin genrico

A continuacin proporcionamos un ejemplo de lo que podra contener un plan de
recuperacin:
Introduccin
Entrada en produccin
Roles y responsabilidades
Estrategia de recuperacin
Activacin
Personal de recuperacin
Dependencias
Lista de verificacin del equipo de recuperacin
Condiciones de vuelta a la normalidad
12. Precauciones que hay que tener

La puesta en marcha de un plan de continuidad de servicios informticos implica tomar
algunas precauciones.
La primera es saber que se debe tratar de un proyecto completo.
Para ser operativo, el plan de recuperacin se debe poner en prctica por parte de un
equipo claramente identificado.
Este equipo debe seguir obligatoriamente una formacin para que cada uno de los
empleados sepa con exactitud qu debe hacer y cundo debe hacerlo.
Se deben realizar pruebas obligatoriamente.
En funcin de la empresa, estas pruebas se deben llevar a cabo como mnimo todos los
meses.
Las pruebas se deben realizar en condiciones lo ms cercanas posible a la realidad.
Algunas empresas no dudan en hacer las pruebas a gran escala: se interrumpe el sistema
operativo para bascular hacia la ubicacin de respaldo. Es cierto que, en este caso, la
empresa asume un riesgo, pero no es este riesgo inferior al hecho de descubrir un
funcionamiento incorrecto ms importante el da que se produzca un verdadero siniestro?
De manera obligatoria, se debe realizar un balance al final de cada prueba.

Las modificaciones identificadas deben dar lugar a peticiones de cambio.

a. Beneficios
Los beneficios de la gestin de la continuidad son numerosos, pero, si hay uno que vale la
pena destacar sobre los dems, es que la supervivencia de la empresa, en caso de siniestro
grave, a menudo depende de la puesta en marcha de este proceso.
La dificultad ms importante para poner en marcha este proceso consiste en obtener un
acuerdo con las partes encargadas de la generacin de la estrategia y la gestin financiera.
1. Enfoque
En esta seccin vamos a ver cmo se asegura la seguridad informtica a nivel de la
organizacin TI.
La eficacia de este proceso es importante para garantizar la calidad de la informacin
proporcionada por la organizacin TI, y tambin el nivel de calidad del suministro de
servicios.
Se deben abordar los diferentes riesgos relacionados con el uso, acceso o almacenamiento
de los datos, definiendo y poniendo en prctica polticas para ello.
2. Por qu una gestin de la seguridad?

Hoy en da, la gestin de seguridad es una necesidad y una obligacin para todas las
empresas.
Se debe definir y poner en prctica una poltica de seguridad.
Su puesta en marcha debe garantizar que satisfaga las necesidades del negocio, as como
las de la organizacin TI.
La gestin de la seguridad debe sensibilizar sobre el cumplimiento de las normas de
seguridad, tanto a las personas de la organizacin TI como a los usuarios de los servicios
proporcionados por la organizacin TI.
La gestin de la seguridad se debe asegurar de que los proveedores del servicio
comprenden y aplican las polticas de seguridad.
La gestin de la seguridad debe gestionar todos los aspectos relativos a las tecnologas de
la informacin, la seguridad informtica, la seguridad de los accesos y la gestin de
documentos.
La gestin de la seguridad es una parte importante para la nocin de garanta de un
servicio y esto est relacionado con la definicin de la calidad del servicio.
La gestin de la seguridad se debe considerar como una parte de la gestin de la empresa.
La seguridad, como la calidad, debe ser un estado de nimo que hay que mostrar todos los
das.

Los principales objetivos del proceso de gestin de la seguridad son los siguientes:
Proteger la informacin frente a fallos, respetando la confidencialidad, integridad y

disponibilidad (regla CIA).
Satisfacer los requerimientos de seguridad acordados en los SLA, OLA y UC.
Satisfacer los requerimientos legales.
Garantizar un nivel de seguridad (referencia de seguridad, autenticidad y no

rechazo).
Las polticas de seguridad se definen en el proceso de gestin de la seguridad.

La puesta en marcha de estas polticas se lleva a cabo en el proceso de gestin de la
disponibilidad y en el centro de servicios.
4. Definicin
No hay una definicin especial para este proceso, aparte de la definicin de la regla CIA
que se describi en la seccin Seguridad - Concepto CIA.
5. Permetro
La gestin de la seguridad tiene a su cargo el conjunto de la organizacin TI y de la
infraestructura informtica.
La seguridad informtica se refiere al conjunto del permetro de la infraestructura
informtica.
La seguridad tambin implica el respecto de la legalidad (reglas y polticas).
La seguridad tambin debe tener en cuenta las obligaciones definidas por el cliente en los
SLA.
La seguridad se refiere no slo a los sistemas y datos, sino tambin a los accesos y a las
personas.
Se debe tener en cuenta el conjunto lgico y fsico de la organizacin TI.
6. Roles
Responsable de la seguridad.
7. Indicadores
Nmero de incidencias de seguridad.
Tiempo de no disponibilidad debido a una incidencia de seguridad.
Nmero de no disponibilidades debido a incidencias de seguridad...

El proceso de gestin de la seguridad
9. Conceptos bsicos
a. Confidencialidad, Integridad y Disponibilidad (CIA)
Este concepto hace referencia a la seguridad de los datos.
Confidencialidad, Integridad y Disponibilidad = Confidentiality, Integrity, Availability
La sigla CIA significa:
Confidentiality: solo las personas autorizadas pueden acceder a los datos.
Integrity: los datos deben estar ntegros en el momento en que se entregan.
Availability: los datos deben estar disponibles en el momento en que se necesitan.
La gestin de la seguridad es responsable de definir las polticas de seguridad de la

empresa y asegurar su conformidad con las directrices de seguridad, en el seno de las
organizaciones TI.
Definiciones de ejemplo
Confidencialidad
High: datos personales bajo proteccin (Data Protection Act/CNIL), datos mdicos e
informacin estratgica.
Medium: internos, no deben salir de la empresa.
Low: externos, todo lo que est autorizado a salir.
Integridad
High: transacciones financieras, software y datos personales.
Medium: informacin
direccin).
Low: sin requerimientos.
de
medidas
informacin
de
identificacin
(nombre,
Disponibilidad
High: 24 horas al da, 99,5%.
Medium: de 07:00 a 19:00, 99%.
Low: sin requerimiento.
b. Las actividades y responsabilidades

Estratgica
La definicin de las polticas de seguridad se establece a nivel estratgico.
Tctica
Las actividades a nivel tctico son las siguientes:
Establecimiento de los niveles de seguridad en las SLA y suministro de servicios,

respetando los acuerdos.
Implantacin de las medidas de seguridad para controlar

disponibilidad): Confidencialidad/Integridad/Disponibilidad.
(gestin
de
la
Operativa
Las actividades a nivel operativo son las siguientes:
Establecer las relaciones importantes con los otros procesos.
Responder a las incidencias de seguridad de manera adecuada (gestin de las

incidencias y problemas).
Participacin en el anlisis de impacto de los RFC.
Puesta en marcha segura de los cambios (gestin de las entradas en produccin).
Aplicacin de la Rueda de Deming

Las actividades de este proceso concuerdan con el modo tradicional de funcionamiento de
los procesos.
Es una aplicacin del principio de la Rueda de Deming.
Rueda de Deming aplicada a la seguridad
c. Ciclo de vida de una incidencia de seguridad

El tratamiento de una incidencia de seguridad se lleva a cabo a travs del proceso de
gestin de las incidencias.
En funcin de su importancia, esta incidencia puede activar la creacin de un problema.
En funcin de los resultados del anlisis, esto puede dar lugar a una peticin de cambio,
incluso a una peticin de cambio urgente.
Esto tambin puede dar lugar a la creacin de nuevas reglas de seguridad para evitar que
este tipo de incidencias de seguridad se vuelvan a producir.
Ciclo de vida de una incidencia de seguridad

a. Beneficios
La puesta en marcha de la gestin de la seguridad permite proteger la empresa contra las
amenazas y ataques que provengan tanto del interior como del exterior de esta.
El coste de la puesta en marcha de este proceso puede parecer elevado pero, en vista de
los costes que la empresa tendra que soportar en caso de siniestro causado por un fallo de
seguridad, prdida o corrupcin de archivos o accesos no autorizados a informacin vital de
la empresa, este coste es muy razonable.
La puesta en marcha de este proceso se enfrenta a menudo con la dificultad de gestin de
los cdigos de acceso.
Cmo implementar una poltica de seguridad sobre los derechos de acceso y conseguir
que los usuarios respeten esta poltica?
Una complicacin excesiva de los cdigos implica a menudo una reaccin bien conocida por
todos: se anota el cdigo en un Post-it y se deja en el cajn, sobre el teclado o en la
pantalla.
Por lo tanto, es necesario conseguir la adhesin del personal a esta poltica.
La gestin de la seguridad, al menos en las empresas grandes y medianas, se convierte en
un trabajo a tiempo completo que requiere una formacin especial.
Es cierto que, en el caso de las empresas pequeas, el establecimiento de este proceso se
simplifica, ya que el tamao del permetro que hay que proteger es un elemento
importante.
Gestin de los proveedores
1. Enfoque
En esta seccin vamos a ver cmo se asegura la gestin de los proveedores.
Este proceso es importante, ya que permite garantizar la calidad del servicio.
2. Por qu una gestin de los proveedores?

La eleccin de un proveedor no se puede hacer basndose nicamente en el precio.
De hecho, es imprescindible que la calidad del servicio de la organizacin TI no se pueda
poner en peligro como consecuencia de un fallo de un proveedor.
Para evitar esto, es necesario asegurar un seguimiento del proveedor.
Fundamentalmente, esto se hace, pero solo en parte, a travs de los contratos de tipo UC
(Underpinning Contract).

Los principales objetivos del proceso de gestin de los proveedores son los siguientes:
Negociar los contratos y firmarlos.
Asegurar el seguimiento del funcionamiento de los contratos.
Asegurar una buena relacin calidad/precio.
Asegurar que se gestionan los proveedores y los servicios.
Garantizar que los contratos se alinean con las necesidades de la empresa.
Asegurar que los contratos estn alineados con los objetivos de los SLA.
Definir y mantener una poltica para proveedores.
4. Definicin
No hay definicin particular para este proceso.
5. Permetro
La gestin de proveedores tiene que ver con las relaciones entre la organizacin TI y el
proveedor (tambin llamado subcontratista).
6. Roles
Responsable de los proveedores.
7. Indicadores
Nmero de incidencias en el suministro de los servicios.
Tiempo de no disponibilidad debido a una incidencia en el suministro del servicio.
Nmero de no disponibilidades debidas a una incidencia en el suministro del

servicio...
Es necesario aadir a esta lista los indicadores definidos en el contrato de tipo UC, firmado
entre el proveedor y la organizacin TI.
El proceso de gestin de los proveedores
9. Conceptos bsicos
a. Negociaciones antes de la firma del contrato
La puesta en marcha de este proceso permite negociar los contratos y obtener una relacin
calidad/precio ventajosa por parte de los proveedores.
Tambin es necesario estar seguros de que los contratos de subcontratacin y los acuerdos
con los proveedores estn alineados con las necesidades de la empresa y que se apoyan y
siguen los objetivos acordados en los SLA y los SLR, de forma conjunta con el responsable
de los niveles de servicio (Service Level Manager).
El responsable del proceso deber negociar y acordar los contratos con los proveedores.
b. Despus de la firma del contrato

El responsable del proceso deber gestionar las relaciones con los proveedores y asegurar
que el rendimiento de los proveedores se mantiene acorde con sus compromisos.
Debe mantener una poltica de proveedores y respaldar las bases de datos de contratos y
proveedores (SCD - Supplier & Contracts Database).
El responsable del proceso deber asegurar la categorizacin de los proveedores y el
mantenimiento de la base de datos de proveedores y contratos (SCD).
El seguimiento de los contratos incluye una evaluacin anual de los resultados.
Al final del contrato, la decisin de su renovacin o no se deber tomar en funcin de los
resultados globales obtenidos a lo largo de la duracin del contrato.

a. Beneficios
La gestin de los proveedores permite un seguimiento ms eficaz de estos, as como
garantizar que se cumplen los acuerdos de servicio definidos (SLA y OLA).
No hay dificultades potenciales para la puesta en marcha de este proceso.
LOS PROCESOS DE LA TRANSICION DE LOS SERVICIOS

La fase de los procesos de transicin de servicios
1. Por qu una transicin de servicios?
Como hemos visto en el captulo de presentacin de la norma, ITIL est dividido en
Los niveles decisionales de la gestin de servicios

Los procesos de transicin de servicios se sitan al mismo tiempo en la parte tctica y en la
parte operativa.
Este posicionamiento, que puede sorprender, resulta sin embargo lgico, ya que el rol de
los procesos de esta fase es proporcionar un vnculo entre los procesos que elaboran los
servicios y los procesos de explotacin que entregan los servicios.
Uno de los objetivos de la transicin de servicios es asegurar que la puesta en marcha de
un cambio no tiene un impacto negativo en la calidad de los servicios proporcionados por la
organizacin.
La transicin de servicios se basa en dos procesos principales:
La gestin de los activos de servicio y configuraciones.
La gestin de cambios.
Para una mayor eficacia, es deseable que estos dos procesos se pongan en marcha al
mismo tiempo.
2. Los objetivos de la transicin de servicios

El objetivo de la transicin de servicios es asegurar que los servicios nuevos, modificados o
eliminados, corresponden a las expectativas del negocio, tal y como se documentan en las
fases de estrategia y diseo de servicios.
Los objetivos principales son los siguientes:
Planificar y gestionar los cambios de manera eficaz.
Gestionar los riesgos relacionados con el cambio de un servicio (nuevo, modificado o

eliminado).
Asegurar el xito del despliegue de los cambios.
Asegurar que los cambios generan valor para el negocio.
Proporcionar un buen conocimiento de los servicios y de los activos de los servicios.
3. El permetro de la transicin de los servicios

La fase de transicin debe dar consejos a las fases de diseo y mejora continua de los
servicios.
Debe permitir una mejora en cuanto a la capacidad para poner en marcha un servicio
nuevo o modificado o eliminar uno existente.
Esto incluye la planificacin, la construccin, la prueba, la evaluacin y el despliegue del
cambio.
4. Los procesos de transicin de servicios
Gestin de la transicin, planificacin y soporte.
Gestin de los activos de servicio y configuraciones.
Gestin de cambios.
Gestin de las entradas en produccin.
Validacin del servicio y de las pruebas.
Evaluacin.
Gestin del conocimiento.
Gestin de la transicin, planificacin y soporte

1. Enfoque
Este proceso es esencial para el correcto funcionamiento del conjunto de procesos de la
fase de transicin, ya que garantiza la visin global y asegura y coordina los recursos
necesarios para cumplir los compromisos de esta fase.

Los principales objetivos del proceso de gestin de la transicin son los siguientes:
Planificar y coordinar los recursos.
Coordinar las actividades de los diferentes actores.
Poner en marcha servicios nuevos o modificados.
Retirar todos los elementos que forman parte de un servicio eliminado.
Poner en marcha todas las modificaciones que tienen que ver con el entorno
informtico.
Identificar y gestionar los riesgos para limitar los errores en el funcionamiento

durante la fase de transicin.
Controlar y mejorar el rendimiento de las actividades de la fase de transicin.
3. Permetro del proceso

En este proceso, el permetro de las actividades incluye el mantenimiento de las polticas,
las normas y los modelos para el conjunto de actividades y procesos de la fase de
transicin.
La gestin de la transicin tambin tiene que coordinar los esfuerzos necesarios para poner
en marcha varios cambios en un mismo periodo.
Asimismo hay que priorizar los requerimientos, algunas veces contradictorios.
Por supuesto, se debe aplicar la mejora continua de los procesos de esta fase.
4. Descripcin del proceso y las relaciones principales
El proceso de transicin, planificacin y soporte
5. Conceptos bsicos
El diseo de los servicios, en coordinacin con el cliente y los proveedores de los servicios,
internos y externos, desarrolla el servicio.
Para esto, se basa en el empaquetado de servicios (SDP - Service Design Package).
El empaquetado de servicios es un requisito previo para la fase de transicin.
Se puede leer una descripcin de un paquete de servicios en la descripcin del proceso de
gestin del porfolio de servicios (fase de estrategia).
Atencin: este proceso no es responsable de la planificacin de la construccin, las pruebas

y el despliegue de un cambio. Estas actividades se gestionan en el marco del proceso de
gestin de cambios.
6. Preparacin para la transicin

La transicin necesita la puesta en marcha de varias actividades previas al cambio.
A continuacin se enumeran algunos ejemplos de estas actividades:
Revisar y aceptar los elementos de entrada que provengan de las otras fases del ciclo
de vida.
Revisar y controlar los elementos esperados: la demanda de

empaquetado de servicios y los criterios de aceptacin del servicio.
cambios,
el
Asegurar que se crea una base de referencia para permitir una eventual vuelta atrs.
Gestin de los activos de servicio y configuraciones

1. Enfoque
En esta seccin vamos a ver cmo se gestionan los activos, as como cul es la base de la
gestin de los activos de servicio y configuraciones (SACM): cmo se gestionan las
relaciones entre los elementos de configuracin.
Atencin: normalmente se habla de gestin de configuraciones, que es la definicin del

proceso en la versin 2 de ITIL; esto es as por una sencilla cuestin de simplificacin
terminolgica.
2. Por qu una gestin de los activos de servicio y de las

configuraciones?
La gestin de los activos, a menudo llamada Asset Management, no es suficiente para
describir el conjunto de componentes de un sistema de informacin.
Para asegurar su gestin de manera efectiva, es imprescindible tener la informacin
completa y precisa de la infraestructura entera del sistema de informacin y del conjunto
de sus componentes.
Si los servicios no se entregan en las condiciones definidas en los contratos de servicio, la
organizacin puede sufrir prdidas importantes.
Debido al papel que desempean estos activos en el soporte a la prestacin de calidad del
servicio, el valor real de los activos informticos es normalmente superior a su valor
presupuestario.

Los objetivos principales del proceso de gestin de configuraciones son los siguientes:
Optimizar los activos de servicios.
Garantizar la integridad de los elementos de configuracin y las configuraciones

necesarias para mantener un CMS (Configuration Management System) operativo.
Dar asistencia a la gestin eficaz de los servicios TI:

Proporcionando un modelo lgico de la infraestructura de los TI y de los servicios TI.
Aportando una base slida a la gestin de incidencias, la gestin de problemas, la
gestin de cambios y las entradas en produccin.
4. Definiciones
Activo: es un componente de un proceso de negocio:
Proceso
Organizacin
Personal
Informacin
Software
Infraestructura
Capital financiero
Elemento de Configuracin (CI - Configuration Item): es un activo, componente de

servicio u otro elemento que est, o estar, bajo el control del proceso de gestin de
activos y configuraciones.
Los elementos de configuracin varan en complejidad, tamao y tipo, y van desde un
servicio o sistema entero, incluidos el hardware, software, documentacin y personal de
soporte, hasta un simple mdulo de software o un componente de hardware sin
importancia.
DML (Definitive Media Library): los diferentes CD de las versiones definitivas y autorizadas
de todos los CI de software se registran en la biblioteca. En realidad esta zona de
almacenamiento puede estar formada por una o varias bibliotecas lgicas o fsicas. En la
versin 2 de ITIL se habla de DSL (Definitive Storage Library).
DHS (Definitive Hardware Storage): lugares de almacenamiento de los equipos principales.
CMS (Configuration Management System): sistema de gestin de configuraciones. El
sistema de gestin de configuraciones contiene toda la informacin para todos los CI
incluidos en el permetro definido.
La CMS tiene en cuenta los datos de varias bases de gestin de configuraciones (CMDB),
que en conjunto forman una federacin CMS.
En la versin 2 de ITIL se habla de CMDB (Configuration Management Data Base), y
actualmente, por analoga, muchas personas continan hablando de CMDB en lugar de
CMS.
Baseline: configuracin de referencia.
5. Permetro
La gestin de activos de servicio y configuraciones tiene a su cargo:
La gestin de los activos a los que se hace referencia en la gestin de los activos de
servicios y configuraciones.
La gestin de las relaciones entre los elementos.
La gestin de la documentacin asociada a estos elementos.
6. Roles
Responsable de los activos de servicio y configuraciones.
Responsable de los activos.
7. Indicadores
Nmero de CI creados.
Nmero de CI modificados.
Nmero de CI archivados.
Nmero de errores en la identificacin de los CI...

8. Descripcin del proceso y las principales relaciones
El proceso de gestin de activos de servicio y configuraciones
9. Conceptos bsicos
a. El ciclo de vida de un CI
El ciclo de vida de un CI est definido por cinco actividades que se detallan a continuacin:
El ciclo de vida de un CI
b. Las actividades de la gestin de configuraciones

Las principales actividades de la gestin de los activos de servicio y configuraciones son las
siguientes:
Planificacin
La primera etapa del proceso consiste en la redaccin de las especificaciones del proyecto y
la planificacin de su puesta en marcha. Las estimaciones deben incluir la definicin del
permetro, los objetivos, las reglas y los procedimientos, el contexto tcnico y organizativo
del proceso de la gestin de activos de servicio y configuraciones.
Identificacin
Durante la segunda etapa, hay que seleccionar e identificar todos los CI de la
infraestructura. Esta identificacin debe incluir los elementos siguientes: su propietario,
relaciones y documentacin asociada. Para cada CI, hay que definir un identificador nico y,
para alguno de ellos, un nmero de versin. Esta etapa termina etiquetando cada elemento
y guardndolo en la CMS.
Control
La actividad de control consiste en asegurar que solo se aceptan y registran los CI
autorizados e identificados, desde su recepcin hasta su destruccin. Esta actividad permite
asegurar que ningn CI se aade, modifica, sustituye o elimina sin que haya una peticin
de cambios aprobada (ver seccin sobre gestin de cambios).
Gestin del estado

A lo largo de todo su ciclo de vida, un CI es objeto de un seguimiento en lo que respecta a
todos los datos actuales y pasados que tienen que ver con l. Este seguimiento permite
conocer la evolucin del estado del CI, fundamentalmente a travs de los cambios
aprobados y las entradas en produccin.
Verificacin y auditora
Adems de las acciones de seguimiento, es imprescindible efectuar una serie de revisiones
y auditoras que permitan verificar la existencia real de los CI y asegurar que se registran
correctamente en el sistema de gestin de activos de servicio y configuraciones.
c. Qu contiene la CMS?
La CMS debe contener todos los elementos de la infraestructura identificados.
Es necesario definir los atributos y relaciones de cada CI.
Contenido de la CMS
Granularidad de la CMS
El punto ms importante de la puesta en marcha de una CMS es la definicin de la
granularidad de la base de datos.
Es necesario tener cuidado en el momento de definir esta granularidad (ver la siguiente
seccin: Beneficios y dificultades - Dificultades potenciales):
Si es demasiado larga, faltar informacin importante.
Si es demasiado fina, la gestin de la base ser especialmente difcil.
Ejemplo:
Si es demasiado larga: si la base de datos solo contiene los servidores, falta informacin
relativa a los puestos de trabajo conectados a estos servidores.
Si es demasiado fina: para qu sirve registrar y, sobre todo, gestionar el ratn del
puesto de trabajo, cuando hoy este tipo de hardware se considera como un consumible?
En principio, el establecimiento de una CMS es bastante fcil, basta con registrar los CI.
En la realidad, las cosas no son tan simples. La dificultad principal reside en mantener la
integridad de la base. Si la granularidad es demasiado fina, ser difcil mantener su
integridad, ya que su actualizacin resultar muy difcil.
Los atributos de un CI
Para cada elemento de configuracin (CI), es imprescindible registrar un determinado
nmero de atributos y las relaciones existentes entre los diferentes CI.
Recordemos que un atributo es una informacin relativa a un CI (ver captulo Anexos Atributos de un CI).
Normalmente encontramos tres tipos de atributos:
Atributos tcnicos:
Caractersticas tcnicas.
Puesta en produccin: manual o automtica con herramientas de auto-diagnstico.
Atributos administrativos:
Ciclo de vida (cambios, incidencias...).
Puesta en produccin: manual o automtica si se integran con los otros procesos.
Atributos contables:
Tarifas, mantenimiento y licencia.
Origen: manual.
Las relaciones de los CI

Adems de los atributos, para cada CI es necesario definir las relaciones que van a unirle
con los otros CI.
Las relaciones se definen mediante las uniones (lgicas o fsicas) entre los diferentes CI de
la infraestructura.
d. Configuracin de referencia
La literatura ITIL habla de Baseline, lo que podemos traducir por Configuracin de
referencia.
Una configuracin de referencia es la imagen de un CI o de un grupo de CI tomados en un
momento concreto con el fin de comparar, o como punto de retorno.
Una configuracin de referencia es utilizada normalmente por el proceso de gestin de
cambios, para permitir una marcha atrs en caso de problemas en la puesta en produccin
de un cambio.
Variante
Es posible definir una versin ligeramente diferente de un CI o de una configuracin de
referencia. Esto se llama variante.

a. Gestin de licencias
Las empresas se encuentran frecuentemente con el problema de la gestin de las licencias
de software.
Debido a los diferentes medios de adquisicin de software disponibles hoy da, ofertas
multilicencia, licencia de empresa y descarga individual en Internet, es difcil controlar las
compras.
El control y la auditora del software estn bajo la responsabilidad del proceso de la gestin
de activos y configuraciones, mientras que las polticas de adquisicin e instalacin deben
estar bajo la responsabilidad del proceso de gestin de seguridad.
La ley hace responsables a los directivos de la empresa en caso de uso fraudulento de

software. Estos corren el riesgo de penas de prisin si el software adquirido ilegalmente se
utiliza en la empresa.
El proceso de gestin de activos de servicio y configuraciones permite a la organizacin
supervisar y controlar las licencias del software, desde su compra hasta la retirada de su
explotacin.
b. Beneficios
El proceso de gestin de activos de servicio y configuraciones permite un suministro
econmico y eficaz de los servicios informticos.
Entre los beneficios que aporta la gestin de activos de servicio y configuraciones, se
pueden enumerar:
Gestin y control de los CI de valor: permite controlar el uso de estos elementos, a

quin han sido confiados y si el inventario actual se corresponde con el inventario
oficial.
Suministro de informacin sobre los CI y su documentacin para mantener todos los

procesos de gestin de servicios, de entradas en produccin, de cambios, de
incidencias, de problemas, de capacidad y de seguridad.
Aportando a un proceso de gestin de problemas los datos sobre las tendencias: la

informacin de la gestin de activos de servicio y configuraciones se asociar a las
tendencias de los problemas aparecidos sobre los tipos particulares de CI. Esta
informacin de tendencia en relacin con los problemas permite una prevencin
proactiva de problemas.
Soporte al proceso de gestin de cambios: la informacin de gestin de activos y

configuraciones permite realizar un anlisis de impacto y planificar los cambios con
total seguridad, eficacia y efectividad. Esto limita el impacto de los cambios sobre el
entorno de produccin.
Soporte al proceso de gestin de entradas en produccin: la informacin de gestin

de activos de servicio y configuraciones contribuye a la integridad del sistema de
informacin, aportando informacin sobre las versiones de los CI y los cambios que
forman parte de la entrada en produccin.
Soporte al proceso de la continuidad de servicios: la CMS, las bibliotecas seguras y

las reservadas con seguridad ayudan a la restauracin de los servicios informticos
despus de un fallo, identificando los CI necesarios y su localizacin.
Soporte al proceso de gestin financiera: es fcil, a partir de la gestin de activos de

servicio y configuraciones, establecer una lista completa de los CI. A partir de esta
lista, se pueden deducir los costes esperados de mantenimiento y los derechos de
licencia, los contratos de mantenimiento, las fechas de renovacin de licencias, las
fechas de fin de vida de los CI y los costes de sustitucin (con la condicin de que
esta informacin se conserve).
Respeto a las obligaciones legales: la gestin de los activos de servicio y

configuraciones conserva un inventario de todos los elementos de software de la
infraestructura informtica. Las copias ilegales de software se pueden identificar
fcilmente, con el objetivo de ser regularizadas, borradas o destruidas.
c. Dificultades potenciales
Las dificultades potenciales que puede encontrar el proceso de gestin de activos y
configuraciones son:
El proyecto que se ha puesto en marcha no est bien controlado: es necesario que

las etapas de anlisis y diseo estn suficientemente desarrolladas, pues en caso
contrario el resultado final no ser el esperado. Cuando los cambios y entradas en
produccin se planifican, es necesario tener en cuenta el tiempo dedicado a las
actividades de gestin de activos y configuraciones.
Puesta en marcha de manera aislada: si la gestin de activos y configuraciones se

pone en marcha de manera aislada, sin proceso de gestin de cambios o proceso de
gestin de entradas en produccin, ser menos eficaz y puede que no se logren los
resultados esperados.
Incorrecta definicin del CI: el nivel de detalle es demasiado elevado (en este caso,
se le pidi al personal un trabajo innecesario) o demasiado bajo (en este caso, el
control es insuficiente).
El alcance del proceso: si el proceso se percibe como demasiado burocrtico o rgido,

las personas intentarn eludir la gestin de activos y configuraciones para ganar
tiempo o simplemente por malicia. Entonces ser necesario emprender acciones de
informacin y formacin para conseguir la adhesin de estas personas.
Ineficacia del proceso: el proceso puede ser ineficaz y una fuente de errores cuando
se gestiona de manera manual. Hoy en da, las herramientas disponibles tienen
buenas prestaciones y permiten la recuperacin automtica de la informacin. Sin
embargo, pueden aparecer problemas cuando la herramienta de gestin de activos y
configuraciones no permite considerar las nuevas funcionalidades o no soporta todas
las categoras de CI.
Falta de compromiso de la direccin: sin un fuerte compromiso por parte de los

dirigentes por respetarlo, el proceso de gestin de activos y configuraciones ser
muy difcil de llevar a cabo.
Gestin de cambios
1. Enfoque
En esta seccin vamos a ver cmo se gestionan los cambios y el impacto positivo que
puede tener la gestin de cambios en la calidad de los servicios de la organizacin.
Veremos que la eficacia de este proceso depende mucho de la calidad de la gestin de
configuraciones.
2. Por qu una gestin de cambios?

Actualmente estamos en un mundo cambiante.
Todo evoluciona: las necesidades de las empresas, las tecnologas, los servicios...
Las organizaciones TI se deben adaptar a todos estos cambios.
Sin embargo, estos cambios no deben tener un impacto negativo en la entrega de los
servicios ni en su calidad.
Para dar una respuesta satisfactoria, es indispensable tener una estrategia de evaluacin
de riesgos.
En la gestin de riesgos, hay que incluir la gestin de recursos, la continuidad del servicio,
el impacto financiero y el impacto en la calidad del servicio prestado.
Cuando se pone en marcha un cambio, es necesario que sea operativo inmediatamente, es
decir, durante la primera ocurrencia.
Adems, todas las personas que intervienen deben recibir una comunicacin apropiada y
en plazos tiles para todos los cambios que les afectan.
El porfolio de servicios proporciona una definicin clara de todos los servicios que estn en
el pipeline, activos o eliminados. La comprensin del porfolio de servicios ayuda a las
partes implicadas en la transicin a entender los impactos potenciales en un servicio nuevo
o modificado y sobre los otros servicios.
Es esto lo que permitir efectuar los cambios que garanticen un equilibrio entre la
necesidad de cambios y el impacto de estos en los servicios.
Para asegurar una gestin de cambios eficaz, es indispensable tener informacin completa
y precisa de la infraestructura del sistema de informacin y el conjunto de sus
componentes. Se trata del rol de gestin de configuraciones que hemos visto
anteriormente.
Por esta razn, es aconsejable poner en marcha estos dos procesos de manera simultnea.
Finalmente, es importante tener siempre en mente la idea de que todo cambio (adicin,
modificacin o eliminacin de un componente) en la infraestructura informtica se debe
tener en cuentaobligatoriamente por la gestin de cambios antes de aplicarse.

Los objetivos principales del proceso de gestin de cambios son los siguientes:
Asegurar que se utilizan los mtodos y los procedimientos estndares para un

tratamiento eficaz y rpido de todos los cambios, de manera que se minimice el
impacto de todos los incidentes relacionados con los servicios.
Garantizar que todos los cambios son:

Registrados, examinados, priorizados.
Autorizados.
Planificados.
Probados.
Aplicados.
Documentados.
Revisados.
Optimizar los riesgos de negocio: algunas veces, no hacer nada es un riesgo superior
al de poner en marcha un cambio que implique un riesgo, pero tambin un beneficio
potencial.
4. Definiciones
Cambios: es la adicin, modificacin o eliminacin de un CI o de una configuracin de
referencia.
RFC (Request For Change): formulario que se utiliza para describir un cambio solicitado.
Cambio estndar: un cambio relativamente comn, autorizado de forma previa por el
cliente, cuyos impactos, costes y riesgos son conocidos y que implica un procedimiento de
tratamiento establecido.
CAB (Change Advisory Board): es una estructura que examina los cambios y asesora al
responsable de estos sobre las decisiones que hay que tomar.
ECAB (Emergency Change Advisory Board): es una estructura que examina los cambios
urgentes y asesora al responsable de los cambios sobre las decisiones que hay que tomar
en el mbito de un cambio urgente.
FSC (Forward Scheduled Change): calendario de cambios que contiene los detalles de
todos los cambios de infraestructura aprobados para su implantacin, con las fechas
propuestas de implantacin.
PIR (Post Implementation Report): revisin posterior a la implantacin que verifica que los
cambios cumplen sus objetivos, que los clientes estn satisfechos y que no ha habido
consecuencias negativas.
PSA (Project Service Availability): disponibilidad prevista de los servicios, calendario que
prev los periodos de inactividad de los servicios.
5. Permetro
La gestin de cambios se encarga de:
Todos los cambios aportados por el diseo de los servicios.
Todos los cambios aportados por la explotacin de los servicios.
Estos cambios pueden incluir:
Hardware
Software
Aplicaciones
Contratos de servicios
Entorno de la organizacin
Documentos asociados a los diferentes CI
Sistemas de medida (herramientas, mtodos y mtricas)
Arquitecturas tcnicas
6. Roles
Responsable de los cambios.
Responsable de las entradas en produccin.
Miembro del CAB.
7. Indicadores
Nmero de RFC registrados.
Nmero de RFC implementados con xito.
Nmero de RFC que generaron incidencias.
Nmero de RFC que generaron problemas.
Nmero de vueltas atrs.
Nmero de cambios estndares.
Nmero de cambios urgentes.
Esta lista no es exhaustiva; convendr definir los indicadores en funcin de la estructura

que se aplique.
El proceso de gestin de cambios
9. Conceptos bsicos
a. El ciclo de vida de un cambio
El ciclo de vida de un cambio se puede definir por ocho actividades principales que se
detallan a continuacin:
El ciclo de vida de un cambio
b. Los diferentes tipos de cambios

Hay tres tipos de peticin de cambios:
Peticin de cambios normal

Es el caso del tratamiento normal de la peticin que sigue el conjunto de etapas del ciclo de
vida.
Peticin de cambios estndar

Es una peticin previamente autorizada por el cliente. En un primer momento, esta peticin
se ha tratado en el marco de un cambio normal. Los resultados fueron satisfactorios (el PIR
no indica ninguna dificultad de puesta en marcha y no hay impacto negativo sobre los
servicios), se conviene con el cliente que es posible realizar todas las peticiones de este
tipo de manera simplificada (ya que han sido descritas y validadas). Por ejemplo: peticin
de instalacin de un puesto de trabajo estndar.
Con frecuencia, este tipo de peticiones se tratan directamente por el centro de servicios.
Sin embargo, el responsable de los cambios debe informar al CAB de los cambios
estndares, despus de la oportuna revisin.
Peticin de cambios urgente

Es una peticin que se debe poner en marcha rpidamente. En este caso, se simplifican un
determinado nmero de etapas o estas no se realizan.
Este tipo de cambios debe ser excepcional.
c. Impacto de los cambios

Menor
En caso de un impacto menor, el responsable de los cambios autoriza el cambio e informa
al CAB de la accin emprendida.
Significativo
Cuando el cambio tiene un nivel significativo en trminos de impacto o de recursos, el
responsable de los cambios enva al CAB el conjunto de elementos relativos a la peticin
para su evaluacin.
La evaluacin del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y
la planificacin de la puesta en marcha.
El CAB asesora al responsable de los cambios.
Importante
En caso de un impacto importante o de coste significativo, el responsable de los cambios
transmite el cambio a la direccin para pedir consejo.
Si el cambio se aprueba, se transmite al CAB para su evaluacin.
La evaluacin del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y
la planificacin de la puesta en marcha.
El CAB asesora al responsable de los cambios.
d. Urgencia
El responsable de los cambios define la urgencia de la peticin:
Inmediata
Riesgo de prdidas potenciales importantes.
Reunin del ECAB para su evaluacin inmediata y toma de decisin rpida, con el
objetivo de poner en marcha el cambio lo antes posible.
Asignar un mximo de recursos de manera inmediata para tratar el cambio.
Alta
Impacto fuerte sobre determinados usuarios o impacto sobre un gran nmero de

usuarios.
Definir la prioridad alta para la construccin y puesta en marcha del cambio.
Asignar los recursos necesarios y planificar una rpida entrada en produccin.
Media
Sin impacto importante.
Asignar una prioridad media y planificar el cambio para la prxima entrada en

produccin planificada.
Baja
Cambio justificado, pero sin impacto real sobre la entrega del servicio.
Construir el cambio y planificar para la prxima entrada en produccin prevista.
Esta definicin solo tiene valor como ejemplo. La tabla se debe definir en funcin de la
organizacin.
e. El CAB y el ECAB
El CAB
El CAB es una entidad de geometra variable. El responsable de los cambios es el que
debe definir la composicin del CAB, en funcin del cambio o de los cambios solicitados.
De manera ideal, el CAB deber estar formado por los responsables de proceso, asistidos
por los expertos del campo o de las reas implicadas (por ejemplo: bases de datos, redes,
aplicacin implicada...).
El CAB no se rene por cada peticin de cambios. En trminos generales, se fija un plan de
revisiones del CAB, durante las que se examinan el conjunto de peticiones de cambio.
Previamente a estas revisiones, el responsable de los cambios tendr que enviar al
conjunto de miembros del CAB los elementos que forman parte de cada cambio solicitado.
En funcin del tamao de la organizacin, estas revisiones se organizan con la presencia
fsica de los miembros del CAB o por vdeo o teleconferencia.
El ECAB
Como el CAB, el ECAB es una entidad de geometra variable. Es el responsable de los

cambios el que definir la composicin del ECAB, en funcin de los cambios urgentes
solicitados.
Normalmente, la composicin del ECAB est limitada a dos o tres miembros que ayudarn
al responsable de los cambios a tomar una decisin rpida. Por supuesto, no hay
planificacin de revisiones ECAB. nicamente la urgencia justifica la creacin de un ECAB.
f. Las actividades de la gestin de cambios

Una parte de las actividades las realiza el proceso de puesta en produccin, que veremos
en el captulo siguiente, pero cuya coordinacin est asegurada por la gestin de cambios.
Las principales actividades de la gestin de cambios son las siguientes:
Recepcin
El responsable de la gestin de cambios recibe los RFC que provienen:
De los procesos de explotacin de servicios.
De los procesos de diseo de servicios.
De los procesos de la estrategia de servicios.
De manera ideal, debera contener, como mnimo, los siguientes elementos:
El identificador nico de la RFC.
Las referencias de las incidencias y problemas relacionados.
La referencia del CI implicado.
La descripcin del cambio.
Las razones del cambio.
Las consecuencias potenciales si el cambio no se pone en marcha.
Los datos del solicitante.
La prioridad solicitada.
La estimacin del impacto del cambio.
La estimacin de los recursos necesarios para la puesta en marcha.
La estimacin de los riesgos.
Las posibilidades de marcha atrs.
Si la RFC no se completa de forma correcta, se rechaza automticamente sin que se

registre.
Registro
Si la RFC se completa correctamente, se registra.
El tipo de la peticin de cambio puede ser:
Normal
Estndar (si todava no se ha identificado)
Urgente
En funcin del tipo de cambios, el tratamiento es diferente.

Ahora vamos a ver en detalle el tratamiento de una peticin normal.
Evaluacin
Los miembros del CAB examinan los elementos recibidos para cada cambio registrado.
Para esta evaluacin, deben tener en cuenta los elementos siguientes:
Impacto sobre el servicio implicado.
Impacto sobre los otros servicios.
Impacto sobre las infraestructuras.
Consecuencias en caso de no llevarse a cabo.
Recursos necesarios para la puesta en marcha.
Recursos adicionales necesarios si el cambio se pone en marcha.
Autorizacin
Se habla de autorizacin o aprobacin para poner en marcha un cambio.
La nica persona habilitada para autorizar o rechazar un cambio es la que haya sido
autorizada para el cambio. Generalmente, es el responsable de los cambios.
Rene al CAB o al ECAB para obtener sus evaluaciones y tener en cuenta sus consejos
antes de tomar su decisin.
Construccin
Esta parte se realiza en el mbito del proceso de gestin de entradas en
produccin.
La gestin de cambios tiene un papel de coordinacin en la construccin de los cambios y
en la puesta en produccin.
Es importante preparar un plan de marcha atrs, especialmente tomando una
configuracin de referencia (ver seccin de Gestin de los activos de servicio y
configuraciones).
Tambin es necesario elaborar un plan de pruebas.
Estas pruebas deben tener en cuenta una prueba unitaria del cambio y una prueba en un
entorno lo ms cercano posible al entorno de produccin.
En el caso de un cambio urgente, en funcin de la urgencia, puede ser que el plan de

vuelta atrs y el plan de pruebas no se estudien ni realicen.
Pruebas
produccin.
Se debe poner en marcha el plan de pruebas.
Estas pruebas deben tener en cuenta los siguientes aspectos:
Impacto sobre el rendimiento del servicio.
Impacto sobre el rendimiento de otros servicios.
Funcionalidad.
Asistencia posible.
Capacidad de mantenimiento.
Fiabilidad y disponibilidad.
Cumplimiento de las reglas de seguridad.
Entrada en produccin
produccin.
Como consecuencia de las etapas anteriores, la gestin de cambios pasa el testigo al
proceso de entradas en produccin, que veremos en el captulo siguiente.
Como consecuencia de la entrada en produccin, se regresa al proceso de gestin de
cambios para realizar la ltima etapa de la gestin de cambios.
Reporting
Como consecuencia de la entrada en produccin del cambio, es imprescindible hacer
balance de la peticin de cambio.
Esta operacin se traduce en la creacin de un documento llamado PIR (Post
Implementation Review).
Durante esta revisin, se deben analizar todos los aspectos tcnicos de la puesta en
marcha:
Nivel de recursos consumidos en relacin con las previsiones.
Tiempo de puesta en marcha en relacin con las previsiones.
Dificultades encontradas.
Nmero de incidencias creadas.
Nmero de problemas creados.
La marcha atrs se ha iniciado?
Los resultados son consistentes con los objetivos...
Como consecuencia de esta revisin, ser posible cerrar todos los tickets Problema e
Incidencia relacionados con el cambio.
Atencin: en el mbito de un cambio de software o de aplicacin, es imprescindible que el

personal del Centro de servicios y los usuarios hayan recibido correctamente la formacin
necesaria para aprender la nueva versin.
Del mismo modo, deberemos asegurarnos de que la documentacin, tanto para un cambio
de software o de aplicacin como para un elemento de infraestructura, est a disposicin
del personal del centro de servicios y de los usuarios.
Cambio normal y cambio urgente
g. Las 7 R de la gestin de cambios

En los libros en ingls se menciona el trmino 7 R, ya que en cada pregunta encontramos
una palabra que empieza por la letra R como asunto principal. Encontrar entre parntesis
la palabra inglesa.
Para cualquier peticin de cambio, es obligatorio hacerse las siete preguntas siguientes:
Quin pide el cambio? (Who Raised)
Cul es el motivo para esta peticin? (Reason)
Cul es el resultado esperado de este cambio? (Return)
Cules son los riesgos potenciales de este cambio? (Risks)
Qu recursos hay que poner en marcha para hacer este cambio? (Resources)
Quin es responsable de la construccin, las pruebas y la implementacin del

cambio? (Responsible)
Cules son las relaciones entre este cambio y los otros cambios? (Relationship)
Sin estos elementos, la evaluacin del impacto del cambio en la entrega no es posible.
El anlisis de los riesgos y beneficios es imprescindible para asegurar las ventajas del
cambio.

a. Beneficios
El proceso de gestin de cambios permite una gestin eficiente de todas las modificaciones,
asegurando que los cambios que se han puesto en marcha no afectarn a la calidad de los
servicios proporcionados por la organizacin ni a los niveles de servicio contractuales.
Entre los beneficios que aporta la gestin de cambios, podemos incluir:
Mejor evaluacin del coste de los cambios solicitados.
Mejor evaluacin de los costes reales de los cambios aplicados.
Mejor respuesta a los requerimientos del negocio.
Reduccin del impacto negativo de los cambios sobre la calidad de los servicios
proporcionados por la organizacin.
Cumplimiento de los compromisos establecidos en los SLA.
Mejora de la gestin de los incidentes y de la gestin de los problemas (garanta de

que la informacin relativa a la infraestructura se suministra antes del cambio).
Mejora de la gestin de la disponibilidad y de la gestin de la continuidad, mediante

un mejor conocimiento de la evolucin de las infraestructuras.
Disminucin de los riesgos, ya que se tienen en cuenta los cambios en la gestin de

la seguridad.
Productividad mejorada para los equipos de la organizacin, ya que las acciones se

planifican.
Productividad mejorada para los usuarios, ya que hay menos interrupciones del
servicio no programadas.
Perspectivas de negocio mejoradas, ya que se demuestra profesionalidad.
Las dificultades potenciales que podemos encontrar en el proceso de gestin de cambios
son:
Gestin de activos y configuraciones deficiente o no implementada.
Proceso demasiado burocrtico.
Intentos de eludir el proceso de gestin de cambios.
PIR no realizada al final de una implementacin.
Permetro demasiado importante para los recursos disponibles.
Procedimientos de vuelta atrs ausentes o deficientes.
Falta de apoyo por parte de la direccin de la organizacin.
Gestin de las entradas en produccin

1. Enfoque
En esta seccin vamos a ver cmo se gestionan las entradas en produccin de los cambios.
Veremos que la eficacia de este proceso es muy dependiente de las acciones realizadas por
la gestin de cambios.
En trminos de gestin de proceso, la gestin de las entradas en produccin se podra
considerar como un subproceso de la gestin de cambios, ya que se inicia por la gestin de
cambios y se vuelve hacia la gestin de cambios al final del proceso.
2. Por qu una gestin de las entradas en produccin?

Hemos visto en la seccin anterior el tratamiento de las peticiones de cambios (RFC).
Para dar una respuesta satisfactoria a la gestin de cambios, es imprescindible tener una
estrategia de entradas en produccin rigurosa.
Esto permite efectuar los cambios que garantizan la proteccin del entorno de produccin.
Todos los aspectos, ya sean tcnicos o no, se deben tener en cuenta para una gestin
eficiente de las entradas en produccin.
Para asegurar una gestin eficaz de las entradas en produccin, es imprescindible disponer
de informacin completa y precisa de la infraestructura del sistema de informacin y del
conjunto de sus componentes. La gestin de activos y configuraciones, que hemos visto
anteriormente, tiene el papel de proporcionar esta informacin.
La puesta en marcha de la gestin de las entradas en produccin debe permitir proteger el
entorno de produccin contra cualquier dao debido a entradas en produccin no
autorizadas o a pruebas realizadas directamente en el entorno de produccin.

Los objetivos principales del proceso de gestin de las entradas en produccin son los
siguientes:
Definir las polticas de entrada en produccin.
Disear y aplicar procedimientos eficaces para los despliegues.
Asegurar que todos los despliegues se pueden trazar, instalar, probar, verificar y,
eventualmente, volver atrs o desinstalar.
Planificacin de los contenidos exactos de las actualizaciones y de los planes de

desarrollo (coordinacin con la gestin de cambios).
Verificacin de que todos los elementos desarrollados o modificados cumplen los

requisitos de seguridad y se pueden controlar por la CMS.
Asegurar que el servicio nuevo o modificado permite garantizar los niveles de utilidad
y garanta recogidos en el SLA.
Gestin de los requisitos de clientes y usuarios para las actualizaciones y su

despliegue.
Comunicar y asegurar que se ha dado a los usuarios y al personal de la organizacin

formacin suficiente (particularmente al centro de servicios).
Supervisar y controlar los despliegues

documentacin) nuevos o modificados.
Mantener y controlar el contenido de la DML (Definitive Media Library) y de la DHS

(Definitive Hardware Storage) y asegurar que todas las copias se almacenan
correctamente en la DML.
Puesta en marcha del ELS (Early Life Support).
de
software
hardware
(y
de
su
4. Definiciones
ELS (Early Life Support): es un soporte especfico que se debe aplicar en el momento de la
entrada en produccin de nuevos productos, en particular en el momento de la
modificacin o modificaciones de versin de software o de aplicaciones.
Plan de vuelta atrs: plan que permite volver a la situacin anterior en caso de que el
despliegue de los cambios no sea satisfactorio.
Big Bang: modo de implementacin de un cambio.
FSC (Forward Scheduled Change): calendario de cambios que contiene los detalles de
todos los cambios de infraestructura aprobados para su implantacin, con sus fechas
propuestas de implantacin.
PSA (Projected Service Availability): disponibilidad proyectada de servicios, calendario que
prev los periodos de inactividad de los servicios.
PIR (Post Implementation Review): revisin posterior a la implantacin que verifica que el
cambio cumple sus objetivos, que los clientes estn satisfechos y que no hay consecuencias
negativas.
5. Permetro
La gestin de las entradas en produccin es responsable de:
El diseo de las entradas en produccin.
La validacin del hardware y software.
La planificacin de las entradas en produccin.
La puesta en marcha del ELS.
Esto incluye todos los componentes de las configuraciones necesarias para implementar
una entrada en produccin, como:
Activos de servicio fsicos (servidor o redes).
Activos de servicio virtuales (servidor o memoria).
Aplicaciones y software.
Formacin para los usuarios y el personal de TI.
Los servicios (incluyendo los contratos y acuerdos de servicio).
6. Roles
Responsable de las entradas en produccin.
Responsable de cambios.
7. Indicadores
Nmero de entradas en produccin, principales y de poca importancia.
Nmero de entradas en produccin implementadas con xito.
Nmero de entradas en produccin que generaron incidencias.
Nmero de entradas en produccin que generaron problemas.
Nmero de marchas atrs.
se ponga en marcha.
El proceso de gestin de las entradas en produccin
9. Conceptos bsicos
a. El ciclo de vida de una entrada en produccin
El ciclo de vida de una entrada en produccin se puede definir por seis actividades
principales, que se detallan a continuacin:
El ciclo de vida de un cambio
b. Los diferentes tipos y modos de entrada en produccin

Tipos de despliegue
Existen tres tipos de despliegue:
Despliegue completo (Full release): la ventaja de establecer un despliegue

completo es que se construyen todos los componentes y se prueban y ponen en
marcha todos juntos. El despliegue se puede realizar al mismo tiempo sobre todas
las infraestructuras (software o hardware), o sobre un entorno piloto, antes de
implementarlo en el conjunto de entornos. La ventaja de hacerlo en dos partes (o
fases) es la reduccin de riesgos de bloqueo generalizado en caso de dificultad.
Desafortunadamente, esta opcin resulta a menudo ms costosa, ya que es
necesario modificar los recursos tcnicos en cada fase del despliegue.
Despliegue intermedio (Delta release): en este caso de despliegue, solo se

cambia la parte de la infraestructura que haya sido modificada desde la ltima
entrada en produccin. El coste de un cambio como este es, en general, menos
elevado que en el caso de un despliegue completo. Por el contrario, si se ha
modificado un CI sin que se haya registrado en la CMDB, se corre el riesgo de tener
dificultades en el despliegue. Esto puede obligar en algunos casos a la necesidad de
una vuelta atrs. Como en el caso del despliegue completo, el despliegue intermedio
se puede realizar en una o dos fases, con las mismas consecuencias financieras.
Despliegue por agrupacin (Package): la tendencia en la mayora de las

empresas es agrupar los cambios, en la medida en que no sean cambios
importantes, con el objetivo de limitar las interrupciones del servicio. Algunos
cambios, incluso de poca importancia, pueden provocar la puesta en marcha de otros
cambios al mismo tiempo. Hay que prestar atencin, sin embargo, a no crear una
entrada en produccin empaquetada, que contenga demasiados cambios; existira el
riesgo de tener que hacer una marcha atrs sobre demasiados elementos.
Modo de despliegue
Por otro lado, el despliegue se puede lograr de varias maneras, en funcin de las
herramientas que se utilicen:
Big Bang
En ese caso se realiza un despliegue de manera global sobre el conjunto de la
infraestructura, en una nica operacin.
Fase
En este caso, en funcin del nmero de personas o ubicaciones implicadas y si es posible,
el despliegue se realiza en varias operaciones planificadas, ubicacin por ubicacin, servicio
por servicio, o cliente por cliente.
Modo Push & Pull
En este caso, la emisin de las entradas en produccin se realiza de manera electrnica. En
modo Push, se fuerza la instalacin sobre un conjunto de puestos; en modo Pull, es el
usuario el encargado de hacer la actualizacin sobre su puesto. Pueden aparecer problemas
en la utilizacin de este modo de despliegue.
En el caso del Push, nunca se est del todo seguro de que todos los puestos de trabajo
hayan tenido suministro elctrico, lo que implica que algunos usuarios podran utilizar una
versin diferente en un momento dado.
En el caso del Pull, puede aparecer el mismo problema si no todos los usuarios hacen el
cambio en el momento indicado.
Modo Automatizado o Manual
La entrada en produccin de los cambios se puede realizar de manera manual o
automatizada, en funcin de las herramientas disponibles en la organizacin.
c. Las cuatro fases de la entrada en produccin

1. Planificacin de la entrada en produccin
En esta fase, hay que preparar una planificacin para la construccin y despliegue de la
entrada en produccin. Esta fase comienza con la autorizacin de la gestin del cambio
para la planificacin de una entrada en produccin y termina con la autorizacin de la
gestin del cambio para la creacin de la entrada en produccin.
2. Construccin y pruebas
La entrada en produccin se construye, prueba y controla en la DML (Definitive Media
Library). Esta fase comienza con la autorizacin de la gestin del cambio para la creacin
de la entrada en produccin y termina con la autorizacin de la gestin del cambio para el
control de una base de referencia en la DML, a travs del proceso de gestin de
configuraciones (SACM). Esta fase es nica para cada entrada en produccin.
3. Despliegue
El paquete de entrada en produccin que est en la DML se despliega en el entorno de
produccin.
Esta fase comienza con la autorizacin de la gestin del cambio para el despliegue. Incluye
la creacin de una base de referencia en la DML, por el proceso de gestin de
configuraciones (SACM). Esta fase es nica para cada entrada en produccin.
Esta fase termina con el soporte por la fase operacin del ciclo de vida y el inicio del ELS
(Early Life Support).
La fase de despliegue puede ser un proceso recurrente en funcin de la opcin de
despliegue seleccionado.
4. Revisin del despliegue y cierre

Se debe aprender de la experiencia; se deben analizar los objetivos de rendimiento y
realizacin para determinar los ejes de mejora.
d. Las actividades de gestin de la puesta en produccin

El responsable de la gestin de las entradas en produccin debe definir una estrategia para
aclarar los roles y responsabilidades de cada uno. Esta estrategia se debe concretar en un
documento.
La poltica de entradas en produccin se debe revisar despus de cada cambio principal de
la infraestructura tcnica.
Las principales actividades de la gestin de las entradas en produccin son las siguientes.
Diseo
Es imprescindible disear los procedimientos para la entrada en produccin de los cambios.
En esta actividad, es necesario:
Definir los modelos de entrada en produccin.
Definir el plan de pruebas.
Definir el plan de puesta en marcha.
Preparar los procedimientos documentados.
Construccin y preparacin
En esta actividad hay que construir el cambio:
Identificar el hardware y el software implicados en el cambio.
Ensamblar el conjunto de componentes.
Preparar el entorno de pruebas.
Asegurar, si el cambio lo implica, que la documentacin est disponible y que se ha

definido y puesto en prctica correctamente un plan de formacin.
Evaluacin
En esta actividad hay que realizar las pruebas.
De manera ideal, en la medida de lo posible, es deseable implicar a los clientes y usuarios
en las pruebas. El objetivo es obtener la aceptacin formal del cliente y del usuario sobre la
futura entrada en produccin.
Estas pruebas deben incluir pruebas funcionales, operativas, de rendimiento y de
integracin.
Se deben realizar de manera unitaria y de manera global, en un entorno lo ms parecido
posible al entorno de produccin.
Planificacin
La planificacin de cambios se debe realizar teniendo en cuenta el calendario de cambios

(FSC), as como las disponibilidades proyectadas de servicios (PSA).
La planificacin implica obtener un consenso sobre el contenido de la puesta en produccin,
la planificacin de los recursos, la planificacin de la aceptacin de los grupos de soporte y
del cliente y la produccin del plan de vuelta atrs.
Comunicacin y formacin
La comunicacin con los clientes, los usuarios y el personal del centro de servicios es
imprescindible. Cada uno debe saber cmo se va a producir la entrada en produccin de los
cambios y conocer los impactos de la operacin.
En caso de que el cambio implique que se debe impartir una formacin, ya sea a los
usuarios, al personal del centro de servicios o a los dos, la formacin se deber llevar a
cabo antes de la entrada en produccin.
Algunos cambios, fundamentalmente en caso de una nueva versin de software o una
nueva aplicacin, necesitan aplicar una clula de soporte (Early Life Support) para asistir al
personal del centro de servicios durante un cierto tiempo.
La puesta en marcha del ELS tambin se debe preparar para que est operativo despus de
la instalacin de los cambios.
El personal que ha contribuido al desarrollo del servicio tambin puede estar integrado en
el soporte ELS.
Esto mejorar la transmisin del conocimiento a los tcnicos del centro de servicios, lo que
tambin puede mejorar la calidad de las relaciones entre los diferentes equipos.
Distribucin e instalacin
La instalacin del cambio se debe realizar utilizando uno de los tipos y modos de
despliegue, enumerados en el captulo anterior.
La CMS se debe actualizar con motivo de la entrada en produccin, la copia de versiones en
la DML o el almacenamiento del hardware en la DSH, la actualizacin de todos los CI
implicados.
Se deben registrar todos los fallos encontrados durante la instalacin para la redaccin del
PIR.

a. Beneficios
La gestin de las entradas en produccin permite desplegar el cambio asegurando que los
cambios que se han puesto en marcha no afectarn a la calidad de los servicios
proporcionados por la organizacin ni a los niveles de servicio contractuales.
Entre los beneficios que aporta la gestin de cambios, podemos enumerar:
Entornos de produccin y de pruebas estables.
Reduccin del impacto negativo del cambio sobre la calidad de los servicios
proporcionados por la organizacin.
Respeto de los acuerdos definidos en los SLA.
Gestin de la disponibilidad y gestin de la continuidad mejoradas, al tener en cuenta

elFSC para realizar el despliegue.
Baja probabilidad de encontrar copias ilegales de software en la organizacin.
Mejora de la productividad de los equipos de la organizacin TI, ya que las acciones

estn planificadas.
Mejora de la productividad de los usuarios, ya que hay menos interrupciones del

servicio no programadas.
Las dificultades que pueden entorpecer el proceso de gestin de las entradas en produccin
son:
Resistencia al cambio de los equipos acostumbrados a realizar las entradas en

produccin individualmente.
Intentos para evitar los procedimientos de aplicacin.
Responsabilidades mal definidas.
Gestin de activos y configuraciones errnea o no implementada.
Permetro demasiado importante para los recursos disponibles.
Procedimientos de vuelta atrs ausentes o errneos.
Gestin de validaciones y pruebas

1. Enfoque
Este proceso contribuye a la puesta en marcha de una estrategia de calidad.
Esta estrategia de calidad permite entregar un servicio nuevo o modificado, a travs de las
fases de diseo y entrada en produccin, correspondiente a las necesidades y al uso
esperado.
2. Por qu una gestin de las validaciones y las pruebas?

La validacin y las pruebas son un dominio esencial de la gestin de servicio.
A menudo, esta actividad se pasa por alto o se ignora, lo que es un error.
Si los servicios no se prueban lo suficiente, su despliegue puede generar:
Incidentes, diferencias entre lo que espera el cliente y lo que suministra el proveedor

de servicios.
Llamadas al centro de servicios para pedir explicaciones o aclaraciones sobre el uso y

las funcionalidades de un servicio o de una aplicacin.
Problemas y errores difciles de diagnosticar.
Costes adicionales, ya que puede ser ms costoso reparar un error en un entorno de

produccin que en un entorno de pruebas.
Uso del servicio que no corresponde a los requerimientos del negocio.

Los objetivos principales del proceso de gestin de validaciones y pruebas son los
siguientes:
Asegurar que las necesidades del cliente, para un servicio nuevo o modificado, se
definen y obtienen el soporte adecuado.
Asegurar que un servicio nuevo o modificado responde correctamente a las

necesidades (utilidad) y que se proporciona la garanta correctamente (garanta).
Asegurar que un servicio nuevo o modificado proporciona los resultados que el

cliente espera, respetando los costes, la capacidad y la disponibilidad previstos
inicialmente.
Poner en marcha un proceso de planificacin e implementacin que pruebe que el

servicio nuevo o modificado responder a las necesidades, incluidos los compromisos
que se especifican en el SLA.

El proveedor de servicios asume la responsabilidad del suministro de la prestacin y del
mantenimiento de los activos de servicio, cliente o proveedor, respetando los compromisos
definidos en los acuerdos de servicios (SLA/OLA).
Este proceso permite asegurar que el proveedor de servicios es capaz de garantizar la
prestacin a lo largo del ciclo de vida del servicio, lo que implica disponer de los recursos y
capacidades necesarias.
Los resultados de este proceso servirn al proceso de gestin de los cambios para activar, o
no, el proceso de despliegue.
El proceso de gestin de validaciones y pruebas
6. Conceptos bsicos
a. Enfoques y tcnicas de pruebas
Existen numerosos enfoques que se pueden combinar para hacer la validacin y las
pruebas, segn las restricciones del entorno de pruebas y del futuro entorno de produccin.
De la misma manera, se pueden combinar diferentes enfoques para responder a los
requerimientos de diferentes tipos de servicio, modelos de servicio, perfiles de riesgo, nivel
de competencia, objetivos y nivel de pruebas de proceso.
A continuacin se enumeran algunos ejemplos:
Enfoque basado en el riesgo.
Enfoque de conformidad con los estndares o las normas.
Enfoque basado en la experiencia.
Enfoque basado en los mtodos del ciclo de vida del desarrollo de software y
simulacin.
Escenario de pruebas.
Prototipado.
Pruebas de laboratorio.
Pruebas de no regresin.
Ejecucin de proyectos piloto.
Para optimizar los recursos de prueba, las actividades de prueba se deben definir y asignar
en funcin de la importancia del servicio, del impacto potencial sobre las operaciones
previstas y del nivel de riesgos.
Los anlisis del impacto sobre el negocio se deben hacer durante la fase de diseo,
particularmente en los procesos de gestin de la capacidad, disponibilidad y continuidad de
servicios.
Gestin de la evaluacin de los cambios

1. Enfoque
Este proceso contribuye a la puesta en marcha de una estrategia de calidad.
Esta estrategia de calidad permite entregar un servicio nuevo o modificado, a travs de las
fases de diseo y entrada en produccin, que corresponde a las necesidades y uso
esperado.
2. Por qu una gestin de la evaluacin de los cambios?

La gestin de los cambios necesita los resultados de la gestin de evaluacin para poder
decidir desplegar o no un cambio.
Para esto, es necesario un marco estandarizado y uniforme para evaluar el rendimiento de
los cambios, teniendo en cuenta el rendimiento real y el esperado.
Ser necesario identificar los riesgos reales o potenciales para proporcionar ayuda a la
toma de decisin para la gestin de los cambios.

Los objetivos principales del proceso de evaluacin de los cambios son:
Definir correctamente el resultado esperado por las partes implicadas y suministrar

informacin de gestin precisa y eficaz.
Evaluar los objetivos de un cambio, pero tambin los efectos no esperados que
puede tener este cambio, teniendo en cuenta las capacidades, los recursos y las
restricciones organizativas.
Proporcionar resultados de buena calidad que permitirn a la gestin de los cambios

decidir desplegar o no un cambio.

Este proceso se aplica a todos los cambios sometidos al proceso de gestin de los cambios.
El proceso de gestin de las evaluaciones
6. Conceptos bsicos
Todos los cambios se deben evaluar, pero solo los cambios significativos lo deben ser en el
marco del proceso de evaluacin.
Los criterios de evaluacin se deben definir para poder determinar cules son los cambios
implicados por este proceso.
Esta evaluacin debe tener en cuenta los riesgos inherentes a este cambio y las
interacciones con los otros servicios o las infraestructuras compartidas.
Como para los otros procesos ITIL, es deseable la aplicacin de modelos.
Por supuesto, se debe documentar la decisin que se tome.
a. Desarrollo de las actividades del proceso
El desarrollo de las actividades del proceso de evaluacin

1. Enfoque
En esta seccin, vamos a ver cmo se gestiona el conocimiento en el seno del proveedor de
servicios.
Para una parte importante, el conocimiento proviene de una fuente interna de la empresa,
pero tambin del exterior (fabricantes de software, proveedores externos...).
2. Por qu una gestin del conocimiento?

La capacidad para suministrar un servicio de calidad se basa en un buen conocimiento del
entorno de suministro del servicio, pero tambin en el entorno exterior y en la capacidad
de reaccionar en funcin de las circunstancias.
Para esto, los colaboradores de los departamentos de TI deben poder encontrar
informacin en las diferentes bases de informacin de la empresa.
Este conocimiento debe incluir la identificacin de los participantes y los riesgos.

Los objetivos principales del proceso de gestin del conocimiento son los siguientes:
Mejorar la calidad de la gestin decisional, asegurando que la informacin est

disponible y sea segura, a travs del ciclo de vida de los servicios.
Hacer que el proveedor de servicios sea ms eficiente y mejorar la calidad del

servicio.
Mejorar la satisfaccin del cliente.
Reducir los costes

conocimiento.
Asegurar que la gestin tiene una comprensin clara del valor del servicio
suministrado al cliente.
Poner en marcha y mantener un sistema de gestin del conocimiento (SKMS).
Recolectar, analizar, almacenar, compartir, usar y mantener el conocimiento, la

informacin y los datos a travs de la organizacin.
del
servicio,
reduciendo
la
necesidad
de
redescubrir
el
4. Permetro
La gestin del conocimiento se aplica al conjunto de actividades de la gestin de los
departamentos de TI, a travs de las diferentes fases del ciclo de vida de los servicios.
5. Descripcin del proceso y de las principales relaciones
La gestin del conocimiento
6. Conceptos bsicos
Es obligatoria una poltica de gestin del conocimiento para guiar al equipo directivo, en
trminos de comportamiento y compromiso, con objeto de hacer ms efectivo y eficiente
este proceso.
Esta poltica ser diferente en funcin de la cultura de la empresa.
Sin embargo, tiene que incluir:
El conocimiento y la informacin necesarias para el soporte de los servicios.
Todo el conocimiento y la informacin se deben crear, revisar, aprobar, mantener,

controlar y hacerlos disponibles siguiendo un proceso formal y documentado.
Todas las polticas, planes y procesos se deben revisar, al menos, una vez al ao.
a. SKMS
La base de datos de conocimientos se llama SKMS (Service Knowledge Management
System).
Esta base de datos contiene las bases de datos especficas de cada proceso.
Por ejemplo, la base de datos de la gestin de configuraciones (CMDB) se incluye en el
sistema de gestin de configuraciones (CMS - Configuration Management System), que a
su vez est incluida en la SKMS.
b. El modelo DIKW
El modelo DIKW
El modelo DIKW es una representacin de la estructura del conocimiento. A continuacin
explicamos el significado de este acrnimo.
En primer lugar, partimos de datos sin tratar (la D del modelo).

Cuando estos datos se estructuran (qu, quin, cundo y dnde), pasamos a la I del
modelo, ya que los datos se han transformado en Informacin.
La siguiente etapa va a responder al Cmo. En esta etapa, podemos hablar de
Conocimiento.
La ltima etapa se llama de la Sabidura, ya que en este momento sabemos cmo usar el
conocimiento y, por tanto, crear valor.
LOS PROCESOS DE LA EXPLOTACION DE SERVICIOS

La fase de explotacin de servicios
1. Por qu una explotacin de los servicios?
Como hemos visto en el captulo de presentacin de la norma, ITIL se descompone en
Los niveles decisionales de la fase Operaciones

Los procesos de explotacin de los servicios se sitan en la parte correspondiente a los
niveles operativos.
La explotacin de los servicios se basa en las funciones y procesos.
En esta primera parte, no veremos los procesos transicin de servicios, a pesar de que
se identifican tanto en la parte tctica como en la parte operativa. Se tratarn en la
parte transicin de los servicios.
2. Los objetivos de la explotacin de servicios

Al contrario de lo que sugieren algunas ideas preconcebidas, la explotacin de servicios no
solo afecta a las operaciones diarias dirigidas a suministrar el servicio.
En el marco del ciclo de vida de los servicios, el objetivo de la explotacin de servicios es
asegurar que el negocio puede cumplir sus objetivos y poner en marcha procesos para
optimizar los costes y la calidad de los servicios.
En el mbito tecnolgico, la explotacin de los servicios es responsable del correcto
funcionamiento de los diferentes elementos que forman la infraestructura informtica, que
soporta los servicios y la ejecucin de las actividades de control, para gestionar y entregar
los servicios.
En el mbito del negocio global, la explotacin de servicios es responsable de suministrar
servicios eficaces con un coste aceptable y con un nivel de servicio equivalente a los niveles
definidos en los SLA. Tambin debe asegurar el mantenimiento del nivel de satisfaccin de
los usuarios.
3. Los procesos de explotacin de los servicios
La gestin de eventos.
La gestin de incidencias.
La gestin de problemas.
El tratamiento de consultas.
La gestin de accesos.
4. Las funciones de explosin de servicios

La fase explotacin de servicios se compone, adems de los procesos mencionados
anteriormente, de cuatro funciones:
El centro de servicios.
La gestin de operaciones.
La gestin tcnica.
La gestin de aplicaciones.
a. La definicin de una funcin

Una funcin es un grupo de personas o un equipo y herramientas u otros recursos que se
usan para realizar las actividades definidas en un proceso.
Una persona o un grupo de personas pueden trabajar para varias funciones.
Una actividad se puede realizar por una persona, un grupo de personas o varios grupos de
personas.
Para asegurar un suministro ptimo de los servicios, es imprescindible definir claramente
los roles y responsabilidades de cada uno.
La organizacin debe aplicar y gestionar una estructura de equipos, grupos o funciones.

La definicin de los roles y responsabilidades se debe efectuar a nivel de cada proceso y de
cada una de las actividades del proceso (ver Anexos - El modelo RACI).
b. La ubicacin de las funciones
Ubicacin de las funciones y relaciones
Funciones
1. Funcin de gestin de operaciones

a. Descripcin de la funcin
La funcin de gestin de operaciones
b. Conceptos bsicos
La gestin de operaciones est formada por dos partes:
El control de las operaciones: gestin del conjunto de actividades diarias para

suministrar el servicio.
Los medios generales (Facilities Management): gestin del entorno fsico y de los
contratos con los proveedores externos.
2. Funcin de gestin de aplicaciones

Esta funcin es responsable de la gestin de las aplicaciones a travs de su ciclo de vida.
Tiene relacin con la gestin de las operaciones y el centro de servicios.
Vase el esquema de la seccin La ubicacin de las funciones.
3. Funcin de gestin tcnica

Esta funcin suministra las competencias y los recursos tcnicos para las operaciones.
Tiene un papel importante en el diseo, transicin (pruebas y despliegue) y operaciones

(soporte).
Tiene relacin con la gestin de operaciones y el centro de servicios.
Vase el esquema de la seccin La ubicacin de las funciones.
El centro de servicios
1. Etapas preliminares
Antes de la puesta en marcha del centro de servicios, es necesario realizar varias etapas
preliminares.
Encontrar estas etapas en los captulos siguientes:
Definicin de la estrategia de negocios: captulo Los procesos de la estrategia de

servicios - Generacin de la estrategia.
Preparar la puesta en marcha de un CMS inicial: captulo Los procesos de la

transicin de servicios - Gestin de los activos de servicio y configuraciones.
Preparar la puesta en marcha de contratos de servicios bsicos: captulo Los

procesos del diseo de servicios - Gestin de los niveles de servicio.
Preparar la gestin de los cambios: captulo Los procesos de la transicin de servicios

- Gestin de cambios.
2. Requisitos previos
Antes de establecer el centro de servicios, se deben iniciar los siguientes procesos, aunque
no necesariamente finalizarlos:
Gestin de la estrategia.
Gestin del porfolio de servicios.
Gestin de los activos y configuraciones.
Gestin de los niveles de servicios
Gestin de cambios
Gestin de incidencias.
Gestin de problemas (fundamentalmente, gestin de la base de errores conocidos).
3. Los diferentes tipos del centro de servicios

El centro se servicios se llama SPOC (Single Point of Contact) porque permite al usuario
acceder al conjunto de los servicios especializados, usando un punto de contacto nico.
Se pueden distinguir los siguientes cuatro tipos de centro de servicios.
4. El centro de servicios local

El centro de servicios tiene a cargo las llamadas de los usuarios procedentes de la ubicacin
en la que est instalado.
Centro de servicios local

Este tipo de centro es prctico mientras la empresa no tenga demasiadas ubicaciones; en
caso contrario, esto implica una multiplicacin de las competencias y los recursos para cada
ubicacin.
Inconvenientes
En este tipo de organizacin, no hay capitalizacin posible entre los empleados presentes
en las dos ubicaciones.
Tampoco es posible que una ubicacin absorba una sobrecarga puntual de otra segunda
ubicacin. Esta sobrecarga se podra deber a una incidencia tcnica, una ausencia no
planificada de un tcnico o a cualquier otro motivo.
5. Centro de servicios centralizado

El centro de servicios est implantado en una ubicacin central y recibe las llamadas de los
usuarios de las diferentes ubicaciones de la empresa.
Este tipo de centro permite un mejor uso de los recursos disponibles, una reduccin de los
costes operativos y contribuye a mejorar la visibilidad del conjunto de la gestin.
Centro de servicios centralizado

La nocin de SPOC sigue siendo vlida para el usuario, ya que este accede al conjunto de
los servicios especializados, usando para ello un punto de contacto nico.
6. Centro de servicios virtual

El centro de servicios se implanta en diferentes ubicaciones que pueden estar repartidas en
uno o varios pases o continentes. Sin embargo, los usuarios solo ven el centro de servicios
virtual.
El funcionamiento de estos centros se basa en el uso de tecnologas de telecomunicaciones
de mayor rendimiento y el uso de redes de banda ancha.
Los centros se pueden establecer en funcin de varios criterios:
Idiomas hablados.
Aplicaciones implicadas.
Centro de servicios virtualizado

Este tipo de centros, como el centro de servicios centralizado, permite un mejor uso de los
recursos disponibles, una reduccin de los costes operativos y contribuye a mejorar la
visibilidad del conjunto de la gestin.
La nocin de SPOC sigue siendo vlida para el usuario, ya que accede al conjunto de los
servicios especializados, usando para ello un punto de contacto nico.
7. Centro de servicios Follow the sun

Las organizaciones internacionales pueden combinar el modelo de centro de servicios
virtual con una nocin de desfases horarios.
El centro de servicios se implanta en diferentes ubicaciones, que pueden estar repartidas
en uno o varios pases o continentes. De esta manera, algunas veces se utiliza el trmino
de centro de servicios Follow the sun, para recordar que el acceso al centro de servicios
es posible durante las 24 horas del da.
Sin embargo, los usuarios solo ven el centro de servicios virtual.
El funcionamiento de estos centros se basa en el uso de tecnologas de telecomunicaciones
de mayor rendimiento y el uso de redes de banda ancha.
Los centros se pueden establecer en funcin de varios criterios:
Idiomas hablados.
Aplicaciones implicadas.
Desfases horarios.
Uno de los beneficios de este tipo organizaciones es que los equipos de soporte del centro
de servicios trabajan en horarios normales, cuyo coste de explotacin es menor.
Centro de servicios Follow the Sun
8. Externalizar el centro de servicios

a. Por qu externalizar el centro de servicios?
Hoy en da, un nmero importante de empresas han elegido externalizar su centro de
servicios.
Esta solucin responde, en general, a una estrategia de externalizacin total o parcial de la
actividad informtica.
Una ventaja importante de esta solucin es que la empresa subcontratada est obligada a
obtener resultados. Esta obligacin de resultados se debe trasladar correctamente al
contrato de externalizacin del servicio, contrato de tipo UC (ver captulo Los procesos del
diseo de los servicios - Gestin de los niveles de servicio).
Este tipo de soluciones pueden ser interesantes para pequeas o medianas estructuras, ya
que las inversiones, tanto en hardware como en software, relativas a las herramientas de
gestin de incidencias y problemas se pueden agrupar a nivel de subcontratacin.
Adems, esta solucin tambin permite resolver un problema interno de competencias
informticas.
b. Los riesgos de la externalizacin

La eleccin de la externalizacin de un centro de servicios es una decisin particularmente
importante para la empresa.
En efecto, en el marco de una externalizacin, la empresa acepta confiar a otra empresa el
cuidado de la gestin de una parte de su informtica y, por tanto, de una parte de sus
competencias.
Esto es importante, ya que las competencias de las personas de la organizacin TI forman

parte de los activos de la empresa (ver el captulo Los procesos de la transicin de los
servicios - Gestin de los activos de servicios y configuraciones, para la definicin del
trmino Activo).
Por lo tanto, esta decisin implica la aceptacin por parte de la empresa de la prdida de
parte de sus activos, al menos temporalmente.
Por otra parte, la empresa debe tener en cuenta que esta decisin se puede modificar en
cualquier momento.
Por lo tanto, ser necesario prever en el contrato con el proveedor una clusula de marcha
atrs, tambin llamada clusula de reversibilidad.
En esta clusula, el proveedor se debe comprometer a transmitir a la empresa el conjunto
del conocimiento desarrollado y, si es necesario, las herramientas especficas desarrolladas
para asegurar el servicio durante el periodo en el que el servicio ha estado bajo su
responsabilidad.
Durante esta prestacin, la empresa se debe asegurar de que el proveedor respeta este
compromiso y que pone en marcha los medios necesarios que permitan esta vuelta atrs.
9. El funcionamiento del centro de servicios

a. Registro de la informacin por el centro de servicios, nocin de ticket
Una de las obligaciones del centro de servicios es registrar el conjunto de informacin que
le ha sido transmitida, tanto por parte de los clientes/usuarios como por el hardware o el
software.
Para registrar esta informacin, el centro de servicios va a utilizar un software de
tratamiento de llamadas.
La creacin de un registro genera un ticket, al que se hace referencia por medio de un
identificador nico, que servir posteriormente para asegurar que se trazan de manera
correcta las diferentes acciones realizadas para el tratamiento de este registro, y para la
comunicacin con el cliente o usuario.
Se debe proporcionar este identificador a la persona que est en el origen de su creacin.
Existen diferentes tipos de ticket:
Incidencia
Problema
Peticin de servicio
Peticin de informacin
Alerta (recuperada por el hardware o el software)
b. Los medios tcnicos del centro de servicios

El centro de servicios debe disponer de una herramienta con buen rendimiento, capaz de
realizar el conjunto de operaciones que permitan atender y hacer el seguimiento de las
llamadas de los usuarios.
Atencin: el programa de certificacin puesto en marcha actualmente por APMG y OGC ha

permitido certificar las primeras herramientas.
Sin embargo, varios fabricantes de software han optado por tener en cuenta las
recomendaciones ITIL con el objetivo de que sus herramientas respeten de manera ms
fiable las mejores prcticas de ITIL.
El trmino Compliant ITIL no es en absoluto una garanta de que la herramienta le
permita realizar el conjunto de operaciones descritas en ITIL V3.
Por ejemplo, podemos observar que ciertos programas de software solo tienen en cuenta
los servidores en la CMS; cmo se gestiona en este caso la nocin de CI a nivel de los
puestos de trabajo o del software?
Las herramientas utilizadas deben permitir el registro de los diferentes elementos tiles y
necesarios para el tratamiento de la llamada de un usuario o de un miembro del equipo
informtico (incidencia, problema y peticin de servicio), o de la generacin de un evento
por parte del hardware o el software.
Especialmente, la herramienta de gestin de las llamadas debe permitir la definicin de la
prioridad de la llamada, en funcin de los criterios establecidos en el contrato de servicio
(urgencia e impacto).
Tambin debe permitir hacer el seguimiento del tiempo transcurrido con el objetivo de
respetar los plazos de tratamiento definidos en el contrato de servicio en funcin de la
prioridad.
Esta herramienta debe proporcionar la posibilidad de elaboracin de estadsticas.
c. Los medios humanos del centro de servicios

El centro de servicios es el punto de centralizacin de los equipos tcnicos de soporte.
Los empleados se deben organizar en equipos, que deben adaptarse para tener en cuenta
los horarios definidos en los contratos de niveles de servicio.
Pueden existir equipos de diferentes niveles de soporte, en funcin del tamao de la
empresa.
Atencin: en ITIL, el centro de servicios se ve como una funcin. Los empleados del
centro pueden tener un rol en los procesos de incidente o problema.
d. La comunicacin del centro de servicios

El establecimiento del centro de servicios es un acto fundador, originado por la puesta en
marcha de una estrategia ITIL en la empresa.
El centro de servicios es el punto de entrada para los clientes del servicio informtico; no
olvide que los clientes del servicio informtico pueden ser personas internas de la empresa,
aunque tambin clientes de la empresa, si proporciona a sus clientes los medios
informticos.
El centro de servicios tambin es un escaparate de los servicios informticos.
Por este motivo, la comunicacin se debe definir claramente y adaptar al entorno de la

empresa.
Por lo tanto, es importante preparar correctamente la comunicacin del centro de
servicios.
El responsable del centro de servicios debe definir una poltica real de marketing de los
servicios ofrecidos por el centro. Esto es importante, ya que la comunicacin se deber
realizar en la fase inicial de la puesta en marcha, pero tambin de manera regular
posteriormente.
La apertura de un centro de servicios debe estar marcada por una importante comunicacin
hacia los clientes y usuarios, as como hacia el conjunto del personal de la organizacin.
En esta comunicacin, la oferta de servicios debe ser clara, precisa y comprensible para
todos los futuros usuarios.
Se pueden utilizar varios canales:
Envo por buzoneo (en papel o electrnico).
Envo de un documento de ayuda (en papel).
Envo de un objeto que permita la memorizacin del nmero de llamada o una

direccin de correo electrnico.
Direccin de correo de la Direccin General...
e. Comunicacin del estado de los tickets creados por los clientes o usuarios
Los clientes o usuarios pueden presentar sus peticiones por diferentes medios, segn las
tecnologas que se hayan puesto en marcha en el centro de servicios.
Estas tecnologas pueden permitir:
Una llamada telefnica.
Un fax.
Un correo electrnico.
Una entrada directa de la peticin por medio de un formulario o un acceso directo a

la herramienta.
Un acceso Web...
A lo largo del ciclo de vida de un ticket, el cliente o usuario debe poder, en todo momento,
conocer el estado de su ticket.
Esto entra en la categora de la comunicacin necesaria para la satisfaccin del cliente o
usuario.
Para esto, los agentes del centro de servicios deben poder consultar, en cualquier
momento, las evoluciones de las acciones realizadas en el contexto del tratamiento de un
ticket que ha abierto un cliente/usuario.
El centro de servicios se debe comunicar de manera regular con el cliente o usuario.

Esta comunicacin es necesaria para el cierre de un ticket, algo que no se podr realizar sin
el acuerdo del cliente o usuario.
El centro de servicios tambin se debe comunicar con los otros procesos que se han puesto
en marcha en la empresa.

a. Beneficios
La puesta en marcha de un centro de servicios permite hacer un seguimiento mejor de las
incidencias informticas.
Tambin permite mejorar el rendimiento del conjunto de los empleados de la empresa, ya
que les da una respuesta rpida y, por tanto, limita el tiempo perdido a causa de las
incidencias informticas.
Durante la puesta en marcha de un centro de servicios, pueden aparecer una serie de
dificultades o inconvenientes.
La primera dificultad que puede encontrar es la comunicacin.
Si no establece un sistema de comunicacin slido, con el apoyo de la direccin de la
empresa y de la organizacin TI, no obtendr la adhesin de los usuarios.
La segunda dificultad es la identificacin de los futuros tcnicos y su formacin.
Estas son, sin duda, las dificultades ms frecuentes.
Procesos
La explotacin de servicios est formada por cinco procesos. Los ms importantes son la
gestin de incidencias y la gestin de problemas.
Los otros tres procesos son la gestin de eventos, de consultas y de accesos.
Estos cinco procesos se detallan a continuacin.
Gestin de eventos
1. Enfoque
En esta seccin, vamos a ver cmo se gestionan los eventos en la explotacin de servicios.
En la seccin anterior hemos visto la aplicacin del centro de servicios.
Un evento se puede considerar como un cambio de estado, que tiene un sentido para un
elemento de configuracin (CI) o para un servicio.
La eficacia de un servicio depende del conocimiento de la infraestructura y la capacidad
para identificar una desviacin con respecto a una situacin normal o esperada.
Esto es posible con una cuidadosa supervisin y un sistema de control basado en dos tipos
de herramientas, supervisin activa y supervisin pasiva.
2. Objetivo del proceso

El objetivo principal del proceso de gestin de eventos es identificar los eventos, darles un
sentido y determinar las acciones ms importantes.
Los objetivos de la gestin de eventos son los siguientes:
Detectar cualquier cambio de estado que tenga algn sentido para un elemento de
configuracin (CI) o para un servicio.
Determinar las acciones de control para los eventos y asegurar la comunicacin con
las funciones adecuadas.
Suministrar un punto de entrada para la ejecucin de varios procesos de las

operaciones y actividades de control.
Suministrar los medios de comparar el rendimiento real de funcionamiento y el

comportamiento opuesto a las normas de diseo y al contenido de los acuerdos de
servicios SLA.
Suministrar una base para crear informes.
3. Permetro
El permetro de la gestin de eventos se aplica a todas las actividades de la gestin de
servicios que necesitan un control automatizado. Esto incluye la gestin de los CI y el
entorno fsico, la gestin de licencias, la seguridad y las operaciones diarias.
4. Indicadores
Nmero de eventos de tipo alerta.
Nmero de eventos de tipo excepcin.
Nmero de eventos de tipo entorno.

El proceso de gestin de eventos
6. Conceptos bsicos
a. Diferentes tipos de evento
Existen tres tipos de eventos:
Evento de tipo informacin.
Evento de tipo alerta.
Evento de tipo excepcin.
Evento de tipo informacin

Estos son los eventos que afectan a las actividades regulares y normales dentro de la
gestin de servicios.
Este tipo de evento no activa ninguna accin particular.

Por ejemplo: un usuario que se conecte a una aplicacin o una tarea que empieza o
termina con normalidad.
Evento de tipo alerta
Estos son los eventos que se producen cuando se sobrepasa un umbral. Estos umbrales se
definen en la herramienta de gestin de eventos o en los SLA u OLA.
Este tipo de evento necesita, de manera regular, la intervencin de un operador.
Por tanto, este tipo de evento se transmite al responsable designado de la actividad.
En algunos casos, este tipo de evento puede generar una incidencia.
Por ejemplo: un umbral de uso del espacio en disco superior al 70% o el tiempo de
respuesta de una transaccin superior al 10% del tiempo definido.
Evento de tipo excepcin
Estos son los eventos relacionados con una situacin excepcional.
Por ejemplo: un umbral de uso del espacio en disco superior al 90%, una transaccin no
terminada o un intento de conexin a una aplicacin con un usuario o una contrasea
incorrectos.
Gestin de las incidencias

1. Enfoque
En esta seccin vamos a ver cmo se gestionan las incidencias en el seno del centro de
servicios.
En la seccin anterior hemos visto la puesta en marcha de un centro de servicios.
Cuando una empresa decide poner en marcha ITIL, normalmente el proceso incidencia es
uno de los primeros en activarse, despus de la puesta en marcha de un centro de
servicios, ya que esto permite iniciar progresivamente la estrategia ITIL.
Tambin veremos cmo se tratan los eventos y las peticiones, ya que las segundas llegan al
centro de servicios y se tienen en cuenta por el proceso de incidencia inicialmente.
2. Por qu una gestin de incidencias?

Independientemente de cul sea la calidad de los servicios proporcionados por la
organizacin TI, es inevitable que se produzcan incidencias. En efecto, no es realista
pretender producir un servicio que garantice su funcionamiento sin ninguna incidencia, ya
que esto hara necesario realizar pruebas en un entorno idntico al de la explotacin, lo que
hace necesario a su vez tener que prever todos los escenarios posibles.
Por otra parte, no hay que olvidar nunca que un error humano siempre es posible y que
este se halla en el origen de un porcentaje nada despreciable de las incidencias...
Cuando no hay gestin de incidencias, el usuario, en caso de un funcionamiento incorrecto
de su puesto de trabajo o de la aplicacin que utiliza, tender a molestar a sus compaeros
para resolver este funcionamiento incorrecto. Esto tendr un impacto sobre la actividad de
la persona, pero tambin de sus compaeros. Si, a pesar de la ayuda de sus compaeros,
el usuario no soluciona el funcionamiento incorrecto, contactar con los tcnicos. La
interrupcin de un tcnico en su trabajo tambin tendr un impacto sobre su efectividad.
Adems, como no hay ningn registro del funcionamiento incorrecto ni sobre las causas o
solucin propuesta, no puede haber capitalizacin sobre esta intervencin.
Finalmente, como no hay un seguimiento, ser imposible determinar la criticidad de una
incidencia aislada, pero que podra evolucionar y convertirse en una crisis ms o menos
grave.
Sin embargo, si se ha puesto en marcha una gestin de incidencias, se pueden identificar
varios puntos positivos:
Reactividad: el usuario puede acceder rpidamente a un tcnico que le proporcione

asistencia. Menos prdida de tiempo para el usuario y tambin para sus compaeros,
a los que no molestar ms.
Eficacia de un tcnico: ya no se le molesta durante una actividad planificada.
Capitalizacin del saber: si se registra una incidencia, en caso de que vuelva a

parecer una incidencia del mismo tipo, el conjunto de tcnicos del servicio sabrn lo
que conviene hacer, lo que ahorra tiempo en el tratamiento de las incidencias y
minimiza la prdida de tiempo por parte del usuario.
Prevencin: ser posible identificar correctamente una incidencia menor antes de que
se convierta en crtica, con el riesgo de que esto provoque una situacin de crisis.
Atencin: el personal deber tener la formacin necesaria para poder realizar una misin
de soporte telefnico. No es suficiente con ser un excelente tcnico para poder hacerse
cargo de una llamada telefnica de un usuario. Es imprescindible que el personal que trata
las incidencias, adems de sus competencias tcnicas, tenga capacidad de relacin y sepa
mostrar empata durante el tratamiento de una llamada. La seleccin y formacin del
personal ser, por lo tanto, muy importante.
3. Objetivo del proceso

El objetivo principal del proceso de gestin de incidencias es:
Restaurar un servicio operativo tan rpido como sea posible, minimizando el impacto en la
empresa y asegurando que se mantienen los niveles de servicio y disponibilidad
acordados.
El funcionamiento normal de un servicio se define como el funcionamiento del servicio
dentro de los lmites acordados de servicio (SLA).
Tambin hay que tener en cuenta otros objetivos:
Asegurar que se usan los mtodos estandarizados y los procedimientos, para

garantizar una respuesta rpida y eficaz.
Aumentar la visibilidad de las incidencias y comunicacin entre el negocio y la

organizacin de los TO.
Mantener la satisfaccin del cliente en relacin con la calidad de los servicios de TI.
4. Definiciones
La definicin de incidencia es la siguiente:
Todo evento operativo que no forma parte de las operaciones estndares de un sistema,
que provoca o pueda provocar una interrupcin del servicio o una alteracin de su calidad.
La definicin de evento es la siguiente:
Un cambio de estado que tiene un significado para la gestin de un componente de
configuracin (CI) de un servicio informtico.
La definicin de alerta es la siguiente:
Una advertencia que indica que se ha alcanzado un umbral, ha cambiado alguna cosa o se
ha producido un error.
La definicin de peticin de servicio es la siguiente:
Una peticin por parte de un usuario de informacin, un consejo para un cambio estndar
o para el acceso a un servicio informtico, por ejemplo, restaurar una contrasea o
proporcionar un servicio informtico estndar para un nuevo usuario.
5. Permetro
La gestin de incidencias trata las incidencias reportadas por:
Los usuarios (por medio del centro de servicios).
El personal tcnico.
La supervisin tcnica.
Algunos ejemplos de incidencias:
A nivel de hardware:
Puesto de trabajo averiado.
Impresora no operativa.
Recurso no disponible o inaccesible.
Alerta o excepcin generada automticamente por un componente del sistema.
A nivel de aplicacin:
Servicio no disponible.
Funcionamiento incorrecto de la aplicacin.
Pregunta sobre la utilizacin del servicio.
6. Roles y funcin
Entre los roles encontramos:
Los grupos de primer y, ocasionalmente, de segundo y tercer nivel (si existen), as

como los grupos de expertos.
El responsable de incidencias.
En cuanto a la funcin, hallamos la de gestor del centro de servicios.
7. Indicadores
Se pueden establecer varios indicadores para medir el funcionamiento del proceso:
Nmero de incidencias creadas.
Nmero de incidencias resueltas en el primer contacto.
Duracin media del tratamiento de una incidencia.
Nmero de incidencias tratadas sin contar los retrasos de las SLA.
Nmero de incidencias escaladas.
se ponga en marcha.
El proceso de gestin de incidencias
9. Conceptos bsicos
a. El ciclo de vida de una incidencia
El tratamiento de una incidencia se desarrolla en varias etapas. Normalmente se habla del
ciclo de vida de una incidencia.
Las peticiones de servicios, consultas y eventos se tratan por medio del centro de servicios
y se registran en el mbito del proceso de gestin de incidencias.
En el mbito de la gestin de incidencias, tambin abordaremos las nociones de escalado e
incidencia principal.
El ciclo de vida de las incidencias

Ahora vamos a ver en detalle cada una de las etapas del ciclo de vida.
b. Registro de una incidencia

La primera etapa del tratamiento de una incidencia consiste en registrarla en la
herramienta de gestin que se ha puesto en marcha en el centro de servicios.
Se deben registrar todas las incidencias, sin excepcin. En caso contrario, no ser posible
conocer realmente la actividad de los equipos del centro de servicios, ni hacer un
seguimiento en caso de llamada de un usuario.
En esta etapa, el tcnico debe identificar al solicitante.

Si ya se ha puesto en marcha el proceso de gestin de los activos y configuraciones
(SACM), ser posible encontrar sus datos en la herramienta de gestin de incidencias, a
partir de su nombre o de su identificador. Sin embargo, el tcnico deber validar con el
usuario la exactitud de la informacin.
En caso contrario, corresponder al tcnico registrar el conjunto de datos del usuario.
c. Clasificacin
Esta es, sin duda, la etapa ms importante en la gestin de incidencias.
La categorizacin
Permite determinar cul es el hardware, servicio o personas implicadas en la incidencia y el
nivel de prioridad que le ha sido asignado.
El tcnico ser capaz de categorizar la incidencia por medio del interrogatorio al usuario.
Atencin: el usuario describe, en general, los sntomas que ha identificado, pero estas no
son obligatoriamente las causas de la incidencia. Por lo tanto, es posible que la
categorizacin evolucione durante el tratamiento de la incidencia.
La categorizacin nos va a ayudar a identificar cul es el SLA que se debe tener en cuenta
para definir la prioridad de la incidencia.
Esta categorizacin va a permitir identificar el grupo de soporte al que se debe dirigir la
llamada, en la medida en que el tcnico no sea capaz de tratarla l mismo.
Durante esta etapa, el tcnico identificar, si es posible, el elemento de configuracin
(Configuration Item - CI) implicado.
Durante esta etapa, el tcnico identificar si la peticin es de servicio. En este caso, la
peticin se tratar por el procedimiento de tratamiento de peticiones de servicio.
Muchas incidencias son recurrentes y, en este caso, las causas y las soluciones pueden ser
conocidas.
Por este motivo, es posible que durante esta etapa el tcnico necesite consultar la base de
problemas y errores conocidos.
Si se identifican los elementos comunes, se podr poner en prctica rpidamente la
solucin definitiva o una temporal.
En caso contrario, implicar bsqueda y diagnstico por el grupo de soporte que se
encargar de la incidencia.
La priorizacin
La priorizacin se lleva a cabo basndose en dos parmetros:
El impacto.
La urgencia.
Estos parmetros se deben definir en el contrato de servicios (Service Level Agreement SLA).
En funcin de estos dos parmetros, se puede definir una tabla de asignacin de
prioridades.
La combinacin de estos dos parmetros va a permitir definir la prioridad de la incidencia.
Tabla de definicin de prioridades

Esta tabla de asignacin debe indicar los plazos de resolucin previstos.
Esta tabla debe estar a disposicin de los tcnicos.
Hoy en da, la mayor parte de las herramientas de gestin de llamadas permiten integrar
esta tabla en la configuracin de la herramienta.
La prioridad de una incidencia siempre se debe determinar a partir de esta tabla. El usuario
no debe decidir el nivel de prioridad de su llamada. En caso de que el usuario proteste por
el nivel de prioridad, el tcnico no debe faltar a la regla y deber elevar la protesta a sus
superiores.
El impacto
El impacto de una incidencia se determina en funcin de criterios definidos en el contrato
de servicios (SLA).
El impacto de un funcionamiento incorrecto no es el mismo si este afecta a un puesto de

trabajo o a un servidor.
Del mismo modo, en trminos de software, si el funcionamiento incorrecto afecta a una
aplicacin administrativa, el impacto no ser el mismo que si afecta a una aplicacin
empresarial.
El nmero de usuarios afectados tambin se tiene en cuenta en la definicin del impacto.
Generalmente se definen un mnimo de tres niveles:
Alto: afecta a un nmero importante de usuarios o est implicada una aplicacin

principal.
Medio: afecta a un nmero limitado de usuarios o est implicada una aplicacin

estndar.
Bajo: afecta a un nico usuario o a muy pocos o est implicada una aplicacin
administrativa.
Los diferentes niveles se deben definir para cada servicio en el mbito del SLA.
La urgencia
La urgencia tambin se define en el SLA. Generalmente se establecen un mnimo de tres
niveles:
Alto: es una aplicacin o un equipo crtico.
Medio: es una aplicacin o un equipo no crtico.
Bajo: el usuario puede continuar trabajando, aunque de forma no ptima.
La prioridad
Es necesario definir en qu plazo se debe restablecer el servicio.
Se construye una tabla de prioridad a partir de los parmetros de impacto y urgencia.
Es preciso definir los plazos de restablecimiento del servicio en relacin con el nivel de
prioridad.
Adicionalmente a los niveles de prioridad definidos a partir del impacto y la urgencia, se

puede definir un nivel de prioridad sin que tenga asociado un plazo de restablecimiento del
servicio. En este caso, se debe planificar la intervencin e informar al usuario del plazo de
planificacin.
d. Incidencia principal
Ms all de la priorizacin de una incidencia, existen circunstancias para las que es
necesario tomar medidas particulares. Por ejemplo, en caso de que la red de comunicacin
de la empresa sea totalmente inaccesible para todos los usuarios.
En este tipo de situaciones, se califica la incidencia como incidencia principal.
Esto significa que se va a activar un procedimiento particular con el objetivo de tratar la

incidencia lo ms rpido posible, poniendo en prctica los recursos adecuados a una
situacin como esta. Esto se puede parecer a lo que se conoce generalmente como una
situacin crtica.
e. Escalado
Existen dos casos de escalado. Uno de ellos forma parte del tratamiento normal de una
incidencia y el otro es, y debe seguir siendo, excepcional.
Esquema de la gestin del escalado

Escalado funcional: es el envo de una incidencia a un nivel de asistencia superior, debido
principalmente a la falta de conocimiento o experiencia de un tcnico, o porque ha
transcurrido el plazo de tiempo acordado en el SLA para tratar la incidencia o est prximo
a terminar.
Generalmente, las herramientas de gestin de incidencias actuales permiten desencadenar

este escalado funcional de manera automtica, en funcin de los plazos previstos en el
SLA.
En este tipo de escalado, las incidencias cambian de propietario.

Escalado jerrquico: enfoque adoptado durante una actividad cuando es probable que la
resolucin de una incidencia no se realice a tiempo o no vaya a ser satisfactoria. Los
encargados de la gestin deben tomar rpidamente la decisin apropiada.
Este tipo de escalado tambin se pone en marcha cuando un cliente solicita una
modificacin de la prioridad asignada a su incidencia.
En este tipo de procesos de escalado, las incidencias no cambian de propietario.
f. Investigacin y diagnstico
Durante esta fase, el tcnico llevar a cabo las investigaciones necesarias para determinar
las verdaderas causas de la incidencia.
Para ello, preguntar al usuario y consultar las bases de datos que tiene a su disposicin.
Entre ellas se encuentran las bases de datos de problemas y errores.
Es importante tener informado al cliente durante esta fase y, cuando sea posible, ofrecerle
una solucin temporal. Por ejemplo, para una incidencia relacionada con una impresora, se
le puede proponer imprimir en otra impresora.
No hay que olvidar el objetivo del proceso de gestin de incidencias: minimizar el impacto
sobre el servicio.
Todas las investigaciones y operaciones llevadas a cabo durante esta fase se debern
registrar en la herramienta de gestin de incidencias para garantizar su trazabilidad, as
como para permitir un anlisis global de las incidencias, que se llevar a cabo en el proceso
de la gestin de problemas.
g. Resolucin
La resolucin de la incidencia se puede llevar a cabo basndose en una solucin aportada
por:
El centro de servicios.
Un grupo de soporte.
La gestin de problemas.
Un RFC.
La informacin relativa a las operaciones puestas en prctica para la resolucin de la

incidencia se deben registrar en la herramienta de gestin de incidencias.
h. Cierre
En principio, cualquier incidencia se puede cerrar sin el consentimiento de la persona que

est en el origen de la incidencia.
En la realidad, ser necesario establecer excepciones, ya que no es posible mantener
abiertas las incidencias ms all de un cierto tiempo.
Por ejemplo, una de las opciones utilizadas en algunas empresas es considerar que, en
caso de no obtener respuesta de un usuario contactado por correo electrnico, el ticket se
cierra de manera administrativa.
La ausencia de respuesta puede ser consecuencia de varios factores: ausencia de larga
duracin, baja en la empresa...
En esta fase, el centro de servicios se debe asegurar de que el registro de las diferentes
acciones realizadas durante el tratamiento de la incidencia se ha hecho correctamente en la
herramienta de gestin de incidencias.

a. Beneficios
La gestin de incidencias no debera ser un centro de coste. Es un centro de beneficios para
la empresa.
El coste del centro de servicios y la gestin de incidencias siempre es compensado por las
ganancias en productividad que aporta a la empresa: disminucin de la no disponibilidad
del personal, del nmero de incidencias y gestin proactiva de estas.
La principal dificultad es convencer a todos los usuarios de que utilicen el centro de
servicios y, por lo tanto, la gestin de incidencias.
La segunda es convencer a los tcnicos para que registren todas las incidencias, aunque el
tiempo de entrada de datos en la herramienta sea varias veces superior al tiempo que lleva
la respuesta al usuario.
Si no se registra el conjunto de incidencias, ser difcil demostrar que el centro de servicios
es un centro que genera beneficios.
Gestin de problemas
1. Enfoque
En esta seccin vamos a ver cmo se gestionan los problemas.
En la seccin anterior hemos visto la gestin de incidencias.
Como el proceso incidencia, el proceso gestin de problemas es, a menudo, uno de los
primeros en aplicarse, despus del centro de servicios y de la gestin de incidencias, ya
que permite iniciar gradualmente la estrategia ITIL.
2. Por qu una gestin de problemas?

El objetivo principal del proceso de gestin de incidencias es restaurar lo ms
rpidamente posible un servicio normal y minimizar el impacto sobre las aplicaciones de
negocio.
Este objetivo es el que no permite, en general, que gestin de incidencias busque la causa
subyacente desconocida de las incidencias.
Por lo tanto, es necesario confiar a otro proceso la responsabilidad de buscar esta causa
original, lo que puede llevar tiempo.
Atencin: habitualmente se habla de causa desconocida, causa subyacente

desconocida, causa inicial o causa primera para definir la causa de un funcionamiento
incorrecto en la prestacin de un servicio o de la incidencia. Todos estos trminos tienen el
mismo significado y valor.

El objetivo principal del proceso de gestin de problemas es:
Minimizar el impacto en la empresa durante las incidencias y problemas derivados de
errores en la infraestructura, y prevenir la aparicin de incidencias, problemas y errores, de
forma proactiva.
Para ello, el proceso tiene por objetivo identificar la causa raz del funcionamiento
incorrecto y de las incidencias, mitigar su impacto y encontrar, si es posible, una solucin
rpida y definitiva que impida la reproduccin de estos funcionamientos incorrectos e
incidencias.
Cuando sea posible, la gestin de problemas puede, en un primer momento, proporcionar
una solucin temporal, antes de buscar una solucin definitiva.
Esto debera permitir la vuelta al funcionamiento normal del servicio.
El proceso es reactivo y proactivo al mismo tiempo, en funcin de la actividad implicada.
Se proporcionan explicaciones detalladas en la seccin Gestin de problemas - Conceptos
bsicos.
Recordatorio: el funcionamiento normal de un servicio se define como un funcionamiento

dentro de los lmites acordados del servicio (SLA).
4. Definicin
La definicin de problema es la siguiente:
Un problema es la causa subyacente desconocida de una o varias incidencias.
5. Permetro
La gestin de problemas trata todos los problemas reportados por:
La gestin de eventos.
La gestin de incidencias.
La gestin de problemas tambin debe:
Llevar a cabo una actividad de seguimiento y control de las incidencias.
Tener una actividad de control de errores.
Realizar una gestin proactiva de los problemas.
6. Roles
Entre los roles se encuentran:
Los grupos de tercer nivel, si existen, as como los grupos de expertos.
El responsable de problemas.
7. Indicadores
Nmero de problemas creados.
Nmero de problemas importantes.
Nmero de errores conocidos, registrados en la base de datos de errores.
Nmero de problemas resueltos en el periodo.
Duracin media del tratamiento de un problema.
Nmero de problemas tratados ms all de los plazos acordados en los SLA (si se
han definido).
Nmero de RFC remitidos a la gestin de cambios.
Nmero de RFC cerrados sin generacin de incidencia o de un nuevo problema.
se establezca.
El proceso de gestin de problemas
9. Conceptos bsicos
a. El ciclo de vida de un problema
El ciclo de vida de un problema est relacionado con el ciclo de vida de las incidencias.
Normalmente, una o varias incidencias estn relacionadas con el origen de un problema.
Como se seala en la gestin de incidencias, el objetivo de este proceso es restaurar el
servicio normal en el menor tiempo posible. Para ello, es esencial que el centro de servicios
cuente con una base de conocimientos documentados (base de datos de errores
conocidos), para ayudar en un diagnstico rpido. La puesta al da de la base de datos es
una de las actividades de la gestin de problemas.
El siguiente diagrama muestra la relacin entre el proceso de gestin de incidencias y el

proceso de gestin de problemas, incluida la actualizacin de la base de datos de errores
conocidos, as como la creacin de un RFC.
El ciclo de vida de los problemas
b. Las actividades de la gestin de problemas

Las principales actividades de la gestin de problemas son las siguientes:
Gestin de problemas.
Control de errores.
Gestin proactiva de problemas.
Gestin de problemas
La gestin de problemas tiene un rol importante en la prestacin de servicios. Permite
identificar el CI o los CI (Configuration Item) responsables del mal funcionamiento.
Identificar las causas principales de una o varias incidencias puede permitir limitar el
nmero de estas, en particular en el caso de incidencias recurrentes, proporcionando una
solucin definitiva.
Algunas veces, la gestin de problemas puede entrar en colisin con el objetivo de la
gestin de incidencias: restaurar el servicio normal lo ms rpidamente posible.
De hecho, algunas veces es necesario tomar un tiempo para identificar y analizar la causa
raz de un problema. Esto significa congelar el estado del CI el tiempo que dura este
anlisis, lo que va en contra del objetivo de la gestin de incidencias. Por lo tanto, ser
necesario recurrir al arbitraje para decidir qu actitud tomar. En caso de recurrencia de las
incidencias, la decisin adecuada consistir en tomar el tiempo til y necesario para realizar
este anlisis.
La gestin de problemas tambin depende mucho de las acciones de la gestin de
incidencias. Es imprescindible que el conjunto de acciones realizadas para el tratamiento de
una incidencia (prueba, soluciones temporales, arreglos temporales...) se registren para
que el anlisis preliminar realizado por la gestin de problemas pueda ser eficaz. Tambin
es primordial que la gestin de incidencias identifique los CI afectados o implicados en la
incidencia.
Control de errores
Control de errores
El objetivo del control de errores es identificar, evaluar, supervisar los errores y, cuando sea
posible y econmicamente interesante, eliminarlos.
Tratamiento de errores
Cuando se ha implementado con xito la RFC que se ha puesto en marcha para la gestin
de cambios, se puede cerrar el error y los problemas que tiene asociados.
Gestin proactiva de problemas

La gestin proactiva de problemas es una de las actividades importantes de la gestin de
problemas.
El objetivo de esta actividad es prevenir la aparicin de incidencias o de un funcionamiento
incorrecto en la prestacin de servicios.
Para ello, la gestin de problemas debe analizar, en intervalos regulares, las incidencias y
problemas.
Este anlisis debe permitir definir las tendencias e identificar los CI que potencialmente
pueden causar la aparicin de nuevas incidencias.
Este anlisis se puede completar con un anlisis de costes asociados a la resolucin de
incidencias.
Ver el anexo: las secciones Anlisis de Kepner y Tregoe y Diagrama de Ishikawa.

a. Beneficios
Uno de los beneficios principales de la gestin de problemas es la reduccin del nmero de
incidencias.
Tambin se obtendr una mayor correccin de incidencias en el centro de servicios y, al
mismo tiempo, los tcnicos se benefician de una base de datos de errores conocidos.
Por otro lado, el anlisis proactivo de tickets de incidencias puede resaltar los problemas
potenciales.
Todos estos elementos contribuyen a mejorar la disponibilidad del servicio.
La gestin de problemas necesita la identificacin y formacin continua de los tcnicos que
en general tienen un nivel tcnico superior al de los tcnicos del centro de servicios.
Posteriormente, es imprescindible separar las actividades de gestin de incidencias, de
aquellas que pertenecen a la gestin de problemas. Estos son dos procesos con objetivos
opuestos.
En una pequea empresa, los tcnicos deben tener conocimiento, en todo momento, del
proceso en el que van a trabajar, principalmente si son las mismas personas las que
aseguran la realizacin de las tareas.
Gestin de consultas
1. Enfoque
En esta seccin vamos a ver cmo se gestionan las consultas, tambin
llamadas peticiones de servicio, en el marco de la fase de explotacin de servicios.
Ya hemos visto en la seccin anterior la aplicacin del centro de servicios. La gestin de
consultas se asegura a travs del centro de servicios.
Existen varios tipos de consultas. Algunas son el objeto de una simple transmisin a un
equipo, grupo o funcin, mientras que otras necesitan un tratamiento ms importante o
largo.
La gestin de cambios estndar tambin se asegura a travs de este proceso.

El objetivo principal del proceso de gestin de consultas es responder a todas las
peticiones y preguntas que recibe el centro de servicios.
Los objetivos de la gestin de consultas son los siguientes:
Suministrar un canal a los usuarios para solicitar y obtener los servicios estndares,
para los que se han definido autorizaciones y cualificaciones.
Suministrar una informacin al cliente y a los usuarios de la disponibilidad de un

servicio y el procedimiento para obtenerlo.
Origen para entregar las peticiones de cambio estndares.
Mantener la satisfaccin del cliente y de los usuarios, a travs de un proceso

eficiente.
Tener en cuenta las reclamaciones de los usuarios o del cliente.
3. Permetro
El permetro de la gestin de consultas se aplica a todas las peticiones de los usuarios.
4. Indicadores
Nmero de consultas recibidas.
Nmero de consultas tratadas en modo excepcin.
Nmero de peticiones de cambio estndares.
Nmero de consultas rechazadas.
se aplique.
El proceso de gestin de problemas
6. Conceptos bsicos
Las consultas pueden afectar a diferentes actividades:
Peticin para el suministro de un equipamiento, con o sin autorizacin inicial.
Peticin para la instalacin de un software.
Peticin para obtener un acceso a una base de datos.
Peticin para la puesta en marcha de una peticin de cambio estndar.
Esta lista no es exhaustiva; conviene definir las peticiones en funcin de la estructura que
se aplique.
Una buena gestin de consultas implica, obligatoriamente, la puesta en marcha de

modelos.
Gestin de accesos
1. Enfoque
En esta seccin vamos a ver cmo se gestionan los accesos en el marco de la fase de
explotacin de servicios.
Hemos visto anteriormente la aplicacin del centro de servicios; la puesta en marcha de
este proceso est relacionada con el centro de servicios.

Los objetivos de la gestin de accesos son los siguientes:
Gestionar los accesos aplicando polticas de seguridad definidas en el proceso de

gestin de la seguridad.
Responder de manera eficaz a las peticiones para garantizar el acceso a los

servicios.
Modificar los derechos asociados a una peticin de accesos.
3. Permetro
El permetro de la gestin de accesos afecta a todas las peticiones de acceso, ya sean
accesos a un servicio o grupo de servicios, a bases de datos o redes, que necesiten un
control de accesos.
4. Indicadores
Nmero de peticiones.
Nmero de rescisiones.
Nmero de intentos fraudulentos.
El proceso de la gestin de accesos
6. Conceptos bsicos
El control de los accesos se basa en varias actividades:
Gestin de contraseas.
Asignacin de derechos de acceso.
Modificacin de derechos de acceso.
Eliminacin de derechos de acceso.
Acciones proactivas sobre los accesos.
La gestin de los accesos debe garantizar que solo los usuarios autorizados puedan acceder
a un servicio.
Tambin es imprescindible identificar los intentos de intrusin a travs de las redes.
Las tecnologas de identificacin de un usuario evolucionan constantemente.
Por lo tanto, ser imprescindible adaptarse a los mtodos con mejor rendimiento.
Las polticas de seguridad se definen en el proceso de gestin de la seguridad. El proceso

de gestin de los accesos pone en marcha estas polticas.
MEJORA CONTINUA DE SERVICIOS (CSI)

Enfoque
El ciclo de vida de la gestin del servicio se divide en varias fases.
El proceso de mejora continua de servicios (Continual Services Improvement) gestiona la
iteracin entre esas diferentes fases.
Un proverbio dice el que no avanza retrocede.
Por este motivo, es necesario que, de forma regular, por no decir constantemente, se
alineen de nuevo los servicios con las cambiantes necesidades del cliente y de la empresa.
Por qu un proceso de mejora continua de servicios?

Uno de los objetivos de la puesta en marcha de ITIL es proporcionar un valor aadido a los
servicios propuestos por la organizacin TI a sus clientes.
Para responder a este objetivo, es necesario poner en marcha un proceso que permita
medir y mejorar el nivel de madurez del servicio y los procesos.
Objetivos del proceso

Los principales objetivos del proceso de mejora continua de los servicios son los siguientes:
Analizar los resultados de los diferentes contratos (SLA, OLA y UC).
Identificar e implementar las reas de mejora para los servicios y procesos.
Mejorar la rentabilidad, sin disminuir el nivel de calidad.
Mejorar la relacin con el cliente.
Asegurar que los mtodos de gestin de la calidad son eficaces.
Definicin
ROI: Retorno de la inversin (Return On Investment).
VOI: Valor de la inversin (Value On Investment).
Valores intangibles: son los beneficios no expresados en valor econmico; por ejemplo,
la mejora de la satisfaccin del cliente, el aumento de la competencia de los actores de la
organizacin TI, la disminucin de los riesgos...
Permetro
Los procesos de mejora continua de los servicios implican al conjunto de la gestin de
servicios (procesos, servicios, organizacin, personal...).
El permetro abarca los servicios ofrecidos y los procesos internos.
Roles
Los principales roles son:
El responsable de la mejora continua de servicios.
Todos los dems responsables de procesos.
Todos los dems propietarios de procesos.
Propietario del servicio.
Indicadores
Se pueden aplicar varios indicadores:
Los KPI.
Los CSF.
Las bases de referencia.
La medicin de los servicios.
Las mtricas.
Descripcin del proceso
El proceso de mejora continua de servicios
Conceptos bsicos
El ciclo de vida de la mejora continua de servicios

El ciclo de vida de los servicios tiene las fases siguientes:
Definir la estrategia de gestin de servicios (Service Strategy - SS).
Disear de servicios para apoyar la estrategia (Service Design - SD).
Implementar los
Transition - ST).
Soportar los servicios de gestin de actividades operativas (Service Operation - SO).
servicios
para satisfacer los
requisitos
de
diseo (Service
1. Las relaciones con los otros procesos

El proceso de mejora continua de los servicios est relacionado con el conjunto de los
procesos.
Participa en todas las fases del ciclo de vida de los servicios.
2. El valor aadido al negocio

La mejora continua de los servicios aade valor al negocio a travs de:
Las mejoras.
Los beneficios.
Un retorno de la inversin.
Un valor de inversin.
Los valores intangibles.
3. Las herramientas para la mejora

Varias herramientas contribuyen a la mejora continua de los servicios.
Ya hemos visto algunas en los captulos anteriores:
La Rueda de Deming (en el captulo ITIL y las normas).
Las 4 P (en la seccin Consideraciones sobre el diseo de los servicios - captulo Los
procesos del diseo de los servicios).
Vamos a ver otras dos.
a. El modelo CSI
El enfoque Continual Service Improvement (CSI)

A la pregunta Adnde queremos ir?, corresponde una actividad que consiste en
identificar la visin que tenemos de los servicios y procesos.
A la pregunta Dnde estamos actualmente?, corresponde una actividad de evaluacin
de la situacin actual.
A la pregunta Dnde queremos estar?, corresponde una actividad de definicin de

objetivos medibles y la prioridad de las mejoras.
A la pregunta Cmo conseguir nuestro objetivo?, corresponde una actividad de puesta
en marcha de las acciones de mejora.
A la pregunta Cmo sabemos que hemos llegado?, corresponde una actividad de
verificacin de las medidas y de las mtricas aplicadas para asegurar que los objetivos
fijados se han alcanzado.
A la pregunta Cmo vamos a continuar?, corresponde una actividad de control, para
asegurar la eficacia del proceso de mejora continua de los servicios.
Ver tambin la descripcin en el captulo Puesta en marcha de un proyecto ITIL.
b. El proceso de mejora en 7 etapas
El proceso de mejora en 7 etapas

Etapa 1 - Identificacin de la estrategia para la mejora
Visin y estrategia
Necesidades de negocio
Estrategias
Objetivos tcticos
Objetivos operativos
Etapa 2 - Definir lo que vamos a medir

Etapa 3 - Recoger los datos
Qu
Cundo
Cmo
Criterios para evaluar la integridad de los datos
Objetivos operativos
Medir los servicios
Etapa 4 - Tratamiento de los datos
Frecuencia
Formato
Herramientas y sistema
Exactitud
Etapa 5 - Anlisis de los datos
Relaciones
Tendencias
Conforme con la planificacin
Objetivos alcanzados
Acciones correctivas
Etapa 6 - Presentacin y uso de la informacin
Evaluacin
Resumen
Planes de accin...
Etapa 7 - Poner en prctica las medidas correctivas
El proceso de mejora continua en siete etapas est directamente relacionado con los
objetivos estratgicos, tcticos y operativos. Mide los servicios y los procesos de gestin de
los servicios.
PUESTA EN MARCHA DE UN PROYECTO ITIL

Etapas preliminares
Antes de poner en marcha un proyecto ITIL, es necesario estar seguros de una serie de
puntos que garanticen una puesta en marcha exitosa:
Definicin del proyecto.
Ciclo de implantacin.
Eleccin de los procesos de puesta en marcha inicial.
La implantacin anterior de una certificacin ISO 9001 puede favorecer la implantacin de
un proyecto ITIL.
Definicin del proyecto

La primera actividad de la puesta en marcha de un proyecto ITIL consiste en definir cul es
la visin de la organizacin TI para la empresa.
Esta actividad es responsabilidad de la Direccin de la empresa.
La direccin de la organizacin, por supuesto, prepara un conjunto de documentos para
presentar el proyecto a la direccin de la empresa y, de esta manera, proporcionarle los
elementos que le permitirn tener en cuenta y apoyar el proyecto.
Esto plantea la cuestin de la gestin documental del proyecto desde el momento inicial y,
al final, la gestin documental de los procesos ITIL.
Una gestin documental rigurosa implica que se documenten las diferentes actividades del
proyecto y los procesos.
Para esto, es necesario poner en prctica en los documentos la gestin de los participantes,
definiendo fundamentalmente sus funciones: propietario del proceso, redactor, validador y
destinatario.
En el modelo RACI, el propietario del proceso se define como Accountable (ver en el
anexo la descripcin del modelo).
Es conveniente utilizar el trmino propietario del proceso en los documentos que
describen el proceso, salvo en el caso de la documentacin en ingls.
Tambin ser necesario definir y publicar un documento sobre la gestin de los derechos de
acceso, para que cada uno sepa quin est autorizado a hacer qu y cundo.
Como en toda gestin documental, ser necesario asegurar la gestin de las versiones de
los diferentes documentos, as como la versin de los procesos a travs de estos diferentes
documentos. Vaya a la seccin Puesta en marcha de un proyecto ITIL - Puesta en marcha
de la gestin del conocimiento.
Esta gestin ser ms eficaz si, al mismo tiempo, se lleva a cabo una mejora de la calidad
del proyecto.
Ciclo de implantacin
La implantacin de los procesos se debe hacer siguiendo una determinada lgica.
Se puede adoptar el principio de funcionamiento descrito en el captulo Mejora continua de
los servicios de ITIL, para estudiar la puesta en marcha del proyecto. Para ms detalle
sobre el proceso, vaya al captulo Mejora continua de los servicios (CSI).
Para ello, se puede utilizar el siguiente modelo:
Modelo del ciclo de implantacin

Este modelo se basa en seis etapas que vamos a describir a continuacin.
Etapa 1 - Cul es la visin?

Esta etapa permite validar la visin y los objetivos que la Direccin de la empresa quiere
que ponga en marcha la Direccin de la organizacin TI.
Especialmente, esta etapa debe permitir identificar cmo la organizacin TI va a poder
aportar un valor aadido a las reas de negocio de la empresa o del cliente.
Los procesos ITIL se pueden utilizar como modelo de organizacin, para identificar aquellos
que aportan a la empresa un retorno de la inversin lo ms rpidamente posible.
En esta etapa es necesario establecer una comunicacin slida por parte de la Direccin de
la empresa para anunciar y apoyar este proyecto.
Etapa 2 - Dnde estamos actualmente?

La segunda es una etapa de observacin y anlisis.
Para conocer el camino que se debe recorrer y definir las medidas que se deben poner en
marcha, en primer lugar es necesario verificar la situacin actual. Esta operacin permite
conocer el grado de madurez de la organizacin ITIL.
Esta etapa es importante, ya que le permite identificar cmo difiere la organizacin actual
de la propuesta por ITIL.
En esta etapa es necesario abordar aspectos muy diferentes:
La visin a largo plazo.
Los procesos de gestin (segn lo descrito por ITIL).
El establecimiento de una verdadera cultura de servicio.
Los medios tecnolgicos.
Los medios humanos.
La formacin.
La documentacin...
En esta etapa, la organizacin TI ha de establecer un esquema de comunicacin que
deber mantener durante todo el desarrollo del proyecto.
Es imprescindible obtener la adhesin de los empleados para que tenga xito la puesta en
marcha de los procesos; la comunicacin que se establezca, en todas las formas, ser un
factor de adhesin.
En la segunda etapa, se plantean preguntas sobre el nivel de madurez alcanzado por la
empresa en general, y la direccin informtica en particular.
La medicin y el anlisis de la situacin se lleva a cabo a travs de reuniones, seminarios,
auditoras o investigaciones.
En la puesta en marcha de una estrategia de calidad, las etapas 1 y 2 se pueden asimilar

a la etapa Act de la Rueda de Deming (PDCA).
Etapa 3 - Adnde queremos ir?

Durante esta tercera etapa, ser necesario definir de manera precisa qu organizacin se
establecer y cules son los roles y objetivos que se asignarn a cada propietario de
proceso dentro de la organizacin de TI, en la implantacin de la estructura ITIL.
En esta etapa se definen cules son los niveles de rendimiento esperados y las mtricas
que permitirn medirlos.
Esta fase, para cada proceso, debe permitir identificar y construir su estructura y
relaciones, actuales y futuras, con las otras entidades de la empresa.
Tambin durante esta etapa se deben identificar los beneficios, los problemas y los costes
esperados de la puesta en marcha del proyecto.
Esto pasa por el anlisis de las medidas que hay que aplicar para obtener los resultados
esperados, tal y como fueron definidos en las etapas anteriores.
Se deben definir de manera detallada las necesidades, los recursos (tcnicos y humanos) y
la carga de trabajo.
Se debe elaborar y publicar el plan del proyecto de implantacin para explicar cules sern
los cambios y cmo se pondrn en marcha.
En esta etapa la comunicacin es muy importante, ya que permitir al conjunto de la
empresa entender cmo se pondr en marcha el proyecto de implantacin.
En la puesta en marcha de una estrategia de calidad, la etapa 3 se puede asimilar a la

etapa Plan de la Rueda de Deming (PDCA).
Etapa 4 - Cmo llegar a nuestro objetivo?

Esta cuarta etapa corresponde a la puesta en marcha del proyecto.
Se deben poner en marcha los procesos y se deber estudiar la medida de su eficacia.
En esta etapa es importante desarrollar o mejorar los procesos, despus de adaptar o
instalar las herramientas informticas destinadas a sostenerlos.
No hay que olvidar que, para que un proceso funcione, necesita establecer un sistema de
documentacin basado en documentos y procedimientos.
Tambin se debe tener en cuenta y realizar la formacin del personal.
Se debe prever una fase de pruebas y validacin antes de pasar a un modo de
funcionamiento recurrente.
Estas pruebas deben permitir verificar el correcto funcionamiento del proceso y el logro de
los objetivos definidos anteriormente por la empresa.

etapa Do de la Rueda de Deming (PDCA).
Etapa 5 - Hemos llegado?

Esta etapa le debe permitir asegurar que el proyecto puesto en marcha cumpla con las
expectativas iniciales de la empresa.
Para esto, es necesario medir los resultados de los procesos, ayudndose de las mtricas
aplicadas en las etapas anteriores y, si es necesario, definiendo nuevas mtricas.
Estas medidas deben tener en cuenta la satisfaccin del personal y de los clientes de la
organizacin TI.
Esta medicin se puede realizar utilizando las encuestas de satisfaccin.
Tambin es importante asegurar la mejora de la calidad del servicio y observar que los
niveles de actividades reales se ajustan a las previsiones.

etapa Check de la Rueda de Deming (PDCA).
Etapa 6 - Continuar el ciclo de vida de los procesos

Esta ltima etapa, que de hecho no debe ser la ltima, ya que va a desembocar en la
puesta en marcha del proceso de mejora continua del servicio, es importante para el
seguimiento de las operaciones.
Para ello, es necesario revisar lo que se ha hecho, las dificultades y problemas que se han
encontrado, y reflexionar sobre la manera de mejorar.
El resultado de esta etapa permitir poner en prctica la primera etapa del proceso de
mejora continua del servicio.
Para ello, es importante hacer una evaluacin completa del proyecto de implantacin,
revisar los procesos para asegurar que su contenido est correctamente alineado con los
objetivos y verificar que existe un correcto aporte de valor aadido a los procesos de
negocio de la empresa o del cliente.
Durante esta etapa, tambin es preciso verificar, controlar y mejorar, si es necesario, las
mtricas que permitirn medir los resultados del funcionamiento de los procesos (ver el
captulo Mejora continua de los servicios).
Tambin es una oportunidad para recordar el mensaje clave: mantener una visin
empresarial en la puesta en marcha de los servicios.
La direccin debe llevar a cabo una comunicacin al final de este proyecto, destacando las
mejoras comprobadas y recordando su fuerte apoyo a este proyecto y a las estructuras y
la organizacin que se han puesto en marcha.
Puesta en marcha del proyecto

1. Plazos de realizacin
En funcin del tamao de la empresa y de los medios que se ponen en marcha, los plazos
de realizacin sern ms o menos dilatado.
Para acelerar el proceso de puesta en marcha, muchas empresas cuentan con la
participacin de consultores independientes especializados en la aplicacin de las
estrategias de ITIL.
La siguiente tabla da una idea de los plazos de puesta en marcha de los procesos de un
proyecto ITIL.
Pequea/mediana
empresa
Procesos ITIL
Gran
empresa
Centro de servicios + Gestin de incidencias
2 a 4 meses
4 a 6 meses
Gestin de problemas
1 a 2 meses
2 a 4 meses
Gestin de configuraciones
2 a 6 meses
3 a 10 meses
Gestin de cambios
2 a 6 meses
3 a 10 meses
Gestin del porfolio de servicios + Gestin del

catlogo de servicios
1 a 4 meses
3 a 8 meses
2 a 4 meses
3 a 6 meses
1 a 3 meses
2 a 6 meses
1 a 3 meses
2 a 6 meses
Tiempo
de
puesta
en
marcha
de los
procesos
Se trata de tiempos medios para una puesta en marcha ptima.
Para pequeas y medianas empresas, la puesta en marcha global de un proyecto ITIL tarda
de uno a dos aos, en funcin de los recursos asignados al proyecto y del tamao de la
empresa.
El nmero de oficinas de la empresa tambin puede modificar el tiempo global de puesta
en marcha.
En el caso de grandes empresas, el tiempo razonable es de dos a cuatro aos,
fundamentalmente dependiendo del nmero de oficinas y de sus implantaciones en
diferentes pases.
2. Formacin de los actores del proyecto

En el mbito de una implantacin ITIL, es deseable que todo el equipo directivo de la
empresa siga una formacin de tipo ITIL Foundation, incluso aunque el paso de la
certificacin no sea obligatorio.
De manera ideal, esta formacin debera incluir a los responsables de las diferentes reas
en una misma sesin, para permitir a unos y otros intercambiar y entender mejor las
dificultades que pueden encontrar diariamente en la realizacin de sus tareas.
Una formacin como esta permite entender los conceptos principales, as como adquirir un
vocabulario comn; la formacin da a todos los actores un nivel de conocimiento mnimo
para llevar a cabo este proyecto de magnitud para la empresa.
En una segunda etapa, pero que se puede realizar al mismo tiempo, es imprescindible
formar al conjunto de personas de la organizacin TI. Una vez ms, el paso de la
certificacin ITIL Foundation no es obligatorio, pero s muy recomendable, ya que requiere
una fuerte implicacin de los empleados en la formacin.
Con respecto a las personas que se identifican para ser propietarias de los procesos, es
posible hacer que sigan una formacin complementaria adaptada a los procesos de los que
sern propietarias.
Estos cursos de formacin se pueden realizar en formato interempresas o intraempresa.
3. Los factores de xito

a. Tener una visin clara del proyecto
El objetivo principal de ITIL es sustituir una visin muy orientada a la tecnologa por una
visin de negocio. Entender ITIL es importante, pero tambin es necesario identificar qu
va a apoyar esto a la actividad de la empresa y a participar en la creacin de valor.
b. ITIL es un medio, no un objetivo

Algunas direcciones informticas y proveedores de servicios informticos utilizan ITIL como
una pantalla para protegerse de los usuarios y de sus clientes.
ITIL debe servir al objetivo de resolver las incidencias y los problemas encontrados por los
usuarios y los clientes, as como al objetivo de la mejora continua de los servicios, y no
convertirse l mismo en un objetivo.
c. Preparacin de la empresa
La puesta en marcha de un proyecto ITIL normalmente es un largo y, algunas veces, difcil
camino.
La resistencia al cambio siempre existe en las empresas y acta como freno a este.
Se deben desarrollar mtodos especficos para explicar este cambio y hacer frente a esta
resistencia.
La comunicacin, en todas sus variedades, forma parte de estas medidas.
d. Comunicacin
La puesta en marcha de un proyecto ITIL dar lugar a un cambio en las relaciones entre las
diversas reas y la organizacin TI.
La direccin de la empresa debe establecer una comunicacin destinada al conjunto del
personal de la empresa.
Esta accin de comunicacin debe usar los resultados tan pronto como estn disponibles, y
utilizarlos para mantener una motivacin continua de los diferentes actores del proyecto.
Uno de los objetivos de la comunicacin ser facilitar el paso de la organizacin TI de una

cultura tecnolgica a una cultura de servicio.
e. Apoyo de la directiva
Los miembros de la directiva de la empresa se deben adherir al proyecto; para ello es
imprescindible que la Direccin General de la empresa establezca una comunicacin
especfica con objeto de acompaarlos en este proyecto.
Una falta de implicacin de la directiva en el proyecto ser rpidamente identificada por los
diferentes actores y provocar la desmotivacin de los actores del proyecto, incluso una
resistencia al cambio.
f. Identificar a los propietarios de los procesos

La puesta en marcha de un proyecto ITIL tal vez dar lugar a cambios en la estructura de
la empresa.
Hoy en da muchas empresas estn constituidas por un silo de competencias o
actividades.
La puesta en marcha de los procesos, que a menudo abarca varias reas de competencias,
va a necesitar, en algunos casos, una modificacin de la estructura jerrquica.
Es necesario forzar al conjunto de actores a trabajar de modo colaborativo.
Por lo tanto, va a ser necesario identificar a los propietarios de procesos capaces de
trabajar de un modo transversal.
g. Formacin
Una de las grandes aportaciones de ITIL es proporcionar un vocabulario comn para todos
los actores de la gestin de servicios informticos.
La formacin de estos actores har ganar un tiempo considerable en el establecimiento de
los procesos y reforzar la adhesin de los actores (ver ms arriba la seccin Formacin de
los actores del proyecto).
h. Apoyar el cambio
La implantacin de un nuevo sistema o de un nuevo procedimiento implica
sistemticamente una resistencia por parte de las personas que utilizan o producen el
elemento modificado. Esta resistencia al cambio es natural y clsica, pero no debe tomarse
a la ligera. Para tratar este problema, tanto los usuarios como los miembros de la direccin
informtica deben entender los objetivos que se buscan, identificar los beneficios y
compartir la visin de la nueva organizacin, para ver el cambio como algo deseable y
necesario. La presentacin de estos cambios requiere un enfoque gradual y debe conducir a
su aceptacin por las diversas partes implicadas en el proyecto.
i. Prever un proceso progresivo

Los procesos de gestin de servicios de ITIL representan una carga muy importante
durante su puesta en marcha y algunas veces van en contra de la madurez de la empresa.
Esto puede implicar cierta confusin y una mala integracin del conjunto. La solucin
consiste en pasar por etapas progresivas que respeten los objetivos de la empresa y las
futuras evoluciones de su madurez. Esto tambin permite proyectar la implantacin de los
procesos desde una ptica de resultados a corto plazo, que favorece su adopcin.
j. Definir un proyecto realista

Para tener xito en un proyecto de implantacin de ITIL, es necesario tener medios
humanos, tcnicos, tecnolgicos y financieros.
Este es un compromiso de medio o largo plazo; en funcin del tamao de la empresa,
normalmente entre uno y tres aos.
Hay que tener cuidado con el exceso de ambicin en el inicio del proyecto.
Es necesario empezar poco a poco y hacer crecer el permetro progresivamente. No

puede haber una operacin de tipo Big Bang para implementar un proyecto ITIL; es,
obligatoriamente, un proyecto a largo plazo.
Querer poner en marcha todos los procesos al mismo tiempo representa un proyecto muy
importante, largo y costoso.
El peor enemigo durante la implantacin de ITIL, como en la mayora de los proyectos, es
la bsqueda de la perfeccin y la definicin de objetivos demasiado ambiciosos. En este
caso, los riesgos de desmotivacin o rechazo de los actores del proyecto son muy elevados.
k. Definir prioridades
La puesta en marcha del proyecto se extiende durante algunos meses, incluso aos.
Por lo tanto, es imprescindible definir las prioridades de su puesta en marcha.
La eleccin de los procesos se debe hacer en funcin de las prioridades determinadas por la
empresa.
De manera ideal, debern ser prioritarios los procesos que permitan el nacimiento de una
cultura de servicio.
El establecimiento de un centro de servicios y del proceso de gestin de incidencias se
puede hacer de manera simple y obtener resultados rpidamente.
La comunicacin de estos resultados permitir una mayor motivacin de los actores del
proyecto.
4. Eleccin de los procesos

De forma ideal, aunque normalmente no es el caso, sera necesario poner en marcha el
conjunto de procesos ITIL en el mismo momento en que se implanta la organizacin TI.
Actualmente, la gran mayora de las empresas ya han implantado una organizacin
informtica.
Por lo tanto, es necesario tener en cuenta la existencia de la empresa y establecer un
proyecto en funcin de su realidad.
En este contexto, los primeros procesos que se deben poner en marcha son los siguientes:
Generacin de la estrategia.
Gestin de incidencias.
Gestin de problemas.
Gestin de configuraciones.
Gestin de cambios y entradas en produccin.
5. Definicin del equipo de proyecto

Es imprescindible trabajar en modo proyecto para tener xito en la implantacin de
procesos ITIL.
La primera actividad que se debe realizar es definir el equipo de proyecto que se encargar
de poner en prctica los procesos y asegurar el seguimiento del proyecto.
La tentacin de poner en marcha los procesos a medida que sea necesario es un error, ya
que esto no implica automticamente la adhesin del personal y finalmente es, al menos,
tan caro como el caso de creacin de un equipo de proyecto.
Este equipo de proyecto debe preparar un informe del proyecto y validarlo con la Direccin
de la empresa y la Direccin de la organizacin TI.
Sin el soporte real y eficaz de la Direccin de la empresa, no es posible poner en marcha

un proyecto ITIL en ella. Es importante que la direccin de la empresa emita un
comunicado sobre este proyecto tan pronto se haya tomado la decisin de ponerlo en
marcha.
6. Generacin de la estrategia
En un primer lugar, la direccin de la organizacin TI debe poner en marcha, de manera
paralela, una estrategia para la organizacin.
En este mbito, debe definir la estrategia que desea poner en marcha para la explotacin y
En este estado del proyecto, no es necesario tener una definicin completa y definitiva de
las estrategias que se van a poner en marcha.
El conjunto de estrategias se debe revisar ms adelante.
Es durante esta etapa cuando resulta deseable poner en marcha un ciclo de formacin ITIL.
7. Puesta en marcha de los procesos de explotacin de

servicios
Normalmente, los procesos de gestin de explotacin de servicios son los primeros en
ponerse en marcha.
Existen varias razones para esta eleccin:
Visibilidad, tanto a nivel interno de la organizacin TI como para los clientes y

usuarios.
Resultados fcilmente demostrables.
Procesos que con frecuencia se ponen en marcha parcialmente.
Puntos de entrada para ms procesos.
Tiempo de puesta en marcha bastante corto.
8. Puesta en marcha del centro de servicios

Esta etapa se puede desarrollar al mismo tiempo que las etapas descritas en las secciones
Puesta en marcha de la gestin de activos de servicios y configuraciones y Puesta en
marcha de la gestin de cambios.
Es necesario determinar qu tipo de centro de servicios se implantar: centro de servicios
local, centralizado o virtual.
La puesta en marcha del proceso de gestin de incidencias debe coincidir con la puesta en
marcha del centro de servicios.
La comunicacin con las otras reas de la empresa y con el cliente es imprescindible.
Es necesario comunicar al conjunto de actores la puesta en marcha y el modo de

funcionamiento del centro de servicios para garantizar el apoyo de todos los actores a la
nueva organizacin y la implementacin exitosa del proyecto.
a. Consideraciones sobre la puesta en marcha del centro de servicios en el mbito

de varias estructuras locales
La puesta en marcha del centro de servicios necesita tener en cuenta los siguientes
elementos:
Establecer los procesos comunes a todas las ubicaciones y procedimientos comunes,

si es posible.
Asegurar que las competencias conocidas por una ubicacin estn disponibles para el
resto de las ubicaciones.
Asegurar la compatibilidad del hardware, el software y la infraestructura de red.
Utilizar los mismos procesos de escalado y mismos cdigos de estado en todas las
ubicaciones.
Utilizar la misma base de datos compartida.
Estandarizar la clasificacin de las peticiones.
En el mbito de este ejemplo, vamos a decidir poner en marcha un centro de servicios

centralizado, por lo tanto, nico en la sede de la empresa.
El jefe de proyecto responsable de la puesta en marcha del centro de servicios debe tener
en cuenta los diferentes recursos de los que dispone, tanto de hardware (PBX, puestos de
trabajo [informticos y de telefona], redes...) como de software (herramientas de gestin
de llamadas, bases de datos, bases de conocimiento, CMS...), adems de los recursos
humanos (recepcionistas, agentes de soporte de nivel 1, agentes de soporte de nivel n) y,
para finalizar, los recursos financieros.
El jefe de proyecto debe tener en cuenta una serie de puntos clave:
Definir objetivos claros y alcanzables.
Inicio sencillo, con un permetro reducido.
No intentar hacer todo al mismo tiempo.
Adoptar un enfoque por fases.
Implicar y consultar a los clientes.
Implicar y consultar a los usuarios finales.
Formar equipos que aseguren el soporte de los productos/aplicaciones/hardware.
Educar y formar a los clientes y los usuarios en la utilizacin del centro de servicios.
Asesorar y vender el servicio.
No iremos ms all en la descripcin del trabajo del jefe de proyecto: se trata de la puesta
en parcha de un proyecto real informtico.
Atencin: no se pueden poner en marcha todos los niveles de soporte al mismo tiempo. De
nuevo, hay que ser modesto y empezar poco a poco, con un servicio, para posteriormente
integrar de manera progresiva el conjunto de servicios definidos en el catlogo de servicios.
b. Desarrollo de las operaciones

En primer lugar, debe elegir una herramienta de gestin de llamadas que corresponda
a sus necesidades.
Si ya hay una herramienta operativa, es necesario asegurar que permite todas las
operaciones de creacin, control y seguimiento de los tickets. Tambin es necesario
verificar la configuracin de la herramienta en funcin de las obligaciones definidas en el
contrato de servicios.
Posteriormente, debe configurar la herramienta para tener en cuenta las reglas definidas en
el contrato de nivel de servicios o SLA (ver seccin Gestin de los niveles de servicio captulo Los procesos del diseo de los servicios). En general, los fabricantes de software
proporcionan un soporte para la configuracin de sus herramientas, ya que normalmente
resulta complejo realizar esta configuracin de manera ptima.
Atencin: no olvide que un error en la configuracin de la herramienta, puede tener

importantes consecuencias en el cumplimiento del contrato de servicios.
La configuracin se refiere, en particular a:
Los horarios de soporte.
Los diferentes tipos de llamadas.
Los diferentes cdigos de gestin de tickets.
Los diferentes datos relativos a los actores del soporte.
Las nociones de impacto y urgencia, que despus permitan definir automticamente

un nivel de prioridad.
Las colas de espera y asignacin de llamadas, para cada uno de los tipos de
llamadas.
Las reglas de escalado.
Las obligaciones de respetar los plazos de tratamiento.
Todas las otras obligaciones especificadas en el contrato de nivel de servicios.
Esta no es una lista exhaustiva de los puntos que se deben tratar.

En una etapa posterior, es obligatorio prever una formacin del conjunto de los equipos del
centro de servicios (responsables y tcnicos) sobre el uso de la herramienta.
Del perfecto manejo de la herramienta de gestin de incidencias depender la eficacia y

eficiencia del centro de servicios y, por lo tanto, la percepcin que tendrn los clientes de
l.
9. Puesta en marcha de la gestin de incidencias y problemas

En esta etapa ser necesario poner en marcha los procesos de gestin de incidencias
y problemas.
De manera ideal, esta etapa deber coincidir con la puesta en marcha del centro de
servicios.
Sea cual sea el tamao de la organizacin TI, es deseable identificar correctamente los dos
procesos de gestin de incidencias y problemas.
Los objetivos de estos dos procesos son distintos y opuestos:
Restablecer el servicio lo ms rpidamente posible para la gestin de incidencias; por

lo tanto, responder lo ms rpidamente posible.
Identificar la causa subyacente desconocida para la gestin de problemas; por lo

tanto, tomar el tiempo necesario para analizar e identificar la causa primera real de
las incidencias.
Si el tamao de la organizacin TI no permite tener dos equipos distintos, en este caso es

preferible asignar los roles a los tcnicos, dejndoles cambiar de rol de manera regular.
Por ejemplo, una parte del equipo asegura la gestin de incidencias por la maana y
cambia de rol por la tarde, para asegurar la gestin de problemas.
Esta forma de funcionar tambin se puede establecer de manera diaria o semanal.
Esta etapa implica estar especialmente atentos a la formacin de los tcnicos del centro de
servicios.
10. Puesta en marcha de los procesos de transicin de

servicios
Despus de la puesta en marcha de los procesos de explotacin de servicios, es
aconsejable poner en marcha los procesos de transicin de servicios.
Estos, a su vez, suelen ser puntos de entrada para el proceso de diseo de servicios.
El proceso de gestin del catlogo de servicios se pone en marcha habitualmente en el
mismo momento que los procesos de transicin de servicios, ya que servir de unin entre
los procesos de explotacin y transicin de servicios.
Al mismo tiempo, servir como punto de partida para muchos procesos de diseo de
servicios.
11. Puesta en marcha de la gestin de activos de servicio y

configuraciones
Esta etapa se puede llevar a cabo al mismo tiempo que las etapas descritas en las
secciones Puesta en marcha del centro de servicios y Puesta en marcha de incidencias y
problemas.
Los procesos de gestin de activos de servicio y configuraciones se apoyan en la creacin
de una base de datos (CMS) que contenga el conjunto de activos de la empresa.
La puesta en marcha de la CMS se puede hacer de manera independiente de la puesta en
marcha del centro de servicios y de los procesos de gestin de incidencias y problemas,
aunque su disponibilidad pueda ayudar al funcionamiento de estos dos procesos.
La creacin de esta base de datos se apoya en un anlisis preciso de su contenido futuro, y
fundamentalmente de los atributos y relaciones que se definirn.
Atencin: no quiera ir demasiado rpido y demasiado lejos; es necesario ser modesto y

comenzar poco a poco, antes de ampliar el permetro y la granularidad de la CMS.
En caso de que ya exista una gestin de Assets en la empresa, eventualmente se podrn
utilizar los datos ya disponibles.
Lo importante es mantener actualizada la CMS. Esto se consigue poniendo en marcha el

proceso de gestin de cambios.
a. Qu beneficios se pueden obtener de la puesta en marcha?

La puesta en marcha de la gestin de activos de servicio y configuraciones (SACM) permite
a la empresa obtener una mejor gestin de sus activos y configuraciones. Esto ser tanto
ms importante cuanto que los elementos definidos e identificados en este proceso sean
puntos de entrada para muchos otros procesos.
No se trata aqu de detallarlos todos, pero podemos tomar como ejemplo los casos
siguientes:
Mejora de la seguridad.
Mejora de la movilidad del personal.
Mejora de la gestin de configuraciones tipo.
b. Los riesgos en trminos de seguridad

Un problema frecuente que se encuentra la mayora de las empresas: la gestin de los
derechos de acceso.
Cmo es la asignacin de derechos de acceso en las empresas?
Tras entrar en la empresa, al empleado se le asignan derechos de acceso basados en la
posicin que va a ocupar.
Las complicaciones comienzan cuando el empleado cambia de puesto.
Lgicamente, a este empleado se le debern retirar una serie de derechos, aquellos que ya
no corresponden a su nuevo puesto, y deber recibir otros nuevos, siempre en funcin de
su nuevo puesto.
En la realidad, y de hecho sucede en muchas empresas, cuando un empleado cambia su
puesto solo se le asignan sus nuevos derechos, lo que puede, a la larga, provocar muchos
problemas.
Fundamentalmente, esta falta de rigor en la gestin de derechos provocar que el
empleado tenga que realizar varias llamadas al centro de servicios para contrarrestar la
falta de acceso a archivos o aplicaciones debido a los derechos que no se concedieron.
Mucho ms grave es mantener los derechos de acceso del empleado a archivos o
aplicaciones, aunque el personal asignado al nuevo puesto ocupado por el empleado no
est autorizado a acceder a estos archivos o aplicaciones.
Los riesgos en los que se incurre por este funcionamiento incorrecto pueden ser muy
elevados, ya sea por errores de uso o manipulacin involuntaria o debido a una voluntad de
accin maliciosa.
Estos riesgos se pueden evitar aplicando las configuraciones tipo, identificadas en la CMS,
para cada tipo de funcin. Por lo tanto, basta aplicar, por cada cambio de funcin de un
empleado, la configuracin correspondiente a su nueva funcin.
c. Las dificultades encontradas durante el movimiento de personal

Normalmente, se presentan tres situaciones diferentes en este punto.
Personas con discapacidad

En todas las empresas, al menos tericamente, debe haber un cierto porcentaje, fijado por
ley, de personal con discapacidad.
El puesto de trabajo del empleado puede necesitar una adaptacin, en funcin de su
discapacidad.
En el marco de una reorganizacin de servicios en el seno de la empresa, es imprescindible

tener en cuenta las diferentes caractersticas de acondicionamiento del puesto de trabajo
del empleado.
Estas caractersticas pueden estar relacionadas con una dificultad fsica de acceso al lugar
de trabajo o con la necesidad de utilizar un equipamiento especial; por ejemplo, una
pantalla de tamao especfico en caso de discapacidad visual.
No siempre las personas encargadas de la puesta en marcha de la reorganizacin tendrn
conocimiento de estas caractersticas, lo que puede provocar un funcionamiento incorrecto
en el momento de la mudanza.
La aplicacin de una configuracin tipo permitir identificar las caractersticas vinculadas a

esta persona, facilitando el trabajo de los equipos encargados de la reorganizacin, y
aportar la seguridad de una transferencia sin riesgos.
Llegada de un nuevo empleado

Actualmente, muchas empresas utilizan personal externo.
En normal que estos nuevos empleados se encuentren el da de su llegada sin puesto de
trabajo y sin ninguna posibilidad de acceder a las aplicaciones o a los datos con los que
tienen que trabajar.
Tambin es habitual que el plazo de espera para disponer de un puesto de trabajo con
todos los derechos correspondientes a su funcin en la empresa sea superior a una
semana.
Al final, para que este nuevo empleado pueda trabajar, termina compartiendo el puesto de
trabajo con sus compaeros y, lo que es ms grave, los cdigos de acceso a las
aplicaciones y a los datos (usuario y contrasea).
Se debe tener en cuenta dos aspectos en este tipo de situacin:
La falta de productividad del nuevo empleado.
El incumplimiento de las normas de seguridad definidas en el proceso de gestin de

la seguridad de la informacin.
La preparacin de la llegada de un nuevo empleado permitir a los equipos internos poner

en marcha los diferentes medios informticos antes de que esta se produzca y servir, por
lo tanto, para mejorar la productividad y eliminar los riesgos relacionados con la seguridad
de la informacin.
Marcha de un empleado
No es raro ver todava hoy en da en las empresas grandes o medianas que cuando se
marcha de un empleado no se hace nada en trminos de actualizacin de los derechos de
acceso a las aplicaciones y datos.
Adems, es frecuente que esta situacin se mantenga durante varias semanas, incluso
meses.
El impacto es tambin doble:
No se liberan recursos, fundamentalmente de almacenamiento.
No se respetan las normas de seguridad definidas en el proceso de gestin de la

seguridad de la informacin.
De nuevo, en ausencia de procesos claramente definidos e identificados, los riesgos de

olvido son muy elevados. El empleado es un recurso de la organizacin TI y, por lo tanto,
se debe gestionar en el proceso de gestin de activos de servicio y configuraciones para
evitar este tipo de funcionamientos inco-rrectos.
d. Dificultades en la gestin de configuraciones tipo

En las empresas medianas y grandes, en el seno de la organizacin informtica, hay un
equipo encargado de la puesta en marcha y mantenimiento de los equipos informticos.
En ausencia de definicin de configuraciones tipo, los empleados de estos equipos deben
gestionar de manera unitaria la instalacin de cada puesto de trabajo.
La optimizacin de los tiempos de puesta en marcha de los puestos de trabajo para estos
equipos pasa necesariamente por la definicin de configuraciones tipo.
Se tienen en cuenta dos tipos de configuraciones tipo:
Configuraciones de tipo hardware: la definicin de configuraciones tipo permiten una

gestin ms eficaz de los puestos de trabajo y facilitan las operaciones de
mantenimiento de los puestos. La utilizacin de un Master especfico para cada tipo
de configuracin de hardware, en funcin del tipo de mquina o fabricante, permite
una puesta en marcha y despliegue de los puestos de trabajo ms rpidos.
Configuraciones de tipo funcional: la definicin de configuracin tipo en funcin del

tipo de puesto funcional ocupado por el empleado va a permitir una vez ms, gracias
al uso de un Master, una preparacin del puesto ms rpida y, sobre todo, mejor
controlada (seguridad de que todo el software del puesto est correctamente
instalado y configurado, y que todos los derechos de acceso a la aplicaciones y datos
se han definido correctamente).
12. Puesta en marcha de la gestin de cambios

Esta etapa se puede llevar a cabo al mismo tiempo que las etapas descritas en la seccin
Puesta en marcha del centro de servicios y Puesta en marcha de la gestin de incidencias y
problemas.
La puesta en marcha de los procesos de gestin de cambios y gestin de las entradas en
produccin probablemente va a proporcionar cambios en los hbitos de funcionamiento de
la organizacin TI.
De manera ideal, la puesta en marcha del proceso de gestin de cambios se debera hacer
al mismo tiempo que la puesta en marcha del proceso de gestin de los activos de servicio
y configuraciones.
Sin embargo, debido a que los procesos de diseo de servicios todava no estn
implementados, es posible que nicamente una parte del proceso de gestin de cambios se
ponga en marcha en esta etapa.
Un punto muy importante en esta etapa es permitir la actualizacin de la CMS tan pronto
como se identifique un cambio en la infraestructura.
La constitucin del CAB se debe llevar a cabo al comienzo de esta etapa. Esta
responsabilidad recae sobre el propietario del proceso, normalmente llamado Change
manager o responsable de los cambios.
Es deseable, al menos al inicio del proceso, informar a todos los propietarios de procesos,
tan pronto estn identificados, del conjunto de peticiones de cambio presentadas. Esto no
implica necesariamente que estn obligados a participar en las reuniones del CAB, al
menos si no se ven implicados por los cambios examinados.
La elaboracin y la firma de los contratos de acuerdo de servicio entre la organizacin TI y
el cliente o entre la organizacin TI y los proveedores se deben llevar a cabo en el marco
del proceso de gestin de cambios para asegurar la coherencia de las ofertas y de las
respuestas proporcionadas.
La puesta en marcha de este proceso debe permitir la coordinacin de las actividades en
los proyectos en las intervenciones de los equipos internos y las intervenciones de los
proveedores.
Un punto importante que es preciso tener en cuenta en el momento de la implantacin de
un cambio, fundamentalmente durante la instalacin de un nuevo servicio, una nueva
versin de software o de aplicacin, es la parte documental.
En efecto, es importante para el conjunto de los actores de la empresa, pero tambin para
el cliente y los usuarios, haber sido informados de este cambio y haber recibido, si se da el
caso, documentacin adaptada, as como la formacin necesaria para aprender
correctamente el nuevo servicio o la nueva versin de software o de una aplicacin.
En el caso anterior, es igualmente importante establecer un soporte especfico para esta
puesta en marcha (Early Life Support).
Adems del hecho de que esto permite asumir ms rpidamente el nuevo servicio o versin
de software/aplicacin, esto tambin permite un refuerzo de las relaciones entre los
equipos de diseo de servicios y los equipos operativos durante el ciclo de vida de los
servicios.
No hay que olvidar que uno de los objetivos de la gestin de cambios es reducir los riegos
relacionados con los cambios mal controlados.
El punto ms importante durante la fase de inicio del proceso es asegurar que todos los
cambios relativos a los elementos de la configuracin de activos del servicio y de la
configuracin se registran correctamente en el sistema de gestin (CMS: Configuration
Management System). Ser necesario estar atentos.
13. Puesta en marcha de la gestin de pruebas y validacin de

los servicios
Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en la seccin
Puesta en marcha de la gestin de cambios.
Las empresas, en funcin de su tamao y del tamao de su organizacin TI, no tendrn

siempre un equipo de pruebas y de validacin de los servicios para asegurar el conjunto de
pruebas anteriores a las entradas en produccin de los cambios.
En ausencia de equipos dedicados, el responsable del proceso deber formar un equipo
temporal para hacer las diferentes pruebas y operaciones de validacin de los servicios. En
la medida de lo posible, puede ser interesante incluir en estos equipos a empleados
procedentes tanto de la gestin del diseo de servicios como de la gestin operativa.
Esta mezcla puede mejorar la colaboracin entre los diferentes equipos.
Esta etapa permite verificar, antes de la puesta en marcha de un servicio, que corresponde
a las necesidades y proporciona el rendimiento esperado. Esto tambin sirve para asegurar
que responde a las especificaciones solicitadas en el contrato de servicios.
14. Puesta en marcha de la gestin de las entradas en

produccin
Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en las secciones
Gestin de cambios y Gestin de validaciones y pruebas, del captulo Los procesos de la
transicin de los servicios.
La formacin del equipo encargado de la puesta en marcha en produccin seguir las reglas
definidas en la seccin Gestin de las entradas en produccin y Gestin de las validaciones
y pruebas del captulo Los procesos de transicin de Servicios.
Para lograr su objetivo, el responsable del proceso debe definir un plan de despliegue de
acuerdo con el cliente y las diferentes partes interesadas.
Tambin es imprescindible asegurar que el paquete de instalacin est compuesto por un
conjunto de componentes compatibles entre ellos.
Es importante asegurar la trazabilidad del paquete de instalacin y despliegue para permitir
una eventual desinstalacin en caso de que sea necesario.
Durante esta etapa, tambin ser necesario asegurar que el conocimiento y las
competencias se transfieren a los equipos operativos (soporte y explotacin).
15. Puesta en marcha de la gestin del conocimiento

Este proceso tiene por objetivo asegurar que la informacin fiable y segura, es decir,
aquella que respeta el principio de CIA, est disponible para permitir mejorar la calidad de
la toma de decisiones.
Para ello, es necesario asegurar que la nocin de valor aadido se ha entendido claramente
y se comparte por el conjunto de equipos de cada servicio prestado por la organizacin de
TI.
Es necesario asegurar que la informacin relativa al servicio (usuarios, restricciones,
beneficios esperados...) sea accesible a las personas adecuadas, en el momento adecuado.
El suministro de la informacin que define el conocimiento permite al proveedor del servicio

mejorar la calidad del servicio proporcionado, reduciendo los costes y aumentando la
satisfaccin del cliente.
Es deseable poder aprovechar la puesta en marcha de este proceso para hacerse cargo del
conjunto de actividades relacionadas con la gestin de la documentacin.
Se debe poner en marcha una estandarizacin de los diferentes formatos de soporte para
clarificar la presentacin y lectura de los diferentes documentos.
Esta estandarizacin debe permitir un mejor entendimiento de la documentacin para el
conjunto de los empleados de la organizacin TI.
El establecimiento de una gestin documental, idealmente usando una herramienta de
gestin documental, debe permitir a cada uno encontrar rpidamente la informacin que
necesita, tanto para tomar decisiones como para proporcionar soporte a los usuarios.
El establecimiento del proceso de gestin del conocimiento se puede hacer a travs de la
gestin del conocimiento (SKMS - Service Knowledge Management System) y de
herramientas de gestin de los activos de servicio y configuraciones (CMS - Configuration
Management System).
16. Puesta en marcha del porfolio de servicios y del catlogo

de servicios
En esta etapa, se debe comenzar la puesta en marcha de los procesos de gestin del
porfolio de servicios y gestin del catlogo de servicios.
El catlogo de servicios es un subconjunto del porfolio de servicios.
La primera etapa consistir en hacer un inventario de los servicios que entrega actualmente
la organizacin TI. Esto constituir la base del catlogo de servicios que alimentar
finalmente al porfolio de servicios.
La puesta en marcha completa del proceso de gestin del porfolio de servicios se puede
realizar en segundo lugar, al mismo tiempo que el proceso de gestin de la demanda.
La elaboracin de un catlogo de servicios servir para:
Crear una etapa preparatoria en el establecimiento de la gestin de los niveles de

servicio.
Poner en marcha la comunicacin hacia los empleados de la organizacin TI, clientes

y usuarios.
Realizar un anlisis de las diferentes actividades de la organizacin TI y las relaciones

entre estas actividades.
El anlisis de las actividades dar lugar a una reflexin de los problemas relacionados con
los procesos, la organizacin y las herramientas de la organizacin TI.
En esta etapa, ser necesario hacer un anlisis de cada uno de los servicios para identificar
el valor aadido aportado para cada servicio.
El catlogo de servicios se debe dividir en dos captulos distintos.
El catlogo de servicios debe identificar y diferenciar el catlogo de servicios de negocio, es
decir, los servicios ofrecidos a los clientes, y el catlogo de servicios tcnicos, es decir, los
servicios internos.
El catlogo de servicios de negocio contiene los detalles de todos los servicios informticos
suministrados y prestados a los clientes. Contiene las relaciones con las reas de negocio y
con los procesos. Este catlogo es visible para los clientes.
El catlogo de servicios tcnicos contiene las relaciones con los componentes y con los CI
necesarios para proporcionar el servicio. Tambin contiene las relaciones con los servicios
de soporte. Este catlogo es visible para los servicios internos de la organizacin TI.
Cmo describir un servicio?
La descripcin de un servicio debe incluir los siguientes elementos:
Una descripcin tcnica o funcional del servicio. Esta descripcin se puede basar
ANEXOS
Anlisis de Kepner y Tregoe
Para analizar los problemas, es posible utilizar la matriz desarrollada por Charles Kepner y
Benjamin Tregoe.
Kepner y Tregoe afirman que el anlisis de un problema debe ser un proceso automtico de
resolucin de problemas.
Esta matriz utiliza el conocimiento y las experiencias pasadas.
Se definen cinco fases para el anlisis de un problema.
1. Las cinco fases

Las cinco fases definidas por Kepner y Tregoe son las siguientes:
Definicin del problema.
Descripcin del problema (identificacin de la identidad, el lugar, el momento y el

tamao).
Establecimiento de las posibles causas.
Pruebas de las causas ms probables.
Verificacin de causa real.
Sea cual sea la cantidad de informacin o la urgencia de encontrar una solucin, es mejor
adoptar un enfoque estructurado para analizar los problemas, con el objeto de aumentar
las posibilidades de xito.
2. Definicin del problema

El anlisis y la bsqueda de la causa se basan en la definicin del problema.
Es imprescindible identificar de manera precisa cules son las desviaciones en relacin con
los niveles de servicio acordados.
En la prctica, la definicin de un problema es, a menudo, difcil debido a la complejidad de
la infraestructura informtica o de los acuerdos de niveles de servicio no explcitos.
Frecuentemente, la causa ms probable del problema se seala en la descripcin de este.

No hay que sacar conclusiones precipitadas que podran conducir a pistas falsas.
3. Descripcin del problema

Se utilizan los siguientes elementos para describir un problema:
Identidad: qu componente (CI) o parte

correctamente?, cul es el problema identificado?
Ubicacin: dnde aparece el problema?
Momento: cundo apareci el problema?, con qu frecuencia aparece?
Tamao: cul es la importancia del problema (en trminos de tamao)?, cuntos

componentes (CI) estn afectados?
del
componente
no
funciona
La situacin real y efectiva se determina por las respuestas a estas preguntas.

A continuacin, se deber buscar en el entorno prximo los componentes que funcionan
correctamente.
Esto le permitir identificar lo que podra haber sido parte del problema, pero que no lo es.
A continuacin, se pueden identificar las diferencias relevantes entre las dos situaciones.
Atencin: los cambios pasados pueden ser la causa de estas diferencias.
4. Establecer las posibles causas

La lista de las diferencias y, en caso necesario, de los cambios antes mencionados,
contiene, por lo general, la causa principal del problema.
De este modo, es posible determinarla.
5. Prueba de las causas ms probables

Se debe examinar cada posible causa para determinar si se puede aceptar como causa de
todos los sntomas del problema.
6. Verificacin de la causa real

Se deben verificar las posibles causas identificadas para comprobar si son la causa principal
del problema.
La puesta en marcha de un cambio o la sustitucin de una pieza pueden ser pruebas.
Diagrama de Ishikawa
Esta herramienta fue destacada por Kaoru Ishikawa (1915-1989), ingeniero qumico y
pionero (y uno de los tericos) de la gestin de calidad.
Herramienta de anlisis de causas probables, este diagrama causa-efecto tambin se llama

diagrama de espinas de pescado o diagrama de las 5M.
1. Objetivos
Este diagrama permite determinar el conjunto de causas que producen un efecto
estudiado:
Profundizar y explorar todas las dimensiones de una situacin dada.
Llegar a un acuerdo sobre la definicin y caractersticas de la cuestin tratada.
Ordenar por familias y subfamilias todas las causas de un problema dado.
Visualizar con claridad la relacin adecuada de causa y efecto.
2. Casos de uso
El diagrama de Ishikawa se utiliza con frecuencia en los dos siguientes mbitos:
Resolucin de un problema:
Determinar la causa principal de un problema.
Entender las razones que hacen que un proceso no genere los entregables previstos.
Identificar las posibles fuentes de informacin.
En el caso de resolucin de problemas, esto puede evitar errores de diagnstico.
Ello tiene un impacto directo en el plazo, la calidad y los costes invertidos en la
resolucin del problema.
Desarrollo de un nuevo servicio o de un proyecto: cules son las reas que es

preciso considerar para obtener un servicio eficiente. La gestin y los medios
financieros se pueden tener en cuenta en este mbito.
3. Las reas de clasificacin

Originalmente, Kaoru Ishikawa identific cinco reas de clasificacin.
Las cinco reas pueden ser una base efectiva para la clasificacin:
Materia: materias primas, piezas,

almacenamiento, calidad y manipulacin.
Equipo: maquinaria,
mantenimiento.
Mano de obra:
experiencia.
Medio: entorno fsico, iluminacin, ruido, planificacin, relaciones, proveedores,

mercado y legislacin.
Mtodos: instrucciones, manuales y procedimientos.
herramientas,
directos,
conjuntos,
equipos,
indirectos,
suministros,
capacidad,
motivacin,
identificacin,
edad,
formacin,
nmero
absentismo
4. Progreso
En el marco de la resolucin de un problema:
Definir con claridad el eje sobre el que desea actuar directamente.
Listar las causas ms probables del problema.
Clasificar las causas probables en las cinco reas.
Establecer subfamilias cuando el nmero de casos por familia lo justifique.
Trazar el diagrama causa/efecto (Ishikawa).
Recomendacin: asegrese de que el diagrama es claro y legible.
5. Ejemplo
Definir con claridad el eje sobre el que desea actuar directamente
El objetivo:
prestacin de un servicio de tipo centro de servicios.
Listar las causas ms probables del problema

En este caso, vamos a definir cuatro reas:
recursos de red,
telefona,
seguridad de datos,
puestos de trabajo.
Clasificar las causas probables en las reas

Para el rea de recursos de red:
proveedores,
mantenimiento,
ancho de banda.
Para el rea de telefona:
puesto telefnico:
tipo:
o con cables,
o sin cables,
cantidad:
o instalados,
o en reserva,
desbordamiento,
mantenimiento,
ACD,
Autoconmutador,
Para el rea de seguridad de los datos:
derechos de acceso,
conexiones exteriores,
copia de seguridad de los datos,
Para el rea de puestos de trabajo:
mantenimiento,
calidad:
instalados,
en reserva,
configuracin:
software,
hardware,
Establecer subfamilias cuando el nmero de casos por familia lo justifique

En este caso, no vamos a definir subfamilias.
Trazar el diagrama de causa/efecto (Ishikawa)

A continuacin encontrar el diagrama resultante de nuestras hiptesis.
Diagrama de Ishikawa
El modelo RACI
Para el correcto funcionamiento de un sistema basado en procesos, es importante saber, en
el seno de la organizacin: quin hace qu, cules son las responsabilidades y cules los
roles.
Para gestionar eficazmente un servicio o un proceso, es imprescindible que las
responsabilidades y los roles de cada uno estn claramente definidos.
Esto es lo que permitir a la organizacin tener buen rendimiento y tomar rpidamente
buenas decisiones antes de poder ejecutarlas eficazmente.
En el caso de una eleccin estratgica o de una operacin crtica, saber quin decide, quin
acta y quin est implicado permite a la organizacin reaccionar con rapidez.
El modelo RACI proporciona ventaja para tomar decisiones con confianza y serenidad.
RACI es acrnimo de los cuatro roles principales siguientes:
Responsible (en espaol: Responsable de la realizacin) es la persona o personas

que realizan la actividad. Puede haber varias personas con este rol.
Accountable (en espaol: Responsable) es la nica persona responsable de una

actividad. Muy a menudo, hay una relacin jerrquica entre A y R (con frecuencia, A
es jefe de R).
Consulted (en espaol: Consultado): son las personas consultadas; por lo tanto,
aquellas cuya opinin se solicita.
Informed (en espaol: Informado): son las personas a las que se mantendr
informadas.
Atencin a la correcta definicin de Responsible y Accountable porque es comn

intercambiar el significado en espaol de Responsable de la realizacin y Responsable.
En la siguiente tabla, la R es equivalente a Responsible. No se trata, pues, del
Responsible sino de la persona encargada de hacer.
El modelo RACI
El punto importante cuando se utiliza el modelo RACI o cualquier otra herramienta o

modelo es no permitir la asignacin de responsabilidades al azar. Por otra parte, es
importante que la asignacin de roles se haga lo antes posible en la puesta en marcha del
proyecto. No hay que esperar a una situacin de crisis para asignar los roles. Los conflictos
se pueden evitar y se pueden tomar decisiones rpidamente si los roles se definen de
antemano.
1. Las variantes del modelo RACI

a. RASCI
Una variante del modelo RACI se llama RASCI y aade un rol adicional:
La S significa Supportive (en espaol: el que da soporte). Este rol desempea un papel de
soporte, por ejemplo asignando recursos adicionales para la puesta en marcha del
proyecto.
b. RACI-VS
Otra versin ms completa de RACI, llamada RACI-VS, se utiliza para los roles siguiente:
Verifies (en espaol: Controlador): la persona o grupo que verifica si se ha cumplido el
criterio de aceptacin.
Signs Off (en espaol: Responsable del cierre): persona que aprueba la decisin V (ver
ms arriba) del controlador y que autoriza la transferencia del producto. Se puede tratar de
la persona A (Accountable - Responsable).
Atributos de un CI
1. Propuesta de definicin de los atributos de un CI
Atributo
Descripcin
Identificador del CI
Nombre nico por el que se conoce este tipo de CI.
Nmero de serie, de
licencia (o copia de
licencia)
Identificador nico para las instancias particulares del CI (por ejemplo,

para un software, nmero de licencia o nmero de copia, y para
hardware, el nmero de serie).
Categora
Clasificacin de un CI (hardware, software, documentacin...).
Tipo
Descripcin del tipo de CI. Completa la categora y aade

informacin (por ejemplo, configuracin del hardware, paquete de
software, perifrico de hardware o mdulo de software o de un
programa).
Nmero de
(hardware)
modelo
Modelo de CI (correspondiente, por ejemplo, al nmero de modelo del

proveedor; por ejemplo, modelo yyy PC/aa de tal proveedor).
Fecha de vencimiento de
la garanta
Fecha de vencimiento de la garanta del proveedor para el CI de

hardware o de responsabilidad de asistencia para el software.
Nmero de versin
Nmero de versin del CI.
Ubicacin
Ubicacin del CI (por ejemplo, la biblioteca en la que encuentra el CI o

el CD sobre el que se registra, el lugar o ubicacin donde se sita el
servicio).
Propietario responsable
El nombre o designacin del propietario responsable del CI.
Fecha de inicio de la
responsabilidad
Fecha a partir de la cual el propietario se convierte en responsable del

CI.
Origen/proveedor
El origen del CI (por ejemplo, el nombre del servicio si se ha

desarrollado internamente, comprado a la organizacin xxx...).
Licencia
Nmero de licencia o referencia a un contrato de licencia.
Fecha
aprovisionamiento
Fecha de aceptacin
de
Fecha en la que la organizacin ha adquirido el CI.
Fecha en la que el CI ha superado satisfactoriamente las pruebas de

aceptacin de la organizacin.
Para
los
RFC,
los
registros de cambios, los registros de paquetes, los nombres, los nmeros de copia, los
nmeros de modelo y los nmeros de versin de los CI afectados por el cambio, y cmo se
afectan, se debe guardar en un CMS. Tambin se deben registrar un modo para volver
atrs y las consecuencias de una vuelta atrs.
Glosario
Este glosario retoma los trminos usados en este libro, as como los acrnimos y trminos
ingleses usados en la literatura ITIL.
Estos trminos estn clasificados por orden alfabtico.
Puede encontrar un diccionario ITIL de la OGC en espaol, que puede descargar
gratuitamente en internet.
Haga un bsqueda usando ITIL 2011 Spanish Glossary v1.0 para acceder al documento
descargable. Atencin, este diccionario tiene 154 pginas, pero es particularmente til por
el nivel de detalle que ofrece y por la facilidad de bsqueda tanto en ingls como en
espaol.
Activacin: lanzamiento por la direccin general de la empresa del plan de reanudacin de
la actividad despus de un problema importante.
Actualizacin: agrupamiento de uno o varios cambios autorizados, probados e instalados
en el entorno de produccin.
Actualizacin agrupada: conjunto de actualizaciones de software o de hardware,
implantadas al mismo tiempo en el entorno de produccin.
Actualizacin completa: actualizacin integral de los componentes de un sistema
(hardware, software, documentacin, procedimientos...) que hayan sido modificados o no
desde la ltima actualizacin.
Actualizacin diferencial (DELTA): actualizacin que solo sustituye los elementos de
configuracin que han cambiado desde la ltima actualizacin.
Acuerdo de nivel de explotacin: expresin en trminos tcnicos del acuerdo de nivel
de servicio firmado por los usuarios, y que expresa de manera particular los recursos
tcnicos y humanos que se deben utilizar.
Acuerdo de nivel de servicios: documento que define los objetivos concretos y
especficos para el servicio considerado. Compromete a las dos partes (clientes y
proveedores, u organizacin TI si el cliente es un servicio interno de la empresa), en lo
relativo a los niveles esperados en trminos de disponibilidad, capacidad y costes, y
permite la evaluacin del rendimiento de la organizacin informtica durante el suministro
y soporte de este servicio.
Adaptabilidad: capacidad de un servicio para cambiar su nivel de rendimiento y costes,
como consecuencia de un cambio en la peticin o en la infraestructura.
Ajuste: actividad dedicada a adaptar los parmetros de un componente
infraestructura o servicio, con el objetivo de obtener una mejora del rendimiento.
de
la
Alerta: mensaje electrnico que proviene de un sistema de monitorizacin automtico

informando de que se ha alcanzado un umbral o se produce o se puede producir un fallo.
Amenazas: causas eventuales de una perturbacin que acta sobre la infraestructura

(hardware, software o servicios) y que podran dificultar el suministro de los servicios.
Amortizacin: medida de la disminucin del valor de un activo a lo largo del tiempo,
desde un punto de vista contable, sea cual sea la causa del desgaste u obsolescencia.
Anlisis de impacto: identificacin de los procesos de negocio crticos y las prdidas o
daos potenciales que pueda causar a la empresa como consecuencia de un
funcionamiento incorrecto de estos procesos.
Anlisis de los fallos del sistema: tcnica diseada para proporcionar un enfoque
estructurado de la identificacin de las causas subyacentes de los funcionamientos
incorrectos en el suministro de los servicios.
Anlisis del riesgo: identificacin de la importancia de los componentes de la
infraestructura (los elementos de activos), de las amenazas a las que estos componentes
puedan estar expuestos y de su vulnerabilidad frente a las amenazas identificadas.
Anomala: condicin que causa la imposibilidad de una unidad funcional para ejecutar la
funcin requerida.
Asistencia: servicio que corresponde al suministro de ayuda y de soporte que la direccin
informtica aporta al cliente.
Atributo: caracterstica descriptiva de un elemento de configuracin registrado en la base
de datos de la gestin de configuraciones (por ejemplo: tipo de CI, marca o modelo,
proveedor...).
Auditora: proceso de inspeccin y verificacin utilizado para validar que una actividad se
realiza segn un estndar aceptado o segn la mejor prctica reconocida.
Base de datos de la gestin de las configuraciones: base de datos que reagrupa la
informacin de configuracin e histrica de todos los elementos de configuracin (CI), as
como las relaciones establecidas entre estos CI.
Biblioteca de software definitivo (Definitive Software Library o Definitive Media
Library): es la biblioteca en la que se guardan las versiones definitivas y autorizadas de
todos los CI de software. En realidad, esta zona de almacenamiento puede estar formada
por una o varias bibliotecas lgicas o fsicas.
Cadena de valor: sucesin de actividades que crea un producto o servicio susceptible de
generar un valor de mercado o permitir a la empresa aumentar su cifra de negocios.
Calendario de cambios: calendario que contiene los detalles de todos los cambios
aprobados para la implementacin y sus fechas de ejecucin propuestas.
Cambio: modificacin voluntaria de un elemento de configuracin de la infraestructura,
con el objetivo de cambiar su comportamiento, capacidad o estado.
Cambio de urgencia: modificacin de un componente de la infraestructura planificado y
puesto en marcha en un plazo muy corto, con el objetivo de evitar un riesgo potencial
importante o reducir el impacto para el sistema de informacin.
Cambio estndar: modificacin frecuente conocida y controlada usando procedimientos

de puesta en marcha precisos y sin necesidad de pasar por el comit consultivo de
cambios.
Capacidad: potencia, rendimiento, velocidad o volumen de un componente o de la
infraestructura.
Catlogo de servicios: documento producido bajo la responsabilidad del proceso de
gestin del catlogo, con el objetivo de informar a los clientes y usuarios de los servicios y
la infraestructura disponibles.
Categora: clasificacin por grupos distintos de los elementos de configuracin como
hardware, cambio o problema.
Categorizacin de las incidencias: clasificacin que permite jerarquizar las incidencias.
Centro de beneficio: modo de organizacin contable en el que una actividad de negocio
interna de la empresa se percibe como una actividad independiente, cuyos objetivos se
definen por la Direccin de la empresa, pero que es susceptible de generar beneficios,
incluso si estos se logran en detrimento de otras actividades de la empresa.
Centro de coste: modo de organizacin contable en el que una actividad de negocio solo
se percibe a travs de sus gastos.
Centro de llamadas: interfaz entre los usuarios y la informtica, dedicada a la recepcin
de llamadas telefnicas de peticin de asistencia, consultas o quejas.
Centro de servicios: el centro de servicios se llama en la actualidad SPOC (Single Point of
Contact), ya que permite al usuario acceder al conjunto de servicios especializados a travs
de un nico punto de contacto. El centro de servicios tambin sustituye a un rol de gestin
de las incidencias, ofreciendo un recurso tcnico de primer nivel y teniendo en cuenta todas
las peticiones, quejas o consultas de los usuarios.
Ciclo de vida: descripcin de las diferentes etapas de la duracin de uso de un producto,
servicio o proceso.
Ciclo de vida de las incidencias: progreso del estado de
funcionamiento incorrecto del servicio que va desde la
funcionamiento incorrecto hasta la restauracin del servicio,
diagnstico del origen, reparacin o solucin temporal del
operativa.
un evento, que implica un

aparicin o deteccin del
pasando por las etapas de
fallo en la infraestructura
Ciclo de vida de los problemas: progreso del estado de la causa de una anomala que
afecta al sistema de informacin, que pasa por la identificacin de la causa, elaboracin de
una solucin temporal o permanente y peticin de cambio eventual, para poner en marcha
esta solucin.
Clasificacin: actividad de agrupamiento de los elementos de configuracin (CI) por tipo
(hardware, software, procedimientos, documentos o servicios externos).
Cliente: el que especifica las necesidades de negocio, con quin se ha acordado los
servicios que se tienen que entregar y quin es responsable de su financiacin.
Comit consultivo de cambios: analiza los impactos y proporciona los consejos al cliente
sobre los cambios (no los autoriza). Asiste al gestor de cambios en la evaluacin,
priorizacin y planificacin de los cambios. Se compone de las propiedades del proceso
tctico y del proceso de gestin de cambios, del responsable de la seguridad, del cliente,
del representante o de los representantes de los usuarios y de los especialistas si es
necesario.
Comit de urgencia de cambios: reunin de urgencia de un comit consultivo de
cambios, restringido a los miembros imprescindibles para la evaluacin de un cambio
urgente.
Configuracin bsica: imagen congelada del estado de un elemento de configuracin (CI)
o de un conjunto de CI, con el objetivo de evaluar el impacto de un cambio en la
infraestructura o asegurar que la infraestructura se puede restaurar rpidamente.
Contabilidad: conjunto de actividades que permiten a la organizacin informtica
identificar, clasificar y justificar sus gastos financieros.
Contramedida: accin que se toma para reducir el riesgo o su impacto sobre el sistema
de informacin.
Contrato: Acuerdo formal entre dos personas, sometidas a las restricciones legales en
vigor.
Contrato de subcontratacin: contrato con un proveedor externo para obtener una
prestacin de servicios que permita el suministro de los servicios informticos. De esta
manera, hablamos de contrato de tipo UC (Underpinning Contract).
Control de configuraciones: actividad que asegura que solo los elementos de
configuracin (CI) autorizados e identificados se usan en la infraestructura informtica de la
empresa.
Convivialidad: capacidad de un servicio, aplicacin o hardware de utilizarse de manera
sencilla, intuitiva y sin formacin excesiva.
Coste de funcionamiento (de explotacin, produccin...): representa los gastos de
explotacin diaria de una organizacin (costes en personal, mantenimiento del hardware,
electricidad...).
Coste de transferencia: representa el coste de las prestaciones suministradas de una
divisin de la empresa a otra.
Coste de los servicios externos: representa los costes de los servicios adquiridos a los
proveedores externos.
Coste directo: representa los costes que se pueden imputar totalmente a un cliente (por
ejemplo: aplicacin contable que se imputa a la Direccin financiera).
Coste fijo: representa un coste que no vara con el volumen de uso o las evoluciones de la
actividad de la empresa.
Coste indirecto: representa un coste que no se puede imputar completa y directamente a
un nico cliente o servicio, por lo que cuyo valor se debe repartir entre los diferentes
actores (por ejemplo: mensajera utilizada por toda la empresa).
Coste marginal: representa el coste de produccin de una unidad adicional antes de la
aplicacin del sistema de produccin. Incluye principalmente los costes de materia prima,
mano de obra y amortizacin del sistema. El inters de este valor es demostrar que el
coste de posesin de un equipamiento no es simplemente su coste de compra y tambin

permite confirmar que el coste de produccin de una unidad disminuye con el volumen
producido.
Coste total de posesin: representa el coste acumulado de todos los elementos que
componen un servicio o un equipamiento. Dicho de otra manera, el precio de compra inicial
incluye los costes de personal, mantenimiento, transferencia, materias primas
consumibles...
Coste variable: representa un coste que evoluciona en funcin del volumen de uso de un
servicio, materias primas o de un producto.
Cultura de servicio: base sobre la que se debe construir la organizacin TI. La
satisfaccin del cliente es la prioridad ms importante de la organizacin TI y las
actividades de puestas en marcha contribuyen a estos objetivos.
Definitive Hardware Storage: zona de
informticos de recarga.
almacenamiento seguro de los equipos
Definitive Media Library o Definitive Software Library: biblioteca en la que se

guardan las versiones definitivas y autorizadas de todos los CI de software. En realidad,
esta zona de almacenamiento puede estar formada por una o varias bibliotecas lgicas o
fsicas.
Diagnstico: tercera etapa del ciclo de vida de una incidencia durante la que el equipo
informtico intenta identificar su origen.
Dimensionamiento de la aplicacin: actividad de evaluacin de los recursos necesarios
para una aplicacin nueva y adicin o mejora de una aplicacin existente.
Disponibilidad: indica la capacidad de un sistema para hacer su funcin durante un
tiempo dado. Normalmente, este valor se expresa como un porcentaje del tiempo durante
el que el sistema est disponible, en relacin con el horario de servicio negociado en el
SLA.
Duracin media de disponibilidad (MTBF): duracin media durante la que el servicio
est disponible. Este tiempo tambin se llama Up Time o tiempo de disponibilidad.
Duracin media de reparacin (MTTR): duracin media de reparacin, tambin
llamada Down Time o tiempo de no disponibilidad. Es el tiempo que transcurre entre el
momento en que se produce la incidencia y el momento en que se restaura el servicio.
Incluye el tiempo de deteccin, diagnstico (o tiempo de respuesta), reparacin,
restauracin y recuperacin.
Duracin media entre dos incidencias (MTBSI): tiempo entre dos incidencias.
Eje sobre el cliente: basado en los objetivos del cliente.
Elemento de configuracin: representa cualquier componente de la infraestructura
informtica referenciado en la base de datos de configuraciones (CMDB), como el
hardware, el software, documentacin o documentos de la organizacin (contratos,
acuerdos, formularios, procedimientos...).
Ensamblado: etapa final en la produccin de una configuracin, utilizable a partir de un
conjunto de elementos de configuracin para obtener un paquete de software o hardware a
instalar.
Entorno: conjunto de hardware, software, procedimientos, etc., funcionando de manera

conjunta, con el objetivo de proporcionar un servicio.
Entorno de produccin u operativo: sistema informtico que se usa para proporcionar
el servicio solicitado por los usuarios.
Entorno de prueba: sistema informtico compuesto de hardware, software y
documentacin, que se usa para probar los cambios antes de implantarlos en el entorno de
produccin.
Error conocido: causa identificada del funcionamiento incorrecto de un componente de la
infraestructura, sin que por el momento se haya implantado obligatoriamente una solucin
definitiva.
Evaluacin de riesgos: actividad que permite analizar los riesgos potenciales y sus
consecuencias en el sistema de informacin y, por extensin, en la actividad de la
organizacin TI o de la empresa.
Evento: todo evento detectable o perceptible que pudiera tener un impacto significativo en
la gestin de la infraestructura informtica o la entrega de un servicio.
Externalizacin: operacin que consiste en transferir los servicios realizados internamente
en la empresa a un proveedor externo.
Facturacin: actividad de creacin y emisin de una factura para recuperar la cantidad
acordada en el suministro de un servicio.
Fase de alerta: primera fase del plan de continuidad de actividad durante el que se inician
las acciones urgentes y la evaluacin de los daos.
Fase de invocacin y de recuperacin: la segunda fase de un plan de recuperacin de
las actividades del negocio durante la que se lanzan los procedimientos de reparacin,
restauracin y recuperacin de los servicios.
Fiabilidad: corresponde a la aptitud de un sistema para funcionar de manera perdurable,
con incidencias o interrupciones mnimas.
Funciones vitales para el negocio (VBF - Vital Functions Business): agrupa las
funcionalidades que soporta uno o varios servicios informticos, cuya no disponibilidad
puede tener consecuencias graves para la actividad de la empresa.
Gestin de la capacidad del negocio (BCM - Business Capacity Management):
actividad de la gestin de las capacidades que permite asegurar que se tienen en cuenta
las necesidades futuras en materia de servicios informticos.
Gestin de la capacidad de los recursos (BCR - Business Capacity Resource):
actividad de gestin de las capacidades que permite asegurar que los recursos informticos
existentes se vigilan y miden, y que se tiene en cuenta el suministro de las nuevas
tecnologas.
Gestin de la capacidad de los servicios (SCM - Service Capacity Management):
actividad de la gestin de las capacidades que permite asegurar que los recursos cumplen
los objetivos de los servicios informticos firmados en los acuerdos de nivel de servicios.
Gestin de la continuidad del negocio (BCM - Business Continuity Management):

proceso de evaluacin de los errores y las consecuencias que pueden tener en las funciones
y procesos de negocio crticos, para asegurar que la empresa est en condiciones de
responder de manera planificada y preparada.
Gestin de la disponibilidad: proceso responsable del diseo, implementacin y control
de la disponibilidad de los servicios informticos.
Gestin de las capacidades: proceso encargado de definir y controlar las necesidades de
la empresa en materia de capacidad informtica, con el objetivo de proporcionar esta
capacidad en el momento adecuado y con un coste ptimo.
Gestin de cambios: proceso responsable de controlar y gestionar las peticiones de
cambios de la infraestructura y los servicios.
Gestin de configuraciones: proceso de planificacin, identificacin, control
verificacin de los elementos de configuracin, que componen la infraestructura.
Gestin de incidencias: proceso de gestin cuyo objetivo es restablecer un servicio

operativo tan rpidamente como sea posible, minimizando el impacto en la empresa y
asegurando que se mantienen los niveles de servicio y disponibilidad acordados.
Gestin de las crisis: proceso de estimacin de los impactos como consecuencia de un
error grave e identificacin de los modos de accin que permitan sobrevivir.
Gestin de problemas: proceso de gestin cuyo objetivo es minimizar el impacto sobre la
empresa de las incidencias y problemas que provienen de errores de la infraestructura, y
prevenir la aparicin de incidencias, problemas y errores de manera proactiva.
Gestin de riesgos: actividad de identificacin de los riesgos que puedan afectar a la
empresa y de identificacin de las contramedidas adoptadas y justificadas, desde un punto
de vista financiero.
Gestin financiera: proceso responsable de la presupuestacin, contabilidad y facturacin
de los servicios informticos.
Histrico de cambios: informacin de seguimiento del iniciador, origen, fecha y contenido
de los cambios.
Horas/Horario de mantenimiento: horario acordado de disponibilidad del soporte de los
servicios.
Horas/Horario de servicio: horario acordado de disponibilidad del servicio.
Impacto: medida de las consecuencias que tiene o puede tener un evento (incidencia,
problema, error grave o cambio) en la empresa.
Imputacin: asignacin de los costes de produccin de los servicios informticos, con
vistas a su imputacin a uno o varios clientes en forma de facturacin real o ficticia.
Incidencia: corresponde a un evento quo no forma parte del funcionamiento normal de un
sistema (servicio, procedimiento, software, hardware...) y que causa o puede causar una
alteracin de la calidad de los servicios y de la productividad del cliente.
Infraestructura: agrupa el conjunto de componentes (elementos de configuracin) que se

usan en el suministro de los servicios informticos y de telecomunicacin a los usuarios
(hardware informtico
y de telecomunicaciones, software, oficinal, personal,
documentacin...).
Interfaz: relacin de interaccin fsica o funcional entre los elementos de configuracin.
Mantenimiento de los servicios: agrupamiento lgico dentro del repositorio ITIL de los
cinco procesos de gestin de configuraciones, incidencias, problemas, cambios y
actualizaciones.
Medida de reduccin de riesgo: medida adoptada para reducir la probabilidad o las
consecuencias de la aparicin de un error en las actividades de la empresa.
Mejora continua: principio segn el cual todos los aspectos del suministro y
mantenimiento de los servicios se reevalan regularmente, para identificar las mejoras
potenciales, sobre todo en trminos de eficacia. Este principio se basa en la Rueda de
Deming.
Mtricas de disponibilidad informtica: conjunto de mtricas que se usan para medir la
disponibilidad, fiabilidad, mantenibilidad y el tiempo de respuesta de los servicios
informticos.
Modelo de coste: reparto de los costes de produccin de los servicios informticos, con el
objetivo de calcular el coste total de estos servicios antes de facturarlos a los clientes.
Modelo de coste por cliente: costes identificados y distribuidos para cada cliente del
servicio.
Modelo de coste por servicio: costes identificados y distribuidos sobre los servicios
informticos que se proporcionan al cliente.
Modelo de incidencia: conjunto estructurado de preguntas empleadas por el personal del
centro de servicios para permitir la resolucin rpida o la asignacin precisa de las
incidencias. El personal tcnico mantiene y proporciona escenarios de diagnstico como
una de sus responsabilidades dentro del proceso de la gestin de las incidencias.
Objetivo de continuidad del negocio: definicin del detalle y permetro de recuperacin
de la actividad despus un error grave, incluyendo personal, infraestructuras y servicios.
Objetivos de negocio: objetivos medibles, elaborados con el objetivo de ayudar a la
realizacin de la estrategia de la empresa.
Objetivos de nivel de servicios: equivalente al documento de especificaciones de un
servicio, este documento corresponde a la expresin de las necesidades de los clientes de
la organizacin TI, en trminos de servicio.
Organizacin: estructura que corresponde a la dimensin organizacional. Puede ser el
servicio informtico, como entidad especfica de la empresa.
Periodo de convivencia del servicio: horario de disponibilidad acordado en el SLA de un
servicio informtico.
Periodo de no disponibilidad: periodo situado en los horarios de servicio acordados
durante el que el servicio no est operativo.
Peticin de cambio o RFC(Request For Change): formulario que se utiliza para

describir un cambio solicitado. El cambio puede afectar a cualquier componente o servicio
de la infraestructura informtica.
Peticin de servicio: peticin de cambio menor que no afecta a la infraestructura y no
justifica la intervencin del comit consultivo de cambios, como por ejemplo la modificacin
de una contrasea o la instalacin de un puesto de trabajo nuevo.
Plan: documento formal que describe los objetivos, la planificacin y los recursos que hay
que poner en marcha en un proceso.
Plan de capacidad: este plan sirve para gestionar los recursos necesarios para el
suministro de los servicios informticos a diario, y tambin para tener una visin de las
necesidades futuras.
Plan de continuidad de las actividades de negocio: describe las funciones,
responsabilidades y acciones necesarias que permiten retomar las actividades del negocio
crticas despus de un error grave.
Plan de continuidad de los servicios: este plan describe las acciones y procedimientos
que la direccin informtica debe seguir en caso de error grave, para retomar el suministro
de los servicios crticos para el negocio.
Plan de la calidad de los servicios: este plan describe los objetivos internos que hay que
alcanzar durante un periodo dado, para mejorar los niveles de servicio acordados y la
percepcin de la calidad que la empresa tiene de estos servicios.
Plan de la disponibilidad: plan que permite asegurar que las necesidades de
disponibilidad de los servicios TI actuales y futuras se pueden satisfacer de manera
rentable.
Plan de despliegues: plan que describe los mtodos, planificaciones y recursos
necesarios para implantar las actualizaciones en produccin.
Plan de vuelta atrs: este plan describe las acciones que se tiene que tomar para
restablecer el servicio despus de una actualizacin sin xito.
Poltica de facturacin: conjunto de reglas y decisiones de la empresa, respecto a la
facturacin y cobro, que la direccin informtica debe poner en marcha para justificar sus
finanzas.
Potencial de mantenimiento externo: capacidad para disponer de los servicios de
proveedores externos, con el objetivo de mantener un CI de la infraestructura en estado de
funcionamiento, para que pueda ejecutar las funciones requeridas.
Potencial de servicio externo: capacidad para disponer de la asistencia de proveedores
externos para configurar un Cl de la infraestructura.
Precio con margen: coste de produccin al que se aade un margen equivalente a un
porcentaje de este coste.
Precio del mercado: precio idntico o comparable al que generalmente facturan los
proveedores externos por el mismo servicio.
Precio fijo: precio acordado con un cliente para un servicio dado en un periodo dado.
Prestacin: suministro de un bien o de un servicio a un cliente. En el contexto ITIL,

tambin hablamos de servicio.
Presupuestacin: ciclo peridico de previsin, negociacin y control de los gastos de la
organizacin informtica.
Primer nivel de asistencia: recursos tcnicos y de gestin presentes dentro del centro de
servicios que permiten resolver rpidamente las incidencias sencillas.
Prioridad: valor que se basa en el impacto sobre el negocio y la urgencia asignada a una
incidencia, problema o cambio, para indicar su importancia relativa en la cola de gestin de
estos eventos.
Problema: origen desconocido subyacente en una o varias incidencias existentes o
potenciales.
Proceso de escalado: es el enrutamiento de una incidencia, problema o cambio a un nivel
de asistencia superior, por razones tcnicas o jerrquicas.
Programa de mejora de servicios (Service Improvement Plan): plan formal de
puesta en marcha de mejora continua de la calidad y eficacia de los servicios informticos.
Afecta a un proceso o servicio que suministra la organizacin TI.
Propietario del proceso: persona sobre la que recaen los acuerdos del proceso. Su
funcin es asegurar la eficacia de un proceso. Es responsable del diseo, la gestin de
cambios, la mejora continua del proceso y sus medidas.
Proveedor de servicios: organizacin interna o externa que suministra los servicios o
productos a los clientes. Algunas de estas organizaciones pueden albergar determinadas
aplicaciones de la empresa en sus oficinas. Por tanto, se trata de un proveedor de
alojamiento de aplicaciones (ASP - Application Service Provider).
Proveedor externo: tercera parte responsable del suministro o mantenimiento de uno o
varios elementos del sistema de informacin.
Proveedor interno: unidad responsable del suministro de los servicios informticos dentro
de la empresa, independientemente de su pertenencia efectiva a esta.
Pruebas de integracin: pruebas realizadas en un entorno tan prximo como sea posible
al entorno de produccin. El conjunto de componentes de hardware y software implicados
en un cambio se tienen que identificar para asegurar que funcionan correctamente en
conjunto.
Recuperacin: operacin de relanzamiento de la actividad como consecuencia de un fallo.
Esta operacin agrupa las acciones de reparacin y restauracin de uno o varios elementos
de configuracin o de un servicio.
Recuperacin gradual: inicio en fro. Opcin de la continuidad de los servicios
informticos. La recuperacin de la actividad de la empresa se hace en un plazo que puede
ser de hasta varios das despus de un error grave.
Recuperacin inmediata: inicio inmediato. Opcin de la continuidad de los servicios
informticos. La recuperacin de los servicios es instantnea o casi inmediata (menos de
24 horas) en el caso de un error grave.
Recuperacin intermedia: inicio intermedio. Opcin de la continuidad de los servicios

informticos. La recuperacin de los servicios es rpida (entre 24 y 72 horas) en caso de un
error grave.
Redundancia: mtodo que se usa para eliminar los puntos de debilidad nicos, mediante
la duplicacin de los elementos de configuracin (CI), cuya no disponibilidad puede
perturbar la actividad del servicio.
Registro: informacin individual o compuesta contenida en una base de datos.
Registro de actualizacin: registro que contiene la informacin de la historia de una
actualizacin, as como de los elementos de configuracin a los que afecta.
Registro de cambio: registro que contiene la informacin de un cambio, junto con los
diferentes componentes a los que afecta.
Registro de cambios: lista exhaustiva que agrupa la informacin de las peticiones de
cambio (evaluacin, pruebas, decisiones, estado actual...).
Registro de error conocido: registro que contiene la informacin y el histrico de un
error conocido.
Registro de incidencia: registro que contiene la informacin y el histrico de una
incidencia.
Registro de problema: registro que contiene la informacin y la historia de un problema.
Relacin: interdependencia o conexin entre los componentes de la infraestructura, los
servicios o los procesos de la direccin informtica. Las relaciones permiten evaluar el
impacto potencial de un cambio, un funcionamiento incorrecto o de un fallo.
Resistencia: es la capacidad de un sistema o componente para continuar funcionando
incluso si una parte de los elementos del sistema o del componente ha fallado.
Restauracin del servicio: actividad de puesta a disposicin de los usuarios de un
servicio o de los datos imprescindibles para su trabajo.
Revisin postimplementacin: reunin de evaluacin de un cambio despus de su
implementacin para determinar si se ha implementado con xito y si se obtienen los
beneficios previstos.
Riesgo: evaluacin de la probabilidad de que una perturbacin se produzca y haya
prdidas potenciales como resultado de ella.
Segundo nivel de asistencia: agrupa las personas que tienen competencias tcnicas
avanzadas, implicadas en la gestin de incidencias y problemas no resueltos por los
equipos de primer nivel.
Servicio: en el marco de ITIL, un servicio puede tener dos sentidos diferentes: una
organizacin o una prestacin.
Solucin de seguridad: hardware, software y procedimientos aplicados para asegurar la
disponibilidad de los componentes de la infraestructura que sufren un fallo.
Solucin temporal: solucin provisional que permite recuperar el servicio en las

condiciones lo ms cercanas posible a un funcionamiento normal.
Tarificacin: elaboracin de la poltica tarifaria y establecimiento de las tasas de
facturacin que se aplicarn a los clientes.
Tasa de resolucin de primer contacto: proporcin de incidencias resueltas desde el
primer contacto entre el usuario y el centro de servicios. Esta tasa se expresa en un
porcentaje de las incidencias registradas por el centro de servicios durante el mismo
periodo.
Tasa en vigor: modo de facturacin de los servicios informticos en el que los precios
propuestos son comparables a los de otras organizaciones parecidas.
Tecnologa de la informacin y las comunicaciones (TIC): conjunto de tecnologas de
tratamiento y transferencia de datos, segn las instrucciones programadas, para extraer
resultados. Incluye la informacin de tipo texto, imagen, vdeo, sonido...
Tipo de coste: los componentes de los servicios informticos se clasifican por un tipo de
componente como hardware, software, personal, instalacin, servicio externo... Esto
permite elaborar un modelo de coste.
Tipo de llamada: todas las llamadas recibidas en el centro de servicios se clasifican segn
su tipo. Este tipo se puede definir en funcin de su asunto, destino, importancia...
(ejemplo: incidencia, consulta, peticin de servicio, queja...).
Tolerancia a las averas: capacidad de un servicio o un sistema para continuar su
actividad cuando se produce un error. Ver tambin Resistencia.
Tratamiento de los errores: actividad que elabora una solucin que permite resolver un
error conocido (la causa), pasando eventualmente por una peticin de cambio en la
infraestructura.
Tratamiento de los problemas: actividad que identifica la causa de un probl

Entender ITIL 2011normas y Mejores Prácticas para Avanzar Hacia ISO 20000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Entender ITIL 2011normas y Mejores Prácticas para Avanzar Hacia ISO 20000

Uploaded by

Copyright:

Available Formats

Entender ITIL

Los procesos de la estrategia de servicios

ITIL Y LAS NORMAS

1990: publicacin de los primeros elementos por el organismo gubernamental

1991: primer examen de certificacin ITIL.

2001: publicacin de la segunda versin de ITIL (ITIL V2).

2005-2006: evolucin importante en el mbito de las certificaciones.

2007: publicacin de ITIL-Refresh (ITIL V3).

2011: publicacin de la nueva versin (ITIL 2011).

Describe las mejores prcticas de gestin de los servicios de TI.

Pertenece al dominio pblico.

Es independiente de los fabricantes de TI (software y hardware) y de las empresas

Loyalist College (LCS)

A raz de los trabajos de la organizacin britnica de normalizacin, ha visto la luz la norma

Atencin: el programa de certificacin puesto en prctica actualmente por APMG y OGC ha

System - Sistema de Gestin de la Configuracin); cmo se gestiona en este caso la

3. Las versiones de ITIL

Presentacin de la estructura de ITIL V2

El suministro de servicios (Service Delivery), que se refiere a los procesos necesarios

b. Los procesos ITIL V2

Gestin de niveles de servicios

Gestin de la continuidad de los servicios

Presentacin de la estructura de ITIL V3

Mejora continua de servicios

d. Los procesos ITIL V3

Mejora continua de servicios

Nivel decisional: Estrategia de servicios (Procesos estratgicos)

Gestin del porfolio de servicios

Nivel decisional: Diseo de servicios (Procesos estratgicos y tcticos)

Gestin del catlogo de servicios

Gestin del nivel de servicios

Gestin de la continuidad de los servicios informticos

Gestin de la seguridad informtica

Nivel decisional: Transicin de servicios (Procesos tcticos y operativos)

Gestin de los activos de servicios y configuraciones

Gestin de los despliegues y de las entradas en produccin

Validacin y prueba de los servicios

Gestin del conocimiento

Nivel decisional: Explotacin de los servicios (Procesos operativos)

Valor para las empresas

Estandarizacin de los procesos

Valor para las empresas

Polticas, principios y conceptos bsicos

Actividades del proceso

Activadores, entradas, salidas e interfaces

Factores de xito crticos

Riesgos y oportunidades (cuando se implementan)

f. Los procesos ITIL 2011

Mejora de los procesos en siete etapas

Nivel decisional: Estrategia de servicios (Procesos estratgicos)

Gestin de la estrategia de servicios

Gestin del porfolio de servicios

Gestin de la relacin comercial

Nivel decisional: Diseo de servicios (Procesos tcticos)

Coordinacin del diseo

Gestin del catlogo de servicios

Gestin de los niveles de servicios

Gestin de la continuidad de los servicios informticos

Gestin de la seguridad informtica

Nivel decisional: Transicin de servicios(Procesos tcticos y operativos)

Planificacin y soporte de la transicin de servicios

Gestin de los activos de servicios y configuraciones

Gestin de los despliegues y de las entradas en produccin