Material de

descargaArchivos

Entender ITIL adicionales

Publicación: octubre
2012
2011Normas y Ref. ENI : DPT11ITI
ISBN : 9782746076181
mejores prácticas para Share on facebookShare
on email
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 organización.

El libro está estructurado a partir de la

noción de «ciclo de vida de los servicios ».
El libro servirá de hilo conductor para
aquellos que ya hayan seguido
una formación ITIL Foundation
(Versión 3 o 2011) y permitirá, a todos
los que aún no tienen ningún conocimiento
sobre la materia, descubrir y entender
las contribuciones de ITIL en la gestión
de los servicios, así como
la metodología para tener éxito en la
implantación ITIL en la empresa,
independientemente de su tamaño.

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 posiblecertificación ISO 20000. Para
ello, se dedica una serie de capítulos a
lasnormas, métodos y herramientas que
facilitan la puesta en marcha y gestión 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 anidación de los procesos y las
implicaciones que esto tiene.

El último capítulo presenta un caso

práctico de puesta en marcha de un
proyecto ITIL en una empresa y permite
entender mejor el desarrollo de este tipo de
proyectos.

Los capítulos del libro:

Prefacio – Prólogo – ITIL y las normas – El
ciclo de vida de la gestión de los servicios –
 Los procesos de la estrategia de servicios –
Los procesos del diseño de los servicios –
Los procesos de la transición de los
servicios – Los procesos de la explotación
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 años en
los proyectos de Experto en Calidad que ha
desarrollado en diferentes empresas. Es toda esta
experiencia, tanto técnica como pedagógica, la que hoy
le permite proponer un libro claro y práctico de la
puesta en marcha del referencial ITIL.

Prefacio
En el mundo actual, la gestión de una empresa obliga a tener múltiples competencias,
conocimientos y herramientas adaptadas. Al mismo tiempo, la empresa se debe enfrentar a
retos y restricciones importantes. En este contexto, los sistemas de información juegan un
papel estratégico principal, que tienen influencia incluso sobre la supervivencia de la
empresa. De esta manera, la correcta gestión de los sistemas de información y las
elecciones organizativas determinan, de una manera importante, el buen funciona- miento
de la empresa.

En el momento actual las empresas dependen, cada vez en mayor medida, de sus sistemas
de información, cuyos requerimientos se hacen sentir tanto a nivel financiero como a nivel
de la rapidez con la que la dirección de los sistemas de información debe responder a las
necesidades de las empresas, siempre cambiantes, con una complejidad de los sistemas de
información cada vez más importante. Si además de todo esto consideramos las nuevas
tecnologías, movilidad, distribución geográfica, externalización de los servicios y
conectividad, entenderemos con facilidad que la dirección de los sistemas de información
tengan obligatoriamente que hacer malabares con todos estos elementos para poder
ofrecer servicios de calidad para los negocios.

Así, cada vez más las empresas y su dirección de sistemas de información tienen en
consideración el uso de estándares, métodos y marcos de trabajo de dominio público, con
el objetivo de mejorar la gestión de su sistema de información. Pero existen muchas
opciones y es fácil perderse en este laberinto.

Entre las diferentes opciones relacionadas con la gestión de los servicios, hoy en día ITIL
representa una de las maneras más habituales para estructurar las direcciones de los
sistemas de información de una forma clara y efectiva, basándose en las buenas prácticas
reconocidas a través de todo el mundo. En la actualidad, ITIL está reconocido como un
estándar de facto para la gestión de los servicios informáticos. Pero hay que reconocer que
ITIL, debido a su actual evolución, sigue siendo una materia complicada para un neófito y
es fácil perderse entre las innumerables posibilidades que ofrece.

El presente libro propone, de una manera concisa y precisa, una visión de conjunto de ITIL,
cubriendo todos los procesos, y presenta varias facetas de su aplicación. De esta manera,
es un placer para mí felicitar a Jacques Quesnel por haber tenido éxito en la presentación
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 gestión. 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 través de las múltiples 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 máximo los beneficios que ofrece ITIL, ya sea por
falta de entendimiento de los conceptos o por una incorrecta aplicación de estos. Por este
motivo, la experiencia de Jacques Quesnel representa una mina importante de información
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.

También es importante observar que el libro proporciona una vista de varios métodos,
estándares y marcos de trabajo que permiten aprender la gestión de los sistemas de
información con un enfoque más global, y posicionar ITIL entre sus compañeros de viaje.

Permítanme una última reflexión: poco importan los esfuerzos realizados para emprender
algo; si no hacemos las elecciones correctas, los resultados no serán 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 creación del método TIPA

Participante de los grupos de trabajo ISO 20 000 y 15 504

PROLOGO
Una nueva versión de este libro
Las buenas prácticas ITIL evolucionan.

En 2011, la OGC ha publicado una nueva versión 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 versión se indica por el año de publicación, lo que simplifica la
identificación de las versiones.

Por lo tanto, la nueva versión de ITIL es ITIL 2011.

Sin ser una versión principal, esta versión añade cambios, fundamentalmente en la fase
estratégica del servicio, y explica algunos puntos que no estaban lo suficientemente claros
en la versión 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
«Librería de infraestructura de las tecnologías de información»), es un conjunto de libros en
los que se presentan numerosas prácticas, procedimientos y métodos utilizados en la
gestión de servicios informáticos.

ITIL es una recopilación de las mejores prácticas aplicadas desde hace años en
organizaciones de tamaño más o menos importante.

Por tanto, ITIL se utiliza como línea directriz en la implantación de una gestión de servicios
en un entorno informático.

Los procesos descritos en ITIL se ponen en marcha, en su totalidad o parte de ellos, en

función de su empresa, actividad, tamaño y objetivos estratégicos.

1. Histórico

 1972: comienzo de los trabajos de desarrollo de las prácticas por la CCTA (Central
Computing and Telecommunication Agency).

 1990: publicación de los primeros elementos por el organismo gubernamental

británico CCTA.

 1991: primer examen de certificación ITIL.

 2001: publicación de la segunda versión de ITIL (ITIL V2).

 2005-2006: evolución importante en el ámbito de las certificaciones.

 Finales de 2005: adopción de la norma ISO/CEI 20000 para las empresas, basadas
en el marco ITIL.

 2007: publicación de ITIL-Refresh (ITIL V3).

 2011: publicación de la nueva versión (ITIL 2011).

a. ¿Qué no es ITIL?
ITIL no es:

 Un lenguaje.

 Un proceso.

 Un método.

 Una norma.

b. ¿Qué es ITIL?
Un conjunto de manuales que describen los procesos integrados de gestión de las TI
(tecnologías de la información).

Un marco de referencia global que:

  Describe las mejores prácticas de gestión de los servicios de TI.

 Pertenece al dominio público.

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

de consultoría, 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
mayoría de los países, también en España (http://www.itsmf.es).

Hay ocho organismos de certificación (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 oficial

ITIL: http://www.itil-officialsite.com/ExaminationInstitutes/ExamInstitutes.aspx

A raíz de los trabajos de la organización británica de normalización, ha visto la luz la norma

BS15000, que recoge la mayor parte de las prácticas ITIL.

Desde 2005, esta norma se ha convertido en una norma internacional: ISO/IEC 20000-
2011 (ver la siguiente sección).

Atención: el programa de certificación puesto en práctica 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 más fiable las mejores prácticas de ITIL. El término «Compliant ITIL»
no es en absoluto una garantía 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 Gestión de la Configuración); ¿cómo se gestiona en este caso la
noción de CI (Configuration Item - Elemento de Configuración) a nivel de los puestos de
trabajo o del software?

3. Las versiones de ITIL

a. ITIL V2
Un determinado número de empresas todavía están bajo ITIL V2, aunque podemos pensar
que van a evolucionar hacia ITIL 2011 antes o después.

Presentación de la estructura de ITIL V2

La versión ITIL V2 está formada por 10 libros. Los dos más importantes son:

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

para el diseño y suministro de servicios.

 Los servicios de soporte (Service Support), que se refiere a los procesos necesarios
para el mantenimiento y la asistencia técnica de los servicios.

b. Los procesos ITIL V2

Procesos tácticos

 Gestión de niveles de servicios

 Gestión financiera

 Gestión de la capacidad

 Gestión de la continuidad de los servicios

 Gestión de la disponibilidad

 Gestión de la seguridad
 Procesos operativos

 Gestión de cambios

 Gestión de incidencias

 Gestión de problema

 Gestión de configuraciones

c. ITIL V3
Esta versión de ITIL se publicó en 2007 y representa una evolución importante respecto a
la V2. Los conceptos de la versión anterior se conservan en lo fundamental; sin embargo,
esta versión añade cambios importantes y, en particular, sobre la estructura global.

Esta versión se basa en una noción nueva: el ciclo de vida de la gestión de los servicios.

La versión ITIL 2011 también se basa en esta noción.

Esta noción se detallará en el capítulo El ciclo de vida de la gestión de los servicios.

 Presentación de la estructura de ITIL V3

El núcleo de ITIL V3 se compone de cinco libros principales:

 Estrategia de servicios

 Diseño de servicios

 Transición de servicios

 Operación 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 estratégicos)

 Estrategia de servicios

 Gestión del porfolio de servicios

 Gestión financiera

 Gestión de la demanda

Nivel decisional: Diseño de servicios (Procesos estratégicos y tácticos)

 Gestión del catálogo de servicios

 Gestión del nivel de servicios

 Gestión de la disponibilidad

 Gestión de la capacidad

 Gestión de la continuidad de los servicios informáticos

 Gestión de la seguridad informática

 Gestión de proveedores

Nivel decisional: Transición de servicios (Procesos tácticos y operativos)

 Gestión de cambios

 Gestión de los activos de servicios y configuraciones

 Gestión de los despliegues y de las entradas en producción

 Validación y prueba de los servicios

 Evaluación

 Gestión del conocimiento

Nivel decisional: Explotación de los servicios (Procesos operativos)

 Gestión de eventos

 Ejecución de consultas

 Gestión de incidencias

 Gestión de problemas

 Gestión de la evaluación
e. ITIL 2011
Esta nueva versión de ITIL se presenta como una evolución de la versión V3.

Los puntos más importantes que se tienen en cuenta son:

Estandarización de cada proceso

 Objetivos

 Perímetro

 Valor para las empresas

Estandarización de los procesos

 Objetivos

 Perímetro

 Valor para las empresas

 Políticas, principios y conceptos básicos

 Actividades del proceso

 Activadores, entradas, salidas e interfaces

 Factores de éxito críticos

 Información

 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 estratégicos)

 Gestión de la estrategia de servicios

 Gestión del porfolio de servicios

 Gestión financiera

 Gestión de la demanda

 Gestión de la relación comercial

Nivel decisional: Diseño de servicios (Procesos tácticos)

 Coordinación del diseño

  Gestión del catálogo de servicios

 Gestión de los niveles de servicios

 Gestión de la disponibilidad

 Gestión de la capacidad

 Gestión de la continuidad de los servicios informáticos

 Gestión de la seguridad informática

 Gestión de proveedores

Nivel decisional: Transición de servicios(Procesos tácticos y operativos)

 Planificación y soporte de la transición de servicios

 Gestión de cambios

 Gestión de los activos de servicios y configuraciones

 Gestión de los despliegues y de las entradas en producción

 Validación y prueba de servicios

 Evaluación de los cambios

 Gestión del conocimiento

Nivel decisional: Explotación de los servicios (Procesos operativos)

 Gestión de eventos

 Ejecución de consultas

 Gestión de incidencias

 Gestión de problemas

 Gestión de los accesos

4. La filosofía de ITIL
La filosofía de ITIL se basa en cuatro principios:

 Considerar que la organización 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
organización, ya sea esta grande o pequeña, y a todas las tecnologías.

 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 prácticas más eficaces para utilizar los recursos humanos y tecnologías
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 organización TI.

 Reducir los costes de entrega de los servicios TI a más largo plazo.

Esto implica:

 Una transición, desde una cultura generalmente orientada a la tecnología, hasta una
cultura orientada alrededor del «negocio» y de los servicios.

 Gestionar la organización TI como una unidad de «negocio».

b. Algunas definiciones importantes

Para entender correctamente los objetivos de la puesta en práctica de ITIL, es necesario

definir algunos términos que se utilizarán en este libro, para que tenga una comprensión
clara de su significado.

TI: Tecnologías de la información. Con frecuencia, es el término utilizado para definir la

organización TI, ya sea el servicio informático o la dirección informática, en función del
tamaño de la empresa o de su organización. Algunas veces, la sigla TI se traduce al inglés
y se convierte en IT.

Es la organización que proporciona el servicio al cliente (interno o externo).

Negocio: los términos «profesión», «negocio» o «tarea» tienen el mismo significado.

Según la organización de la empresa cliente, podemos utilizar un término u otro.

El negocio es una denominación de la entidad que utiliza el servicio proporcionado por la

organización 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
específicos que le son propios y para los que se han definido y validado los niveles de
servicio específicos, entre el negocio y la organización TI.

Servicio: medio de proporcionar un valor añadido a los clientes, facilitándoles la obtención

de los resultados esperados, respetando las restricciones de costes y riesgos (ver la
siguiente sección).

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, también es responsable de la financiación de los servicios.
 Usuario: persona que utiliza diariamente los servicios proporcionados por la organización
TI.

Proveedor de servicios: organización 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 organización.

 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 sección).

Propietario de proceso: el propietario de uno o varios procesos es responsable de los

resultados del proceso y rinde cuentas a su dirección.

Responsable de procesos: el responsable de un proceso está encargado de la realización

de un proceso y rinde cuentas al propietario del proceso.

CMS (Configuration Management System): sistema de gestión de configuraciones. En ITIL

V2 hablamos de CMDB (Configuration Management Data Base).

CMDB (Base de datos de gestión de configuraciones): modelo físico que refleja la

infraestructura que contiene todos los CI, su estado y las relaciones entre ellos.
Actualmente, todavía muchas personas hablan de CMDB en lugar de la CMS, por motivos
de comprensión o facilidad.

CI (Elemento de Configuración), componente de la infraestructura o elemento asociado a

una infraestructura, bajo el control de la gestión de configuraciones.

Incidencia: todo evento que no forma parte de las operaciones estándares de un servicio
y que cause o pueda causar una interrupción o reducción de la calidad del servicio.

Petición de servicio: petición 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 práctica?

Una buena práctica se define por varios elementos:

 Se desarrolla a partir de elementos generales aplicables a múltiples 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 prácticas más utilizadas en el entorno informático son las siguientes:
  ITIL, COBIT, CMMI, PRINCE2, PMBOK y Six Sigma.

Las normas más utilizadas en el entorno informático 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 través de una interacción entre cliente, usuarios y

proveedor.

 El cliente y el proveedor pueden ajustar el servicio durante su entrega.

 La satisfacción con un servicio depende, de manera decisiva, de las experiencias

anteriores del cliente, los usuarios, sus expectativas y de una buena gestión de estas
últimas.

Ejemplos de servicios TI:

 Servicio de mensajería electrónica

 Servicio de impresión

 Servicio de utilización 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 adopción de un enfoque a procesos durante el

desarrollo y puesta en práctica de un sistema de gestión de la calidad, en el seno de la
organización. La exigencia de mejora continua de la calidad permite aumentar la
satisfacción de los clientes en relación con sus requerimientos.

ITIL también 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 identificación de las interacciones entre los diferentes
procesos.

Un proceso está formado por una o varias actividades estructuradas y relacionadas.

Un proceso proporciona resultados específicos.

Definición de un proceso
Un proceso es un conjunto de actividades estructuradas y relacionadas para proporcionar
un resultado específico.

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.

Descripción de un proceso

Para obtener un funcionamiento óptimo del sistema de calidad, es necesario vigilar, medir y
analizar estos procesos.

La gestión de estos procesos se realiza para obtener el resultado deseado.

Cuando se utiliza en un sistema de gestión de la calidad, este enfoque destaca la

importancia de:

 Entender y cumplir los requerimientos.

 Considerar los procesos en términos de valor añadido.

  Medir el rendimiento y la eficacia de los procesos.

 Mejorar continuamente los procesos, basándose en mediciones objetivas.

La mejora continua de los procesos se basa en la Rueda de Deming.

f. Definición de los objetivos

La definición de un objetivo debe responder obligatoriamente al acrónimo 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 evolución.

 A de Alcanzable. No sirve para nada fijar objetivos demasiado ambiguos. Esto

también 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.

Atención: tener multitud de objetivos diferentes para un mismo proceso no es acertado.

De manera ideal, un proceso no debería tener más 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 duración de un ciclo es de un año).
Este principio también 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,

basándonos en lo que hemos definido durante la actividad Act.

 Definir los indicadores que permitirán medir la mejora real.

D de Do (Hacer)

En esta fase vamos a:

 Realizar las acciones que se definen en el plan, respetando los objetivos y el

calendario.

C de Check (Controlar)

En esta fase vamos a:

  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 validarán durante el próximo ciclo en el Plan.

h. La calidad
La calidad representa la totalidad de características de un servicio, que le permiten
satisfacer las necesidades identificadas e implícitas.

¿Cómo influye la calidad en el servicio?

 La calidad del servicio refleja la consecución 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 diálogo 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 cuál es el precio razonable asociado a los servicios esperados.

 La calidad del servicio no se puede evaluar de manera anticipada.

Las normas
Más adelante encontrará las diferentes normas, modelos y mejores prácticas utilizadas en
la actualidad en el entorno de los servicios informáticos.

1. ISO 9001:2008

La norma ISO 9001 tiene por objetivo la certificación de las empresas, No obstante,
también existe una certificación 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 gestión de la calidad, y establece los requisitos exigidos para la existencia de un sistema
de gestión de la calidad.

Estos requerimientos servirán como base a la certificación del organismo. Las otras normas
de la serie 9000: vocabulario (ISO 9000), líneas directrices (ISO 9004)... no contienen
requisitos y no pueden servir de base para la certificación.

La versión en vigor de ISO 9001 es la versión de 2008 (aparecida en noviembre de 2008).

La versión ISO 9001:2000 tuvo validez hasta noviembre de 2010.

En relación con la documentación sustituida (ISO 9001:2000), la norma NF EN ISO

9001:2008 no añade ningún requisito nuevo. Únicamente introduce aclaraciones a los
 requisitos existentes de la norma NF EN ISO 9001:2000. También añade 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 adopción de un enfoque a procesos en el momento
del desarrollo y puesta en práctica de un sistema de gestión de la calidad, en el seno del
organismo.

La exigencia de mejora continua de la calidad permite incrementar la satisfacción de los

clientes en relación 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 identificación de las interacciones entre los diferentes
procesos (ver la sección El enfoque a procesos).

Para obtener un funcionamiento óptimo del sistema de calidad, es necesario hacer un

seguimiento, medir y analizar estos procesos.

La gestión de estos procesos se realiza con el objetivo de obtener el resultado deseado.

Cuando se utiliza en un sistema de gestión de la calidad, este enfoque destaca la

importancia de:

 Entender y cumplir los requerimientos.

 Considerar los procesos en términos de valor añadido.

 Medir el rendimiento y la eficacia de los procesos.

 Mejorar constantemente los procesos basándose en medidas objetivas.

b. Los requerimientos de la norma *

* Una parte del texto está extraída 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 están relacionados con cuatro grandes áreas:

 La responsabilidad de la dirección: exigencia de hechos por parte de la dirección,

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 noción de sistema.

 El proceso: requerimientos relativos a la identificación y gestión de los procesos, que

contribuyen a la satisfacción 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 - versión 2008

La puesta en marcha de un sistema de gestión de la calidad según los requerimientos de la
norma ISO 9001-Versión 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 satisfacción de los clientes mediante la aplicación eficaz del

sistema y, en particular, poner en práctica un proceso de mejora continua (según el
principio PDCA o Rueda de Deming).

Los requerimientos de la norma

Los requerimientos de la norma ISO 9001 se presentan en ocho artículos:

 Artículo 1: dominio de la aplicación

 Artículo 2: referencias normativas

 Artículo 3: términos y definiciones

 Artículo 4: sistema de gestión y de calidad

 Artículo 5: responsabilidad de la dirección

 Artículo 6: gestión de recursos

 Artículo 7: realización del producto

 Artículo 8: medida, análisis y mejora

La norma se basa en ocho principios de gestión:

 Orientación a cliente

 Liderazgo

 Implicación del personal

 Enfoque a procesos

 Gestión 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 organización; no es una norma internacional reconocida.

 COBIT (Control Objectives for Information and related Techonology - Objetivos de control
para la Información y Tecnología relacionadas) es una herramienta unificadora que permite
establecer un lenguaje común para hablar de la gestión de los sistemas de información,
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 españolas, 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 legislación de control adoptada en
todo el mundo. Es el resultado de 15 años de búsqueda y cooperación 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 tecnología de la información, como
ITIL, CMMI e ISO 17799. La nueva versión de este repositorio se puede descargar
gratuitamente en el organismo ITGI independiente, sin ánimo de lucro, en la
dirección http://www.itgi.org.

Es un marco de control que tiene como objetivo ayudar en el manejo de la gestión del
riesgo (seguridad, fiabilidad, conformidad) y de las inversiones. COBIT ha evolucionado y la
versión 4 apareció en España en el año 2007.

COBIT es un enfoque orientado a procesos.

Fuente: http://es.wikipedia.org/wiki/CobiT

COBIT descompone los sistemas informáticos 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:

 Planificación y organización (10 procesos)

 Adquisición y puesta en práctica (7 procesos)

 Proveedor del servicio (13 procesos)

 Seguimiento y evaluación (4 procesos)

b. Los seis niveles

Para medir la madurez de los procesos, CobiT utiliza una evaluación 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 prácticas recogidas por los expertos
de SI.

Hoy en día, un número creciente de empresas importantes ponen en práctica el modelo

COBIT para poder proporcionar información clara y comprensible, no solo a sus accionistas,
sino también a las autoridades oficiales de sus países o con los que tienen una actividad o
mantienen relación.

3. CMMI *

CMMI es un modelo de organización, no es una norma internacional reconocida.

CMMI, siglas para Capability Maturity Model + Integration, es un modelo de referencia, un

conjunto estructurado de buenas prácticas, destinado a entender, evaluar y mejorar las
actividades de las empresas de ingeniería.

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 informático del Departamento de Defensa
de los Estados Unidos (DoD). En la actualidad se usa ampliamente en las empresas de
ingeniería informática, por los directores de sistemas informáticos e industriales, para
evaluar y mejorar sus propios desarrollos de productos.

Histórico
En los años ochenta, el departamento de defensa de los Estados Unidos solicitó la
elaboración de un repositorio de criterios que le permitieran evaluar a sus proveedores de
software.

Después de una lenta maduración, 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 prácticas de la ingeniería de software.

Después 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 gestión 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 versión de su modelo, el CMMI ( Capability Maturity
Model Integration), que engloba las buenas prácticas de los otros modelos, salvo la gestión
de recursos humanos, que ya no lo tuvo en cuenta (versión 1.1).

En 2006, se actualizó la versión del modelo (versión 1.2). Esta última versión del CMMI, la
actual, tiende a simplificar el modelo y a mejorar la consideración 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 relación con
esta escala; el equipo puede ser un grupo de trabajo, uno o varios proyectos, una sociedad
e incluso una institución del Estado.

CMMI es un marco genérico 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 (versión publicada

en 2007).

 CMMI-SVC para el suministro de servicios (publicación en febrero de 2009).

La particularidad de estos tres modelos es que tienen una parte común (el núcleo o «core»
en inglés), que representa alrededor del 60% de las prácticas.

De un modelo a otro, las diferencias se centran en la categoría de «ingeniería», cuyas

prácticas varían según la actividad implicada.

El modelo CMMI se utiliza mayoritariamente en las sociedades informáticas; sin embargo,

los principios de CMMI se aplican a cualquier actividad de ingeniería: arquitectura,
mecánica, electrónica...

Madurez
De acuerdo con la definición dada en el CMMI, la madurez de una organización es el grado
con el que esta despliega los procesos explícitamente y de manera coherente, procesos que
se documentan, gestionan, miden, controlan y mejoran continuamente.

Un nivel de madurez (Maturity Level) corresponde a la consecución de un nivel de

capacidad uniforme para un grupo de procesos. Un nivel de capacidad (Capability Level)
mide la consecución de los objetivos de un proceso para el nivel dado.

b. Descriptivo de un modelo
Las buenas prácticas recomendadas por el modelo (versión 1.2), se reúnen 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 están documentados, pero no se utilizan. No hay

supervisión (monitoring), ninguna evaluación de rendimiento y no existe comunicación.

En este nivel, tanto las soluciones como los proyectos son decididos, desarrollados e
instaurados por un individuo.
No hay descripción del nivel 1 de madurez en el modelo.

Reproducible (Managed), nivel de madurez 2

Los planes de proyecto (plan de desarrollo, control de calidad, gestión de configuración...)

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 prácticas de gestión de proyectos de ingeniería.

Estándar (Defined), nivel de madurez 3

En este nivel, se pone en práctica una estandarización adecuada, una capitalización

centralizada (en particular, sobre las medidas realizadas en los proyectos) y un repositorio
de control interno (o sistema de calidad). Existen líneas directrices, un plan estratégico y
una planificación 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

expresión de la calidad solicitada por el cliente para cuantificar los objetivos del proyecto y
establecer los planes, según la capacidad de los procesos de la organización.

Optimizado (Optimizing), nivel de madurez 5

Los procesos que se gestionan cuantitativamente para el seguimiento del proyecto (nivel 4
de madurez) están en continua optimización con el objetivo de anticipar las evoluciones
previstas (necesidades de clientes, nuevas tecnologías...).

Fuente: http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration

4. PRINCE2

PRINCE es un método, no es una norma internacional reconocida. La certificación PRINCE

se destina a las personas, y no a las organizaciones informáticas.

PRINCE es un método y una guía de mejores prácticas en términos de gestión de

proyectos.

PRINCE, originariamente llamado PROMPT, fue adoptado por la OGC en 1989 y aplicado en
los proyectos del gobierno británico.

En 1996, la última versión del método (PRINCE2) fue ampliada y se hizo más flexible para
poder gestionar proyectos de todo tipo y tamaño.

El OGC es el propietario y depositario del método PRINCE2 y, en los orígenes de ITIL,

recoge las mejores prácticas de gestión de servicios informáticos. PRINCE2 es de dominio
público.

Método
Un proyecto es un proceso con un inicio y un fin claramente definidos.
Los proyectos siempre se deben controlar para que tengan éxito.

El método 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 límites de secuencia (LS)

 (CP) - Cerrar un proyecto (CP)

 (PL) - Planificar (PL)

Podemos agrupar estas etapas en cuatro fases:

 Arranque (SU)

 Iniciación (IP)

 Ejecución (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 certificación de empresas. No obstante,

también existe una certificación para las personas: Auditor certificado ISO 20000.

En el origen de la norma ISO 20000, se encuentra la norma británica BS 15000, que se

basa en las buenas prácticas ITIL.

La versión ISO 20000-2011 es la nueva versión publicada.

La norma ISO 20000 se presenta en dos volúmenes.

El primer volumen contiene los requerimientos de la norma, es decir, aquello que se debe
demostrar en el proceso de la auditoría de certificación.

El segundo contiene las mejores prácticas 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 sería conveniente hacer o
cómo 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 gestión de los organismos informáticos en el seno de las
empresas.

Se puede facilitar la puesta en práctica de una certificación ISO 20000 si la empresa ya

está llevando a cabo un proceso de calidad (ha adquirido la certificación ISO 9001 o
simplemente tiene establecido un enfoque a procesos), o si ya se ha realizado un enfoque
ITIL.

Los procesos de gestión de los servicios

ISO 20000-11 hace referencia a 13 procesos.

ISO 20000-2011

Estos 13 procesos se describen en los artículos 3 a 10 de la norma.

El artículo 3 trata de los requerimientos de un sistema de gestión.

 El artículo 3.1 trata de la responsabilidad de la Dirección.

 El artículo 3.2 trata de los requerimientos relativos a la documentación.

 El artículo 3.3 trata de la competencia, sensibilización y formación del personal.

El artículo 4 trata de la planificación y de la puesta en marcha de la gestión de los
servicios.

La siguiente figura ilustra los procesos y relaciones entre los procesos presentes en los
artículos 4 a 10 de la norma.

Rueda de Deming aplicada a los procesos de gestión de servicios

 El artículo 4.1 trata de la planificación de la gestión de los servicios (Planificar).

 El artículo 4.2 trata de la puesta en marcha de la gestión y suministro de los

servicios (Hacer).

 El artículo 4.3 trata del seguimiento, medición y revisión (Verificar).

 El artículo 4.4 trata de la mejora continua (Actuar).

El artículo 5 trata de la planificación y puesta en marcha de las modificaciones o creación

de servicio.
El artículo 6 trata de los procesos de suministro de los servicios.

 El artículo 6.1 trata de la gestión de los niveles de servicio.

 El artículo 6.2 trata de los informes de servicio.

 El artículo 6.3 trata de la gestión de la continuidad y disponibilidad de los servicios.

 El artículo 6.4 trata de la dotación presupuestaria y contabilidad de los servicios

informáticos.

 El artículo 6.5 trata de la gestión de la capacidad.

 El artículo 6.6 trata de la gestión de la seguridad de la información.

El artículo 7 trata de los procesos de gestión de las relaciones.

 El artículo 7.1 trata de las generalidades.

 El artículo 7.2 trata de la gestión de las relaciones comerciales.

 El artículo 7.3 trata de la gestión de los proveedores.

El artículo 8 trata de los procesos de resolución de problemas.

 El artículo 8.1 trata del contexto.

 El artículo 8.2 trata de la gestión de incidencias.

 El artículo 8.3 trata de la gestión de problemas.

El artículo 9 trata de los procesos de control.

 El artículo 9.1 trata de la gestión de las configuraciones.

 El artículo 9.2 trata de la gestión de los cambios.

El artículo 10 trata de los procesos de la puesta en producción.

 El artículo 10.1 trata de los procesos de gestión de la puesta en producción.

EL CICLO DE VIDA DE LA GESTION DE SERVICIOS

Enfoque
En este capítulo vamos a ver cómo se representa la estructura del ciclo de vida de la
gestión de los servicios en ITIL V3 y cuáles son las relaciones entre las diferentes fases del
ciclo y los diferentes procesos y funciones.
El contexto del ciclo de vida de la gestión de los servicios es un contexto organizativo.

Es importante entender correctamente el objetivo del ciclo de vida de la gestión de los

servicios antes de poner en práctica una estrategia ITIL. De su comprensión dependerá, en
parte, el éxito de su proyecto ITIL.

Este ciclo de vida de la gestión 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 gestión al menos una vez cada año.

En cada fase del ciclo de vida de la gestión de los servicios, se efectúan los controles y se
analizan los retornos de la experiencia. Las mejoras se pondrán en práctica en el curso del
ciclo siguiente.

Enfoque del ciclo de vida de la gestión de los servicios

El ciclo de vida de la gestión 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
lógico, ya que los otros procesos se ponen en práctica a partir de las decisiones tomadas y
estrategias definidas por la Dirección informática o la Dirección General de la empresa.

Los otros tres grupos de procesos se representan alrededor de la estrategia de servicios. Se

comienza por el diseño de servicios (Service Design - SD), seguido por la transición de
servicios (Service Transition - ST), para terminar con la explotación 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 gestión de los servicios está formado por las siguientes fases:

 Definir la estrategia de gestión de servicios (Service Strategy - SS).

 Diseñar los servicios con el fin de soportar la estrategia (Service Design - SD).
 Poner en práctica los servicios con el fin de satisfacer las exigencias del diseño
(Service Transition - ST).
 Soportar los servicios de gestión de las actividades operativas (Service Operation -
SO).

Fases del ciclo de vida de la gestión de los servicios

La interacción 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.

Después de la realización de todas las fases del ciclo de vida de la gestión 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 informáticos establece una estrategia:

 Gestionando las exigencias del negocio (proceso de gestión de peticiones).

 Traduciéndola en una estrategia de entrega de servicios (estrategia de servicios).
 Validando la sostenibilidad de los costes (proceso de gestión financiera).
 Introduciendo el servicio en el porfolio de servicios (proceso de gestión del porfolio
de servicios).

En este estado, la organización TI debe utilizar los recursos, lo que tiene un coste, en los
proyectos de consultoría en un nivel estratégico. Durante este periodo, esta estructura no
proporciona valor a la empresa.

Durante la segunda fase, fase de diseño de servicios (Service Design - SD), cuando ya se
ha definido una estrategia, la organización TI comienza a diseñar el servicio:

 Estableciendo las exigencias de «nivel de servicio» de este servicio (proceso de

gestión de nivel de servicio).
 Estudiando la disponibilidad (proceso de gestión de la disponibilidad).
 La capacidad necesaria (proceso de gestión de la capacidad).
 Seleccionando los proveedores que van a soportar el servicio (proceso de gestión de
proveedores).
 Definiendo las disposiciones adecuadas para la continuidad de los servicios (proceso
de gestión de la continuidad de servicios informáticos).
 Validando y estableciendo las exigencias de seguridad (proceso de gestión de
seguridad de la información).
 Añadiendo el servicio al catálogo de servicios (proceso de gestión del catálogo de
servicios).

Durante la tercera fase, fase de transición 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 transición (planificación y soporte en la transición).

 Evalúa, aprueba, pone en marcha y planifica los cambios (proceso de gestión de
cambios).

Antes de la puesta en marcha de estos cambios, el servicio se prueba (proceso de

validación y prueba de servicios) en un entorno lo más parecido posible al futuro entorno
de explotación, pero nunca en el propio entorno de explotación.

Si la prueba tiene éxito, el servicio se documenta (proceso de gestión del conocimiento) y

sus componentes se añaden a la base de datos de los activos y configuraciones (proceso de
gestión de activos de servicio y configuraciones).

La última actividad consiste en poner el servicio en producción en un entorno real (proceso

de gestión de despliegues y entradas en producción).

Para terminar, la última etapa consiste en la satisfacción del cliente, que se mide antes de
cerrar el cambio.

Durante la cuarta fase, fase de explotación 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 (función de centro de servicios
y procesos de tratamiento de consultas).
 Haciendo seguimiento de los eventos y alertas del servicio (proceso de gestión de los
eventos).
 Restaurando el servicio después de un problema (proceso de gestión de incidencias).
 Buscado las causas de las incidencias y reduciendo la duración de estas (proceso de
gestión de problemas).
 Gestionando de manera segura el uso del servicio (proceso de gestión del acceso).
 Manteniendo el software (función de gestión de aplicaciones).
 Ejecutando las actividades diarias (función de gestión de operaciones).
 Soportando la infraestructura (función de gestión técnica).

La fase de mejora continua de los servicios (Continual Service Improvement) se realiza

durante todas las fases del ciclo de vida de la gestión del servicio. Está encargada de medir
el servicio y los procesos (medición de los servicios) y de documentar los resultados
(realización 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 pondrán en práctica durante el próximo periodo del ciclo de vida de la
gestión del servicio, comenzando de nuevo por la estrategia de servicios, seguida del
diseño de servicios y la transición de servicios. La fase de explotación de servicios continúa
gestionando las operaciones durante todos los periodos del servicio.

Los niveles decisionales

En la toma de decisiones en el seno de una organización, se definen tres niveles
decisionales en la versión 3 de ITIL:

 Nivel estratégico: decisiones a largo plazo, que normalmente se toman para

atender ciertas metas y objetivos. Una decisión incorrecta en este nivel tiene a
menudo consecuencias importantes o puede suponer un coste muy elevado. Estas
decisiones se toman a nivel de la Dirección informática o la Dirección General de la
empresa.
 Nivel táctico: decisiones a medio plazo, a menudo destinadas a ser proactivas y a
un nivel intermedio entre las decisiones estratégicas y operativas.
 Nivel operativo: decisiones a corto plazo, a menudo decisiones reactivas, que
tendrán un impacto sobre las operaciones diarias.
 Los niveles decisionales

Estos niveles se utilizan para identificar las decisiones tomadas. También permiten
identificar las líneas de comunicación entre los diferentes niveles. El nivel de comunicación
estratégico generalmente es responsabilidad de la Dirección informática de más alto nivel,
o de la Dirección General de la empresa. Esto depende del tamaño y la estructura de la
organización.

La fase de diseño de los servicios se sitúa entre el nivel táctico y el estratégico. La fase de
transición de servicios se sitúa entre el nivel táctico 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 noción de
proceso, rol y función.

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 función es una unidad, equipo o grupo de personas, junto con los recursos y
herramientas funcionales específicas, para ejecutar un determinado tipo de trabajo y que
serán 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 organización de los TI.
Un rol es un conjunto de responsabilidades, actividades y autoridades específicas
asignadas a las personas de la organización (un grupo o equipo).

Un rol se define en un proceso o función.

Una misma persona o equipo puede tener varios roles.

La noción de rol se usa en la implementación del modelo RACI.

Atención con no mezclar la noción de rol con un título o el nombre de un puesto.

Los procesos y funciones de ITIL 2011

La imagen siguiente ofrece una visión del conjunto de los procesos (representados por
medio de rectángulos) 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 gestión de servicios está compuesta por un determinado
número 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 estratégica de servicios
La estrategia de servicios comienza con el proceso de creación de la estrategia de
servicios genéricos (creación de la estrategia) y continúa con los procesos de
 gestión de la relación comercial, del porfolio de servicios, de los servicios
financieros y de la demanda.
 Fase de diseño de servicios
El diseño de los servicios se aplica a los procesos de:

 Gestión del catálogo de servicios

 Gestión de los niveles de servicio

 Gestión de la disponibilidad

 Gestión de la capacidad

 Gestión de la continuidad de servicios informáticos

 Gestión de la seguridad informática

 Gestión de proveedores

 Fase de transición de servicios

La transición de los servicios se aplica a los procesos de:

 Gestión de cambios

 Gestión de activos de servicio y configuraciones

 Gestión de despliegues y entradas en producción

 Validación y prueba de servicios

 Evaluación

 Gestión del conocimiento

 Fase de explotación de servicios

La explotación de los servicios se aplica a los procesos de:

 Gestión de eventos

 Ejecución de consultas

 Gestión de incidencias

 Gestión de problemas

 Gestión de la evaluación

También explica las cuatro funciones a través de ITIL: centro de servicios,

gestión técnica, gestión de operaciones informáticas y gestión de aplicaciones.

Campo de aplicación 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 capítulo de presentación de la norma, ITIL está compuesto por
procesos estratégicos, tácticos y operativos.
 Los niveles decisionales de la estrategia de servicios

Los procesos de la estrategia de servicios se sitúan en la parte superior de la organización

IT.

El primer objetivo de la estrategia de servicios es definir la estrategia de la organización en

términos de servicios.

2. Los procesos de la estrategia de servicios

 Generación de la estrategia de servicios

 Gestión financiera

 Gestión de la relación comercial

 Gestión de la demanda

 Gestión del porfolio de servicios

Generación de la estrategia
1. Enfoque
En esta sección vamos a ver cómo se definen y ponen en práctica las estrategias de
servicios.

2. ¿Por qué una estrategia de servicios?

La estrategia consiste en tomar una decisión sobre cómo aportar valor a un cliente, en
función de nuestras capacidades y aptitudes (la nuestra y la de nuestros proveedores).
 Esto resulta complicado porque la negociación es compleja e incierta. Se basa en
probabilidades; existe la necesidad de discernir las tendencias y los modos, en constante
interacción.

3. Objetivos del proceso

Los objetivos de la estrategia de servicios son los siguientes:

 Permitir la comprensión de la estrategia que se pone en marcha.

 Proporcionar una definición clara de los servicios que usa el cliente.

 Tener la capacidad de definir cómo se crea y entrega el valor del servicio.

 Identificar las oportunidades de servicios y cómo explotarlos.

 Proponer un modelo de prestación de servicios claro, que establezca cómo se

entregan y financian los servicios, a quién se entregan y con qué propósito.

 Tener las capacidades organizativas necesarias para la ejecución de la estrategia.

 Documentar y coordinar el uso de los activos de servicio para ofrecer un servicio y

cómo optimizar su rendimiento.

 Proporcionar los procesos que definen la estrategia de la organización, los servicios

que permitirán alcanzar la estrategia, qué nivel de inversión será necesario, a qué
nivel de peticiones y los medios de asegurar una relación de trabajo entre el cliente y
el proveedor de servicios.

Para esto, la dirección de la empresa dará la dirección, definirá las políticas, identificará los
proyectos y asignará los recursos.

La estrategia también definirá la priorización de las inversiones.

Para hacer frente a la evolución de la empresa y de su entorno, será necesario revisar esta
estrategia al menos una vez al año.

4. Definiciones
Aptitud: capacidad de una organización, persona, proceso, aplicación, elemento de
configuración o servicio TI para realizar una actividad.

Recursos: término genérico que incluye la infraestructura, personas, medios financieros o

todo aquello que ayude a liberar el servicio.

5. Perímetro
La gestión de la estrategia es responsable de proporcionar varios entregables:

 Los requerimientos para el diseño de servicios.

 Los requerimientos para la transición de servicios.

 Los requerimientos para la explotación de servicios.

6. Conceptos básicos
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 añadido a estos y cómo 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 términos de servicio:

 nuevos servicios,

 servicios mejorados,

 servicios obsoletos.

Para estar en disposición 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. Definición del valor añadido

El valor añadido de un servicio se debe demostrar centrándose en la utilidad y la garantía.

Es este valor añadido el que permitirá a la organización 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 añadido, que ofrecerá mejores
rendimientos. Podemos poner como ejemplo un banco que utiliza un servicio para conceder
préstamos a sus clientes.

Si la organización TI le ofrece un servicio que permite la aprobación de un préstamo en 24

horas, mientras que otros bancos requieren 48 horas para hacerlo, es evidente que esta
diferencia en el tiempo de tratamiento de una petición es una utilidad del servicio, que
permitirá proporcionar un valor añadido al cliente.

Garantía del servicio

La garantía 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 garantía 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 gestión

de la continuidad para este servicio).

La organización 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 generación de servicios son:

 Definir el mercado: se trata de entender las necesidades de los clientes y las

oportunidades en términos de servicios.

 Desarrollar las ofertas: a partir del análisis hecho en la etapa anterior, se definen
cuáles son los servicios que serán ofrecidos por la organización TI.

 Desarrollar los activos estratégicos: como hemos visto en la sección de

definición del valor añadido, conviene identificar los medios que se deben aplicar
para proporcionar un valor añadido a los clientes, a través de los servicios ofrecidos
por la organización TI.

 Preparar la ejecución: el objetivo es definir el contenido del porfolio de servicios y

del catálogo de servicios, así como definir cuáles serán los requerimientos para el
diseño, la transición y la explotación de servicios.

Estas actividades se ven limitadas por factores internos (organización, competencias de los
empleados, elecciones estratégicas de la empresa...) y por factores externos (evolución del
mercado, estado de la competencia, evolución tecnológica, requerimientos
reglamentarios...).
7. Roles
Los principales roles son los siguientes:

 Los miembros de la Dirección de la empresa.

 El responsable de la generación de la estrategia.

 El propietario del proceso.

8. Descripción del proceso

El proceso de Generación 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 diseño de servicios.

 Los requerimientos para la transición de servicios.

 Los requerimientos para la explotación de servicios.

 Los requerimientos para la mejora continua.

Las otras fases del ciclo de vida de los servicios pondrán en marcha soluciones que
garanticen los requerimientos en este proceso.

Gestión financiera
1. Enfoque
En esta sección vamos a ver cómo se pone en práctica la gestión financiera.

Este proceso es importante para el correcto funcionamiento de la organización TI, ya que

permite conocer exactamente los costes del conjunto de servicios proporcionados al cliente
y determinar los modos de facturación.

Este proceso también permite asegurar que se aplican los procedimientos y las prácticas
definidas por la gestión financiera para el conjunto de equipos de la organización TI.

Fundamentalmente, veremos su importancia en la forma de determinar los costes para

cada servicio.

2. ¿Por qué una gestión financiera?

Los costes de los servicios informáticos están en continuo aumento para responder a las
necesidades, en constante evolución, de los clientes y las empresas.

En ausencia de una gestión financiera, es difícil conocer el verdadero coste de los servicios
informáticos.

Esto explica que frecuentemente haya insatisfacción por parte de los clientes o de las
empresas, respecto a la relación calidad/precio de los servicios que se les proponen.

La aplicación de un proceso de gestión 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 versión 3 de ITIL introduce el concepto de Valorización del servicio.

¿Qué es la valorización?

Podemos definir este término de las siguientes maneras: «Reconocimiento del valor de
cualquier cosa para sacar de ella más recursos». Desde un punto de vista económico:
«Aumento del valor de mercado de un producto o servicio por medios legales o una acción
voluntaria».

En el caso de ITIL se trata de valorizar, en términos financieros, las inversiones realizadas

por la empresa y la organización TI. Esta valorización se basa en el valor acordado de los
servicios ofrecidos por la organización TI.

La valorización del servicio es una media del coste total de entrega de un servicio
informático y del valor total para la empresa de ese servicio. La estimación del valor del
servicio se utiliza para permitir a la empresa y al proveedor del servicio informático llegar a
un acuerdo sobre el valor de este.

La valorización del servicio se basa en factores clave:

 La prestación de valor.

 El valor potencial del servicio.

 La prestación de valor determina la base de referencia mínima del coste para proporcionar
el servicio. Es decir: «¿cuál es el coste total de entrega de este servicio?»

Desde el comienzo de este libro, hemos dicho que el objetivo era proporcionar un valor
añadido al servicio prestado. El valor potencial del servicio es la componente de este valor
añadido, basado en la percepción de valor que tiene el cliente. Este valor se calcula en
función de la utilidad y la garantía.

a. Otros conceptos
La modelización de la demanda es la identificación de los costes de uso de un servicio y la
previsión de las implicaciones financieras de la demanda de servicios en el futuro. Se
identifican las necesidades de financiación, las variaciones y las causas o razones de esta
variación. La demanda del servicio se puede gestionar a través de la tarificación y de los
ajustes de bonus susceptibles de influir en la demanda del cliente.

La gestión del porfolio de servicios utiliza los datos proporcionados por la gestión
financiera, para comparar las unidades organizativas entre ellas o en relación con los
proveedores externos. Esto permite decidir cómo y dónde se obtiene un servicio.

3. Objetivos del proceso

El objetivo principal del proceso de gestión financiera para un servicio interno es asegurar
una gestión económica de los recursos TI, utilizados para proporcionar los servicios de las
TI.

Para obtener un resultado satisfactorio, es necesario poner en práctica tres actividades,

entre las cuales una es opcional:

 Presupuestación (obligatoria).

 Contabilidad de las TI (obligatoria).

 Imputación (opcional).

Para una organización TI, la gestión financiera también permite poder justificar los gastos
informáticos y establecer la relación con los servicios suministrados.

Esto también permite participar en las decisiones de gestión en términos de inversión

informática.

Para esto, la gestión financiera necesita tener información detallada de los cambios.

4. Definición
Presupuestación (Budgeting): es un proceso de previsión y control de los gastos
informáticos.

Contabilidad (Accounting): es el proceso habitual que permite conocer y verificar los

costes por cliente, servicio o actividad.

Imputación (Charging): es el proceso que permite facturar los costes de un servicio a un

cliente. También se conoce como facturación.

5. Perímetro
La gestión financiera es responsable de:
  Prever la financiación.

 Establecer un plan operativo.

 Realizar el análisis de costes.

 Definir las políticas de facturación.

La gestión financiera cubre la totalidad de los costes de la organización 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 gestión financiera

 Responsable de la relación comercial

 Responsable de los niveles de servicios

 Responsable de la capacidad

 Responsable de la gestión de configuraciones

7. Indicadores
Se pueden aplicar varios indicadores para elaborar un cuadro de mando. Este cuadro de
mando se deberá proporcionar a la Dirección:

 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 función 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 función de la estructura que
se ponga en marcha.
8. Descripción del proceso

El proceso de Gestión financiera

9. Conceptos básicos
a. El ciclo de vida de la gestión financiera

El ciclo de vida de la gestión financiera

b. Las relaciones con los otros procesos
La gestión de activos y configuraciones
La gestión financiera necesita información de los activos de la organización TI.

Esta información está disponible y actualizada continuamente por la gestión de activos y

configuraciones (gestión de los CI, su estado, coste y las relaciones entre estos activos).

La gestión de la demanda
La gestión de la demanda es un punto de entrada para la gestión financiera, ya que
permite conocer los costes de la puesta en marcha de un servicio.

La gestión de la relación comercial

La gestión de la relación comercial necesita la información financiera relativa a los costes
de las soluciones e inversiones necesarias, principalmente en términos de activos de
servicios. Este proceso también tendrá que proporcionar información a la gestión
financiera.

La gestión del porfolio de servicios

La gestión del porfolio de servicios necesita información de la gestión financiera para
comparar los costes de las entidades organizativas entre ellas o con los proveedores
externos, con objeto de decidir cómo se proporcionarán los servicios.

La gestión de la capacidad
La información de costes es imprescindible para evaluar los costes de la gestión de la
capacidad.

La información conseguida para determinar los costes también será útil para las diferentes
evaluaciones de recursos e inversiones.

La gestión de los niveles de servicios

El SLR y después 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 organización TI.

La gestión financiera trabaja en estrecha colaboración con la gestión de los niveles de

servicio, para definir los modos de facturación que se utilizarán para el cliente.

¡Atención! No hay que olvidar que, si bien es necesario tener en cuenta los costes
relacionados directamente con la producción del servicio, también hay que tener en cuenta
los diferentes costes generales necesarios para el funcionamiento de la organización TI.

c. Planificación de la gestión financiera

La puesta en marcha de la gestión financiera se basa en tres subprocesos: la
presupuestación, la contabilidad y la facturación.

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 implantación de la
estrategia ITIL.

Será necesario establecer un plan de aplicación, definir las políticas de facturación e

identificar los costes y los beneficios esperados.
 Una vez más, es mejor ser modestos y comenzar por un perímetro restringido para validar
las opciones tomadas, antes de hacer un despliegue generalizado.

Poner en marcha la gestión financiera implica un fuerte compromiso de la dirección de la

empresa en el proyecto.

d. La presupuestación
El objetivo de la presupuestación es asegurar la concordancia entre el presupuesto
provisional y el coste real de servicios.

La creación del presupuesto permite asegurar que la financiación 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 demás costes relacionados con la prestación del servicio

La presupuestación permite:

 Prever la financiación necesaria para gestionar la organización TI durante un periodo

dado.

 Tener la seguridad de que los ingresos estarán disponibles para soportar los gastos
previstos.

 Asegurar que los gastos reales se mantienen conforme a las previsiones.

Para ser eficaz, la presupuestación implica una revisión periódica 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 organización 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 transición de la contabilidad al «centro de

beneficio» de la gestión de la organización TI.

Cuando es necesario tomar decisiones de inversión o renovación, el hecho de disponer de

una contabilidad de los servicios informáticos puede ayudar a tomar una decisión.

La contabilidad permite:

 Identificar los coses en función de su clasificación: costes de inversión 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 española, incluidas contabilidades extranjeras para algunas empresas. Por
lo tanto, es necesario tener recursos capaces de controlar estas normas.

f. La categorización de los costes

La contabilidad debe diferenciar la categorización de los costes:

 Los costes de inmovilización.

Por ejemplo: adquisición de un servidor.

 Los costes de explotación.

Por ejemplo: contrato de mantenimiento.

g. La facturación
Es el proceso que permite facturar los costes de un servicio a un cliente, ya sea interno o
externo.

Es habitual que la facturación se concrete en una factura, correspondiente a una fracción

de la cantidad de la facturación anual, por ejemplo 1/12 cada mes.

Sin embargo, la facturación se puede basar en varios modelos:

 Precio de coste

 Coste máximo

 Tarifa interna vigente

 Tarifa del mercado

  Precio fijo negociado con el cliente

h. La imputación
La imputación es opcional en el caso del suministro de servicios internos; sin embargo es
preferible ponerla en marcha desde el comienzo de la gestión financiera.

El proceso de gestión de los niveles de servicio se debe poner en marcha al mismo tiempo
que la gestión financiera si se quiere obtener un reparto justo y simple de los costes.

En este marco, es necesario distinguir varias opciones que permitirán definir las reglas de
imputación.

Modelos de costes
Es posible definir el cálculo 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 localización; en este caso se tienen en cuenta los diferentes costes
relacionados con el suministro del servicio, en una ubicación particular.

Tipos de coste
Es posible repartir los costes en función de su tipo:

 Hardware (adquisición, ubicación)

 Software (adquisición, ubicación, modo ASP)

 Mantenimiento (software, hardware)

 Personal (salarios, formación)

 Inmuebles

 Servicios externos

 Transferencia de cargas

Categorización de los costes

Es preciso hacerse cargo de la categorización de los costes y diferenciar:

 Las inmovilizaciones o la explotación.

Por ejemplo: adquisición de un servidor (inmovilización), frente a los contratos de

mantenimiento (explotación).

 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 prestación 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 función del número 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 recuperación 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 energía, conserjería de los locales.

El acumulado de los costes directos e indirectos absorbidos va a permitir obtener los costes
absorbidos.

El hecho de añadir el incremento generado por los costes indirectos no absorbidos permitirá
obtener un coste real del centro de servicios.

Se deberá realizar el mismo cálculo para cada servicio.

Gestión del porfolio de servicios

1. Enfoque
En esta sección vamos a ver cómo se gestiona el porfolio de servicios.

Veremos que este proceso es importante para la gestión de los servicios proporcionados
por la organización TI.

2. ¿Por qué una gestión del porfolio de servicios?

La organización TI debe conocer constantemente los servicios que ofrece a sus clientes,
pero también aquellos que son susceptibles de ser ofrecidos o que se han eliminado.

Este proceso debe ayudar a responder a las siguientes preguntas estratégicas:

 ¿Por qué un cliente compraría este servicio?

 ¿Por qué nos compraría a nosotros?

 ¿Cuál es el modelo de precios o facturación?

 ¿Cuáles son nuestras fuerzas, debilidades, prioridades y riesgos?

 ¿Cuáles son nuestros recursos y nuestra capacidad para ponerlos en marcha?

3. Objetivos del proceso

Para responder a las preguntas anteriores, los objetivos del proceso son los siguientes:

 Proporcionar un proceso y los mecanismos para permitir a la organización estudiar y

decidir cuáles 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 organización para evaluar cómo estos servicios le

permitirán 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 inversión.

 Seguir las inversiones en servicios a lo largo de su ciclo de vida, permitiendo de esta

manera a la organización evaluar su estrategia, así como su capacidad de aplicación.

 Analizar los servicios para identificar aquellos que ya no son viables con objeto de
eliminarlos del porfolio de servicios.

4. Definición
Porfolio de servicios: expresión de la estrategia de los servicios de la organización TI.
Contienen el conjunto de servicios (pipeline, catálogo de servicios y servicios eliminados).

Catálogo de servicios: es un subconjunto del porfolio de servicios. Contiene todos los

servicios operativos.

5. Perímetro
La gestión del porfolio de servicios es responsable de:

 La identificación de todos los servicios.

 Control de las inversiones en servicios.

 Maximizar el valor de los servicios.

 La construcción del paquete de servicios (SDP - Service Design Package).

6. Roles
Los roles principales son los siguientes:

 Responsable del porfolio de servicios.

 Responsable del catálogo de servicios.

 Responsable de la relación comercial.

 Propietario del servicio.

7. Indicadores
Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:

 Número global de servicios en el pipeline.

 Número global de servicios en el catálogo de servicios.

 Número global de servicios retirados del porfolio de servicios.

  Número de servicios que se han movido en un periodo:

 del pipeline al catálogo de servicios.

 del catálogo de servicios a los servicios retirados.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se establezca.

8. Descripción del proceso

El proceso de gestión del porfolio de servicios

9. Conceptos básicos
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 catálogo de servicios
El catálogo de servicios debe contener todos los detalles de todos los servicios operativos:

 Sus características (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 organización TI necesita conservar los diferentes elementos relativos a los servicios

eliminados.

De hecho, éstos se podrían 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 catálogo de servicios

La organización 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 práctica un porfolio de servicios

que debe contener el catálogo de servicios.

El porfolio de servicio se diseña en el diseño de los servicios, pero se produce y actualiza en

la gestión del porfolio de servicios.
El porfolio de servicios debe contener un conjunto de información relativa a cada servicio:

 Sus características (descripción detallada).

 Su valor añadido.

 Los riesgos asociados.

 Su coste.

 Su estado.

Las opciones de estado en el porfolio de servicios contienen, al menos:

 Requerimientos: la empresa o el diseño 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: están construidos el servicio y los componentes que forman parte de él.

 Probado: están probados el servicio y los componentes que forman parte de él.

Los servicios proporcionados por los proveedores de servicios también son elementos clave
del porfolio de servicios y del catálogo de servicios.

La organización debe definir una política relativa a la gestión del porfolio de servicios y al
catálogo de servicios. Esta política debe, en particular, definir los detalles de las
responsabilidades de cada servicio.

El diseño de servicios diseña 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

función de las áreas del negocio implicadas.

Lo ideal sería que la gestión del porfolio de servicios se hiciera con la colaboración de
diseño, transición de servicios, explotación y mejora continua de servicios.

Una vez que el servicio se transfiere a la transición de servicios, se debe incluir en el

catálogo de servicios.

El proceso de gestión de cambios debe validar todos los cambios en el porfolio de servicios
o en el catálogo de servicios.
f. El empaquetado de los servicios
La gestión del porfolio de servicios es responsable de la construcción del empaquetado de
los servicios (SDP - Service Design Package).

Este empaquetado de servicios se utilizará en las fases de diseño y transición de servicios.

Normalmente, un servicio está compuesto por un conjunto de componentes o servicios

que, una vez ensamblados, darán lugar a un paquete de servicios.

Un paquete de servicios puede contener:

 Una carta que incluye una descripción del uso y la garantía.

 Las especificaciones del servicio.

 Los criterios de aceptación del servicio.

 Los modelos que se usan en la prestación 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 básico.

 Uno o varios servicios de apoyo, que proporcionarán un valor añadido.

 Módulos complementarios.

 Módulos de extensión del servicio.

Construcción de un paquete

Para este ejemplo, podemos tomar un servicio de tipo centro de servicios.

Vamos a definir un servicio básico; por ejemplo, un soporte de 09:00 a 17:00 h, de lunes a
viernes.

Para incluir este servicio básico en el porfolio de servicios, debemos definir e identificar
todos los componentes de este servicio para determinar su coste.

A este servicio básico se le podrán añadir servicios adicionales, para obtener un servicio
diferenciado para cada cliente.

Podemos hablar de la construcción de un servicio a partir de piezas, como se hace con las
piezas de LEGO®.

En función de las necesidades del cliente, vamos a añadir una o varias piezas específicas,
correspondientes a dichas necesidades.

Podemos definir las piezas correspondientes a una extensión del servicio:

  Extensión de 07:00 a 09:00 h.

 Extensión de 17:00 a 19:00 h.

 Extensión para el sábado.

 Extensión para el domingo...

También podemos definir las piezas complementarias:

 Complemento para un idioma extranjero.

 Complemento para un soporte de tipo penalización, 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.

También será necesario definir los niveles de servicio asociados a cada uno de estos
módulos 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.

Gestión de las peticiones

1. Enfoque
En esta sección vamos a ver cómo se gestionan las peticiones de los clientes, en términos
de peticiones de nuevos servicios.

Veremos que este proceso es muy importante para la generación de la estrategia de

servicios.

2. ¿Por qué una gestión de peticiones?

Los clientes expresan regularmente nuevas necesidades en forma de peticiones. La
dirección de la organización necesita conocer el conjunto de estas peticiones para definir su
estrategia de servicio.

3. Objetivos del proceso

Los principales objetivos del proceso de gestión de las peticiones son los siguientes:

 Minimizar al máximo la incertidumbre de la petición del cliente.

 Proporcionar datos fiables para la gestión de la capacidad, con objeto de obtener una
capacidad eficiente.

4. Definición
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. Perímetro
La gestión de las peticiones es responsable de:

 La identificación de las peticiones de los clientes.

 La identificación de los diferentes componentes de un servicio.

6. Roles
Los roles principales son los siguientes:

 Responsable de las peticiones.

 Responsable de la relación comercial.

 Responsable de la gestión 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:

 Número de peticiones de cliente.

 Número de peticiones tenidas en cuenta.

 Número de peticiones planificadas a corto plazo.

 Número de peticiones rechazadas.

Esta lista no es exhaustiva; convendrá definir los indicadores en función de la estructura

que se establezca.
8. Descripción del proceso

El proceso de gestión de peticiones

9. Conceptos básicos
Minimizar la incertidumbre de la petición
La gestión de la demanda es importante para la estrategia de servicios.

La organización TI necesita conocer la tendencia de evolución de las necesidades del

cliente, para adaptar su oferta.

La organización TI debe ser capaz de responder a las peticiones de sus clientes, cuando
necesite la disponibilidad del servicio correspondiente a su petición.

Para poder responder correctamente a la petición, el proceso de gestión de la capacidad

requiere conocer la tendencia de evolución de los servicios.

Esta tendencia de evolución puede ser de tipo capacidad, al alza o a la baja, o de

tipo tecnología(integración de nuevas tecnologías o eliminación de tecnologías obsoletas).

La adaptación de la capacidad tendrá un impacto en la calidad del servicio que se

proporcionará.

Esta medición de la evolución de la petición se debe hacer escuchando al cliente y en

estrecha coordinación con él, fundamentalmente a través de la gestión de la relación
comercial.
 Sin embargo, en la «vida real», es necesario ser realista y no creer que esto eliminará
todas las incertidumbres relacionadas con la evolución de las necesidades de las empresas.

10. Las actividades de la gestión de peticiones

Las actividades de la gestión de peticiones implican al conjunto de fases del ciclo de vida.

 Estrategia de servicios: identificar los servicios y expectativas en términos de

resultados del cliente, así como los PBA (Patterns of Business Activity) que generan.

 Previsión de peticiones en función de los escenarios de uso.

 Soporte de la gestión del porfolio de servicios.

 Diseño de servicios: confirmar los requerimientos del cliente en términos de

disponibilidad y rendimiento, así como asegurar que los activos de los servicios
necesarios están disponibles.

 Los procesos principales en esta fase son la gestión de la capacidad y la gestión de la

disponibilidad.

 La gestión de peticiones también permitirá definir las opciones de la gestión de la

continuidad de los servicios.

 Transición de los servicios: implicación en las pruebas y validación del servicio, en

previsión de la explotación y validación de los PBA.

 Explotación de los servicios: las funciones de gestión de aplicaciones, gestión técnica

y gestión de operaciones de supervisión del uso de los activos de servicio, en los
diferentes niveles definidos.

11. Fuentes de información para la gestión de peticiones

Las principales fuentes de información que utiliza el proceso de gestión de peticiones son:

 Los Business Plan.

 Los planes y previsiones de comercialización.

 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:

 Clasificación: permite indicar cuál es el tipo de cada PBA.

 Atributos: frecuencia, volumen, ubicaciones y duración.

 Necesidades: rendimiento, seguridad, disponibilidad y plazo.

 Activos de servicios: equipos de diseño que redactarán los perfiles de usuario para
cada PBA.
  Los PBA pueden ser diarios, semanales, mensuales o anuales, en función de las
necesidades.

LOS PROCESOS DEL DISEÑO DE SERVICIOS

La fase de diseño de servicios
1. ¿Por qué un diseño de servicios?
Como hemos visto en el capítulo de presentación de la norma, ITIL se compone de
procesos estratégicos, tácticos y operativos.

Los niveles decisionales de gestión de los servicios

La fase de diseño de servicios se encuentra entre el nivel estratégico y el táctico.

Los procesos del diseño de servicios se sitúan después de los procesos de estrategia de
servicios.

El primer objetivo del diseño de servicios es elaborar los servicios que se explotarán a
través de la transición de servicios.

2. Los procesos de diseño de servicios

 Coordinación del diseño

 Gestión del catálogo de servicios

 Gestión de la capacidad

 Gestión de la disponibilidad

 Gestión de la continuidad
  Gestión de la seguridad

 Gestión de proveedores

3. Consideraciones sobre el diseño de los servicios

a. Enfoque
Las actividades de diseño de los servicios se pueden definir y analizar a partir de los cinco
aspectos principales siguientes.

Enfoque del diseño de servicios

b. El diseño de las soluciones de servicios

Durante la fase de diseño 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 diseño de una solución de servicio, se debe tener en cuenta:

 El diseño de los servicios informáticos y las infraestructuras existentes.

 Diseñar las soluciones de servicios para los nuevos requerimientos.

 Revisar los servicios informáticos existentes.

c. El diseño de los sistemas de gestión de los servicios y las herramientas

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

El porfolio de los servicios se utiliza para dar soporte a todos los procesos y describir los
servicios de un proveedor, en términos de valor de negocio. Define las necesidades de la
empresa y valida la adecuación de la respuesta de los proveedores a estas necesidades.

El porfolio de servicios permite responder a las siguientes preguntas estratégicas:

 ¿Por qué un cliente debería comprar estos servicios?

 ¿Por qué debería comprarnos estos servicios a nosotros?

 ¿Cuáles son las tarifas y el sistema de facturación?

 ¿Cuáles son mis puntos fuertes y débiles, las prioridades y los riesgos?

 ¿Cómo se deben asignar nuestros recursos y nuestras aptitudes?

d. El diseño de las arquitecturas técnicas

El desarrollo y despliegue de una infraestructura informática, compuesta por un conjunto
de aplicaciones y datos, son las actividades del diseño de las arquitecturas técnicas. Este
desarrollo se realiza con el objetivo de satisfacer las necesidades de negocio actuales y
futuras.

También se deben tener cuenta los aspectos relativos a las personas, procesos y socios o
proveedores que rodean a estos componentes técnicos.

e. El diseño de los procesos

Como recordatorio, la definición de proceso es: «conjunto estructurado de actividades
diseñadas para lograr un objetivo específico».

Para lograr este objetivo, el proceso parte de una o varias entradas y, a través de las
diferentes actividades predefinidas, las transforma en elementos de salida.

Las actividades de planificación y de regulación de un proceso son las actividades de

control que van a permitir la realización de un proceso de manera eficiente y eficaz.

Un modelo de proceso incluye todos los roles, responsabilidades, herramientas y controles.

f. El diseño de los sistemas de medición

El funcionamiento normal de un proceso obliga a que tenga mediciones y controles.

Esto es válido para todos los aspectos de los procesos de diseño.

Se pueden definir y utilizar cuatro tipos de métricas para medir la capacidad y el

rendimiento de los procesos:

 Métricas de progreso: hitos y entregables en la capacidad del proceso.

 Métricas de conformidad: conformidad de un proceso respecto a los

requerimientos gubernamentales y reglamentarios.
  Métricas de eficacia: la precisión y exactitud del proceso y su capacidad de
entregar un resultado conforme a los términos de eficacia.

 Métricas de eficiencia: la productividad del proceso, velocidad, capacidad de

tratamiento y el uso de sus recursos.

4. Las 4 P
Muchos diseños, planes y proyectos fracasan debido a diferentes motivos.

Sin embargo, muchos de estos fracasos se deben a una ausencia de preparación de la

gestión.

La puesta en marcha de la gestión de servicios ITIL como una práctica hace referencia a la
preparación y planificación de un uso efectivo y eficiente de las 4 P (del
inglés People, Product,Process y Partners).

a. Personas
En esta categoría incluimos a los usuarios, los clientes y al personal informático y
responsables. Entre los elementos importantes, están la comunicación, la formación y una
definición clara de los roles y responsabilidades de todas las partes implicadas.

b. Procesos
En esta categoría se encuentran los procesos ITIL, que se integran en el ciclo de vida de la
gestión de servicios:

 Estrategia de servicios (Service Strategy - SS).

 Diseño de servicios (Service Design - SD).

 Transición de servicios (Service Transition - ST).

 Explotación de servicios (Service Operation - SO).

 Mejora continua de servicios (Continual Service Improvement - CSI).

c. Productos
Hoy en día, las organizaciones informáticas disponen de un determinado número de
herramientas, que se anuncian como «Compliant ITIL» o «Conforme ITIL».

Por supuesto, salvo si tiene la certificación ITIL por la OC, estas herramientas no ofrecen
realmente una garantía de conformidad.

No hay que creer que el uso de estas herramientas va a garantizar que la organización TI
trabaje conforme a ITIL. Para que la organización TI trabaje conforme a ITIL, será
necesario poner en práctica todos los procesos descritos en este libro, así como una
organización que permita este modo de funcionamiento.

d. Asociaciones
Para suministrar servicios informáticos de calidad, la organización debe poner en marcha
un proceso de gestión de proveedores (socios, fabricantes, empresas de servicios...).

5. Los enfoques para el suministro de los servicios

La organización 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 adaptación y personalización.

En realidad, existe una buena estrategia para cada empresa. Esta estrategia debe estar en
relación con las capacidades de la organización TI.

La estrategia de suministro de los servicios es responsabilidad del proceso de generación

de la estrategia.

La organización no tiene necesariamente la capacidad de ofrecer el conjunto de servicios

solicitados por sus clientes. En este caso, la organización buscará una solución alternativa
para responder positivamente a estos.

Esta solución deberá garantizar la continuidad del suministro y la calidad de los servicios
suministrados.

Esta solución alternativa pasa a menudo por la externalización de una parte o del servicio
completo.

Lo primero de todo es que la organización TI se debe formular las siguientes preguntas:

 ¿Por qué externalizar?

 ¿Qué se debe externalizar?

 ¿A qué se debe parecer la relación?

 ¿Cómo llegar?

Las principales estrategias para el suministro de servicios se describen más adelante.

a. Internalización
Esta estrategia se basa en el uso de los recursos organizativos internos de la organización
TI.

Estos recursos se asignan al diseño, desarrollo, transición, mantenimiento y explotación.

Estos recursos garantizan el soporte de los servicios nuevos, modificados o revisados.

b. Externalización
Esta estrategia se basa en el uso de los recursos de una o varias organizaciones externas
para proporcionar una parte claramente definida del diseño, desarrollo, mantenimiento,
explotación o soporte de un servicio.

Los servicios de aplicaciones de tipo ASP pueden estar en esta categoría.

La firma de un acuerdo oficial entre la organización TI y el proveedor externo se debe hacer

en forma de contrato de tipo UC (Underpinning Contract).

c. Cosourcing
Esta estrategia consiste en una combinación de recursos internos y externos que colaboran
para suministrar en común los elementos claves del ciclo de vida.
 Normalmente, esto implica el uso de varias organizaciones externas que colaboren en el
diseño, desarrollo, transición, explotación y soporte de una parte de un servicio.

d. Asociación o multisourcing
En esta estrategia, los acuerdos oficiales se establecen entre dos o más organizaciones
para colaborar en el diseño, desarrollo, transición, explotación o soporte de los servicios
informáticos.

Se debe prestar una atención especial a las asociaciones estratégicas que favorezcan la
competencia y las oportunidades comerciales.

Coordinación del diseño

1. Enfoque
En esta sección vamos a ver cómo se gestiona el diseño 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
coordinación 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 diseño
de los servicios, manteniendo un único punto de coordinación y control para todas las
actividades y procesos de esta fase.

2. Objetivos del proceso

Los objetivos de este proceso son los siguientes:

 Asegurar un diseño coherente de los servicios para responder a los requerimientos y

expectativas del cliente, fundamentalmente en términos de resultados.
Evidentemente, esto implica a la gestión del sistema de información, arquitectura,
tecnología, procesos, información y métricas. Esto debe responder a las necesidades
actuales del cliente y su evolución en un entorno cambiante.

 Coordinar todas las actividades de diseño a través de los proyectos, cambios,

proveedores y equipos de soporte, gestión de planificaciones, recursos y conflictos.

 Planificar y coordinar los recursos y las capacidades necesarias para diseñar o

modificar los servicios.

 Producir los SDP (Service Design Packages), basados en la carta de servicios y las
peticiones de cambio.

 Asegurar que el diseño de los servicios y SDP se produce y transmite a la fase

transición de servicios.

 Gestionar los criterios de calidad, requerimientos entre las fases de estrategia y

transición de servicios.

 Asegurar que todos los modelos de servicios y soluciones diseñadas están de acurdo
con la estrategia, la gestión 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 estándares comunes, las prácticas de
reutilización de las actividades y los procesos y sistemas de soporte apropiados.

 Mejorar el rendimiento de la fase de diseño de los servicios.

3. Descripción del proceso

Proceso de coordinación del diseño

4. Conceptos básicos
a. Políticas de diseño
El proveedor del servicio debe definir las políticas que permitirán identificar el tipo de
diseño sobre el que la coordinación debe prestar más atención.

Por ejemplo, este puede ser el caso para los cambios importantes, y el resto de los cambios
tendrán que corresponder a las normas de diseño definidas en este proceso.

También se debe definir los niveles de documentación. Para un cambio importante, puede
ser necesario tener un paquete de diseño (SDP - Service Design Package) completo,
mientras que para los cambios menos importantes será suficiente con una documentación
simplificada.

Las políticas de diseño deben incluir:

 El respeto de los estándares y convenciones de la empresa.

 El respeto de las reglas de gestión en todas las actividades.

 La puesta en marcha de estándares para asegurar una buena comprensión de las

actividades de diseño:
  Modelos de documento

 Planes de documentación

 Planes de formación

 Planes de marketing y comunicación

 Planes de medida y métricas

 Planes de prueba

 Planes de despliegue

 Criterios para resolver los posibles conflictos de asignación de recursos.

 Modelos de coste estándares.

5. Indicadores

 Evolución del porcentaje de los servicios (diseño o cambio) exitosos, en términos de

calidad, coste y respeto de los plazos.

 Reducción del número de cambios urgentes que se crean como consecuencia del
diseño de los servicios.

 Satisfacción del cliente para cada servicio nuevo o modificado.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se ponga en marcha.

Gestión del catálogo de servicios

1. Enfoque
En esta sección vamos a ver cómo se gestiona el catálogo de servicios.

Veremos que este proceso es importante para la gestión de los servicios proporcionados
por la organización TI, y principalmente para la gestión de la relación comercial, la gestión
de los niveles de servicios y el centro de servicios.

2. ¿Por qué una gestión del catálogo de servicios?

La organización informática necesita conocer cada uno de los servicios operativos e
identificar todos los clientes de un mismo servicio.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión del catálogo de servicios son:

 Mantener el conocimiento y comprensión de los servicios operativos establecidos por

la organización TI.

 Mantener la información contenida en el catálogo de servicios.

  Asegurar la coherencia de la información entre el porfolio de servicios y el catálogo
de servicios.

 Asegurar la coherencia de la información contenida en el catálogo de servicios,

principalmente de todos los detalles, los estados, las interfaces y las dependencias.

4. Definición
Porfolio de servicios: expresión de la estrategia de servicios de la organización TI.

Catálogo de servicios: contiene todos los servicios operativos o listos para usar.

5. Perímetro
La gestión del catálogo de servicios, que es un subconjunto del porfolio de servicios, es
responsable de todos los servicios operativos.

La gestión del catálogo de servicios cubre:

 La contribución a la definición de los servicios y paquetes de servicios (SDP).

 El desarrollo y mantenimiento de la descripción de los servicios y paquetes de

servicios (SDP).

 La producción y mantenimiento de un catálogo de servicios actualizado.

 Asegurar la coherencia de la información relativa a las interfaces y las dependencias

con el porfolio de servicios.

6. Roles
Los roles principales son los siguientes:

 Responsable del catálogo de servicios

 Responsable del porfolio de servicios

 Responsable de la relación comercial

 Propietario del proceso

7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Número de servicios en el catálogo de servicios.

 Número de servicios retirados en el periodo.

 Número de servicios movidos en un periodo:

 Del pipeline al catálogo de servicios.

 O del catálogo a los servicios retirados.

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.
8. Descripción del proceso

El proceso de gestión del catálogo de servicios

9. Conceptos básicos
a. El catálogo de servicios
La organización informática 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 catálogo de

servicios.

El catálogo de servicios es un subconjunto del porfolio de servicios.

El catálogo de servicios debe contener todos los detalles de todos los servicios operativos:

 Sus características

 Sus interfaces

 Sus dependencias

 Los procesos relacionados

 Sus atributos
  Su estado (le que debe ser único)

 Su precio

 Los soportes...

El catálogo de servicios está compuesto por dos secciones:

 El catálogo de servicios profesionales. Solo los clientes o posibles clientes pueden ver
este catálogo.

 El catálogo de servicios técnicos.

Todos los cambios en el porfolio de servicios o en el catálogo de servicios se deben validar

por el proceso de gestión de cambios.

Relaciones entre los componentes del catálogo

Relaciones entre los componentes del catálogo de servicios

El catálogo de servicios profesionales

El catálogo de servicios de negocio contiene detalles de todos los servicios informáticos
entregados a los clientes.

Deben estar descritas las relaciones entre los procesos profesionales y los servicios.

El catálogo de servicios técnicos

El catálogo de servicios técnicos contiene los detalles de todos los servicios informáticos
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 catálogo de servicios
El diseño de servicios diseña el porfolio de servicios, pero este se actualiza en gestión del
porfolio de servicios.

Los servicios proporcionados por los proveedores de servicios también son los elementos
clave del porfolio de servicios y del catálogo de servicios.

La organización debe definir una política relativa a la gestión del porfolio y catálogo de
servicios. En particular, esta política debe definir los detalles de las responsabilidades para
cada servicio.

La gestión del porfolio de servicios se deberá realizar, de manera ideal, con la colaboración
de diseño, transición, explotación y mejora continua de servicios.

Tan pronto como se transfiere un servicio a transición de servicios, este se debe incluir en
el catálogo de servicios.

Gestión de los niveles de servicio

1. Enfoque
En este apartado vamos a ver cómo se gestionan los diferentes contratos de servicio.

Veremos que este proceso es especialmente importante para la gestión de los servicios
proporcionados por la organización TI.

Esto implica tanto a las relaciones entre el cliente como a las diferentes entidades de la
organización TI y la gestión de los contratos con los subcontratistas.

2. ¿Por qué una gestión de los niveles de servicio?

Es imprescindible verificar y validar las necesidades y requerimientos del cliente, y definir
cuáles serán los compromisos que se deben aplicar entre los diferentes actores del entorno
TI y, en particular, entre los clientes y la organización 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 específicos
y medir sus logros.

3. Objetivos del proceso

El proceso de gestión 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 relación con el
cliente, en coordinación con el proceso de gestión de la relación comercial; estos elementos
van a ayudar a mantener y mejorar la calidad de los servicios y vigilar y mejorar la
satisfacción del cliente, respecto a los servicios proporcionados.

En último lugar, pero igualmente importante, es necesario asegurar la comprensión clara y

no ambigua de los compromisos de niveles de servicios entre la organización TI y el cliente.
4. Definición
Service Level Requirement (SLR): es la expresión de las necesidades del cliente.

Service Level Manager (SLM): es el responsable de la gestión de los niveles de servicio.

Service Level Agreement (SLA): acuerdo de niveles de servicio alcanzado entre el

cliente y la organización TI.

Operationnal Level Agreement (OLA): acuerdo de niveles de servicio entre las

diferentes entidades o servicios de la organización TI.

Underpinning Contract (UC): contrato que establece las relaciones entre la organización
TI y los subcontratistas o proveedores.

Catálogo de servicios: documento que presenta el conjunto de servicios proporcionados

por la organización de los TI.

Service Improvement Program (SIP): programa de mejora de servicios. Es un

documento que presenta las acciones de mejora de la gestión de los TI y de la relación con
el cliente.

Auto-conmutador: equipamiento que permite el enrutamiento de las comunicaciones

telefónicas.

ACD: equipamiento que permite el enrutamiento de las comunicaciones telefónicas, según

un programa que tiene en cuenta los diferentes parámetros predefinidos por la
organización TI.

5. Perímetro
La gestión de los niveles de servicio es responsable de las siguientes acciones:

 Cooperar con la gestión de la relación 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 organización TI y gestionarlos (OLA).

 Establecer contratos de servicios con proveedores externos (UC) y asegurar que

están 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 realización de los servicios, en particular

de los ausentes.

La gestión de los niveles de servicios cubre la totalidad de los servicios ofrecidos por la
organización TI, así como la totalidad de servicios proporcionados por los subcontratistas o
los proveedores de servicios.
6. Roles
Los roles principales son los siguientes:

 Responsable de los cambios

 Responsable de los activos y configuraciones

 Responsable de los niveles de servicios

 Responsable de la relación comercial

 Propietario del proceso

7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso. Deben
estar definidos en el SLA y serán específicos 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.

8. Descripción del proceso

El proceso de gestión de los niveles de servicios

9. Conceptos básicos
a. Relaciones entre la gestión de la relación y la gestión de los niveles de servicio
El objetivo principal de la gestión de los niveles de servicio es asegurar la consecución de
los niveles de servicio definidos. Es una gestión diaria.

El objetivo de la gestión de la relación comercial tiene una orientación a medio o largo

plazo. Se trata de identificar las necesidades del cliente y asegurar la capacidad de la
organización TI para responder a estas necesidades. Este proceso se centra en la relación
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. Expresión de la petición del cliente

La expresión de la petición del cliente se debe realizar a través 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 petición de

cambios (RFC - Request For Change).

El examen de esta petición por la gestión de cambios permitirá identificar los diferentes
equipos que contribuirán al suministro del servicio y a la construcción 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 negociación entre el cliente y el proceso de cambios, con el objetivo de
encontrar un equilibrio entre las necesidades del cliente y aquello que la organización TI
está en disposición de suministrar.

Esta negociación 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
gestión de la capacidad, proceso de gestión de la disponibilidad, proceso de gestión de la
continuidad, proceso de gestión de la seguridad, proceso de gestión de incidencias, centro
de servicios...). El SLM volverá entonces a dirigirse hacia el proceso de gestión de cambios,
para encontrar la adecuación entre la petición del cliente, expresada en el SLR, y lo que
ofrece la organización TI.
Será necesario definir paralelamente los contratos de niveles de servicio entre las
diferentes entidades de la organización TI (OLA - Operationnal Level Agreement) y
también, si fuera necesario, entre la organización 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 deberán registrar en la CMS, a partir del porfolio y
del catálogo de servicios (ver los capítulos correspondientes a estos procesos).

Un SLA debe ser un documento escrito, firmado por las dos partes, en términos no técnicos
y comprensible para todos. Debe contener un determinado número 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 organización TI y el cliente. Un
acuerdo desequilibrado provocará, tarde o temprano, una situación de difícil manejo y la
insatisfacción 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 organización TI.

Muy a menudo, las razones dadas por estas empresas están basadas en cuestiones
jurídicas.

En este caso, la organización TI debe tomar todas las precauciones para que el contrato
que se le ofrece reúna todos los elementos correspondientes al servicio propuesto.

Lo que debe contener un SLA

A continuación encontrará un ejemplo de los elementos que deberá contener, como
mínimo, un SLA para un centro de servicios.

Es necesario indicar que este ejemplo solo es válido para este tipo particular de servicio.

Se deberá adaptar al servicio realmente proporcionado por la organización TI.

 Descripción del servicio.

 Duración del contrato.

 Perímetro 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 técnicos).

  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 solución (2 horas para una llamada de prioridad 2)...

 Condiciones de puesta en marcha de un cambio o evolución del servicio.

 Continuidad de los servicios de la organización TI.

 Seguridad de los servicios de la organización TI.

 Seguridad de la información de los clientes (confidencialidad, integridad,

disponibilidad).

 Responsabilidades de TI y del cliente.

 Informes y revisiones de los servicios (planificación de los comités de control).

 Incentivos/penalizaciones de rendimiento...

Todos los indicadores u objetivos definidos en los acuerdos deben ser medibles.

La aplicación de penalizaciones financieras deberá estar acompañada de la aplicación de

incentivos financieros. Estos incentivos se deberán poner en marcha tan pronto como la
calidad del servicio esté por encima del umbral predefinido.

Definición 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 definición de los objetivos e indicadores.
 Definición 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 más
ambiciosos para las diferentes entidades implicadas en la realización 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 consecución 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% máximo de llamadas no respondidas,
es decir, 120 llamadas/mes como máximo.
 El equipo A recibe 400 llamadas/mes y los otros equipos reciben cada uno
300 llamadas/mes.

Esto significa que el equipo A no debe perder más de 48 llamadas por mes y que los otros
no deben perder más 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 máximo 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 límite 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 hipótesis de que los otros dos equipos estén también en el límite de sus objetivos, el
número 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
máximo de 150 llamadas.

Caso 2

El equipo B tiene dificultades serias y pierde 50 llamadas.

Los otros equipos están en el límite de sus objetivos.

El número total de llamadas perdidas será entonces de: 48 + 36 + 50 = 134 llamadas

perdidas para un objetivo máximo de 150 llamadas.

Los objetivos del SLA serán, sin embargo, correctos.

Estos dos ejemplos muestran que la fijación 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 organización TI.

Es necesario definir en qué ámbito deberán proporcionar sus servicios estas diferentes
entidades.

Para ello, se debe establecer un acuerdo de niveles de servicios específico.

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
Más adelante encontrará un ejemplo de los elementos que debería contener, como mínimo,
un OLA para una prestación de centro de servicios. Describe los compromisos entre el
centro de servicios y el equipo de «informática interna».

Es necesario indicar que este ejemplo sólo es válido para este tipo particular de servicio. Se
debe adaptar al servicio realmente proporcionado por la organización TI.

 Descripción del servicio.

 Perímetro 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 técnicos que intervienen
en la plataforma del centro de servicios).

 Rendimiento del servicio:

 Plazos de intervención sobre un puesto de trabajo.

 Plazos de intervención sobre un puesto telefónico.

 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 instalación de un nuevo puesto de trabajo.

 Flujo de ancho de banda...

 Condiciones de puesta en marcha de un cambio o evolución del servicio.

 Continuidad de los servicios de la organización TI.

 Seguridad de los servicios de la organización TI.

 Seguridad de la información de cliente (confidencialidad, integridad y disponibilidad).

 Responsabilidades del centro de servicios y del equipo de «informática interna».

 Informes y revisiones del servicio (planificación de los comités de control).

 Coste interno de los diferentes elementos del servicio.

 Imputación de los diferentes elementos del servicio...

f. Estudio y puesta en marcha de un acuerdo UC (Underpinning Contract)

En algunos casos, la organización puede tener una estrategia de externalización, 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 diseño, desarrollo, mantenimiento,
explotación y/o soporte de un servicio.

Los servicios de aplicaciones de tipo ASP pueden estar dentro de esta categoría.

La firma de un acuerdo oficial entre la organización TI y el proveedor externo se hace en

forma de contrato de tipo UC (Underpinning Contract).

Los objetivos que se definirán 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 organización TI es «cliente» del proveedor.

Atención, hay que diferenciar entre los acuerdos (tipos SLA y OLA) y el contrato (tipo
UC).

10. Beneficios y dificultades

a. Beneficios
La gestión de los niveles de servicio permite una buena relación con el cliente.

Permite poner en práctica los contratos que servirán de base para medir la efectividad y
eficacia de los procesos a través de los diferentes indicadores que se aplicarán.

La validación de los acuerdos por el proceso de cambios garantizará la adecuación entre las
necesidades del cliente y las capacidades de la organización TI.

b. Dificultades potenciales
Es imprescindible que los contratos sean claros y precisos.

Un error común es la definición de los indicadores.

Es necesario prestar atención a lo que se desea medir y también 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

Número de incidencias principales tratadas en menos de 1 hora, con un umbral del 90%.

Si sólo 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!

Atención también 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. También se deben elaborar y distribuir los informes.
Gestión de la capacidad
1. Enfoque
En esta sección vamos a ver cómo se gestiona la capacidad de la organización TI.

Veremos que el suministro de servicios y su calidad dependen mucho de la eficacia del

proceso.

2. ¿Por qué una gestión de la capacidad?

En un entorno actual, donde los presupuestos están impuestos en general, es importante
asegurar que los costes en inversión y funcionamiento están 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 organización TI para utilizar eficientemente

los recursos.

Para esto, es indispensable controlar el rendimiento y la rentabilidad de los servicios

ofrecidos por la organización TI.

Es imprescindible comprender las peticiones actuales de servicios informáticos de los

clientes para prever los requerimientos futuros.

Igualmente, es necesario ajustar el uso de los recursos teniendo en cuenta otros procesos
de gestión de servicios.

Último punto: es necesario elaborar un plan de la capacidad que prevea los recursos de la
organización TI, necesarios para atender los niveles de servicio pactados en los acuerdos
de servicios (SLA).

La gestión de la capacidad y de la disponibilidad son esenciales para asegurar la parte de

Garantía en el valor del servicio (Valor del servicio = Utilidad + Garantía).

3. Objetivos del proceso

Los objetivos principales del proceso de gestión de la capacidad son los siguientes:

 Producir y mantener un plan de capacidad, apropiado y actualizado, que refleje las

necesidades actuales de la organización 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 organización TI.

 Proporcionar los consejos y servir de guía, para todos los problemas relacionados con
la capacidad y el rendimiento, al resto de los sectores de la organización TI y de la
empresa.

 Evaluar el impacto de todos los cambios solicitados, en términos de plan de

capacidad, recursos y rendimiento.

 Tomar medidas proactiva para mejorar el rendimiento de los servicios, siempre que
tenga justificación financiera.
 El proceso de gestión de la capacidad también tiene la responsabilidad de asegurar el
sistema de alertas de novedades tecnológicas para la organización TI.

4. Definición
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 informáticos.

CCM (Component Capacity Management): subprocesos cuyo objetivo es la gestión, el

control y la previsión del rendimiento, el uso y la capacidad de los componentes.

5. Perímetro
La gestión de la capacidad debe ser un punto central para el rendimiento de la organización
TI, en términos de rendimiento y capacidad.

La gestión de la capacidad tiene en cuenta el conjunto de componentes de la

infraestructura informática (hardware y software). También se debe tener en cuenta la
gestión 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 gestión de los PBA (Pattern Business Activity), proporcionados por el proceso de gestión
de la demanda, se debe tener en cuenta en la gestión de la capacidad.

La gestión de la capacidad, junto con proceso de gestión financiera, va a influir en el

proceso de la gestión de la demanda.

La gestión de la capacidad debe ayudar al diagnóstico y resolución de los incidentes y

problemas asociados a un componente o servicio.

La gestión de la capacidad también se debe hacer cargo de todos los cambios

proporcionados por la gestión de cambios relativos a la infraestructura.

Cuando en la organización TI existe un sistema de alertas de novedades tecnológicas, es

oportuno que esté unido a la gestión de la capacidad.

6. Roles
Los roles principales son los siguientes:

 Responsable de la capacidad

 Propietario del proceso

7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Conformidad con la capacidad prevista.

 Evolución de la capacidad de almacenamiento.

 Evolución de la potencia de procesamiento de CPU.

  Evolución de la banda ancha...

 Interrupción en el suministro del servicio, como consecuencia de una falta de medios

o recursos.

 Reducción del número de incidentes o problemas debidos a un bajo rendimiento.

 ...

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.

8. Descripción del proceso

El proceso de gestión de la capacidad

9. Conceptos básicos

Equilibrio de la gestión de la capacidad

La imagen anterior simboliza la gestión 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 gestión de la capacidad

El ciclo de vida de la capacidad se puede definir con tres actividades principales, que se
detallan a continuación.

El punto de entrada de estas actividades está relacionado con el proceso de estrategia de

servicios.

El ciclo de vida de la gestión de la capacidad

b. Los diferentes subprocesos

La gestión de la capacidad está compuesta de tres subprocesos.
 Algunas actividades de estos subprocesos son similares, aunque cada subproceso tiene un
objetivo muy diferente.

Gestión de la capacidad de negocio (BCM)

El objetivo principal del subproceso de gestión de la capacidad de negocio es garantizar que
los requerimientos de negocio futuros para los servicios informáticos se tienen en cuenta y
están incluidos, y que se planifica y pone en marcha dentro de plazo una capacidad
informática 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 informática.

Los requerimientos de negocio futuros para los servicios informáticos se cuantifican,

diseñan, planifican y ejecutan en plazos.

Gestión 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 también 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 gestión, el control y la previsión:

 Del rendimiento de principio a fin.

 Del uso de los servicios informáticos operativos.

 De la producción y de las cargas de trabajo.

Gestión de la capacidad de los componentes (CCM)

El objetivo principal de este subproceso es la gestión, el control y la previsión del
rendimiento, del uso y la capacidad de los componentes tecnológicos de la infraestructura
informática.

Este subproceso también tiene como objetivo garantizar que todos los componentes de la
infraestructura informática que tienen un recurso limitado sean supervisados y medidos y
que los datos obtenidos se registren, analicen y reporten.

c. Producción del plan de capacidad

El plan de capacidad se construye a partir de los elementos que provienen de las diferentes
actividades de la gestión de la capacidad.
 Producción del Plan de capacidad

La gestión de la capacidad proporciona un plan de capacidad que engloba:

 Los recursos informáticos.

 La financiación necesaria.

 La justificación del coste de este gasto.

El plan de capacidad se establece teniendo en cuenta las necesidades expresadas por el

proceso de gestión del porfolio de servicios, así como por los PBA (Pattern Business
Activity).

Cuando se aplica el proceso de gestión de la continuidad, las necesidades particulares de

este proceso se deben tener en cuenta en el proceso de gestión de la capacidad.

El plan de capacidad también tiene como objetivo soportar el plan de la empresa.

La producción 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 año 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 gestión

informática. Los proveedores de servicios informáticos y la dirección de la organización TI
actúan sobre este último para planificar la capacidad de la infraestructura informática.

El plan de capacidad contiene la información sobre el uso actual de los servicios y los
componentes.

También contiene los planes para el desarrollo de la capacidad informática, 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 continuación encontrará un ejemplo de lo que puede contener un plan de capacidad:

 Introducción

 Perímetro del plan

 Método de recogida de información

 Hipótesis

 Escenarios de negocios

 Resumen de servicios

 Resumen de los recursos

 Tasa de utilización actual

 Previsiones del uso de servicios y recursos

 Opciones de mejora de los servicios

 Modelo de costes

 Recomendaciones

d. Gestión de la demanda
El proceso de gestión de la petición debe permitir a la gestión 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 informática.

La modelización se realiza a partir de estas peticiones.

e. Modelización
El objetivo principal del proceso de la gestión de la capacidad es predecir el
comportamiento de los sistemas informáticos, respecto a un volumen y variedad de tareas
dadas.

El objetivo de la modelización es beneficiarse de la ejecución de los subprocesos de la

gestión de la capacidad.

La modelización se puede basar en estimaciones que son resultado de la experiencia, en la

información actualizada, relativa al uso de los componentes, o en estudios piloto.

También se puede realizar basándose 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 modelización, es necesario crear un modelo de referencia
que refleje exactamente el rendimiento en curso.

Solo después se puede realizar la modelización. Para esto vamos a hacernos, por ejemplo,
la siguiente pregunta: «¿qué pasaría si?».

Esta pregunta puede estar relacionada con los fallos, los cambios planificados efectuados,
los volúmenes y la variedad de las cargas de trabajo.

Análisis de las tendencias

Es posible efectuar un análisis de las tendencias sobre el uso de los componentes a partir
de la información del rendimiento de los servicios que se ha recogido en el proceso de
gestión de la capacidad.

El análisis de la tendencia solo proporciona las estimaciones sobre el uso futuro de los
recursos.

Este análisis puede ayudar en la toma de decisiones y en la definición del plan de

capacidad.

Modelos analíticos
Existen modelos analíticos que son representaciones del comportamiento de los sistemas
informáticos.

Estos modelos utilizan técnicas matemáticas; por ejemplo, teoría de la cola de espera de
red de clase múltiple.

El modelo se construye normalmente a través de un paquete de software, especificando en

el paquete los componentes y la estructura de la configuración que se necesita modelizar.

También conviene precisar el uso del componente, por ejemplo: CPU, memoria, disco o red,
para numerosas tareas o aplicaciones.

Dimensionamiento de la aplicación
El objetivo principal del dimensionamiento de la aplicación 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 también es asegurar que el dimensionamiento obtenido va a garantizar que se

satisfacen los niveles de servicio requeridos.

La modelización se puede utilizar en el proceso de dimensionamiento de la aplicación.

f. Las actividades iterativas de la gestión de la capacidad

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

A partir de los datos obtenidos por un determinado número de controles y entradas de

información (acción de «Check»), se podrá realizar una acción de análisis (acción de
«Act»).

A partir de este análisis, será posible definir las acciones que se deben poner en marcha
(acción de «Plan»).

En ese momento, solo faltará implementar las acciones definidas (acción 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 información muy variada:

 Datos técnicos.

 Financieros.

 De uso.

 de negocio.

 De servicios.

A partir de estos datos, el responsable de la capacidad estará en disposición de

proporcionar los informes de gestión y, sobre todo, el plan de capacidad.

Gestión de la disponibilidad
1. Enfoque
En esta sección vamos a ver cómo se asegura la disponibilidad de los servicios por parte de
la organización TI.

Veremos que la disponibilidad de los servicios y su calidad dependen mucho de la eficacia

de este proceso.

2. ¿Por qué una gestión de la disponibilidad?

Hoy en día, las empresas son cada vez más dependientes de las tecnologías de la
información.

La disponibilidad y fiabilidad de los servicios informáticos 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
más o menos importante para la empresa y el cliente.

Por esta razón hoy en día la gestión de la disponibilidad resulta esencial para garantizar que
la organización TI libere los niveles de disponibilidad de servicios, tal y como fueron
definidos en los SLA.

La satisfacción del cliente y los usuarios depende directamente de la disponibilidad del

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

3. Objetivos del proceso

Los objetivos principales del proceso de gestión 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 organización 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 guía en todos los problemas relacionados con la

disponibilidad para el resto de los sectores de la organización TI y de la empresa.

 Evaluar el impacto de todos los cambios solicitados, en términos de plan de

capacidad, recursos y rendimiento.

 Asegurar que las medidas proactivas se implementan cuando es necesario y tienen

justificación financiera.

4. Definiciones
Disponibilidad: aptitud de un servicio TI o un componente para cumplir la función
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. También 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 informático continuo (sistemas y datos que residen en él), respetando los
parámetros de confidencialidad, integridad y disponibilidad (ver sección Seguridad -
Concepto CIA).

Función vital de negocio (VBF): elementos de negocio críticos 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 función de las restricciones presupuestarias.

5. Perímetro
La gestión de la capacidad tiene a su cargo el conjunto de la infraestructura informática.

La gestión de la capacidad también se debe hacer cargo de todos los cambios

proporcionados por la gestión de los cambios y que conciernen a la infraestructura.

La gestión de la disponibilidad se centra en dos tipos de actividades: las actividades

reactivas y las actividades proactivas.

Estas actividades se desarrollan más extensamente en la sección sobre conceptos básicos.

6. Roles
Los roles principales son los siguientes:

 Responsable de la disponibilidad

 Propietario del proceso

7. Indicadores
Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se
pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:

 Conformidad de la disponibilidad prevista.

 Tiempos de no disponibilidad.

 Número de no disponibilidades.

 MTTR (Mean Time To Repair), MTBSI (Mean Time Before Service Incidents), MTBF
(Mean Time Before Failure)...

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.
8. Descripción del proceso

El proceso de gestión de la disponibilidad

9. Conceptos básicos
El proceso de gestión 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 están implicadas fundamentalmente en los roles operativos. Entre las
actividades reactivas de la gestión de la disponibilidad, podemos identificar la medida, el
análisis y la gestión de todos los eventos encontrados durante el periodo de suministro del
servicio (evento, incidente o problema), generando una disminución de la disponibilidad o
la no disponibilidad parcial o total.

Como sucede con cualquier proceso, la gestión de la disponibilidad debe proporcionar

informes de la disponibilidad de los servicios y componentes.

b. Las actividades proactivas

Para ser eficaz, la gestión de la disponibilidad debe tener actividades proactivas.

Estas actividades se centran en una planificación proactiva, una implicación en el diseño y

la mejora de la disponibilidad.

Estas actividades están implicadas fundamentalmente en los roles de diseño y planificación.

 Las actividades proactivas de la gestión de la disponibilidad son:

 Identificar las funciones vitales de negocio (VBF - Vital Business Functions).

 Diseño con vistas a la disponibilidad.

 Análisis del impacto del fallo de un componente.

 Análisis del punto de fallo único.

 Análisis por árbol de fallos.

 Modelización.

 Análisis y gestión de los riesgos.

 Calendario de pruebas de la disponibilidad.

 Mantenimiento preventivo y planificado.

 Producción de documentos de la disponibilidad proyectada del servicio

(PSA - Projected Service Availability).

 Revisión y mejora continua.

c. Seguridad - Concepto CIA

La seguridad es un punto importante en el proceso de gestión de la disponibilidad.

La disponibilidad también refleja cómo los usuarios acceden a los sistemas de información y
a la información que contienen.

La gestión 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 diseño de la
disponibilidad, especialmente para:

 El acceso lógico y físico 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 gestión 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 gestión de la seguridad es responsable de definir las políticas de seguridad de la
empresa y asegurar la conformidad con las directivas de seguridad en el seno de la
organización TI. Sin embargo, el proceso de gestión de la disponibilidad debe poner en
práctica las políticas de seguridad definidas por la gestión de la seguridad.

d. Los diferentes tipos de disponibilidad

Alta disponibilidad: característica de un servicio TI que minimiza u oculta a ojos del
usuario los efectos de los errores de un componente TI.

Operación continua: característica de un servicio TI que minimiza u oculta a ojos del

usuario los efectos de un periodo de no disponibilidad planificado.

Disponibilidad continua: característica 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. Cálculo 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 cómo se definen estos diferentes indicadores.

 Modo de cálculo de los indicadores

El MTTR, duración media de reparación o tiempo de no disponibilidad, también 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 detección, diagnóstico (o tiempo de respuesta), reparación, restauración y
recuperación.

El MTBF es la duración media durante la cual el servicio está disponible. También se llama
Up Time o tiempo disponible.

El MTBSI es el tiempo medio entre dos incidencias.

Es importante que el indicador MTBF sea lo más elevado posible. También es importante
que el indicador MTBSI sea, del mismo modo, lo más elevado posible. En caso contrario,
esto provocará la aparición de múltiples periodos de no disponibilidad, lo que perjudicará la
calidad percibida por el cliente, aunque el indicador MTBF esté en los límites 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 gestión de la disponibilidad.

Este plan debe contener:

 Los fines.

 Los objetivos.

 Los elementos de gestión (personal, herramientas técnicas...).

 Para elaborar el plan de disponibilidad, es deseable poner en contacto a los
propietarios/responsables de los siguientes procesos:

 La gestión de los niveles de servicios.

 La gestión de la continuidad de los servicios.

 La gestión de la capacidad.

 La gestión financiera.

El plan de disponibilidad debe cubrir un periodo de 1 a 2 años y se deberá hacer una

revisión regular 3 o 4 veces por año.

El plan de capacidad y el plan de disponibilidad son complementarios.

g. El coste de la no disponibilidad
La aplicación del proceso de gestión de la disponibilidad tiene un coste.

Algunas veces es necesario justificar este coste.

Una buena manera de justificar esta inversión es presentar los costes de no disponibilidad.

La tabla siguiente aporta una buena metodología de presentación de los costes de no

disponibilidad y sus consecuencias en la relación con el cliente.
 Coste de la no disponibilidad

10. Beneficios y dificultades

a. Beneficios
El interés de la puesta en marcha del proceso de gestión de la disponibilidad reside en que
permite identificar un responsable único de la disponibilidad del conjunto de servicios
operativos.

Esto también permite tener una persona responsable capaz de responder a las necesidades
expresadas por las diferentes áreas de negocio.

b. Dificultades potenciales
La principal dificultad que puede surgir se relaciona con el volumen y la complejidad de los
elementos que hay que manejar.

La dificultad más 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.

Gestión de la continuidad de los servicios

1. Enfoque
En esta sección vamos a ver cómo la organización TI se asegura de la continuidad de
servicios informáticos.

En el vocabulario que se usa en la continuidad de los servicios, se utiliza de manera

habitual el término 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 gestión de la continuidad?

Las empresas cada vez dependen más de sus equipos informáticos. Un fallo grave puede
tener consecuencias desastrosas para la empresa.

En un número importante de casos, un fallo informático grave conduce a la desaparición de

la empresa.

Sin embargo, aún hoy en día, un gran número de empresas nunca ha puesto en práctica un
plan de continuidad de servicios.

La crisis económica ha obligado a muchas empresas a reducir sus presupuestos

informáticos, incluidos los destinados a copias de seguridad y a la no interrupción de las
actividades. Sin embargo, deben encontrar el equilibrio adecuado entre los costes y los
riesgos, evaluando las pérdidas potenciales en caso de desastre y, sobre todo, el tiempo
que se necesitaría para devolverlo todo a un estado normal de funcionamiento.
 La gestión de la continuidad de los servicios es un elemento esencial de la noción de
garantía en la definición del valor del servicio.

Cuanto más complejas son las aplicaciones, más graves son las consecuencias en caso de
avería.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión de la continuidad de servicios informáticos
son los siguientes:

 Sostener el proceso global de gestión 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 práctica los planes de continuidad, respetando

los niveles de servicio, principalmente en términos 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 organización 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 límites de un coste justificable.

4. Definiciones
BCP (Business Continuity Plan): plan de continuidad del negocio.

BCM (Business Continuity Management): proceso que se ocupa del análisis y gestión del
riesgo, con el objetivo de que la organización pueda asegurar, en todo momento, la
capacidad de producción o el suministro de los servicios mínimamente requeridos.

BIA (Business Impact Analysis): método de análisis del impacto en el negocio que permite
evaluar las pérdidas potenciales durante un siniestro.

DRP (Disaster Recovery Plan): plan de restablecimiento o recuperación informática.

5. Perímetro
La gestión de la continuidad tiene a su cargo toda la infraestructura informática o parte de
ella.

El proceso de continuidad de los servicios (ITSCM) se encarga de:

 Lo que está en el perímetro del proceso y las reglas que tiene asociadas.

 Los BIA (existentes y actualizados), para identificar el impacto en caso de

funcionamiento incorrecto.
  La identificación y la gestión 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 práctica los planes
de continuidad.

6. Roles
Los principales roles son los siguientes:

 Responsable de la continuidad de servicios.

 Propietario del proceso.

7. Indicadores
Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se
pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:

 Índice de formación de los equipos.

 Tiempo de puesta en marcha del plan.

 Tiempo de recuperación.

 Tiempo de retorno a un servicio normal.

 Tiempo para adoptar los nuevos servicios...

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.

8. Aspectos identificables en un BIA (Business Impact

Analysis)
La introducción de un BIA debe permitir la identificación y posterior prevención de un cierto
número de riesgos, como por ejemplo:

 Pérdida de la capacidad operativa.

 Pérdida de ventajas competitivas.

 Pérdida de beneficio.

 Gastos adicionales.

 Reputación dañada.

 No respetar las obligaciones legales.

 Riesgo para la seguridad del personal.

 Pérdida inmediata a largo plazo de partes de mercado.

9. Descripción del proceso

El proceso de gestión de la continuidad

10. Conceptos básicos

a. Ciclo de vida de la gestión de la continuidad de servicios

Ciclo de vida de la gestión de la continuidad

Fase 1 - Iniciación
Durante esta fase, la primera etapa es determinar cuáles son las políticas puestas en
marcha.

La segunda etapa consiste en determinar cuál será el perímetro que se tendrá en cuenta en
el plan de continuidad de servicios.

La última etapa consiste en poner en práctica el proyecto.

Fase 2 - Requerimientos y estrategias

La primera etapa consiste en hacer un análisis de impactos en el negocio, área por área y
servicio por servicio.

La segunda etapa consiste en una evaluación de los riesgos. Para ello es posible utilizar el
método CRAMM (ver la sección El método CRAMM).
La última etapa consiste en definir la estrategia de continuidad de servicios informáticos.

Fase 3 - Puesta en marcha

La primera etapa de esta fase es desarrollar los planes de continuidad de servicios
informáticos.

La segunda etapa es desarrollar los planes informáticos, los planes de recuperación y los
procedimientos relacionados con estos planes.

La tercera etapa consiste en la planificación de la organización.

Para terminar esta fase, la última etapa consiste en la puesta en práctica de la estrategia
de pruebas.

Fase 4 - Gestión operativa

Para esta última fase, en la primera etapa, es necesario formar, educar y sensibilizar a los
empleados.

Durante la segunda etapa, también es necesario poner en práctica las auditorías 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 función de la planificación elaborada en el plan de pruebas.

La última etapa consiste en tener en cuenta la gestión de los cambios.

 Resumen de las actividades de puesta en marcha

b. El método CRAMM
El método CRAMM fue creado en 1987 por la agencia central de informática 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 método de análisis de riesgos conforme a las normas BS 7799 e ISO 17799.

El método CRAMM está estructurado en las tres fases siguientes:

1 - Definición de los valores de riesgo.

2 - Análisis de los riesgos y de vulnerabilidad.

3 - Definición y elección de las medidas de seguridad.

Definición de los valores

Esta primera fase consiste inicialmente en determinar el perímetro de estudio y organizar
las actividades. Seguidamente se procede a la definición de los valores (los activos de la
organización TI) y su importancia relativa.
 Análisis de los riesgos y de la vulnerabilidad
Durante esta fase, se agrupan los valores en función de las necesidades relativas a
disponibilidad, integridad y confidencialidad de los datos (ver Gestión de la disponibilidad -
Conceptos básicos).

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.

Definición y elección de las medidas de seguridad

Durante esta fase será necesario definir las necesidades en términos de medios de
seguridad y compararlas con la seguridad existente.

Seguidamente se debe diseñar el plan de medidas de correcciones que se deben aplicar

para reducir los riesgos a un nivel aceptable.

Gestión de los riesgos

11. Las soluciones de continuidad de servicios

Es útil recordar que, cualquiera que sea la solución 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 efectúe unas transferencias de salario
equivalentes a las del mes anterior.
 En cambio, los servicios relacionados con la producción formarán parte del plan de
continuidad de servicios.

a. No hacer nada
Paradójicamente, esta es la solución adoptada por la gran mayoría de las empresas.

Las razones de esta elección 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 también 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. Solución temporal manual

Esta solución se utiliza en empresas pequeñas.

Normalmente consiste en almacenar las copias de seguridad en una ubicación más o menos
segura.

Si no hay disponible ningún equipamiento informático, se prevé volver al trabajo

directamente en papel.

No hay plan de continuidad de servicios.

Esto también significa que, como en la solución 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 recíprocos
Esta solución se usa por los PME y consiste en acuerdos, formalizados o no, entre dos
empresas próximas la una a la otra.

Estas empresas tienen tamaños relativamente similares y utilizan, en parte, software

similar.

Esta solución se puede poner en práctica 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 informático.

Si hablamos de siniestro de tipo natural (geográfico o climático), esta solución no tiene

ningún valor, ya que no se podrá aplicar.

Por ejemplo, en las inundaciones sufridas en la ciudad de Nueva Orleans, provocadas en el

año 2005 por el huracán Katrina, toda la zona de actividad estaba inundada, lo que hacía
imposible la puesta en marcha de esta solución.

La situación será la misma en caso de siniestro eléctrico, salvo que el acuerdo se realizara
con una empresa físicamente 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 tamaño, pueden poner en marcha un plan de continuidad
de servicios de manera interna, ya que disponen de varios centros informáticos en regiones
diferentes.

En los dos casos, se pueden poner en práctica los siguientes modelos.

Soluciones de hardware
Existen varias ofertas de soluciones de hardware:

 Alquiler de camión con un equipamiento básico, que se pone a disposición 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 máximo de 21 días. Si otra empresa necesita la sala,
deberá esperar el fin del periodo de 21 días para poder disponer de ella.
Estadísticamente, la posibilidad de ver dos empresas solicitando la sala al mismo
tiempo es muy baja, casi improbable. Por lo tanto, esta solución 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 solución
es muy costosa, lo que explica las reticencias de muchas empresas.

 Ubicación de seguridad propiedad de la empresa: en este caso la empresa

decide equipar una sala en una ubicación distante para hacer de ella una ubicación
de respaldo. De nuevo, la empresa podrá equipar con antelación la ubicación de
respaldo.

 Ubicación espejo: en este caso, la empresa va a poner en marcha una solución de

redundancia/mirroring entre dos ubicaciones. Si una de las ubicaciones cae, la otra
puede responder a las operaciones sin demora. Hoy en día, solo los grandes grupos
son capaces de poner en práctica una solución como esta.

e. Los diferentes tipos de recuperación

Recuperación gradual
También llamada recuperación progresiva o Cold stand-by, esta solución prevé una
recuperación en un plazo de más de 72 horas.

Esta solución suele estar vinculada con un tipo de plataforma de seguridad: alquiler de
camión equipado o alquiler de sala blanca compartida.

Recuperación intermedia
Llamada recuperación intermedia o Warm stand-by, esta solución prevé una recuperación
en un plazo comprendido entre 24 y 72 horas.

Con esta solución, la empresa se va a organizar para poner en marcha su ubicación de

respaldo lo más rápidamente 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 actualización del sistema de información con los datos de la última versión
de la copia de seguridad, lo que requiere tiempo.
 Recuperación inmediata
Llamada también Hot stand-by, esta solución prevé una recuperación en un plazo de
menos de 24 horas.

Con esta solución la empresa se va a organizar para poner en marcha su ubicación de

respaldo lo más rápidamente posible, en menos de 24 horas. Esto implica que se debe
realizar una actualización diaria de los datos de la ubicación de respaldo.

f. Plan de recuperación genérico

A continuación proporcionamos un ejemplo de lo que podría contener un plan de
recuperación:

 Introducción

 Entrada en producción

 Roles y responsabilidades

 Estrategia de recuperación

 Activación

 Personal de recuperación

 Dependencias

 Lista de verificación del equipo de recuperación

 Condiciones de vuelta a la normalidad

12. Precauciones que hay que tener

La puesta en marcha de un plan de continuidad de servicios informáticos implica tomar
algunas precauciones.

La primera es saber que se debe tratar de un proyecto completo.

Para ser operativo, el plan de recuperación se debe poner en práctica por parte de un
equipo claramente identificado.

Este equipo debe seguir obligatoriamente una formación para que cada uno de los
empleados sepa con exactitud qué debe hacer y cuándo debe hacerlo.

Se deben realizar pruebas obligatoriamente.

En función de la empresa, estas pruebas se deben llevar a cabo como mínimo todos los
meses.

Las pruebas se deben realizar en condiciones lo más 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 ubicación 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 más importante el día 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.

13. Beneficios y dificultades

a. Beneficios
Los beneficios de la gestión de la continuidad son numerosos, pero, si hay uno que vale la
pena destacar sobre los demás, es que la supervivencia de la empresa, en caso de siniestro
grave, a menudo depende de la puesta en marcha de este proceso.

b. Dificultades potenciales
La dificultad más importante para poner en marcha este proceso consiste en obtener un
acuerdo con las partes encargadas de la generación de la estrategia y la gestión financiera.

Gestión de la seguridad
1. Enfoque
En esta sección vamos a ver cómo se asegura la seguridad informática a nivel de la
organización TI.

La eficacia de este proceso es importante para garantizar la calidad de la información

proporcionada por la organización TI, y también 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 práctica políticas para ello.

2. ¿Por qué una gestión de la seguridad?

Hoy en día, la gestión de seguridad es una necesidad y una obligación para todas las
empresas.

Se debe definir y poner en práctica una política de seguridad.

Su puesta en marcha debe garantizar que satisfaga las necesidades del negocio, así como
las de la organización TI.

La gestión de la seguridad debe sensibilizar sobre el cumplimiento de las normas de

seguridad, tanto a las personas de la organización TI como a los usuarios de los servicios
proporcionados por la organización TI.

La gestión de la seguridad se debe asegurar de que los proveedores del servicio

comprenden y aplican las políticas de seguridad.

La gestión de la seguridad debe gestionar todos los aspectos relativos a las tecnologías de
la información, la seguridad informática, la seguridad de los accesos y la gestión de
documentos.

La gestión de la seguridad es una parte importante para la noción de garantía de un

servicio y esto está relacionado con la definición de la calidad del servicio.

La gestión de la seguridad se debe considerar como una parte de la gestión de la empresa.

 La seguridad, como la calidad, debe ser un estado de ánimo que hay que mostrar todos los
días.

3. Objetivos del proceso

Los principales objetivos del proceso de gestión de la seguridad son los siguientes:

 Proteger la información 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 políticas de seguridad se definen en el proceso de gestión de la seguridad.

La puesta en marcha de estas políticas se lleva a cabo en el proceso de gestión de la

disponibilidad y en el centro de servicios.

4. Definición
No hay una definición especial para este proceso, aparte de la definición de la regla CIA
que se describió en la sección Seguridad - Concepto CIA.

5. Perímetro
La gestión de la seguridad tiene a su cargo el conjunto de la organización TI y de la
infraestructura informática.

La seguridad informática se refiere al conjunto del perímetro de la infraestructura

informática.

La seguridad también implica el respecto de la legalidad (reglas y políticas).

La seguridad también debe tener en cuenta las obligaciones definidas por el cliente en los
SLA.

La seguridad se refiere no sólo a los sistemas y datos, sino también a los accesos y a las
personas.

Se debe tener en cuenta el conjunto lógico y físico de la organización TI.

6. Roles
Los roles principales son los siguientes:

 Responsable de la seguridad.

 Propietario del proceso.

7. Indicadores
Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se
pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:
  Número de incidencias de seguridad.

 Tiempo de no disponibilidad debido a una incidencia de seguridad.

 Número de no disponibilidades debido a incidencias de seguridad...

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.

8. Descripción del proceso

El proceso de gestión de la seguridad

9. Conceptos básicos
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 gestión de la seguridad es responsable de definir las políticas 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 protección (Data Protection Act/CNIL), datos médicos e
información estratégica.

 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: información de medidas e información de identificación (nombre,

dirección).

 Low: sin requerimientos.

Disponibilidad

 High: 24 horas al día, 99,5%.

 Medium: de 07:00 a 19:00, 99%.

 Low: sin requerimiento.

b. Las actividades y responsabilidades

Estratégica
La definición de las políticas de seguridad se establece a nivel estratégico.

Táctica
Las actividades a nivel táctico son las siguientes:

 Establecimiento de los niveles de seguridad en las SLA y suministro de servicios,

respetando los acuerdos.

 Implantación de las medidas de seguridad para controlar (gestión de la

disponibilidad): Confidencialidad/Integridad/Disponibilidad.

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 (gestión de las

incidencias y problemas).

 Participación en el análisis de impacto de los RFC.

  Puesta en marcha segura de los cambios (gestión de las entradas en producción).

Aplicación de la Rueda de Deming

Las actividades de este proceso concuerdan con el modo tradicional de funcionamiento de
los procesos.

Es una aplicación 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 través del proceso de
gestión de las incidencias.

En función de su importancia, esta incidencia puede activar la creación de un problema.

En función de los resultados del análisis, esto puede dar lugar a una petición de cambio,
incluso a una petición de cambio urgente.

Esto también puede dar lugar a la creación 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

10. Beneficios y dificultades

a. Beneficios
La puesta en marcha de la gestión 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 tendría que soportar en caso de siniestro causado por un fallo de
seguridad, pérdida o corrupción de archivos o accesos no autorizados a información vital de
la empresa, este coste es muy razonable.

b. Dificultades potenciales
La puesta en marcha de este proceso se enfrenta a menudo con la dificultad de gestión de
los códigos de acceso.

¿Cómo implementar una política de seguridad sobre los derechos de acceso y conseguir
que los usuarios respeten esta política?

Una complicación excesiva de los códigos implica a menudo una reacción bien conocida por
todos: se anota el código en un Post-it y se deja en el cajón, sobre el teclado o en la
pantalla.

Por lo tanto, es necesario conseguir la adhesión del personal a esta política.

La gestión de la seguridad, al menos en las empresas grandes y medianas, se convierte en

un trabajo a tiempo completo que requiere una formación especial.

Es cierto que, en el caso de las empresas pequeñas, el establecimiento de este proceso se

simplifica, ya que el tamaño del perímetro que hay que proteger es un elemento
importante.

Gestión de los proveedores

1. Enfoque
En esta sección vamos a ver cómo se asegura la gestión de los proveedores.

Este proceso es importante, ya que permite garantizar la calidad del servicio.

2. ¿Por qué una gestión de los proveedores?

La elección de un proveedor no se puede hacer basándose únicamente en el precio.

De hecho, es imprescindible que la calidad del servicio de la organización 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 través de los contratos de tipo UC
(Underpinning Contract).

3. Objetivos del proceso

Los principales objetivos del proceso de gestión de los proveedores son los siguientes:

 Negociar los contratos y firmarlos.

 Asegurar el seguimiento del funcionamiento de los contratos.

 Asegurar una buena relación 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 están alineados con los objetivos de los SLA.

 Definir y mantener una política para proveedores.

4. Definición
No hay definición particular para este proceso.

5. Perímetro
La gestión de proveedores tiene que ver con las relaciones entre la organización TI y el
proveedor (también llamado subcontratista).

6. Roles
Los roles principales son los siguientes:

 Responsable de los proveedores.

 Propietario del proceso.

7. Indicadores
Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se
pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:

 Número de incidencias en el suministro de los servicios.

  Tiempo de no disponibilidad debido a una incidencia en el suministro del servicio.

 Número de no disponibilidades debidas a una incidencia en el suministro del

servicio...

Es necesario añadir a esta lista los indicadores definidos en el contrato de tipo UC, firmado
entre el proveedor y la organización TI.

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.

8. Descripción del proceso

El proceso de gestión de los proveedores

9. Conceptos básicos
a. Negociaciones antes de la firma del contrato
La puesta en marcha de este proceso permite negociar los contratos y obtener una relación
calidad/precio ventajosa por parte de los proveedores.

También es necesario estar seguros de que los contratos de subcontratación y los acuerdos
con los proveedores están 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. Después 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 política de proveedores y respaldar las bases de datos de contratos y
proveedores (SCD - Supplier & Contracts Database).

El responsable del proceso deberá asegurar la categorización de los proveedores y el

mantenimiento de la base de datos de proveedores y contratos (SCD).

El seguimiento de los contratos incluye una evaluación anual de los resultados.

Al final del contrato, la decisión de su renovación o no se deberá tomar en función de los

resultados globales obtenidos a lo largo de la duración del contrato.

10. Beneficios y dificultades

a. Beneficios
La gestión de los proveedores permite un seguimiento más eficaz de estos, así como
garantizar que se cumplen los acuerdos de servicio definidos (SLA y OLA).

b. Dificultades potenciales
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 transición de servicios
1. ¿Por qué una transición de servicios?
Como hemos visto en el capítulo de presentación de la norma, ITIL está dividido en
procesos estratégicos, tácticos y operativos.

Los niveles decisionales de la gestión de servicios

Los procesos de transición de servicios se sitúan al mismo tiempo en la parte táctica y en la

parte operativa.
 Este posicionamiento, que puede sorprender, resulta sin embargo lógico, ya que el rol de
los procesos de esta fase es proporcionar un vínculo entre los procesos que elaboran los
servicios y los procesos de explotación que entregan los servicios.

Uno de los objetivos de la transición 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
organización.

La transición de servicios se basa en dos procesos principales:

 La gestión de los activos de servicio y configuraciones.

 La gestión de cambios.

Para una mayor eficacia, es deseable que estos dos procesos se pongan en marcha al
mismo tiempo.

2. Los objetivos de la transición de servicios

El objetivo de la transición 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 diseño 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 perímetro de la transición de los servicios

La fase de transición debe dar consejos a las fases de diseño 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 planificación, la construcción, la prueba, la evaluación y el despliegue del

cambio.

4. Los procesos de transición de servicios

 Gestión de la transición, planificación y soporte.

 Gestión de los activos de servicio y configuraciones.

 Gestión de cambios.

 Gestión de las entradas en producción.

  Validación del servicio y de las pruebas.

 Evaluación.

 Gestión del conocimiento.

Gestión de la transición, planificación y soporte

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

2. Objetivos del proceso

Los principales objetivos del proceso de gestión de la transición 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
informático.

 Identificar y gestionar los riesgos para limitar los errores en el funcionamiento

durante la fase de transición.

 Controlar y mejorar el rendimiento de las actividades de la fase de transición.

3. Perímetro del proceso

En este proceso, el perímetro de las actividades incluye el mantenimiento de las políticas,
las normas y los modelos para el conjunto de actividades y procesos de la fase de
transición.

La gestión de la transición también 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. Descripción del proceso y las relaciones principales

El proceso de transición, planificación y soporte

5. Conceptos básicos
El diseño de los servicios, en coordinación 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 transición.

Se puede leer una descripción de un paquete de servicios en la descripción del proceso de

gestión del porfolio de servicios (fase de estrategia).

Atención: este proceso no es responsable de la planificación de la construcción, las pruebas

y el despliegue de un cambio. Estas actividades se gestionan en el marco del proceso de
gestión de cambios.

6. Preparación para la transición

La transición necesita la puesta en marcha de varias actividades previas al cambio.

A continuación 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 cambios, el

empaquetado de servicios y los criterios de aceptación del servicio.
  Asegurar que se crea una base de referencia para permitir una eventual vuelta atrás.

Gestión de los activos de servicio y configuraciones

1. Enfoque
En esta sección vamos a ver cómo se gestionan los activos, así como cuál es la base de la
gestión de los activos de servicio y configuraciones (SACM): cómo se gestionan las
relaciones entre los elementos de configuración.

Atención: normalmente se habla de gestión de configuraciones, que es la definición del

proceso en la versión 2 de ITIL; esto es así por una sencilla cuestión de simplificación
terminológica.

2. ¿Por qué una gestión de los activos de servicio y de las

configuraciones?
La gestión de los activos, a menudo llamada Asset Management, no es suficiente para
describir el conjunto de componentes de un sistema de información.

Para asegurar su gestión de manera efectiva, es imprescindible tener la información

completa y precisa de la infraestructura entera del sistema de información y del conjunto
de sus componentes.

Si los servicios no se entregan en las condiciones definidas en los contratos de servicio, la

organización puede sufrir pérdidas importantes.

Debido al papel que desempeñan estos activos en el soporte a la prestación de calidad del
servicio, el valor real de los activos informáticos es normalmente superior a su valor
presupuestario.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión de configuraciones son los siguientes:

 Optimizar los activos de servicios.

 Garantizar la integridad de los elementos de configuración y las configuraciones

necesarias para mantener un CMS (Configuration Management System) operativo.

 Dar asistencia a la gestión eficaz de los servicios TI:

 Proporcionando un modelo lógico de la infraestructura de los TI y de los servicios TI.

 Aportando una base sólida a la gestión de incidencias, la gestión de problemas, la

gestión de cambios y las entradas en producción.

4. Definiciones
Activo: es un componente de un proceso de negocio:

 Proceso

 Organización
  Personal

 Información

 Software

 Infraestructura

 Capital financiero

Elemento de Configuración (CI - Configuration Item): es un activo, componente de

servicio u otro elemento que está, o estará, bajo el control del proceso de gestión de
activos y configuraciones.

Los elementos de configuración varían en complejidad, tamaño y tipo, y van desde un

servicio o sistema entero, incluidos el hardware, software, documentación y personal de
soporte, hasta un simple módulo 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 lógicas o físicas. En la
versión 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 gestión de configuraciones. El

sistema de gestión de configuraciones contiene toda la información para todos los CI
incluidos en el perímetro definido.

La CMS tiene en cuenta los datos de varias bases de gestión de configuraciones (CMDB),
que en conjunto forman una federación CMS.

En la versión 2 de ITIL se habla de CMDB (Configuration Management Data Base), y

actualmente, por analogía, muchas personas continúan hablando de CMDB en lugar de
CMS.

Baseline: configuración de referencia.

5. Perímetro
La gestión de activos de servicio y configuraciones tiene a su cargo:

 La gestión de los activos a los que se hace referencia en la gestión de los activos de
servicios y configuraciones.

 La gestión de las relaciones entre los elementos.

 La gestión de la documentación asociada a estos elementos.

6. Roles
Los roles principales son los siguientes:

 Responsable de los activos de servicio y configuraciones.

  Responsable de los activos.

 Propietario del proceso.

7. Indicadores
Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:

 Número de CI creados.

 Número de CI modificados.

 Número de CI archivados.

 Número de errores en la identificación de los CI...

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.

8. Descripción del proceso y las principales relaciones

El proceso de gestión de activos de servicio y configuraciones

9. Conceptos básicos
a. El ciclo de vida de un CI
El ciclo de vida de un CI está definido por cinco actividades que se detallan a continuación:
 El ciclo de vida de un CI

b. Las actividades de la gestión de configuraciones

Las principales actividades de la gestión de los activos de servicio y configuraciones son las
siguientes:

Planificación
La primera etapa del proceso consiste en la redacción de las especificaciones del proyecto y
la planificación de su puesta en marcha. Las estimaciones deben incluir la definición del
perímetro, los objetivos, las reglas y los procedimientos, el contexto técnico y organizativo
del proceso de la gestión de activos de servicio y configuraciones.

Identificación
Durante la segunda etapa, hay que seleccionar e identificar todos los CI de la
infraestructura. Esta identificación debe incluir los elementos siguientes: su propietario,
relaciones y documentación asociada. Para cada CI, hay que definir un identificador único y,
para alguno de ellos, un número de versión. Esta etapa termina etiquetando cada elemento
y guardándolo en la CMS.

Control
La actividad de control consiste en asegurar que solo se aceptan y registran los CI
autorizados e identificados, desde su recepción hasta su destrucción. Esta actividad permite
asegurar que ningún CI se añade, modifica, sustituye o elimina sin que haya una petición
de cambios aprobada (ver sección sobre gestión de cambios).

Gestión 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 evolución del estado del CI, fundamentalmente a través de los cambios
aprobados y las entradas en producción.

Verificación y auditoría
Además de las acciones de seguimiento, es imprescindible efectuar una serie de revisiones
y auditorías que permitan verificar la existencia real de los CI y asegurar que se registran
correctamente en el sistema de gestión 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 más importante de la puesta en marcha de una CMS es la definición de la
granularidad de la base de datos.

Es necesario tener cuidado en el momento de definir esta granularidad (ver la siguiente

sección: Beneficios y dificultades - Dificultades potenciales):

 Si es demasiado larga, faltará información importante.

 Si es demasiado fina, la gestión de la base será especialmente difícil.

Ejemplo:

Si es demasiado larga: si la base de datos solo contiene los servidores, falta información
relativa a los puestos de trabajo conectados a estos servidores.

Si es demasiado fina: ¿para qué sirve registrar y, sobre todo, gestionar el ratón del
puesto de trabajo, cuando hoy este tipo de hardware se considera como un consumible?

En principio, el establecimiento de una CMS es bastante fácil, 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á difícil mantener su
integridad, ya que su actualización resultará muy difícil.

Los atributos de un CI
Para cada elemento de configuración (CI), es imprescindible registrar un determinado
número de atributos y las relaciones existentes entre los diferentes CI.
 Recordemos que un atributo es una información relativa a un CI (ver capítulo Anexos -
Atributos de un CI).

Normalmente encontramos tres tipos de atributos:

Atributos técnicos:

 Características técnicas.

 Puesta en producción: manual o automática con herramientas de auto-diagnóstico.

Atributos administrativos:

 Ciclo de vida (cambios, incidencias...).

 Puesta en producción: manual o automática si se integran con los otros procesos.

Atributos contables:

 Tarifas, mantenimiento y licencia.

 Origen: manual.

Las relaciones de los CI

Además 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 (lógicas o físicas) entre los diferentes CI de
la infraestructura.

d. Configuración de referencia
La literatura ITIL habla de Baseline, lo que podemos traducir por «Configuración de
referencia».

Una configuración 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 configuración de referencia es utilizada normalmente por el proceso de gestión de

cambios, para permitir una marcha atrás en caso de problemas en la puesta en producción
de un cambio.

Variante
Es posible definir una versión ligeramente diferente de un CI o de una configuración de
referencia. Esto se llama variante.

10. Beneficios y dificultades

a. Gestión de licencias
Las empresas se encuentran frecuentemente con el problema de la gestión de las licencias
de software.

Debido a los diferentes medios de adquisición de software disponibles hoy día, ofertas
multilicencia, licencia de empresa y descarga individual en Internet, es difícil controlar las
compras.
 El control y la auditoría del software están bajo la responsabilidad del proceso de la gestión
de activos y configuraciones, mientras que las políticas de adquisición e instalación deben
estar bajo la responsabilidad del proceso de gestión 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 prisión si el software adquirido ilegalmente se
utiliza en la empresa.

El proceso de gestión de activos de servicio y configuraciones permite a la organización

supervisar y controlar las licencias del software, desde su compra hasta la retirada de su
explotación.

b. Beneficios
El proceso de gestión de activos de servicio y configuraciones permite un suministro
económico y eficaz de los servicios informáticos.

Entre los beneficios que aporta la gestión de activos de servicio y configuraciones, se

pueden enumerar:

 Gestión y control de los CI de valor: permite controlar el uso de estos elementos, a

quién han sido confiados y si el inventario actual se corresponde con el inventario
oficial.

 Suministro de información sobre los CI y su documentación para mantener todos los

procesos de gestión de servicios, de entradas en producción, de cambios, de
incidencias, de problemas, de capacidad y de seguridad.

 Aportando a un proceso de gestión de problemas los datos sobre las tendencias: la

información de la gestión de activos de servicio y configuraciones se asociará a las
tendencias de los problemas aparecidos sobre los tipos particulares de CI. Esta
información de tendencia en relación con los problemas permite una prevención
proactiva de problemas.

 Soporte al proceso de gestión de cambios: la información de gestión de activos y

configuraciones permite realizar un análisis de impacto y planificar los cambios con
total seguridad, eficacia y efectividad. Esto limita el impacto de los cambios sobre el
entorno de producción.

 Soporte al proceso de gestión de entradas en producción: la información de gestión

de activos de servicio y configuraciones contribuye a la integridad del sistema de
información, aportando información sobre las versiones de los CI y los cambios que
forman parte de la entrada en producción.

 Soporte al proceso de la continuidad de servicios: la CMS, las bibliotecas seguras y

las reservadas con seguridad ayudan a la restauración de los servicios informáticos
después de un fallo, identificando los CI necesarios y su localización.

 Soporte al proceso de gestión financiera: es fácil, a partir de la gestión 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 renovación de licencias, las
fechas de fin de vida de los CI y los costes de sustitución (con la condición de que
esta información se conserve).
  Respeto a las obligaciones legales: la gestión de los activos de servicio y
configuraciones conserva un inventario de todos los elementos de software de la
infraestructura informática. Las copias ilegales de software se pueden identificar
fácilmente, con el objetivo de ser regularizadas, borradas o destruidas.

c. Dificultades potenciales
Las dificultades potenciales que puede encontrar el proceso de gestión de activos y
configuraciones son:

 El proyecto que se ha puesto en marcha no está bien controlado: es necesario que

las etapas de análisis y diseño estén suficientemente desarrolladas, pues en caso
contrario el resultado final no será el esperado. Cuando los cambios y entradas en
producción se planifican, es necesario tener en cuenta el tiempo dedicado a las
actividades de gestión de activos y configuraciones.

 Puesta en marcha de manera aislada: si la gestión de activos y configuraciones se

pone en marcha de manera aislada, sin proceso de gestión de cambios o proceso de
gestión de entradas en producción, será menos eficaz y puede que no se logren los
resultados esperados.

 Incorrecta definición 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 burocrático o rígido,

las personas intentarán eludir la gestión de activos y configuraciones para ganar
tiempo o simplemente por malicia. Entonces será necesario emprender acciones de
información y formación para conseguir la adhesión de estas personas.

 Ineficacia del proceso: el proceso puede ser ineficaz y una fuente de errores cuando
se gestiona de manera manual. Hoy en día, las herramientas disponibles tienen
buenas prestaciones y permiten la recuperación automática de la información. Sin
embargo, pueden aparecer problemas cuando la herramienta de gestión de activos y
configuraciones no permite considerar las nuevas funcionalidades o no soporta todas
las categorías de CI.

 Falta de compromiso de la dirección: sin un fuerte compromiso por parte de los

dirigentes por respetarlo, el proceso de gestión de activos y configuraciones será
muy difícil de llevar a cabo.

Gestión de cambios
1. Enfoque
En esta sección vamos a ver cómo se gestionan los cambios y el impacto positivo que
puede tener la gestión de cambios en la calidad de los servicios de la organización.

Veremos que la eficacia de este proceso depende mucho de la calidad de la gestión de

configuraciones.

2. ¿Por qué una gestión de cambios?

Actualmente estamos en un mundo cambiante.

Todo evoluciona: las necesidades de las empresas, las tecnologías, 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 evaluación
de riesgos.

En la gestión de riesgos, hay que incluir la gestión 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.

Además, todas las personas que intervienen deben recibir una comunicación apropiada y
en plazos útiles para todos los cambios que les afectan.

El porfolio de servicios proporciona una definición clara de todos los servicios que están en
el pipeline, activos o eliminados. La comprensión del porfolio de servicios ayuda a las
partes implicadas en la transición 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 gestión de cambios eficaz, es indispensable tener información completa
y precisa de la infraestructura del sistema de información y el conjunto de sus
componentes. Se trata del rol de gestión de configuraciones que hemos visto
anteriormente.

Por esta razón, es aconsejable poner en marcha estos dos procesos de manera simultánea.

Finalmente, es importante tener siempre en mente la idea de que todo cambio (adición,
modificación o eliminación de un componente) en la infraestructura informática se debe
tener en cuentaobligatoriamente por la gestión de cambios antes de aplicarse.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión de cambios son los siguientes:

 Asegurar que se utilizan los métodos y los procedimientos estándares para un

tratamiento eficaz y rápido 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 también un beneficio
potencial.

4. Definiciones
Cambios: es la adición, modificación o eliminación de un CI o de una configuración de
referencia.

RFC (Request For Change): formulario que se utiliza para describir un cambio solicitado.

Cambio estándar: un cambio relativamente común, 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 implantación, con las fechas
propuestas de implantación.

PIR (Post Implementation Report): revisión posterior a la implantación que verifica que los
cambios cumplen sus objetivos, que los clientes están 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. Perímetro
La gestión de cambios se encarga de:

 Todos los cambios aportados por el diseño de los servicios.

 Todos los cambios aportados por la explotación de los servicios.

Estos cambios pueden incluir:

 Hardware

 Software

 Aplicaciones

 Contratos de servicios

 Entorno de la organización

 Documentos asociados a los diferentes CI

  Sistemas de medida (herramientas, métodos y métricas)

 Arquitecturas técnicas

6. Roles
Los principales roles son los siguientes:

 Responsable de los cambios.

 Responsable de las entradas en producción.

 Propietario del proceso.

 Miembro del CAB.

7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Número de RFC registrados.

 Número de RFC implementados con éxito.

 Número de RFC que generaron incidencias.

 Número de RFC que generaron problemas.

 Número de vueltas atrás.

 Número de cambios estándares.

 Número de cambios urgentes.

Esta lista no es exhaustiva; convendrá definir los indicadores en función de la estructura

que se aplique.
8. Descripción del proceso

El proceso de gestión de cambios

9. Conceptos básicos
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 continuación:

El ciclo de vida de un cambio

b. Los diferentes tipos de cambios
Hay tres tipos de petición de cambios:

Petición de cambios normal

Es el caso del tratamiento normal de la petición que sigue el conjunto de etapas del ciclo de
vida.

Petición de cambios estándar

Es una petición previamente autorizada por el cliente. En un primer momento, esta petición
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: petición
de instalación de un puesto de trabajo estándar.

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
estándares, después de la oportuna revisión.

Petición de cambios urgente

Es una petición que se debe poner en marcha rápidamente. En este caso, se simplifican un
determinado número 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 acción emprendida.

Significativo
Cuando el cambio tiene un nivel significativo en términos de impacto o de recursos, el
responsable de los cambios envía al CAB el conjunto de elementos relativos a la petición
para su evaluación.

La evaluación del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y
la planificación 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 dirección para pedir consejo.

Si el cambio se aprueba, se transmite al CAB para su evaluación.

La evaluación del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y
la planificación 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 petición:

Inmediata
  Riesgo de pérdidas potenciales importantes.

 Reunión del ECAB para su evaluación inmediata y toma de decisión rápida, con el
objetivo de poner en marcha el cambio lo antes posible.

 Asignar un máximo de recursos de manera inmediata para tratar el cambio.

Alta

 Impacto fuerte sobre determinados usuarios o impacto sobre un gran número de

usuarios.

 Definir la prioridad alta para la construcción y puesta en marcha del cambio.

 Asignar los recursos necesarios y planificar una rápida entrada en producción.

Media

 Sin impacto importante.

 Asignar una prioridad media y planificar el cambio para la próxima entrada en

producción planificada.

Baja

 Cambio justificado, pero sin impacto real sobre la entrega del servicio.

 Construir el cambio y planificar para la próxima entrada en producción prevista.

Esta definición solo tiene valor como ejemplo. La tabla se debe definir en función de la
organización.

e. El CAB y el ECAB
El CAB
El CAB es una entidad «de geometría variable». El responsable de los cambios es el que
debe definir la composición del CAB, en función 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,
aplicación implicada...).

El CAB no se reúne por cada petición de cambios. En términos 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 función del tamaño de la organización, estas revisiones se organizan con la presencia

física de los miembros del CAB o por vídeo o teleconferencia.

El ECAB
 Como el CAB, el ECAB es una entidad «de geometría variable». Es el responsable de los
cambios el que definirá la composición del ECAB, en función de los cambios urgentes
solicitados.

Normalmente, la composición del ECAB está limitada a dos o tres miembros que ayudarán
al responsable de los cambios a tomar una decisión rápida. Por supuesto, no hay
planificación de revisiones ECAB. Únicamente la urgencia justifica la creación de un ECAB.

f. Las actividades de la gestión de cambios

Una parte de las actividades las realiza el proceso de puesta en producción, que veremos
en el capítulo siguiente, pero cuya coordinación está asegurada por la gestión de cambios.

Las principales actividades de la gestión de cambios son las siguientes:

Recepción
El responsable de la gestión de cambios recibe los RFC que provienen:

 De los procesos de explotación de servicios.

 De los procesos de diseño de servicios.

 De los procesos de la estrategia de servicios.

De manera ideal, debería contener, como mínimo, los siguientes elementos:

 El identificador único de la RFC.

 Las referencias de las incidencias y problemas relacionados.

 La referencia del CI implicado.

 La descripción 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 estimación del impacto del cambio.

 La estimación de los recursos necesarios para la puesta en marcha.

 La estimación de los riesgos.

 Las posibilidades de marcha atrás.

Si la RFC no se completa de forma correcta, se rechaza automáticamente sin que se

registre.

Registro
Si la RFC se completa correctamente, se registra.
El tipo de la petición de cambio puede ser:

 Normal

 Estándar (si todavía no se ha identificado)

 Urgente

En función del tipo de cambios, el tratamiento es diferente.

Ahora vamos a ver en detalle el tratamiento de una petición normal.

Evaluación
Los miembros del CAB examinan los elementos recibidos para cada cambio registrado.

Para esta evaluación, 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.

Autorización
Se habla de autorización o aprobación 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.

Reúne al CAB o al ECAB para obtener sus evaluaciones y tener en cuenta sus consejos
antes de tomar su decisión.

Construcción
Esta parte se realiza en el ámbito del proceso de gestión de entradas en
producción.

La gestión de cambios tiene un papel de coordinación en la construcción de los cambios y

en la puesta en producción.

Es importante preparar un plan de marcha atrás, especialmente tomando una

configuración de referencia (ver sección de Gestión de los activos de servicio y
configuraciones).

También 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 más cercano posible al entorno de producción.
En el caso de un cambio urgente, en función de la urgencia, puede ser que el plan de
vuelta atrás y el plan de pruebas no se estudien ni realicen.

Pruebas
Esta parte se realiza en el ámbito del proceso de gestión de entradas en
producción.

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 producción
Esta parte se realiza en el ámbito del proceso de gestión de entradas en
producción.

Como consecuencia de las etapas anteriores, la gestión de cambios pasa el testigo al

proceso de entradas en producción, que veremos en el capítulo siguiente.

Como consecuencia de la entrada en producción, se regresa al proceso de gestión de

cambios para realizar la última etapa de la gestión de cambios.

Reporting
Como consecuencia de la entrada en producción del cambio, es imprescindible hacer
balance de la petición de cambio.

Esta operación se traduce en la creación de un documento llamado PIR (Post

Implementation Review).

Durante esta revisión, se deben analizar todos los aspectos técnicos de la puesta en
marcha:

 Nivel de recursos consumidos en relación con las previsiones.

 Tiempo de puesta en marcha en relación con las previsiones.

 Dificultades encontradas.

 Número de incidencias creadas.

 Número de problemas creados.

  ¿La marcha atrás se ha iniciado?

 Los resultados son consistentes con los objetivos...

Como consecuencia de esta revisión, será posible cerrar todos los tickets «Problema» e
«Incidencia» relacionados con el cambio.

Atención: en el ámbito de un cambio de software o de aplicación, es imprescindible que el

personal del Centro de servicios y los usuarios hayan recibido correctamente la formación
necesaria para aprender la nueva versión.

Del mismo modo, deberemos asegurarnos de que la documentación, tanto para un cambio
de software o de aplicación como para un elemento de infraestructura, esté a disposición
del personal del centro de servicios y de los usuarios.

Cambio normal y cambio urgente

g. Las «7 R» de la gestión de cambios
En los libros en inglés se menciona el término 7 R, ya que en cada pregunta encontramos
una palabra que empieza por la letra R como asunto principal. Encontrará entre paréntesis
la palabra inglesa.

Para cualquier petición de cambio, es obligatorio hacerse las siete preguntas siguientes:

 ¿Quién pide el cambio? (Who Raised)

 ¿Cuál es el motivo para esta petición? (Reason)

 ¿Cuál es el resultado esperado de este cambio? (Return)

 ¿Cuáles son los riesgos potenciales de este cambio? (Risks)

 ¿Qué recursos hay que poner en marcha para hacer este cambio? (Resources)

 ¿Quién es responsable de la construcción, las pruebas y la implementación del

cambio? (Responsible)

 ¿Cuáles son las relaciones entre este cambio y los otros cambios? (Relationship)

Sin estos elementos, la evaluación del impacto del cambio en la entrega no es posible.

El análisis de los riesgos y beneficios es imprescindible para asegurar las ventajas del
cambio.

10. Beneficios y dificultades

a. Beneficios
El proceso de gestión de cambios permite una gestión eficiente de todas las modificaciones,
asegurando que los cambios que se han puesto en marcha no afectarán a la calidad de los
servicios proporcionados por la organización ni a los niveles de servicio contractuales.

Entre los beneficios que aporta la gestión de cambios, podemos incluir:

 Mejor evaluación del coste de los cambios solicitados.

 Mejor evaluación de los costes reales de los cambios aplicados.

 Mejor respuesta a los requerimientos del negocio.

 Reducción del impacto negativo de los cambios sobre la calidad de los servicios
proporcionados por la organización.

 Cumplimiento de los compromisos establecidos en los SLA.

 Mejora de la gestión de los incidentes y de la gestión de los problemas (garantía de

que la información relativa a la infraestructura se suministra antes del cambio).

 Mejora de la gestión de la disponibilidad y de la gestión de la continuidad, mediante

un mejor conocimiento de la evolución de las infraestructuras.

 Disminución de los riesgos, ya que se tienen en cuenta los cambios en la gestión de

la seguridad.
  Productividad mejorada para los equipos de la organización, 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.

b. Dificultades potenciales
Las dificultades potenciales que podemos encontrar en el proceso de gestión de cambios
son:

 Gestión de activos y configuraciones deficiente o no implementada.

 Proceso demasiado burocrático.

 Intentos de eludir el proceso de gestión de cambios.

 PIR no realizada al final de una implementación.

 Perímetro demasiado importante para los recursos disponibles.

 Procedimientos de vuelta atrás ausentes o deficientes.

 Falta de apoyo por parte de la dirección de la organización.

Gestión de las entradas en producción

1. Enfoque
En esta sección vamos a ver cómo se gestionan las entradas en producción de los cambios.

Veremos que la eficacia de este proceso es muy dependiente de las acciones realizadas por
la gestión de cambios.

En términos de gestión de proceso, la gestión de las entradas en producción se podría

considerar como un subproceso de la gestión de cambios, ya que se inicia por la gestión de
cambios y se vuelve hacia la gestión de cambios al final del proceso.

2. ¿Por qué una gestión de las entradas en producción?

Hemos visto en la sección anterior el tratamiento de las peticiones de cambios (RFC).

Para dar una respuesta satisfactoria a la gestión de cambios, es imprescindible tener una
estrategia de entradas en producción rigurosa.

Esto permite efectuar los cambios que garantizan la protección del entorno de producción.

Todos los aspectos, ya sean técnicos o no, se deben tener en cuenta para una gestión
eficiente de las entradas en producción.
 Para asegurar una gestión eficaz de las entradas en producción, es imprescindible disponer
de información completa y precisa de la infraestructura del sistema de información y del
conjunto de sus componentes. La gestión de activos y configuraciones, que hemos visto
anteriormente, tiene el papel de proporcionar esta información.

La puesta en marcha de la gestión de las entradas en producción debe permitir proteger el

entorno de producción contra cualquier daño debido a entradas en producción no
autorizadas o a pruebas realizadas directamente en el entorno de producción.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión de las entradas en producción son los
siguientes:

 Definir las políticas de entrada en producción.

 Diseñar y aplicar procedimientos eficaces para los despliegues.

 Asegurar que todos los despliegues se pueden trazar, instalar, probar, verificar y,
eventualmente, volver atrás o desinstalar.

 Planificación de los contenidos exactos de las actualizaciones y de los planes de

desarrollo (coordinación con la gestión de cambios).

 Verificación 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 garantía recogidos en el SLA.

 Gestión 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 organización

formación suficiente (particularmente al centro de servicios).

 Supervisar y controlar los despliegues de software y hardware (y de su

documentación) 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).

4. Definiciones
ELS (Early Life Support): es un soporte específico que se debe aplicar en el momento de la
entrada en producción de nuevos productos, en particular en el momento de la
modificación o modificaciones de versión de software o de aplicaciones.

Plan de vuelta atrás: plan que permite volver a la situación anterior en caso de que el
despliegue de los cambios no sea satisfactorio.

Big Bang: modo de implementación de un cambio.

 FSC (Forward Scheduled Change): calendario de cambios que contiene los detalles de
todos los cambios de infraestructura aprobados para su implantación, con sus fechas
propuestas de implantación.

PSA (Projected Service Availability): disponibilidad proyectada de servicios, calendario que

prevé los periodos de inactividad de los servicios.

PIR (Post Implementation Review): revisión posterior a la implantación que verifica que el
cambio cumple sus objetivos, que los clientes están satisfechos y que no hay consecuencias
negativas.

5. Perímetro
La gestión de las entradas en producción es responsable de:

 El diseño de las entradas en producción.

 La validación del hardware y software.

 La planificación de las entradas en producción.

 La puesta en marcha del ELS.

Esto incluye todos los componentes de las configuraciones necesarias para implementar
una entrada en producción, como:

 Activos de servicio físicos (servidor o redes).

 Activos de servicio virtuales (servidor o memoria).

 Aplicaciones y software.

 Formación para los usuarios y el personal de TI.

 Los servicios (incluyendo los contratos y acuerdos de servicio).

6. Roles
Los principales roles son los siguientes:

 Responsable de las entradas en producción.

 Responsable de cambios.

 Propietario del proceso.

7. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Número de entradas en producción, principales y de poca importancia.

 Número de entradas en producción implementadas con éxito.

 Número de entradas en producción que generaron incidencias.

  Número de entradas en producción que generaron problemas.

 Número de marchas atrás.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se ponga en marcha.

8. Descripción del proceso

El proceso de gestión de las entradas en producción

9. Conceptos básicos
a. El ciclo de vida de una entrada en producción
El ciclo de vida de una entrada en producción se puede definir por seis actividades
principales, que se detallan a continuación:
 El ciclo de vida de un cambio

b. Los diferentes tipos y modos de entrada en producción

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 reducción de riesgos de bloqueo generalizado en caso de dificultad.
Desafortunadamente, esta opción resulta a menudo más costosa, ya que es
necesario modificar los recursos técnicos 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 producción. 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 atrás. 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 agrupación (Package): la tendencia en la mayoría 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 atención, sin embargo, a no crear una
entrada en producción empaquetada, que contenga demasiados cambios; existiría el
riesgo de tener que hacer una marcha atrás sobre demasiados elementos.

Modo de despliegue
Por otro lado, el despliegue se puede lograr de varias maneras, en función 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 operación.
 Fase

En este caso, en función del número de personas o ubicaciones implicadas y si es posible,

el despliegue se realiza en varias operaciones planificadas, ubicación por ubicación, servicio
por servicio, o cliente por cliente.

Modo «Push & Pull»

En este caso, la emisión de las entradas en producción se realiza de manera electrónica. En

modo «Push», se fuerza la instalación sobre un conjunto de puestos; en modo «Pull», es el
usuario el encargado de hacer la actualización sobre su puesto. Pueden aparecer problemas
en la utilización 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 eléctrico, lo que implica que algunos usuarios podrían utilizar una
versión 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 producción de los cambios se puede realizar de manera manual o

automatizada, en función de las herramientas disponibles en la organización.

c. Las cuatro fases de la entrada en producción

1. Planificación de la entrada en producción

En esta fase, hay que preparar una planificación para la construcción y despliegue de la
entrada en producción. Esta fase comienza con la autorización de la gestión del cambio
para la planificación de una entrada en producción y termina con la autorización de la
gestión del cambio para la creación de la entrada en producción.

2. Construcción y pruebas

La entrada en producción se construye, prueba y controla en la DML (Definitive Media

Library). Esta fase comienza con la autorización de la gestión del cambio para la creación
de la entrada en producción y termina con la autorización de la gestión del cambio para el
control de una base de referencia en la DML, a través del proceso de gestión de
configuraciones (SACM). Esta fase es única para cada entrada en producción.

3. Despliegue

El paquete de entrada en producción que está en la DML se despliega en el entorno de

producción.

Esta fase comienza con la autorización de la gestión del cambio para el despliegue. Incluye
la creación de una base de referencia en la DML, por el proceso de gestión de
configuraciones (SACM). Esta fase es única para cada entrada en producción.

Esta fase termina con el soporte por la fase operación del ciclo de vida y el inicio del ELS
(Early Life Support).

La fase de despliegue puede ser un proceso recurrente en función de la opción de

despliegue seleccionado.
 4. Revisión del despliegue y cierre

Se debe aprender de la experiencia; se deben analizar los objetivos de rendimiento y

realización para determinar los ejes de mejora.

d. Las actividades de gestión de la puesta en producción

El responsable de la gestión de las entradas en producción debe definir una estrategia para
aclarar los roles y responsabilidades de cada uno. Esta estrategia se debe concretar en un
documento.

La política de entradas en producción se debe revisar después de cada cambio principal de

la infraestructura técnica.

Las principales actividades de la gestión de las entradas en producción son las siguientes.

Diseño
Es imprescindible diseñar los procedimientos para la entrada en producción de los cambios.

En esta actividad, es necesario:

 Definir los modelos de entrada en producción.

 Definir el plan de pruebas.

 Definir el plan de puesta en marcha.

 Preparar los procedimientos documentados.

Construcción y preparación
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 documentación está disponible y que se ha

definido y puesto en práctica correctamente un plan de formación.

Evaluación
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 aceptación formal del cliente y del usuario sobre la
futura entrada en producción.

Estas pruebas deben incluir pruebas funcionales, operativas, de rendimiento y de

integración.

Se deben realizar de manera unitaria y de manera global, en un entorno lo más parecido

posible al entorno de producción.

Planificación
 La planificación de cambios se debe realizar teniendo en cuenta el calendario de cambios
(FSC), así como las disponibilidades proyectadas de servicios (PSA).

La planificación implica obtener un consenso sobre el contenido de la puesta en producción,

la planificación de los recursos, la planificación de la aceptación de los grupos de soporte y
del cliente y la producción del plan de vuelta atrás.

Comunicación y formación
La comunicación con los clientes, los usuarios y el personal del centro de servicios es
imprescindible. Cada uno debe saber cómo se va a producir la entrada en producción de los
cambios y conocer los impactos de la operación.

En caso de que el cambio implique que se debe impartir una formación, ya sea a los
usuarios, al personal del centro de servicios o a los dos, la formación se deberá llevar a
cabo antes de la entrada en producción.

Algunos cambios, fundamentalmente en caso de una nueva versión de software o una

nueva aplicación, necesitan aplicar una célula de soporte (Early Life Support) para asistir al
personal del centro de servicios durante un cierto tiempo.

La puesta en marcha del ELS también se debe preparar para que esté operativo después de
la instalación de los cambios.

El personal que ha contribuido al desarrollo del servicio también puede estar integrado en
el soporte ELS.

Esto mejorará la transmisión del conocimiento a los técnicos del centro de servicios, lo que
también puede mejorar la calidad de las relaciones entre los diferentes equipos.

Distribución e instalación
La instalación del cambio se debe realizar utilizando uno de los tipos y modos de
despliegue, enumerados en el capítulo anterior.

La CMS se debe actualizar con motivo de la entrada en producción, la copia de versiones en

la DML o el almacenamiento del hardware en la DSH, la actualización de todos los CI
implicados.

Se deben registrar todos los fallos encontrados durante la instalación para la redacción del
PIR.

10. Beneficios y dificultades

a. Beneficios
La gestión de las entradas en producción permite desplegar el cambio asegurando que los
cambios que se han puesto en marcha no afectarán a la calidad de los servicios
proporcionados por la organización ni a los niveles de servicio contractuales.

Entre los beneficios que aporta la gestión de cambios, podemos enumerar:

 Entornos de producción y de pruebas estables.

 Reducción del impacto negativo del cambio sobre la calidad de los servicios
proporcionados por la organización.

 Respeto de los acuerdos definidos en los SLA.

  Gestión de la disponibilidad y gestión de la continuidad mejoradas, al tener en cuenta
elFSC para realizar el despliegue.

 Baja probabilidad de encontrar copias ilegales de software en la organización.

 Mejora de la productividad de los equipos de la organización TI, ya que las acciones

están planificadas.

 Mejora de la productividad de los usuarios, ya que hay menos interrupciones del

servicio no programadas.

b. Dificultades potenciales
Las dificultades que pueden entorpecer el proceso de gestión de las entradas en producción
son:

 Resistencia al cambio de los equipos acostumbrados a realizar las entradas en

producción individualmente.

 Intentos para evitar los procedimientos de aplicación.

 Responsabilidades mal definidas.

 Gestión de activos y configuraciones errónea o no implementada.

 Perímetro demasiado importante para los recursos disponibles.

 Procedimientos de vuelta atrás ausentes o erróneos.

Gestión 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 través de las
fases de diseño y entrada en producción, correspondiente a las necesidades y al uso
esperado.

2. ¿Por qué una gestión de las validaciones y las pruebas?

La validación y las pruebas son un dominio esencial de la gestión 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 aplicación.

 Problemas y errores difíciles de diagnosticar.

 Costes adicionales, ya que puede ser más costoso reparar un error en un entorno de
producción que en un entorno de pruebas.
  Uso del servicio que no corresponde a los requerimientos del negocio.

3. Objetivos del proceso

Los objetivos principales del proceso de gestión 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 garantía correctamente (garantía).

 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 planificación e implementación que pruebe que el

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

4. Perímetro del proceso

El proveedor de servicios asume la responsabilidad del suministro de la prestación 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

prestación a lo largo del ciclo de vida del servicio, lo que implica disponer de los recursos y
capacidades necesarias.

Los resultados de este proceso servirán al proceso de gestión de los cambios para activar, o
no, el proceso de despliegue.
5. Descripción del proceso

El proceso de gestión de validaciones y pruebas

6. Conceptos básicos
a. Enfoques y técnicas de pruebas
Existen numerosos enfoques que se pueden combinar para hacer la validación y las
pruebas, según las restricciones del entorno de pruebas y del futuro entorno de producción.

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 continuación se enumeran algunos ejemplos:

 Enfoque basado en el riesgo.

 Enfoque de conformidad con los estándares o las normas.

 Enfoque basado en la experiencia.

 Enfoque basado en los métodos del ciclo de vida del desarrollo de software y
simulación.

 Escenario de pruebas.
  Prototipado.

 Pruebas de laboratorio.

 Pruebas de no regresión.

 Ejecución de proyectos piloto.

Para optimizar los recursos de prueba, las actividades de prueba se deben definir y asignar
en función de la importancia del servicio, del impacto potencial sobre las operaciones
previstas y del nivel de riesgos.

Los análisis del impacto sobre el negocio se deben hacer durante la fase de diseño,
particularmente en los procesos de gestión de la capacidad, disponibilidad y continuidad de
servicios.

Gestión de la evaluación 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 través de las
fases de diseño y entrada en producción, que corresponde a las necesidades y uso
esperado.

2. ¿Por qué una gestión de la evaluación de los cambios?

La gestión de los cambios necesita los resultados de la gestión de evaluación 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 decisión para la gestión de los cambios.

3. Objetivos del proceso

Los objetivos principales del proceso de evaluación de los cambios son:

 Definir correctamente el resultado esperado por las partes implicadas y suministrar

información de gestión precisa y eficaz.

 Evaluar los objetivos de un cambio, pero también 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 permitirán a la gestión de los cambios

decidir desplegar o no un cambio.

4. Perímetro del proceso

Este proceso se aplica a todos los cambios sometidos al proceso de gestión de los cambios.
5. Descripción del proceso

El proceso de gestión de las evaluaciones

6. Conceptos básicos
Todos los cambios se deben evaluar, pero solo los cambios significativos lo deben ser en el
marco del proceso de evaluación.

Los criterios de evaluación se deben definir para poder determinar cuáles son los cambios
implicados por este proceso.

Esta evaluación 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 aplicación de modelos.

Por supuesto, se debe documentar la decisión que se tome.

a. Desarrollo de las actividades del proceso

El desarrollo de las actividades del proceso de evaluación

Gestión del conocimiento

1. Enfoque
En esta sección, vamos a ver cómo 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 también del exterior (fabricantes de software, proveedores externos...).

2. ¿Por qué una gestión del conocimiento?

La capacidad para suministrar un servicio de calidad se basa en un buen conocimiento del
entorno de suministro del servicio, pero también en el entorno exterior y en la capacidad
de reaccionar en función de las circunstancias.

Para esto, los colaboradores de los departamentos de TI deben poder encontrar

información en las diferentes bases de información de la empresa.

Este conocimiento debe incluir la identificación de los participantes y los riesgos.

3. Objetivos del proceso
Los objetivos principales del proceso de gestión del conocimiento son los siguientes:

 Mejorar la calidad de la gestión decisional, asegurando que la información esté

disponible y sea segura, a través del ciclo de vida de los servicios.

 Hacer que el proveedor de servicios sea más eficiente y mejorar la calidad del
servicio.

 Mejorar la satisfacción del cliente.

 Reducir los costes del servicio, reduciendo la necesidad de redescubrir el

conocimiento.

 Asegurar que la gestión tiene una comprensión clara del valor del servicio
suministrado al cliente.

 Poner en marcha y mantener un sistema de gestión del conocimiento (SKMS).

 Recolectar, analizar, almacenar, compartir, usar y mantener el conocimiento, la

información y los datos a través de la organización.

4. Perímetro
La gestión del conocimiento se aplica al conjunto de actividades de la gestión de los
departamentos de TI, a través de las diferentes fases del ciclo de vida de los servicios.

5. Descripción del proceso y de las principales relaciones

La gestión del conocimiento

6. Conceptos básicos
Es obligatoria una política de gestión del conocimiento para guiar al equipo directivo, en
términos de comportamiento y compromiso, con objeto de hacer más efectivo y eficiente
este proceso.

Esta política será diferente en función de la cultura de la empresa.

Sin embargo, tiene que incluir:

  El conocimiento y la información necesarias para el soporte de los servicios.

 Todo el conocimiento y la información se deben crear, revisar, aprobar, mantener,

controlar y hacerlos disponibles siguiendo un proceso formal y documentado.

 Todas las políticas, planes y procesos se deben revisar, al menos, una vez al año.

a. SKMS
La base de datos de conocimientos se llama SKMS (Service Knowledge Management
System).

Esta base de datos contiene las bases de datos específicas de cada proceso.

Por ejemplo, la base de datos de la gestión de configuraciones (CMDB) se incluye en el

sistema de gestión 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 representación de la estructura del conocimiento. A continuación

explicamos el significado de este acrónimo.
 En primer lugar, partimos de datos sin tratar (la «D» del modelo).

Cuando estos datos se estructuran (qué, quién, cuándo y dónde), pasamos a la «I» del
modelo, ya que los datos se han transformado en «Información».

La siguiente etapa va a responder al «Cómo». En esta etapa, podemos hablar de

«Conocimiento».

La última etapa se llama de la «Sabiduría», ya que en este momento sabemos cómo usar el
conocimiento y, por tanto, crear valor.

LOS PROCESOS DE LA EXPLOTACION DE SERVICIOS

La fase de explotación de servicios
1. ¿Por qué una explotación de los servicios?
Como hemos visto en el capítulo de presentación de la norma, ITIL se descompone en
procesos estratégicos, tácticos y operativos.

Los niveles decisionales de la fase Operaciones

Los procesos de explotación de los servicios se sitúan en la parte correspondiente a los

niveles «operativos».

La explotación de los servicios se basa en las funciones y procesos.

En esta primera parte, no veremos los procesos «transición de servicios», a pesar de que
se identifican tanto en la parte «táctica» como en la parte «operativa». Se tratarán en la
parte «transición de los servicios».
2. Los objetivos de la explotación de servicios
Al contrario de lo que sugieren algunas ideas preconcebidas, la explotación 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 explotación 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 tecnológico, la explotación de los servicios es responsable del co- rrecto

funcionamiento de los diferentes elementos que forman la infraestructura informática, que
soporta los servicios y la ejecución de las actividades de control, para gestionar y entregar
los servicios.

En el ámbito del negocio global, la explotación 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. También debe asegurar el mantenimiento del nivel de satisfacción de
los usuarios.

3. Los procesos de explotación de los servicios

 La gestión de eventos.

 La gestión de incidencias.

 La gestión de problemas.

 El tratamiento de consultas.

 La gestión de accesos.

4. Las funciones de explosión de servicios

La fase explotación de servicios se compone, además de los procesos mencionados
anteriormente, de cuatro funciones:

 El centro de servicios.

 La gestión de operaciones.

 La gestión técnica.

 La gestión de aplicaciones.

a. La definición de una función

Una función 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 organización debe aplicar y gestionar una estructura de equipos, grupos o funciones.

La definición 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 ubicación de las funciones

Ubicación de las funciones y relaciones

Funciones
1. Función de gestión de operaciones
a. Descripción de la función

La función de gestión de operaciones

b. Conceptos básicos
La gestión de operaciones está formada por dos partes:

 El control de las operaciones: gestión del conjunto de actividades diarias para

suministrar el servicio.

 Los medios generales (Facilities Management): gestión del entorno físico y de los
contratos con los proveedores externos.

2. Función de gestión de aplicaciones

Esta función es responsable de la gestión de las aplicaciones a través de su ciclo de vida.

Tiene relación con la gestión de las operaciones y el centro de servicios.

Véase el esquema de la sección La ubicación de las funciones.

3. Función de gestión técnica

Esta función suministra las competencias y los recursos técnicos para las operaciones.
 Tiene un papel importante en el diseño, transición (pruebas y despliegue) y operaciones
(soporte).

Tiene relación con la gestión de operaciones y el centro de servicios.

Véase el esquema de la sección La ubicación 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 capítulos siguientes:

 Definición de la estrategia de negocios: capítulo Los procesos de la estrategia de

servicios - Generación de la estrategia.

 Preparar la puesta en marcha de un CMS inicial: capítulo Los procesos de la

transición de servicios - Gestión de los activos de servicio y configuraciones.

 Preparar la puesta en marcha de contratos de servicios básicos: capítulo Los

procesos del diseño de servicios - Gestión de los niveles de servicio.

 Preparar la gestión de los cambios: capítulo Los procesos de la transición de servicios

- Gestión de cambios.

2. Requisitos previos
Antes de establecer el centro de servicios, se deben iniciar los siguientes procesos, aunque
no necesariamente finalizarlos:

 Gestión de la estrategia.

 Gestión del porfolio de servicios.

 Gestión de los activos y configuraciones.

 Gestión de los niveles de servicios

 Gestión de cambios

 Gestión de incidencias.

 Gestión de problemas (fundamentalmente, gestión 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 ubicación
en la que está instalado.

Centro de servicios local

Este tipo de centro es práctico mientras la empresa no tenga demasiadas ubicaciones; en

caso contrario, esto implica una multiplicación de las competencias y los recursos para cada
ubicación.

Inconvenientes
En este tipo de organización, no hay capitalización posible entre los empleados presentes
en las dos ubicaciones.

Tampoco es posible que una ubicación absorba una sobrecarga puntual de otra segunda
ubicación. Esta sobrecarga se podría deber a una incidencia técnica, una ausencia no
planificada de un técnico o a cualquier otro motivo.

5. Centro de servicios centralizado

El centro de servicios está implantado en una ubicación 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 reducción de los
costes operativos y contribuye a mejorar la visibilidad del conjunto de la gestión.
 Centro de servicios centralizado

La noción de SPOC sigue siendo válida 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 países o continentes. Sin embargo, los usuarios solo ven el centro de servicios
virtual.

El funcionamiento de estos centros se basa en el uso de tecnologías de telecomunicaciones

de mayor rendimiento y el uso de redes de banda ancha.

Los centros se pueden establecer en función 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 reducción de los costes operativos y contribuye a mejorar la
visibilidad del conjunto de la gestión.

La noción de SPOC sigue siendo válida 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 noción de desfases horarios.

El centro de servicios se implanta en diferentes ubicaciones, que pueden estar repartidas

en uno o varios países o continentes. De esta manera, algunas veces se utiliza el término
de centro de servicios «Follow the sun», para recordar que el acceso al centro de servicios
es posible durante las 24 horas del día.

Sin embargo, los usuarios solo ven el centro de servicios virtual.

El funcionamiento de estos centros se basa en el uso de tecnologías de telecomunicaciones

de mayor rendimiento y el uso de redes de banda ancha.

Los centros se pueden establecer en función 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 explotación es menor.

Centro de servicios «Follow the Sun»

8. Externalizar el centro de servicios

a. ¿Por qué externalizar el centro de servicios?
Hoy en día, un número importante de empresas han elegido externalizar su centro de
servicios.

Esta solución responde, en general, a una estrategia de externalización total o parcial de la

actividad informática.

Una ventaja importante de esta solución es que la empresa subcontratada está obligada a
obtener resultados. Esta obligación de resultados se debe trasladar correctamente al
contrato de externalización del servicio, contrato de tipo UC (ver capítulo Los procesos del
diseño de los servicios - Gestión de los niveles de servicio).

Este tipo de soluciones pueden ser interesantes para pequeñas o medianas estructuras, ya
que las inversiones, tanto en hardware como en software, relativas a las herramientas de
gestión de incidencias y problemas se pueden agrupar a nivel de subcontratación.

Además, esta solución también permite resolver un problema interno de competencias

informáticas.

b. Los riesgos de la externalización

La elección de la externalización de un centro de servicios es una decisión particularmente
importante para la empresa.

En efecto, en el marco de una externalización, la empresa acepta confiar a otra empresa el

cuidado de la gestión de una parte de su informática y, por tanto, de una parte de sus
competencias.
 Esto es importante, ya que las competencias de las personas de la organización TI forman
parte de los activos de la empresa (ver el capítulo Los procesos de la transición de los
servicios - Gestión de los activos de servicios y configuraciones, para la definición del
término «Activo»).

Por lo tanto, esta decisión implica la aceptación por parte de la empresa de la pérdida de
parte de sus activos, al menos temporalmente.

Por otra parte, la empresa debe tener en cuenta que esta decisión se puede modificar en
cualquier momento.

Por lo tanto, será necesario prever en el contrato con el proveedor una cláusula de marcha
atrás, también llamada cláusula de reversibilidad.

En esta cláusula, el proveedor se debe comprometer a transmitir a la empresa el conjunto

del conocimiento desarrollado y, si es necesario, las herramientas específicas desarrolladas
para asegurar el servicio durante el periodo en el que el servicio ha estado bajo su
responsabilidad.

Durante esta prestación, la empresa se debe asegurar de que el proveedor respeta este
compromiso y que pone en marcha los medios necesarios que permitan esta vuelta atrás.

9. El funcionamiento del centro de servicios

a. Registro de la información por el centro de servicios, noción de ticket
Una de las obligaciones del centro de servicios es registrar el conjunto de información que
le ha sido transmitida, tanto por parte de los clientes/usuarios como por el hardware o el
software.

Para registrar esta información, el centro de servicios va a utilizar un software de

tratamiento de llamadas.

La creación 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
comunicación con el cliente o usuario.

Se debe proporcionar este identificador a la persona que está en el origen de su creación.

Existen diferentes tipos de ticket:

 Incidencia

 Problema

 Petición de servicio

 Petición de información

 Alerta (recuperada por el hardware o el software)

b. Los medios técnicos 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.
 Atención: el programa de certificación 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 más
fiable las mejores prácticas de ITIL.

El término «Compliant ITIL» no es en absoluto una garantía 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; ¿cómo se gestiona en este caso la noción 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
informático (incidencia, problema y petición de servicio), o de la generación de un evento
por parte del hardware o el software.

Especialmente, la herramienta de gestión de las llamadas debe permitir la definición de la

prioridad de la llamada, en función de los criterios establecidos en el contrato de servicio
(urgencia e impacto).

También debe permitir hacer el seguimiento del tiempo transcurrido con el objetivo de
respetar los plazos de tratamiento definidos en el contrato de servicio en función de la
prioridad.

Esta herramienta debe proporcionar la posibilidad de elaboración de estadísticas.

c. Los medios humanos del centro de servicios

El centro de servicios es el punto de centralización de los equipos técnicos 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 función del tamaño de la

empresa.

Atención: en ITIL, el centro de servicios se ve como una «función». Los empleados del
centro pueden tener un rol en los procesos de incidente o problema.

d. La comunicación 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 informático; no
olvide que los clientes del servicio informático pueden ser personas internas de la empresa,
aunque también clientes de la empresa, si proporciona a sus clientes los medios
informáticos.

El centro de servicios también es un escaparate de los servicios informáticos.

 Por este motivo, la comunicación se debe definir claramente y adaptar al entorno de la
empresa.

Por lo tanto, es importante preparar correctamente la comunicación del centro de

servicios.

El responsable del centro de servicios debe definir una política real de marketing de los
servicios ofrecidos por el centro. Esto es importante, ya que la comunicación se deberá
realizar en la fase inicial de la puesta en marcha, pero también de manera regular
posteriormente.

La apertura de un centro de servicios debe estar marcada por una importante comunicación
hacia los clientes y usuarios, así como hacia el conjunto del personal de la organización.

En esta comunicación, la oferta de servicios debe ser clara, precisa y comprensible para
todos los futuros usuarios.

Se pueden utilizar varios canales:

 Envío por buzoneo (en papel o electrónico).

 Envío de un documento de ayuda (en papel).

 Envío de un objeto que permita la memorización del número de llamada o una

dirección de correo electrónico.

 Dirección de correo de la Dirección General...

e. Comunicación del estado de los tickets creados por los clientes o usuarios
Los clientes o usuarios pueden presentar sus peticiones por diferentes medios, según las
tecnologías que se hayan puesto en marcha en el centro de servicios.

Estas tecnologías pueden permitir:

 Una llamada telefónica.

 Un fax.

 Un correo electrónico.

 Una entrada directa de la petición 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 categoría de la comunicación necesaria para la satisfacción 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 comunicación 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 también se debe comunicar con los otros procesos que se han puesto
en marcha en la empresa.

10. Beneficios y dificultades

a. Beneficios
La puesta en marcha de un centro de servicios permite hacer un seguimiento mejor de las
incidencias informáticas.

También permite mejorar el rendimiento del conjunto de los empleados de la empresa, ya

que les da una respuesta rápida y, por tanto, limita el tiempo perdido a causa de las
incidencias informáticas.

b. Dificultades potenciales
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 comunicación.

Si no establece un sistema de comunicación sólido, con el apoyo de la dirección de la

empresa y de la organización TI, no obtendrá la adhesión de los usuarios.

La segunda dificultad es la identificación de los futuros técnicos y su formación.

Estas son, sin duda, las dificultades más frecuentes.

Procesos
La explotación de servicios está formada por cinco procesos. Los más importantes son la
gestión de incidencias y la gestión de problemas.

Los otros tres procesos son la gestión de eventos, de consultas y de accesos.

Estos cinco procesos se detallan a continuación.

Gestión de eventos
1. Enfoque
En esta sección, vamos a ver cómo se gestionan los eventos en la explotación de servicios.

En la sección anterior hemos visto la aplicación del centro de servicios.

Un evento se puede considerar como un cambio de estado, que tiene un sentido para un
elemento de configuración (CI) o para un servicio.

La eficacia de un servicio depende del conocimiento de la infraestructura y la capacidad

para identificar una desviación con respecto a una situación normal o esperada.

Esto es posible con una cuidadosa supervisión y un sistema de control basado en dos tipos
de herramientas, supervisión activa y supervisión pasiva.
2. Objetivo del proceso
El objetivo principal del proceso de gestión de eventos es identificar los eventos, darles un
sentido y determinar las acciones más importantes.

Los objetivos de la gestión de eventos son los siguientes:

 Detectar cualquier cambio de estado que tenga algún sentido para un elemento de
configuración (CI) o para un servicio.

 Determinar las acciones de control para los eventos y asegurar la comunicación con
las funciones adecuadas.

 Suministrar un punto de entrada para la ejecución 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 diseño y al contenido de los acuerdos de
servicios SLA.

 Suministrar una base para crear informes.

3. Perímetro
El perímetro de la gestión de eventos se aplica a todas las actividades de la gestión de
servicios que necesitan un control automatizado. Esto incluye la gestión de los CI y el
entorno físico, la gestión de licencias, la seguridad y las operaciones diarias.

4. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Número de eventos de tipo alerta.

 Número de eventos de tipo excepción.

 Número de eventos de tipo entorno.

Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura

que se ponga en marcha.
5. Descripción del proceso

El proceso de gestión de eventos

6. Conceptos básicos
a. Diferentes tipos de evento
Existen tres tipos de eventos:

 Evento de tipo información.

 Evento de tipo alerta.

 Evento de tipo excepción.

Evento de tipo información

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

Por ejemplo: un usuario que se conecte a una aplicación 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 gestión de eventos o en los SLA u OLA.

Este tipo de evento necesita, de manera regular, la intervención 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 transacción superior al 10% del tiempo definido.

Evento de tipo excepción

Estos son los eventos relacionados con una situación excepcional.

Por ejemplo: un umbral de uso del espacio en disco superior al 90%, una transacción no
terminada o un intento de conexión a una aplicación con un usuario o una contraseña
incorrectos.

Gestión de las incidencias

1. Enfoque
En esta sección vamos a ver cómo se gestionan las incidencias en el seno del centro de
servicios.

En la sección 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, después de la puesta en marcha de un centro de
servicios, ya que esto permite iniciar progresivamente la estrategia ITIL.

También veremos cómo 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 gestión de incidencias?

Independientemente de cuál sea la calidad de los servicios proporcionados por la
organización 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 haría necesario realizar pruebas en un entorno idéntico al de la explotación, 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 gestión de incidencias, el usuario, en caso de un funcionamiento incorrecto

de su puesto de trabajo o de la aplicación que utiliza, tenderá a molestar a sus compañeros
 para resolver este funcionamiento incorrecto. Esto tendrá un impacto sobre la actividad de
la persona, pero también de sus compañeros. Si, a pesar de la ayuda de sus compañeros,
el usuario no soluciona el funcionamiento incorrecto, contactará con los técnicos. La
interrupción de un técnico en su trabajo también tendrá un impacto sobre su efectividad.

Además, como no hay ningún registro del funcionamiento incorrecto ni sobre las causas o
solución propuesta, no puede haber capitalización sobre esta intervención.

Finalmente, como no hay un seguimiento, será imposible determinar la criticidad de una

incidencia aislada, pero que podría evolucionar y convertirse en una crisis más o menos
grave.

Sin embargo, si se ha puesto en marcha una gestión de incidencias, se pueden identificar

varios puntos positivos:

 Reactividad: el usuario puede acceder rápidamente a un técnico que le proporcione

asistencia. Menos pérdida de tiempo para el usuario y también para sus compañeros,
a los que no molestará más.

 Eficacia de un técnico: ya no se le molesta durante una actividad planificada.

 Capitalización del saber: si se registra una incidencia, en caso de que vuelva a

parecer una incidencia del mismo tipo, el conjunto de técnicos del servicio sabrán lo
que conviene hacer, lo que ahorra tiempo en el tratamiento de las incidencias y
minimiza la pérdida de tiempo por parte del usuario.

 Prevención: será posible identificar correctamente una incidencia menor antes de que
se convierta en crítica, con el riesgo de que esto provoque una situación de crisis.

Atención: el personal deberá tener la formación necesaria para poder realizar una misión
de soporte telefónico. No es suficiente con ser un excelente técnico para poder hacerse
cargo de una llamada telefónica de un usuario. Es imprescindible que el personal que trata
las incidencias, además de sus competencias técnicas, tenga capacidad de relación y sepa
mostrar empatía durante el tratamiento de una llamada. La selección y formación del
personal será, por lo tanto, muy importante.

3. Objetivo del proceso

El objetivo principal del proceso de gestión de incidencias es:

«Restaurar un servicio operativo tan rápido 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 límites acordados de servicio (SLA).

También hay que tener en cuenta otros objetivos:

 Asegurar que se usan los métodos estandarizados y los procedimientos, para

garantizar una respuesta rápida y eficaz.

 Aumentar la visibilidad de las incidencias y comunicación entre el negocio y la

organización de los TO.
  Mantener la satisfacción del cliente en relación con la calidad de los servicios de TI.

4. Definiciones
La definición de incidencia es la siguiente:

«Todo evento operativo que no forma parte de las operaciones estándares de un sistema,
que provoca o pueda provocar una interrupción del servicio o una alteración de su calidad».

La definición de evento es la siguiente:

«Un cambio de estado que tiene un significado para la gestión de un componente de

configuración (CI) de un servicio informático».

La definición 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 definición de petición de servicio es la siguiente:

«Una petición por parte de un usuario de información, un consejo para un cambio estándar
o para el acceso a un servicio informático, por ejemplo, restaurar una contraseña o
proporcionar un servicio informático estándar para un nuevo usuario».

5. Perímetro
La gestión de incidencias trata las incidencias reportadas por:

 Los usuarios (por medio del centro de servicios).

 El personal técnico.

 La supervisión técnica.

Algunos ejemplos de incidencias:

 A nivel de hardware:

 Puesto de trabajo averiado.

 Impresora no operativa.

 Recurso no disponible o inaccesible.

 Alerta o excepción generada automáticamente por un componente del sistema.

 A nivel de aplicación:

 Servicio no disponible.

 Funcionamiento incorrecto de la aplicación.

 Pregunta sobre la utilización del servicio.

6. Roles y función
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.

 El propietario del proceso.

En cuanto a la función, hallamos la de gestor del centro de servicios.

7. Indicadores
Se pueden establecer varios indicadores para medir el funcionamiento del proceso:

 Número de incidencias creadas.

 Número de incidencias resueltas en el primer contacto.

 Duración media del tratamiento de una incidencia.

 Número de incidencias tratadas sin contar los retrasos de las SLA.

 Número de incidencias escaladas.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se ponga en marcha.
8. Descripción del proceso

El proceso de gestión de incidencias

9. Conceptos básicos
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 gestión de incidencias.

En el ámbito de la gestión de incidencias, también 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 gestión que se ha puesto en marcha en el centro de servicios.

Se deben registrar todas las incidencias, sin excepción. 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 técnico debe identificar al solicitante.

Si ya se ha puesto en marcha el proceso de gestión de los activos y configuraciones

(SACM), será posible encontrar sus datos en la herramienta de gestión de incidencias, a
partir de su nombre o de su identificador. Sin embargo, el técnico deberá validar con el
usuario la exactitud de la información.

En caso contrario, corresponderá al técnico registrar el conjunto de datos del usuario.

c. Clasificación
Esta es, sin duda, la etapa más importante en la gestión de incidencias.

La categorización
Permite determinar cuál es el hardware, servicio o personas implicadas en la incidencia y el
nivel de prioridad que le ha sido asignado.

El técnico será capaz de categorizar la incidencia por medio del interrogatorio al usuario.

Atención: el usuario describe, en general, los síntomas que ha identificado, pero estas no
son obligatoriamente las causas de la incidencia. Por lo tanto, es posible que la
categorización evolucione durante el tratamiento de la incidencia.

La categorización nos va a ayudar a identificar cuál es el SLA que se debe tener en cuenta
para definir la prioridad de la incidencia.

Esta categorización va a permitir identificar el grupo de soporte al que se debe dirigir la

llamada, en la medida en que el técnico no sea capaz de tratarla él mismo.

Durante esta etapa, el técnico identificará, si es posible, el elemento de configuración

(Configuration Item - CI) implicado.

Durante esta etapa, el técnico identificará si la petición es de servicio. En este caso, la

petición 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 técnico necesite consultar la base de
problemas y errores conocidos.

Si se identifican los elementos comunes, se podrá poner en práctica rápidamente la

solución definitiva o una temporal.

En caso contrario, implicará búsqueda y diagnóstico por el grupo de soporte que se

encargará de la incidencia.

La priorización
La priorización se lleva a cabo basándose en dos parámetros:

 El impacto.

 La urgencia.
Estos parámetros se deben definir en el contrato de servicios (Service Level Agreement -
SLA).

En función de estos dos parámetros, se puede definir una tabla de asignación de

prioridades.

La combinación de estos dos parámetros va a permitir definir la prioridad de la incidencia.

Tabla de definición de prioridades

Esta tabla de asignación debe indicar los plazos de resolución previstos.

Esta tabla debe estar a disposición de los técnicos.

Hoy en día, la mayor parte de las herramientas de gestión de llamadas permiten integrar
esta tabla en la configuración 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 técnico no debe faltar a la regla y deberá elevar la protesta a sus
superiores.

El impacto
El impacto de una incidencia se determina en función 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 términos de software, si el funcionamiento incorrecto afecta a una

aplicación administrativa, el impacto no será el mismo que si afecta a una aplicación
empresarial.

El número de usuarios afectados también se tiene en cuenta en la definición del impacto.

Generalmente se definen un mínimo de tres niveles:

 Alto: afecta a un número importante de usuarios o está implicada una aplicación

principal.

 Medio: afecta a un número limitado de usuarios o está implicada una aplicación

estándar.

 Bajo: afecta a un único usuario o a muy pocos o está implicada una aplicación
administrativa.

Los diferentes niveles se deben definir para cada servicio en el ámbito del SLA.

La urgencia
La urgencia también se define en el SLA. Generalmente se establecen un mínimo de tres
niveles:

 Alto: es una aplicación o un equipo crítico.

 Medio: es una aplicación o un equipo no crítico.

 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 parámetros de impacto y urgencia.

Es preciso definir los plazos de restablecimiento del servicio en relación 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 intervención e informar al usuario del plazo de
planificación.

d. Incidencia principal
Más allá de la priorización de una incidencia, existen circunstancias para las que es
necesario tomar medidas particulares. Por ejemplo, en caso de que la red de comunicación
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 más rápido posible, poniendo en práctica los recursos adecuados a una
situación como esta. Esto se puede parecer a lo que se conoce generalmente como una
situación crítica.

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 gestión del escalado

Escalado funcional: es el envío de una incidencia a un nivel de asistencia superior, debido

principalmente a la falta de conocimiento o experiencia de un técnico, o porque ha
transcurrido el plazo de tiempo acordado en el SLA para tratar la incidencia o está próximo
a terminar.
 Generalmente, las herramientas de gestión de incidencias actuales permiten desencadenar
este escalado funcional de manera automática, en función de los plazos previstos en el
SLA.

En este tipo de escalado, las incidencias cambian de propietario.

Escalado jerárquico: enfoque adoptado durante una actividad cuando es probable que la
resolución de una incidencia no se realice a tiempo o no vaya a ser satisfactoria. Los
encargados de la gestión deben tomar rápidamente la decisión apropiada.

Este tipo de escalado también se pone en marcha cuando un cliente solicita una
modificación de la prioridad asignada a su incidencia.

En este tipo de procesos de escalado, las incidencias no cambian de propietario.

f. Investigación y diagnóstico
Durante esta fase, el técnico 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 disposición.

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 solución 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 gestión de incidencias: minimizar el impacto
sobre el servicio.

Todas las investigaciones y operaciones llevadas a cabo durante esta fase se deberán
registrar en la herramienta de gestión de incidencias para garantizar su trazabilidad, así
como para permitir un análisis global de las incidencias, que se llevará a cabo en el proceso
de la gestión de problemas.

g. Resolución
La resolución de la incidencia se puede llevar a cabo basándose en una solución aportada
por:

 El centro de servicios.

 Un grupo de soporte.

 La gestión de problemas.

 Un RFC.

La información relativa a las operaciones puestas en práctica para la resolución de la

incidencia se deben registrar en la herramienta de gestión 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 más 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 electrónico, el ticket se
cierra de manera administrativa.

La ausencia de respuesta puede ser consecuencia de varios factores: ausencia de larga

duración, 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 gestión de incidencias.

10. Beneficios y dificultades

a. Beneficios
La gestión de incidencias no debería ser un centro de coste. Es un centro de beneficios para
la empresa.

El coste del centro de servicios y la gestión de incidencias siempre es compensado por las
ganancias en productividad que aporta a la empresa: disminución de la no disponibilidad
del personal, del número de incidencias y gestión proactiva de estas.

b. Dificultades potenciales
La principal dificultad es convencer a todos los usuarios de que utilicen el centro de
servicios y, por lo tanto, la gestión de incidencias.

La segunda es convencer a los técnicos 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á difícil demostrar que el centro de servicios

es un centro que genera beneficios.

Gestión de problemas
1. Enfoque
En esta sección vamos a ver cómo se gestionan los problemas.

En la sección anterior hemos visto la gestión de incidencias.

Como el proceso incidencia, el proceso gestión de problemas es, a menudo, uno de los
primeros en aplicarse, después del centro de servicios y de la gestión de incidencias, ya
que permite iniciar gradualmente la estrategia ITIL.
2. ¿Por qué una gestión de problemas?
El objetivo principal del proceso de gestión de incidencias es restaurar lo más
rápidamente posible un servicio normal y minimizar el impacto sobre las aplicaciones de
negocio.

Este objetivo es el que no permite, en general, que gestión 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.

Atención: habitualmente se habla de «causa desconocida», «causa subyacente

desconocida», «causa inicial» o «causa primera» para definir la causa de un funcionamiento
incorrecto en la prestación de un servicio o de la incidencia. Todos estos términos tienen el
mismo significado y valor.

3. Objetivos del proceso

El objetivo principal del proceso de gestión de problemas es:

«Minimizar el impacto en la empresa durante las incidencias y problemas derivados de

errores en la infraestructura, y prevenir la aparición de incidencias, problemas y errores, de
forma proactiva».

Para ello, el proceso tiene por objetivo identificar la causa raíz del funcionamiento
incorrecto y de las incidencias, mitigar su impacto y encontrar, si es posible, una solución
rápida y definitiva que impida la reproducción de estos funcionamientos incorrectos e
incidencias.

Cuando sea posible, la gestión de problemas puede, en un primer momento, proporcionar

una solución temporal, antes de buscar una solución definitiva.

Esto debería permitir la vuelta al funcionamiento normal del servicio.

El proceso es reactivo y proactivo al mismo tiempo, en función de la actividad implicada.

Se proporcionan explicaciones detalladas en la sección Gestión de problemas - Conceptos

básicos.

Recordatorio: el funcionamiento normal de un servicio se define como un funcionamiento

dentro de los límites acordados del servicio (SLA).

4. Definición
La definición de problema es la siguiente:

«Un problema es la causa subyacente desconocida de una o varias incidencias».

5. Perímetro
La gestión de problemas trata todos los problemas reportados por:

 La gestión de eventos.
  La gestión de incidencias.

La gestión de problemas también debe:

 Llevar a cabo una actividad de seguimiento y control de las incidencias.

 Tener una actividad de control de errores.

 Realizar una gestión 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.

 El propietario del proceso.

7. Indicadores
Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:

 Número de problemas creados.

 Número de problemas importantes.

 Número de errores conocidos, registrados en la base de datos de errores.

 Número de problemas resueltos en el periodo.

 Duración media del tratamiento de un problema.

 Número de problemas tratados más allá de los plazos acordados en los SLA (si se
han definido).

 Número de RFC remitidos a la gestión de cambios.

 Número de RFC cerrados sin generación de incidencia o de un nuevo problema.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se establezca.
8. Descripción del proceso

El proceso de gestión de problemas

9. Conceptos básicos
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 están relacionadas con el origen de un problema.

Como se señala en la gestión 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 diagnóstico rápido. La puesta al día de la base de datos es
una de las actividades de la gestión de problemas.
 El siguiente diagrama muestra la relación entre el proceso de gestión de incidencias y el
proceso de gestión de problemas, incluida la actualización de la base de datos de errores
conocidos, así como la creación de un RFC.

El ciclo de vida de los problemas

b. Las actividades de la gestión de problemas

Las principales actividades de la gestión de problemas son las siguientes:

 Gestión de problemas.

 Control de errores.

 Gestión proactiva de problemas.

Gestión de problemas
La gestión de problemas tiene un rol importante en la prestación 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
número de estas, en particular en el caso de incidencias recurrentes, proporcionando una
solución definitiva.

Algunas veces, la gestión de problemas puede entrar en colisión con el objetivo de la

gestión de incidencias: restaurar el servicio normal lo más rápidamente posible.

De hecho, algunas veces es necesario tomar un tiempo para identificar y analizar la causa
raíz de un problema. Esto significa congelar el estado del CI el tiempo que dura este
análisis, lo que va en contra del objetivo de la gestión de incidencias. Por lo tanto, será
necesario recurrir al arbitraje para decidir qué actitud tomar. En caso de recurrencia de las
incidencias, la decisión adecuada consistirá en tomar el tiempo útil y necesario para realizar
este análisis.

La gestión de problemas también depende mucho de las acciones de la gestión 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 análisis preliminar realizado por la gestión de problemas pueda ser eficaz. También
es primordial que la gestión 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 económicamente interesante, eliminarlos.
 Tratamiento de errores

Cuando se ha implementado con éxito la RFC que se ha puesto en marcha para la gestión
de cambios, se puede cerrar el error y los problemas que tiene asociados.

Gestión proactiva de problemas

La gestión proactiva de problemas es una de las actividades importantes de la gestión de
problemas.

El objetivo de esta actividad es prevenir la aparición de incidencias o de un funcionamiento

incorrecto en la prestación de servicios.

Para ello, la gestión de problemas debe analizar, en intervalos regulares, las incidencias y
problemas.

Este análisis debe permitir definir las tendencias e identificar los CI que potencialmente
pueden causar la aparición de nuevas incidencias.

Este análisis se puede completar con un análisis de costes asociados a la resolución de

incidencias.

Ver el anexo: las secciones Análisis de Kepner y Tregoe y Diagrama de Ishikawa.

10. Beneficios y dificultades

a. Beneficios
Uno de los beneficios principales de la gestión de problemas es la reducción del número de
incidencias.

También se obtendrá una mayor corrección de incidencias en el centro de servicios y, al

mismo tiempo, los técnicos se benefician de una base de datos de errores conocidos.

Por otro lado, el análisis proactivo de tickets de incidencias puede resaltar los problemas
potenciales.
 Todos estos elementos contribuyen a mejorar la disponibilidad del servicio.

b. Dificultades potenciales
La gestión de problemas necesita la identificación y formación continua de los técnicos que
en general tienen un nivel técnico superior al de los técnicos del centro de servicios.

Posteriormente, es imprescindible separar las actividades de gestión de incidencias, de

aquellas que pertenecen a la gestión de problemas. Estos son dos procesos con objetivos
opuestos.

En una pequeña empresa, los técnicos deben tener conocimiento, en todo momento, del
proceso en el que van a trabajar, principalmente si son las mismas personas las que
aseguran la realización de las tareas.

Gestión de consultas
1. Enfoque
En esta sección vamos a ver cómo se gestionan las consultas, también
llamadas peticiones de servicio, en el marco de la fase de explotación de servicios.

Ya hemos visto en la sección anterior la aplicación del centro de servicios. La gestión de

consultas se asegura a través del centro de servicios.

Existen varios tipos de consultas. Algunas son el objeto de una simple transmisión a un
equipo, grupo o función, mientras que otras necesitan un tratamiento más importante o
largo.

La gestión de cambios estándar también se asegura a través de este proceso.

2. Objetivos del proceso

«El objetivo principal del proceso de gestión de consultas es responder a todas las
peticiones y preguntas que recibe el centro de servicios».

Los objetivos de la gestión de consultas son los siguientes:

 Suministrar un canal a los usuarios para solicitar y obtener los servicios estándares,
para los que se han definido autorizaciones y cualificaciones.

 Suministrar una información al cliente y a los usuarios de la disponibilidad de un

servicio y el procedimiento para obtenerlo.

 Origen para entregar las peticiones de cambio estándares.

 Mantener la satisfacción del cliente y de los usuarios, a través de un proceso

eficiente.

 Tener en cuenta las reclamaciones de los usuarios o del cliente.

3. Perímetro
El perímetro de la gestión de consultas se aplica a todas las peticiones de los usuarios.

4. Indicadores
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
  Número de consultas recibidas.

 Número de consultas tratadas en modo excepción.

 Número de peticiones de cambio estándares.

 Número de consultas rechazadas.

Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que
se aplique.

5. Descripción del proceso

El proceso de gestión de problemas

6. Conceptos básicos
Las consultas pueden afectar a diferentes actividades:
  Petición para el suministro de un equipamiento, con o sin autorización inicial.

 Petición para la instalación de un software.

 Petición para obtener un acceso a una base de datos.

 Petición para la puesta en marcha de una petición de cambio estándar.

Esta lista no es exhaustiva; conviene definir las peticiones en función de la estructura que
se aplique.

Una buena gestión de consultas implica, obligatoriamente, la puesta en marcha de

modelos.

Gestión de accesos
1. Enfoque
En esta sección vamos a ver cómo se gestionan los accesos en el marco de la fase de
explotación de servicios.

Hemos visto anteriormente la aplicación del centro de servicios; la puesta en marcha de

este proceso está relacionada con el centro de servicios.

2. Objetivos del proceso

Los objetivos de la gestión de accesos son los siguientes:

 Gestionar los accesos aplicando políticas de seguridad definidas en el proceso de

gestión de la seguridad.

 Responder de manera eficaz a las peticiones para garantizar el acceso a los

servicios.

 Modificar los derechos asociados a una petición de accesos.

3. Perímetro
El perímetro de la gestión 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
Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:

 Número de peticiones.

 Número de rescisiones.

 Número de intentos fraudulentos.

5. Descripción del proceso

El proceso de la gestión de accesos

6. Conceptos básicos
El control de los accesos se basa en varias actividades:

 Gestión de contraseñas.

 Asignación de derechos de acceso.

 Modificación de derechos de acceso.

 Eliminación de derechos de acceso.

 Acciones proactivas sobre los accesos.

La gestión de los accesos debe garantizar que solo los usuarios autorizados puedan acceder
a un servicio.

También es imprescindible identificar los intentos de intrusión a través de las redes.

Las tecnologías de identificación de un usuario evolucionan constantemente.

 Por lo tanto, será imprescindible adaptarse a los métodos con mejor rendimiento.

Las políticas de seguridad se definen en el proceso de gestión de la seguridad. El proceso

de gestión de los accesos pone en marcha estas políticas.

MEJORA CONTINUA DE SERVICIOS (CSI)

Enfoque
El ciclo de vida de la gestión del servicio se divide en varias fases.

El proceso de mejora continua de servicios (Continual Services Improvement) gestiona la

iteración 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 añadido a los
servicios propuestos por la organización 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 relación con el cliente.

 Asegurar que los métodos de gestión de la calidad son eficaces.

Definición
ROI: Retorno de la inversión (Return On Investment).

VOI: Valor de la inversión (Value On Investment).

Valores intangibles: son los beneficios no expresados en valor económico; por ejemplo,
la mejora de la satisfacción del cliente, el aumento de la competencia de los actores de la
organización TI, la disminución de los riesgos...
Perímetro
Los procesos de mejora continua de los servicios implican al conjunto de la gestión de
servicios (procesos, servicios, organización, personal...).

El perímetro abarca los servicios ofrecidos y los procesos internos.

Roles
Los principales roles son:

 Propietario del proceso.

 El responsable de la mejora continua de servicios.

 Todos los demás responsables de procesos.

 Todos los demás propietarios de procesos.

 Propietario del servicio.

Indicadores
Se pueden aplicar varios indicadores:

 Los KPI.

 Los CSF.

 Las bases de referencia.

 La medición de los servicios.

 Las métricas.

Descripción del proceso

 El proceso de mejora continua de servicios

Conceptos básicos
 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 gestión de servicios (Service Strategy - SS).

 Diseñar de servicios para apoyar la estrategia (Service Design - SD).

 Implementar los servicios para satisfacer los requisitos de diseño (Service

Transition - ST).

 Soportar los servicios de gestión de actividades operativas (Service Operation - SO).

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 añadido al negocio

La mejora continua de los servicios añade valor al negocio a través de:

 Las mejoras.

 Los beneficios.

 Un retorno de la inversión.

 Un valor de inversión.
  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 capítulos anteriores:

 La Rueda de Deming (en el capítulo ITIL y las normas).

 Las 4 P (en la sección Consideraciones sobre el diseño de los servicios - capítulo Los
procesos del diseño de los servicios).

Vamos a ver otras dos.

a. El modelo CSI

El enfoque Continual Service Improvement (CSI)

A la pregunta «¿Adónde queremos ir?», corresponde una actividad que consiste en

identificar la visión que tenemos de los servicios y procesos.

A la pregunta «¿Dónde estamos actualmente?», corresponde una actividad de evaluación

de la situación actual.
 A la pregunta «¿Dónde queremos estar?», corresponde una actividad de definición de
objetivos medibles y la prioridad de las mejoras.

A la pregunta «¿Cómo conseguir nuestro objetivo?», corresponde una actividad de puesta

en marcha de las acciones de mejora.

A la pregunta «¿Cómo sabemos que hemos llegado?», corresponde una actividad de

verificación de las medidas y de las métricas aplicadas para asegurar que los objetivos
fijados se han alcanzado.

A la pregunta «¿Cómo vamos a continuar?», corresponde una actividad de control, para

asegurar la eficacia del proceso de mejora continua de los servicios.

Ver también la descripción en el capítulo Puesta en marcha de un proyecto ITIL.

b. El proceso de mejora en 7 etapas

El proceso de mejora en 7 etapas

Etapa 1 - Identificación de la estrategia para la mejora

 Visión y estrategia

 Necesidades de negocio

 Estrategias

 Objetivos tácticos
  Objetivos operativos

Etapa 2 - Definir lo que vamos a medir

Etapa 3 - Recoger los datos

 Qué

 Cuándo

 Cómo

 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 - Análisis de los datos

 Relaciones

 Tendencias

 Conforme con la planificación

 Objetivos alcanzados

 Acciones correctivas

Etapa 6 - Presentación y uso de la información

 Evaluación

 Resumen

 Planes de acción...

Etapa 7 - Poner en práctica las medidas correctivas

 El proceso de mejora continua en siete etapas está directamente relacionado con los
objetivos estratégicos, tácticos y operativos. Mide los servicios y los procesos de gestión 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:

 Definición del proyecto.

 Ciclo de implantación.
 Elección de los procesos de puesta en marcha inicial.

La implantación anterior de una certificación ISO 9001 puede favorecer la implantación de

un proyecto ITIL.

Definición del proyecto

La primera actividad de la puesta en marcha de un proyecto ITIL consiste en definir cuál es
la visión de la organización TI para la empresa.

Esta actividad es responsabilidad de la Dirección de la empresa.

La dirección de la organización, por supuesto, prepara un conjunto de documentos para

presentar el proyecto a la dirección de la empresa y, de esta manera, proporcionarle los
elementos que le permitirán tener en cuenta y apoyar el proyecto.

Esto plantea la cuestión de la gestión documental del proyecto desde el momento inicial y,
al final, la gestión documental de los procesos ITIL.

Una gestión documental rigurosa implica que se documenten las diferentes actividades del
proyecto y los procesos.

Para esto, es necesario poner en práctica en los documentos la gestión 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 descripción del modelo).

Es conveniente utilizar el término «propietario del proceso» en los documentos que

describen el proceso, salvo en el caso de la documentación en inglés.

También será necesario definir y publicar un documento sobre la gestión de los derechos de
acceso, para que cada uno sepa quién está autorizado a hacer qué y cuándo.

Como en toda gestión documental, será necesario asegurar la gestión de las versiones de
los diferentes documentos, así como la versión de los procesos a través de estos diferentes
documentos. Vaya a la sección Puesta en marcha de un proyecto ITIL - Puesta en marcha
de la gestión del conocimiento.
Esta gestión será más eficaz si, al mismo tiempo, se lleva a cabo una mejora de la calidad
del proyecto.

Ciclo de implantación
La implantación de los procesos se debe hacer siguiendo una determinada lógica.

Se puede adoptar el principio de funcionamiento descrito en el capítulo Mejora continua de

los servicios de ITIL, para estudiar la puesta en marcha del proyecto. Para más detalle
sobre el proceso, vaya al capítulo Mejora continua de los servicios (CSI).

Para ello, se puede utilizar el siguiente modelo:

Modelo del ciclo de implantación

Este modelo se basa en seis etapas que vamos a describir a continuación.

Etapa 1 - ¿Cuál es la visión?

Esta etapa permite validar la visión y los objetivos que la Dirección de la empresa quiere
que ponga en marcha la Dirección de la organización TI.

Especialmente, esta etapa debe permitir identificar cómo la organización TI va a poder

aportar un valor añadido a las áreas de negocio de la empresa o del cliente.
Los procesos ITIL se pueden utilizar como modelo de organización, para identificar aquellos
que aportan a la empresa un retorno de la inversión lo más rápidamente posible.

En esta etapa es necesario establecer una comunicación sólida por parte de la Dirección de
la empresa para anunciar y apoyar este proyecto.

Etapa 2 - ¿Dónde estamos actualmente?

La segunda es una etapa de observación y análisis.

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 situación actual. Esta operación permite
conocer el grado de madurez de la organización ITIL.

Esta etapa es importante, ya que le permite identificar cómo difiere la organización actual
de la propuesta por ITIL.

En esta etapa es necesario abordar aspectos muy diferentes:

 La visión a largo plazo.

 Los procesos de gestión (según lo descrito por ITIL).
 El establecimiento de una verdadera cultura de servicio.
 Los medios tecnológicos.
 Los medios humanos.
 La formación.
 La documentación...

En esta etapa, la organización TI ha de establecer un esquema de comunicación que

deberá mantener durante todo el desarrollo del proyecto.

Es imprescindible obtener la adhesión de los empleados para que tenga éxito la puesta en
marcha de los procesos; la comunicación que se establezca, en todas las formas, será un
factor de adhesión.

En la segunda etapa, se plantean preguntas sobre el nivel de madurez alcanzado por la

empresa en general, y la dirección informática en particular.

La medición y el análisis de la situación se lleva a cabo a través de reuniones, seminarios,

auditorías 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 - ¿Adónde queremos ir?

Durante esta tercera etapa, será necesario definir de manera precisa qué organización se
establecerá y cuáles son los roles y objetivos que se asignarán a cada propietario de
proceso dentro de la organización de TI, en la implantación de la estructura ITIL.

En esta etapa se definen cuáles son los niveles de rendimiento esperados y las métricas
que permitirán 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.

También 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 análisis 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 (técnicos y humanos) y
la carga de trabajo.

Se debe elaborar y publicar el plan del proyecto de implantación para explicar cuáles serán
los cambios y cómo se pondrán en marcha.

En esta etapa la comunicación es muy importante, ya que permitirá al conjunto de la

empresa entender cómo se pondrá en marcha el proyecto de implantación.

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 - ¿Cómo 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, después de adaptar o

instalar las herramientas informáticas destinadas a sostenerlos.

No hay que olvidar que, para que un proceso funcione, necesita establecer un sistema de
documentación basado en documentos y procedimientos.

También se debe tener en cuenta y realizar la formación del personal.

Se debe prever una fase de pruebas y validación 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.

En la puesta en marcha de una estrategia de calidad, la etapa 4 se puede asimilar a la

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, ayudándose de las métricas
aplicadas en las etapas anteriores y, si es necesario, definiendo nuevas métricas.
 Estas medidas deben tener en cuenta la satisfacción del personal y de los clientes de la
organización TI.

Esta medición se puede realizar utilizando las encuestas de satisfacción.

También es importante asegurar la mejora de la calidad del servicio y observar que los
niveles de actividades reales se ajustan a las previsiones.

En la puesta en marcha de una estrategia de calidad, la etapa 5 se puede asimilar a la

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 práctica la primera etapa del proceso de
mejora continua del servicio.

Para ello, es importante hacer una evaluación completa del proyecto de implantación,
revisar los procesos para asegurar que su contenido está correctamente alineado con los
objetivos y verificar que existe un correcto aporte de valor añadido a los procesos de
negocio de la empresa o del cliente.

Durante esta etapa, también es preciso verificar, controlar y mejorar, si es necesario, las
métricas que permitirán medir los resultados del funcionamiento de los procesos (ver el
capítulo Mejora continua de los servicios).

También es una oportunidad para recordar el mensaje clave: mantener una visión
empresarial en la puesta en marcha de los servicios.

La dirección debe llevar a cabo una comunicación al final de este proyecto, destacando las
mejoras comprobadas y recordando su fuerte apoyo a este proyecto y a las estructuras y
la organización que se han puesto en marcha.

Puesta en marcha del proyecto

1. Plazos de realización
En función del tamaño de la empresa y de los medios que se ponen en marcha, los plazos
de realización serán más o menos dilatado.

Para acelerar el proceso de puesta en marcha, muchas empresas cuentan con la

participación de consultores independientes especializados en la aplicación 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.
 Tiempo
de
Pequeña/mediana Gran
Procesos ITIL puesta
empresa empresa
en
marcha
de los
Centro de servicios + Gestión de incidencias 2 a 4 meses 4 a 6 meses

Gestión de problemas 1 a 2 meses 2 a 4 meses

Gestión de configuraciones 2 a 6 meses 3 a 10 meses

Gestión de cambios 2 a 6 meses 3 a 10 meses

Gestión del porfolio de servicios + Gestión del 1 a 4 meses 3 a 8 meses

catálogo de servicios

Gestión de los niveles de servicio 2 a 4 meses 3 a 6 meses

Gestión de la capacidad 1 a 3 meses 2 a 6 meses

Gestión de la disponibilidad 1 a 3 meses 2 a 6 meses

procesos

Se trata de tiempos medios para una puesta en marcha óptima.

Para pequeñas y medianas empresas, la puesta en marcha global de un proyecto ITIL tarda
de uno a dos años, en función de los recursos asignados al proyecto y del tamaño de la
empresa.

El número de oficinas de la empresa también puede modificar el tiempo global de puesta

en marcha.

En el caso de grandes empresas, el tiempo razonable es de dos a cuatro años,

fundamentalmente dependiendo del número de oficinas y de sus implantaciones en
diferentes países.

2. Formación de los actores del proyecto

En el ámbito de una implantación ITIL, es deseable que todo el equipo directivo de la
empresa siga una formación de tipo ITIL Foundation, incluso aunque el paso de la
certificación no sea obligatorio.
 De manera ideal, esta formación debería incluir a los responsables de las diferentes áreas
en una misma sesión, para permitir a unos y otros intercambiar y entender mejor las
dificultades que pueden encontrar diariamente en la realización de sus tareas.

Una formación como esta permite entender los conceptos principales, así como adquirir un
vocabulario común; la formación da a todos los actores un nivel de conocimiento mínimo
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 organización TI. Una vez más, el paso de la
certificación ITIL Foundation no es obligatorio, pero sí muy recomendable, ya que requiere
una fuerte implicación de los empleados en la formación.

Con respecto a las personas que se identifican para ser propietarias de los procesos, es
posible hacer que sigan una formación complementaria adaptada a los procesos de los que
serán propietarias.

Estos cursos de formación se pueden realizar en formato interempresas o intraempresa.

3. Los factores de éxito

a. Tener una visión clara del proyecto
El objetivo principal de ITIL es sustituir una visión muy orientada a la tecnología por una
visión de negocio. Entender ITIL es importante, pero también es necesario identificar qué
va a apoyar esto a la actividad de la empresa y a participar en la creación de valor.

b. ITIL es un medio, no un objetivo

Algunas direcciones informáticas y proveedores de servicios informáticos 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. Preparación de la empresa
La puesta en marcha de un proyecto ITIL normalmente es un largo y, algunas veces, difícil
camino.

La resistencia al cambio siempre existe en las empresas y actúa como freno a este.

Se deben desarrollar métodos específicos para explicar este cambio y hacer frente a esta
resistencia.

La comunicación, en todas sus variedades, forma parte de estas medidas.

d. Comunicación
La puesta en marcha de un proyecto ITIL dará lugar a un cambio en las relaciones entre las
diversas áreas y la organización TI.

La dirección de la empresa debe establecer una comunicación destinada al conjunto del

personal de la empresa.

Esta acción de comunicación debe usar los resultados tan pronto como estén disponibles, y
utilizarlos para mantener una motivación continua de los diferentes actores del proyecto.
 Uno de los objetivos de la comunicación será facilitar el paso de la organización TI de una
cultura tecnológica 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 Dirección General de la empresa establezca una comunicación
específica con objeto de acompañarlos en este proyecto.

Una falta de implicación de la directiva en el proyecto será rápidamente identificada por los
diferentes actores y provocará la desmotivación 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 día muchas empresas están 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 modificación de la estructura jerárquica.

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. Formación
Una de las grandes aportaciones de ITIL es proporcionar un vocabulario común para todos
los actores de la gestión de servicios informáticos.

La formación de estos actores hará ganar un tiempo considerable en el establecimiento de

los procesos y reforzará la adhesión de los actores (ver más arriba la sección Formación de
los actores del proyecto).

h. Apoyar el cambio
La implantación de un nuevo sistema o de un nuevo procedimiento implica
sistemáticamente una resistencia por parte de las personas que utilizan o producen el
elemento modificado. Esta resistencia al cambio es natural y clásica, pero no debe tomarse
a la ligera. Para tratar este problema, tanto los usuarios como los miembros de la dirección
informática deben entender los objetivos que se buscan, identificar los beneficios y
compartir la visión de la nueva organización, para ver el cambio como algo deseable y
necesario. La presentación de estos cambios requiere un enfoque gradual y debe conducir a
su aceptación por las diversas partes implicadas en el proyecto.

i. Prever un proceso progresivo

Los procesos de gestión 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 confusión y una mala integración del conjunto. La solución
consiste en pasar por etapas progresivas que respeten los objetivos de la empresa y las
futuras evoluciones de su madurez. Esto también permite proyectar la implantación de los
procesos desde una óptica de resultados a corto plazo, que favorece su adopción.
j. Definir un proyecto realista
Para tener éxito en un proyecto de implantación de ITIL, es necesario tener medios
humanos, técnicos, tecnológicos y financieros.

Este es un compromiso de medio o largo plazo; en función del tamaño de la empresa,

normalmente entre uno y tres años.

Hay que tener cuidado con el exceso de ambición en el inicio del proyecto.

Es necesario empezar «poco a poco» y hacer crecer el perímetro progresivamente. No

puede haber una operación 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 implantación de ITIL, como en la mayoría de los proyectos, es

la búsqueda de la perfección y la definición de objetivos demasiado ambiciosos. En este
caso, los riesgos de desmotivación 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 años.

Por lo tanto, es imprescindible definir las prioridades de su puesta en marcha.

La elección de los procesos se debe hacer en función de las prioridades determinadas por la
empresa.

De manera ideal, deberán ser prioritarios los procesos que permitan el nacimiento de una
cultura de servicio.

El establecimiento de un centro de servicios y del proceso de gestión de incidencias se

puede hacer de manera simple y obtener resultados rápidamente.

La comunicación de estos resultados permitirá una mayor motivación de los actores del
proyecto.

4. Elección de los procesos

De forma ideal, aunque normalmente no es el caso, sería necesario poner en marcha el
conjunto de procesos ITIL en el mismo momento en que se implanta la organización TI.

Actualmente, la gran mayoría de las empresas ya han implantado una organización

informática.

Por lo tanto, es necesario tener en cuenta la existencia de la empresa y establecer un

proyecto en función de su realidad.

En este contexto, los primeros procesos que se deben poner en marcha son los siguientes:

 Generación de la estrategia.

 Gestión de incidencias.
  Gestión de problemas.

 Gestión de configuraciones.

 Gestión de cambios y entradas en producción.

5. Definición del equipo de proyecto

Es imprescindible trabajar en modo proyecto para tener éxito en la implantación de
procesos ITIL.

La primera actividad que se debe realizar es definir el equipo de proyecto que se encargará
de poner en práctica los procesos y asegurar el seguimiento del proyecto.

La tentación de poner en marcha los procesos a medida que sea necesario es un error, ya
que esto no implica automáticamente la adhesión del personal y finalmente es, al menos,
tan caro como el caso de creación de un equipo de proyecto.

Este equipo de proyecto debe preparar un informe del proyecto y validarlo con la Dirección
de la empresa y la Dirección de la organización TI.

Sin el soporte real y eficaz de la Dirección de la empresa, no es posible poner en marcha

un proyecto ITIL en ella. Es importante que la dirección de la empresa emita un
comunicado sobre este proyecto tan pronto se haya tomado la decisión de ponerlo en
marcha.

6. Generación de la estrategia
En un primer lugar, la dirección de la organización TI debe poner en marcha, de manera
paralela, una estrategia para la organización.

En este ámbito, debe definir la estrategia que desea poner en marcha para la explotación y
transición de servicios.

En este estado del proyecto, no es necesario tener una definición completa y definitiva de
las estrategias que se van a poner en marcha.

El conjunto de estrategias se debe revisar más adelante.

Es durante esta etapa cuando resulta deseable poner en marcha un ciclo de formación ITIL.

7. Puesta en marcha de los procesos de explotación de

servicios
Normalmente, los procesos de gestión de explotación de servicios son los primeros en
ponerse en marcha.

Existen varias razones para esta elección:

 Visibilidad, tanto a nivel interno de la organización TI como para los clientes y

usuarios.

 Resultados fácilmente demostrables.

  Procesos que con frecuencia se ponen en marcha parcialmente.

 Puntos de entrada para más 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 gestión de activos de servicios y configuraciones y Puesta en
marcha de la gestión 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 gestión de incidencias debe coincidir con la puesta en
marcha del centro de servicios.

La comunicación 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 organización y la implementación 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 ubicación estén 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 códigos de estado en todas las
ubicaciones.

 Utilizar la misma base de datos compartida.

 Estandarizar la clasificación 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 [informáticos y de telefonía], redes...) como de software (herramientas de gestión
de llamadas, bases de datos, bases de conocimiento, CMS...), además 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 perímetro 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 utilización del centro de servicios.

 Asesorar y vender el servicio.

No iremos más allá en la descripción del trabajo del jefe de proyecto: se trata de la puesta
en parcha de un proyecto real informático.

Atención: 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 catálogo de servicios.

b. Desarrollo de las operaciones

En primer lugar, debe elegir una herramienta de gestión de llamadas que corresponda
a sus necesidades.

Si ya hay una herramienta operativa, es necesario asegurar que permite todas las
operaciones de creación, control y seguimiento de los tickets. También es necesario
verificar la configuración de la herramienta en función 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 sección Gestión de los niveles de servicio -
capítulo Los procesos del diseño de los servicios). En general, los fabricantes de software
proporcionan un soporte para la configuración de sus herramientas, ya que normalmente
resulta complejo realizar esta configuración de manera óptima.

Atención: no olvide que un error en la configuración de la herramienta, puede tener

importantes consecuencias en el cumplimiento del contrato de servicios.

La configuración se refiere, en particular a:

 Los horarios de soporte.

 Los diferentes tipos de llamadas.

  Los diferentes códigos de gestión de tickets.

 Los diferentes datos relativos a los actores del soporte.

 Las nociones de impacto y urgencia, que después permitan definir automáticamente

un nivel de prioridad.

 Las colas de espera y asignación 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 formación del conjunto de los equipos del
centro de servicios (responsables y técnicos) sobre el uso de la herramienta.

Del perfecto manejo de la herramienta de gestión de incidencias dependerá la eficacia y

eficiencia del centro de servicios y, por lo tanto, la percepción que tendrán los clientes de
él.

9. Puesta en marcha de la gestión de incidencias y problemas

En esta etapa será necesario poner en marcha los procesos de gestión de incidencias
y problemas.

De manera ideal, esta etapa deberá coincidir con la puesta en marcha del centro de
servicios.

Sea cual sea el tamaño de la organización TI, es deseable identificar correctamente los dos
procesos de gestión de incidencias y problemas.

Los objetivos de estos dos procesos son distintos y opuestos:

 Restablecer el servicio lo más rápidamente posible para la gestión de incidencias; por

lo tanto, responder lo más rápidamente posible.

 Identificar la causa subyacente desconocida para la gestión de problemas; por lo

tanto, tomar el tiempo necesario para analizar e identificar la causa primera real de
las incidencias.

Si el tamaño de la organización TI no permite tener dos equipos distintos, en este caso es

preferible asignar los roles a los técnicos, dejándoles cambiar de rol de manera regular.

Por ejemplo, una parte del equipo asegura la gestión de incidencias por la mañana y
cambia de rol por la tarde, para asegurar la gestión de problemas.

Esta forma de funcionar también se puede establecer de manera diaria o semanal.

 Esta etapa implica estar especialmente atentos a la formación de los técnicos del centro de
servicios.

10. Puesta en marcha de los procesos de transición de

servicios
Después de la puesta en marcha de los procesos de explotación de servicios, es
aconsejable poner en marcha los procesos de transición de servicios.

Estos, a su vez, suelen ser puntos de entrada para el proceso de diseño de servicios.

El proceso de gestión del catálogo de servicios se pone en marcha habitualmente en el

mismo momento que los procesos de transición de servicios, ya que servirá de unión entre
los procesos de explotación y transición de servicios.

Al mismo tiempo, servirá como punto de partida para muchos procesos de diseño de
servicios.

11. Puesta en marcha de la gestión 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 gestión de activos de servicio y configuraciones se apoyan en la creación

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 gestión de incidencias y problemas,
aunque su disponibilidad pueda ayudar al funcionamiento de estos dos procesos.

La creación de esta base de datos se apoya en un análisis preciso de su contenido futuro, y

fundamentalmente de los atributos y relaciones que se definirán.

Atención: no quiera ir demasiado rápido y demasiado lejos; es necesario ser modesto y

comenzar poco a poco, antes de ampliar el perímetro y la granularidad de la CMS.

En caso de que ya exista una gestión de Assets en la empresa, eventualmente se podrán

utilizar los datos ya disponibles.

Lo importante es mantener actualizada la CMS. Esto se consigue poniendo en marcha el

proceso de gestión de cambios.

a. ¿Qué beneficios se pueden obtener de la puesta en marcha?

La puesta en marcha de la gestión de activos de servicio y configuraciones (SACM) permite
a la empresa obtener una mejor gestión de sus activos y configuraciones. Esto será tanto
más 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 gestión de configuraciones tipo.

b. Los riesgos en términos de seguridad

Un problema frecuente que se encuentra la mayoría de las empresas: la gestión de los
derechos de acceso.

¿Cómo es la asignación de derechos de acceso en las empresas?

Tras entrar en la empresa, al empleado se le asignan derechos de acceso basados en la

posición que va a ocupar.

Las complicaciones comienzan cuando el empleado cambia de puesto.

Lógicamente, a este empleado se le deberán retirar una serie de derechos, aquellos que ya
no corresponden a su nuevo puesto, y deberá recibir otros nuevos, siempre en función 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 gestión 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 más 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 manipulación involuntaria o debido a una voluntad de
acción maliciosa.

Estos riesgos se pueden evitar aplicando las configuraciones tipo, identificadas en la CMS,
para cada tipo de función. Por lo tanto, basta aplicar, por cada cambio de función de un
empleado, la configuración correspondiente a su nueva función.

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 teóricamente, debe haber un cierto porcentaje, fijado por
ley, de personal con discapacidad.

El puesto de trabajo del empleado puede necesitar una adaptación, en función de su

discapacidad.
En el marco de una reorganización de servicios en el seno de la empresa, es imprescindible
tener en cuenta las diferentes características de acondicionamiento del puesto de trabajo
del empleado.

Estas características pueden estar relacionadas con una dificultad física de acceso al lugar
de trabajo o con la necesidad de utilizar un equipamiento especial; por ejemplo, una
pantalla de tamaño específico en caso de discapacidad visual.

No siempre las personas encargadas de la puesta en marcha de la reorganización tendrán

conocimiento de estas características, lo que puede provocar un funcionamiento incorrecto
en el momento de la mudanza.

La aplicación de una configuración tipo permitirá identificar las características vinculadas a

esta persona, facilitando el trabajo de los equipos encargados de la reorganización, 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 día 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.

También es habitual que el plazo de espera para disponer de un puesto de trabajo con
todos los derechos correspondientes a su función 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 compañeros y, lo que es más grave, los códigos de acceso a las
aplicaciones y a los datos (usuario y contraseña).

Se debe tener en cuenta dos aspectos en este tipo de situación:

 La falta de productividad del nuevo empleado.

 El incumplimiento de las normas de seguridad definidas en el proceso de gestión de

la seguridad de la información.

La preparación de la llegada de un nuevo empleado permitirá a los equipos internos poner

en marcha los diferentes medios informáticos 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 información.

Marcha de un empleado
No es raro ver todavía hoy en día en las empresas grandes o medianas que cuando se
marcha de un empleado no se hace nada en términos de actualización de los derechos de
acceso a las aplicaciones y datos.

Además, es frecuente que esta situación se mantenga durante varias semanas, incluso
meses.
 El impacto es también doble:

 No se liberan recursos, fundamentalmente de almacenamiento.

 No se respetan las normas de seguridad definidas en el proceso de gestión de la

seguridad de la información.

De nuevo, en ausencia de procesos claramente definidos e identificados, los riesgos de

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

d. Dificultades en la gestión de configuraciones tipo

En las empresas medianas y grandes, en el seno de la organización informática, hay un
equipo encargado de la puesta en marcha y mantenimiento de los equipos informáticos.

En ausencia de definición de configuraciones tipo, los empleados de estos equipos deben

gestionar de manera unitaria la instalación de cada puesto de trabajo.

La optimización de los tiempos de puesta en marcha de los puestos de trabajo para estos
equipos pasa necesariamente por la definición de configuraciones tipo.

Se tienen en cuenta dos tipos de configuraciones tipo:

 Configuraciones de tipo hardware: la definición de configuraciones tipo permiten una

gestión más eficaz de los puestos de trabajo y facilitan las operaciones de
mantenimiento de los puestos. La utilización de un Master específico para cada tipo
de configuración de hardware, en función del tipo de máquina o fabricante, permite
una puesta en marcha y despliegue de los puestos de trabajo más rápidos.

 Configuraciones de tipo funcional: la definición de configuración tipo en función del

tipo de puesto funcional ocupado por el empleado va a permitir una vez más, gracias
al uso de un Master, una preparación del puesto más rápida 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 gestión de cambios

Esta etapa se puede llevar a cabo al mismo tiempo que las etapas descritas en la sección
Puesta en marcha del centro de servicios y Puesta en marcha de la gestión de incidencias y
problemas.

La puesta en marcha de los procesos de gestión de cambios y gestión de las entradas en

producción probablemente va a proporcionar cambios en los hábitos de funcionamiento de
la organización TI.

De manera ideal, la puesta en marcha del proceso de gestión de cambios se debería hacer
al mismo tiempo que la puesta en marcha del proceso de gestión de los activos de servicio
y configuraciones.

Sin embargo, debido a que los procesos de diseño de servicios todavía no están
implementados, es posible que únicamente una parte del proceso de gestión de cambios se
ponga en marcha en esta etapa.
 Un punto muy importante en esta etapa es permitir la actualización de la CMS tan pronto
como se identifique un cambio en la infraestructura.

La constitución 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 estén identificados, del conjunto de peticiones de cambio presentadas. Esto no
implica necesariamente que estén obligados a participar en las reuniones del CAB, al
menos si no se ven implicados por los cambios examinados.

La elaboración y la firma de los contratos de acuerdo de servicio entre la organización TI y

el cliente o entre la organización TI y los proveedores se deben llevar a cabo en el marco
del proceso de gestión de cambios para asegurar la coherencia de las ofertas y de las
respuestas proporcionadas.

La puesta en marcha de este proceso debe permitir la coordinación 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 implantación de

un cambio, fundamentalmente durante la instalación de un nuevo servicio, una nueva
versión de software o de aplicación, es la parte «documental».

En efecto, es importante para el conjunto de los actores de la empresa, pero también para
el cliente y los usuarios, haber sido informados de este cambio y haber recibido, si se da el
caso, documentación adaptada, así como la formación necesaria para aprender
correctamente el nuevo servicio o la nueva versión de software o de una aplicación.

En el caso anterior, es igualmente importante establecer un soporte específico para esta

puesta en marcha (Early Life Support).

Además del hecho de que esto permite asumir más rápidamente el nuevo servicio o versión
de software/aplicación, esto también permite un refuerzo de las relaciones entre los
equipos de diseño 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 gestión de cambios es reducir los riegos
relacionados con los cambios mal controlados.

El punto más importante durante la fase de inicio del proceso es asegurar que todos los
cambios relativos a los elementos de la configuración de activos del servicio y de la
configuración se registran correctamente en el sistema de gestión (CMS: Configuration
Management System). Será necesario estar atentos.

13. Puesta en marcha de la gestión de pruebas y validación de

los servicios
Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en la sección
Puesta en marcha de la gestión de cambios.
 Las empresas, en función de su tamaño y del tamaño de su organización TI, no tendrán
siempre un equipo de pruebas y de validación de los servicios para asegurar el conjunto de
pruebas anteriores a las entradas en producción 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 validación de los servicios. En
la medida de lo posible, puede ser interesante incluir en estos equipos a empleados
procedentes tanto de la gestión del diseño de servicios como de la gestión operativa.

Esta mezcla puede mejorar la colaboración 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 también sirve para asegurar
que responde a las especificaciones solicitadas en el contrato de servicios.

14. Puesta en marcha de la gestión de las entradas en

producción
Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en las secciones
Gestión de cambios y Gestión de validaciones y pruebas, del capítulo Los procesos de la
transición de los servicios.

La formación del equipo encargado de la puesta en marcha en producción seguirá las reglas
definidas en la sección Gestión de las entradas en producción y Gestión de las validaciones
y pruebas del capítulo Los procesos de transición 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.

También es imprescindible asegurar que el paquete de instalación esté compuesto por un

conjunto de componentes compatibles entre ellos.

Es importante asegurar la trazabilidad del paquete de instalación y despliegue para permitir

una eventual desinstalación en caso de que sea necesario.

Durante esta etapa, también será necesario asegurar que el conocimiento y las
competencias se transfieren a los equipos operativos (soporte y explotación).

15. Puesta en marcha de la gestión del conocimiento

Este proceso tiene por objetivo asegurar que la información 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 noción de valor añadido se ha entendido claramente
y se comparte por el conjunto de equipos de cada servicio prestado por la organización de
TI.

Es necesario asegurar que la información relativa al servicio (usuarios, restricciones,

beneficios esperados...) sea accesible a las personas adecuadas, en el momento adecuado.

El suministro de la información que define el conocimiento permite al proveedor del servicio

mejorar la calidad del servicio proporcionado, reduciendo los costes y aumentando la
satisfacción del cliente.
 Es deseable poder aprovechar la puesta en marcha de este proceso para hacerse cargo del
conjunto de actividades relacionadas con la gestión de la documentación.

Se debe poner en marcha una estandarización de los diferentes formatos de soporte para
clarificar la presentación y lectura de los diferentes documentos.

Esta estandarización debe permitir un mejor entendimiento de la documentación para el

conjunto de los empleados de la organización TI.

El establecimiento de una gestión documental, idealmente usando una herramienta de

gestión documental, debe permitir a cada uno encontrar rápidamente la información que
necesita, tanto para tomar decisiones como para proporcionar soporte a los usuarios.

El establecimiento del proceso de gestión del conocimiento se puede hacer a través de la

gestión del conocimiento (SKMS - Service Knowledge Management System) y de
herramientas de gestión de los activos de servicio y configuraciones (CMS - Configuration
Management System).

16. Puesta en marcha del porfolio de servicios y del catálogo

de servicios
En esta etapa, se debe comenzar la puesta en marcha de los procesos de gestión del
porfolio de servicios y gestión del catálogo de servicios.

El catálogo de servicios es un subconjunto del porfolio de servicios.

La primera etapa consistirá en hacer un inventario de los servicios que entrega actualmente
la organización TI. Esto constituirá la base del catálogo de servicios que alimentará
finalmente al porfolio de servicios.

La puesta en marcha completa del proceso de gestión del porfolio de servicios se puede
realizar en segundo lugar, al mismo tiempo que el proceso de gestión de la demanda.

La elaboración de un catálogo de servicios servirá para:

 Crear una etapa preparatoria en el establecimiento de la gestión de los niveles de

servicio.

 Poner en marcha la comunicación hacia los empleados de la organización TI, clientes

y usuarios.

 Realizar un análisis de las diferentes actividades de la organización TI y las relaciones

entre estas actividades.

El análisis de las actividades dará lugar a una reflexión de los problemas relacionados con
los procesos, la organización y las herramientas de la organización TI.

En esta etapa, será necesario hacer un análisis de cada uno de los servicios para identificar
el valor añadido aportado para cada servicio.

El catálogo de servicios se debe dividir en dos capítulos distintos.

El catálogo de servicios debe identificar y diferenciar el catálogo de servicios de negocio, es

decir, los servicios ofrecidos a los clientes, y el catálogo de servicios técnicos, es decir, los
servicios internos.
 El catálogo de servicios de negocio contiene los detalles de todos los servicios informáticos
suministrados y prestados a los clientes. Contiene las relaciones con las áreas de negocio y
con los procesos. Este catálogo es visible para los clientes.

El catálogo de servicios técnicos contiene las relaciones con los componentes y con los CI
necesarios para proporcionar el servicio. También contiene las relaciones con los servicios
de soporte. Este catálogo es visible para los servicios internos de la organización TI.

¿Cómo describir un servicio?

La descripción de un servicio debe incluir los siguientes elementos:

 Una descripción técnica o funcional del servicio. Esta descripción se puede basar

ANEXOS
Análisis 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 análisis de un problema debe ser un proceso automático de
resolución de problemas.

Esta matriz utiliza el conocimiento y las experiencias pasadas.

Se definen cinco fases para el análisis de un problema.

1. Las cinco fases

Las cinco fases definidas por Kepner y Tregoe son las siguientes:

 Definición del problema.

 Descripción del problema (identificación de la identidad, el lugar, el momento y el

tamaño).

 Establecimiento de las posibles causas.

 Pruebas de las causas más probables.

 Verificación de causa real.

Sea cual sea la cantidad de información o la urgencia de encontrar una solución, es mejor
adoptar un enfoque estructurado para analizar los problemas, con el objeto de aumentar
las posibilidades de éxito.

2. Definición del problema

El análisis y la búsqueda de la causa se basan en la definición del problema.

Es imprescindible identificar de manera precisa cuáles son las desviaciones en relación con
los niveles de servicio acordados.

En la práctica, la definición de un problema es, a menudo, difícil debido a la complejidad de

la infraestructura informática o de los acuerdos de niveles de servicio no explícitos.
 Frecuentemente, la causa más probable del problema se señala en la descripción de este.
No hay que sacar conclusiones precipitadas que podrían conducir a pistas falsas.

3. Descripción del problema

Se utilizan los siguientes elementos para describir un problema:

 Identidad: ¿qué componente (CI) o parte del componente no funciona

correctamente?, ¿cuál es el problema identificado?

 Ubicación: ¿dónde aparece el problema?

 Momento: ¿cuándo apareció el problema?, ¿con qué frecuencia aparece?

 Tamaño: ¿cuál es la importancia del problema (en términos de tamaño)?, ¿cuántos

componentes (CI) están afectados?

La situación real y efectiva se determina por las respuestas a estas preguntas.

A continuación, se deberá buscar en el entorno próximo los componentes que funcionan

correctamente.

Esto le permitirá identificar lo que podría haber sido parte del problema, pero que no lo es.

A continuación, se pueden identificar las diferencias relevantes entre las dos situaciones.

Atención: 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 más probables

Se debe examinar cada posible causa para determinar si se puede aceptar como causa de
todos los síntomas del problema.

6. Verificación 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 sustitución de una pieza pueden ser pruebas.

Diagrama de Ishikawa
Esta herramienta fue destacada por Kaoru Ishikawa (1915-1989), ingeniero químico y
pionero (y uno de los teóricos) de la gestión de calidad.
 Herramienta de análisis de causas probables, este diagrama causa-efecto también 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 situación dada.

 Llegar a un acuerdo sobre la definición y características de la cuestión tratada.

 Ordenar por familias y subfamilias todas las causas de un problema dado.

 Visualizar con claridad la relación adecuada de causa y efecto.

2. Casos de uso
El diagrama de Ishikawa se utiliza con frecuencia en los dos siguientes ámbitos:

 Resolución 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 información.

En el caso de resolución de problemas, esto puede evitar errores de diagnóstico.

Ello tiene un impacto directo en el plazo, la calidad y los costes invertidos en la
resolución del problema.

 Desarrollo de un nuevo servicio o de un proyecto: cuáles son las áreas que es

preciso considerar para obtener un servicio eficiente. La gestión y los medios
financieros se pueden tener en cuenta en este ámbito.

3. Las áreas de clasificación

Originalmente, Kaoru Ishikawa identificó cinco áreas de clasificación.

Las cinco áreas pueden ser una base efectiva para la clasificación:

 Materia: materias primas, piezas, conjuntos, suministros, identificación,

almacenamiento, calidad y manipulación.

 Equipo: maquinaria, herramientas, equipos, capacidad, edad, número y

mantenimiento.

 Mano de obra: directos, indirectos, motivación, formación, absentismo y

experiencia.

 Medio: entorno físico, iluminación, ruido, planificación, relaciones, proveedores,

mercado y legislación.

 Métodos: instrucciones, manuales y procedimientos.

4. Progreso
En el marco de la resolución de un problema:

 Definir con claridad el eje sobre el que desea actuar directamente.

 Listar las causas más probables del problema.

 Clasificar las causas probables en las cinco áreas.

 Establecer subfamilias cuando el número de casos por familia lo justifique.

 Trazar el diagrama causa/efecto (Ishikawa).

Recomendación: asegúrese de que el diagrama es claro y legible.

5. Ejemplo
Definir con claridad el eje sobre el que desea actuar directamente
El objetivo:

 prestación de un servicio de tipo centro de servicios.

Listar las causas más probables del problema

En este caso, vamos a definir cuatro áreas:

 recursos de red,

 telefonía,

 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 telefonía:

 puesto telefónico:

 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,

 configuración:

 software,

 hardware,

Establecer subfamilias cuando el número de casos por familia lo justifique

En este caso, no vamos a definir subfamilias.

Trazar el diagrama de causa/efecto (Ishikawa)

A continuación encontrará el diagrama resultante de nuestras hipótesis.
 Diagrama de Ishikawa

El modelo RACI
Para el correcto funcionamiento de un sistema basado en procesos, es importante saber, en
el seno de la organización: quién hace qué, cuáles son las responsabilidades y cuáles los
roles.

Para gestionar eficazmente un servicio o un proceso, es imprescindible que las

responsabilidades y los roles de cada uno estén claramente definidos.

Esto es lo que permitirá a la organización tener buen rendimiento y tomar rápidamente

buenas decisiones antes de poder ejecutarlas eficazmente.

En el caso de una elección estratégica o de una operación crítica, saber quién decide, quién
actúa y quién está implicado permite a la organización reaccionar con rapidez.

El modelo RACI proporciona ventaja para tomar decisiones con confianza y serenidad.

RACI es acrónimo de los cuatro roles principales siguientes:

 Responsible (en español: Responsable de la realización) es la persona o personas

que realizan la actividad. Puede haber varias personas con este rol.

 Accountable (en español: Responsable) es la única persona responsable de una

actividad. Muy a menudo, hay una relación jerárquica entre A y R (con frecuencia, A
es jefe de R).

 Consulted (en español: Consultado): son las personas consultadas; por lo tanto,
aquellas cuya opinión se solicita.
  Informed (en español: Informado): son las personas a las que se mantendrá
informadas.

Atención a la correcta definición de «Responsible» y «Accountable» porque es común

intercambiar el significado en español de «Responsable de la realización» 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 asignación de responsabilidades al azar. Por otra parte, es
importante que la asignación de roles se haga lo antes posible en la puesta en marcha del
proyecto. No hay que esperar a una situación de crisis para asignar los roles. Los conflictos
se pueden evitar y se pueden tomar decisiones rápidamente si los roles se definen de
antemano.

1. Las variantes del modelo RACI

a. RASCI
Una variante del modelo RACI se llama RASCI y añade un rol adicional:

La S significa Supportive (en español: el que da soporte). Este rol desempeña un papel de
soporte, por ejemplo asignando recursos adicionales para la puesta en marcha del
proyecto.

b. RACI-VS
Otra versión más completa de RACI, llamada RACI-VS, se utiliza para los roles siguiente:

Verifies (en español: Controlador): la persona o grupo que verifica si se ha cumplido el

criterio de aceptación.
 Signs Off (en español: Responsable del cierre): persona que aprueba la decisión «V» (ver
más 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 definición de los atributos de un CI
 Atributo Descripción

Identificador del CI Nombre único por el que se conoce este tipo de CI.

Número de serie, de Identificador único para las instancias particulares del CI (por ejemplo,
licencia (o copia de para un software, número de licencia o número de copia, y para
licencia) hardware, el número de serie).

Categoría Clasificación de un CI (hardware, software, documentación...).

Tipo Descripción del tipo de CI. Completa la «categoría» y añade Para

información (por ejemplo, configuración del hardware, paquete de los
software, periférico de hardware o módulo de software o de un RFC,
programa). los

Número de modelo Modelo de CI (correspondiente, por ejemplo, al número de modelo del

(hardware) proveedor; por ejemplo, modelo yyy PC/aa de tal proveedor).

Fecha de vencimiento de Fecha de vencimiento de la garantía del proveedor para el CI de

la garantía hardware o de responsabilidad de asistencia para el software.

Número de versión Número de versión del CI.

Ubicación Ubicación del CI (por ejemplo, la biblioteca en la que encuentra el CI o

el CD sobre el que se registra, el lugar o ubicación donde se sitúa el
servicio).

Propietario responsable El nombre o designación del propietario responsable del CI.

Fecha de inicio de la Fecha a partir de la cual el propietario se con- vierte en responsable del
responsabilidad CI.

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

desarrollado internamente, comprado a la organización xxx...).

Licencia Número de licencia o referencia a un contrato de licencia.

Fecha de Fecha en la que la organización ha adquirido el CI.

aprovisionamiento

Fecha de aceptación Fecha en la que el CI ha superado satisfactoriamente las pruebas de

aceptación de la organización.
 registros de cambios, los registros de paquetes, los nombres, los números de copia, los
números de modelo y los números de versión de los CI afectados por el cambio, y cómo se
afectan, se debe guardar en un CMS. También se deben registrar un modo para volver
atrás y las consecuencias de una vuelta atrás.

Glosario
Este glosario retoma los términos usados en este libro, así como los acrónimos y términos
ingleses usados en la literatura ITIL.

Estos términos están clasificados por orden alfabético.

Puede encontrar un diccionario ITIL de la OGC en español, que puede descargar

gratuitamente en internet.

Haga un búsqueda usando ITIL 2011 Spanish Glossary v1.0 para acceder al documento
descargable. Atención, este diccionario tiene 154 páginas, pero es particularmente útil por
el nivel de detalle que ofrece y por la facilidad de búsqueda tanto en inglés como en
español.

Activación: lanzamiento por la dirección general de la empresa del plan de reanudación de

la actividad después de un problema importante.

Actualización: agrupamiento de uno o varios cambios autorizados, probados e instalados

en el entorno de producción.

Actualización agrupada: conjunto de actualizaciones de software o de hardware,

implantadas al mismo tiempo en el entorno de producción.

Actualización completa: actualización integral de los componentes de un sistema

(hardware, software, documentación, procedimientos...) que hayan sido modificados o no
desde la última actualización.

Actualización diferencial (DELTA): actualización que solo sustituye los elementos de

configuración que han cambiado desde la última actualización.

Acuerdo de nivel de explotación: expresión en términos técnicos del acuerdo de nivel

de servicio firmado por los usuarios, y que expresa de manera particular los recursos
técnicos y humanos que se deben utilizar.

Acuerdo de nivel de servicios: documento que define los objetivos concretos y

específicos para el servicio considerado. Compromete a las dos partes (clientes y
proveedores, u organización TI si el cliente es un servicio interno de la empresa), en lo
relativo a los niveles esperados en términos de disponibilidad, capacidad y costes, y
permite la evaluación del rendimiento de la organización informática 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 petición o en la infraestructura.

Ajuste: actividad dedicada a adaptar los parámetros de un componente de la

infraestructura o servicio, con el objetivo de obtener una mejora del rendimiento.

Alerta: mensaje electrónico que proviene de un sistema de monitorización automático

informando de que se ha alcanzado un umbral o se produce o se puede producir un fallo.
Amenazas: causas eventuales de una perturbación que actúa sobre la infraestructura
(hardware, software o servicios) y que podrían dificultar el suministro de los servicios.

Amortización: medida de la disminución 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.

Análisis de impacto: identificación de los procesos de negocio críticos y las pérdidas o

daños potenciales que pueda causar a la empresa como consecuencia de un
funcionamiento incorrecto de estos procesos.

Análisis de los fallos del sistema: técnica diseñada para proporcionar un enfoque
estructurado de la identificación de las causas subyacentes de los funcionamientos
incorrectos en el suministro de los servicios.

Análisis del riesgo: identificación 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.

Anomalía: condición que causa la imposibilidad de una unidad funcional para ejecutar la
función requerida.

Asistencia: servicio que corresponde al suministro de ayuda y de soporte que la dirección

informática aporta al cliente.

Atributo: característica descriptiva de un elemento de configuración registrado en la base

de datos de la gestión de configuraciones (por ejemplo: tipo de CI, marca o modelo,
proveedor...).

Auditoría: proceso de inspección y verificación utilizado para validar que una actividad se
realiza según un estándar aceptado o según la mejor práctica reconocida.

Base de datos de la gestión de las configuraciones: base de datos que reagrupa la

información de configuración e histórica de todos los elementos de configuración (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 lógicas o físicas.

Cadena de valor: sucesión 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 implementación y sus fechas de ejecución propuestas.

Cambio: modificación voluntaria de un elemento de configuración de la infraestructura,

con el objetivo de cambiar su comportamiento, capacidad o estado.

Cambio de urgencia: modificación 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 información.
Cambio estándar: modificación 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.

Catálogo de servicios: documento producido bajo la responsabilidad del proceso de

gestión del catálogo, con el objetivo de informar a los clientes y usuarios de los servicios y
la infraestructura disponibles.

Categoría: clasificación por grupos distintos de los elementos de configuración como

hardware, cambio o problema.

Categorización de las incidencias: clasificación que permite jerarquizar las incidencias.

Centro de beneficio: modo de organización contable en el que una actividad de negocio

interna de la empresa se percibe como una actividad independiente, cuyos objetivos se
definen por la Dirección 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 organización contable en el que una actividad de negocio solo
se percibe a través de sus gastos.

Centro de llamadas: interfaz entre los usuarios y la informática, dedicada a la recepción

de llamadas telefónicas de petición 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 través
de un único punto de contacto. El centro de servicios también sustituye a un rol de gestión
de las incidencias, ofreciendo un recurso técnico de primer nivel y teniendo en cuenta todas
las peticiones, quejas o consultas de los usuarios.

Ciclo de vida: descripción de las diferentes etapas de la duración de uso de un producto,

servicio o proceso.

Ciclo de vida de las incidencias: progreso del estado de un evento, que implica un
funcionamiento incorrecto del servicio que va desde la aparición o detección del
funcionamiento incorrecto hasta la restauración del servicio, pasando por las etapas de
diagnóstico del origen, reparación o solución temporal del fallo en la infraestructura
operativa.

Ciclo de vida de los problemas: progreso del estado de la causa de una anomalía que
afecta al sistema de información, que pasa por la identificación de la causa, elaboración de
una solución temporal o permanente y petición de cambio eventual, para poner en marcha
esta solución.

Clasificación: actividad de agrupamiento de los elementos de configuración (CI) por tipo

(hardware, software, procedimientos, documentos o servicios externos).

Cliente: el que especifica las necesidades de negocio, con quién se ha acordado los
servicios que se tienen que entregar y quién es responsable de su financiación.

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 evaluación,
priorización y planificación de los cambios. Se compone de las propiedades del proceso
táctico y del proceso de gestión 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: reunión de urgencia de un comité consultivo de

cambios, restringido a los miembros imprescindibles para la evaluación de un cambio
urgente.

Configuración básica: imagen congelada del estado de un elemento de configuración (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 rápidamente.

Contabilidad: conjunto de actividades que permiten a la organización informática

identificar, clasificar y justificar sus gastos financieros.

Contramedida: acción que se toma para reducir el riesgo o su impacto sobre el sistema
de información.

Contrato: Acuerdo formal entre dos personas, sometidas a las restricciones legales en
vigor.

Contrato de subcontratación: contrato con un proveedor externo para obtener una

prestación de servicios que permita el suministro de los servicios informáticos. De esta
manera, hablamos de contrato de tipo UC (Underpinning Contract).

Control de configuraciones: actividad que asegura que solo los elementos de

configuración (CI) autorizados e identificados se usan en la infraestructura informática de la
empresa.

Convivialidad: capacidad de un servicio, aplicación o hardware de utilizarse de manera

sencilla, intuitiva y sin formación excesiva.

Coste de funcionamiento (de explotación, producción...): representa los gastos de

explotación diaria de una organización (costes en personal, mantenimiento del hardware,
electricidad...).

Coste de transferencia: representa el coste de las prestaciones suministradas de una

división 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: aplicación contable que se imputa a la Dirección financiera).

Coste fijo: representa un coste que no varía 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: mensajería utilizada por toda la empresa).

Coste marginal: representa el coste de producción de una unidad adicional antes de la

aplicación del sistema de producción. Incluye principalmente los costes de materia prima,
mano de obra y amortización del sistema. El interés de este valor es demostrar que el
coste de posesión de un equipamiento no es simplemente su coste de compra y también
permite confirmar que el coste de producción de una unidad disminuye con el volumen
producido.

Coste total de posesión: 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 función del volumen de uso de un
servicio, materias primas o de un producto.

Cultura de servicio: base sobre la que se debe construir la organización TI. La

satisfacción del cliente es la prioridad más importante de la organización TI y las
actividades de puestas en marcha contribuyen a estos objetivos.

Definitive Hardware Storage: zona de almacenamiento seguro de los equipos

informáticos de recarga.

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 lógicas o
físicas.

Diagnóstico: tercera etapa del ciclo de vida de una incidencia durante la que el equipo
informático intenta identificar su origen.

Dimensionamiento de la aplicación: actividad de evaluación de los recursos necesarios

para una aplicación nueva y adición o mejora de una aplicación existente.

Disponibilidad: indica la capacidad de un sistema para hacer su función durante un

tiempo dado. Normalmente, este valor se expresa como un porcentaje del tiempo durante
el que el sistema está disponible, en relación con el horario de servicio negociado en el
SLA.

Duración media de disponibilidad (MTBF): duración media durante la que el servicio

está disponible. Este tiempo también se llama Up Time o tiempo de disponibilidad.

Duración media de reparación (MTTR): duración media de reparación, también

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 detección, diagnóstico (o tiempo de respuesta), reparación,
restauración y recuperación.

Duración media entre dos incidencias (MTBSI): tiempo entre dos incidencias.

Eje sobre el cliente: basado en los objetivos del cliente.

Elemento de configuración: representa cualquier componente de la infraestructura

informática referenciado en la base de datos de configuraciones (CMDB), como el
hardware, el software, documentación o documentos de la organización (contratos,
acuerdos, formularios, procedimientos...).

Ensamblado: etapa final en la producción de una configuración, utilizable a partir de un

conjunto de elementos de configuración 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 producción u operativo: sistema informático que se usa para proporcionar

el servicio solicitado por los usuarios.

Entorno de prueba: sistema informático compuesto de hardware, software y

documentación, que se usa para probar los cambios antes de implantarlos en el entorno de
producción.

Error conocido: causa identificada del funcionamiento incorrecto de un componente de la

infraestructura, sin que por el momento se haya implantado obligatoriamente una solución
definitiva.

Evaluación de riesgos: actividad que permite analizar los riesgos potenciales y sus
consecuencias en el sistema de información y, por extensión, en la actividad de la
organización TI o de la empresa.

Evento: todo evento detectable o perceptible que pudiera tener un impacto significativo en
la gestión de la infraestructura informática o la entrega de un servicio.

Externalización: operación que consiste en transferir los servicios realizados internamente

en la empresa a un proveedor externo.

Facturación: actividad de creación y emisión 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 evaluación de los daños.

Fase de invocación y de recuperación: la segunda fase de un plan de recuperación de

las actividades del negocio durante la que se lanzan los procedimientos de reparación,
restauración y recuperación de los servicios.

Fiabilidad: corresponde a la aptitud de un sistema para funcionar de manera perdurable,

con incidencias o interrupciones mínimas.

Funciones vitales para el negocio (VBF - Vital Functions Business): agrupa las
funcionalidades que soporta uno o varios servicios informáticos, cuya no disponibilidad
puede tener consecuencias graves para la actividad de la empresa.

Gestión de la capacidad del negocio (BCM - Business Capacity Management):

actividad de la gestión de las capacidades que permite asegurar que se tienen en cuenta
las necesidades futuras en materia de servicios informáticos.

Gestión de la capacidad de los recursos (BCR - Business Capacity Resource):

actividad de gestión de las capacidades que permite asegurar que los recursos informáticos
existentes se vigilan y miden, y que se tiene en cuenta el suministro de las nuevas
tecnologías.

Gestión de la capacidad de los servicios (SCM - Service Capacity Management):

actividad de la gestión de las capacidades que permite asegurar que los recursos cumplen
los objetivos de los servicios informáticos firmados en los acuerdos de nivel de servicios.
Gestión de la continuidad del negocio (BCM - Business Continuity Management):
proceso de evaluación de los errores y las consecuencias que pueden tener en las funciones
y procesos de negocio críticos, para asegurar que la empresa está en condiciones de
responder de manera planificada y preparada.

Gestión de la disponibilidad: proceso responsable del diseño, implementación y control

de la disponibilidad de los servicios informáticos.

Gestión de las capacidades: proceso encargado de definir y controlar las necesidades de

la empresa en materia de capacidad informática, con el objetivo de proporcionar esta
capacidad en el momento adecuado y con un coste óptimo.

Gestión de cambios: proceso responsable de controlar y gestionar las peticiones de

cambios de la infraestructura y los servicios.

Gestión de configuraciones: proceso de planificación, identificación, control y

verificación de los elementos de configuración, que componen la infraestructura.

Gestión de incidencias: proceso de gestión cuyo objetivo es restablecer un servicio

operativo tan rápidamente como sea posible, minimizando el impacto en la empresa y
asegurando que se mantienen los niveles de servicio y disponibilidad acordados.

Gestión de las crisis: proceso de estimación de los impactos como consecuencia de un

error grave e identificación de los modos de acción que permitan sobrevivir.

Gestión de problemas: proceso de gestión cuyo objetivo es minimizar el impacto sobre la

empresa de las incidencias y problemas que provienen de errores de la infraestructura, y
prevenir la aparición de incidencias, problemas y errores de manera proactiva.

Gestión de riesgos: actividad de identificación de los riesgos que puedan afectar a la

empresa y de identificación de las contramedidas adoptadas y justificadas, desde un punto
de vista financiero.

Gestión financiera: proceso responsable de la presupuestación, contabilidad y facturación

de los servicios informáticos.

Histórico de cambios: información 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.

Imputación: asignación de los costes de producción de los servicios informáticos, con

vistas a su imputación a uno o varios clientes en forma de facturación 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
alteración de la calidad de los servicios y de la productividad del cliente.
Infraestructura: agrupa el conjunto de componentes (elementos de configuración) que se
usan en el suministro de los servicios informáticos y de telecomunicación a los usuarios
(hardware informático y de telecomunicaciones, software, oficinal, personal,
documentación...).

Interfaz: relación de interacción física o funcional entre los elementos de configuración.

Mantenimiento de los servicios: agrupamiento lógico dentro del repositorio ITIL de los
cinco procesos de gestión de configuraciones, incidencias, problemas, cambios y
actualizaciones.

Medida de reducción de riesgo: medida adoptada para reducir la probabilidad o las

consecuencias de la aparición de un error en las actividades de la empresa.

Mejora continua: principio según el cual todos los aspectos del suministro y
mantenimiento de los servicios se reevalúan regularmente, para identificar las mejoras
potenciales, sobre todo en términos de eficacia. Este principio se basa en la Rueda de
Deming.

Métricas de disponibilidad informática: conjunto de métricas que se usan para medir la

disponibilidad, fiabilidad, mantenibilidad y el tiempo de respuesta de los servicios
informáticos.

Modelo de coste: reparto de los costes de producción de los servicios informáticos, 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
informáticos que se proporcionan al cliente.

Modelo de incidencia: conjunto estructurado de preguntas empleadas por el personal del

centro de servicios para permitir la resolución rápida o la asignación precisa de las
incidencias. El personal técnico mantiene y proporciona escenarios de diagnóstico como
una de sus responsabilidades dentro del proceso de la gestión de las incidencias.

Objetivo de continuidad del negocio: definición del detalle y perímetro de recuperación

de la actividad después un error grave, incluyendo personal, infraestructuras y servicios.

Objetivos de negocio: objetivos medibles, elaborados con el objetivo de ayudar a la

realización de la estrategia de la empresa.

Objetivos de nivel de servicios: equivalente al documento de especificaciones de un

servicio, este documento corresponde a la expresión de las necesidades de los clientes de
la organización TI, en términos de servicio.

Organización: estructura que corresponde a la dimensión organizacional. Puede ser el

servicio informático, como entidad específica de la empresa.

Periodo de convivencia del servicio: horario de disponibilidad acordado en el SLA de un

servicio informático.

Periodo de no disponibilidad: periodo situado en los horarios de servicio acordados

durante el que el servicio no está operativo.
Petición 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 informática.

Petición de servicio: petición de cambio menor que no afecta a la infraestructura y no

justifica la intervención del comité consultivo de cambios, como por ejemplo la modificación
de una contraseña o la instalación de un puesto de trabajo nuevo.

Plan: documento formal que describe los objetivos, la planificación 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 informáticos a diario, y también para tener una visión 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
críticas después de un error grave.

Plan de continuidad de los servicios: este plan describe las acciones y procedimientos
que la dirección informática debe seguir en caso de error grave, para retomar el suministro
de los servicios críticos 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
percepción 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 métodos, planificaciones y recursos

necesarios para implantar las actualizaciones en producción.

Plan de vuelta atrás: este plan describe las acciones que se tiene que tomar para
restablecer el servicio después de una actualización sin éxito.

Política de facturación: conjunto de reglas y decisiones de la empresa, respecto a la

facturación y cobro, que la dirección informática 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 producción al que se añade un margen equivalente a un

porcentaje de este coste.

Precio del mercado: precio idéntico 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.
Prestación: suministro de un bien o de un servicio a un cliente. En el contexto ITIL,
también hablamos de servicio.

Presupuestación: ciclo periódico de previsión, negociación y control de los gastos de la

organización informática.

Primer nivel de asistencia: recursos técnicos y de gestión presentes dentro del centro de
servicios que permiten resolver rápidamente 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 gestión 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 técnicas o jerárquicas.

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 informáticos.
Afecta a un proceso o servicio que suministra la organización TI.

Propietario del proceso: persona sobre la que recaen los acuerdos del proceso. Su
función es asegurar la eficacia de un proceso. Es responsable del diseño, la gestión de
cambios, la mejora continua del proceso y sus medidas.

Proveedor de servicios: organización 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 información.

Proveedor interno: unidad responsable del suministro de los servicios informáticos dentro
de la empresa, independientemente de su pertenencia efectiva a esta.

Pruebas de integración: pruebas realizadas en un entorno tan próximo como sea posible
al entorno de producción. El conjunto de componentes de hardware y software implicados
en un cambio se tienen que identificar para asegurar que funcionan correctamente en
conjunto.

Recuperación: operación de relanzamiento de la actividad como consecuencia de un fallo.

Esta operación agrupa las acciones de reparación y restauración de uno o varios elementos
de configuración o de un servicio.

Recuperación gradual: inicio en frío. Opción de la continuidad de los servicios

informáticos. La recuperación de la actividad de la empresa se hace en un plazo que puede
ser de hasta varios días después de un error grave.

Recuperación inmediata: inicio inmediato. Opción de la continuidad de los servicios

informáticos. La recuperación de los servicios es instantánea o casi inmediata (menos de
24 horas) en el caso de un error grave.
Recuperación intermedia: inicio intermedio. Opción de la continuidad de los servicios
informáticos. La recuperación de los servicios es rápida (entre 24 y 72 horas) en caso de un
error grave.

Redundancia: método que se usa para eliminar los puntos de debilidad únicos, mediante
la duplicación de los elementos de configuración (CI), cuya no disponibilidad puede
perturbar la actividad del servicio.

Registro: información individual o compuesta contenida en una base de datos.

Registro de actualización: registro que contiene la información de la historia de una

actualización, así como de los elementos de configuración a los que afecta.

Registro de cambio: registro que contiene la información de un cambio, junto con los
diferentes componentes a los que afecta.

Registro de cambios: lista exhaustiva que agrupa la información de las peticiones de

cambio (evaluación, pruebas, decisiones, estado actual...).

Registro de error conocido: registro que contiene la información y el histórico de un

error conocido.

Registro de incidencia: registro que contiene la información y el histórico de una

incidencia.

Registro de problema: registro que contiene la información y la historia de un problema.

Relación: interdependencia o conexión entre los componentes de la infraestructura, los

servicios o los procesos de la dirección informática. 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.

Restauración del servicio: actividad de puesta a disposición de los usuarios de un

servicio o de los datos imprescindibles para su trabajo.

Revisión postimplementación: reunión de evaluación de un cambio después de su

implementación para determinar si se ha implementado con éxito y si se obtienen los
beneficios previstos.

Riesgo: evaluación de la probabilidad de que una perturbación se produzca y haya

pérdidas potenciales como resultado de ella.

Segundo nivel de asistencia: agrupa las personas que tienen competencias técnicas
avanzadas, implicadas en la gestión 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
organización o una prestación.

Solución de seguridad: hardware, software y procedimientos aplicados para asegurar la

disponibilidad de los componentes de la infraestructura que sufren un fallo.
Solución temporal: solución provisional que permite recuperar el servicio en las
condiciones lo más cercanas posible a un funcionamiento normal.

Tarificación: elaboración de la política tarifaria y establecimiento de las tasas de

facturación que se aplicarán a los clientes.

Tasa de resolución de primer contacto: proporción 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 facturación de los servicios informáticos en el que los precios
propuestos son comparables a los de otras organizaciones parecidas.

Tecnología de la información y las comunicaciones (TIC): conjunto de tecnologías de

tratamiento y transferencia de datos, según las instrucciones programadas, para extraer
resultados. Incluye la información de tipo texto, imagen, vídeo, sonido...

Tipo de coste: los componentes de los servicios informáticos se clasifican por un tipo de
componente como hardware, software, personal, instalación, servicio externo... Esto
permite elaborar un modelo de coste.

Tipo de llamada: todas las llamadas recibidas en el centro de servicios se clasifican según
su tipo. Este tipo se puede definir en función de su asunto, destino, importancia...
(ejemplo: incidencia, consulta, petición de servicio, queja...).

Tolerancia a las averías: capacidad de un servicio o un sistema para continuar su

actividad cuando se produce un error. Ver también Resistencia.

Tratamiento de los errores: actividad que elabora una solución que permite resolver un
error conocido (la causa), pasando eventualmente por una petición de cambio en la
infraestructura.

Tratamiento de los problemas: actividad que identifica la causa de un probl