GestiondeServiciosTI ITIL PDF

Contenidos
SERVICIO DE ENTREGA
INTRODUCCIN
1.
INTRODUCCIN
10.
1
2.
2.1.
2.2.
2.3.
GESTIN DE SERVICIOS IT-FUNDAMENTOS 3

Servicios y calidad
3
Organizacin y polticas
9
Gestin de procesos
14
3.
3.1.
3.2.
3.3.
INTRODUCCIN A ITIL
Fundamentos
Organizaciones
Los libros de ITIL
19
19
20
22
SERVICIOS DE SOPORTE
4.
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
GESTIN DE INCIDENTES
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
31
31
34
35
37
40
42
5.
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
GESTIN DE PROBLEMAS
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
43
43
44
45
47
51
53
6.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
GESTIN DE CONFIGURACIONES
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
55
55
57
58
56
65
66
7.
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
GESTIN DE CAMBIOS
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
69
69
71
71
74
75
81
8.
8.1.
8.2.
8.3.
8.4.
8.5.
GESTIN DE VERSIONES
Introduccin
Objetivo
El proceso
Actividades
Costes y problemas
83
83
87
87
89
93
9.
9.1.
9.2.
9.3.
9.4.
9.5.
CENTRO DE SERVICIOS
Introduccin
Objetivo
Estructura
Actividades
Efectividad
95
95
96
96
100
101
10.1.
10.2.
10.3.
10.4.
10.5.
10.6.
11.
11.1.
11.2.
11.3.
11.4.
11.5.
11.6.
GESTIN DE
NIVELES DE SERVICIO
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
103
103
105
105
108
113
114
GESTIN FINANCIERA DE
LOS SERVICIOS TI
Introduccin
Objetivo
El proceso
Actividades
Control del proceso
Costes y problemas
115
115
117
118
120
123
124
12.
GESTIN DE LA CAPACIDAD
12.1. Introduccin
12.2. Objetivo
12.3. El proceso
12.4.Actividades
12.5.Control del proceso
12.6.Costes y problemas
125
125
125
126
128
131
132
13. GESTIN DE LA CONTINUIDAD

13.1.Introduccin
13.2.Objetivo
13.3.El proceso
13.4.Actividades
133
133
133
134
135
141
142
14. GESTIN DE LA DISPONIBILIDAD

14.1.Introduccin
14.2.Objetivo
14.3.El proceso
14.4.Actividades
143
143
144
146
147
147
155
15. GESTIN DE LA SEGURIDAD

15.1.Introduccin
15.2.Objetivo
15.3.El proceso
15.4.Actividades
157
157
157
158
165
168
169
16. ESTUDIO DE CASO Quick Couriers

171
16.1.
Gestin de configuraciones
172
16.2.
Gestin de incidentes y centros de servicio 173
16.3.
Gestin de problemas
174
16.4.
Gestin de cambios
175
16.5.
Gestin de versiones
176
16.6.
Gestin de disponibilidad
177
16.7.
Gestin de la capacidad
178
16.8.
Gestin de la continuidad de
servicios de TI
179
16.9.
Gestin Financiera
180
16.10.
Gestin de niveles de servicio
181
Gestin de Servicios TI basado en ITIL
Captulo 1:
Introduccin
Hace unas dcadas que los desarrollos de las TI vienen provocando un gran impacto en los procesos del
negocio. La introduccin del PC y de las tecnologas LAN, cliente/servidor e Internet ha permitido que las
organizaciones lleven sus productos al mercado de una forma mas rpida y con mayor eficiencia. Estos
desarrollos han marcado la transicin de la era industrial a la de la informacin. Las organizaciones
jerrquicas tradicionales tienen dificultades para adaptarse a mercados en constante cambio, lo que ha
marcado una tendencia hacia organizaciones menos jerrquicas y ms flexibles. De igual manera, dentro de
las organizaciones se ha puesto nfasis en cambiar de funciones verticales o departamentos a procesos
horizontales que se extienden a travs de toda la organizacin, y se le otorga a personal de menor nivel la
autoridad para tomar decisiones. Teniendo en cuenta estos aspectos bsicos se desarrollaron los procesos
operativos de la Gestin de Servicios TI.
En los aos 80, la calidad de los servicios TI que prestaba el gobierno britnico era tal que se instruy a la por
entonces CCTA (Agenda Central de Telecomunicaciones y Computacin, hoy Ministerio de Comercio, OGC)
para que desarrollara una propuesta con el fin de que los ministerios y dems oficinas del sector pblico de
Gran Bretaa utilizaran de manera eficaz y con eficiencia de costes los recursos TI. El objetivo era desarrollar
una propuesta sin compromisos con proveedor alguno. Esto dio como resultado la Information Technology
Infrastructure Library (ITIL). ITIL1 naci de una coleccin de las mejores prcticas observadas en el
sector de servicios TI.
ITIL proporciona una descripcin detallada de una serie de buenas prcticas de TI, a travs de una amplia lista
de roles, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organizacin de TI. En
algunos casos se han definido las buenas prcticas como procesos que cubren las actividades ms importantes
de las organizaciones de servicios de TI. La vasta cantidad de temas cubiertos por las publicaciones convierte
ITIL en un elemento de referencia til para fijar nuevos objetivos de mejora para la organizacin de TI. La
organizacin puede as crecer y madurar con ellos.
Basndose en ITIL se han desarrollado varios sistemas para la Gestin de Servicios TI, generalmente
organizaciones del negocio. Los ejemplos incluyen Hewlett & Packard (HP ITSM modelo de referencia),
IBM (TI Modelo de Proceso), Microsoft (MOF) y muchos otros. Esta es una de las razones por las que ITIL
se ha convertido en el estndar de facto para describir varios procesos fundamentales de la Gestin de
Servicios TI. Esta adopcin y adaptaciones de ITIL reflejan la propia filosofa de ITIL, y son desarrollos bien
venidos para que ITIL se transforme en el tan necesario orden metodolgico imprescindible para los actuales
entornos heterogneos y distribuidos de TI.
La falta de una gua bsica, introductoria y orientada al auto aprendizaje ha puesto trabas a la adopcin
general de ITIL. EI material proporcionado en los cursos de ITIL es a menudo demasiado escaso porque se
elaboran especficamente para cada curso. Esta publicacin esta dirigida a cualquier persona involucrada en la
Gestin de Servicios TI o interesada en el tema. Dado que el colectivo al que apuntamos es muy amplio, el
Forum de Gestin de Servicios TI (itSMF) resulta el canal perfecto para la industria como organizacin sin
fines de lucro. Los objetivos del itSMF y de esta publicacin son compatibles.
La declaracin de misin del itSMF es la siguiente:
El objetivo del ITSMF es promover experiencia y buenas prcticas actuales de la Gestin de Servicios TI,
como organizacin independiente, sin fines de lucro. ITSMF para ello organiza conferencias, publica una
revista, establece grupos de trabajo, y edita publicaciones. ITSMF tambin tiene como objetivo ampliar su
1
ITIL. es una marca registrada de CCTA/OGC
Introduccin
nmero de miembros.
Como corresponde, la declaracin del ITSMF con respecto a este libro es:
Hacer accesible a una audiencia mas amplia la experiencia de la Gestin de Servicios TI.
As, los objetivos de este libro son:
1.
2.
3.
4.
Contribuir a conseguir la misin del itSMF publicando un libro de referencia prctico y accesible sobre
gestin de servicios TI, que tambin se pueda utilizar para preparar los exmenes de ITIL.
Adoptar ITIL como el marco de referencia estndar y comn para el libro.
Estar actualizado con los nuevos trminos, experiencia y mtodos relevantes que hagan ms accesible la
Gestin de Servicios TI, y publicar nuevas ediciones regularmente.
Asegurar que el texto es independiente haciendo caso omiso de las publicaciones comerciales.
Dado el rpido desarrollo en este campo, los libros de ITIL no siempre pueden describir los ltimos avances.
ITIL es en primera instancia una coleccin de buenas prcticas desarrolladas en la industria, y la teora y la
prctica no siempre van a la par. Cuando escribimos este libro tratamos de incorporar los progresos actuales
del campo de las TI, sin desviarnos considerablemente de las publicaciones de ITIL. De esta manera, se puede
utilizar el libro como gua de auto-estudio para prepararse para los exmenes oficiales de ITIL, y como
introduccin general a reas ms amplias de la Gestin de Servicios TI. Esta publicacin no se dirige a la
planificacin y la implementacin en profundidad de los procesos de ITIL.
En el captulo 2 "Fundamentos de la Gestin de Servicios TI", sin embargo, se mencionan de forma general
los temas relacionados con la Gestin de Servicios TI, en trminos de calidad, procesos y polticas.
La primera edicin de este libro esta basada en una publicacin itSMF de Holanda, creada como introduccin
a la Gestin de Servicios TI. Ese trabajo se basaba en resmenes y descripciones de publicaciones ITIL,
autorizados por la OGC. Un gran nmero de auditores de distintos miembros del itSMF audit una edicin
global. Karen Ferris, KMF Advance, y Graham Kennedy, Pro-Active Service P/L realizaron la revisin inicial
de la edicin australiana en enero del 2002. La revisin posterior en mayo 2002 fue hecha por Karen Ferris.
Dado el deseo de un amplio consenso en el campo de ITIL, son bienvenidos nuevos desarrollos, material
adicional y contribuciones de profesionales de ITIL. Los editores discutirn los contenidos y los incorporarn
si corresponde a las nuevas ediciones.
Jan van Bon
Redactor jefe
Abril 2004
Si tiene algn comentario sobre este documento por favor envelo a los editores de "Gestin de Servicios TI,
una introduccin a ITIL", c/o Inform-IT, P.O. Box 23. 9841 PA Grijpskerk, the Netherlands, e-mail:
jvbon@wxs.nl.
Captulo 2:
Gestin de Servicios TI fundamentos
Este captulo trata temas tales como gestin de servicios, calidad, organizacin, poltica y procesos. Estos
conceptos ofrecen un marco de referencia para el desarrollo de un acercamiento sistemtico a la Gestin
de Servicios TI.
Los procesos de Gestin de Servicios TI descritos en este libro (tambin nombrados como Gestin TI) se
comprenden mejor al analizarlos bajo la perspectiva de los conceptos sobre organizaciones, calidad y
servicios que influenciaron el desarrollo de la metodologa. La familiaridad con estos trminos tambin ayuda
a comprender los vnculos entre los diferentes elementos de la IT Infrastructure Library (ITIL). ITIL es la
mejor descripcin conocida de Gestin de Servicios TI y es, por lo tanto, utilizada como base para este libro.
En este capitulo se introducen los siguientes temas:
Servicios y calidad - esta seccin trata la relacin entre la experiencia de calidad de los clientes de la
empresa y los usuarios, y la gestin de calidad del proveedor de servicios TI.
Organizacin y polticas - esta seccin trata conceptos tales como visin, objetivos y polticas y discuten
conceptos como planificacin, cultura corporativa y Gestin de Recursos Humanos. Tambin se discute la
coordinacin entre los procesos del negocio de una empresa y las actividades TI que los soportan.
Gestin de Procesos - esta seccin considera el control de los procesos relacionados con los Servicios TI.
2.1 Servicios y calidad

Las organizaciones a menudo son muy dependientes de sus servicios TI y no slo esperan que dichos
servicios TI proporcionen soporte a la organizacin sino que tambin aporten nuevas opciones para conseguir
los objetivos de la organizacin. Asimismo, las elevadas expectativas de los clientes de servicios TI tienden a
cambiar significativamente con el tiempo.
Los proveedores de servicios TI ya no pueden permitirse el lujo de centrarse en la tecnologa y en su
organizacin interna, sino que ahora deben considerar la calidad de los servicios que ofrecen y concentrarse
en la relacin con sus clientes.
La provisin de servicios TI implica la gestin total mantenimiento y operacin- de la infraestructura TI
Antes de comprar un producto, generalmente evaluamos su calidad tanto como su apariencia, su utilidad y
sus prestaciones. En general, el cliente tiene pocas oportunidades para influir sobre la calidad del producto.
Esto se debe a que ese producto ha sido desarrollado en una fbrica mediante un proceso sobre el que el
cliente no tiene control. Gestionando efectivamente la planta de produccin, el fabricante tratar por su parte
de entregar un producto de calidad constante. En este ejemplo, la fabricacin, las ventas y el consumo del
producto son procesos independientes.
Sin embargo, los servicios se proporcionan en relacin con el cliente. Los servicios no pueden evaluarse por
adelantado, sino slo una vez prestados. La calidad de un servicio depende cierta forma de la manera en la
que proveedor de servicio y su cliente interactan. A diferencia del proceso de fabricacin, el cliente y el
proveedor pueden realizar cambios cuando se est desarrollando y utilizando el servicio. La forma en la que el
cliente percibe el servicio y lo que el proveedor piensa que ofrece, dependen ampliamente de sus experiencias
personales y de sus expectativas.
El proceso de proveer un servicio es la combinacin de produccin y uso, en la que participan
simultneamente el proveedor y el cliente.
Gestin de Servicios TI - Fundamentos
La percepcin del cliente es esencial para la provisin de los servicios. Los clientes generalmente se harn las
siguientes preguntas para evaluar la calidad del servicio:
El servicio cumple con mis expectativas?
Puedo esperar un servicio similar la prxima vez?
Es razonable el coste del servicio?
Si el servicio cumple o no con las expectativas depende ante todo de cuan eficazmente se acordaron los
entregables con el cliente, ms que de la propia forma en la que se provee el servicio.
Un dialogo continuo con el cliente es esencial para refinar los servicios y asegurarse de que tanto el cliente
como el abastecedor sepan lo que se espera del servicio. En un restaurante, el camarero primero explicar el
men, y luego, al servir el plato, preguntar si es de su gusto. El camarero coordina activamente la oferta y la
demanda durante la comida. Y es esta experiencia con el cliente lo que se utiliza para mejorar el contacto
futuro con l.
La calidad de un servicio es la capacidad que tiene ste para satisfacer las necesidades y las expectativas del
cliente. Para poder proporcionar calidad, el abastecedor deber evaluar continuamente la forma en la que se
experimenta el servicio y lo que el cliente espera en el futuro. Lo que un cliente considera normal puede
resultar algo especial para otro, y sin embargo con el tiempo el cliente se acostumbrar a lo que consideraba
especial al principio. Los resultados de la evaluacin del servicio pueden utilizarse para determinar si este
debe ser modificado, si el cliente debe recibir ms informacin, o si es necesario cambiar el precio del
servicio.
La calidad es el conjunto de caractersticas de un producto o servicio que influyen en la satisfaccin de las
necesidades explicitas e implcitas (ISO-8402).
Los costes razonables pueden considerarse un requisito derivado. Una vez que se acord lo que se espera del
servicio, se debe convenir su coste. En este momento el proveedor del servicio debe ser consciente de los
costes en los que incurrir, y los valores actuales de mercado para servicios similares.
El proveedor de servicio que a veces exceda las expectativas y otras no las cumpla har que el cliente no se
sienta satisfecho. Proporcionar una calidad constante es uno de los aspectos ms importantes, si no el que
ms, de la industria de los servicios.
Por ejemplo, un restaurante tendr que comprar siempre ingredientes frescos, los chefs debern trabajar juntos
para proporcionar resultados constantes, y con suerte no existirn mayores diferencias de estilo entre el
personal de servicio. Un restaurante slo recibir la categora tres estrellas cuando consiga la misma calidad a
lo largo del tiempo. Este no siempre es el caso: hay cambios entre el personal de servicio, una oferta exitosa
puede terminarse pronto, y los chefs pueden irse para abrir sus propios restaurantes. Ofrecer alta calidad
constantemente tambin significa que el componente de las actividades debe estar coordinado: cuanto mejor y
ms eficaz sea la cocina, mas rpido se puede servir a los clientes.
As, cuando se presta un servicio, la calidad total es resultado del conjunto de procesos que forman integrados
el servicio. Estos procesos forman una cadena, y los eslabones se afectan unos a otros y a la calidad del
servicio. La coordinacin eficaz de los procesos no solo requiere proporcionar una calidad adecuada al llevar
a cabo cada proceso, sino tambin una calidad consistente.
2.1.1 Aseguramiento de la calidad

Suministrar productos o servicios requiere actividades. La calidad de un producto o servicio depende mucho
de la manera en la que se organizan estas actividades. El crculo de calidad de Deming (Figura 2.1) muestra
un modelo simple y eficaz para controlar la calidad. El modelo asume que para dar una calidad apropiada, se
deben seguir los siguientes pasos:
Planificar (Plan) - Qu se debe hacer, cundo, quin debe hacerlo, cmo, y utilizando qu?
Hacer (Do) - se llevan a cabo las actividades programadas.
Verificar (Act) - determinar si las actividades dan los resultados esperados.
Actuar (Check) - ajustar los planes basndose en la informacin recogida al comprobar.
Una intervencin eficaz y a tiempo significa que las actividades estn divididas en procesos con sus propios
planes y oportunidades para analizar. Debe estar claro quin es responsable en la organizacin y qu autoridad
tiene para cambiar planes y procedimientos, incluyendo actividades y procesos.
Figura 2.1. Circulo de Calidad de Deming
El Dr. Edward Deming fue un estadista estadounidense que el General Douglas MacArthur llev a Japn
para ayudar a la reconstruccin de la economa destruida tras la Segunda Guerra Mundial. El haba
desarrollado teoras sobre el posible uso de la experiencia y la creatividad en las organizaciones en los
EEUU en los aos 30, pero debido a la Depresin sus ideas no fueron tomadas en cuenta en ese pas. Sin
embargo, sus mtodos de optimizacin fueron utilizados con xito en Japn.
Algunas declaraciones tpicas de Deming:
'El cliente es la parte ms importante de la lnea de produccin'.

'Tener clientes satisfechos no es suficiente, la ganancia viene de los clientes que regresan y de
aquellos que hacen buenos comentarios de su producto o servicio a conocidos y amigos.'
'La clave de la calidad es reducir la variedad.'
Elimine las barreras entre los departamentos.'
'Los gestores deben aprender a tomar responsabilidades y a ser Lderes.'
'Mejorar constantemente.'
'Impartir un programa vigoroso de educacin y auto-superacin.'
'impartir capacitacin para el trabajo.'
'La transformacin es trabajo de todos.'

La Gestin de Calidad es responsabilidad de todos los que trabajan en la organizacin proveedora de
servicios. Cada empleado debe saber cmo su contribucin a la organizacin afecta a la calidad de trabajo
provista por sus colegas, y eventualmente al servicio que proporciona la organizacin.
La gestin de calidad tambin significa estar a la bsqueda de nuevas oportunidades todo el tiempo e
implementar mejoras en las actividades relacionadas con la calidad.
Aseguramiento de la calidad es un aspecto poltico dentro de la organizacin. Se refiere al conjunto de
medidas y procedimientos que utiliza la organizacin para asegurar que los servicios proporcionados
continan cumpliendo las expectativas del cliente y los acuerdos establecidos.
El compromiso de calidad garantiza que las mejoras originadas en la gestin de calidad se mantengan.
Un sistema de calidad es la estructura orgnica relacionada con responsabilidades, procedimientos y recursos
para implementar la gestin de calidad.
La serie de estndares ISO 9000 es la que se usa generalmente para desarrollar, evaluar y mejorar los sistemas
de calidad.
Estndar de calidad ISO 9000:
Algunas organizaciones exigen que sus abastecedores tengan el certificado ISO 9001 o ISO 9002. Dicho
certificado prueba que el abastecedor tiene un sistema de calidad adecuado y que un auditor independiente
evala su efectividad peridicamente.
ISO es la Organizacin Internacional para la Estandarizacin. El sistema de calidad que cumple con los
estndares ISO asegura al abastecedor que:
-
el abastecedor ha tornado medidas para poder proporcionar la calidad acordada a los clientes;
la gestin de calidad evala habitualmente la operacin del sistema de calidad, y utiliza los resultados
de las auditorias externas para implementar mejoras en el sistema si fuera necesario;
los procedimientos del abastecedor se encuentran documentados y se comunican a aquellos a quienes
afecta;
que las quejas de los clientes estn registradas, tratadas a su debido tiempo, y que se utilizan para
mejorar el servicio si es posible;
que el abastecedor controla los procesos de produccin y puede mejorarlos.
El certificado ISO no otorga una garanta absoluta sobre la calidad del servicio provisto; sin embargo,
indica que el abastecedor toma en serio el compromiso de calidad y que se encuentra listo para tomar
medidas al respecto.
La nueva serie de estndares ISO 9000, ISO-9000-2000, pone aun ms nfasis que el estndar anterior en
la capacidad de una organizacin para aprender de la experiencia y para implementar mejoras de calidad
continuas.
2.1.2 Madurez de organizacin

La experiencia en la mejora de calidad de los servicios TI ha demostrado que no es suficiente estructurar y
definir las prcticas actuales. El origen de las diferencias entre el servicio provisto y los requisitos del cliente
se relaciona generalmente con la forma en la que se gestiona la organizacin TI. Una mejora permanente de
calidad demanda una cierta madurez de la organizacin.
La Fundacin Europea para la Gestin de Calidad fue creada en 1988 por catorce grandes compaas
europeas, con el apoyo de la Comisin Europea.
El objetivo de la EFQM es promover la Gestin de Calidad Total, para distinguirse por la satisfaccin al
cliente, al empleado, contribuir a la mejora de la sociedad, y los resultados de rendimiento.
El "Modelo de Excelencia del Negocio de EFQM, ms conocido como el modelo EFQM, es ampliamente
aceptado como el mayor marco de trabajo estratgico para gestionar una organizacin que busque mejorar
equilibrada y continuamente todos los aspectos relacionados con el comercio. Ms de 600 empresas y
organizaciones de investigacin se han unido a EFQM. Para mayor informacin:
http://www.efqm.org/
El modelo de la Fundacin Europea para la Gestin de Calidad (EFQM) (Figura 2.2) puede resultar til para
determinar la madurez de una organizacin. Este modelo identifica las reas ms importantes a considerar
cuando se gestiona una organizacin.
El crculo de Calidad de Deming esta incorporado en el modelo EFQM. Las medidas (estrategia, polticas) se
toman basndose en los resultados de las diferentes reas. Estas medidas sirven para apoyar a la planificacin
(por ej. la estructura de los procesos) que debera conducir a los resultados deseados. El modelo EFQM
identifica nueve reas.
Figura 2.2Modelo EFQM
Como herramienta adicional, la organizacin holandesa de calidad, INK, dividi el modelo en etapas que
indican hasta que punto una empresa ha implementado la Gestin de Calidad Total, tanto en un rea en
particular, como en general.
Existen cinco etapas:
-
Orientada al producto - tambin conocida como ad hoc, orientada a la produccin; todo el mundo en la
organizacin trabaja mucho (pero sus esfuerzos no estn dirigidos).
Orientada al proceso - tambin conocida como "sabemos de qu se trata nuestro negocio", el
desempeo de la organizacin est planificado y es repetible.
Orientada al sistema - o "cooperacin entre departamentos".
Orientada a la cadena - tambin "sociedad externa"; la organizacin pone nfasis en el valor que agrega
a la cadena abastecedor-cliente de la que forma parte.
Orientada a la calidad total - o "el cielo en la tierra"; la organizacin ha llegado al nivel en el que el
ejercicio de una mejora continua y equilibrada ha adquirido el carcter de instintivo.
Las reas cubiertas en el modelo EFQM pueden combinarse con los niveles de madurez organizativa. Los
cuestionarios pueden utilizarse para determinar la madurez de la organizacin en las distintas reas. Los
auditores internos o externos pueden llevar a cabo tal valoracin,
Cuando una organizacin determina su madurez, puede desarrollar una estrategia para perfeccionarse y
transformarla despus en un plan. El plan, basado en el modelo y por un periodo de un ao, describe las
mejoras que deben hacerse en aspectos especficos de cada rea y caso. Al repetir este proceso de autoevaluacin y planificacin ao tras ao, la organizacin se percata de cmo esta madurando. Las mayores
ventajas de este planteamiento son que la organizacin puede mejorar su calidad paso a paso, que los
resultados intermedios son visibles, y que la direccin puede pilotar la organizacin segn su estrategia.
Adems del planteamiento de EFQM existen otros controles de salud y otros tipos de auto-evaluacin.
Algunos se centran principalmente en el mbito interno. Debemos recordar que las mejoras a las partes
internas de la organizacin pueden tener un efecto limitado sobre los resultados, por ejemplo si no mejora la
relacin con los clientes, la satisfaccin de los empleados y el liderazgo, o si la estrategia y la poltica de la
organizacin no estn claras.
En el sector de las TI, el proceso de mejora de la madurez mas conocido, es el Modelo de Madurez de
Capacidad (CMM). Este mtodo de mejora de proceso fue desarrollado por el Instituto de Ingeniera de
Software (SEI) de la Universidad de Carnegie Mellon. CMM tiene como objetivo mejorar la madurez del
proceso de creacin de software. CMM incluye los siguientes niveles;
-
Inicial - el proceso ocurre ad hoc.

Repetible - los procesos han sido diseados de manera tal que el servicio de calidad pueda repetirse.
Definido - los procesos han sido documentados, estandarizados e integrados.
Gestionado - la organizacin mide los resultados y utiliza esas medidas conscientemente para mejorar la
calidad de sus servicios.
ptimo - la organizacin optimiza conscientemente el diseo de sus procesos para mejorar la calidad de
sus servicios o para desarrollar nuevas tecnologas o servicios.
Los modelos de madurez basados en los niveles de CMM de madurez tambin han sido creados para la
Gestin de Servicios TI. Desarrollar y mantener un sistema de calidad que cumpla con los requisitos de la
norma ISO 9000 (ISO-9000-2000) puede ser considerado por la organizacin como la herramienta para
alcanzar y mantener el nivel de madurez orientado al sistema (o "gestionado" en el CMM de Servicio TI).Esos
estndares ISO hacen hincapi en la definicin, descripcin y diseo de los procesos.
Cuando se evala la madurez de una organizacin no podemos restringirnos al proveedor del servicio. El
nivel de madurez del cliente (Figura 2.3) tambin es importante. Si existen grandes diferencias entre el
abastecedor y el cliente, entonces estas debern ser consideradas para evitar un error en el planteamiento, los
mtodos y las expectativas mutuas. En concreto, esto afecta a la comunicacin entre el cliente y el
abastecedor. Es aconsejable que ambas organizaciones tengan el mismo nivel de desarrollo para operar a
ese nivel, o para ajustar la comunicacin en lnea con el nivel mas bajo.
Figura 2.3 Niveles de Comunicacin y madurez: cliente y proveedor
2.2 Organizacin y polticas

Las secciones anteriores ilustran claramente que la calidad de servicio se encuentra en franca asociacin con
la calidad de una organizacin y sus polticas. Esta seccin tratar otros aspectos importantes de la
organizacin y polticas que son relevantes a la gestin de procesos.
2.2.1 Visin, objetivos y polticas

Una organizacin es una forma de cooperacin entre personas. Cualquier organizacin, desde un club de
petanca hasta una empresa multinacional, depende del concepto de por qu vale la pena cooperar con la
organizacin. Esta visin puede ser poder ganar dinero vendiendo PCs. Sin embargo, para resultar atractivo
para los stakeholders (p. ej. clientes, inversionistas, personal) su organizacin tendr que comunicar por qu
deberan hacer negocios con usted, por ejemplo porque usted es el mejor, el mas barato o el mas gracioso. De
esta manera, usted querr elaborar una imagen acorde. Para comunicar su visin, se puede definir a la
organizacin a travs de la Declaracin de Misin (Figura 2.4). La declaracin de misin es una descripcin
breve y clara de los objetivos de la organizacin y los valores en los que cree.
Los objetivos de la organizacin describen en detalle lo que desea conseguir. Los buenos objetivos tienen
cinco elementos fundan en tales: deben ser Singulares, Medibles, Adecuados, Realistas, y ligados al Tiempo
(SMART).
La poltica de la organizacin es la combinacin de todas las decisiones y medidas tomadas para definir y
conseguir los objetivos. En tales polticas, la organizacin priorizar los objetivos y decidir cmo se
consiguen los mismos. Por supuesto, las prioridades pueden cambiar con el tiempo, segn las circunstancias.
Cuanto ms claras sean las polticas de la organizacin para todos los stakeholders, menor necesidad de
definir de qu manera el personal debe hacer su trabajo. En vez de utilizar procedimientos detallados, el
personal puede guiarse con las polticas de manera independiente. Las polticas que se formulan con claridad
contribuyen a crear una organizacin flexible, ya que todos los niveles de la organizacin pueden responder
con mayor rapidez a las circunstancias cambiantes.
Figura 2.4 Visin, objetivos y polticas
La planificacin es necesaria para implementar las polticas en forma de actividades especficas. Los planes
estn a menudo divididos en etapas para fijar hitos que sirvan para monitorizar su progreso. Por ejemplo, se
pueden usar las polticas para disear un plan anual, que se utilizar luego para desarrollar los presupuestos.
Un plan anual puede hacerse ms detallado para un departamento, un proyecto, o un trimestre. Cada uno de
estos planes contiene un nmero de elementos: un programa de actividad, los recursos necesarios, y acuerdos
sobre la calidad y cantidad de los productos o servicios a suministrar.

Para realizar las actividades planeadas es precisa la accin. Las acciones son asignadas al personal como
tareas, o cedidas a organizaciones externas.
Cuando se traduce la misin de la organizacin en objetivos, polticas, planificacin y tareas, existe el riesgo
de que despus de un tiempo la misin, los objetivos o las polticas se olviden. Por tal razn es importante que
a cada paso se mida si la organizacin todava se esta moviendo en la direccin correcta, y se tomen acciones
correctivas si fuera necesario.
As, debemos evaluar si la organizacin y los procesos cumplen con los objetivos, y para ello existen varios
mtodos. Uno de los mtodos del negocio ms comunes es la Cuadro de Mando Integral o Balanced Score
Card (BSC). En este mtodo, los objetivos de la organizacin o los procesos se utilizan para definir Factores
Crticos de xito (CSF). Los CSFs estn definidos segn reas de inters o perspectivas: clientes/mercado,
procesos del negocio, personal/innovacin y finanzas. Los parmetros determinados para medir si los CFSs
cumplen con los estndares se conocen como Indicadores Clave de Rendimiento (KPI). Si es necesario se
pueden subdividir en Indicadores de Rendimiento (PI).
Los Indicadores Clave de Rendimiento, o KPIs, son parmetros para medir el progreso relativo con relacin
a los objetivos principales o Factores Crticos de xito (CSF) en la organizacin.
El resultado de las mediciones y las circunstancias cambiantes pueden llevar a la modificacin de los
procesos, tareas, planes, y polticas, y hasta a un cambio en los objetivos, la misin y la visin de la
organizacin. Cuando mas madura es una organizacin, ms fcil le resultar hacer frente a tales cambios.
Si el departamento TI soporta los intereses del negocio, los objetivos del departamento TI derivarn de los
objetivos del negocio. El departamento TI, por ejemplo, puede tener este objetivo: "Contribuir a la fuerza
competitiva del negocio". Los objetivos especficos del departamento TI se desarrollarn as con base en este
objetivo general. Segn la naturaleza del negocio, los objetivos del departamento TI sern definidos tomando
en cuenta aspectos de seguridad, accesibilidad, tiempo de respuesta, sofisticacin tcnica, y otras
consideraciones.
2.2.2 Horizonte de planificacin

Cuando se consideran las polticas y la planificacin del departamento TI, debemos ser conscientes de los
lazos entre la planificacin global del negocio, los sistemas de aplicacin y la infraestructura tcnica. Cuando
planeamos la red y las aplicaciones del negocio, el departamento de TI deber estar ms all de una
planificacin a corto plazo para garantizar que el negocio tenga una infraestructura TI en la que desarrollarse
en el momento actual y en el futuro.
La Figura 2.5 muestra un ejemplo de las relaciones entre los diferentes planes.
Figura 2.5 Horizonte de planeamiento
10

La infraestructura tcnica tiene un amplio horizonte de planificacin y su papel de soporte contiene menos
vnculos claros con las actividades esenciales del negocio. Lleva tiempo desarrollar la infraestructura tcnica,
y el hecho de que los sistemas de informacin y los negocios dependan de la infraestructura tcnica limita la
velocidad con la que pueden implementarse los cambios.
Adems, la creacin de una infraestructura tecnolgica demanda una inversin considerable y se debe tener
en cuenta el tiempo de depreciacin.
El horizonte de planificacin es ms corto para las aplicaciones ya que son diseadas con intenciones
claramente de negocio. Para poner en prctica la planificacin del ciclo de vida de las aplicaciones lo primero
que debe considerarse son las funciones del negocio que proveer el sistema, tras lo cual se encuentra la
tecnologa fundamental.
Los planes del negocio, basados en la estrategia de la organizacin, cubren por lo general un ao natural o
financiero. Durante este periodo se elaboran el presupuesto, los informes de planificacin y de progreso. En
algunos sectores se ha acortado el tiempo del ciclo de planificacin porque los ciclos de desarrollo de los
productos tambin se han reducido.
La planificacin debe consignar cuatro elementos:
-
Tiempo - es el factor ms fcil de determinar. Lo define la fecha de comienzo y de finalizacin, y se

divide a menudo en etapas.
Cantidad - los objetivos deben ser medibles para monitorizar el progreso. Trminos tales como 'mejor' y
'ms rpido' resultan insuficientes para los fines de la planificacin.
Calidad - la calidad de los entregables (resultados) deben ser los apropiados para el objetivo.
Costes e ingresos - los resultados deben coincidir con los costes, esfuerzos e ingresos esperados.
La diferencia en las perspectivas de planificacin se da entre reas, y tambin entre los diferentes niveles de
actividades y procesos (estratgico, tctico y operativo). Este tema ser analizado con mayor profundidad ms
adelante.
2.2.3 Cultura
Las organizaciones que desean cambiar, por ejemplo mejorando la calidad de sus servicios, se enfrentarn a
la larga con la cultura de la organizacin. La cultura de la organizacin, o cultura corporativa, se refiere a la
forma en la que las personas se relacionan unas con otras dentro de la organizacin; la manera en la que se
toman y se llevan a cabo las decisiones; y la actitud de los empleados para con su trabajo, los clientes,
abastecedores, superiores y colegas.
La cultura, que depende de los estndares y valores del personal de la organizacin no puede controlarse, pero
si influenciarse. Influenciar la cultura de una organizacin supone liderazgo en forma de una poltica clara y
consistente y de una poltica de personal que le d soporte.
La cultura corporativa puede tener gran influencia en la provisin de servicios TI. Los negocios valoran la
innovacin de diferentes formas. En una organizacin estable, donde la cultura d poco valor a la innovacin,
puede resultar difcil ajustar sus servicios TI a los cambios en la organizacin del cliente. Si el departamento
TI es inestable, una cultura que valora el cambio puede plantear una seria amenaza a la calidad de sus
servicios. En tal caso, se puede producir la liberacin completa, donde muchos cambios sin control producen
gran cantidad de fallos.
2.2.4 Gestin de Recursos Humanos

La poltica de personal tiene un papel importante y fundamental en la consecucin de objetivos a largo plazo
de una organizacin (ver tambin el modelo EFQM). Tambin se puede utilizar para cambiar la poltica
corporativa. El objetivo de la actual gestin de recursos humanos es optimizar el rendimiento de todo el
personal de la organizacin, para lo cual se usan todos los instrumentos disponibles: incorporacin y
seleccin, capacitacin y desarrollo profesional, motivacin y gratificacin.
11

La Gestin de Recursos Humanos (HRM) es la cumbre de la gestin de personal moderna. La Gestin de
Recursos Humanos esta basada en dos premisas:
-
La gestin de personal debe contribuir a los objetivos de la organizacin. Si las organizaciones tienen que
responder mejor y con mayor rapidez en un ambiente que cambia cada vez ms rpido, esto afectar al
despliegue, la calidad y el volumen de personal.
Ofrecer a los empleados la posibilidad de desarrollar y utilizar sus habilidades beneficiar a la

organizacin.
Hay tres planteamientos para la HRM:

-
El planteamiento firme entiende a los recursos humanos como un medio de produccin que debe ser
organizado lo ms eficiente y eficazmente posible. Como la estrategia corporativa esta determinada por
factores econmicos, tcnicos y de mercado, lo mismo se aplica a la poltica de personal. Este
planteamiento otorga diferentes valores a los empleados. Los empleados fundamentales son
estratgicamente ms importantes que los perifricos los cuales pueden ser reemplazados con facilidad.
Por ejemplo, una empresa puede decidir contratar slo personal fundamental en forma permanente, y para
el resto utilizar una agencia de contratacin.
El planteamiento flexible considera que el negocio se ver beneficiado al hacer el mejor uso posible del
potencial humano y de las oportunidades. Los empleados de hoy en da estn muy capacitados, son muy
ambiciosos y estn preparados para hacer una gran inversin en su trabajo. Por tal razn, su potencial
debe identificarse de antemano considerando la necesidad de un desarrollo continuo (desarrollo
profesional, poltica de capacitacin). Cuando se selecciona la estrategia y la poltica, el negocio debe
basar su decisin en el talento y el potencial de sus empleados.
El planteamiento integral toma en cuenta los intereses compartidos del personal y la direccin de la
organizacin. Para conseguir los objetivos de la organizacin tendr que existir buena entrada, buen
movimiento y flujo de personal. Los cambios en el mercado y en la organizacin (p. ej. los desarrollos
tecnolgicos) provocan cambios constantes en las habilidades requeridas.
Todos los aspectos relacionados con la poltica de personal deben ser minuciosamente coordinados. La
dinmica de los empleados dentro de la organizacin, las habilidades determinantes y a desarrollar
(competencia), y la promocin en el mercado laboral interno se estn convirtiendo cada vez ms en factores
de importancia dentro de la organizacin.
La calidad de servicio que brinda una organizacin se beneficiar de un mejor uso del potencial de sus
empleados. Esto facilita el progreso constante. Los instrumentos para la gestin de calidad en la poltica de
personal incluyen:
-
12
El despliegue de la poltica - comunicar a cada empleado cmo y hasta qu punto su tarea contribuye a
hacer realidad los objetivos de la organizacin. Para lograr el xito es condicin importante extender el
despliegue a todas las capas de la gestin.
Autorizacin - dar a los empleados la oportunidad de organizar e implementar sus tareas de acuerdo con
la organizacin. El grado de autorizacin determina hasta que punto se puede hacer responsables a los
empleados por la calidad de trabajo que ofrecen.
Responsabilidad - como resultado de la poltica de despliegue y autorizacin. Si se explic a un
empleado lo que se espera de l, y si se le brind la oportunidad de preparar y llevar a cabo la tarea como
lo deseaba, entonces debe hacerse responsable de ello. Esto puede ser tomado como base de evaluacin y
gratificacin para los empleados. La gratificacin puede ser material (salario) o inmaterial, por ejemplo
ascenso, nuevas oportunidades para desarrollarse y oportunidades profesionales.
Gestin de competencias - esto incluye el uso eficaz de las competencias disponible en la organizacin,
y una forma sistemtica de desarrollar las competencias que necesita la misma. Este planteamiento define
y monitoriza las competencias que necesitan los procesos y los proyectos as como las competencias de
los empleados. Al organizar a los empleados la clave es, adems de la obtencin de un buen nexo entre

las competencias necesarias y las disponibles, las oportunidades de crear competencias, transferir
experiencia y aprender habilidades. Los mentores o los entrenadores pueden ayudar a los empleados.
Establecer grupos de habilidades tambin puede ayudar al intercambio de experiencia y a fomentar el
desarrollo de nuevas competencias.
2.2.5 Gestin de Relaciones con el Cliente TI
La calidad de los servicios TI depende ampliamente de la buena relacin con los clientes de la organizacin
TI. Estas relaciones sientan la base para establecer y actualizar los acuerdos. La Gestin de Relaciones con el
Cliente TI es la encargada de mantener la relacin con los clientes y de coordinar a nivel estratgico, tctico y
operativo con las organizaciones de clientes. La Figura 2.6, muestra un diagrama de las relaciones con el
cliente, ilustra la comunicacin horizontal que se da entre los clientes y la organizacin TI, con respecto al
soporte y a la coordinacin. La comunicacin vertical tiene relacin con las polticas, el control y la
generacin de informes.
Figura 2.6 Gestin de Relaciones con el Cliente
En la Gestin de Relaciones con el Cliente TI, el mayor desafo es asegurar que existan relaciones buenas y
eficaces a todo nivel entre la organizacin TI y la del cliente. Sin embargo, la magnitud de la Gestin de
Relaciones con el Cliente TI ser diferente segn los niveles. Uno de los elementos en las relaciones con el
cliente es el Centro de Servicios, y el control de los Niveles de Servicio se puede basar en la Gestin de
Niveles de Servicio. En estas reas, la Gestin de Relaciones con el Cliente TI representara, principalmente,
un papel de soporte organizando, por ejemplo, encuestas entre los clientes y los usuarios, proporcionando
informacin, etc.
El usuario es la "mano sobre el teclado ", el empleado que utiliza los servicios TI para sus actividades
habituales.
El cliente es aquel que "paga la cuenta", la persona autorizada para dar por finalizado el acuerdo sobre los
servicios con la organizacin TI (por ejemplo un Acuerdo de Nivel de Servicio, 0 SLA) y responsable de
abonar los servicios TI.
Obviamente el cliente "que paga la cuenta" tambin puede ser el usuario de las "manos sobre el teclado" en
muchas oportunidades.
La Gestin de Relaciones con el Cliente TI representa un papel muy importante en el desarrollo del
Alineamiento Estratgico entre la organizacin TI y la organizacin que compra de servicios TI. En la
prctica, esto consiste principalmente en mantenerse en contacto con la organizacin de clientes, y explorar
las opciones para aunar los objetivos estratgicos de ambas organizaciones. sta puede ser la base de una
13

relacin a largo plazo, en la que la organizacin TI se centra en el cliente y propone soluciones que le ayuden
a lograr sus objetivos del negocio. Dada la naturaleza dinmica de la organizacin de clientes y de la
organizacin TI, tambin debe coordinarse las consecuencias de los cambios en ambas organizaciones.
Los acuerdos con los clientes sobre los servicios provistos son especificados mediante propuestas de servicios
en la Gestin de Niveles de Servicio. Por ejemplo, si el cliente desea introducir una Intranet, entonces se debe
acordar la disponibilidad, el soporte a los usuarios, la implementacin de peticiones de cambio y el coste.
Tales acuerdos se formalizan en los Acuerdos de Nivel de Servicio (SLA).
Si la organizacin de clientes desea cambiar (expandir o modificar) servicios TI que se enmarcan dentro de
los acuerdos establecidos en el SLA, se deber generar una Petici6n de Cambio (RFC). La Gestin de
Cambios procesa despus esa peticin. Los cambios que estn ms all de los acuerdos actuales se incluyen
en el proceso de la Gestin de Niveles de Servicio.
En la mayora de los casos, los usuarios pueden contactar al Centro de Servicios (Service Desk) para consultar
tales peticiones y preguntas, y para informar sobre los problemas que aparecen.
La figura 2.6 muestra informacin sobre la comunicacin vertical y horizontal y sobre los horizontes de
planificacin de los procesos.
La coordinacin a nivel estratgico tiene un horizonte de planificacin de varios aos. La Gestin de Niveles
de Servicio se relaciona con los acuerdos a nivel tctico, con un horizonte de planificacin de por lo menos un
ao. La Gestin de Cambios, Centro de Servicios y la Gestin de Incidentes se ocupan del nivel de
operaciones, con un horizonte de planificacin de meses, semanas, das o hasta horas.
2.3 Gestin de Procesos

Todas las organizaciones se orientan a hacer realidad su visin, misin, objetivos y polticas, y para ello se
deben realizar las actividades correctas. Volvamos al ejemplo del restaurante, las actividades adecuadas
incluyen comprar alimentos, llevar la contabilidad, pedir material de publicidad, recibir a los invitados,
limpiar las mesas, pelar las patatas, y hacer caf.
Con una lista tan desordenada, algo se va a escapar y nos confundiremos fcilmente. Por tal motivo es una
buena idea estructurar las actividades. Sera preferible disponer de una lista de manera tal que podamos ver
como cada grupo de actividades contribuye a los objetivos del negocio, y como se relacionan.
Tales grupos de actividades se conocen como procesos. Si la estructura de procesos de una organizacin esta
claramente descripta, mostraran:
-
Qu debe hacerse.
Qu resultado se espera.
Cmo medimos si los procesos dan los resultados esperados.
Cmo los resultados de un proceso afectan a los de otros procesos.
Las preguntas de la Figura 2.7 surgen continuamente durante el planteamiento basado en el proceso de la
Gestin de Servicios TI. Las herramientas para responder a estas preguntas se encuentran a la derecha.
14
Figura 2.7 Modelo de mejora del proceso
2.3.1 Procesos
Cuando se organizan las actividades en procesos, no utilizamos la asignacin existente de tareas, ni las
divisiones departamentales existentes. Es una eleccin consciente. Al optar por una estructura de procesos,
podemos demostrar que ciertas actividades de la organizaci6n no estn coordinadas, estn duplicadas o que
estn descuidadas o son innecesarias.
Un proceso es una serie de actividades relacionadas lgicamente que conducen a definir un objetivo.
En todo caso miramos al objetivo de los procesos y las relaciones con los otros procesos. Un proceso es una
serie de actividades que se desarrollan para convertir una entrada en una salida (Figura 2.8). Podemos
asociar el consumo y la produccin de cada proceso con los estndares y las caractersticas de calidad para
proveer informacin sobre los resultados que deben obtenerse con los procesos. Esto produce una cadena de
procesos que muestra que pasa dentro de la organizacin y cuales son los resultados, y tambin los puntos de
monitorizacin de la cadena para controlar la calidad de los productos y los servicios brindados por la
organizacin.
Los estndares de produccin de cada proceso deben definirse para que la cadena completa de procesos
cumpla con los objetivos de la corporacin, si cada proceso se desempea de acuerdo con los estndares
definidos para ese proceso.
El proceso ser eficaz si el resultado del proceso se ajusta a los estndares definidos. En caso de que las
actividades del proceso tambin se desarrollen con el mnimo esfuerzo y costes necesarios, el proceso ser
eficiente. El propsito de la gestin de procesos es utilizar la planificacin y el control para garantizar que los
procesos sean eficaces y eficientes.
Es posible estudiar cada proceso por separado para optimizar su calidad. El propietario del proceso es
responsable de los resultados del mismo. El gestor del proceso es responsable de realizar y estructurar los
procesos, y de informar sobre ellos al propietario del proceso. Los operadores del proceso son responsables
de actividades especficas, y el gestor de procesos recibe informacin sobre estas actividades.
15
Figura 2.8 Diagrama de proceso
La combinacin lgica de las actividades da como resultado la clara transferencia de puntos en donde se
puede controlar la calidad de los procesos. En el ejemplo del restaurante, podemos separar la responsabilidad
de comprar y cocinar, para que los cocineros no tengan que comprar nada y no gasten demasiado en
ingredientes frescos que no agregan valor.
La direccin de la organizacin puede controlar teniendo en cuenta la calidad de los procesos segn los datos
de los resultados de cada proceso. En muchos casos, se debern acordar los indicadores de rendimiento
relevantes y los estndares. El control diario de los procesos puede ser dejado a cargo del gestor de procesos.
El propietario del proceso evaluar los resultados considerando el informe de los indicadores de rendimiento y
observando si cumplen con los estndares acordados.
Si los indicadores no son claros, el propietario del proceso tendr dificultades para determinar si los procesos
estn bajo control, y si se estn implementando las mejoras proyectadas.
Los procesos son descritos utilizando procedimientos e instrucciones de trabajo.
Un procedimiento es una descripcin de actividades lgicamente relacionadas, y de la persona que se
encarga de realizarlas. Un procedimiento puede incluir etapas de distintos procesos. Un procedimiento
define quien hace que cosa, y vara dependiendo de la organizacin.
Un grupo de instrucciones de trabajo delimita cmo se deben llevar a cabo una o ms actividades en un
procedimiento.
La Figura 2.9 muestra el modelo de proceso basado la metodologa ITIL que es la base del proceso de Gestin
de Servicios TI que describe este libro.
16
Figura 2.9 Modelo de proceso genrico ITIL
2.3.2 Procesos y departamentos

La mayora de los negocios se encuentran organizados jerrquicamente. Tienen departamentos que son
responsables de un grupo de empleados. Hay diferentes formas de estructurar los departamentos, por ejemplo
por cliente, producto, regin o disciplina. Los servicios TI dependen por lo general de varios departamentos,
clientes o disciplinas. Por ejemplo, si hay que proporcionar un servicio TI a usuarios con acceso a un
programa contable a travs de un servidor central, tendremos que hacer uso de varias disciplinas. El
departamento de sistemas debe hacer que el programa y la base de datos estn accesibles, el departamento de
comunicaciones debe hacer accesible los sistemas, y el departamento de soporte de PCs debe proveer a los
usuarios con una interfaz para que puedan acceder a la aplicacin.
Los procesos que abarcan muchos departamentos pueden controlar la calidad del servicio evaluando ciertos
aspectos como calidad, disponibilidad, capacidad, coste y estabilidad. Una organizacin de servicios tratar de
alcanzar estos aspectos de calidad para cumplir con las peticiones de los clientes. La estructura de tales
procesos debe garantizar que haya buena informacin sobre la provisin de servicios, para poder mejorar los
servicios de planificacin y control.
Figura 2.10 Procesos y departamentos (ejemplo)
17

La Figura 2.10 muestra un ejemplo bsico de las combinaciones de actividades en un proceso (se indica con
lneas punteadas).
2.3.3 Gestin de Servicios TI

La Gestin de Servicios TI es lo que se conoce en principio como el planteamiento orientado al proceso y al
servicio de lo que fue una vez la Gestin de TI En este captulo demostraremos que los procesos siempre
deben tener un objetivo definido. El objetivo de los procesos de Gestin de Servicios TI es contribuir a la
calidad de los servicios TI. La gestin de calidad y el control de procesos forman parte de la organizacin y
sus polticas.
En un planteamiento orientado al proceso tambin debemos considerar la situacin que se vive dentro de la
organizacin (polticas, cultura, tamao, etc.).
ITIL, la mejor orientacin conocida para la Gestin de Servicios TI, no dicta el tipo de organizacin, sino que
describe las relaciones entre las actividades en los procesos, que son relevantes a cualquier organizacin. Esto
proporciona un marco para intercambiar experiencias entre las organizaciones. Este planteamiento tambin
ofrece un marco para aprender de la experiencia de organizaciones dinmicas.
18
Captulo 3:
Introduccin a ITIL
Este captulo describe la estructura y los objetivos de la IT Infrastructure Library (ITIL) y las
organizaciones que contribuyen a mantener a ITIL como estndar de las mejores prcticas de la Gestin
de Servicios TI.
3.1 Fundamentos
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez ms de las TI para alcanzar sus
objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de
servicios TI de calidad que se correspondan con los objetivos del negocio, y que satisfaga los requisitos y las
expectativas del cliente. A travs de los aos, el nfasis pas de estar sobre el desarrollo de las aplicaciones TI
a la gestin de servicios TI. La aplicacin TI (a veces nombrada como un sistema de informacin) slo
contribuye a realizar los objetivos corporativos si el sistema est a disposicin de los usuarios y, en caso de
fallos o modificaciones necesarias, es soportado por mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del
tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtencin). De esta manera, los
procesos eficaces y eficientes de la Gestin de Servicios TI se convierten en esenciales para el xito de TI.
Esto se aplica a cualquier tipo de organizacin, grande o pequea, publica o privada, con servicios TI central
izados o descentralizados, con servicios TI internos o provistos por terceros. En todos los casos, el servicio
debe ser fiable, consistente, de alta calidad, y de coste aceptable.
La Gestin de Servicios TI dirige la provisin y el soporte de los servicios TI adaptados a las necesidades de
la organizacin. ITIL fue creada para comunicar las mejores prcticas en la Gestin de Servicios TI
sistemtica y coherentemente. Su planteamiento se basa en la calidad de servicio y en el desarrollo eficaz y
eficiente de los procesos.
ITIL ofrece un marco comn para todas las actividades del departamento TI, como parte de la provisin de
servicios, basado en la infraestructura TI. Estas actividades se dividen en procesos, que proporcionan un
marco eficaz para lograr una Gestin de Servicios TI ms madura. Cada uno de estos procesos cubre una o
ms tareas del departamento TI, tal como desarrollo de servicio, gestin de infraestructura, y provisin y
soporte de los servicios. Este planteamiento del proceso permite describir las mejores prcticas de la Gestin
de Servicios TI independientemente de la estructura de organizacin real de la entidad.
Muchas de estas prcticas son claramente identificables y son de hecho utilizadas hasta cierto punto en varias
organizaciones TI. ITIL presenta estas mejoras prcticas de manera coherente. Los libros de ITIL describen
cmo estos procesos, una vez identificados, pueden ser optimizados, y cmo la coordinacin entre ellos puede
ser mejorada. Los libros de ITIL tambin explican cmo los procesos se pueden formalizar dentro de una
organizacin. Los libros de ITIL ofrecen un marco de referencia para unificar la terminologa relevante dentro
de la organizacin, y ayuda a definir los objetivos y a determinar el esfuerzo necesario para su cumplimiento.
Utilizando el planteamiento basado en los procesos, ITIL describe primero lo que debe incluirse en la Gestin
de Servicios TI para dotar los servicios TI de la calidad demandada. La estructura y la asignacin de tareas y
responsabilidades entre las funciones y los departamentos dependen del tipo de organizacin y estas
estructuras varan mucho entre los departamentos TI y cambian con bastante frecuencia. La descripcin de la
estructura de proceso ofrece un punto de referencia comn que no cambia con tanta frecuencia, y que puede
ayudar a mantener la calidad de los servicios TI durante y despus de las reorganizaciones y entre los
abastecedores y los socios cuando cambian.
La lista incluida a continuacin identifica algunas ventajas y desventajas de ITIL. Esta lista no pretende ser
definitiva o exhaustiva, pero se ofrece como base para considerar las ventajas o las desventajas de ITIL y las
distintas formas en las que las organizaciones utilizan esta metodologa.
19
Introduccin a ITIL
Ventajas de ITIL para el cliente/usuario:

- La entrega de servicios TI se orienta ms al cliente y los acuerdos sobre la calidad del servicio mejoran la
relacin entre el departamento TI y el cliente.
- Se describen mejor los servicios, en un lenguaje ms cmodo para el cliente, y con mayores detalles.
- Se manejan mejor la calidad y el coste del servicio.
- Mejora las comunicaciones con la organizacin TI al acordar los puntos de contacto.
Ventajas de ITIL para la organizacin:
- La organizacin TI desarrolla una estructura ms clara, se vuelve ms eficaz, y se centra ms en los
objetivos corporativos.
- La direccin tiene ms control y los cambios resultan ms fciles de manejar.
- Una estructura de proceso eficaz brinda un marco para concretar de manera ms adecuada la
externalizacin de algunos de los elementos de los servicios TI.
- Seguir las mejores prcticas de ITIL alienta el cambio cultural hacia la provisin de servicios, y sustenta
la introduccin de un sistema de gestin de calidad basado en las series ISO 9000.
- ITIL establece un marco de referencia para las comunicaciones interna y las comunicaciones con los
abastecedores, as como la estandarizacin y la identificacin de los procedimientos.
Problemas potenciales de ITIL:
- Su introduccin puede llevar tiempo y bastante esfuerzo, y supone un cambio de cultura en la
organizacin. Una introduccin demasiado ambiciosa puede llevar a la frustracin porque nunca se
alcanzan los objetivos.
- Si la estructura de procesos se convierte en un objetivo en si misma, la calidad del servicio se puede ver
afectada de forma adversa. En ese caso, los procedimientos se transforman en obstculos burocrticos
que tratan de evitarse en lo posible.
- Puede no haber progreso si existe falta de comprensin sobre lo que deben proporcionar los procesos,
cuales son los indicadores de rendimiento, y como se controlan los procesos.
- No se ven las reducciones de coste y la mejora en la entrega de los servicios.
- Una implementacin con xito implica el compromiso del personal de todos los niveles de la
organizacin. Dejar el desarrollo de las estructuras de proceso a un departamento de especialistas puede
aislar al departamento de la organizacin y puede fijar una direccin no aceptada por los otros
departamentos.
- Si hay poca inversin en las herramientas de soporte, los procesos pueden no funcionar adecuadamente y
el servicio no mejorar. Se pueden necesitar ms recursos y ms personal si la organizacin se encuentra
sobrecargada con las actividades de rutina de la Gestin de Servicios TI.
Estos problemas potenciales por supuesto que se pueden superar. ITIL fue desarrollada en vista de las
ventajas que aporta. Muchas de estas sugerencias de mejores prcticas buscan prevenir tales problemas, o
ayudar a solucionarlos en caso de que aparezcan.
3.2 Organizaciones
3.2.1 OGC (CCTA)
ITIL fue originalmente un producto de la CCTA. CCTA era la Agenda Central de Computacin Y
Telecomunicaciones del Gobierno del Reino Unido. Desde el 1 de abril de 2001, la OGC (Office of
Government Commerce) absorbi a la CCTA y ahora es la propietaria de ITIL, El objetivo de la OGC es
ayudar a sus clientes del sector pblico en el Reino Unido a actualizar sus actividades de provisin y a hacer
el mejor uso posible de TI y dems instrumentos. "La OGC procura modernizar la provisin de TI en el
gobierno, y conseguir un valor sustancial por el dinero invertido". La OGC promueve el uso de las "mejores
prcticas" en muchas reas (p. ej. la gestin de proyectos, provisin, y Gestin de Servicios TI). La OGC
publica gran cantidad de libros (bibliotecas) escritos por expertos del Reino Unido e internacionales de
diversas compaas y organizaciones.
20

La IT Infrastructure Library de la OGC consta de un nmero claro y completo de "Cdigos de Prctica" para
brindar servicios TI eficaces y eficientes.
3.2.2 ITSMF
El Information Technology Service Management Forum (ITSMF), conocido originalmente como Information
Technology Infrastructure Management Forum (ITIMF), es el nico grupo de usuarios internacionalmente
reconocido e independiente dedicado a la Gestin de Servicios TI. Es propiedad de sus miembros y son ellos
quienes lo operan. El ITSMF tiene gran influencia y contribuye a la Industria de las Mejores Prcticas y a los
Estndares a nivel mundial.
El primer captulo de ITSMF se fund en el Reino Unido en 1991. El ITSMF holands (ITSMF Holanda) fue
el captulo posterior, establecido en Noviembre de 1993. Ahora existen captulos ITSMF en pases como
Sudfrica, Blgica, Alemania, Austria, Suiza, Canad, los Estados Unidos, y Australia, que cooperan con
itSMF Internacional.
Los captulos ITSMF promueven el intercambio de informacin y experiencia que permite a las
organizaciones TI mejorar los servicios que ofrecen. Organizan seminarios, conferencias, sesiones sobre
temas especficos, y otros eventos sobre temas actuales de Gestin de Servicios TI. Tambin publican noticias
y operan un sitio Web para compartir informacin. Estas tareas tambin contribuyen al desarrollo de ITIL.
3.2.3 EXIN y ISEB

La fundacin holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems
Examination Board" (ISEB) han desarrollado juntas un sistema de certificacin profesional para ITIL. Fue
realizado en estrecha cooperacin con la OGC y el ITSMF. EXIN e ISEB son organizaciones sin nimo de
lucro que cooperan para ofrecer una amplia gama de certificaciones en tres niveles:
-
Foundation Certificate en Gestin de Servicios TI

Practitioner Certificate en Gestin de Servicios TI
Manager Certificate en Gestin de Servicios TI
El sistema de certificacin esta basado en los requisitos para completar eficazmente el papel pertinente dentro
de una organizacin TI. A la fecha, se han entregado ms de 50.000 certificados Foundation a profesionales
de ms de 30 pases.
El certificado Foundation esta dirigido a aquellos profesionales que deben desempear las tareas de mayor
importancia dentro de la organizacin, y las relaciones entre las mismas. El examen Foundation cubre la
funcin del Centro de Servicios, y los procesos para la Gestin de Incidentes, la Gestin de Problemas, la
Gestin de Cambios, la Gestin de la Disponibilidad y de la Capacidad, la Gestin de Continuidad de
Servicios TI, la Gestin Financiera para Servicios TI, y la Gestin de la Seguridad.
Despus de obtener el certificado Foundation, se puede pasar al examen de Practitioner y de Manager. Los
Practitioners son entrenados a nivel prctico sobre el desempeo especfico de los procesos ITIL o las tareas
en tales procesos, para procesos como Gestin de Incidentes, Gestin de Cambios, y Gestin de Niveles de
Servicio. Se capacita a los gestores a nivel terico para controlar todos los procesos que se enuncian en el
certificado Foundations, para aconsejar sobre la estructura y la optimizacin de los procesos, y sobre como
implementarlos.
Hoy en da, ITIL representa mucho ms que una serie de libros tiles sobre Gestin de Servicios TI. El marco
de mejores prcticas en la Gestin de Servicios TI es sector completo de organizaciones, herramientas,
educacin y servicios de consultora, marcos de trabajo relacionados, y publicaciones. Desde 1990, se
considera a ITIL como el marco de trabajo y el planteamiento y la filosofa compartida por quienes utilizan
las mejores prcticas ITIL en sus trabajos. Gran cantidad de organizaciones se encuentran en la actualidad
cooperando internacionalmente para promover el estndar ITIL como un estndar de facto para la Gestin de
Servicios TI.
21
Introduccin a ITIL
Figure 3.1 Entorno de ITIL (fuente: OGC)
La Figura 3.1, el medio ITIL, muestra que las organizaciones involucradas tambin proveen 'feedback' entre
la practica actual (elipses blancas) y la teora (elipses grises) para mantener ITIL al da. Adems, se han
desarrollado extensiones y alternativas, algunas de las cuales pueden ser consideradas como mtodos de
Gestin de Servicios TI en su propia forma. Estas alternativas mencionan las necesidades de ciertos grupos u
organizaciones que tienen problemas especficos no cubiertos por ITIL.
El aspecto que hace clnica a la metodologa ITIL es que ofrece un marco de trabajo especfico basado en la
experiencia prctica de un conjunto global de usuarios profesionales.
3.3 Los Libros de ITIL

Cada uno de los libros de ITIL trata una parte del marco de trabajo y da una descripcin general de lo que es
necesario para organizar la Gestin de Servicios TI.
ITIL define los objetivos y las actividades, y las entradas y salidas de los procesos de la organizacin TI. Sin
embargo, ITIL no brinda una descripcin especfica de la forma en la que se deben implementar estas
actividades, ya que esto puede variar de organizacin a organizacin. Se pone mas nfasis en el planteamiento
que ha sido probado; pero eso, segn las circunstancias, puede ser implementado de diferentes formas. ITIL
no es un mtodo, sino que ofrece un marco de trabajo para planificar los procesos, los roles y las actividades
ms comunes, indicando los nexos entre ellos y los flujos de comunicaciones necesarios.
ITIL se basa en la necesidad de proporcionar servicios de alta calidad, con nfasis en la relacin con el
cliente. La organizacin TI deber cumplir los acuerdos con el cliente lo que implica mantener una buena
relacin con ellos, con los socios y con los abastecedores.
Parte de la filosofa TI tiene su base en los sistemas de calidad, como la serie ISO 9000, y los marcos de
trabajo de Calidad Total, como el EFQM. ITIL sustenta tales sistemas de calidad y ofrece una clara
descripcin de los procesos y las mejores prcticas en la Gestin de Servicios TI. Esto puede llevar a una
reduccin significativa del tiempo necesario para conseguir la certificacin ISO.
En principio, ITIL consista en un gran nmero de libros, cada uno de los cuales describa un rea especifica
de mantenimiento y operacin de la infraestructura TI. Los diez libros que describan Soporte de Servicio y
Entrega de Servicio eran considerados el eje de ITIL. Existan aproximadamente 40 libros ms sobre temas
suplementarios relacionados con la Gestin de Servicios TI, desde cableado hasta manejo de las relaciones
con el cliente. Sin embargo, la serie de libros originales de la Infrastructure Library abordaba la Gestin de
Servicios TI desde la perspectiva TI.
El Conjunto de Perspectivas del Negocio se introdujo para acortar la distancia entre el negocio y la
organizacin TI y ayudar a alinear sus objetivos. Y hay que tener en cuenta que con el tiempo ciertos aspectos
de ITIL tenan un planteamiento algo anticuado.
Los libros centrales de ITIL han sido revisados y se han publicado dos libros, uno sobre Soporte del Servicio,
y otro sobre Provisin del Servicio. Esto ha eliminado muchas repeticiones y contradicciones ocasionales de
22

las primeras colecciones y ha mejorado la cohesin interna. Ilustra tambin la visin de la Gestin de
Servicios TI con ms claridad.
En cuanto a la publicacin de este libro, la actualizacin de todas las colecciones de las publicaciones ITIL
que se observa en la figura a continuacin todava no se ha completado. La estructura bsica de ITIL se ilustra
en la Figura 3.2, que utiliza un conjunto de piezas de rompecabezas como analoga.
Figura 3.2 ITIL puzzle (fuente: OGC)
El rompecabezas de ITIL muestra los siete elementos principales de los libros ITIL. Cada uno de estos
elementos se conecta con los otros seis, y hasta cierto punto se superpone.
Los siete elementos son:
Soporte del Servicio (2000)
Provisin del Servicio (2001)
Gestin de la Seguridad (1999)
Gestin de infraestructuras TI (2002)
Gestin de Aplicaciones (2002)
Planificacin para Implementar la Gestin de Servicios (2002)
Perspectiva del Negocio (fecha prevista: 2004}
El rompecabezas ITIL tambin ha sido comparado con placas tectnicas, o con continentes que chocan o se
superponen. No slo es difcil identificar con exactitud los lmites, sino que adems hay roces y presin. Esta
imagen se confirma con lo que sucede en muchas organizaciones. En esta frontera en particular, se presentan
los mayores problemas de gestin. Aunque no se puede evitar el problema, podemos, como con los
terremotos, prepararnos para enfrentarlos.
En este captulo, presentaremos la coleccin de publicaciones ITIL usando los elementos ms importantes del
rompecabezas ITIL.
23
Introduccin a ITIL
3.3.1 Perspectiva del Negocio

Los libros ITIL de la Coleccin Perspectiva del Negocio describen muchos temas relacionados con la
comprensin y la apreciacin de los servicios TI como un aspecto integrado a la gestin del negocio.
La coleccin de Perspectiva del Negocio, y el libro de Perspectiva del Negocio, que eventualmente
reemplazara la coleccin, incluye:
-
Gestin de la Continuidad del Negocio

Asociaciones y externalizacion
Cambios para la supervivencia
Adaptacin del negocio a los cambios radicales
Otros libros de ITIL tratan estos temas, adems de los de la Coleccin de Perspectiva del Negocio.
Gestin de Recursos Fsicos
La Gestin de Recursos Fsicos se hace cargo de acordar los contratos entre la organizacin TI y las empresas
que aportan los Recursos. Los abastecedores de Gestin de Recursos Fsicos podran ser responsables de la
operacin de todo o parte de la infraestructura TI. Sin embargo, la organizacin TI carga con la ltima
responsabilidad por los servicios brindados al cliente. Este libro describe las medidas que puede tomar la
organizacin TI para poder aceptar la responsabilidad sobre los acuerdos de Nivel de Servicio, y para evaluar
los servicios provistos por los abastecedores de recursos.
Gestin de Relaciones con Abastecedores
Hasta cierto punto la Gestin de Relaciones con Abastecedores es similar a la Gestin de Relaciones con
Clientes, pero slo cubre la relacin entre la organizacin TI y sus abastecedores. Una buena relacin con los
abastecedores no trata slo de los acuerdos y los contratos; bsicamente se ocupa de la forma de cooperacin
entre ambas partes, que contribuye a la entrega actual y futura de los servicios TI y a los objetivos de la
organizacin TI. La naturaleza y el contenido de los contactos establecidos pueden distinguir las relaciones
con los abastecedores. Estos pueden servir para discutir las perspectivas a largo plazo de relaciones existentes,
promover las comunicaciones, o para investigar el alcance ofrecido por los diferentes abastecedores. Las
tareas ms importantes del proceso de Gestin de Relaciones con Abastecedores incluyen la seleccin de
abastecedores, la evaluacin de su desempeo, y la determinacin de la forma en la que la organizacin TI
opera los contactos con los abastecedores.
3.3.2 Provisin del Servicio

Como se indica ms arriba, el Soporte del Servicio y la Provisin del Servicio son considerados parte central
del marco de trabajo ITIL para la Gestin de Servicios TI. El libro ITIL sobre Provisin del Servicio describe
los servicios que necesita el cliente, y lo esencial para proporcionar esos servicios.
Los siguientes temas se encuentran en la coleccin de Provisin del Servicio:
-
Gestin de Niveles de Servicio

Gestin Financiera de los Servicios TI
Gestin de la Capacidad
Gestin de Continuidad de los Servicios TI
Gestin de la Disponibilidad
La Gestin de la Seguridad (con referencia al libro ITIL sobre Gestin de la Seguridad) se agreg en la
introduccin de este libro, pero no es parte de la coleccin de la Provisin del Servicio. La compleja
interrelacin entre los procesos descritos en los libros sobre Soporte del Servicio y Provisin del Servicio es
casi imposible de mostrar en este diagrama. El diagrama simplificado de la Figura 3.3 ilustra las principales
generalidades.
24
Figura 3.3 Soporte del Servicio Y Provisin del Servicio
Gestin de Relaciones con Clientes TI

Las mejores prcticas de la mayora de las organizaciones demuestran que es aconsejable cohesionar y
estructurar las relaciones con la organizacin del cliente a distintos niveles. Las actividades de la Gestin de
Relaciones con Clientes TI abarcan muchos procesos (ver tambin la seccin 2.2.5). El Centro de Servicios es
el primer punto de contacto con los usuarios. Sin embargo, el cliente, que encarga el servicio, contactar
inicialmente a travs de la Gestin de Relaciones con Clientes TI. De ese modo, este proceso crea un puente
entre la organizacin TI, que tradicionalmente ha tenido un planteamiento tcnico, y los clientes que quieren
alcanzar sus objetivos del negocio. La Gestin de Relaciones con Clientes TI no forma parte de la coleccin
de Provisin del Servicio y no se desarrolla en este libro introductorio.
El objetivo de la Gestin de Niveles de Servicio es establecer acuerdos claros con el cliente sobre los
servicios TI, e implementar estos acuerdos. En consecuencia, la Gestin de Niveles de Servicio precisa
informacin sobre las necesidades del cliente, los recursos proporcionados por la organizacin
TI, y los recursos financieros disponibles.
La Gestin de Niveles de Servicio maneja el servicio prestado al cliente (Foco en el Cliente). Al crear
servicios basados en las necesidades del cliente (atraccin por demanda) y no slo segn lo que le resulta
tcnicamente factible en la actualidad (impulsada por el suministro), la organizacin TI puede mejorar la
satisfaccin del cliente. El captulo sobre Gestin de Niveles de Servicio en el libro de Provisin del Servicio
describe:
-
La claridad con la que se deben definir los acuerdos en el Acuerdo de Nivel de Servicio puede optimizar
los servicios TI al justificar el coste para el cliente.
Cmo se puede evaluar y discutir el servicio.
Cmo se puede reforzar el servicio al soportar los Contratos con los abastecedores de la propia
organizacin TI.

La Gestin Financiera de los Servicios TI maneja todo lo relativo con la entrega prudente de los servicios TI.
Por ejemplo, la gestin Financiera proporciona informacin sobre los costes en los que incurre la
organizacin al suministrar los servicios TI. Esto permite una consideracin adecuada de los costes y
beneficios (precio y rendimiento) al decidir que cambios realizar en la infraestructura o en los servicios TI.
Tal como se discute en el captulo sobre Gestin Financiera del libro de Provisin del Servicio, la
identificacin, asignacin, proyeccin y evaluacin de los costes se denominan bajo el trmino "contabilidad
25
Introduccin a ITIL
de costes", que en la versin actual de ITIL aparece como Elaboracin de Presupuesto y Contabilidad. Estas
actividades ayudan a entender los costes (en qu costes se incurre y donde?) y tambin se puede utilizar en la
elaboracin del presupuesto. Con respecto a la corriente de ingresos de la organizacin TI, la Gestin
Financiera de los servicios TI describe varios mtodos de imputacin, que incluye la definicin de objetivos y
la determinacin del precio, adems de elaborar los diferentes aspectos del presupuesto.
La Gestin de la Capacidad es el proceso de optimizacin de costes, tiempo de adquisicin, y despliegue de
los recursos TI para sustentar los acuerdos establecidos con el cliente. La Gestin de la Capacidad tiene a su
cargo la gestin de recursos, de rendimiento, de demanda, modelado, capacidad de planificacin, la gestin de
carga y el ajuste del tamao. La Gestin de la Capacidad hace nfasis sobre la planificacin para garantizar
que los Niveles de Servicio acordados tambin se puedan cumplir en el futuro.
La Gestin de la Disponibilidad es el proceso de garantizar el correcto despliegue de los recursos, mtodos y
tcnicas, para sustentar la disponibilidad de los servicios TI acordados con el cliente. La Gestin de la
Disponibilidad se encarga de temas tales como optimizar el mantenimiento, o disear medidas para minimizar
el nmero de incidentes.
Gestin de la Seguridad
El objetivo de la Gestin de la Seguridad es proteger la infraestructura TI del uso sin automacin (como el
acceso sin autorizacin a la informacin). Esto se basa en los requisitos establecidos en los Acuerdos de Nivel
de Servicio, en los requisitos contractuales, la legislacin y la poltica, y un nivel bsico de seguridad. Cuando
se actualiz la parte de Provisin del Servicio de ITIL se decidi que no era necesario reemplazar el libro
publicado sobre Gestin de la Seguridad. El libro ITIL sobre Provisin del Servicio no trata la Gestin de la
Seguridad, pero hace referencia al libro sobre Gestin de la Seguridad de ITIL.
Gestin de Continuidad de Servicios TI
Este proceso indica la preparacin y la planificacin de medidas de recuperacin ante desastres en los
servicios TI en el caso de que se produzca una interrupcin del negocio. Conocida como Planificacin de
Contingencias en la revisin anterior de ITIL, pone nfasis en los vnculos entre todas las medidas necesarias
para salvaguardar la continuidad de la organizacin de clientes ante la posibilidad de un desastre (Gestin de
la Continuidad del Negocio) y las medidas para prevenir tal desastre. La Gestin de Continuidad de Servicios
TI es el proceso de planificacin y coordinacin tcnica, financiera y de gestin de recursos que se necesita
para garantizar la continuidad del servicio tras el desastre, segn lo convenido con el cliente.
3.3.3 Soporte del Servicio

El libro ITIL sobre Soporte del Servicio describe como el cliente puede tener acceso a los servicios adecuados
para contribuir a su negocio.
Este libro cubre los siguientes temas:
Centro de Servicios (Service Desk)
Gestin de Incidentes
Gestin de Problemas
Gestin de Configuraciones
Gestin de Cambios
Gestin de Versiones (Release Management)
Centro de Servicios (Service Desk)
El Centro de Servicios es el punto de contacto inicial con la organizacin TI para los usuarios. Previamente,
los libros ITIL se referan a esta como Centro de Soporte (Help Desk). La tarea mas importante del Centro de
Soporte era registrar, resolver y controlar los problemas. El Centro de Servicios puede tener un papel ms
amplio (por ejemplo recibir Peticiones de Cambio) y puede encargarse de actividades relacionadas con
muchos procesos. Es el punto de contacto inicial con el proveedor de servicios TI.
26

Entre las contribuciones realizadas por la ITIL al campo de la Gestin de Servicios TI la diferencia entre
incidentes y problemas es posiblemente una de las ms conocidas, pero no siempre la ms popular.
Aunque esta distincin puede a veces resultar confusa, su mayor ventaja yace en que la diferencia se hace
entre la rpida restitucin del servicio (tarea de la Gestin de Incidentes), y la identificacin y el remedio de la
causa del incidente (tarea de la Gestin de Problemas).
El proceso de la Gestin de Incidentes tiene como objetivo resolver el incidente y restaurar la provisin del
servicio rpidamente. Los incidentes son registrados, y la calidad del registro de incidentes determina la
eficacia de cierto nmero de procesos a los que este registro aporta informacin.
Gestin de Problemas
Si se sospecha que existe un problema dentro de la infraestructura TI, la Gestin de Problemas trata de
identificar la causa raz del mismo. Se puede sospechar que hay un problema porque se registran incidentes
repetitivamente, pero est claro que el objetivo es la prevencin de dichos incidentes cuando sea posible.
Una vez que se identificaron las causas (errores conocidos), se decide si es necesario realizar mejoras
permanentes en la infraestructura para prevenir nuevos incidentes. Esta mejora se hace emitiendo una Peticin
de Cambio.
Ntese tambin que la definicin ITIL de Gestin de Problemas difiere bastante de p. ej. la definicin que la
industria TI le diera en los Estados Unidos en el pasado.
La Gestin de Configuraciones se encarga de realizar los cambios de infraestructura (estandarizacin y
verificacin del estado), de identificar los elementos de configuracin (inventario, vnculos respectivos,
verificacin y registro), de reunir y gestionar la documentacin de la infraestructura TI y de proporcionar
informacin de la Infraestructura TI a todos los otros procesos.
Gestin de Cambios
La Gestin de Cambios asume la tarea de implementar los cambios en la infraestructura TI de manera
controlada. El objetivo del proceso es determinar los cambios necesarios, y cmo deben implementarse para
que produzcan el menor efecto adverso sobre los servicios TI, y al mismo tiempo garantizar la correcta
identificacin de los cambios, a travs de una eficaz coordinacin en toda la organizacin.
Los cambios se realizan a partir del estado de las actividades monitorizadas por la Gestin de
Configuraciones, a peticin de la organizacin del cliente, la Gestin de Problemas y muchos otros procesos.
Los cambios se implementan siguiendo unos pasos especficos de definicin, planificacin, construccin y
pruebas, aceptacin, implementacin y evaluacin.
Gestin de Versiones (Release Management)
Una versin es un grupo de elementos de configuracin (CIs) que son probados e introducidos juntos en el
entorno en uso. El principal objetivo de la Gestin de Versiones es garantizar un correcto despliegue de
versiones, incluyendo la integracin, el anlisis y el almacenamiento de las mismas.
La Gestin de Versiones garantiza que se suministren slo aquellas versiones que son correctas y que se
hayan analizado. Este proceso se relaciona de cerca con las actividades de la Gestin de Configuraciones y de
Cambios. A travs de las actividades de la Gestin de Versiones se implementan de manera real los cambios.
27
Introduccin a ITIL
3.3.4 Gestin de Infraestructuras TI

Los procesos de Gestin de operaciones TI se desarrollarn en un nuevo libro ITIL sobre Gestin de
Infraestructuras TI. Este libro cubrir:
-
Gestin del Servicio de Redes

Gestin de Operaciones
Gestin de Centros distribuidos
Instalacin y Aceptacin de Ordenadores
Gestin de Sistemas
La Gestin de Infraestructuras TI incluye tambin la Gestin del Entorno.

Gestin de Servicios de Red
Los procesos de la Gestin de Servicios de Red se encargan de planificar y administrar las redes de
comunicaciones. Se incluyen los sistemas de telefona y las redes LAN y WAN. El modulo ITIL de Gestin
de Servicios de Red tambin trata las necesidades de comunicaciones a largo plazo de la organizacin.
Describe en si cmo las mejores prcticas de ITIL se pueden aplicar al entorno de redes.
Gestin de Operaciones
La Gestin de Operaciones de Informtica (Operacin de Sistemas) trata sobre la Gestin de hardware y de
los sistemas de software, que incluye los mainframe y los sistemas medios, y tambin los servidores, para
garantizar que se brinden los Niveles de Servicios acordados.
Gestin de Centros distribuidos
Los procesos de Gestin de Centros distribuidos tiene a su cargo la gestin de las operaciones en
organizaciones descentralizadas. El objetivo es proveer soporte del servicio TI donde se encuentre el usuario.
Esto incluye especficamente llegar a acuerdos sobre las actividades de varios procesos (en especial los
procesos de soporte de los servicios TI) cuando se prestan servicios TI en diferentes lugares. Es importante
definir con exactitud las responsabilidades para optimizar el servicio.
Aprobacin e Instalacin de Ordenadores
La Instalacin de Ordenadores y la Aprobacin se ocupan bsicamente de fijar las pautas de la planificacin
para la aceptacin, la instalacin y la eventual desinstalacin del hardware de la infraestructura TI. Estas
pautas surgen de las actividades de los procesos de la Gestin de Cambios y de la Gestin de Versiones.
Gestin de Sistemas
A la fecha los libros ITIL no han cubierto la Gestin de Sistemas. En el futuro, este tema ser desarrollado en
un nuevo libro sobre Gestin de Infraestructuras TI.
Gestin del Entorno
La Gestin del Entorno tiene como funcin gestionar el entorno de la infraestructura TI (suministro de
energa, refrigeracin, etc.). Una de las tareas de este proceso es instalar y mantener los equipos de
climatizacin de los CPD y redes.
3.3.5 Gestin de Aplicaciones

El libro ITIL sobre Gestin de Aplicaciones trata la relacin entre la gestin y el ciclo de vida del software.
Incluye temas tales como Soporte del Ciclo de Vida del Software y Anlisis de un Servicio TI para Uso
Operativo. Un tema muy importante en Gestin de Aplicaciones es cmo se responde eficazmente a los
cambios en el negocio. En este punto, resulta de suma importancia definir los requisitos e implementar una
solucin que satisfaga al cliente.
Soporte del Ciclo de Vida del Software
El soporte del ciclo de vida del software se encarga de definir la forma en la que se dar soporte del software
durante todo su ciclo de vida, consultando a los responsables del desarrollo del software.
28

Es muy importante la forma en la que se disea, construye, evala, opera y mantiene, y eventualmente se
desinstala el software en los servicios TI. En cada etapa del ciclo de vida del software se debe llegar a un
acuerdo entre los que desarrollan y los que operan la infraestructura TI. La seleccin de los modelos del Ciclo
de Vida del Software tienen un gran impacto sobre los servicios TI.
Probar un Servicio TI para Uso Operacional
El objetivo de Probar un Servicio TI para Uso Operacional es garantizar la correcta operacin de los servicios
TI nuevos o modificados antes de que entren en operacin. Esto se realiza en varias etapas: prueba de sistema,
prueba de instalacin y prueba de aceptacin del usuario, para determinar si la aplicacin desarrollada
funciona, si esta correctamente instalada, si tiene interfaces con el resto de la infraestructura TI, y si ofrece a
los usuarios las funciones que se acordaron con el cliente.
3.3.6 Direccin y Organizacin

Las colecciones ITIL tambin incluyen algunos libros sobre temas a nivel estratgico, el Conjunto de
Direccin. Los libros sobre Gestin de Calidad, Organizacin de Servicios TI y Planificacin y Control de los
Servicios TI tratan de manera especfica las polticas y la planificacin de los servicios TI a largo plazo.
Gestin de Calidad para Servicios TI
La Gestin de Calidad para los Servicios TI se ocupa de establecer y mantener un sistema de calidad
coherente, basado en los procesos de Gestin de Servicios TI descritos en otros libros ITIL. Este libro
describe la introduccin de un sistema de calidad (basado en los estndares de la norma ISO-9000) en una
organizacin TI, y la evaluacin de un sistema de gestin de calidad existente. Las actividades de la Gestin
de Calidad incluyen la definicin e implementacin de la poltica de calidad, y la operativa del sistema de
calidad, incluyendo las auditorias.
Organizacin de Servicios TI
La Organizacin de Servicios TI maneja la estructura de la organizacin TI. Este libro ITIL describe como se
puede analizar y evaluar la organizacin, en particular en trminos de tareas, autoridad y responsabilidad. Se
proporciona un marco de trabajo para tratar los cambios de la organizacin, basado en la descripcin de
procesos en otros libros ITIL. Las actividades ms importantes de este proceso son determinar y definir la
estructura y el papel de la organizacin y la descripcin de las diferentes funciones.
Planificacin y Control para los Servicios TI
La Planificacin y Control para los Servicios TI intenta proporcionar un sistema de planificacin, informacin
y control coherente para la organizacin TI que garantice el cumplimiento de los objetivos y los requisitos
segn la estrategia del negocio y la estrategia de la organizacin TI. Esto implica coordinar la planificacin y
la informacin de varios procesos de la Gestin de Servicios TI (por ejemplo en forma de planes anuales y de
informes trimestrales).
3.3.7 Planificacin e implementacin

Hoy en da se cuenta con mucha experiencia en el mundo entero en la planificacin y la implementacin de
programas para optimizar la Gestin de Servicios TI. Un libro futuro de ITIL tratar sobre este tema.
En esencia, el concepto de planificacin e implementacin de cambios en la Gestin de Servicios TI se
describe en el modelo de mejora de los procesos (captulo 2). En la practica, la situacin que se ilustra en este
modelo no se manifiesta en la forma en la que las organizaciones toman sus decisiones, que puede verse
afectada por aspectos histricos o polticos. Por tal razn es imprescindible que los directivos se comprometan
con el programa de mejoras (Gestin de Compromisos), y que entiendan la cultura de la organizacin. Se
debe ser consciente de que ya puede haber procesos que logren las necesidades de la organizacin, al menos
en parte. Si se ignora esto, se puede generar resistencia en las personas necesarias para alinear mejor estos
procesos con las necesidades del negocio y la experiencia adquirida con la Gestin de Servicios TI.
Har falta una comisin temporal para analizar las necesidades de la organizacin e implementar las
soluciones necesarias. En un plan de mejora esto puede ser considerado un proyecto en si mismo, o una serie
de proyectos. Una de las ventajas es que la organizacin se topar con puntos decisivos y podr decidir si
29
Introduccin a ITIL
terminar, continuar, o modificar el proyecto. En dicho contexto el libro de ITIL recomienda adoptar
PRINCE2 (Proyectos En Ambientes Controlados, 2a versin) para manejar tales proyectos.
Cada proyecto debe basarse en el anlisis de la situacin actual, la situacin deseada, y el camino entre ambas.
En muchos casos, las alternativas se compararan segn:
-
Conveniencia para la organizacin.

Riesgos, obstculos y problemas potenciales.
Costes de transicin y costes a largo plazo.
Costes por continuar con el planeamiento actual.
Identificar las alternativas potenciales puede resultar un proyecto en si mismo.

La experiencia nos demuestra que ITIL no es una formula mgica. No se deben esperar milagros. Se debe
prestar particular atencin a los llamados proyectos de implementacin ITIL que esconden una agenda
particular reorganizacin o fusin. ITIL describe la mejor prctica para perfeccionar la Gestin de Servicios
TI, no es un libro de cocina para organizaciones. En principio ITIL brinda un marco de referencia para
estructuras de proceso en la organizacin TI y, en un nivel ms bajo, una gua para la estructura de esa
organizacin. Si un proyecto tiene como objetivo mejorar la organizacin como tal, es aconsejable contratar
expertos en el campo.
Una medicin de base o un anlisis de salud puede ser un buen comienzo para el proceso de mejora. Una
evaluacin as de la Gestin de Servicios TI puede ayudar a identificar las fortalezas y las debilidades de la
organizacin, y a definir con claridad los objetivos del proyecto de mejora. La medicin se puede repetir
despus de un tiempo para ver el progreso del proyecto o programa.
30
Captulo 4:
4.1 Introduccin
La Gestin de Incidentes es una tarea reactiva, p. ej. reducir o eliminar los efectos de (potenciales)
alteraciones en los servicios TI, asegurando de esta manera que los usuarios puedan volver a trabajar lo ms
pronto posible. Por esta razn los incidentes se registran, se clasifican y se asignan a los especialistas
adecuados, luego se controlan y por ltimo se resuelven y se cierran. Dado que toda esta actividad precisa de
un estrecho contacto con los usuarios, el eje del proceso de Gestin de Incidentes es la funcin del Centro de
Servicios que sirve como la oficina de entrada a los departamentos de especialistas y abastecedores
subyacentes. La Gestin de Incidentes es esencial para los otros procesos ITIL ya que proporciona una valiosa
informacin sobre los errores de infraestructura.
La Figura 4.1. Muestra un ejemplo de la Gestin de Incidentes como proceso horizontal en la organizacin,
que gestiona de manera eficaz y controla el flujo de trabajo de los incidentes.
Usuarios
Super
Usuarios
Centro de
servicios
Gestin de
aplicaciones
Primera Lnea
De soporte
Organizacin
Gestin de Red y
Servidor
o
Procesamiento Central
o
Sistema de Telefona
Segunda Lnea
De soporte
Proceso de Gestin de Incidentes
Abastecedores
Desarrollo
&
Arquitectos
Tercera lnea
De soporte
th
n Lnea de Soporte
Figura 4.1 Posicin de procesos de la Gestin de Incidentes en relacin con las funciones de los departamentos de la
organizacin TI
4.1.1 Terminologa
Incidente
Utilizamos una amplia definicin de la palabra "Incidente", por lo que casi todas las llamadas al Centro de
Servicios pueden ser registradas y monitorizadas como incidentes.
El libro ITIL sobre Soporte del Servicio define un incidente como:
Cualquier evento que no forma parte de la operacin estndar de un servicio y que causa, o puede causar
una interrupcin a, o una reduccin de la calidad de ese servicio.
Por eso como reconocimiento de lo que es usual, ITIL pasa a ampliar la interpretacin de esta definicin de
'Incidente', de modo que casi todas las llamadas al Centro de Servicios pueden ser registradas y monitoreadas
como Incidentes.
En este contexto, 'Incidentes' incluyen no slo errores de hardware y software, sino tambin Peticiones de
Servicio debido a que ambos son tramitados de una manera similar. Es decir, Gestor de Incidentes tramita sus
completos ciclos de vida.
Peticiones de Servicio se pueden hacer para 'servicios estndar': que han sido acordados ser facilitados bajo
SLAs; son suministrados a travs de procedimientos acordados que tienen apropiadas verificaciones y
controles; y donde se mantienen registros, p. ej. en la CMDB.
31
Ejemplos de Peticin de Servicio:

-
Preguntas funcionales o peticiones de informacin.

Indagacin del estado de otros incidentes.
Cambio de la clave de acceso.
Peticiones de lotes de trabajo, restituciones y autorizaciones de claves.
Extraccin de base de datos.
Peticin para facilitar a nuevo empleado la apropiada funcionalidad/servidos TI.
Una Peticin de Servicio puede ser para un Cambio Estndar que, mientras este cubierto por un 'servicio
estndar', es tramitado bajo Gestin de Incidentes y no es sometido al proceso de Peticin de Cambio.
Si se pide un Servicio que no es para un definido 'servicio estndar', y ese altera el estado de la infraestructura,
entonces ese hace iniciar una Peticin de Cambio (RFC).
Una RFC no es tramitada por Gestin de Incidentes pero es tratada formalmente por Gestin de Cambios.
Impacto, urgencia y prioridad
Cuando se atienden muchos incidentes al mismo tiempo, se deben establecer prioridades. Estas prioridades se
basan en la seriedad del error para el negocio y el usuario. El Centro de Servicios asigna la prioridad
consultando al usuario y de acuerdo con las disposiciones del SLA que determina el orden en el que deben
tratarse los incidentes. Cuando los incidentes se escalan a niveles superiores - segunda lnea (grado dos),
tercera lnea (grado tres) o un nivel de soporte superior, se mantiene la prioridad o se ajusta consultando con
el Centro de Servicios.
Por supuesto que el usuario pensar que su incidente es el de mayor prioridad, pero las exigencias del usuario
son por lo general subjetivas. Para hacer una evaluacin objetiva, se deben discutir con el usuario los
siguientes criterios:
-
Impacto del incidente - grado de desviacin sobre la operativa normal, en trminos de nmero de
usuarios o de procesos del negocio afectados.
Urgencia del incidente - la demora aceptable para el usuario o el proceso del negocio.
La prioridad se determina sobre la base de la urgencia y el impacto. Para cada prioridad se define un nmero
de personas y cierta cantidad de recursos. Para incidentes con la misma prioridad, el esfuerzo que se deba
poner en cada uno determinara el orden. Por ejemplo, un incidente que rquiem poco esfuerzo se puede
resolver antes que otro para el que se necesite mas esfuerzo.
Figura 4.2 Determinando el impacto, la urgencia y la prioridad
La Gestin de Incidentes tiene opciones para reducir el impacto o la urgencia, tales como cambiar el hardware
o asignar otra cola de impresin. El impacto y la urgencia tambin pueden cambiar durante la vida de un
incidente, por ejemplo cuando afecta a ms usuarios o durante los periodos crticos.
32

Impacto y urgencia pueden combinarse en una matriz como la de la Tabla 4.1.
Tabla 4.1 Ejemplo de un sistema de codificacin de una prioridad
Escalado
En el caso de que no pueda resolverse un incidente en la primera lnea de soporte dentro del tiempo acordado,
se tendr que acudir a un grupo de mayor experiencia o a una autoridad en la materia.
Esto se conoce como escalado, que viene determinado por los tiempos de resolucin y las prioridades de las
que hablamos mas arriba.
Distinguimos entre escalado funcional y jerrquico:
-
Escalado funcional (horizontal) - el escalado funcional significa involucrar mas personal especializado
o privilegios de acceso (autoridad tcnica) para solucionar el incidente, pudindose exceder los lmites
del departamento.
Escalado jerrquico (vertical) - jerrquico significa que se realiza un movimiento vertical (a niveles
mas altos) en la organizacin porque la autoridad (autoridad de la organizacin, poderes) o recursos
necesarios para resolver el incidente son insuficientes.
El Gestor de Incidentes puede planificar reservar capacidad de antemano para el escalado funcional en la lnea
de organizacin, para que no sea necesario el escalado jerrquico para resolver el incidente.
Primera, segunda y subsiguientes lneas de soporte
Ya se explic antes la asignacin de la ruta del incidente, o el escalado funcional. La experiencia, la urgencia
y la autoridad determinan la asignacin de la ruta. El Centro de Servicios es el que generalmente provee el
soporte de primer nivel, los departamentos de administracin el soporte de segundo nivel, los desarrolladores
de software y los especialistas el de tercer nivel, y los abastecedores el de cuarto nivel.
Si la organizacin es pequea, no habr tantos niveles de escalado. En organizaciones muy grandes, el Gestor
de Incidentes puede nombrar Coordinadores de Incidentes en determinados departamentos para ayudarlo. Por
ejemplo, los Coordinadores actan como interfaz entre el proceso y la lnea de organizacin. Cada uno de
ellos coordina su propio grupo de soporte.
33
La Figura 4.3 ilustra el proceso de escalado.
Figura 4.3 Escalado de Incidente (fuente: OGC). Nota: 'Nth lnea' tambin conocida como 'TierN'
4.2 Objetivo
El objetivo de la Gestin de Incidentes es restituir el servicio, como lo define el SLA, lo ms pronto que sea
posible, con el menor impacto posible sobre la actividad del negocio de la organizacin y el usuario. La
Gestin de Incidentes tambin debe mantener registros eficaces de los incidentes para medir y evaluar el
proceso, y proporcionar informacin a los otros procesos.
4.2.1 Beneficios
-
34
Para el negocio en conjunto:

Mayor resolucin dentro del tiempo estipulado de los incidentes reduciendo el impacto en el
negocio.
Mayor productividad para el usuario.
Monitorizacin de incidentes como proceso independiente, centrado en el cliente.
Disponibilidad de informacin de produccin centrada en el SLA.
Para la organizacin TI:
Mejora de la monitorizacin, permitiendo una adecuada medicin del rendimiento contra el SLA.
Gestin de informacin til del SLA haciendo uso de la informacin disponible.
Mejor y ms eficaz uso del personal.
No perder o registrar de manera incorrecta los incidentes y las peticiones de servicio.
CMDB ms precisa, ya que se audita mientras se registran los incidentes en relacin con los
elementos de configuracin.
Mejora de la satisfaccin del usuario y del cliente.
Si no se implementa la Gestin de Incidentes nos podemos enfrentar con los siguientes efectos adversos:
-
Al no tener un responsable de monitorizar y escalar los incidentes, estos se pueden volver

innecesariamente severos y reducir el nivel de servicio. Los usuarios pueden ser derivados a otras
autoridades sin que se les resuelva el problema.
Se interrumpe continuamente a los especialistas con llamadas de usuarios que impiden que ellos realicen
su trabajo. En consecuencia, mucha gente puede estar trabajando sobre el mismo incidente, perdiendo
tiempo innecesariamente, y dando soluciones conflictivas.
Hay falta de informacin administrativa sobre el dominio del usuario y los servicios.
Dados todos los problemas mencionados, el cliente y la organizacin gastan ms de lo necesario.
4.3 El proceso
La Figura 4.4 muestra la entrada y la salida del proceso, y sus actividades.
Figura 4.4 Posicin del proceso de Gestin de Incidentes
4.3.1 Entradas al Proceso

Los incidentes se pueden producir en cualquier parte de la infraestructura y los usuarios lo informan, pero los
incidentes tambin pueden ser detectados por otros departamentos adems del Centra de Servicios. y
automticamente por sistemas de deteccin que se montan para capturar eventos (fallos) de la infraestructura
tcnica o de aplicaciones.
4.3.2 Gestin de Configuraciones

La Base de Datos de la Gestin de Configuraciones (CMDB) representa un papel muy importante en la
Gestin de Incidentes ya que define las relaciones entre los recursos, los servicios, los usuarios y los Niveles
de Servicio. Por ejemplo, la Gestin de Configuraciones muestra quien es responsable de un componente de
infraestructura, para que esos incidentes puedan ser mejor direccionados.
Tambin ayuda a decidir sobre temas operativos, como el cambio de una cola de impresin o el cambio de
usuarios a otro servidor. Cuando se registra el incidente, los detalles de configuracin se asocian con el
registra de incidentes para brindar informacin mas correcta sobre el error. Si fuera necesario, se actualiza el
estatus de los componentes relevantes de la Base de Informacin de la Gestin de Configuraciones.
35
4.3.3 Gestin de Problemas

La Gestin de Problemas exige algunos requisitos de calidad para registrar los incidentes de manera que
resulte ms fcil la identificacin de cualquier error subyacente. La Gestin de Problemas asiste a la de
Incidentes aportando informacin sobre problemas, errores conocidos, trabajos en curso y Soluciones
Temporales.
4.3.4 Gestin de Cambios

Se puede resolver un incidente al implementar un cambio, por ejemplo remplazando un monitor. La Gestin
de Cambios da informacin a la Gestin de Incidentes sobre los cambios programados y sus estados. A su
vez, los cambios pueden provocar incidentes por estar mal implementados o por tener errores. La Gestin de
Cambios se encarga de informar de tales incidentes a la Gestin de Cambios.
4.3.5 Gestin de Niveles de Servicio

La Gestin de Niveles de Servicio supervisa los acuerdos sobre el soporte a proporcionar. La Gestin de
Incidentes debe conocer el Acuerdo de Nivel de Servicio (SLA) para utilizarlo cuando se comunica con los
usuarios. Los registros de incidentes pueden ser utilizados para generar informes que determinen si se esta
cumpliendo con el nivel de servicio acordado.
4.3.6 Gestin de la Disponibilidad

Para medir aspectos relacionados con la disponibilidad de los servicios, la Gestin de la Disponibilidad utiliza
los informes de incidentes y el estado de verificacin que maneja la Gestin de Configuraciones. Se puede
asignar a un servicio el estado de "cado", como un CI/EC en el CMDB. Esta informacin se debe utilizar
para determinar la disponibilidad real de un servicio y el tiempo de respuesta del abastecedor. Esta capacidad
requiere de acciones con marcadores de tiempo a lo largo del progreso de los incidentes, desde la deteccin
inicial hasta el cierre.
4.3.7 Gestin de la Capacidad

Cabe a la Gestin de la Capacidad lo relativo a los incidentes que se provocan por falta de espacio en el disco
o por tiempo de respuesta lento, por ejemplo. Un administrador de sistemas o el sistema por si mismo pueden
sealar estos incidentes en el proceso de Gestin de Incidentes.
La Figura 4.5 ilustra los pasos que incluye el proceso:
-
36
Admisin y registro del incidente - se admite la llamada y se crea un registro del incidente.
Clasificacin y soporte inicial - el incidente se codifica por tipo, estado, impacto, urgencia, prioridad,
SLA, etc. Se puede sugerir al usuario una solucin, aunque sea temporal.
Si la llamada es por una Peticin de Servicio, se inicia el proceso que corresponde.
Comparacin - se investiga si el incidente es conocido, y si se relaciona con un problema o error
conocido, y si existe una solucin o un trabajo relacionado en curso.
Investigacin y Diagnostico - si no hay una solucin conocida, se investiga el incidente.
Resolucin y Recuperacin - una vez que se encontr la solucin, se resuelve el tema.
Cierre - se pregunta al usuario si esta satisfecho con la solucin y se cierra el incidente.
Monitorizacin y seguimiento del progreso - se monitoriza el ciclo entero del incidente, y si se
considera que no se puede resolver el problema a tiempo, se contina con el escalado.
Figura 4.5 Proceso de Gestin de Incidentes
4.4 Actividades
4.4.1 Admisin y registro
En muchos casos ser el Centro de Servicios el que registre los incidentes. Se deben registrar de inmediato los
incidentes que se producen, por las siguientes razones:
-
Ponerse al da con las tareas de registro atrasadas resulta bastante difcil.

La progresin de un incidente slo se puede monitorizar si esta registrado.
El registro de incidentes ayuda al diagnostico de los nuevos incidentes.
La Gestin de Problemas puede utilizar el registro de incidentes para descubrir las causas que los
provocan.
Es ms fcil determinar el impacto si se han registrado todas las llamadas.
Sin registro, no se podrn monitorizar los niveles de servicio conforme a lo acordado.
Al registrar los incidentes de manera inmediata, se pueden evitar situaciones donde muchas personas
estn siguiendo el mismo problema o donde nadie este trabajando para dar por cerrado el incidente.
37
El lugar donde se notifica el incidente determina quien lo informa. Los incidentes pueden notificarse de la
siguiente forma:
-
Por el usuario - quien informa sobre el incidente al Centro de Servicios.

Por un sistema - cuando se captura un problema o un evento en la infraestructura tcnica o en una
aplicacin, como cuando se excede un umbral crtico, el evento se introduce en el sistema de registro de
incidentes como incidente y si fuera necesario se direcciona a un grupo de soporte.
Por un empleado del Centro de Servicios - quien se asegura de registrar el incidente.
Por una persona de otro departamento TI - quien registra el incidente en el sistema de registro de
incidentes o informa de la llamada al Centro de Servicios.
Se debe evitar registrar el mismo incidente dos veces. Por tal motivo, cuando se registra un incidente se
verifica si no hay incidentes similares en curso:
-
Si es as (y si se relacionan con el mismo incidente), se actualiza la informacin o se registra el

incidente por separado y se lo relaciona con el incidente principal. En caso de ser necesario se pueden
corregir el impacto y la prioridad y se agrega la informacin del nuevo usuario.
Si no es as (no resulta igual a los incidentes abiertos), se registra un nuevo incidente.
En ambos casos, el resto del proceso es igual, aunque los pasos a seguir en el primer caso son mucho ms
simples.
Cuando se registra un incidente se emprenden las siguientes actividades:
-
Asignacin de un nmero - en la mayora de los casos el sistema asigna automticamente un nmero de

incidente nico que el usuario utilizara en comunicaciones es futuras.
Registro de informacin de diagnstico bsica - hora, sntomas, usuario, persona encargada del tema,
ubicacin e informacin del servicio y/o hardware afectado.
Complementar la informacin del incidente - con cualquier informacin relevante sobre el incidente
{p. ej. Utilizando un script para recoger mas informacin) o a travs de la CMDB (Generalmente en base
a la relacin definida en la base de datos entre elementos de configuracin).
Alertar - si el incidente tiene un gran impacto, como cuando falla un servidor importante, se debe alertar
a los otros usuarios y departamentos de gestin.
4.4.2 Clasificacin
La clasificacin de los incidentes tiene como meta la categorizacin del incidente para facilitar su
monitorizacin y su registro. Cuanto ms extensivas sean las opciones de clasificacin, mejor. Sin embargo,
esto tambin requiere un mayor nivel de compromiso por parte del personal. A veces se intenta combinar
muchos aspectos de clasificacin en una sola lista -tipo, grupo de soporte y origen-lo que puede resultar
confuso. Es mejor utilizar muchas listas cortas. En esta seccin encontraremos puntos relevantes para la
clasificacin.
Categora
Primero, a los incidentes se les asigna una categora y una subcategora, por ejemplo segn los posibles
orgenes del incidente o el grupo de soporte pertinente:
-
38
Procesamiento central - acceso, sistema, aplicacin.

Red - router, segmento, hub, y direccin IP.
Uso y Funcionalidad - servicio, capacidad, disponibilidad, backup, manual.
Organizacin y Procedimientos - orden, Peticin, soporte, comunicaciones.
Peticin de Servicio - cuando el usuario solicita al Centro de Servicios soporte, entrega, informacin,
consejo o documentacin. Esto puede cubrirse como un proceso aparte o de la misma manera en la que se
trata un incidente.

Prioridad
Luego se asigna la prioridad para garantizar que los grupos de soporte prestan la atencin necesaria al
incidente. La prioridad es un nmero basado en la Urgencia Con qu rapidez se debe resolver? y el Impacto
Cunto dao se causar si no se soluciona rpido?
Prioridad = Urgencia * Impacto.
Servicio
Se puede utilizar una lista para identificar el/los servicios que se relacionan con el incidente, para referirlo/s al
SLA pertinente. Esta lista tendr tambin los tiempos de escalado para los servicios relacionados como lo
determina el SLA.
Grupo de soporte
Si el Centro de Servicios no puede resolver el incidente de inmediato, se asigna un grupo de soporte para que
se encargue del incidente. Este direccionamiento se basa a menudo en la categora del incidente. Cuando se
definen las categoras, se debe considerar la estructura de los grupos de soporte. El correcto direccionamiento
de los incidentes es esencial para la eficaz Gestin de Incidentes.
Uno de los Indicadores de Clave de Rendimiento para la calidad del Proceso de Gestin de Incidentes debera
ser "el nmero de llamadas mal direccionadas".
Tiempo estimado
Segn la prioridad y el SLA, se informar a la persona que llama del tiempo mximo estimado para resolver
el incidente (ciclo horario), y cuando volver a llamar. Estos tiempos son registrados en el sistema.
Nmero de referencia del incidente
Se da al usuario un nmero de incidente para referencias futuras.
Posicin del flujo de trabajo (estado)
El estado del incidente indica su posicin en el flujo de trabajo del incidente. Ejemplos de estados son:
- Nuevo
- Admitido
- Planeado
- Asignado
- Activo
- Suspendido
- Resuelto
- Cerrado
4.4.3 Comparacin
Despus de haber sido clasificado, se investiga si hay registro de un incidente similar previamente, y si existe
una solucin o trabajo en curso. Si el incidente tiene los mismos sntomas que otro problema o error conocido,
se lo puede relacionar.
4.4.4 Investigacin y Diagnostico

El Centro de Servicios o el grupo de soporte direccionan los incidentes para los que no disponen de una
solucin o que van ms all de la experiencia del agente a otro grupo de soporte con ms experiencia o
conocimiento tcnico. El grupo de soporte investigar y resolver el incidente o lo direccionar a otro grupo
de soporte.
Durante el proceso de resolucin, distintos agentes pueden actualizar el registro del incidente con el estado
actual y la informacin sobre las medidas tomadas, clasificacin revisada, tiempo, e identificacin del agente.
39
4.4.5 Resolucin y Recuperacin

Despus de haber completado el anlisis y de haber resuelto el incidente satisfactoriamente, el agente registra
la solucin en el sistema. Para algunas soluciones, se tendr que emitir una Peticin de Cambio (RFC) a la
Gestin de Cambios. En el peor de los casos, si no se encuentra la solucin, el incidente permanece abierto.
4.4.6 Cierre
Una vez que se implemento una solucin satisfactoria para el usuario, el grupo de soporte direcciona el
incidente otra vez al Centro de Servicios. Se contacta a la persona que informo sobre el incidente para
verificar que todo esta resuelto. Si se confirma que el incidente fue resuelto de manera correcta, se da por
cerrado; pero si no es as se vuelve a comenzar desde el lugar adecuado.
Durante el cierre, la categora final, prioridad, servicio(s) afectado(s), y el componente causante (CI) tambin
se deben actualizar.
4.47 Seguimiento de progreso y monitorizacin

En muchos casos, el Centro de Servicios, como dueo de todos los incidentes, es responsable de la
monitorizacin de progreso. En ese caso, el Centro de Servicios tambin debe informar al usuario sobre el
estado del incidente. El feedback con el usuario puede resultar til eras un cambio de estado, de ciclo horario
esperado, y escalamiento. Durante el seguimiento y la monitorizacin puede haber un escalamiento funcional
a otro grupo de soporte, o escalamiento jerrquico para forzar decisiones sobre la resolucin.
4.5 Control del proceso

El control del proceso se basa en los informes de los diferentes grupos designados. El Gestor de Incidente es
responsable de estos informes, como as tambin de la confeccin de la lista de distribucin y del calendario
de informes.
Los informes deben ser muy detallados y adaptados a las necesidades por las siguientes razones:
-
40
Gestor de Incidentes - necesita el informe para:

Identificar las partes faltantes en el proceso
Identificar los conflictos con los acuerdos
Seguir el desarrollo de los procesos
Identificar las tendencias
Gestin de Lnea TI - informe para la gestin del grupo de soporte; tendr que facilitar el control dentro
de cada departamento. Para ello es necesario tener informacin sobre:
El progreso de resolucin del proceso
El ciclo horario del incidente en los distintos grupos de soporte
Gestin de Niveles de Servicio - este informe tendr en primera medida informacin sobre la calidad de
servicios brindados. El Gestor de Niveles de Servicio recibir todos los informes necesarios para que
Nivel de Servicios los informe a los clientes. Los informes a los clientes deben dar informacin que
especifique si se han cumplido los acuerdos con respecto a Niveles de Servicio dentro del proceso de
Gestin de Incidentes.
Gestores de proceso de otros procesos de Gestin de Servicios - los informes para los otros gestores de
otros procesos sern meramente informativos. Por ejemplo, la Gestin de Incidentes podra brindar la
siguiente informacin basada en los informes de incidente:
Nmero de incidentes informados y registrados.
Nmero de incidentes resueltos, subdivididos por la resolucin de tiempo.
Estado de los incidentes sin resolver y el nmero de los incidentes sin solucin.
Incidentes por periodo, grupo de cliente, grupo de soporte y resolucin de acuerdo con el SLA.
Incidentes por categora y prioridad, por grupo de soporte.
4.5.1 Factores crticos para el xito

Una exitosa Gestin de Incidentes necesita:
-
Un CMDB actualizado que ayude a estimar el impacto y la urgencia de los incidentes. De manera
alternativa, esta informacin se puede obtener de los usuarios, pero la informacin no ser tan completa,
puede ser muy subjetiva y llevar ms tiempo.
Una Base de Conocimiento, por ejemplo una base de datos actual de errores problema /conocidos que
describa como reconocer los incidentes, y soluciones y workarounds disponibles. Aqu tambin deben
incluirse la base de datos de los proveedores.
Un sistema bien automatizado para registrar, seguir y monitorear los incidentes.
Fuertes vnculos con la Gestin de Niveles de Servicio para garantizar adecuadas prioridades y
apropiados tiempos de resolucin.
4.5.2 Indicadores de Rendimiento

La evaluacin de procesos de rendimiento necesita de parmetros claramente definidos y objetivos
mensurables, a menudo llamados Indicadores de Rendimiento. Estos se informan con regularidad, por
ejemplo todas las semanas, para elaborar datos para el historial que puedan utilizarse para identificar las
tendencias.
Ejemplos de tales parmetros incluyen:
-
Nmero total de incidentes.

Tiempo de resolucin promedio.
Tiempo de resolucin promedio por prioridad.
Promedios resueltos dentro de los parmetros del SLA.
Porcentaje de incidentes resueltos por la primera lnea de soporte (sin direccionar).
Coste de soporte promedio por incidente. '
Incidentes resueltos por estacin de trabajo o por agente de Mesa de Servicio.
Incidentes resueltos sin visitar al usuario.
Nmero de incidentes (o porcentaje) con clasificacin inicial incorrecta.
Nmero de incidentes (o porcentaje) mal direccionados.
4.5.3 Funciones y rotes

Los procesos cortan la jerarqua horizontalmente. Esto solo se logra si se hace una correcta descripcin de las
responsabilidades y las autoridades asociadas con la implementacin. Para brindar flexibilidad puede ser til
utilizar un planteamiento basado en roles. En organizaciones mas pequeas, o para reducir costes, los roles se
pueden combinar, por ejemplo la Gestin de Cambios con la Gestin de Configuraciones.
Gestor de Incidentes
En muchas organizaciones se asigna el papel del Gestor de Incidentes al Gestor de Mesa de Ayuda.
El Gestor de Incidentes es responsable de:
-
Monitorear la eficacia y eficiencia de los procesos.

Controlar el trabajo de los grupos de soporte.
Hacer recomendaciones para mejorar.
Desarrollar y mantener el sistema de Gestin de Incidentes.
Personal del grupo de soporte

- La primera lnea de soporte es responsable del registro, clasificacin, comparacin, direccionamiento,
resolucin y cierre de los incidentes.
- Los otros grupos de soporte se encargan principalmente de la investigacin, diagnstico y recuperacin,
todo dentro del set de prioridades.
41
4.6 Costes y problemas

4.6.1 Costes
Los costes asociados con la Gestin de Incidentes incluyen la implementacin inicial de costes, tales como la
definicin de los procesos, capacitacin e instruccin del personal, y la seleccin y compra de las
herramientas para dar soporte al sistema. La seleccin de las herramientas puede tomar tiempo. Adems hay
costes de funcionamiento asociados con el personal y el uso de las herramientas.
Estos costes dependen mucho de la estructura de la Gestin de Incidentes, la escala de actividades,
responsabilidades, y la cantidad de lugares.
4.6.2 Problemas
La introduccin e implementacin de la Gestin de Incidentes puede verse afectada por los siguientes
problemas:
-
42
Usuarios y personal de TI omiten los procedimientos de la Gestin de Incidentes - si los usuarios

resuelven los problemas por si mismos, o se contactan directamente con personal especializado, sin tener
en cuenta los procedimientos, la organizacin TI no tendr informacin sobre el nivel de servicio y la
cantidad de errores. De igual manera, los informes de la gestin no harn una clara descripcin de la
situacin.
Sobrecarga y acumulacin de incidentes - si de repente hay gran cantidad de incidentes, el tiempo no
ser suficiente y los incidentes no sern bien registrados. Esto se produce cuando antes de ingresar la
informacin se debe atender al prximo usuario. No se describe con precisin el incidente y los
procedimientos para ubicar y derivar los incidentes no se siguen como corresponde. En consecuencia, la
resolucin se vuelve ineficaz y la carga de trabajo se incrementa an ms. Si el nmero de incidentes
aumenta demasiado, un procedimiento para emplear capacidad de reserva puede prevenir la sobrecarga.
Escalado - en la Gestin de Incidentes, los incidentes que no se pueden resolver rpidamente pueden
escalar. Demasiados escalados pueden tener un efecto adverso en los especialistas que son distrados de
sus trabajos regulares.
Falta de un Catlogo de Servicios y de Acuerdos de Nivel de Servicio - si no se encuentran claramente
definidos los servicios y los productos a los que se da soporte, ser difcil para la Gestin de Incidentes
negarse a ayudar a los usuarios.
Falta de compromiso - solucionar los incidentes utilizando un planteamiento basado en el proceso
requiere por lo general cambios en la cultura y un mayor nivel de compromiso de los empleados. Esto
puede generar alta resistencia dentro de la organizacin. Una Gestin de Incidentes precisa de un
verdadero compromiso por parte del personal.
Captulo 5:
Gestin de Problemas
5.1 Introduccin
Como leyera en el captulo anterior, la Gestin de Incidentes acta cuando hay un incidente, y finaliza cuando
la situacin ha sido recuperada. Esto significa que la causa de raz del incidente no siempre est al descubierto
y que el incidente se puede repetir.
La Gestin de Problemas investiga la infraestructura y los registros disponibles, incluyendo la Base de Datos
de Incidentes, para identificar las causas reales y los errores potenciales en la provisin de los servicios. Estas
investigaciones son necesarias porque la infraestructura es compleja y distribuida, y los nexos entre los
incidentes puede que no resulten tan obvios. Por ejemplo, muchos errores pueden encontrarse en la base del
problema, mientras que las definiciones de gran cantidad de problemas pueden estar asociadas con el mismo
error. Primero se debe identificar la causa.
Una vez que identificada la causa principal y documentada una solucin temporal, el problema se transforma
en un error conocido. Se puede emitir Peticin de Cambio (RFC) para eliminar la causa. Aun despus de esto,
la Gestin de Problemas contina con el seguimiento y la monitorizacin de los errores conocidos en la
infraestructura. Por tal razn, se registra la informacin sobre los errores conocidos, sus sntomas y las
soluciones disponibles.
5.1.1 Definiciones de "problema" y "error conocido"

La figura 5.1 muestra la relacin entre un problema, un error conocido y RFC, y define estos trminos.
Figura 5.1 Relacin entre problemas y errores conocidos (Fuente: OGC)
5.1.2 Relacin con la Gestin de Incidentes

La Gestin de Problemas brinda soporte a la de Incidentes suministrando soluciones temporales
(workarounds) y reparaciones rpidas (quick fixes), pero no es responsable de solucionar el incidente.
La Gestin de Incidentes apunta a la rpida solucin del error, de cualquier manera, incluyendo una solucin
temporal, mientras que la Gestin de Problemas se toma el tiempo para investigar, identificar la causa raz y
eliminarla. Un incidente jams debe "transformarse" en un problema.
43
Gestin de Problemas
Sin embargo, se puede definir un problema relacionado adems del incidente. As, al investigar un problema
se puede llegar a la solucin de un incidente actual que todava esta sin resolver.
La Figura 5.2 muestra la relacin entre incidentes, problemas, errores conocidos y cambios.
Figura 5.2 Relaciones entre Gestin de Incidentes, Gestin de Problemas y Gestin de Cambios.
5.2 Objetivo
El objetivo de la Gestin de Problemas es descubrir la causa principal de los problemas previniendo as los
incidentes. La Gestin de Problemas realiza actividades proactivas y reactivas. La Gestin de Problemas
reactiva tiende a identificar la causa principal de los incidentes pasados y ofrecen propuestas para mejorar o
rectificar. La Gestin proactiva tiene como objetivo prevenir los incidentes identificando las debilidades en la
infraestructura y proponiendo mtodos para eliminarlos.
La Gestin de Problemas garantiza que:
-
Se identifiquen, documenten, y rastreen los errores a largo plazo.

Se documenten los sntomas y las soluciones permanentes o temporales de los errores.
Se realicen las Peticiones de Cambio pertinentes para modificar la infraestructura.
Se prevengan los nuevos incidentes.
Se elaboren los informes sobre la calidad de la infraestructura y los procesos.
La Gestin de Problemas puede mejorar con rapidez la calidad del servicio reduciendo significativamente el
nmero de incidentes y la carga de trabajo en la organizacin TI. Algunas de las ventajas son:
-
44
Mejor calidad de servicio TI y gestin - ya que se documentan y/o eliminan los errores.
Aumento de la productividad del usuario - por la mejora en la calidad del servicio.
Aumento de la productividad del personal - dado que se documentan las soluciones, hasta el agente de
Gestin de Incidentes ms inexperto puede resolver los incidentes con mayor velocidad y eficacia.
Mejora de la reputacin del servicio TI - dado que aumenta la estabilidad de los servicios, es probable
que los clientes encarguen ms servicios a la organizacin TI.

-
Aumento de conocimiento y aprendizaje operativo y administrativo - la Gestin de Problemas

almacena informacin en el historial que puede utilizarse para identificar tendencias, y que puede servir
para tomar medidas que prevengan nuevos incidentes. La informacin del historial tambin es til para
investigar y diagnosticar y al elaborar RFCs.
Mejora en el registro de incidente - la Gestin de Problemas introduce estndares para registrar y
clasificar los incidentes identificando los problemas y sus sntomas de manera eficaz. Esto tambin
mejora el registro de los incidentes.
Tasas ms altas de resolucin en primera lnea de soporte - el soporte de primera lnea tendra ms
posibilidades de resolver los incidentes porque la Gestin de Problemas brinda soluciones a los
incidentes y a los problemas, y soluciones temporales disponibles en una base de conocimientos.
5.3 El proceso
Las entradas de la Gestin de Problemas son:

-
Registros de Incidentes.
Soluciones temporales definidas por la Gestin de Incidentes.
Detalles de configuracin de la Base de Datos de la Gestin de Configuraciones (CMDB).
Detalles de los abastecedores sobre los productos que se utilizan en la infraestructura, incluyendo los
detalles tcnicos y errores conocidos de esos productos).
Detalles sobre la infraestructura y su comportamiento, como registros de capacidad, mediciones de
rendimiento, informes de Nivel de Servicio, etc.
Las principales actividades de la Gestin de Problemas:

-
Control de Problemas - definir e investigar los problemas.

Control de Errores - seguir los errores conocidos y elevar RFCs.
Gestin de Problemas Proactiva - prevencin de incidentes mediante la mejora de la infraestructura.
Suministro de informacin - informar sobre los resultados y los problemas ms importantes.
La informacin de salida incluye:

-
Errores conocidos.
Peticiones de Cambio (RFCs).
Informes actualizados de los problemas (actualizados con la informacin sobre las soluciones
y/o soluciones temporales (workarounds) ).
Cierre del registro de problema una vez que se elimin la causa raz.
Informacin de gestin (informes y estadsticas).
Figura 5.3 Posicin del proceso de la Gestin de Problemas
45
Gestin de Problemas
Podemos asociar los siguientes procesos a la Gestin de Problemas:
5.3.1 Gestin de Incidentes

La Gestin de Incidentes es un socio muy importante de la Gestin de Problemas. Disponer de informes de
incidentes eficaces resulta esencial para el xito de la Gestin de Problemas, ya que esa informacin se utiliza
para identificar los problemas.
Por otra parte, la Gestin de Problemas da soporte a la Gestin de Incidentes. La Gestin de Problemas
estudia el problema, y hasta que se encuentra la solucin para el mismo puede documentar una solucin
temporal (que se encuentra al estudiar un problema) para tratar el incidente. Una vez identificada la causa y
definido un error conocido, se puede proponer una Reparacin Rpida que prevenga otros inconvenientes por
el momento, o que reduzca el dao causado por un incidente. Si es posible, la Gestin de Problemas registrar
una RFC que permita llegar a una solucin definitiva.
Nota: tanto la Gestin de Incidentes como la de Problemas pueden aplicar soluciones temporales

La Gestin de Cambios es responsable de controlar la implementacin de los cambios, incluso de las RFCs
propuestas por la Gestin de Problemas para eliminar problemas. Esta gestin tiene a su cargo el anlisis del
impacto y los recursos necesarios, planificacin, coordinacin y evaluacin de los cambios solicitados, como
as tambin de informar a la Gestin de Problemas sobre el progreso y el cumplimiento de los cambios
correctivos. Dichos cambios son evaluados en comn con la Gestin de Problemas. Ello da como resultado la
Revisin Post Implementacin (PIR), tras la que errores proceso de Control de Errores puede cerrar los
errores conocidos, y los registros de incidente pertinentes.

La Gestin de Configuraciones brinda informacin fundamental sobre los elementos de la infraestructura,
configuraciones de hardware y software, servicios, y otras relaciones tales como "esta conectado con",
"usuarios", y "forma parte de". Estas relaciones son de vital inters para las investigaciones de la Gestin de
Problemas.

La Gestin de la Disponibilidad tiende a planear y hacer realidad los niveles de disponibilidad convenidos, y
aporta informacin a la Gestin de Problemas. La Gestin de Problemas ayuda a la de Disponibilidad
identificando las causas de falta de acceso y remedindolas. La Gestin de la Disponibilidad dirige el diseo y
la arquitectura de la infraestructura y se encarga de prevenir los problemas e incidentes optimizando la
planificacin de la disponibilidad y la monitorizacin.

La Gestin de la Capacidad optimiza el uso de los recursos TI y suministra a la Gestin de Problemas
informacin esencial, necesaria para definir los problemas. La Gestin de Problemas ayuda a la de Capacidad
identificando las causas de los problemas relacionados con capacidad y proponiendo los cambios necesarios
para rectificarlos.

La Gestin de Niveles de Servicio abarca la negociacin y la concrecin de los acuerdos sobre la calidad de
los servicios TI y la provisin de los mismos. La Gestin de Niveles de Servicio da informacin a la de
Problemas que se utiliza para definir los problemas. Los procedimientos de la Gestin de Problemas deben
contribuir con los estndares de calidad acordados. La Gestin de Problemas asiste tambin a la Gestin
Financiera y a la de Continuidad de Servicios TI.
46
5.4 Actividades
5.4.1 Control de Problemas
Con esta actividad se espera identificar los problemas e investigar sus causas. Lo imperativo para Control de
Problemas es avanzar con el problema para que se convierta en un error conocido al diagnosticar la causa
principal del mismo. Las actividades de Control de Problemas se pueden observar en la Figura 5.4
Figura 5.4 Control de Problemas (fuente: OGC)
Identificacin y registro del Problema

En principio, cualquier incidente de causa desconocida debe asociarse con un problema. Sin embargo, esto
por lo general slo valdr la pena si el incidente se produce frecuentemente o si se espera que se repita, o si
hay un nico incidente grave.
La actividad de "identificar problemas" se encarga a los Coordinadores de Problemas. No obstante, personal
que no esta involucrado en forma directa con la identificacin del problema, como el personal de Gestin de
la Capacidad puede identificar uno. Sus hallazgos tambin deben ser registrados como problemas.
Esta tarea de identificacin de problemas es quizs una de las ms difciles de todo el proceso de Gestin de
Problemas, ya que es necesario utilizar todas las fuentes disponibles para inferir la existencia de un problema.
La principal fuente de informacin ser la Base de Datos de registros de Incidentes y para llevar a cabo esta
actividad ser de vital importancia que el personal que gestiona incidentes realice una correcta clasificacin
de los incidentes y sobre todo documente correctamente el tipo de cierre que se ha dado al incidente. Todos
aquellos incidentes que se han cerrado aplicando una solucin temporal o de los que no se ha concluido una
causa raz clara son susceptibles de ser analizados por los Coordinadores de Problemas para su registro.
Los detalles del problema son similares a los del incidente, pero en este caso no es necesario incluir
informacin sobre el usuario, etc. Sin embargo, se deben identificar los incidentes relacionados con el
problema.
Ejemplos de instancias cuando se identifican problemas:
-
El anlisis de los detalles de los incidentes indican que un incidente se repite, y provoca un volumen o
tendencia significativa.
El anlisis de la infraestructura identifica las reas dbiles donde se podran originar nuevos incidentes
(tambin analizados por la Gestin de la Disponibilidad y de Capacidad).
Cuando se produce un incidente serio que requiere de una solucin permanente, para evitar que se repita
en el futuro.
Los Niveles de Servicio estn amenazados (capacidad, rendimiento, costes, etc.).
Los nuevos incidentes no pueden relacionarse con problemas existentes o errores conocidos.
Los incidentes registrados no pueden relacionarse con un problema existente o con un error conocido.
47
Gestin de Problemas
El anlisis de tendencias puede descubrir reas que necesitan mayor atencin. Los esfuerzos adicionales se
pueden expresar en trminos de coste y beneficio para la organizacin. Por ejemplo, al identificar las reas
que necesitan ms soporte y determinan cun relevantes son para los servicios que brindan.
Esta evaluacin puede basarse en el "factor dolor" de los incidentes, que toma en cuenta lo siguiente:
-
Coste de los incidentes para las actividades del negocio.

Nmero de incidentes.
Nmero de usuarios y de procesos del negocio afectados.
Tiempo y coste necesarios para resolver los incidentes.
Clasificacin y distribucin
Los problemas se pueden clasificar por rea (categora). La identificacin seala al nivel mas bajo de CIs que
afecta el problema. La clasificacin debe acompaarse de un anlisis de impacto, que no es ms que la
seriedad del problema y su efecto sobre los servicios (urgencia e impacto). Luego se asigna una prioridad, de
la misma manera que se hace con el proceso de Gestin de Incidentes.
Con base en esa clasificacin se asignan el personal y los recursos, y se dispone del tiempo necesario para
resolver el problema.
La clasificacin incluye:
Categora - identificar el dominio pertinente, por ejemplo el hardware o software.
Impacto - sobre el proceso del negocio.
Urgencia - grado hasta el que es posible postergar la solucin.
Prioridad - combinacin de urgencia, impacto, riesgo y recursos necesarios.
Estado - problema, error conocido, resuelto.
La clasificacin no es esttica, por lo que puede cambiar durante el ciclo de vida de un problema.
Por ejemplo, la disponibilidad de una solucin temporal o de una reparacin rpida puede reducir la urgencia
de un problema, mientras los nuevos incidentes pueden aumentar el impacto de un problema.
Investigacin y diagnostico
La investigacin y el diagnstico son una fase reiterativa se repite muchas veces, acercndose cada vez ms
al resultado esperado. A menudo, se intenta reproducir el incidente en un entorno de prueba. Puede ser
necesario contar con mas expertos, p. ej. Especialistas de un grupo de soporte para asistir con el anlisis y el
diagnstico del problema.
Los problemas no slo son provocados por el hardware y el software. Pueden ser causa de un error en la
documentacin, un error humano o de procedimiento, como la descarga de una versin de software errnea.
Por tal razn puede ser til incluir los procedimientos y la documentacin en la CMDB y subordinarlos al
proceso de Gestin de Versiones. Gran cantidad de errores pueden deberse a los componentes de la
infraestructura.
Una vez que se conoce la causa del problema, que se han identificado el CI o la combinacin de los CIs, se
puede establecer un nexo entre el CI y el/los incidente(s) para luego definir un error conocido. Paso seguido,
la Gestin de Problemas contina con las actividades de Control de Errores.
Fuentes de error en otros entornos
En muchos casos, los errores slo se pueden identificar en el entorno de produccin. Sin embargo, los
productos del entorno de desarrollo (proveedores externos o desarrolladores internos) pueden en realidad
contener errores conocidos ("bugs"). Nota: Para una organizacin de desarrollo el entorno de desarrollo de
software es su entorno de produccin.
48

Por lo general, el entorno de desarrollo y los abastecedores debe especificar los errores que contiene la
versin especificada. Las revistas de informtica traen a menudo informacin sobre los bugs/problemas de los
productos populares. Algunos fabricantes ofrecen base de datos de conocimiento de sus productos que
contienen los errores conocidos para esos productos.
Si el error conocido en el producto suministrado no es demasiado serio, o si existe un imperativo del negocio
para avanzar con la descarga a pesar de la falla, se puede decidir usar el tem desarrollado en el entorno de
produccin, siendo imprescindible que los errores conocidos se incluyan en el Control de Errores. Se da un
enlace a la Gestin de Incidentes para garantizar que los incidentes que resulten de la implementacin puedan
ser reorganizados rpidamente. Si fuera necesario, tambin se puede proporcionar una solucin temporal o
reparacin rpida. Antes de empezar con la implementacin, la Gestin de Cambios deber decidir si estos
errores conocidos son aceptables al realizar el anlisis de Riesgo e Impacto. Tal decisin se toma a menudo
bajo presin porque los usuarios se encuentran esperando las nuevas funciones y no suelen ser conscientes del
impacto que puede provocar la existencia de estos errores conocidos.
5.4.2 Control de Errores

El Control de Errores comprende la monitorizacin y la rectificacin de los errores conocidos hasta que son
resueltos con xito, si es posible y apropiado. Control de Errores logra este objetivo elevando Peticiones de
Cambio a la Gestin de Cambios, y evaluando los cambios en una Revisin Post Implementacin (PIR).
Control de Errores realiza el seguimiento de todos los errores conocidos desde su identificacin hasta su
resolucin. El Control de Errores puede abarcar varios departamentos y comprende los entornos de
produccin y desarrollo.
Figura 5.5 Control de Errores (fuente: OGC)
Identificacin de errores y registro

Una vez que se establece la causa del problema y se conoce el CI pertinente, se asigna el estado de "error
conocido" y comienza el proceso de Control de Errores. En muchos casos tambin se conocer una solucin
temporal para el problema, an si este se origino en el rea de desarrollo. A pesar de esto, muchas veces
todava ser necesario encontrar esta Solucin Temporal. Si todava hay incidentes abiertos sern
comunicados a la Gestin de Incidentes. As, la solucin temporal podr utilizarse en la resolucin de los
incidentes relacionados con el problema.
49
Gestin de Problemas
Investigando una solucin
El personal involucrado en la Gestin de Problemas evala lo necesario para resolver el error conocido.
Comparan distintas soluciones, considerando los Acuerdos de Nivel de Servicio, costes y beneficios.
Determinan el impacto y la urgencia de la RFC. Todas las actividades de solucin de ser registradas y deben
existir los medios para realizar el seguimiento de los problemas (con estatus de error conocido) y determinar
su estado.
Reparacin de emergencia
Durante el proceso, puede ser necesario aprobar una reparacin de emergencia si el error conocido esta
provocando incidentes graves. Si la reparacin de emergencia necesita de una modificacin, se deber emitir
primero una RFC. Si el tema es muy serio y la demora resulta inaceptable, se tendr que seguir el
procedimiento de RFC urgente.
Definicin de la solucin seleccionada
La solucin ptima se determin en el paso previo. Sin embargo, puede optarse por no arreglar el error
conocido, p. ej. porque no existe la justificacin del negocio para hacer tal cosa. Por ejemplo, una empresa
que tiene problemas con su sistema ERP desarrollado en la misma empresa puede haber dado una moratoria a
todos los cdigos de reparacin del problema existente, porque la empresa ha tomado la decisin estratgica
de cambiar a SAP a fin de ao. Como en ste, y otros casos similares, el coste de implementar la correccin
del problema puede no redundar en beneficios equivalentes. En otros casos, el impacto es aceptable, el
incidente puede remediarse fcilmente aplicando una solucin temporal o su repeticin resulta poco probable.
En otras ocasiones, ser necesario un esfuerzo desproporcionado para remediar el error conocido. Cualquiera
sea la decisin, se debe registrar el error conocido para que la Gestin de Incidentes pueda usarlo y se deben
documentar las decisiones tomadas, normalmente en la RFC relacionada.
Una vez que se eligi la solucin, habr informacin suficiente para elevar una RFC. Luego, la Gestin de
Cambios implementa la correccin del error conocido.
Revisin Post Implementacin (PIR)
Antes de cerrar el problema se debe revisar el cambio con el que se propone eliminar el error conocido en una
Revisin Post Implementacin (PIR). Si el cambio logr el objetivo se puede cerrar el problema. En la Base
de Datos de Problemas, se cambia el estatus al de "resuelto". Se informa a la Gestin de Incidentes para que
todo incidente relacionado tambin sea cerrado si precede.
Nota: Muchas organizaciones implementan el proceso para que slo se cierre el problema si los incidentes
asociados han sido cerrados (y as verificar con el cliente el cierre) sino, el problema se tendr que reabrir si
no se pueden cerrar los incidentes asociados.
Seguimiento y monitorizacin
Esta actividad monitoriza el progreso de los problemas y los errores conocidos durante todas las etapas del
proceso de Control de Problemas y Control de Errores.
Los objetivos son:
-
Determinar si la seriedad o la urgencia del problema vara, creando por lo tanto la necesidad de ajustar la
prioridad asignada.
Monitorizar el progreso de identificacin e implementacin de la solucin, y monitorizar si la RFC se
implement de manera correcta. Por tal razn la Gestin de Cambios informa regularmente a Control de
Errores sobre el progreso de las RFCs que ha recibido.
Aportar informacin
Durante el proceso, se da informacin a la Gestin de Incidentes sobre las soluciones temporales y las
reparaciones rpidas generadas. Tambin es posible informar a los usuarios. Aunque la Gestin de Problemas
proporciona informacin, ser el Centro de Servicios quien la distribuya. La Gestin de Problemas utiliza la
CMDB para decidir que informacin se debe dar y a quien. El SLA tambin puede aportar informacin sobre
lo que se debe comunicar y a quien.
50
5.4.3 Gestin de Problemas Proactiva

Por lo general, la Gestin de Problemas Proactiva tiene a su cargo la calidad de la infraestructura. La Gestin
de Problemas Proactiva (es decir la prevencin de problemas) se concentra en el anlisis de tendencia y la
identificacin potencial de incidentes antes de que ocurran. Esto se realiza mirando los componentes que son
dbiles o que estn sobrecargados. Si hay muchos dominios, se harn intentos para prevenir que los errores
que se producen en un dominio se repitan en otros.
Se pueden descubrir e investigar las debilidades de los componentes de infraestructura.

5.5.1 Informes de Gestin e Indicadores de Rendimiento
El xito de la Gestin de Problemas se demuestra a travs de:
-
La reduccin de la cantidad de incidentes, resolviendo problemas.

La reduccin del tiempo necesario para resolver los problemas.
Disminucin de otros costes asociados con la resolucin.
Los parmetros del proceso tambin pueden ser informados a fines de gestin interna, para evaluar
y controlar la eficacia de la Gestin de Problemas.
Los informes de la Gestin de Problemas pueden ser extensivos y cubrir los siguientes temas:
-
Informe de tiempo - dividido en Control de Problemas, Control de Errores y Gestin de Problemas

Proactiva y por grupo de soporte y abastecedor.
Calidad del producto - los detalles del incidente, problema y error conocido pueden utilizarse para
identificar los productos afectados por los errores frecuentes, y para determinar si los abastecedores
pueden tener obligaciones contractuales asociadas.
Eficacia de la Gestin de Problemas - detalles sobre la cantidad de incidentes, antes y despus de
resolver un problema, problemas registrados, cantidad de RFCs elevados, y errores conocidos resueltos.
Relacin entre la Gestin de Problemas reactiva y proactiva - aumentar la intervencin proactiva en
vez de reaccionar ante los incidentes muestra un incremento en la madurez del proceso.
Calidad de los productos en desarrollo - los productos entregados por el entorno de desarrollo deben
ser de alta calidad; de otra manera pueden provocar nuevos problemas. Los informes sobre los nuevos
productos y sus errores conocidos son relevantes para la monitorizacin de la calidad de los productos.
Estatus y Planes de Accin para problemas abiertos - resumen de lo que se ha hecho hasta el
momento, y que se har a futuro para progresar con los problemas ms importantes, incluyendo las RFCs
planeadas y el tiempo y los recursos necesarios.
Propuestas para mejorar la Gestin de Problemas - si la informacin sobre los factores anteriormente
mencionados no cumple con los objetivos del Plan de Calidad de Servicio, se puede proponer el registro,
la informacin, las actividades proactivas, y los recursos adicionales necesarios.
Se pueden auditar los procesos habitualmente para planificar y mejorar los procesos. Los informes dependen
del alcance de la Gestin de Problemas. Si el alcance se extiende a los productos en desarrollo, la Gestin de
Problemas puede definir y monitorizar los errores conocidos an mientras el software este en desarrollo.
5.5.2 Factores crticos de xito

El xito de la implementacin de la Gestin de Problemas depende de:
-
Eficacia en el registro automatizado de incidentes y del registro del comportamiento de la infraestructura.

Objetivos viables y hacer el mejor uso posible de la experiencia del personal, por ejemplo acordando
sobre su disponibilidad a determinados horarios y reservando tiempo para investigar las causas
principales de los problemas.
51
Gestin de Problemas
-
Es imprescindible contar con una cooperacin eficaz entre la Gestin de Incidentes y la de Problemas. Al
asignar las tareas y las actividades se debe estar al tanto del conflicto entre la Gestin de Incidentes y la
identificacin de las causas de la Gestin de Problemas.
5.5.3 Funciones y roles

Los procesos atraviesan las funciones o los departamentos de la organizacin y su jerarqua. Para lograr
procesos eficaces se debe definir con claridad las responsabilidades y la autoridad asociadas con su
implementacin. Para brindar flexibilidad, puede resultar til adoptar un modelo basado en los roles. En
pequeas organizaciones, o por razones financieras, los roles pueden estar combinados; por ejemplo la
Gestin de Problemas y la de Nivel de Servicio. La ltima vieta en el punto 5.5.2 explica por qu muchas
organizaciones evitan la combinacin del Centro de Servicios / Gestor de Incidentes y Gestor de Problemas.
Gestor de Problemas
El Gestor de Problemas es responsable de todas las actividades de la Gestin de Problemas tales como:
-
Desarrollo y mantenimiento de Control de Problemas y Control de Errores.

Evaluacin de la eficiencia y la eficacia de Control de Problemas y Control de Errores.
Ofrecer informacin administrativa.
Gestionar el personal de la Gestin de Problemas.
Obtener los recursos para las actividades.
Desarrollar y mejorar los sistemas de Control de Problemas y Control de Errores.
Analizar y evaluar la eficacia de la Gestin de Problemas Proactiva.
Roles de Tratamiento de Problemas

Las responsabilidades del personal con roles de tratamiento de problemas incluyen:
-
Responsabilidades reactivas:
Identificar y registrar los problemas analizando los detalles de los incidentes.
Investigar los problemas basndose en su prioridad.
Elevar RFCs.
Realizar el seguimiento del progreso de la resolucin de los errores conocidos.
Aconsejar a la Gestin de Incidentes sobre la existencia de soluciones temporales y de reparaciones
rpidas.
Responsabilidades proactivas:
Identificar tendencias,
Elevar RFC.
Prevenir que los problemas no se extiendan a otros sistemas.
52

5.6.1 Costes
Adems de los costes por soporte y de las herramientas de diagnstico, debemos considerar los costes de
personal. En el pasado, no era comn dejar tiempo para estas actividades. Aparte del personal TI interno
involucrado en la Gestin de Problemas, debe considerarse el coste de contratar expertos adicionales de
abastecedores externos. Sin embargo, los beneficios de estas actividades pueden fcilmente ser ms valiosos
que los costes incurridos.
5.6.2 Problemas
Si es posible se tienen que evitar los siguientes puntos al implementar la Gestin de Problemas:
-
Mala conexin entre la Gestin de Incidentes y la de Problemas - si existe una mala conexin entre
los detalles de los incidentes y el problema y los detalles del error conocido, la Gestin de Incidentes no
estar al tanto de las soluciones temporales de los problemas, y le ser difcil a la Gestin de Problemas
evaluar y seguir los problemas. Habr menos informacin sobre el historial y menos experiencia
documentada sobre la infraestructura TI. El xito de la Gestin de Problemas depende fuertemente de la
creacin de este vnculo.
Mala comunicacin de los errores conocidos del rea de desarrollo a la de produccin el software
y la infraestructura tcnica que se transfieren del entorno de produccin deben venir acompaados de
detalles al respecto de cualquier error conocido. Transmitir el conocimiento de los errores conocidos en el
momento en que se descargan los sistemas evita que la organizacin desperdicie tiempo investigando
errores que ya son conocidos. Por eso, debe haber un intercambio de informacin eficaz tanto entre los
sistemas de almacenamiento como en los de registro, o debe haber un sistema unificado.
Falta de compromiso - si el planteamiento previo era informal, puede haber resistencia a un
planteamiento estricto de la Gestin de Problemas, en particular en cuanto a la documentacin y al
mantenimiento de los registros de historial. Por esa razn, el personal involucrado en las actividades de
Gestin de Problemas deben contar con informacin correcta y eficaz de los progresos en la
implementacin de los procesos.
53
Gestin de Problemas
54
Captulo 6:
6.1 Introduccin
Cada organizacin TI tiene informacin sobre su infraestructura TI. Tal informacin por lo general se
encontrar disponible tras proyectos importantes que se siguen de una auditora y de un Anlisis de Impacto
Sin embargo, lo ms importante es mantener esta informacin actualizada.
La Gestin de Configuraciones se encarga de suministrar detalles fiables y actualizados sobre la
infraestructura TI. Es por dems importante ya que esta informacin no slo incluye detalles sobre elementos
especficos de la infraestructura (Elementos de Configuracin, o CIs), sino sobre cmo estos CIs se relacionan
unos con otros. Estas relaciones son la base del anlisis de impacto y tendrn una importancia vital para la
Gestin de Cambios.
La Gestin de Configuraciones comprueba si los cambios en la infraestructura TI han sido correctamente
registrados, incluyendo la relacin entre CIs, y monitoriza el estado de los componentes para garantizar una
correcta percepcin de las versiones de los Elementos de Configuracin (CIs) en vigor.
Si la Gestin de Configuraciones est bien implementada, puede proporcionar informacin sobre los
siguientes temas:
Informacin financiera y poltica de producto
- Qu componentes TI estn en uso, cuantos de cada modelo (versin), y por cuanto tiempo los hemos
tenido?
- Cules son las tendencias en los diferentes grupos de productos?
- Cul es el valor actual, depreciado de los componentes TI?
- Qu componentes TI se pueden eliminar y cuales necesitan actualizarse?
- Cunto costar reemplazar ciertos componentes TI?
- Qu licencias tenemos, son correctas?
- Qu contratos de mantenimiento deben ser revisados?
- Hasta qu punto est estandarizada nuestra infraestructura?
Correccin de la informacin y evaluacin de impacto
- Qu componentes TI necesitaremos para un procedimiento de recuperacin ante un desastre?
- EI plan de recuperacin para desastre seguir siendo eficaz si se cambian las configuraciones?
- Qu componentes TI se ven afectados por el rollout?
- A que red esta conectado el equipo?
- Qu mdulos de software estn incluidos en cada suite?
- Qu componentes TI se ven afectados por el cambio?
- Qu RFCs estn en consideracin para componentes TI especficos, y que incidentes y problemas han
tenido lugar en el pasado y vienen al caso en la actualidad?
- Qu componentes TI son responsables de los errores conocidos?
- Qu componentes TI han sido adquiridos durante un periodo de un abastecedor en particular?
Provisin de los servicios y fijacin de precio
- Cules son las configuraciones de componentes TI esenciales para ciertos servicios?
- Qu componentes TI se utilizan en un lugar y quienes lo usan?
- Cules son los componentes TI estndar que pueden ordenar los usuarios y a cuales damos soporte
(catalogo de producto)?
55
6.1.1 Conceptos bsicos

En la terminologa de la Gestin de Configuraciones los componentes TI y los servicios brindados con ellos
se conocen como Elementos de Configuracin (CIs). Cada componente TI del que se tiene registro de
existencia y versin es un CI. Como se muestra en la Figura 6.1, los CIs pueden incluir hardware, todo tipo de
software, componentes de red activos y pasivos, servidores, procesadores centrales, documentacin,
procedimientos, servicios y codos los otros componentes TI que deban ser controlados por la organizacin TI.
Si la Gestin de Configuraciones se aplica ms a los Sistemas de Informacin que a las Tecnologas de la
Informacin, la CMDB tambin se puede usar para guardar y controlar los detalles de los usuarios TI, del
staff TI y de las unidades del negocio. Esos CIs tambin debern estar a disposicin de la Gestin de
Cambios, por ejemplo en los procesos de presentacin del personal y de despedida.
Figura 6.1 Elementos de Configuracin
Todos los CIs estn incluidos en la Base de Datos de la Gestin de Configuraciones (CMDB). La CMDB
sigue el rastro de los componentes TI y la relacin entre ellos. En su forma ms bsica, una CMDB puede
consistir en formularios de papel o un conjunto de hojas de clculo.
Los departamentos de desarrollo utilizan a menudo algo similar al CMDB para el control de versiones de
todos los mdulos de programas. Este tipo de control de versiones se suele encontrar incluido en las
plataformas de desarrollo. Una CMDB puede consistir de varias bases de datos fsicas que forman una entidad
lgica, en cuyo caso. Es aconsejable optimizar la integracin entre las diferentes bases de datos.
La CMDB no debe ser confundida con las bases de datos de los programas de administracin de stock o con
las herramientas de auditoria. Los programas de administracin de stock slo brindan informacin limitada
sobre el hardware y el software activo, los componentes de la red y del entorno.
Sin embargo, la CMDB tambin muestra cmo debera ser la infraestructura si todo fuera hecho como se
planea (ver tambin Gestin de Cambios), intuyendo la documentacin. La informacin de la CMDB es de
hecho una administracin de la configuracin autorizada de la infraestructura.
Una lista con las diferencias (deltas) entre la base de datos de la gestin de recursos y la CMDB puede aportar
informacin muy valiosa.
As mismo, una caracterstica muy importante de la CMDB es que representa no slo los Elementos de
Configuracin existentes y todos sus atributos, sino las relaciones entre ellos.
56
La Gestin de Configuraciones no debe ser confundida con la de Activos:

-
La Gestin de Activos - es un proceso contable para monitorizar la depreciacin de los activos que
exceden en precio ciertos lmites, manteniendo registros del precio de compra, depreciacin, unidad del
negocio y localizacin. Un sistema eficaz de Gestin de Activos puede ser la base para poner en marcha
el sistema de Gestin de Configuraciones, ya que puede ser la fuente inicial para poblar la CMDB.
La Gestin de Configuraciones - va ms all, ya que adems mantiene informacin sobre la relacin
entre los CIs (Elementos de Configuracin) y la estandarizacin y la autorizacin de los CIs. La Gestin
de Configuraciones tambin monitoriza el feedback sobre la informacin actual - estado de los
componentes TI, su ubicacin, y los cambios que se les han hecho.
6.2 Objetivos
La Gestin de Configuraciones tiene como objetivo asistir con la administracin del valor econmico de los
servicios TI (una combinacin de requisitos del cliente, calidad y costes) manteniendo un modelo de
infraestructura y de servicios TI lgico, y dando esa informacin a los otros procesos comerciales. La Gestin
de Configuraciones implementa esto identificando, monitorizando, controlando y ofreciendo informacin
sobre los Elementos de Configuracin y sus versiones.
Los objetivos de la Gestin de Configuraciones incluyen:
- Mantener informes fiables de los detalles de los componentes TI y de los servicios que brinda a la
organizacin.
- Proveer informacin y documentacin correctas para ayudar a los otros procesos de la Gestin de
Servicios.
6.2.1 Beneficios
La Gestin de Configuraciones contribuye a que la provisin de servicios de alta calidad en TI mantenga una
relacin de coste/calidad ptima al:
-
Gestionar componentes TI - los componentes TI son esenciales para los servicios. Cada elemento de los
servicios incluir uno o ms CIs y la Gestin de Configuraciones verifica que sucede con ellos.
Servicios comerciales de alta calidad - la Gestin de Configuraciones proporciona informacin a los
procesos de Cambios, identificacin y solucin de problemas y soporte a usuarios. Esto reduce la
cantidad de errores y por lo tanto tambin reduce los costes al evitar la duplicacin de esfuerzos.
Eficacia en la solucin de problemas - la Gestin de Configuraciones proporciona informacin al
respecto de la ubicacin de los CIs afectados y gestiona la modificacin y reemplazo de CIs. Tambin
brinda informacin de tendencias para el proceso de Gestin de Problemas.
Procesamiento de los cambios mas veloz - la Gestin de Configuraciones facilita el anlisis de impacto
rpido y veraz para poder procesar los cambios ms rpida y eficazmente.
Mejor control del software y hardware - se puede combinar el instalaciones de los paquetes,
posiblemente tambin con los rollouts de hardware, y de esa manera evaluar toda la combinacin por
adelantado. La CMDB y las lneas de referencia (tomas instantneas de la infraestructura) se pueden
utilizar para desarrollar planes de distribucin y de evaluacin para grupos especficos.
Mejora de la seguridad - gestionar las versiones utilizadas brinda informacin sobre los cambios
autorizados a los CIs y el uso de las diferentes versiones de software. La informacin de la CMDB
tambin puede ayudar a la correcta gestin del uso de licencias de software.
Cumplimiento de los requisitos legales - cuando se realicen las auditorias y se las compare con la
CMDB se identificaran las copias ilegales. Esto puede aadir un beneficio adicional ya que el software
ilegal puede contener virus. De esta manera, la Gestin de Configuraciones puede prevenir la
introduccin de virus dentro de la organizacin. A pesar de que puede resultar difcil evitar que el
personal introduzca software ilegal contaminado, el hecho de que el staff sepa que pueden ser
descubiertos por la Gestin de Configuraciones, CMDB y las auditoras, y con las medidas disciplinarias
que esto acarrea, puede desalentar esta prctica. Es la idea de no ser descubiertos lo que incita al personal
a romper las reglas.
57
Mayor precisin en la planificacin del gasto - la CMDB puede brindar informacin sobre los costes
de mantenimiento y los contratos, las licencias y fechas de vencimiento.
Mas ayuda a la Gestin de la Disponibilidad y de Capacidad -estos procesos dependen de los detalles
de configuracin correctos para analizar y planear los servicios.
Una base slida para la Gestin de Continuidad de Servicios TI - la CMDB, si existe una copia de
respaldo en un lugar seguro, puede ser de mucha utilidad al restaurar los servicios tras un desastre. La
CMDB tambin es importante para identificar los CIs necesarios para la recuperacin ante desastres,
incluyendo los procedimientos relevantes y los manuales si estn incluidos en la CMDB. El primer paso
para la realizacin de un Plan de Continuidad del Negocio es la elaboracin de un BIA (Business Impact
Analisys). Durante esta fase, la existencia de una CMDB con los datos correctamente actualizados ser
de una gran ayuda.
Identificacin de los costes ocultos - normalmente encontraremos en las organizaciones multitud de
registros administrados localmente por las secciones de la organizacin responsables de cada uno de los
procesos. Las duplicidades e inconsistencias entre estos diferentes registros significan costes y riesgos
adicionales. Para facilitar la identificacin de los costes y reducir la carga de trabajo del personal TI se
recomienda que la CMDB se convierta en un proceso coordinado a una cantidad limitada de individuos y
en una base de datos nica a nivel de la organizacin con la informacin centralizada.
6.3 El Proceso
El proceso de registro y modificaciones de la Gestin de Configuraciones incluye mantener informacin sobre
cambios e informacin de los procesos de adquisicin. Los egresos son los registros de los otros procesos y la
gestin TI. Hay otra produccin: en esa la Gestin de Configuraciones brinda datos CMDB para los otros
procesos para tener acceso mientras desarrollan sus actividades.
Gestin de Cambios
Gestin de Versiones
Requerimiento de cambio registra

y asigna un nmero de RDC
Reporte y auditora de
configuraciones
Anlisis
Analiza el impacto y busca consensos
cuando se presentan diferencias entre
asesores
Reporte de reas y CIs impactadas
Aprobacin del cambio
Actualizacin de registros de CIs
CMDB
Librera
de SW
definitiva
(DSL)
Implantacin del cambio

Involucra pruebas previas a la
liberacin
Liberacin y distribucin de nuevas

versiones de SW y HW con
documentacin
Liberacin de SW de la DSL y
actualizacin de la CMDB
Revisin de la implantacin
Evala si el cambio cumpli con las
expectativas
Cierre del cambio
Fin
Figura 6.2: Relaciones entre la CMDB y otros procesos (fuente: OGC)
58
Revisin de los registros de la

CMDB actualizados

La Gestin de Configuraciones tiene vnculos con cierta cantidad de procesos.

La Gestin de Incidentes necesita consultar informacin sobre toda la infraestructura y los servicios
relacionadas con sta. Cuando se registran incidentes, la Gestin de Incidentes necesita acceso a toda la
informacin relativa a los CIs, p. ej. para determinar la ubicacin de los CIs y el propietario, para determinar
si hay un problema o error conocido asociado a una solucin temporal con el CI, para que cliente y para que
servicio se dispuso, y porque SLA est cubierto.

La Gestin de Problemas precisa informacin sobre la complejidad de la infraestructura de TI. Este proceso
debera poder vincular los problemas y los errores conocidos a CIs y utiliza los datos CMDB para analizar
incidentes y problemas. Al realizar la verificacin real de la infraestructura con la configuracin autorizada en
la CMDB puede mostrar desviaciones o defectos en la infraestructura.

La Gestin de Cambios utiliza la CMDB para estimar el impacto de los cambios a implementar. Este proceso
autoriza cambios, y los cambios deben asociarse con los CIs pertinentes, de forma que en cualquier momento
los dems procesos pueden consultar el histrico de cambios realizados sobre un determinado CI (Por
ejemplo, esta informacin cobra una importancia especial durante el anlisis de Problemas). La Gestin de
Cambios es responsable del registro de RFCs, de forma que se convierte tambin en un proveedor de datos
para mantener actualizada la CMDB.
6.3.4 Gestin de Versiones

El proceso de Gestin de Versiones da informacin sobre los planes de despliegue y sobre las versiones
autorizadas, tal como las fechas previstas de versiones mayores y menores. Este proceso proporciona
informacin sobre los cambios implementados. Antes de implementar un cambio pide informacin sobre CIs,
tal como el estado, ubicacin, cdigo de fuente, etc.

La Gestin de Niveles de Servicio necesita informacin sobre las caractersticas del servicio, las relaciones
entre servicios y la infraestructura subyacente. Los datos de SLM tambin se pueden guardar en la CMDB
dentro del CI como atributo. El Nivel de Servicio (p. ej. oro, plata, bronce) se puede registrar contra el
servicio CI, o el componente CI de hardware o software.
6.3.6 Gestin Financiera

La Gestin Financiera necesita informacin sobre el uso de servicios; por ejemplo quin tiene un PC o quin
usa una determinada aplicacin, y combina esto con la informacin de los SLAs para determinar los precios a
cobrar. Este proceso tambin monitoriza los componentes y las inversiones TI (Gestin de Activos).

La Gestin de la Disponibilidad utiliza la CMDB para identificar los CIs que contribuyen al servicio, para
disear planes para los cambios, y para identificar debilidades, por ejemplo usando el Anlisis de Impacto de
Fallo de Componentes (CFIA). La disponibilidad de un servicio (cadena de componentes de la
infraestructura) slo es tan buena como el componente mas dbil (vinculo en la cadena). La Gestin de
Configuraciones da informacin sobre la composicin de la cadena, y de cada elemento.
6.3.8 Gestin de Continuidad de Servicios TI

La Gestin de Continuidad utiliza las configuraciones estndar de la CMDB (lneas de referencia o de base)
para especificar los requisitos de recuperacin ante desastres y evala que estas configuraciones estn
disponibles en el lugar de recuperacin de desastre. As mismo, hay que recordar que en la CMDB no slo
podremos almacenar elementos fsicos o componentes de servicios, sino adems mantendremos datos vitales
para la Gestin de Continuidad como es la documentacin, los procedimientos para la activacin de las
salvaguardas y el Plan de Contingencia.
55

La Gestin de la Capacidad usa datos de la CMDB para planear la optimizacin de la infraestructura TI, para
asignar la carga de trabajo y para desarrollar un plan de capacidad.
6.3.10 Actividades
Aunque, como los otros procesos, la Gestin de Configuraciones tiene un flujo de trabajo lgico, este no se
sigue de una manera tan estricta. Se tiende a desarrollar las actividades en paralelo.
La secuencia que se muestra a continuacin se brinda primero para desarrollar el proceso al introducirlo, y
para procesar e implementar los nuevos requisitos de informacin.
-
Planificacin - determinar la estrategia, poltica u objetivos de los procesos, anlisis de la informacin

disponibles y sus fuentes, identificacin de las herramientas y recursos, creacin de interfaces con otros
procesos, proyectos, abastecedores, etc.
Identificacin - establecer el proceso para mantener la base de datos actualizada. Las actividades
incluyen el desarrollo de modelos de datos para registrar todos los componentes de la infraestructura TI,
las relaciones entre ellos y la informacin sobre sus propietarios o persona responsable, estado y
documentacin disponible. Tambin se deben desarrollar los procedimientos para los nuevos CIs y para
los cambios a CIs. Como las demandas de informacin cambian continuamente, la identificacin de los
datos de configuracin cambia de la misma manera. Es muy importante en esta fase ser previsor al
respecto de los procesos de ITIL que se van a implementar, ya que cada proceso requerir de conjuntos
de informacin diferente. De esta manera, si nicamente se va a poner en prctica la Gestin de
Incidentes, el conjunto de informacin o atributos necesarios de cada CI ser diferente al que se
necesitara en el caso de querer implementar la gestin Financiera.
Control - el control garantiza que la CMDB este actualizada por la sola admisin, registro y
monitorizacin de CIs autorizados e identificados. Control asegura que no se agregue, cambie o
reemplace un CI sin la documentacin que corresponda, como un RFC aprobado o una especificacin
actualizada.
Monitorizacin del estado - guardar detalles actuales e histricos sobre el estado de los CIs durante su
ciclo de vida. Este tipo de monitorizacin se puede usar para identificar estados tales como "en
desarrollo", "en pruebas", "en produccin, "en almacn (stock)" o "eliminado".
Verificacin - verificacin de la Base de Datos de la Gestin de Configuraciones (CMDB) por medio de
auditorias de la infraestructura TI para verificar la existencia de CIs registrados y para evaluar la
exactitud de los registros.
Elaboracin de informes - para dar informacin a los otros procesos e informar sobre las tendencias y
desarrollos en el uso de los CIs.
Estos temas sern tratados en detalle ms adelante.
6.4 Actividades
6.4.1 Planificacin
Los propsitos, objetivos, alcance y prioridades de la Gestin de Configuraciones se deben definir dentro de
la Gestin de Servicios y deben estar en lnea con los objetivos del negocio. El alcance de la Gestin de
Configuraciones viene detallado en el Paso de Identificacin. Los pasos relevantes para implementar la
Gestin de Configuraciones estn fuera del alcance de este libro.
6.4.2 Identificacin
La identificacin se relaciona con la definicin y mantenimiento de las convenciones y los nmeros de
versin de los componentes fsicos de la infraestructura T I , la relacin entre ellos, y los atributos pertinentes.
Las configuraciones de TI de referencia del hardware actuales y futuros se describen en forma de clusters CI.
56

La pregunta general sobre la identificacin de los componentes TI es:
"Qu servicios y componentes asociados a la infraestructura TI debera controlar la Gestin de Servicios, y
qu informacin necesitamos para ellos?
Cuando se desarrolla un sistema de identificacin, se deben tomar decisiones sobre el alcance y el nivel de
detalles de la informacin a registrar. Se debe identificar un propietario o stakeholder para cada propiedad
(caracterstica) a registrar. La pregunta general de arriba puede detallarse para determinar la informacin a
registrar. Ejemplos de tales preguntas son:
-
De qu recursos se dispone para obtener y mantener actualizada la informacin?

Qu madurez tienen nuestros procesos administrativos y logsticos?
A qu niveles se instalan, reemplazan, desarrollan y/o distribuyen los componentes en la organizacin,
independientemente de los componentes ms importantes?
Qu actividades desarrolladas por terceros deberan medirse y estar bajo control?
Qu componentes impactarn los servicios si se ven afectados por un fallo, y que informacin es
pertinente al diagnosticar tales fallos?
Para qu componentes se debe registrar el estado y la historia del estado?
De qu componentes hay varias versiones o variantes utilizadas en la organizacin?
Qu componentes pueden afectar la capacidad y disponibilidad de los servicios despus de un cambio?
Qu componentes de valor deberan contar con seguro contra robo o perdida?
Cules son las necesidades de informacin actuales y futuras de los otros procesos?
Para qu componentes se debera contar con informacin sobre nmero de serie, fecha de compra, y
abastecedor, y que informacin necesita el departamento contable?
Para qu componentes se debe contar con informacin al respecto de contratos de soporte y
mantenimiento y que informacin de este tipo es la requerida por cada uno de los diferentes
abastecedores?
Qu requisitos se asocian con las provisiones del SLA?
Qu informacin se necesita para establecer los precios?
Las ambiciones son realistas o se deberan diferir algunos temas?
Las respuestas a estas preguntas nos darn informacin sobre una serie de actividades. Se debe tomar una
decisin sobre el alcance (extensin) de la CMDB y su nivel de detalle (profundidad). La profundidad se
puede dividir en: el nmero de niveles, las relaciones a rastrear, las convenciones de nomenclatura, y
atributos. Estas reas se tratan ms abajo.
Detallando el Alcance (de Tipos CI)
Cuando se establece una CMDB y cuando se actualiza el modelo de datos, se debe decidir que parte de la
infraestructura TI debe controlar la Gestin de Configuraciones. Por ejemplo, se deberan incluir PDAs,
copiadoras y mquinas de fax en red, teclados y personal TI, o estn fuera del alcance? El alcance de la
Gestin de Configuraciones afecta al alcance de los diagnsticos de la Gestin de Problemas, el anlisis de
impacto de la Gestin de Cambios, la comprobacin de los SLAs, el anlisis y planeamiento de la Gestin de
la Disponibilidad, etc.
De manera adicional, tambin se pueden analizar los servicios TI y su contribucin o impacto en las
actividades comerciales del cliente. Por ltimo, se pueden considerar los acuerdos hechos con los clientes
sobre soporte y servicios.
El alcance se puede dividir en reas con sus propios requisitos y planteamientos. Ejemplos de estas reas son
estaciones de trabajo, comunicaciones de datos, archivos, servicios de impresin y aplicacin, procesamiento
central, base de datos y sistemas TI, y servicios de telefona. Para desarrollar cada rea, se puede establecer un
proyecto independiente en al entorno de gestin pertinente.
57
El alcance de la CMDB puede incluir hardware y software, pero tambin documentacin, como Acuerdos de
Nivel de Servido (SLAs), procedimientos, manuales, especificaciones tcnicas, cartas de organizacin, planes
de personal y proyectos. Como otras CIs, estos documentos estarn presentes fsicamente en todos lados, pero
son ingresados en la CMDB bajo nmero de versin, fecha de publicacin, autor y otra informacin. Por lo
tanto la Gestin de Configuraciones y la de Cambios pueden controlar las caractersticas de estos documentos.
La Figura 6.3 muestra la relacin entre un servicio y los componentes CMDB. Debajo de esto, encontramos
los otros CIs necesarios para el servicio. Mantener la posicin de estas relaciones hace ms fcil determinar el
impacto de los incidentes en los servicios. Tambin es posible generar un informe de todos los componentes
utilizados para un servicio. Esta informacin despus se puede utilizar para planear las mejoras del servicio.
El CI "servicio" tambin puede tener relaciones con otras CIs como acuerdos con el cliente en forma de
Acuerdos de Nivel de Servicio. El Servicio B est por completo fuera del alcance. Esta figura muestra que no
todas los CIs que contribuyen al "servicio A" estn cubiertos por el alcance de la CMDB, lo que significa que
el servicio A no cuenta con soporte total.
Figura 6.3: Alcance de CMDB (fuente: OGC)
Despus de determinar el nmero de reas en el alcance, podemos identificar el ciclo de vida de los elementos
CI a incluir en el alcance. Los CIs se incluyen en la CMDB cuando su estado es "en desarrollo" o "en
produccin", o slo cuando han sido incorporados a la infraestructura? La ventaja de incluir los productos en
desarrollo es que sus especificaciones no pueden cambiarse sin consultar y que su transferencia al ambiente
de gestin ser ms fcil. La monitorizacin del estado de actividad de la Gestin de Configuraciones se ver
afectada por esta eleccin, pero tambin puede ampliar el alcance de la Gestin de Configuraciones en
trminos de ciclo de vida del producto.
Nivel de detalle
Determinar el nivel de detalle de cada tipo de CI es un aspecto importante del establecimiento de la Gestin
de Configuraciones.
Es imposible predeterminar el nivel de detalle o conjunto de atributos que se deben incluir en la CMDB, por
lo que esta decisin ser trascendental para la correcta implantacin del proceso de Gestin de
Configuraciones. Para determinar el nivel de detalle, se disea un plan de las relaciones entre CIs a cubrir en
profundidad en la CMDB, y los nombres y atributos a cubrir.
Se deben sopesar con cuidado, los requisitos, carga de trabajo asociadas y recursos disponibles cuando se
determina la profundidad de las relaciones a cubrir. El nmero de relaciones aumenta exponencialmente con
el nmero de niveles y el coste de mantenimiento posterior puede llegar a ser prohibitivo), ya sea
econmicamente o bien en trminos de esfuerzo. Es importante tener en cuenta que el proceso de Control
58

indicado anteriormente se debe asegurar de que el contenido de la CMDB este al da y sea fiel a la realidad,
por lo que a ms informacin queramos mantener en la CMDB el coste de Control ser mayor.
Relaciones CI
Las relaciones entre CIs son tiles para diagnosticar errores y predecir la disponibilidad de los servicios.
Se pueden registrar muchas relaciones lgicas y fsicas diferentes.
Relaciones fsicas:
- Forma parte de - esta es la relacin padre/hijo del CI, p. ej. un floppy disk forma parte de un PC, y un
modulo de software forma parte de un programa.
- Esta conectado a- p. ej. un PC conectado a un segmento LAN.
- Es necesario para - p. ej. hardware necesario para realizar una aplicacin.
Relaciones lgicas:
- Es copia de - copia de un modelo estndar, lnea de referencia o programa.
- Se relaciona - un procedimiento, manuales y documentacin, un SLA, o rea de cliente.
- Es usado por- p. ej. un CI necesario para brindar un servicio, o un modulo de software que comparten
cierto nmero de programas.
Figura 6.4, Relacin padre/hijo de los Cls(fuente: OGC)
Al respecto de las relaciones entre Elementos de Configuracin, estas son bidireccionales y normalmente
encontraremos que el mero hecho de relacionar un CI 'a con un CI 'b' mediante una relacin R, es decir aRb
hace que aparezca una relacin inversa de forma automtica entre el CI 'b' y el CI a De esta forma, si
decimos que existe la relacin 'a es necesario para b automticamente aparece una relacin inversa que nos
indica que 'b necesita a'. Por ejemplo, podemos tener elementos de Configuracin que representan unas
determinadas aplicaciones y tenemos otros elementos de Configuracin que representan diferentes niveles de
versin de Sistema Operativo.
As podremos relacionar las aplicaciones indicando las diferentes versiones de Sistema Operativo (por
ejemplo, la contabilidad requiere Linux versin 2.3, el control de existencias requiere Linux versin 2.5, la
gestin de nominas requiere Linux versin 2.3) y cuando se vaya a realizar un Cambio sobre la aplicacin de
Contabilidad sabremos los requisitos que tiene, pero si debemos realizar una actualizacin de Sistema
Operativo, podremos realizar el anlisis de Impacto y determinar fcilmente a que aplicaciones vamos a
afectar (Por ejemplo, del caso anterior sabemos que actualizar la versin Linux de 2.3 a 2.4 puede afectar a las
aplicaciones de Contabilidad y de Nominas).
59
Profundidad o Nivel de Detalle
Cuando se define el nivel del sistema, se crea una jerarqua de componentes y elementos. Se seleccionan los
padres CIs y se define el nmero de niveles utilizados para el detalle. El nivel ms alto est conformado por la
infraestructura TI en si misma. El nivel ms bajo es el nivel ms detallado que se debe controlar. Incorporar
un CI a la CMDB slo resulta til si su control y la informacin relacionada tienen algn beneficio para los
procesos ITIL.
Una consideracin a tomar en cuenta para analizar nivel y profundidad es que el CI registrado en la CMDB
debe seguir el proceso formal de Gestin de Cambios para que el cambio tenga efecto.
As, registrar el ratn en la CMDB significa que el pedido de un nuevo mouse debe canalizarse a travs de la
Gestin de Cambios como una RFC y no como una Peticin de Servicio. Esto por lo general resulta una
buena regla y una llamada de atencin para las organizaciones que tienen un nivel de detalle demasiado bajo.
Las siguientes consideraciones generales se aplican a la definicin de la CMDB:
-
A mayor cantidad de niveles, se debe manejar ms cantidad de informacin. Esto incrementa la carga de
trabajo y da como resultado una CMDB ms grande, ms compleja y ms difcil de mantener.
Cuanto menos niveles haya, menor control e informacin se tendr sobre la infraestructura TI.
Si la CMDB no tiene muchos detalles, no se pueden monitorizar los cambios de los componentes principales.
En ese caso, ante cualquier cambio a los componentes de un CI padre se crear una variante3 del CI padre. Por
ejemplo, un PC disponible con dos tipos de disco duro aparecer como Variante A y Variante B. Si hay
demasiados cambios en los componentes hijo, ser difcil y complejo mantener el nmero de variantes. Sin
embargo, si existen mas niveles fundamentales se pueden mantener las variantes en el nivel correcto. Se
pueden registrar ms atributos para los componentes hijo y se los puede asociar con los errores conocidos, y
durante el diagnstico se pueden hacer preguntas tales como: "Qu controlador se necesita para esta opcin
de hardware?", "A qu segmento est conectada esta tarjeta de interfaz de red?", "Qu programas utilizan
esta biblioteca?".
Figura 6.5, Detalle de la CMDB (fuente: OGC)
Las variantes se utilizan si coexisten demasiadas por mas de una CI; p. cj. cuando hay una relacin paralela. Las versiones existen, por ejemplo, si tanto la
versin nueva como la vieja estn en uso al mismo tiempo, p. ej. cuando hay una relacin actual. El uso eficaz de estos dos conceptos ayuda en la
planificacin de cambios. Si se desarrolla cada variante por separado, se debe introducir un nmero de versin de sistema por separado para cada variante.
No resulta una buena alternativa porque hace ms compleja la infraestructura TI y se necesita mas estudio para mantenerla. En muchos casos es aconsejable
continuar desarrollando la fuente de todas las variantes y utilizar la nueva versin donde sea posible para crear las variantes necesarias.
60

Convencin de nomenclatura
Cada CI debe tener un nombre nico y sistemtico para asegurarse que se pueda distinguir de otros CIs. La
opcin ms bsica es un simple sistema de numeracin, posiblemente dividido en lneas para cada rea. Al
crear un nuevo CI se puede generar un nmero nuevo. De ser posible, los nombres deben tener significado
para facilitar la comunicacin con los usuarios, sobre todo en aquellos CIs que vayan a ser utilizados en el
soporte a usuarios. Por ejemplo, cuando un usuario llama al Centro de Atencin a Usuarios indicando que su
PC no funciona, tendr que indicar que PC de todos los que hay en la organizacin es el que no funciona.
Debemos utilizar una nomenclatura cmoda de usar y que el usuario pueda encontrar de una forma sencilla
(no es una buena idea, por ejemplo, utilizar como identificador de un PC un nmero de serie de 10 dgitos).
Los nombres de las convenciones tambin se pueden utilizar para clasificar los CIs, y que de esta manera sean
fciles de identificar durante las auditoras, el mantenimiento y los registros de incidentes.
Algunos de los nombres recomendados por la ITIL para las convenciones son:
-
Las etiquetas fsicas del hardware deben ser de fcil acceso y lectura para los usuarios, y deben ser
difciles de quitar. Se puede acordar con los proveedores de servicio externalizados que soportan los
contratos que se refieran a la informacin presente en las etiquetas. Un usuario tambin debe poder leer la
etiqueta al informar un incidente.
Se debe marcar con un nmero CI, un nmero de versin y una fecha los documentos controlados, tales
como SLAs, procedimientos, y cartas de organizacin.
Se debe almacenar en la DSL (Biblioteca de Software Definitiva) las copias de software, ver el captulo
sobre Gestin de Versiones. Todo el software debe contar con un nmero CI, y si es posible, el software
instalado tambin debe tener un nmero CI, un nmero de versin, y un nmero de copia.
Atributos
Adems de los niveles de estructura CI, las relaciones, y las convenciones sobre los nombres, el desarrollo
detallado de la CMDB tambin debe incluir los atributos. Los atributos son utilizados para almacenar la
informacin pertinente en el CI. Se pueden utilizar los siguientes atributos para crear una CMDB.
ATRIBUTO
DESCRIPCIN
Nmero / etiqueta o cdigo de barra CI
Identificacin nica del CI. Este es a menudo un nmero de registro que le asigna
automticamente la base de datos. Aunque no se pueden etiquetar fsicamente todos los CIs,
todos tienen un nmero nico.
Nmero de identificacin del proveedor en forma de un nmero serial o nmero de licencia.
Herramientas de auditoria a menudo usan sus propios identificadores que pueden ser
diferentes para cada rea. Este atributo provee el vnculo a este ambiente.
Identificacin nica que utiliza el proveedor en el catalogo. Cada versin de un modelo tiene
un nmero diferente, p. ej. PAT-NL-C366-4000-T.
Nombre completo del modelo, que a menudo incluye un identificador de versin, p. ej.
'PIIMMX400MHz'.
Fabricante del CI.
Clasificacin del CI (p. ej. hardware, software, documentacin, etc.).
Descripcin del tipo de CI, brinda detalles sobre la categora, p. ej. Configuracin hardware,
paquete software, o modulo de programa.
Fecha en la que vence la categora.
Nmero de versin del CI.
Ubicacin del CI, p. ej. la biblioteca o media donde residen los CIs del software, o el
lugar/habitacin donde se ubican los CIs de hardware.
Nombre y/o designacin del propietario o persona responsable del CI.
Fecha en la que la persona antes mencionada se hace responsable del CI.
El origen del CI, p. ej. desarrollado en la casa, comprado del proveedor X, etc.
Nmero de licencia o referencia al acuerdo de licencia.
Fecha en la que el CI fue entregado a la organizacin.
Fecha en la que el CI fue entregado y aceptado en la organizacin.
Estado actual del CI, ej. 'en prueba', 'activo', 'eliminado'.
Siguiente estado programado del CI, con la fecha e indicacin de la accin requerida.
Coste de adquisicin del CI.
Valor actual del CI tras la depreciacin.
Campo de texto para comentarios, p. ej. para describir como una variante difiere de otra.
Copia o nmero serial

Nmero de identificacin de herramientas de
auditoria
Nmero del modelo / catalogo de referencia
Nombre del modelo
Fabricante
Categora
Tipo
Fecha de vencimiento de la categora
Nmero de versin
Ubicacin
Propietario responsable
Fecha de Responsabilidad
Origen/proveedor
Licencia
Fecha de entrega
Fecha de aceptacin
Estado (actual)
Estado (programado)
Coste
Valor residual tras la depreciacin
Comentario
Tabla 6.1. Ejemplos de atributos
61
Depende de la herramienta de Gestin de Servicios si la relacin con los incidentes, etc. se incluye en la
CMDB como atributo o de otra manera. En general, los nmeros de las CIs pertinentes se incluyen en el
registro de incidentes, de problemas y de cambios. Cualquiera sea la aproximacin que se elija, las relaciones
que se deben mantener entre los CI y los otros registros de los diferentes procesos son los siguientes:
ATRIBUTO
Nmeros de RFC
Nmeros de Cambios
Nmeros de Problemas
Nmeros de Incidentes
DESCRIPCTON
Nmero(s) de RFC abiertos actualmente o con anterioridad para el CI.
Nmero(s) de cambio(s) abiertos actualmente o con anterioridad para el CI.
Nmero(s) de problema(s) abiertos actualmente o con anterioridad para el CI.
Nmero(s) de incidente(s) relacionados con el CI.
Tabla 6.2 Otros registros relacionados con los CIs
Como se mencionara anteriormente, mantener las relaciones entre los CIs es un trabajo importante de la
Gestin de Configuraciones. Dependiendo del tipo de base de datos, estas relaciones se pueden registrar como
atributos CI, o en una tabla por separado.
ATRIBUTO
Relaciones CI padres
Relaciones CI hijos
Otras relaciones
DESCRIPCION
Clave o nmero CI de los CIs padre.
Clave o nmero CI de los CIs hijo.
Relaciones entre el CI y los otros CIs, aparte de las relaciones padre hijo antes mencionadas, p.
ej. este CI 'usa' o 'esta conectado a'.
Tabla 6.3 Relacin entre los atributos
Algunas bases de datos cuentan con una opcin en forma de texto para registrar los cambios de los contenidos
de campo para mantener un log histrico (Auditoria de cambios sobre los atributos).
Esto puede ser til para los campos marcados como "Estado Actual" para obtener informacin sobre Tiempo
de Parada (downtime), reparadores y mantenimiento. Tambin puede ser til para rastrear la informacin del
propietario.
Adems de los atributos que se mencionan ms arriba, puede ser necesario tener listas de los atributos con
informacin tcnica sobre cada tipo de CI. Cada categora de CI diferente tendr caractersticas diferentes. Por
ejemplo, para una PC: capacidad del disco duro, fabricante BIOS y versin BIOS, RAM, direccin IP, etc.
Muchos sistemas de Gestin de Sistemas o de Gestin de Inventario registrarn esta informacin, y en ese
caso es suficiente crear un enlace al tipo de registro CI para evitar que se duplique la informacin. Sin
embargo, debemos recordar que estos sistemas dan informacin actual sin indicar si los resultados vienen de
un cambio aprobado o sin autorizacin.
Las listas rpidas se pueden usar para facilitar la entrada y la actualizacin de atributos. Tambin se pueden
crear vnculos a otras fuentes confiables, para informacin sobre ubicacin, usuarios, departamentos, nmeros
de telfono, tenedor de presupuesto, y nmeros de presupuesto. Existen muchas opciones, pero se debe
considerar la carga de trabajo que implica mantener estos archivos.
Lneas de referencia
Una lnea de referencia de configuraciones es una toma instantnea de un grupo de CIs tomada en punto de
tiempo especfico. Una lnea fundamental de configuracin se puede usar como:
-
62
Un producto autorizado/soportado que pueda ser incorporado a la infraestructura (estas lneas

fundamentales estn incluidas en el catalogo del producto).
CIs estndar para registrar informacin de coste (coste de los elementos).
Puntos de comienzo para desarrollar y evaluar las nuevas configuraciones.
Como un back-out si existieran problemas con las nuevas configuraciones tras los cambios.
Como un estndar para dar configuraciones a los usuarios, p. ej. "una estacin de trabajo estndar".
Como punto de partida para suministrar nuevo software.

Una estacin de trabajo estndar (homologada para la Organizacin) es un ejemplo comn de una lnea de
referencia. Al limitar el nmero de estaciones de trabajo estndar distintas es ms fcil estimar el impacto y
los recursos necesarios para poner en marcha nuevas funciones y mejoras, y para evaluarlas. Las lneas de
referencia tambin se pueden utilizar para establecer una poltica para combinar y planear los cambios, p. ej.
para Releases Empaquetados. Las lneas de referencia ayudan a reducir los costes de gestin y facilitan el
proyecto de planificacin.
El catalogo de producto es otra aplicacin til de las lneas de referencia. Este catalogo enumera las
configuraciones certificadas que se pueden utilizar en la infraestructura TI, y que los usuarios pueden
solicitar. En ese caso, un CI nuevo es una copia del catalogo, con nmero y etiqueta.
Antes de incorporar un modelo o producto nuevo a la infraestructura se lo debe incluir en el catlogo.
Para esto es necesario tomar tres decisiones:
Del negocio - Sirve a los intereses del negocio del usuario?
Finanzas - Los costes de soporte son aceptables?
Impacto - E1 impacto sobre el servicio es aceptable?
Registro
La CMDB en principio est llena de informacin de los registros financieros y de los registros de la
infraestructura TI y se suplementa con la informacin tcnica de los abastecedores. Slo se registra la
informacin con un stakeholder identificado, y la organizacin debe comprometerse a registrarla (p. ej. debe
estar preparada para actualizar la informacin).
6.4.3 Monitorizacin del Estado

El ciclo de vida de un componente se puede dividir en muchas etapas, y se le puede asignar un cdigo de
estado a cada etapa. Esto depende de las caractersticas de la infraestructura TI que la organizacin quiera
registrar. Llevar un registro de la fecha de cada cambio de estado puede ser una fuente de informacin muy
til sobre el ciclo de vida de un producto: fecha de orden, de instalacin, y las necesidades de mantenimiento
y soporte.
Figura 6.6 Ejemplo de la monitorizacin del CI (fuente: OGC)
El estado de un componente tambin puede determinar lo que se puede hacer con el. Por ejemplo, si se rastrea
el estado de partes no operacionales, este hardware no puede cambiar de lugar sin previa consulta, por
ejemplo como parte de un plan de recuperacin ante desastres. Un cambio en el estado de un CI puede ser
producto de un cambio autorizado o sin autorizacin o de un incidente.
Se puede utilizar la siguiente clasificacin de estatus:
Nuevos CIs
- En desarrollo/pedido
- Evaluado
- Aceptado
63
CIs Existentes
- Recibido
- RFC abierta para la CI, nueva versin pedida
- El cambio se incluyo y se aprob en los planes, se proveer una nueva CI y documentacin (que tambin
es una CI)
- Mantenimiento en progreso
- Down
CIs Archivadas
- Obsoleto
- Borrado
- Eliminado
- Robado
- Vendido o alquiler vencido
- En almacenamiento de archivo a la espera de donacin, venta o destruccin
- Destruido
Todas CIs
- En stock
- El pedido ha sido recibido, o la versin cambiada esta disponible
- A prueba
- Lanzado para instalar
- Vivo (activo), la CI esta en uso
- Excedente
6.4.4. Control
La informacin debe manejarse de manera eficaz para mantener la CMDB al da. Cuando una actividad
cambia las caractersticas registradas de una CI, o la relacin entre las CIs, el cambio debe quedar asentado en
la CMDB. Nota: los cambios en las caractersticas de las CIs slo pueden realizarse si el cambio fue
autorizado por la Gestin de Cambios; la Gestin de Incidentes slo puede cambiar el estatus de una CI
existente.
La Gestin de Configuraciones controla todos los componentes TI que recibe la organizacin y garantiza que
sean registrados en el sistema. El hardware se puede registrar cundo se pide o cundo se entrega, y el
software cundo se incluye definitivamente en la Biblioteca de Software Definitiva (DSL).
Una de las tareas de control es garantizar que slo se registren las CIs que hayan sido autorizadas y que estn
incluidas en el catalogo de productos. Por tal razn, la Gestin de Configuraciones mantiene fuertes vnculos
con los abastecedores, la Gestin de Incidentes, de Problemas y de Cambios.
Si los cambios coordinados por la Gestin de Cambios se efectan en la estructura TI, la Gestin de
Configuraciones debe incluir la informacin en la CMDB. Aunque las publicaciones de ITIL no son muy
claras al respecto, en la prctica, registrar las RFCs es responsabilidad de la Gestin de Cambios. Los cambios
son la mayor fuente de informacin sobre los cambios en la infraestructura y la actualizacin de la CMDB.
Como tal, la Gestin de Configuraciones impone ciertos requisitos sobre la madurez de los otros procesos en
los departamentos, en particular en la Gestin de Cambios, de produccin y el departamento de compras.
Para garantizar que la situacin real refleje la CMDB autorizada, se monitorizan las siguientes acciones:
- El CI esta presente en la CMDB.
- El CI cambia de estado, p. ej. "activo" o "inactivo" (til para la Gestin de la Disponibilidad).
- El CI cambia de propietario.
- El CI cambia en relacin a otro CI.
- El CI ha sido eliminado.
- El CI tiene otra relacin con un servicio, documentacin u otros Cis.
- Se renueva o modifica la licencia del CI.
- Los detalles del CI se actualizan despus de la auditoria.
64
6.4.5 Verificacin y auditorias

Las auditorias se utilizan para verificar si la CMDB es un reflejo fiel de la situacin actual. Por ejemplo, las
herramientas de auditora pueden analizar automticamente las estaciones de trabajo e informar sobre la
situacin actual y el estado de la infraestructura TI. Esta informacin se puede utilizar para chequear y
actualizar la CMDB. Las auditorias se pueden llevar a cabo en las siguientes situaciones:
-
Despus de implementar la nueva CMDB.

Seis meses despus de la implementacin.
Antes y despus de cambios importantes.
Despus de una recuperacin ante desastres.
En cualquier momento que resulte conveniente.
Se realizan las siguientes preguntas durante una auditoria:

-
Estn todas las RFCs, de todas las etapas de implementacin, registradas en la CMDB, y estn
controlada por la Gestin de Configuraciones?
La CMDB esta actualizada? en caso negativo, Por qu? Qu impacto tiene en la Gestin de Cambios
(anlisis real del impacto de los cambios planificados)?
E1 nombre de los nuevos CIs es acorde con las convenciones de nomenclatura?
Las variantes estn bien utilizadas?
Se han registrado correctamente las configuraciones bsicas, y se dispone de ellas inmediatamente?
Los contenidos de la Biblioteca de Software Definitivo (DSL) y del Depsito de Hardware Definitivo
(DHS) se corresponden con la informacin de la CMDB? En caso negativo, Por qu no?
Las auditorias tambin se pueden hacer al azar, o si la Gestin de Configuraciones piensa que la informacin
no es correcta. Si existe un vnculo con las herramientas de auditora, se pueden generar auditorias o informes
delta casi todos los das para cada rea.
Las herramientas de auditoria no deben estar habilitadas para actualizar automticamente la CMDB cuando se
encuentran discrepancias. Todas las discrepancias indican que los procesos de Gestin de Cambios han sido
pasados por alto y deben ser investigados.
6.5 Control del Proceso

6.5.1 Informes de gestin e indicadores de rendimiento
Los informes de la Gestin de Configuraciones pueden incluir los siguientes elementos:
-
Informacin sobre la calidad de los procesos.

Cantidad de diferencias observadas entre los informes y la situacin encontrada durante una auditoria
(deltas).
Cantidad de ocasiones en las que una configuracin no tena autorizacin.
Cantidad de ocasiones en las que no se pudo encontrar una configuracin registrada.
Diferencias a nivel de atributo descubiertas durante la auditoria.
Tiempo necesario para procesar un pedido para registrar informacin.
Lista de CIs donde se registraron ms de un cierto nmero de incidentes o cambios.
Informacin estadstica sobre la estructura y composicin de la infraestructura TI.
Datos de crecimiento y otra informacin sobre los desarrollos en la infraestructura TI.
Resmenes, registros y propuestas para mejorar, como recomendaciones para cambios en el marco y
nivel de los CIs rastreados por la Gestin de Configuraciones, debido a cambios del negocio, tcnicos, de
precio de mercado y otros.
Lista de costes de personal cuando se implementa el proceso.
65
6.5.2 Factores crticos de xito

Es condicin para que la Gestin de Configuraciones tenga xito que se reciba la informacin necesaria para
mantener la base de datos al da. Esto significa que los vnculos con la Gestin de Cambios deben ser fuertes.
Siempre debe haber un stakeholder que registre las caractersticas.
Al introducir el proceso es esencial que la implementacin se divida en etapas. Si los registros necesarios se
introducen de repente, generalmente se producen fallos porque no se puede instaurar de golpe la disciplina
requerida en la Gestin de Configuraciones. Los registros que se mantienen antes de introducir el proceso
deben ser eliminados para evitar la duplicacin. Cuando se introduce el proceso es importante promover
algunas ventajas claras para la Gestin de Configuraciones (Ganancias Rpidas). Tambin resulta importante
que los elementos registrados del proceso sean entregados al personal que tenga las habilidades necesarias y
la actitud correcta.

Los procesos atraviesan la jerarqua de la organizacin. Esto slo resulta posible si las responsabilidades y las
autoridades asociadas con su implementacin se encuentran bien definidas. Para otorgar flexibilidad, puede
ser til tomar un planteamiento basado en roles y responsabilidades.
En organizaciones pequeas, o por motivos financieros, se pueden combinar los roles: por ejemplo Gestin de
Cambios y de Configuracin. Las tareas de la Gestin de Configuraciones pueden incluir:
-
Propuestas de cambio al alcance y nivel de detalle de la Gestin de Configuraciones.

Asegurar que los procesos de la Gestin de Configuraciones sean comunicados a toda la organizacin.
Proveer personal y capacitacin para los procesos.
Desarrollar el sistema de identificacin y la convencin de nomenclatura.
Evaluar los sistemas existentes e implementar nuevos.
Definir, planificar e implementar la CMDB.
Crear informes.
Organizar auditoras de configuracin.

6.6.1 Costes
Los costes de la introduccin e implementacin de la Gestin de Configuraciones dependen mucho del
alcance y nivel de detalle. Estos costes incluyen el hardware, software y personal. Los costes del hardware y
software dependen de:
-
Hardware necesario adicional, y su configuracin.

Software necesario adicional, y su configuracin.
Coste de las licencias basado en el nmero de usuarios.
Aplicacin y diseo de la base de datos, poblacin, personalizacin e implementacin.
Desarrollo de la base de datos.
Mantenimiento de la base de datos.
Coste de personal adicional asociado al proceso.
Los costes de personal dependen primero del tamao de la organizacin y del nivel de detalle de la CMDB.
66
6.6.2 Problemas
La organizacin TI debe fijar un claro compromiso con las caractersticas a registrar de la infraestructura TI, y
debe brindar los recursos necesarios para esta clase de gestin. La organizacin tambin se debe comprometer
a utilizar la CMDB y a incorporar cualquier dato de importancia y de estructura de cualquier base de datos
pertinente usada antes de la introduccin de la CMDB en la CMDB.
Los siguientes problemas pueden afectar al xito de la implementacin:
-
Alcance de la CMDB o nivel de detalle del CI equivocado - si el alcance de la CMDB es demasiado

estrecho, no se podrn chequear, arreglar, asegurar o restaurar las partes importantes de la infraestructura.
Si el alcance es demasiado amplio, la pesadez de la base de datos y de su mantenimiento ser un
obstculo que har ms lentos todos los procesos de gestin de servicios. En caso de que existan
demasiados niveles, atributos, y relaciones, resultara muy engorroso mantener la CMDB. Pocos detalles
pueden significar informacin de registro insuficiente sobre las CIs y los incidentes, problemas, errores
conocidos y RFCs relacionados.
Sistemas manuales inadecuados - algunas organizaciones desean mantener los registros en papel
durante todo el tiempo que sea posible y slo comprar herramientas automticas cuando su utilizacin se
torna casi imposible. Esto puede originar demoras, confusin, y escasez de personal y recursos. Es mejor
seleccionar una herramienta mas temprano, teniendo en cuenta las necesidades funcionales.
Asumir cambios urgentes - siempre habr situaciones en las que los cambios deban ser implementados
rpidamente. Esto suele suceder fuera de horario de oficina. Si la CMDB tambin resulta pertinente en
esta situacin, es aconsejable registrar el cambio en la CMDB de inmediato, pero la persona a cargo
puede estar ausente. Si es posible esperar hasta la maana siguiente, los registros del cambio y la CMDB
deben actualizarse lo ms pronto posible.
Calendarios demasiado ambiciosos - en caso de que el cronograma para los cambios (RFCs) no de
tiempo a implementar la Gestin de Configuraciones, el trabajo ser demorado y la Gestin de
Configuraciones parecer ser el obstculo. Se deben realizar esquemas realistas en base a experiencias
pasadas.
Aceptacin de la gestin - por ser la Gestin de Configuraciones un proceso relativamente nuevo y no
siempre visible, la gente puede presentar una cierta resistencia. Debe existir un claro compromiso para el
xito de la implantacin. As, el Gestor de Configuraciones debe promover el proceso e informarlo al
resto de la organizacin. La experiencia ensea que los costes del proceso se reducen si se presenta a la
Gestin de Configuraciones como una disciplina separada con un personal dedicado y un gestor
responsable del proceso.
Pasando por alto el proceso - en situaciones de stress o del personal tratara de evitar la Gestin de
Configuraciones. Si la situacin persiste, an despus de dar toda la informacin sobre las desventajas de
dejar de lado el proceso, se deben tomar medidas disciplinarias.
67
68
Captulo 7:
Gestin de Cambios
7.1 Introduccin
El rpido desarrollo de la TI y del mercado muestra que el cambio es ahora una cosa comn. Sin embargo, la
experiencia demuestra que los incidentes que afectan las aplicaciones del negocio tienen por lo general
relacin con cambios. Las causas de tales incidentes son numerosas: pueden ser causa de descuido, falta de
recursos, preparacin insuficiente, pobre anlisis de impacto, y evaluacin incorrecta o dificultades iniciales.
Si los incidentes relacionados con los cambios no se ponen bajo control, el proveedor de servido TI, y por
consiguiente el negocio en s mismo, puede salirse fuera de control. El nmero de incidentes aumenta con
cada incidente que necesita un tratamiento de emergencia, que a su vez puede provocar nuevos incidentes. La
planificacin diaria falla a menudo para tener en cuenta la presin creciente de trabajo (Lo importante deja
paso a lo urgente". Dejamos de realizar las actividades importantes para realizar las actividades urgentes y
por lo tanto las importantes no se realizan nunca). Esto en su momento impactar en la rutina de operacin y
mantenimiento de los servicios TI. La Gestin de Cambios tiende a manejar el proceso de cambio y limitar as
el nmero de incidentes relacionados con los cambios. El lema de la Gestin de Cambios es:
No todo cambio es una mejora, pero toda mejora es un cambio.
La Figura 7.1 muestra el ciclo de cambios como un proceso provisto de propuestas para nuevos desarrollos
(Entrega de Servicio y Gestin de Problemas), cambios (pedidos hechos a la Gestin de Cambios) y
soluciones (Gestin de Problemas):
-
Innovacin y mejora - la introduccin de nuevos servicios y de nuevas capacidades tcnicas en la

infraestructura TI sern responsables de algunos de los errores nuevos, a largo plazo de la infraestructura
TI.
Cambios - cualquier cosa, desde una instalacin menor hasta la reubicacin de un mainframe; si se hace
sin cuidado, los cambios representarn errores a largo plazo en la infraestructura TI.
Medidas correctivas - tienden a corregir los recientemente ingresados errores a largo plazo.
La Gestin de Cambios opera como un control termosttico entre flexibilidad (permitiendo cambios que
pueden llevar a errores a largo plazo) y estabilidad (permitiendo cambios para remediar errores a largo
plazo). Las medidas correctivas reducen el nmero de incidentes y como resultado la presin de trabajo
tambin disminuye.
Figura 71 Entradas al proceso de cambio
69
Gestin de Cambios
7.1.1 Trminos Bsicos

Autoridades en la Gestin de Cambios
Hay dos autoridades en la Gestin de Cambios:
-
El Gestor de Cambios - la persona responsable de filtrar, aceptar y clasificar todas las Peticiones de
Cambio (RFCs). En grandes organizaciones, el Gestor de Cambios puede tener ayudantes, Coordinadores
de Cambios, que lo/la representan al vincularse con las distintas reas de la organizacin. La Gestin de
Cambios es tambin responsable de conseguir la autorizacin necesaria. Hasta cierto punto, el proceso ya
tiene autorizacin por declaracin, pero puede ser preciso acercarse a la Gestin TI (p. ej. Comit
Ejecutivo o de Direccin) por algunos cambios. El Gestor de Cambios tambin es responsable de
planificar y coordinar la implementacin de los cambios.
El Consejo Asesor de Cambio (CAB) - este cuerpo de consulta se rene a menudo para evaluar y
planificar los cambios. Por lo general, slo los cambios ms importantes se presentan ante el CAB. Se
debe designar un CAB/EC (Comit de Emergencia) con autoridad suficiente para tomar decisiones de
emergencia. La membresa del Consejo es flexible e incluye representantes de todas las secciones TI ms
importantes:
Gestor de Cambios (presidencia)
Gestor de (Niveles de) Servido
Representantes del Centro de Servicios y de la Gestin de Problemas
Gestores de Lnea
Gestores del Negocio (o sus representantes) del rea de clientes
Representante(s) de grupo de usuarios
Representantes de Desarrollo de Aplicaciones
Gestores de Software y Sistemas
Representantes de Abastecedores
Alcance de proceso
El alcance de la Gestin de Cambios se determina junto con la de Configuracin, ya que la Gestin de
Configuraciones brinda la informacin para evaluar el impacto de los cambios. Despus de implementar el
cambio, la Gestin de Configuraciones actualizar la CMDB. Si la CMDB tiene informacin sobre mouses y
teclados, el reemplazo de un teclado debe contar como cambio.
Determinar el alcance es una actividad dinmica, porque el alcance puede variar y por lo tanto la informacin
de la CMDB tambin cambiar. Por esa razn el alcance tiene que revisarse continuamente, y los modelos de
datos de la CMDB deben actualizarse al mismo tiempo.
Para garantizar que la Gestin de Cambios y la de Configuracin cooperan de manera eficaz, se deben
registrar los cambios y la informacin relacionada con la CMDB. Se puede asumir que una cantidad de tareas
de administracin de rutina, que estn bien definidas y cubiertas por procedimientos (estandarizados), no
necesitan del control de la Gestin de Cambios. Ejemplos de tales actividades de rutina incluyen el montaje
de cintas para copias de seguridad o la creacin de IDs de usuario. En ese caso, las actividades no se procesan
como cambio, pero se clasifican como Peticiones de Servicio bajo la Gestin de Incidentes. Una evaluacin
cuidadosa de los operadores de rutina puede resultar til para que la Gestin de Cambios no se vuelva
demasiado burocrtica.
Una forma de manejar esto es definir los llamados cambios pre-autorizados (o "categora 0") que estn
registrados (preferentemente por los mismos solicitantes) en la base de datos de cambio, pero no necesitan del
esfuerzo de los procedimientos de la Gestin de Cambios. Por ejemplo, si por lo general se siguen catorce
etapas cuando se contrata personal (establecer una cuenta, instalar su estacin de trabajo, crear su cuenta de email, etc.), esta clase de procedimiento de rutina no requiere el escrutinio que merecen los cambios
importantes en la infraestructura. Como resultado, estas clases de cambios estndar se convierten en una
plantilla repetitiva y se las trata como peticiones de Servicio preautorizadas.
70
7.2 Objetivo
El objetivo de la Gestin de Cambios es garantizar que se utilicen los procedimientos y los mtodos estndar
para que se puedan manejar los cambios con rapidez, con el menor impacto posible en la calidad de servicio.
Todos los cambios deben poder ser identificables, en otras palabras, uno debe poder responder a la pregunta,
"qu cambi?".
7.2.1 Ventajas
Para poder proporcionar servicios TI de manera eficaz, la organizacin debe ser capaz de manejar gran
cantidad de cambios con suavidad y responsabilidad.
Las ventajas especficas de la Gestin de Cambios incluyen:
-
Reduccin del impacto adverso de los cambios en la calidad de los servicios TI.
Mejor estimacin de los costes de los cambios propuestos.
Se tiran atrs pocos cambios y todas los back-outs se implementan con mayor suavidad.
Se obtiene mejor informacin administrativa sobre los cambios, que permite un mejor diagnstico de las
reas de problema.
Mejora en la productividad del usuario a travs de servicios TI ms estables y perfeccionados.
Mejora en la productividad del personal TI, porque no se distraen de sus actividades planificadas por
cambios urgentes o procedimientos de back-out.
Aumento de la capacidad para adaptarse a cambios frecuentes sin desestabilizar el entorno TI.
7.3 El proceso
El proceso de la Gestin de Cambios aprueba o rechaza cada RFC. El Gestor de Cambios posibilita el
proceso, pero es el Consejo Asesor de Cambio (CAB) el que toma las decisiones reales sobre los cambios ms
importantes. El CAB tiene miembros de todas las otras partes de la organizacin, como as tambin clientes y
abastecedores. La Gestin de Configuraciones es la encargada de dar informacin sobre el impacto potencial
de los cambios propuestos.
Figura 7.2 Posicin de la Gestin de Cambios
Las entradas de la Gestin de Cambios incluyen:

-
RFCs
Informacin de la CMDB (especficamente el anlisis de impacto de los cambios)
Informacin de otros procesos (Base de Datos de Capacidad, informacin de presupuestos, etc.)
Planificacin de cambio (Programa Precoz de Cambio: FSC)
Las salidas del proceso incluyen:

- Planificacin de cambio actualizado (Programa Precoz de Cambio: FSC)
- Disparadores de la Gestin de Configuraciones y de Versiones
- Agenda CAB, minutas y acciones
- Informes de la Gestin de Cambios
71
Gestin de Cambios
La Gestin de Cambios tiene las siguientes relaciones con los otros procesos.

La Gestin de Incidentes tiene una relacin bilateral con la Gestin de Cambios. Por un lado, la Gestin de
Cambios pasa los cambios solicitados por la Gestin de Incidentes para que dejen de ser incidentes, o cambios
pedidos por la Gestin de Problemas que eliminan la causa raz de los incidentes. Por otro lado, aunque se
tomen muchas precauciones, la implementacin de cambios an puede derivar en incidentes. Estos pueden
tener relacin con una pobre implementacin, o con usuarios que no estaban bien preparados para el cambio.
El personal pertinente de la Gestin de Incidentes debe estar informado de la implementacin de los cambios,
para que puedan identificar y remediar los incidentes relacionados rpidamente.

La Gestin de Cambios y de Configuracin tienen procesos muy ligados, tanto que los dos procesos se pueden
integrar eficazmente, un paso recomendado en la gua del Servicio de Soporte ITIL.
Los cambios se registran bajo el control de la Gestin de Configuraciones y tambin realiza el anlisis de
impacto de los cambios. La Gestin de Configuraciones identifica las relaciones entre el CI (en el cambio que
se dirige) y los otros CIs, para mostrar que se ve afectado por el cambio.

La relacin entre la Gestin de Cambios y la de Problemas es muy similar a la que manden en la Gestin de
Cambios y la de Incidentes Por un lado los cambios se solicitan generalmente para resolver problemas. Por
otro lado, si la implementacin de los cambios no se encuentra bien controlada, los cambios pueden derivar en
nuevos problemas.
7.3.4 Gestin de Versiones

Los cambios a menudo dan como resultado el desarrollo y la implementacin de un nuevo conjunto de
aplicaciones o infraestructura tcnica. La Gestin de Versiones tiene a su cargo esta implementacin. La
Gestin de Cambios se encarga de controlar el desarrollo de las nuevas versiones de tales sistemas.

La Gestin de Niveles de Servicio tiene que determinar el impacto de los cambios en los servicios y los
procesos de negocio. Segn la situacin, la Gestin de Niveles de Servicio puede contar con un representante
en el CAB. Si un cambio tiene un impacto muy importante o presenta un gran riesgo, se deber discutir
siempre su implementacin y tiempo con el cliente. La Gestin de Cambios informa a la Gestin de Niveles
de Servicio a travs del informe de Disponibilidad Proyectada de Servicio (PSA). En dicho informe, la
Gestin de Cambios enumera los cambios a los SLAs acordados y el impacto del Programa de Cambios a
Futuro (FSC) sobre la disponibilidad de servicio.

La Gestin de la Disponibilidad inicia los cambios que tienden a mejorar la disponibilidad del servicio y
verifica si se obtuvo la mejora que se quera. La Gestin de la Disponibilidad tambin entender sobre la
estimacin del impacto potencial de los cambios, ya que tal impacto podra afectar la disponibilidad del
servicio.

El Gestor de Capacidad ante todo debe preocuparse por el efecto cumulativo de los cambios a lo largo del
tiempo, como el aumento del tiempo de respuesta y la necesidad de mayor capacidad de almacenamiento.
Teniendo como base el Plan de Capacidad, la Gestin de la Capacidad propondr a menudo mejoras y
cambios en forma de RFCs.
72
7.3.8 Gestin de Continuidad de Servicios Tl

Se deben controlar siempre las medidas de prevencin y los planes de recuperacin que garanticen la
continuidad de los servicios, ya que los cambios en la infraestructura pueden transformar un plan en algo
irrealizable o superfluo. La Gestin de Cambios trabaja junto con la Gestin de Continuidad de Servicios TI
para garantizar que la Gestin de Continuidad de Servicios TI conozca todos cambios que pueden afectar los
planes de recuperacin y pueda as tomar las medidas para asegurar que el plan se complete. Adicionalmente,
la Gestin de Continuidad de Servicios deber ser notificada de todos aquellos cambios que puedan afectar a
los CIs o servicios amparados en los planes de continuidad para la revisin y posible modificacin de dichos
planes.
7.3.9 Actividades de la Gestin de Cambios

La Gestin de Cambios utiliza las siguientes actividades para procesar los cambios:
-
Registro - no incluida en las actividades de la Gestin de Cambios, pero con ayuda en este proceso,
porque la Gestin de Cambios es la responsable de garantizar que todos los cambios sean correctamente
registrados.
Aceptacin - filtrar las RFCs y aceptarlas para mayor consideracin.
Clasificacin - clasificar las RFCs por categora y prioridad.
Planificacin - consolidar los cambios, planear su implementacin y los recursos necesarios.
Coordinacin - coordinar la construccin, evaluacin e implementacin del cambio.
Evaluacin - determinar si cada cambio fue exitoso y sacar conclusiones para el prximo evento
(aprendizaje).
Figura 7.3 Actividades de la Gestin de Cambios
73
Gestin de Cambios
7.4 Actividades
7.4.1 Registro
Primero, se deben registrar o anotar todas las RFCs. Cuando se eleva una RFC para solucionar un problema,
tambin se debe registrar el nmero de error conocido.
Qu constituye una RFC?
No todas las peticiones de modificacin son tratadas como un cambio: algunas tareas administrativas
rutinarias que se encuentran bien definidas y estn cubiertas por procedimientos (estandarizados) pero que no
precisan de modificaciones pueden ser tratadas como Peticiones de Servicio (p. ej. cambios "categora 0", ver
7.1.1).
Esto da como resultado la siguiente clasificacin de cambios:
-
Cambios Estndar (en calidad de Peticiones de Servicio) - cambios bien definidos y aprobados, que
estn registrados de manera individual, pero no fueron evaluados por la Gestin de Cambios. Estos
cambios se realizan como rutina (Nota: no todos las Peticiones de Servicio son cambios).
Cambios no Estndar - todos los otros pedidos de modificacin de la infraestructura administrada.
Dnde se originan las RFCs?

Las RFCs conciernen a todos los aspectos de la infraestructura dentro del alcance de los procesos ITIL.
Cualquier persona que trabaje dentro de la infraestructura puede elevar una RFC.
Se pueden identificar varias fuentes de RFCs, tales como:
-
74
Gestin de Problemas - propone soluciones para eliminar errores a largo plazo para estabilizar la
provisin de los servicios.
Clientes - pueden pedir ms, menos u otros servicios. Estas peticiones pueden elevarse directamente
como RFCs, o se los puede canalizar a travs de la Gestin de Niveles de Servicio o de la Gestin de
Relaciones con el Cliente TI.
Poltica - los procesos tcticos y estratgicos del Set de Aprovisionamiento de Servicios y del de
Gestores puede llevar a RFCs a cambiar los servicios. Por ejemplo, la Gestin de Niveles de Servicio, la
Gestin de la Disponibilidad y la Gestin de la Capacidad producen planes anuales para mejorar los
servicios, que despus se elevarn en forma de RFCs.
Legislacin - si se imponen nuevos cambios regulatorios a las actividades del negocio, o si se introducen
nuevos requisitos por seguridad TI, Continuidad Del negocio o Gestin de Licencias. El proceso
correspondiente controla esto.
Abastecedores - los abastecedores ponen a la venta nuevas versiones y actualizaciones de sus productos
e identifican los errores que corrigieron. Tambin pueden comunicar que ya no ofrecen soporte a ciertas
versiones, o que no hay garantas sobre el desempeo de una versin (p. ej. por los problemas del
Milenio). Por esta razn la Gestin de Problemas y la Gestin de la Disponibilidad pueden elaborar una
RFC.
Proyectos - un proyecto siempre provocar un nmero de cambios. La Gestin de Proyectos deber
coordinar esto con la Gestin de Cambios a travs de los procesos pertinentes, tales como Gestin de
Niveles de Servicio, Gestin de la Capacidad, etc.
El resto del personal TI - en principio todos pueden elevar propuestas para mejorar los servicios.
Especficamente, el personal TI puede contribuir al perfeccionamiento de los procedimientos y los
manuales.

Registro de RFC
Aqu hay algunos ejemplos de la informacin que se puede incluir en una RFC:
-
Nmero de identificacin de la RFC.

Nmero de problema/error conocido asociado (si corresponde).
Descripcin e identificacin de los CIs correspondientes.
Motivo del cambio incluyendo la justificacin y el beneficio para el negocio.
Versin actual y nueva del CI a cambiar.
Nombre, ubicacin y nmero de telfono de la persona que realiza la RFC,
Da de emisin.
Recursos y tiempo estimados.
7.4.2 Aceptacin
Despus de registrar la RFC, la Gestin de Cambios har una evaluacin inicial para corroborar si alguna de
las RFCs son poco claras, ilgicas, poco prcticas o innecesarias. Las que as resulten sern rechazadas,
mencionando las razones. La persona que elev el pedido siempre debe tener notificacin de las decisiones
tomadas y contar con la oportunidad de defender su peticin.
Un cambio provoca la modificacin de los datos de la CMDB, por ejemplo:
-
Un cambio en el estado de un CI existente.

Un cambio en las relaciones entre un CI con otros CIs.
Un nuevo CI, o la variacin de un CI existente.
Un nuevo propietario o ubicacin del CI.
S la RFC fuera aceptada, se incluye en un registro del cambio la informacin necesaria para el resto del
procesamiento. Despus se agregar la siguiente informacin al registro:
Prioridad signada.
Evaluacin del impacto de la implementacin y de la no implementacin del Cambio y de los costes
necesarios.
Categora.
Recomendaciones del Gestor de Cambios.
Fecha y hora de la autorizacin.
Fecha estimada para la implementacin del cambio.
Planes de soporte.
Planes de "marcha atrs".
Requisitos de soporte.
Plan de implementacin.
Informacin sobre el constructor y los que la ejecutan.
Fecha y hora real del cambio.
Fecha de evaluacin.
Resultados de la evaluacin y problemas observados.
Razones por las que se rechaz el pedido (si corresponde).
Informacin sobre el escenario y la evaluacin.
7.4.3 Clasificacin
Una vez que se acepta una RFC, se especifica su prioridad y su orden:
-
La prioridad indica qu importancia tiene un cambio frente a las otras RFCs, y deriva de la urgencia y el
impacto del cambio. Si un cambio se produce para corregir un error conocido, la Gestin de Problemas
puede ya haber asignado un cdigo de prioridad. Sin embargo, la Gestin de Cambios asigna el cdigo de
prioridad final despus de considerar las otras RFCs en proceso.
La Gestin de Cambios determina la categora basndose en los impactos y recursos. Esta clasificacin
determina si se dar ms consideracin al pedido, e indica el significado del cambio.
75
Gestin de Cambios
Determinacin de la prioridad
Aqu hay un ejemplo del sistema de prioridad de cdigos:
-
Baja prioridad - se necesita un cambio, pero puede esperar hasta un mejor momento (p. ej. El prximo
lanzamiento, o mantenimiento programado).
Prioridad normal - no representa gran urgencia o no implica un impacto importante, pero no se debe
diferir el cambio. En la reunin de CAB se le da prioridad normal cuando se asignan los recursos.
Prioridad alta - un error grave que afecta a muchos usuarios, o un error poco conveniente que afecta a
un gran nmero de usuarios, o relacionados con otros temas urgentes. En la prxima reunin de CAB se
le da la mayor prioridad a este cambio.
Prioridad mxima - la RFC se produce por un problema que afecta seriamente el uso de servicios
esenciales de los usuarios, o que necesita de un cambio TI urgente (p. ej. nuevas funciones por razones
del negocio, una legislacin de emergencia o un arreglo rpido que no puede esperar). Los cambios con
esta prioridad se clasifican como "cambios de emergencia". Los cambios de emergencia no siguen los
procedimientos normales, ya que los recursos deben estar disponibles de inmediato. Se puede necesitar de
una reunin de emergencia de CAB o del Comit de Conduccin TI. Con tal fin en especial, se debe
constituir un CAB/EC (Comit de Emergencia), con autoridad suficiente para tomar decisiones de
emergencia. Todos los planes hechos con anterioridad pueden demorarse o interrumpirse.
Los cdigos pueden asociarse con nmeros, p. ej. bajo-l/mximo-4.

Determinacin de la categora
La Gestin de Cambios determina las categoras, si es necesario junto con el CAB, que indica el impacto del
cambio y la demanda que tiene para la organizacin TI.
Algunos ejemplos de categoras:
-
Impacto menor - un cambio que no necesita mucho trabajo. El Gestor de Cambios puede aprobar estos
cambios sin presentarlos ante la CAB.
Impacto sustancial - un cambio que precisa bastante esfuerzo y que tendr un impacto sustancial en los
servicios. Estos cambios se discuten en la reunin de CAB para determinar el esfuerzo necesario y el
impacto potencial. Antes de la reunin, se hace circular la informacin entre los miembros de la CAB y
posiblemente entre los especialistas y los encargados de desarrollo.
Impacto mayor - un cambio para el que se necesitar mucho esfuerzo. El Gestor de Cambios necesita
autorizacin previa de la gestin TI o del Comit de Conduccin TI, tras el que se enva el cambio a
CAB.
Se puede asignar nmero a los cdigos, p. ej. menor=l/mayor=3.

Muchos cambios caen dentro de las dos primeras categoras. Adems tambin se deben especificar la
clasificacin, los grupos que trabajan en la solucin, y los servicios afectados por el cambio.
7.4.4 Planes
La Gestin de Cambios planifica los cambios utilizando un calendario de cambio, o un Programa de Cambios
a Futuro (FSC). El FSC contiene detalles de todos los cambios aprobados y su planificacin.
Los miembros de CAB aconsejan sobre los cambios planificados, como la disponibilidad de personal,
recursos, costes, aspectos de afectacin del servicio, y el cliente; todo debe ser considerado. CAB acta como
un comit consejero.
La Gestin de Cambios tiene autoridad delegada ya que se pronuncia en representacin de la Direccin de TI.
Los cambios ms importantes pueden necesitar de la aprobacin de la Direccin de TI, antes de presentarlos
ante CAB.
76

La aprobacin del cambio puede constar de tres aspectos:
-
Aprobacin financiera - anlisis coste/beneficio y presupuesto

Aprobacin tcnica - impacto, necesidad y viabilidad
Aprobacin del negocio - aprobacin de los usuarios de las funciones necesarias y el impacto
Para conseguir una planificacin eficaz, la Gestin de Cambios debe estar en contacto con las oficinas de
proyecto y con todas las otras oficinas de la organizacin que construyen e implementan los cambios. Es ms,
se debe prestar especial consideracin a las comunicaciones eficaz de la planificacin de cambios a nivel
horizontal (interdepartamental), en lo posible a travs de Programa de Cambios a Futuro (FSC).
Poltica de Cambios
Las RFCs pueden combinarse en un nico lanzamiento. En ese caso, un solo back-out ser suficiente por si
algo sale mal. Esta clase de lanzamiento debe considerarse como un nico cambio, an s incluye muchos
cambios. Los lanzamientos pueden planearse con un objetivo funcional para el negocio. Pueden incluir
hardware y software, y son implementados por la Gestin de Versiones.
Es aconsejable definir la poltica de esta seccin y comunicarla a la organizacin TI y a los clientes (ver
tambin Gestin de Versiones).
La poltica debe tener como objetivo evitar la ruptura innecesaria con el usuario. Al consultar a los
departamentos TI afectados, el CAB puede especificar ventanas de tiempo regulares para implementar los
cambios en un horario que minimice el impacto en el servicio.
Los horarios ms aconsejables son los fines de semana o fuera del horario de oficina, pero siempre depender
de los servicios afectados y de los niveles de servicio pactados para ellos.
De igual manera se pueden establecer horarios en los que no se permitan cambios o en los que se produzcan
pocos, como durante las horas de oficina o a fines del ao financiero cuando todos los usuarios de los
departamentos estn haciendo los deberes peridicos.
Reuniones del CAB
Se debe distribuir la informacin sobre la planificacin de un cambio antes de la reunin CAB.
Antes de la reunin tambin se deben hacer circular los documentos y la informacin correspondiente sobre
los puntos a tratar.
El CAB debe tener cierta cantidad de puntos fijos en la agenda de sus encuentros, incluyendo:
-
Cambios sin autorizacin.

Cambios autorizados que no han sido remitidos a CAB.
RFCs que deben ser evaluadas por los miembros de CAB.
Cambios abiertos y cerrados.
Evaluaciones de cambios pasados.
Anlisis de impacto y los recursos

Cuando se estiman los recursos necesarios y el impacto del cambio, los miembros de CAB, el Gestor de
Cambios y dems personas involucradas (identificados por CAB) deben tener en cuenta los siguientes
aspectos:
-
Capacidad y rendimiento de el/los servicio(s) afectados.

Fiabilidad y recuperacin.
Planes de la Gestin de Continuidad de Servicios T I .
Planes de back-out.
Seguridad.
Impacto del cambio en los otros servicios.
77
Gestin de Cambios
-
Registro y aprobacin.
Recursos necesarios y costes (soporte y mantenimiento).
Cantidad y disponibilidad de los especialistas necesario.
Ciclo de tiempo necesario para el cambio.
Nuevos recursos a comprar y evaluar.
Impacto sobre las operaciones.
Cualquier conflicto con los otros cambios.
Impacto de la no implementacin del cambio.
Los miembros de CAB tambin pueden aconsejar sobre la prioridad.
7.4.5 Coordinacin
Los cambios aprobados se comunican a los especialistas de producto que corresponde, quienes pueden luego
construir e integrar los cambios. Se evalan los cambios antes de ser implementados.
La Gestin de Versiones puede cumplir un rol importante en la construccin, evaluacin, implementacin y
despliegue de los cambios aprobados. Se debe prestar especial atencin a las comunicaciones de los cambios a
los grupos de soporte.
Construccin
No todos los cambios tienen una fase de construccin especfica. Por ejemplo, los cambios estndar como la
reubicacin de un PC pueden planificarse e implementarse de inmediato.
La construccin puede incluir la creacin de una nueva versin de software, con nueva documentacin,
manuales, procedimientos de instalacin, un plan de back-out, y cambios de hardware. La Gestin de
Cambios controla y coordina, y cuenta con la ayuda de la Gestin de Versiones y la administracin de lnea,
que debera trabajar para garantizar que existen los recursos necesarios para implementar los planes.
Se deber redactar un procedimiento de back-out como parte de la entrega de un cambio para revertir el
cambio si no ofrece los resultados esperados. La Gestin de Cambios no debe aprobar el cambio en caso de
no existir un procedimiento de back-out. Si el cambio impacta en el mbito del usuario, se debe redactar un
plan de comunicaciones y posiblemente de formacin. El plan de implementacin tambin se escribe durante
la fase de construccin.
Los indicadores de rendimiento muestran hasta qu punto el proceso de la Gestin de Cambios es exitoso al
manejar los cambios de manera eficaz y eficiente, con el menor impacto adverso posible en el nivel de
servicio acordado. Estos indicadores cubren temas tales como:
-
La cantidad de cambios que se complete por tiempo, por categora.

Tasa a la que se implementan los cambios.
Nmero de cambios rechazados.
Nmero de incidentes que resultaron de los cambios.
Nmero de back-outs relacionados con los cambios.
Coste de los cambios implementados.
Correlacin entre los recursos estimados y los tiempos contra los reales.
Nmero de cambios urgentes.
Examen
El procedimiento de back-out, la implementacin de cambio, y los resultados esperados del cambio deben ser
evaluados en detalle. Se debe considerar el criterio definido antes por el CAB. En muchos casos, una
evaluacin por separado del entorno o una evaluacin de laboratorio (piloto o maqueta) sern necesarias para
la evaluacin. Las primeras etapas de la evaluacin pueden ser llevadas a cabo por los constructores, pero el
cambio no debe implementarse sin alguna clase de evaluacin independiente.
78

Esto a menudo se hace de dos formas -evaluacin de la aceptacin del usuario donde la comunidad del
negocio (a menudo el cliente del cambio) evala la funcionalidad del cambio, y la evaluacin de la
aceptacin operacional donde aquellos que soportan y mantienen la infraestructura cambiada realizan una
evaluacin independiente.
Se incluir a las reas de soporte tcnico y al Centro de Servicios que evaluarn la documentacin de soporte,
backup y procedimientos de recuperacin, etc. Tambin son necesarias las instrucciones claras para
monitorizar la calidad de la evaluacin, y documentar los resultados de la evaluacin.
Implementacin
Se puede pedir a cualquier persona en el departamento correspondiente responsable de la gestin de la
infraestructura TI que implemente un cambio en la infraestructura.
La Gestin de Cambios garantiza que el cambio se realice segn lo programado. Debe haber un plan de
comunicaciones que indique a quin se tiene que informar del cambio, por ejemplo los usuarios, el Centro de
Servicios, la Administracin de Redes, etc.
Si no se puede evaluar un cambio correctamente, es posible aplicar el cambio a un pequeo grupo de usuarios,
y evaluar los resultados antes de su implementacin a gran escala.
7.4.6 Evaluacin
Se deben evaluar los cambios implementados con la posible excepcin de los cambios estndar. Si es
necesario, el CAB decide si se necesita de un seguimiento. Se deben tener en cuenta los siguientes puntos:
El cambio produjo los objetivos necesarios?
Los usuarios estn satisfechos con el resultado?
Hubo efectos colaterales?
Se excedieron los costes y los esfuerzos estimados?
Si el cambio fue satisfactorio, se puede cerrar la RFC. Los resultados son incluidos en la Revisin Post
Implementacin (PIR) o evaluacin del cambio. Si el cambio no fue exitoso, entonces se retoma el proceso
desde donde surgi el problema, utilizando un planteamiento modificado. A veces es mejor volver atrs y
crear una RFC nueva o modificada. Seguir adelante con un cambio infructuoso crea mayores problemas.
Los procedimientos con un lmite de tiempo automtico pueden ayudar a garantizar que no se descuiden las
evaluaciones de cambio. Segn la naturaleza del cambio, se puede hacer una evaluacin despus de unos das,
o despus de meses. Por ejemplo, un cambio en un PC que se utiliza todos los das puede evaluarse pasado
unos das, mientras que un cambio en un sistema que se usa solo una vez por semana se puede evaluar
pasados los tres meses.
7.4.7 Implementacin de cambios de emergencia

Por ms bueno que sea la planificacin, puede haber cambios que demanden prioridad absoluta. Los cambios
de emergencia son muy importantes y deben realizarse lo antes posible. En muchos casos, los recursos
dedicados a otras actividades deben desviarse de esos cambios. Los cambios urgentes pueden tener un serio
impacto en el trabajo planeado. As, el objetivo es minimizar la cantidad de cambios urgentes o inesperados
(prioridad "mxima"). Algunas medidas preventivas incluyen:
-
Garantizar que los cambios se pidan a tiempo, antes de que sean urgentes.
Al remediar errores debido a cambios con poca preparacin, la situacin no debe regresar ms all de la
versin anterior, el Estado Confiable Previo. Luego, se debe preparar con cuidado una implementacin
mejor.
A pesar de las medidas antes mencionadas, los cambios urgentes todava pueden aparecer, y necesitan de
procedimientos para tratarlos con rapidez, sin que la Gestin de Cambios pierda control del proceso. Si hay
tiempo, el Gestor de Cambios puede organizar una reunin de emergencia del CAB/EC. Si no hay tiempo o si
79
Gestin de Cambios
el pedido se realiza fuera de horas de oficina, debe existir un mtodo alternativo para obtener autorizacin.
Esta no debe ser una reunin cara a cara, puede ser una conferencia telefnica.
Se menciona un ejemplo en el proceso de Gestin de Incidentes, donde se puede aplicar una reparacin de
emergencia para resolver un incidente serio. Si el tema es muy serio y la demora es inaceptable, se debe
seguir el procedimiento de RFC urgente.
Es posible que haya poco tiempo para las evaluaciones normales. Por ejemplo, una estacin de trabajo
controla una mquina grande que mezcla almidn para hacer pldoras en una fbrica farmacutica.
Si la estacin de trabajo no se recupera dentro de una hora despus producida la falla, la mezcla de almidn se
endurece, y dos personas trabajando con martillos y cinceles tardarn dos semanas para eliminar manualmente
el material endurecido.
Mientras tanto, la empresa pierde miles de euros por hora por no poder fabricar pastillas. En tal caso, el
Gestor de Cambios debe evaluar los riesgos, y decidir sobre la implementacin del cambio.
Despus, se deben completar todas las etapas necesarias del proceso normal para garantizar que las
evaluaciones que se evitaron se lleven a cabo, y que se actualicen los archivos (cambiar registros y la
CMDB), para garantizar que an podemos contestar a la pregunta "qu cambio?".

7.5.1 Informes de gestin
La Gestin de Cambios tiende a provocar un balance entre flexibilidad y estabilidad. Se pueden dar informes
sobre los siguientes temas para mostrar la situacin actual de la organizacin:
-
Nmero de cambios implementados en un periodo (total y por categora CI).

Lista de las causas de los cambios y RFCs.
Nmero de cambios exitosos implementados.
Nmero de back-outs y sus razones.
Nmero de incidentes relacionados con los cambios implementados (incidentes provocados por y
resueltos por los cambios).
Grficos y anlisis de tendencias para los periodos que corresponda.
Los indicadores de rendimiento muestran hasta qu punto el proceso de Gestin de Cambios es exitoso en el
manejo eficaz y eficiente de los cambios, con el menor impacto posible adverso sobre el nivel de servicio
acordado.
Estos indicadores cubren temas tales como:
-
80
Nmero de cambios implementados en un periodo (total y por categora CI).

Lista de las causas de los cambios y RFCs.
Nmero de cambios implementados con xito.
Nmero de back-outs y sus razones.
Nmero de incidentes relacionados con los cambios implementados.
Grficos y anlisis de tendencias para los periodos que corresponda.

7.6.1 Costes
-
Costes de personal - en muchos casos, ya hay personal que coordina los cambios. An as, se puede
incurrir en costes de personal adicionales para cumplir con las tareas del Gestor de Cambios y constituir
el Consejo Asesor de Cambio. Sin embargo, hasta cierto punto estos costes se compensarn al aliviar el
esfuerzo de coordinacin dentro de la organizacin. En muchos casos, se introduce la Gestin de
Cambios para mejorar la calidad de servicio, y los costes adicionales en los que se incurre se clasifican
como costes de calidad. Despus de una implementacin exitosa de la Gestin de Cambios, los costes de
coordinacin de cambios se ven compensados por una reduccin en el coste de resolucin de incidentes y
problemas.
Costes de herramientas - se deben determinar con anticipacin los costes de hardware y software. A
menudo, al introducir muchos procesos, se compra una herramienta integrada para la Gestin de
Cambios, la Gestin de Configuraciones y la Gestin de Incidentes. Cuando se manejan mbitos TI
complejos, se vuelve casi imposible controlar estos procesos administrativos sin tales herramientas.
7.6.2 Problemas
Se pueden encontrar los siguientes problemas al introducir la Gestin de Cambios:
-
Los sistemas en los que se utiliza papel son muy difciles de usar y presentarn demasiados problemas.
Puede haber resistencia contra un paraguas de autoridad de Gestin de Cambios que monitorice todos los
aspectos de la infraestructura TI. En tal caso, el personal TI debe contar con capacitacin para
comprender que todos los componentes de la infraestructura TI pueden tener un impacto importante sobre
otro, y que los cambios que se aplican a las configuraciones precisan de coordinacin total.
Pueden haber intentos para implementar cambios sin seguir los procedimientos acordados. Es
absolutamente imprescindible que haya una reaccin contundente de la organizacin a tales intentos. La
integridad de los procesos de la Gestin de Cambios dependen del cumplimiento total. Las quejas del
personal sobre las sugerencias para mejorar los procesos de la Gestin de Cambios deben ser toleradas y
bienvenidas, respectivamente, pero la falta de cumplimiento debe tratarse con decisin o el proceso se
arruinar.
Otros medios para garantizar el cumplimiento de los procedimientos de la Gestin de Cambios incluyen:
Llevar a cabo auditoras regulares, en lo posible por un auditor independiente, para evaluar el
cumplimiento de los procedimientos de la Gestin de Cambios.
Supervisin administrativa del personal de soporte interno y externo y de los que desarrollan la
actividad.
Garantizar el control de todos los CIs y las versiones protegiendo la CMDB y conviniendo que la
Gestin de Configuraciones realice Auditorias de Configuracin regulares.
Garantizar que la Gestin de Incidentes informe si los usuarios tienen acceso a hardware y software
que no est incluido en la CMDB.
Incorporar las condiciones y los procedimientos en los contratos con los abastecedores externos.
Nombrar un Gestor de Cambios con mucha experiencia y suficiente conocimiento del negocio (este
aspecto es por lo general poco valorado) y tcnico.
Conseguir a la persona correcta para el rol es crucial y no debe descuidarse como generalmente es el
caso.
7.6.3 Sugerencias
Algunos problemas se pueden controlar implementando las siguientes sugerencias:
-
Garantizar que todos los cambios sigan el procedimiento completo.

Comunicarse con todo el personal TI y con todos los abastecedores para asegurarse que aceptan la
Gestin de Cambios, y que no se tratan de implementar cambios sin coordinacin.
Asegurar que se estn evaluando los cambios.
Trabajar con la Gestin de Configuraciones para garantizar que se introduzcan los cambios de la CI en la
CMDB.
81
Gestin de Cambios
82
Captulo 8:
Gestin de Versiones
8.1 Introduccin
Dado que las organizaciones se vuelven cada vez ms dependientes de los procesos TI, la monitorizacin
eficaz y la proteccin de estos procesos tambin se vuelve ms importante. Como la tasa de cambio tambin
sigue creciendo, hay una mayor necesidad de mantener los cambios bajo control.
Los cambios en la infraestructura TI se producen en un ambiente complejo y distribuido. En las aplicaciones
cliente/servidor, esto afecta tanto al cliente como al servidor. La liberacin e implementacin de hardware y
software exigen una preparacin cuidadosa en estos casos.
Una Versin (release) es un conjunto de Elementos de Configuracin (CIs) nuevos y/o cambiados que estn
evaluados y homologados y que se introducen juntos en el entorno productivo.
La versin viene definida por la RFC que implementa. La Gestin de Versiones (Release Management) se
establece como un proyecto planeado para implementar los cambios en los servicios TI, y dirige todos los
aspectos, tcnicos y no-tcnicos, de los cambios.
La Gestin de Versiones tiende a garantizar la calidad del entorno de produccin utilizando procedimientos
formales y verifica cundo se implementan nuevas versiones. La Gestin de Versiones se encarga de la
implementacin, a diferencia de la Gestin de Cambios que se ocupa de la verificacin.
La Gestin de Versiones trabaja muy de cerca con la Gestin de Configuraciones y con la Gestin de
Cambios, para garantizar que la CMDB en comn se actualice con cada versin.
La Gestin de Versiones tambin garantiza que los contenidos de las versiones se actualicen en la Biblioteca
de Software Definitiva (DSL). La CMDB tambin sigue el rastro de las especificaciones de hardware,
instrucciones de instalacin, y configuraciones de red.
Los stocks de hardware, en particular de configuraciones bsicas estandarizadas, se almacenan en el Depsito
de Hardware Definitivo (DHS). Sin embargo, por lo general, la Gestin de Versiones pone mayor foco en el
control del software que del hardware.
En grandes proyectos en particular, la Gestin de Versiones debe formar parte de todo el plan de proyecto
para garantizar fondos. Se puede asignar un presupuesto anual fijo para las actividades de rutina tales como
cambios menores.
Aunque habr costes relacionados cuando se establezcan los procesos, stos son menores si se los compara
con los costes potenciales asociados con planificacin y control del software y hardware insuficiente, como
pueden ser:
-
Interrupciones importantes por la escasa planificacin de las versiones de software.

Duplicacin del trabajo porque hay copias de las diferentes versiones.
Uso ineficaz de los recursos porque nadie sabe dnde encontrarlos.
Prdida de archivos fuente, lo que significa que hay que comprar o desarrollar software otra vez.
Falta de proteccin contra los virus, lo que implica que hay que descontaminar la red.
83
Gestin de Versiones

Versiones
Las versiones comprenden uno o ms cambios autorizados. La primera subdivisin se basa en el nivel de
versin. Las versiones a menudo se dividen en:
-
Versiones mayores - lanzamiento importante de hardware y software, generalmente derivado de

modificaciones substanciales en las funcionalidades. Estas versiones suelen eliminar gran cantidad de
errores conocidos, incluyendo soluciones temporales y soluciones rpidas.
Versiones menores de software y actualizaciones de hardware - stas por lo general incluyen mejoras
menores y soluciones a errores conocidos. Algunas de estas correcciones pueden haber sido
implementadas anteriormente como reparaciones de emergencia (hotfixes), pero ahora quedan incluidas
dentro de la versin. Estas versiones tambin aseguran que el "Estado Confiable Previo", el punto de
comienzo de todas las evaluaciones, sea actualizado.
Reparaciones de emergencia - normalmente implementado como una reparacin rpida para un
problema o error conocido.
Unidades de versin
Cuando estamos reuniendo en cuenta el hardware dentro del control de gestiones normalmente surgir la
cuestin de si se cambiarn o controlarn los PCs completos o se llegar al nivel de detalle de placa, discos,
memorias, etc. As mismo, cuando nos referimos al software, los cambios se pueden realizar a nivel de
sistema, suite, programa o a nivel de modulo. Un buen ejemplo es la DLL (Biblioteca de Vnculos
Dinmicos) en el entorno Windows, que a menudo es compartida por varios programas. A veces, se obtiene
una versin de la DDL con un paquete, que puede necesitar de una reevaluacin de todos los otros paquetes
de software. Este proceso tambin desarrolla polticas sobre el contenido mnimo de una versin.
Identificacin de la versin
Las copias del software se pueden distribuir desde la DSL hacia los otros entornos que corresponda:
-
Entorno de desarrollo - el desarrollo de una nueva versin se puede derivar de una versin anterior de la
DSL. El nmero de versin se incrementa con cada nueva versin. El software slo se puede cambiar en
el entorno de desarrollo.
Entorno de pruebas - es el ambiente para probar las versiones. A menudo se divide en pruebas tcnicas
que hacen los desarrolladores, pruebas funcionales realizadas por usuarios, pruebas de implementacin
hecha por desarrolladores de versin, y posiblemente una prueba de aceptacin final entre los usuarios y
la organizacin administrativa.
Entorno de produccin - el entorno en vivo donde se ponen a disposicin del usuario los sistemas de
informacin.
Archivo - tiene versiones ms viejas de software que ya no estn en uso.
Dado que pueden estar disponibles muchas versiones, se les otorga identificadores nicos. La identificacin
de versin debe hacer referencia al CI pertinente e incluir un nmero de versin de dos o ms dgitos, por
ejemplo:
-
Versiones importantes - sistema de nmina v. 1, v.2, v.3, etc.

Versiones menores - sistema de nmina v. 1.1, v. 1.2, v. 1.3, etc.
Versiones por arreglos de emergencia - sistema de nmina v. 1.1.1, v. 1.1.2, v. 1.1.3, etc.
La Figura 8.1 muestra la prueba y la posible modificacin de cada nueva versin antes de su liberacin.
Como parte de esta liberacin, la versin anterior es archivada por si resulta necesario un backout.
84
Figura 8.1 Gestin de Versiones
Figura 8.2 Back-out de Gestin de Versiones
Tipos de versin
Se debe estimar la cantidad de cambios que se pueden desarrollar, probar e implementar durante un cierto
periodo. Un Paquete de Versiones, una combinacin del nmero de cambios en un solo rollout, puede ser
muy complejo para implementarlo de manera segura.
El rpido desarrollo de nuevas versiones de hardware y software en el mercado significan que una versin
puede ser viejo antes de que se lo pueda liberar. Por otro lado, los cambios frecuentes pueden tener un
impacto adverso en el servicio.
La Gestin de Cambios debe decidir el nmero de cambios que se pueden incluir en una versin, y de qu
manera se implementar el rollout. La Gestin de Cambios puede seleccionar alguna de las siguientes
opciones:
-
Versin Delta - una Versin Delta slo incluye hardware y software cambiado. Esto por lo general se
relaciona con una reparacin de emergencia o una reparacin rpida. La desventaja de este tipo de
versiones es que no siempre es posible probar todos los vnculos con el resto del entorno, y que los
mdulos que ya no usa el software no se borran. Una versin Delta resulta apropiada en caso de que se
pueda separar el software del resto del ambiente TI. La ventaja de una Versin Delta es que da menos
trabajo establecer el ambiente de prueba.
Versin Completa - una Versin Completa significa que el programa se distribuye entero, incluyendo
los mdulos que no fueron cambiados. Esta va es muy aconsejable cuando no est claro qu se cambi.
Se probar en detalle el hardware y el software y habr menos incidentes despus de la implementacin.
Cuando se prepara una Versin Completa resulta ms fcil juzgar si se alcanzarn los criterios de
rendimiento esperados. La ventaja de una Versin Total es que se pueden implementar simultneamente
varios cambios. La preparacin ser ms fcil ya que se pueden utilizar los script de instalacin estndar.
Durante la instalacin tambin se puede aprovechar para limpiar el entorno de usuario. Sin embargo, una
Versin Total requiere de una mayor preparacin y ms cantidad de recursos que una Versin Delta.
Paquete de Versiones - un Paquete de Versiones es un conjunto de versiones (ya sean mayores o
menores) agrupadas en un nico paquete. Hace nfasis en largos perodos de estabilidad para los
usuarios. El arreglo de errores menores de software, con los que los usuarios pueden vivir, y la
incorporacin de nuevas funcionalidades son actividades que a menudo se pueden combinar eficazmente.
De igual manera, las actualizaciones programadas, por ejemplo de software de terceras partes como el
software de sistema y las aplicaciones de ofimtica son las que por lo general se tratan con un Paquete de
Versiones.
85
Gestin de Versiones
Figura 8.3 Tipos de Versiones
Biblioteca de Software Definitiva (DSL)

La Biblioteca de Software Definitiva (DSL) es un depsito seguro que contiene las versiones autorizadas
definitivas (copias master) de todo el software de los CIs. La DSL puede estar fsicamente en muchos lugares
y comprende cierta cantidad de espacios securizados y cajas fuertes a prueba de incendios. La Gestin de
Versiones cubre el ciclo de vida del software desde el momento que se incorpora a la DSL.
Las versiones se construyen con el software homologado en la DSL. Despus se desarrollan los scripts de
instalacin y se pueden estampar los CDs en ambientes descentralizados.
La DSL puede incluir muchas versiones del mismo software, incluyendo versiones, documentacin y cdigos
fuente archivados. Por tal motivo, la DSL debe ser respaldada a menudo, ya que no slo contiene la versin
actual sino tambin las versiones de back-out anteriores. Si hay muchos lugares con administracin local,
entonces cada lugar tendr una copia de las DSL para hacer el despliegue del software.
Depsito de Hardware Definitivo (DHS)
El Depsito de Hardware Definitivo tiene repuestos y stock de hardware. Estos son componentes de repuestos
y montajes que se mantienen en el mismo nivel que sus contrapartes en el ambiente en vivo. El hardware de la
DHS se usa para reemplazar o reparar configuraciones similares en la infraestructura TI. Los detalles de la
composicin de estas configuraciones deben incluirse en la CMDB.
Base de Datos de la Gestin de Configuraciones (CMDB)
Durante todas las actividades de la Gestin de Versiones, es aconsejable verificar la informacin sobre los CIs
en la CMDB. Cuando las versiones de software se incorporan en la DSL, y se incorporan las versiones de
hardware en la DHS, tambin se actualizan los detalles de la CMDB. Para ayudar a la Gestin de Versiones,
la CMDB debe contener detalles sobre:
-
Los contenidos de las versiones, incluyendo CIs de hardware y software con referencia a la RFC original.
CIs de hardware y software que pueden sufrir algn impacto por una versin.
Detalles de la ubicacin fsica del hardware cubierto por la versin.
Todo esto implica directamente que el nivel de detalle que se mantenga a nivel de Unidad de Versin debe de
estar mapeado correctamente con el nivel de detalle que mantengamos en la CMDB.
86
8.2 Objetivos
La Gestin de Versiones maneja y distribuye versiones de software y hardware utilizados para la produccin,
que el departamento TI soporta, para proporcionar el nivel de servicio necesario.
Los objetivos de la Gestin de Versiones incluyen:
-
Planificacin, coordinacin e implementacin (o disposicin de la implementacin) de software y

hardware.
Diseo e implementacin eficaz de procedimientos para distribuir e instalar los cambios en los sistemas
TI.
Garantizar que el hardware y software relacionado con los cambios sean rastreables y seguros, y que slo
se instalen las versiones correctas, autorizadas y probadas.
Comunicarse con los usuarios y considerar sus expectativas durante la Planificacin y despliegue de las
nuevas versiones
Determinar la composicin y planificacin de un despliegue junto con la Gestin de Cambios.
Implementar nuevas versiones de software y hardware en la estructura operativa, bajo el control de la
Gestin de Cambios, y con el soporte de la Gestin de Configuraciones. Una versin puede incluir un
nmero de CIs relacionados y, adems del hardware y software, documentacin como informes, planes y
manuales del usuario y de soporte.
Asegurar que las copias originales de software y su documentacin legal o de licencias se encuentren
bien almacenadas en la Biblioteca de Software Definitiva (DSL) y que la CMDB est actualizada; lo
mismo aplica al hardware en la DHS.
8.2.1 Ventajas
Junto con la Gestin de Configuraciones y la Gestin de Cambios eficaces, la Gestin de Versiones ayuda a
garantizar que:
-
El software y el hardware en produccin son de alta calidad, porque son desarrollados y probados bajo
control de calidad antes de ser liberados.
Se minimiza el riesgo de los errores en las combinaciones de software y hardware o la liberacin de una
versin incorrecta.
El negocio maneja con cuidado sus inversiones de software, de las que depende.
Hay menor cantidad de implementaciones separadas, y se prueba cada implementacin en detalle.
Se reduce el riesgo de los incidentes y los errores conocidos al probar y controlar la implementacin.
Los usuarios se ven ms involucrados en la prueba de una versin.
Se publica por adelantado un calendario de liberaciones (roadmap); por lo tanto, las expectativas de los
usuarios estn ms en lnea con las versiones en produccin.
El negocio tiene un diseo y construccin de software y hardware central, o la obtencin de medios,
seguido de la distribucin a Las ubicaciones de produccin.
El negocio puede estandarizar las versiones de software y hardware entre las diferentes ubicaciones, para
brindar un soporte de mayor calidad.
Se reduce el riesgo del software ilegal, adems del riesgo de los incidentes y problemas provocados por
las versiones equivocadas o infectadas que se introducen en el ambiente en vivo.
Se detectan con ms facilidad las copias no autorizadas y las versiones equivocadas.
8.3 El proceso
El proceso de la Gestin de Versiones incluye las siguientes actividades:
-
Poltica y planificacin de liberacin de versiones.

Construccin y configuracin versiones.
Prueba y aceptacin de la versin.
Planificacin del despliegue.
Comunicaciones, preparacin y capacitacin.
Distribucin e instalacin de la versin.
87
Gestin de Versiones
Estas actividades no son cronolgicas. La poltica de liberacin de versiones y la planificacin se hacen cada
6 meses o un ao, mientras que las otras actividades se hacen por lo general a diario.
Figura 8.4 Gestin de Versiones
El xito de la Gestin de Versiones depende de las entradas y de la cooperacin con los otros procesos ITIL
(Figura 8.4). Las interfaces ms importantes son con los siguientes procesos:

La Gestin de Configuraciones es responsable de registrar las versiones de software y hardware registradas en
la CMDB como configuraciones bsicas. El software agregado en la DSL y el hardware para la DHS estn
registrados en la CMDB a un nivel de detalle acordado. El estado de la monitorizacin provisto en la Gestin
de Configuraciones indica el estado de cada CI, por ejemplo "uso en vivo", "a prueba", "en stock" o
"archivada".

La Gestin de Cambios controla la distribucin. La Gestin de Cambios tambin es responsable de garantizar
que se prueba adecuadamente la versin. Esta Gestin tambin decide cuntos cambios se pueden combinar
en una nica versin. La Gestin de Cambios describe los procedimientos para garantizar que los cambios
estn autorizados, incluyendo el anlisis de impacto y el anlisis de los recursos necesarios. En muchos casos,
la Gestin de Versiones es responsable de la implementacin de los cambios de software y hardware, y por lo
general tiene un lugar en el Consejo Asesor de Cambios (CAB).

Un servicio TI generalmente consiste en la provisin de infraestructura de hardware junto con software
estndar o software desarrollado en casa. La Gestin de Versiones es responsable de poner a disposicin el
hardware y el software y de manejarlo. La Gestin de Versiones monitoriza los acuerdos sobre la
disponibilidad del software pactados en el proceso de la Gestin de Niveles de Servicio.
88
8.3.4 Actividades de la Gestin de Versiones

La figura 8.5 muestra las actividades de la Gestin de Versiones y sus vnculos con el ciclo de vida de un
cambio.
Entorno de Desarrollo
Poltica y
planificacin
de liberacin
de versiones
Diseo y
desarrollo o
orden y
compra
Entorno de Prueba
Gestin de Versiones
Construccin
Prueba y
y
aceptacin
configuracin
de la
de versiones
versin
Planificacin
del
despliegue
Comunicacin,
preparacin y
capacitacin
Entorno Vivo
Distribucin e
instalacin de
la versin
Biblioteca de Software Definitiva (DSL)

Depsito de Hardware Definitivo (DHS)
Base de Datos de la Gestin de Configuraciones (CMDB)
Figura 8.4 Actividades de la Gestin de Versiones
8.4 Actividades
8.4.1 Poltica y planificacin de liberacin de versiones
La Gestin de Versiones desarrolla una poltica de versiones para definir cmo y cundo se configuran y
despliegan las versiones. Las versiones ms importantes se pueden planificar por adelantado, junto con la
identificacin o nmero de versin, para que se puedan considerar los cambios adicionados con el tiempo
correcto.
El Gestor de Versiones tambin especifica a qu nivel se pueden distribuir unos CIs independientemente de
otros (unidades de versin). Esto depende de:
-
El impacto potencial de la versin sobre los otros componentes.

La cantidad de horas/hombre y el ciclo para construir y probar los cambios por separado comparndolo
con el esfuerzo asociado para juntarlos e implementarlos simultneamente.
La dificultad de la instalacin en los puestos de trabajo de los usuarios. Puede resultar ms fcil instalar
un programa completo porque se dispone de las tcnicas o herramientas estndar para ello.
La complejidad de las dependencias entre el software, hardware nuevo y el resto de la infraestructura TI cuanto ms fcil es separar el hardware del software, ms fcil es probarlo.
Antes de planificar una versin, se debe recopilar informacin sobre el ciclo de vida del producto, los
productos a entregar, la descripcin de los servicios TI y los niveles de servicio correspondientes, la
autorizacin de las RFCs pertinentes, etc.
Al plantear una versin se deben considerar los siguientes puntos:
-
Coordinacin del contenido de la versin.

Acuerdo sobre el programa, los lugares y las unidades organizativas.
Diseo del programa de liberacin de versin.
Diseo del plan de comunicaciones.
Visitas a las diferentes ubicaciones para determinar qu hardware y software estn en uso.
Acuerdos al respecto de roles y responsabilidades.
Obtener cotizaciones y negociar con los abastecedores sobre el hardware, software y los servicios de
instalacin y quizs de soporte.
Diseo de planes de back-out.
Diseo de un plan de calidad para la versin.
Planificar la aceptacin de la versin en la organizacin administrativa y con los usuarios.
89
Gestin de Versiones
Los resultados de esta actividad son parte del plan de cambio, e incluyen planes para el despliegue, planes de
prueba y criterios de aceptacin.
8.4.2 Diseo, construccin y configuracin

Es aconsejable desarrollar procedimientos estndar para disear, construir y configurar las versiones. Una
versin puede basarse en los sets de componentes (CIs) desarrollados en casa o adquiridos de terceras partes y
configuradas.
Las instrucciones de instalacin y las instrucciones para configurar las versiones tambin deben tratarse como
parte de la propia versin, y deben incluirse como CIs bajo el control de la Gestin de Cambios y la Gestin
de Configuraciones.
Es aconsejable establecer y probar todo el hardware y software en un "laboratorio" antes de instalarlo en el
lugar. Los componentes de software y hardware de una versin deben estar bien configurados y registrados
para que sean reproducibles.
Se deben disear las instrucciones de operacin para garantizar que se combine el mismo conjunto de
componentes siempre. A menudo se reserva el hardware estandarizado que slo se utiliza para compilar o
crear imgenes.
Es preferible que esta parte del proceso sea automtico para que sea ms confiable. Naturalmente la Gestin
de Versiones cubre el software y el hardware necesarios para esto.
En los entornos de desarrollo de software, esta actividad se conoce como Gestin de Construccin y se
encuentra bajo la responsabilidad de la Gestin de Versiones.
Plan de back-out
Un plan de back-out a nivel versin Completa define las actividades necesarias para recuperar el servicio si
algo sale mal.
La Gestin de Cambios es la responsable del diseo de los planes de backout, sin embargo la Gestin de
Versiones tiene que ayudar a que los planes de back-out sean prcticos.
En particular cuando se implementa un Paquete de Versiones que combina muchas RFCs, puede ser necesario
coordinar los distintos planes de back-out para la versin.
En caso de que algo salga mal con la versin total o una versin Delta, es aconsejable regresar por completo
la versin al Estado de Confiabilidad Previo. Si una versin no puede volverse atrs totalmente, tambin
deben existir planes de Recuperacin ante Desastres para restablecer el servicio.
Es aconsejable cumplir con los requisitos del plan de back-out por adelantado, como la creacin de backups y
la provisin de servidores de repuesto.
Para dirigir el caso donde la implementacin podra llevar ms de lo esperado, y donde tal atraso pusiera en
peligro la normal provisin de los servicios, el plan de back-out tambin puede incluir las fechas lmites para
mostrar cundo se debe comenzar el back-out para restaurar el servicio a tiempo (por ejemplo antes del lunes
a la maana, 7:00 de la maana).
Estas fechas lmites se conocen como "punto de no retorno", ya que si cruzamos este lmite seremos incapaces
de completar las actividades de back-out a tiempo para no afectar a la provisin normal del servicio dentro del
marco de disponibilidad acordado en los SLAs. Se debe incluir un plan de back-out en el anlisis de riesgo del
cambio, y los usuarios tienen que aceptar el plan.
La construccin real de la versin puede incluir la compilacin y la vinculacin de los mdulos de software, o
la introduccin de datos de prueba o datos como tablas de cdigos zip, tarifas de impuestos, zonas horarias y
90

tablas de monedas adems de informacin del usuario. Para esto se utilizan scripts de instalacin automticos,
que se almacenan en la DSL junto con los planes de backout.
Las versiones completas se deben identificar en la CMDB como configuraciones estndar para facilitar sus
configuraciones en el futuro.
Los planes de prueba cubren la prueba y la aceptacin de la calidad del software, hardware, procedimientos,
instrucciones de operacin y scripts de rollout antes de la versin, y posiblemente las pruebas de evaluacin
despus de la versin. Tambin se deben probar los scripts de instalacin. La informacin necesaria para esta
actividad incluye:
-
Definicin de la versin.
Programa de despliegue.
Instrucciones para configurar y construir la versin.
Descripcin de los elementos a comprar u obtener licencia, y el plan de obtencin de estos elementos.
Scripts de instalacin automticos y planes de prueba.
Copias fuente del software para su incorporacin a la DSL.
Planes de back-out.
8.4.3 Prueba y aceptacin de la versin

Un conjunto deficiente de pruebas es la causa ms comn de cambios y versiones no satisfactorios. Para
advertir esto, antes de la implementacin, la versin debe someterse a una prueba funcional de los
representantes de los usuarios y una prueba operativa por parte del personal de gestin TI que considerar la
operacin tcnica, las funciones, el aspecto operativo, el rendimiento, y la integracin con el resto de la
infraestructura.
Las pruebas tambin deben incluir los scripts de instalacin, los procedimientos de back-out, y cualquier
cambio a los procedimientos de administracin.
Se debe elevar a la Gestin de Cambios una aceptacin formal para cada etapa. La ltima etapa es aprobar la
versin para su despliegue.
La Gestin de Cambios debe coordinar la aceptacin formal de los usuarios y el "sign-off" de los
desarrolladores, antes de que la Gestin de Versiones empiece con el despliegue.
Las versiones deben aceptarse en un ambiente de pruebas controlado, que consiste en configuraciones bsicas
similares a las del entorno final productivo.
Esta situacin de base para la versin debe detallarse en su definicin. Se deben registrar las configuraciones
bsicas en la CMDB. Si no se acepta la versin se enva de vuelta a la Gestin de Cambios.
Los resultados de esta actividad incluyen:
-
Procedimientos de instalacin probados.

Componentes de versin probados.
Errores conocidos y defectos de la versin (que deben set incluidos en la documentacin operativa).
Resultados probados.
Documentacin de administracin y soporte.
Lista de sistemas afectados.
Instrucciones de operacin y herramientas de diagnstico.
Planes de contingencia y planes de back-out probados.
Programa de capacitacin para el personal, los gestores y los usuarios.
Documentos de aceptacin firmados.
Autorizacin de cambio para la versin.
91
Gestin de Versiones
8.4.4 Planificacin de la implementacin

El plan de liberacin de versiones diseado durante las etapas previas se complementa ahora con informacin
sobre las actividades de implementacin.
El plan de despliegue (rollout) incluye:
-
Diseo de un programa y lista de tareas y recursos humanos necesarios.

Creacin de una lista de CIs a instalar y borrar, y la forma en que se deben borrar.
Diseo de un plan de actividad para cada ubicacin afectada por la implementacin, considerando los
tiempos de despliegue disponibles, y para una organizacin internacional, las zonas horarias.
Envo de notificaciones de liberacin de versin y otras comunicaciones a las partes que corresponda.
Compra, almacenamiento seguro, e identificacin y registro de todos los nuevos CIs en la CMDB para
esta versin.
Programacin de reuniones con la gestin, los departamentos administrativos, la Gestin de Cambios, y
los representantes de los usuarios.
Existen muchas formas de implementar un despliegue:

-
La versin se puede desplegar por completo a toda la organizacin -el modelo Big Bang.
La versin se puede desplegar por etapas, combinando varias opciones:
Incrementos funcionales, donde todos los usuarios al mismo tiempo consiguen nuevas funciones.
Incrementos por localizacin, donde se trata con los grupos de usuarios.
Evolutivo, donde las funciones se expanden en etapas.
8.4.5 Comunicaciones, preparacin y capacitacin

El personal que tiene contacto con los clientes (Centro de Servicios y Gestin de Relaciones con el Cliente),
el personal operativo, y los representantes de las organizaciones de usuarios deben conocer los planes, y cmo
stos afectarn su rutina de actividades.
Esto se puede implementar a travs de sesiones de capacitacin en conjunto, cooperacin, y su participacin
conjunta en la aceptacin de las versiones. Se deben comunicar las responsabilidades, y se debe verificar que
todos sean conscientes de ellas y las hayan asumido. Si el despliegue se hace en etapas, los usuarios deben
saberlo y es necesario comunicarles los planes y cundo podrn hacer uso de las nuevas funciones.
Los cambios en los Acuerdos de Nivel de Servicio (SLA), en los Acuerdos de Nivel de Operaciones (OLA) y
los Contratos de Soporte (UC) deben ser comunicados al personal pertinente por adelantado.
8.4.6 Distribucin e instalacin de versiones

La Gestin de Versiones monitoriza los procesos de logstica para la compra, el almacenamiento, transporte y
entrega del software y hardware. El proceso tiene el soporte de procedimientos, registros, y documentos como
los visados de los paquetes, para que la Gestin de Configuradotes tenga una informacin fiable. Las
instalaciones para almacenar hardware y software deben ser seguras y solo el personal autorizado debe tener
acceso a las mismas.
Donde sea posible es recomendable utilizar herramientas automticas para distribuir el software y la
instalacin. Esto reducir el tiempo necesario para la distribucin, e incrementar la calidad y no requerir de
mayores recursos. En general estas herramientas tambin facilitarn la verificacin de una instalacin exitosa.
Antes de comenzar con la instalacin, es aconsejable verificar que el ambiente donde se va a realizar el
despliegue cumpla con las condiciones, tales como espacio de disco suficiente, seguridad, controles
ambientales o limitaciones como aire acondicionado, espacio en el suelo, UPS / energa, tomas de corriente y
de red, etc.
Despus de la instalacin se debe actualizar la CMDB para facilitar la verificacin de cualquier informacin
al respecto del despliegue.
92

8.5.1 Costes
Los costes de la Gestin de Versiones incluyen:
-
Costes de personal.
Costes de almacenamiento para la DSL y la DHS, entornos de construccin, prueba y distribucin.
Costes de las herramientas de software y hardware necesario.
8.5.2 Problemas
Se pueden presentar los siguientes problemas:
-
Resistencia al cambio - al principio puede haber algo de resistencia entre el personal acostumbrado a los
mtodos familiares. Por ejemplo les puede resultar difcil aceptar que para ciertas actividades recibirn
instrucciones de otra rea. Para despejar sus ideas, tendrn que ser informados sobre las ventajas de la
utilizacin de ITIL como marco de referencia.
Evitar la Gestin de Versiones - el software no autorizado puede traer virus a la organizacin, afectar
seriamente los servicios, y hacer ms difcil el soporte. Se deben tomar acciones firmes con el personal y
los usuarios, en particular en el entorno PC, que intenten utilizar o instalar software no autorizado. En
este aspecto, muchas veces ser ms interesante restringir las capacidades de los usuarios para la
utilizacin o instalacin de software que fiscalizar estas actividades. Para ello ser necesario demostrar a
los usuarios los costes ocultos de la no utilizacin de estas normativas, ya que para ellos normalmente los
costes de TI no son apreciables y la poblacin de usuarios en el entorno PC suele ser muy elevada (lo que
multiplica el factor de impacto de estos costes ocultos)
Reparaciones de Emergencia - no se debe evitar la Gestin de Versiones, an cuando sea necesario un
cambio urgente.
Distribucin - si se libera software en distintas ubicaciones, se debe garantizar que sea de una forma
sincronizada, para prevenir la aparicin de versiones diferentes en las diferentes localizaciones.
Carencia de Entorno de Pruebas - si no se cuenta con el entorno de pruebas adecuado puede ser difcil
evaluar correctamente las nuevas versiones o el nuevo software antes del despliegue.
93
Gestin de Versiones
94
Captulo 9:
Centro de Servicios
9.1 Introduccin
El Centro de Servicios (Service Desk) juega un rol importante en la ayuda al usuario. Un Centro de Servicios
completo y a pleno es como la oficina central de los otros departamentos, y puede tratar las consultas de los
clientes sin necesidad de personal especializado. Para el usuario, el Centro de Servicios es el nico punto de
contacto con la organizacin TI, que garantiza que encontrar la persona correcta para ayudarlo con su tema o
consulta. En otras palabras, los usuarios no deben pasarse horas buscando a alguien que les ayude a solucionar
sus problemas. A menudo, el Centro de Servicios tambin hace el seguimiento de las llamadas que se originan
dentro de la organizacin TI. Por ejemplo, los incidentes que se detectan dentro del departamento
(automticamente o por personal), y pide el servicio que viene de la misma organizacin TI.
Este captulo es diferente del resto del libro porque aqu nos centramos en una funcin, unidad organizativa, o
un departamento, mientras que el resto del libro trata de procesos. Se incluye el tema porque el Centro de
Servicios juega un rol esencial en la Gestin de Servicios TI. Para hacer un enfoque global de las actividades,
hablamos de Centro de Servicios en vez de Help Desk (Centro de Soporte), como se hizo durante mucho
tiempo. El Help Desk por lo general se dedicaba al proceso de incidentes, en tanto que el Centro de Servicios
cubre un rango de actividades de soporte ms amplio.
El Centro de Servicios maneja actividades relacionadas con una serie de procesos ITIL:
-
El proceso primario es la Gestin de Incidentes ya que el Centro de Servicios registra y monitoriza

muchos incidentes, y muchas llamadas del Centro de Servicios se relacionan con los incidentes. Esto
incluye la coordinacin de actividades de terceros involucrados en el manejo de incidentes.
Se puede dar al Centro de Servicios la responsabilidad de instalar software y hardware y por lo tanto tiene
un rol en la Gestin de Versiones o la Gestin de Cambios.
Si cuando se registra un incidente, el Centro de Servicios verifica los detalles del que llama y sus recursos
TI, el Centro de Servicios tiene funciones en la Gestin de Configuraciones.
El Centro de Servicios puede tomar actividades relacionadas con peticiones estndar, como la instalacin
de conexiones LAN y la reubicacin de las estaciones de trabajo. En ese caso contribuir a la evaluacin
de los cambios y se involucrar con la Gestin de Cambios.
El Centro de Servicios puede informar a los usuarios sobre los productos que tienen soporte y sobre los
servicios a los que tienen derecho. Si el Centro de Servicios no est autorizado a satisfacer una consulta,
debe informarlo con educacin al usuario y notificar de la consulta a la Gestin de Niveles de Servicio.
Figura 9.1 Procesos del Centro de Servicios
95
Centro de Servicios
El Centro de Servicios maneja actividades relacionadas con ITIL, p. ej. Gestin de Infraestructura
(Operaciones). El Centro de Servicios mantiene contacto con los clientes a travs de promociones y provisin
de informacin sobre los servicios.
El Centro de Servicios resulta una herramienta excelente para los contactos diarios con los usuarios para hacer
un seguimiento de la satisfaccin del cliente.
9.2 Objetivos
El objetivo del Centro de Servicios es dar soporte a la provisin de los servicios acordados, garantizando
acceso a la organizacin TI y comprometindose con un cierto nmero de actividades (de varios procesos).
Al ser un punto de contacto inicial, el Centro de Servicios reduce la cantidad de trabajo de los otros
departamentos TI interceptando preguntas irrelevantes y aqullas que son fciles de contestar.
El Centro de Servicios acta como filtro que slo permite que pasen a un segundo o tercer nivel si resulta
necesario. Como punto de contacto inicial siempre acta de manera profesional al tratar con los usuarios y
garantiza que no tengan que buscar eternamente la solucin.
De esta forma se garantiza que siempre habr alguien responsable de la llamada (consulta, incidente, peticin,
etc.), mientras que en organizaciones en las que no existe esta figura, es el propio usuario quien tiene que
mantenerse al da con el estado de su consulta y, en el caso de haber contactado con la persona equivocada,
buscar quin es la persona correcta y tratar de contactar con l.
9.3 Estructura
9.3.1 Accesibilidad
Una de las mayores tareas del Centro de Servicios es garantizar la accesibilidad de la organizacin TI. Se
debe animar a los usuarios a que llamen al Centro de Servicios si tienen alguna pregunta o si necesitan ayuda.
La forma en que se procesan las llamadas se pueden monitorizar con registros producidos por la central
telefnica y analizarse mediante aplicaciones especficas de ACD.
Para dar impresin de fiabilidad, el Centro de Servicios debe ser consistente y eficaz en el contacto con el
cliente. Se puede dar soporte con procedimientos basados en cuestionarios y respuestas estndar, por ejemplo
utilizando guiones o listas de verificacin (checklists).
Se puede utilizar amplio abanico de medios diferentes para mejorar la accesibilidad, aunque los contactos
telefnicos o va e-mail son los ms comunes. Tambin se puede usar correo de voz, fax, pasarelas de
Internet, y mensajes que se generan automticamente (p. ej. mensajes de texto a los telfonos mviles, o
buscapersonas).
9.3.2 Soporte al negocio

Las llamadas se pueden dividir en incidentes que afectan la infraestructura tcnica, incidentes y preguntas
sobre el uso de una aplicacin, preguntas sobre el estado de los servicios (progreso del incidente), cambios
estndar, y otras consultas.
Depende del tipo de Centro de Servicios, puede hacerse cargo de todas las llamadas o slo de los problemas
tcnicos, no respondiendo consultas sobre aplicaciones del negocio. En este caso, el departamento de cliente
que usa la aplicacin tiene un contacto para la aplicacin o un Centro de Soporte especfico para las
aplicaciones de negocio.
Este tratar de responder preguntas de los usuarios y slo enviar las preguntas tcnicas al Centro de Servicios
de la organizacin TI. De esa manera, el Centro de Servicios no se ver sobrecargado con preguntas
relacionadas al uso de aplicaciones.
96
9.3.3 Opciones estructurales

Existen muchas opciones para la estructura del Centro de Servicios. Los modelos ms comunes incluyen:
-
Centro de Servicios Centralizado como un nico punto de contacto para todos los usuarios, posiblemente
con subdivisiones locales de Centro de Servicios para las aplicaciones del negocio (divisin de la funcin
del Centro de Servicios).
Centro de Servicios Distribuido (locales) en ciertos lugares. Generalmente, dividir el Centro de Servicios
en distintas ubicaciones har ms difcil su gestin, pero da al usuario una percepcin ms prxima del
soporte recibido.
Centro de Servicios Virtual donde la ubicacin es inmaterial porque se usan tecnologa de comunicacin
que hacen que el usuario no note la localizacin remota del soporte.
Centro de Servicios Centralizado

La Figura 9.2 muestra la funcin dividida del Centro de Servicios Centralizado. Si la organizacin TI es
responsable de brindar el servicio (el Sistema de Informacin) y de ayudar con el uso del Sistema de
Informacin, es mejor que el usuario pueda acceder a un Centro de Servicios como nico punto de contacto.
En ese caso, el Centro de Servicios es responsable de aceptar y registrar la llamada, y de monitorizar el
progreso y el escalado. Aqu, el soporte de las operaciones del negocio forma parte del Centro de Servicios TI
o es responsabilidad de un equipo de soporte dirigido por el Centro de Servicios. Para ello hace falta un
sistema de registro de incidentes comn.
Si la organizacin TI no es responsable del soporte a las operaciones del negocio, el Help Desk de
operaciones del negocio representar a los usuarios cuando se solicite servicio de soporte provisto por TI.
Figura 9.2 Funcin dividida del Centro de Servicios
Este modelo se puede combinar con un puente de operaciones (una concentracin fsica de las actividades de
administracin operativas, p. ej. Centro de Servicios en combinacin con el departamento de Operaciones)
que permite comunicaciones directa entre el Centro de Servicios y la administracin de operacin
(produccin, Operaciones), donde Produccin incluye Administracin de Redes, Operacin de Sistemas, etc.
Esta comunicacin directa facilita una rpida respuesta si hay errores que el Centro de Servicios no puede
resolver de inmediato. Es ideal que los departamentos se encuentren fsicamente prximos entre si.
97
Centro de Servicios
Centro de Servicios Distribuido
Los Centros de Servicios Distribuidos estn dispersos entre muchos lugares, en diferentes edificios o hasta en
distintos pases. La Figura 9.3 da un ejemplo de la estructura del Centro de Servicios distribuido. Existe otra
opcin entre:
-
Un punto de contacto central, que dirige las llamadas al soporte local. El Centro de Servicios central
puede servir como punto de contacto inicial para los usuarios y especializarse en el registro de incidentes.
El software actual de redireccin de llamadas aumenta la efectividad del Centro de Servicios para atender
los incidentes.
Puntos de contacto locales con Un Centro de Servicios central para rastrear y monitorizar los incidentes.
A menudo cuando la organizacin local tiene su propio lenguaje y su propia cultura se utiliza esta
aproximacin. Tambin se usa cuando la organizacin tiene una cantidad importante de aplicaciones
habituales en cada lnea del negocio. Por ejemplo, una empresa qumica tiene ms de trescientas
categoras de aplicaciones de usuario, y mil aplicaciones en total. Con este nivel de customizacin, la
nica solucin prctica es distribuir la funcin del Centro de Servicios fuera de cada lnea de negocio, ya
que hace falta conocimiento "en el terreno" para resolver muchos de los incidentes que se registran. La
responsabilidad local en materia de costes de soporte tambin pueden motivar la creacin de este tipo de
estructuras.
Un call center. Esta opcin se vuelve cada vez ms popular y es la ms utilizada por los abastecedores.
Un nmero de telfono central, a menudo gratuito, brinda acceso a un men de respuesta por voz donde
el usuario puede seleccionar el tema sobre el que necesita ayuda, como e-mail o aplicaciones de
ofimtica. Despus la llamada es dirigida a un grupo de soporte de especialistas. Estos grupos de soporte
pueden estar en reas geogrficas distintas, pero esto para el usuario es irrelevante.
Figura 9-3 Centro de Servicios distribuido con control central (fuente: OGC)
Centro de Servicios Virtual

El Centro de Servicios Virtual es una versin especializada y moderna del Centro de Servicios distribuido.
Esta consiste en cierta cantidad de Help Desks locales que parecen formar una unidad haciendo uso de la
tecnologa de telecomunicaciones moderna y las redes que hacen de la ubicacin algo inmaterial. El Centro de
Servicios y el soporte ahora se pueden ubicar en cualquier lugar. Al utilizar diversas ubicaciones en distintas
98

zonas horarias alrededor del mundo ("soporte que sigue al sol") se brinda soporte con cobertura 24 horas. La
desventaja del Centro de Servicios virtual es que resulta ms difcil dar soporte "on-site".
Por ltimo, vemos la "autoayuda" como una forma de brindar funcionalidad "automatizada" del Centro de
Servicios.
La autoayuda en forma de, por ejemplo, acceso Web a la base de datos de conocimientos (buscando errores
conocidos o Preguntas ms Frecuentes) y registros de incidente (verificacin del estado, etc.) es una manera
interesante de reducir los costes y de facultar a la comunidad de usuarios finales para resolver sus problemas.
9.3.4 Personal del Centro de Servicios

Los requisitos del personal del Centro de Servicios se determinan de acuerdo con la misin y la estructura del
Centro de Servicios. A continuacin algunos ejemplos de las misiones del Centro de Servicios y de los
requisitos de los recursos humanos asociados:
-
Call center - este tipo de unidad de soporte slo registra llamadas y no da soluciones. Las llamadas se
pasan a un departamento de especialistas que las maneja. En algunos casos, el registro y el
direccionamiento de las llamadas pueden automatizarse utilizando sistemas de respuesta por voz.
Centro de Servicios no cualificado o de registro de llamadas - se registran las llamadas, se hace una
descripcin en trminos generales, y se direcciona de inmediato. El Centro de Servicios tiene una funcin
de despacho, y para las llamadas que se espera que maneje, necesita gran cantidad de procedimientos
estandarizados, scripts para tratar las llamadas, disciplina, y un Gestor con experiencia. La ventaja de este
modelo es que se estandariza el registro de incidente. La desventaja es que el tiempo de respuesta es ms
largo y que las tasas de resolucin en primer contacto son mucho ms bajas que las de un Centro de
Servicios cualificado.
Centro de Servicios Cualificado - este tipo de Centro de Servicios tiene ms habilidades y experiencia
que el tipo anterior. Utilizando soluciones documentadas puede resolver muchos incidentes, mientras que
deriva otros a grupos de especialistas. Las tasas de resolucin en primer contacto son mucho ms
elevadas que las del Service Desk no cualificado.
Centro de Servicios Experto - esta clase de Centro de Servicios tiene conocimiento especial de toda la
infraestructura TI y la experiencia para resolver la mayora de los incidentes de manera independiente.
9.3.5 Tecnologa del Centro de Servicios

Existen muchas opciones tcnicas para establecer Centro de Soporte. Aparte de una herramienta de Gestin
de Servicios eficaz, se incluyen:
-
La integracin de las herramientas de la gestin de servicios con las herramientas de administracin de

sistemas.
Tecnologa de comunicaciones es como Integracin de Telefona-Computadoras (CTI) o Protocolo de
Voz para Internet {VOIP}.
Sistemas Interactivos de Respuesta por Voz (IVR).
E-mail.
Servidores de fax (fax va e-mail o Internet).
Envo de llamadas a buscapersonas, telfonos mviles, ordenadores porttiles y pocket-PC.
Herramientas de gestin del conocimiento, bsqueda y diagnstico (base de conocimiento, razonamiento
basado en casos, etc.).
Sistemas de administracin automatizados y herramientas de red.
Plataformas de auto servicio Intranet e Internet.
99
Centro de Servicios
9.4 Actividades
9.4.1 Responder a las llamadas
Una llamada significa que un usuario contacta con el Centro de Servicios. Todas las llamadas deben ser
registradas para facilitar la monitorizacin del progreso y para obtener mtricas para el control del proceso.
Hay dos categoras de llamadas
-
Incidentes - todas las llamadas, excepto aquellas que se relacionan con los cambios estndar:
Informes de errores: fallas verdaderas y quejas sobre el servicio.
Peticiones de Servicio: en ITIL las Peticiones de Servicio se clasifican como incidentes, pero no
incluyen fallas en la infraestructura TI. Las Peticiones de Servicio tampoco caen en la categora de la
Gestin de Cambios. Los ejemplos incluyen preguntas como "Cmo hago?", peticiones de
informacin, p. ej. estado de las cuestiones, documentacin o consejo, peticiones de restauracin de
claves, ejecucin de procesos batch, restauracin de archivos o de extractos de base de datos,
peticiones de consumibles (incluyendo el reemplazo de un mouse, teclado, etc., si no son CIs),
provisin de documentacin ejemplo manual de usuarios, etc. Peticiones de Servicio tambin pueden
ser cambios estndar. Un cambio estndar es de hecho un cambio rutinario de la infraestructura que
sigue una trayectoria establecida, es la solucin aceptada para un requisito especfico o conjunto de
requisitos, y no es tramitado en el proceso de Gestin de Cambios. Varios ejemplos son una
actualizacin de un PC como preparacin para el uso de software especfico, setting up PC, software
y conexiones de red para nuevos estarters, instalaciones estndar no complicadas y pedidos estndar
para workstations, perifricos y aplicaciones locales. Cambios estndar son cambios, de modo que
implicarn un cambio de la registrada infraestructura TI.
Cambios - estos son los cambios no estndar que no son tramitados como Peticiones de Servicio. Una
peticin para tal cambio seguir el proceso estndar de Gestin de Cambios, requiriendo una formal
Peticin de Cambio (RFC).
Nota: ITIL considera ambos tipos de llamados (informes de error y Peticiones de Servicio) como "incidentes",
ya que estos llamados se tratan de igual manera. Por otro lado, la ITIL autoriza procedimientos aislados para
las Peticiones de Servicio, que se separan del proceso de la Gestin de Incidentes.
9.4.2 Dando informacin

El Centro de Servicios debe servir como fuente principal de informacin para los usuarios. Se puede hacer de
manera pasiva (p. ej. creando un tabln de anuncios), o activamente (e-mails, mensajes registrados en
pantalla, o mensajes de salva pantallas).
Todos los esfuerzos deben hacerse para informar a los usuarios sobre los errores actuales o esperados,
preferiblemente antes de que sufran las consecuencias. El Centro de Servicios tambin debe brindar
informacin sobre los servicios nuevos y existentes, proporcionar informacin al respecto de los Acuerdos de
Nivel de Servicio (SLAs) y pedir procedimientos y costes.
9.4.3 Coordinacin con el abastecedor

El Centro de Servicios tambin es responsable de los contactos con los abastecedores de mantenimiento. Esto
cubre la reparacin y reemplazo de impresoras, estaciones de trabajo y, en algunos casos, equipamiento de
telecomunicaciones.
Este tipo de mantenimiento puede ocuparse de gestionar los incidentes en el puro sentido de la palabra y
tambin los incidentes en trminos de cambios y peticiones.
9.4.4 Tareas de administracin operativas

Realizar copias de seguridad y recuperarlas, proveer de conexiones LAN, administracin de espacio de disco
en los servidores locales, habilitacin de cuentas, autorizacin y reseteo de claves.
100
9.4.5 Monitorizacin de la infraestructura

En el Centro de Servicios, las herramientas pueden utilizarse para estimar el impacto de las fallas que afectan
a un equipo esencial, como routers, servidores y pasarelas, sistemas de misin crtica, aplicaciones, y bases de
datos. A menudo, estas herramientas pueden detectar fallas e informar a la Gestin de Incidentes
automticamente cuando se produce la falla o cuando hay amenazas. No es necesario que el Centro de
Servicios utilice estas herramientas, ya que es una tarea primaria de "Operaciones", que debe brindar la
informacin al Centro de Servicios, pero s que es importante que el Centro de Servicios est informado de la
situacin de estos fallos, con el fin de poder reaccionar adecuadamente ante los clientes y proporcionar
informacin al respecto de la situacin de las previsiones de recuperacin.
9.5 Efectividad
La satisfaccin del cliente o usuario es la seal ms importante de efectividad del Centro de Servicios.
Algunos Indicadores Clave de Rendimiento son:
-
Se atiende rpido el telfono? (p. ej. el 90% de las llamadas se responden dentro de X segundos).
En cuntos minutos se dirigen las llamadas al soporte de segundo nivel (si no se pueden resolver en el
Centro de Servicios)?
El servicio se restaura dentro de un tiempo aceptable y de acuerdo con el SLA?
Se avisa a los usuarios con tiempo sobre los cambios y errores actuales y a futuro?
Algunos indicadores de rendimiento solo pueden medirse a travs de encuestas con el cliente, p. ej. :
-
Se atiende el telfono con educacin?

Reciben los usuarios buenos consejos sobre cmo prevenir los incidentes?

El Centro de Servicios debe verificar en forma regular (p. ej. cada seis meses) si llega a los estndares
definidos. Las mtricas apropiadas incluyen:
-
Porcentaje de incidentes que pueden cerrarse sin recurrir a otos niveles como soporte o abastecedores de
segunda o tercera lnea.
El nmero de llamadas que gestiona cada estacin de trabajo/usuario y el total para el Centro de
Servicios.
Tiempo de resolucin promedio por incidente, por impacto, o tiempo para comprender una peticin. Se
debe especificar tanto el ciclo de tiempo como el tiempo que se emplea para cada caso.
Los informes ACD sobre el tiempo de respuesta promedio, nmero de llamadas que los usuarios finalizan
antes de tiempo, promedio de tiempo por llamada y mtricas relativas por agente del Centro de Servicios.
Se pueden fijar estndares para estas mtricas, que despus se utilizan para contrastar la mejora o el deterioro
del servicio. La efectividad del Centro de Servicios tambin se puede medir a travs de encuestas regulares en
la organizacin de clientes.
9.5.2 Factores de xito crticos

Si es difcil contactar el Centro de Servicios, los usuarios no llamarn y en su lugar tratarn de resolver los
errores por s mismos, o a buscar a algn miembro de la organizacin que los pueda ayudar. De esta manera,
el desempeo del Centro de Servicios debe alcanzar cierto nivel antes de hacer una campaa publicitaria.
Si los usuarios tratan de contactar directamente a los especialistas, deben ser remitidos al Centro de Servicios.
Deben existir buenos SLAs y OLAs y un catlogo de servicios para garantizar que el soporte que brinda el
Centro de Servicios tenga un enfoque claro.
101
Captulo 10:
10. 1 Introduccin
La Gestin de Niveles de Servicio es el proceso de negociar, definir, medir, manejar y mejorar la calidad de
los servicios TI a un coste aceptable. Todo esto se debe desarrollar en un entorno de necesidades de negocio
con cambios rpidos en la tecnologa. La Gestin de Niveles de Servicio trata de encontrar el balance correcto
entre la provisin del servicio y la demanda, la satisfaccin del cliente, y el coste de los servicios TI. Es
importante que tanto el proveedor como el cliente se den cuenta de que se proporciona y se recibe un servicio
mutuo. Esto se formaliza mediante el diseo, acuerdo y mantenimiento de los Acuerdos de Nivel de Servicio
(SLAs), Acuerdos de Nivel de Operaciones (OLAs), Contratos de Soporte (UCs) y Planes de Calidad de
Servicio.

TI Proveedores de Servicio TI y Clientes
En teora, cualquier persona que hace uso de servicios TI es un cliente. En muchos casos, la organizacin TI
ser el proveedor.
Como la organizacin TI por lo general tambin obtiene servicios TI, y la organizacin TI es a la vez un
cliente de los Proveedores de Servicio TI, puede haber una compleja trama de relaciones. Por ejemplo, el
departamento de desarrollo de software puede pedir servicios on-line al departamento de procesamiento
central, y al mismo tiempo el departamento de desarrollo puede proporcionar mantenimiento de software para
garantizar la continuidad de los mismos servicios on-line.
En teora, la Gestin de Niveles de Servicio es un proceso lineal creado para definir los servicios y dar fin a
los acuerdos, como por ejemplo los Contratos de Soporte (UCs) con proveedores externos, los Acuerdos de
Nivel de Operaciones (OLAs) con proveedores internos, o los Acuerdos de Nivel de Servicio (SLAs) con los
clientes. Sin embargo, se necesita un planteamiento flexible puesto que la distincin entre los clientes y los
Proveedores de Servicio TI es poco clara.
En el contexto de la Gestin de Niveles de Servicio se usan las siguientes definiciones de cliente y proveedor:
-
El cliente es el representante de una organizacin que est autorizado a cerrar acuerdos en nombre de la
organizacin sobre la adquisicin de servicios TI. Por eso, no son los mismos que los usuarios finales de
los servicios TI.
El proveedor es el representante de una organizacin autorizado a acordar en nombre de sta la
provisin de servicios TI.
Requisitos de Nivel de Servicio (SLR)

Los Requisitos de Nivel de Servicio cubren las definiciones detalladas de las necesidades del cliente, y se
utilizan para desarrollar, modificar y comenzar los servicios. Los Requisitos de Nivel de Servicio pueden
servir como guas para el servicio y sus SLAs, y pueden utilizarse tambin como una asignacin de diseo.
Hojas de Especificacin de Servicio (Hojas Espec)
Las Hojas de Especificacin de Servicio describen la relacin entre funcionalidad (como se acord con el
cliente, y por consiguiente dirigido externamente desde el punto de vista del proveedor) y tecnologa
(implementacin dentro de la organizacin, y por lo tanto dirigido internamente) y brindar una especificacin
detallada del servicio. Las Hojas Espec traducen los Requisitos de Nivel de Servicio (especificaciones
externas) a definiciones tcnicas necesarias para prestar el servicio (especificaciones internas). Las Hojas de
Espec tambin describen los links entre SLAs, UCs, y OLAs. Las Hojas Espec son una herramienta
importante para monitorizar la correspondencia entre las especificaciones internas y externas.
103

Catlogo de Servicios
El desarrollo de un Catlogo de Servicios puede ayudar a la organizacin TI a perfilarse y a presentarse como
un Proveedor de Servicio TI y no slo como la que implementa y mantiene la tecnologa.
El Catlogo de Servicios da una descripcin detallada de los servicios operativos en el lenguaje del cliente,
junto con un resumen de los niveles de servicio asociados que la organizacin puede dar a sus clientes. Como
tal, es una herramienta de comunicaciones muy importante. El Catlogo de Servicios puede ayudar a dirigir
las expectativas de los clientes y de esta manera se facilita el proceso de alineacin entre los servicios del
cliente y del proveedor. Este documento surge de las especificaciones externas en las Hojas Espec y por lo
tanto debe redactarse en un lenguaje sencillo para el cliente, y no en forma de especificaciones tcnicas.
Acuerdos de Nivel de Servicio (SLA)
Un Acuerdo de Nivel de Servicio es un acuerdo entre la organizacin TI y el cliente, en el que se detalla el
servicio o los servicios a brindar. El SLA describe los servicios en trminos no tcnicos, de acuerdo con la
percepcin del cliente, y durante el tiempo que dure el acuerdo sirve como estndar para medir y ajustar los
servicios TI. Los SLAs por lo general tienen una estructura jerrquica, por ejemplo los servicios generales
como redes y los servicios del Centro de Servicios se definen para toda la organizacin y los aprueba la
gerencia. Los servicios ms especficos, asociados con las actividades del negocio, se acuerdan a un nivel ms
bajo en la organizacin, por ejemplo con la unidad de administracin de servicio, responsable de presupuesto
o representante de clientes.
Programa de Mejora de Servicio (SIP)
El Programa de Mejora de Servicio se implementa a menudo como un proyecto, define las actividades, fases e
hitos asociados con la mejora de un servicio TI.
Plan de Calidad de Servicio (SQP)
El Plan de Calidad de Servicio es un documento importante ya que tiene toda la informacin administrativa
necesaria para manejar la organizacin TI. El Plan de Calidad de Servicio define los parmetros del proceso
de la Gestin de Servicios y de la administracin de operacin. El SLA es "qu" entregaremos a diferencia de
la SQP que es "cmo" lo entregaremos. Incluye metas para cada proceso, en forma de Indicadores de
Rendimiento. Por ejemplo, para la Gestin de Incidentes tiene los tiempos de resolucin para varios niveles
de impacto, y para la Gestin de Cambios tiene los tiempos del ciclo y costes de cambios estndar tale como
la reubicacin. Se definen los informes y los intervalos de los mismos para todos los procesos. Los
Indicadores de Rendimiento derivan de los Requisitos de Nivel de Servicio y se documentan en las hojas
Espec. Si los proveedores externos contribuyen a proveer los servicios, por ejemplo cuando el Centro de
Servicios o el mantenimiento de PC's se realizan a travs de terceros, los Indicadores de Rendimiento tambin
se definen en los Contratos de Apoyo.
Acuerdo de Nivel de Operaciones (OLA)
Un Acuerdo de Nivel de Operaciones es un acuerdo con un departamento TI interno que detalla los acuerdos
sobre la provisin de ciertos elementos de un servicio, como un OLA sobre la disponibilidad de la red o la
disponibilidad de los servidores de impresoras. Por ejemplo, si el SLA contiene objetivos para resolver
incidentes de alta prioridad, los OLAs deben incluir objetivos para cada elemento de la cadena de soporte
(objetivo para el Centro de Servicios para responder llamadas, escalar, etc., objetivos para que el Soporte de
Red comience a investigar y resolver errores relacionados con la red que se les asign a ellos, etc.). Los OLAs
ayudan a la organizacin a proporcionar los servicios.
Contrato de Soporte (UC)
Un Contrato de Soporte es un contrato con proveedores externos que define los acuerdos sobre la provisin de
ciertos elementos de un servicio, por ejemplo el arreglo de estaciones de trabajo, o el alquiler de lneas de
comunicacin. Esto resulta similar a la implementacin externa de un OLA. En muchas organizaciones, un
departamento TI interno proporciona los servicios TI. Los SLAs y las OLAs son a menudo descripciones de
lo que se acord entre los departamentos internos, ms que los contratos legales. Sin embargo, un UC con un
proveedor externo se har por lo general como un contrato formal.
104
10.2 Objetivos
La Gestin de Niveles de Servicio garantiza que se mantengan y mejoren continuamente los servicios TI que
necesita el cliente. Esto se logra acordando, monitorizando e informando el rendimiento de la organizacin
TI, para crear una relacin de negocio eficaz entre la organizacin TI y sus clientes.
Una Gestin de Niveles de Servicio eficaz mejora el rendimiento y los resultados de los negados del cliente
creando mayor satisfaccin. Dado que la organizacin TI conoce ms lo que se espera de ella y lo que da,
tendr ms posibilidades para planear, presupuestar y manejar sus servicios.
Beneficios
En general, la introduccin de la Gestin de Niveles de Servicio tendr los siguientes beneficios:
-
Los servicios TI estn diseados para alcanzar las expectativas, como los define los Requisitos de Nivel
de Servicio.
El rendimiento del servicio se puede medir, lo que significa que se puede manejar e informar.
Si la organizacin TI cobra a los clientes por el uso de los servicios TI, el cliente puede sacar
conclusiones sobre la calidad del servicio y los costes correspondientes.
Ya que la organizacin TI puede especificar los servicios y los componentes necesarios, puede tener
control sobre la gestin de recursos y se pueden reducir los costes a largo plazo.
Se mejora la relacin con el cliente y la satisfaccin del mismo.
Tanto el cliente como la organizacin TI son conscientes de sus roles y responsabilidades, por lo que
habr menos malentendidos u omisiones.
10.3 El Proceso
La Gestin de Niveles de Servicio es un proceso que vincula al proveedor de servicio TI y al cliente para esos
servicios. El proceso de Gestin de Niveles de Servicio tiene varios objetivos:
-
Integrar los elementos necesarios para proveer los servicios TI.

Documentar los servicios describiendo claramente los elementos de los distintos documentos.
Describir los servicios que se prestan al cliente en una terminologa que puedan entender y que puedan
consultar.
Alinear la estrategia TI con las necesidades del negocio.
Mejorar la Entrega del Servicio TI de forma controlada.
La Gestin de Niveles de Servicio tiene un rol central en los procesos de la Gestin de Servicios TI, y tiene
fuertes vnculos con los otros procesos de Soporte y Entrega. La Gestin de Niveles de Servicio hace de
puente entre el cliente, ya que le da la oportunidad de discutir las necesidades de su negocio sin empantanarse
en detalles tcnicos. La organizacin TI despus traduce estas necesidades del negocio a especificaciones y
actividades tcnicas dentro de la organizacin. Podremos decir que la Gestin de Niveles de Servicio es
exitosa siempre y cuando el cliente no tenga que preocuparse por la tecnologa.
La Gestin de Niveles de Servicio demanda cooperacin eficaz y productiva con los clientes, porque la
definicin correcta de niveles de servicio requiere de la contribucin y el esfuerzo del cliente.
Si el cliente {el negocio) no se encuentra familiarizado con los temas, primero se tendr que tratar este tema.
La Figura 10.1 muestra la carga de trabajo de la Gestin de Niveles de Servicio compuesta por los dos
componentes del proceso: el superior trata de lograr acuerdos y el inferior de garantizar que se cumplan los
stos.
105
Figura 10.1 Proceso de la Gestin de Niveles de Servicio
La Gestin de Niveles de Servicio incluye las siguientes actividades:

-
106
Identificacin - identificar las necesidades del cliente, la gestin de la relacin, y la promocin de la

organizacin TI. Comprender los procesos del negocio y las necesidades del cliente.
Definicin - definir los servicios a proveer para satisfacer las necesidades y los requisitos del cliente.
Estos servicios se definen en los Requisitos de Nivel de Servicio y en las Hojas de Espec de Servicio.
Como resultado de esta actividad se originar el Plan de Calidad de Servicio.
Finalizacin - finalizar el contrato, es decir negociar con el cliente el nivel de servicio requerido, en
relacin a los costes, y definirlo en los Acuerdos de Nivel de Servicio (SLAs). Apuntalar los SLAs con
Acuerdos de Nivel de Operaciones (OLAs) y los Contratos de Apoyo (UCs). Escribir o revisar el
Catlogo de Servicios especificando los servicios disponibles para el cliente.
Monitorizacin - monitorizar los niveles de servicio.
Informacin - redactar los Informes de Niveles de Servicio. Informar al cliente y a la organizacin TI en
forma regular sobre los servicios reales, comparndolos con los Logros de Nivel de Servicio.
Revisin - revisar el servicio junto con el cliente para determinar las oportunidades para realizar mejoras.
Si es necesario, se puede comenzar con un Programa de Mejora de Servicio. Se puede establecer una
comunicacin continua con el cliente para conocer su experiencia e ideas sobre el servicio brindado. Esto
puede dar como resultado SLAs nuevos o corregidos.
Una Gestin de Niveles de Servicio completamente eficaz necesita de la introduccin de los otros procesos de
Soporte de Servicio y Entrega de Servicio. Todos los procesos contribuyen en algn punto con la Gestin de
Niveles de Servicio. Cuando se define un servicio y los niveles de servicio asociados, se debe considerar hasta
qu punto introducir los procesos de soporte. Las relaciones entre Gestin de Niveles de Servicio y los otros
procesos se resumen abajo.
Relacin con el Centro de Servicios
Aunque el Centro de Servicios es una funcin, no un proceso, la relacin entre la funcin del Centro de
Servicios y los procesos de la Gestin de Niveles de Servicio es en particular muy importante.
El Centro de Servicios es el punto de contacto inicial para los usuarios y, en el caso de un error intenta
recuperar los niveles de servicio acordados con la mayor rapidez posible, a travs de la Gestin de Incidentes.
Dado su contacto directo con los usuarios de los servicios TI, el Centro de Servicios generalmente puede
proporcionar informacin valiosa sobre la percepcin de calidad (satisfaccin del usuario) que tienen los
usuarios sobre la Gestin de Niveles de Servicio.
Normalmente habr una fuerte relacin entre la satisfaccin del usuario y del cliente. El Centro de Servicios
tambin juega un rol importante en la asistencia con la definicin de una respuesta y los tiempos de solucin
que se efectivizarn en caso de interrupcin del servicio.
Relacin con la Gestin de la Disponibilidad
La Gestin de la Disponibilidad es responsable de la ejecucin y la optimizacin de la disponibilidad de los
servicios. La Gestin de Niveles de Servicio proporciona a la Gestin de la Disponibilidad inputs sobre la
disponibilidad de los servicios TI, en tanto que la Gestin de la Disponibilidad da informacin a la Gestin de
Niveles de Servicio sobre la verdadera disponibilidad.
Relacin con la Gestin de la Capacidad
Gestin de la Capacidad tiene a su cargo el manejo de la capacidad de la infraestructura Tl. Se establecer un
Plan de Capacidad con detalles sobre el uso actual de la infraestructura, y las previsiones de uso futuro La
Gestin de la Capacidad ayuda a la Gestin de Niveles de Servicio dando informacin sobre el impacto de un
servicio nuevo o la extensin de uno ya existente en toda la capacidad. La Gestin de la Capacidad tambin
indica si se utiliza un servicio dentro de los lmites acordados.
La Gestin de Niveles de Servicio brinda informacin a la Gestin de la Capacidad sobre el uso esperado
actualmente y en un futuro, con el que la Gestin de Niveles de Servicio se ha comprometido o se est por
comprometer con el cliente.
Relacin con la Gestin de Incidentes & Problemas
La Gestin de Incidentes y la Gestin de Problemas son buenos indicadores de la efectiva implementacin de
los acuerdos SLA. La Gestin de Incidentes en particular cumple un rol importante en la veloz restitucin de
los servicios despus de un error.
La Gestin de Problemas tiene como objetivo optimizar la estabilidad de los servicios tomando medidas
permanentes que garanticen la no repeticin de los errores.
Resolver incidentes y problemas resulta esencial para proporcionar un servicio de alta calidad. La Gestin de
Niveles de Servicio utiliza la informacin de los informes que generan estos procesos al comunicarse con el
cliente.
Relacin con la Gestin de Cambios
El SLA puede definir los cambios que el cliente puede solicitar a la organizacin TI, y los acuerdos para
responder a estos cambios (a quin dirigir los cambios, ciclo de tiempo, costes, informar a la organizacin,
etc.). Un cambio tambin puede afectar los niveles de servicio con los que se ha acordado. La Gestin de
Cambios controla todos los cambios asociados a un servicio y al SLA asociado.
107

Relacin con la Gestin de Versiones
Muchos servicios TI suman la provisin de hardware de la infraestructura al software hecho a medida. La
Gestin de Versiones monitoriza los acuerdos que hace la Gestin de Niveles de Servicio en cuanto a
provisin de hardware y software. La Gestin de Niveles de Servicio informa sobre la calidad del servicio TI
en base a los informes de la Gestin de Versiones.
Relacin con la Gestin de Continuidad de Servicios TI
La Gestin de Continuidad de Servicios TI se ocupa de la rpida recuperacin de los servicios TI en caso de
desastre, y monitoriza las medidas y procedimientos correctos. Los acuerdos con el cliente sobre este tema se
hacen en el proceso de Gestin de Niveles de Servicio. Despus se incluyen las medidas y los costes en el
SLA. Se puede acordar que ante un desastre, ciertos niveles de servicio se reduzcan temporalmente o no
tengan efecto.
Los cambios al servicio y el SLA pueden necesitar una modificacin de las medidas y los procedimientos de
continuidad definidos.
Relacin con la Gestin de la Seguridad
Las medidas de seguridad asociadas con el servicio TI tambin resultan esenciales para la eficaz Gestin de
Niveles de Servicio. Tanto la organizacin TI como el cliente tendrn ciertos requisitos de seguridad. Los
acuerdos correspondientes se definen en el SLA. La Gestin de la Seguridad garantiza que se implementen,
monitoricen e informen las medidas de seguridad a la Gestin de Niveles de Servicio.
Relacin con la Gestin de Configuraciones
La Gestin de Configuraciones es responsable de introducir los detalles de las componentes (CIs) y la
documentacin (SLA) relacionados con el servido en la CMDB, y de dar informacin de su base de datos.
As, la creacin o modificacin de un servicio o SLA afectar la CMDB. El Centro de Servicios utiliza la
CMDB para determinar el impacto de un error en los servicios, y para verificar los acuerdos sobre la respuesta
y los tiempos de solucin. La CMDB tambin se utiliza para informar sobre la calidad de los CIs, para
permitir que la Gestin de Niveles de Servicio informe sobre la calidad del servicio brindado.
Relacin con la Gestin Financiera de los Servicios TI
Si se cobra al cliente por los servicios prestados por la organizacin TI, esto tambin se incluye en el SLA.
Estos pueden ser cargos por nica vez, o cargos por servicios especiales o adicionales. La Gestin Financiera
da informacin a la Gestin de Niveles de Servicio sobre los costes asociados a la provisin de un servicio.
Tambin da informacin sobre los mtodos de facturacin, y la tarifa a cobrar para cubrir los costes de un
servicio.
10.4 Actividades
A continuacin se describen las etapas del proceso, incluyendo el flujo de trabajo del proceso y las
actividades.
10.4.1 Identificacin
A medida que los negocios se hacen ms dependientes de sus servicios TI, tambin aumenta la demanda para
mayor calidad de servicios TI. La calidad percibida de un servicio depende de las expectativas del cliente, la
Gestin actual de las percepciones del cliente, la estabilidad del servicio, y la aceptabilidad de los costes. Por
estas razones, la mejor forma de dar la calidad que corresponde es discutirlo primero con el cliente.
Experiencias pasadas muestran que el cliente es poco claro sobre sus expectativas, ya que asumen que
simplemente se proporcionarn ciertos aspectos del servicio, sin haberlo acordado con claridad.
Estos aspectos asumidos (implcitos) de los servicios TI son a menudo causa de mucha confusin. Esto marca
otra vez la necesidad de que los Gestores de Nivel de Servicio conozcan bien a sus clientes, y que los ayuden
a clarificar sus ideas sobre los servicios y los niveles de servicio que realmente necesitan, y a qu coste.
108

Los requisitos del cliente se deben expresar en valores medibles para que puedan contribuir al diseo y
monitorizacin de los servicios TI. Si no se han acordado las mtricas con el cliente, no se podr verificar si
los servicios TI cumplen los acuerdos. La Gestin de Niveles de Servicio juega un rol principal para
comprender y definir lo que quiere el cliente.
El primer paso a determinar en los SLAs sobre los servicios que se proporcionan hoy o que se darn en el
futuro deber ser la identificacin y definicin de las necesidades del cliente en los Requisitos del Nivel de
Servicio. Adems de hacer eso una vez durante el proceso, tambin se debe hacer en forma regular,
inundndola con informes y revisiones, a pedido del cliente o para beneficio de la organizacin TI. Esta
actividad puede cubrir tanto servicios nuevos como existentes.
10.4.2 Definicin
Definir el alcance y la profundidad de los requisitos del cliente es considerado un proceso de diseo dentro de
la Gestin de Niveles de Servicio. De acuerdo al modelo de seguridad de calidad ISO 9001, un proceso de
diseo debera incluir los siguientes pasos:
-
diseo
desarrollo
produccin
instalacin y mantenimiento.
El proceso de diseo debera ser manejado para garantizar que los resultados al final del proceso se
correspondan con los requisitos del cliente. Durante el proceso de diseo, el trmino "externo" se refiere a las
comunicaciones con los clientes, e "interno" al apoyo tcnico dentro de la organizacin TI. El proceso de
diseo comprende una serie de pasos, desde el detalle de los requisitos del cliente y su definicin en
estndares, hasta el desarrollo de requisitos tcnicos para proporcionar el servicio.
Definicin de estndares externos
El primer paso para cuantificar los servicios TI nuevos o existentes es definir o redefinir las expectativas del
cliente sobre los servicios en trminos generales. Estas expectativas se formalizan por documentado en los
Requisitos de Nivel de Servicio (SLRs). Esto debe incluir a toda la organizacin de clientes. Es considerado el
paso ms difcil en la Gestin de Niveles de Servicio.
Al principio de esta etapa, el Gestor de Nivel de Servicio se debe preparar para el encuentro con la
organizacin de cliente. Las primeras preguntas a realizar son: "Qu se necesita del servicio TI y en qu
elementos debe consistir el servicio?" Un servicio puede implicar el uso de una infraestructura limitada, como
una Red WAN. Tal servicio puede contribuir a uno compuesto, como acceso a toda la informacin del
sistema, incluyendo la infraestructura completa (WAN, LAN, estaciones de trabajo, aplicaciones, etc.).
Durante estas reuniones, se debe dividir en grupos a los usuarios. La Gestin de Nivel de Servicio disea una
lista de los grupos de usuarios y sus requisitos y autoridad. Para definir los Requisitos de Nivel de Servicio es
necesaria la siguiente informacin:
-
Descripcin, desde la perspectiva del cliente, de las funciones a proveer por el servicio.
Horas y das en los que el servicio debe estar disponible.
Requisitos de continuidad del servicio.
Funciones TI necesarias para brindar el servicio.
Referencias a los mtodos de operacin actuales o los estndares a considerar cuando se define el
servicio.
Referencia al SLA a modificar o reemplazar si corresponde.
La etapa de diseo traer aparejado un documento de Requisitos de Nivel de Servicio, que estar firmado por
el Gestor de Nivel de Servicio y el cliente. Mientras el departamento se encuentra trabajando en el diseo,
adquisicin de mercaderas e implementacin se pueden modificar los Requisitos de Nivel de Servicio. Tales
cambios se pueden relacionar con la factibilidad de las funciones o costes previstos. Ambas partes deben
aprobar los cambios.
109
Traduccin a estndares internos

Durante la fase de especificacin, los Requisitos de Nivel de Servicio se estudian minuciosamente.
Esta etapa debe proporcionar la siguiente informacin:
-
Descripcin veraz y detallada de los servicios TI y de los componentes necesarios.

Especificacin de la forma en que se implementar y proporcionar el servicio.
Especificacin del proceso de control de calidad necesario.
Figura 10.2 Etapa de especificacin (fuente: OGC)
En la etapa de especificacin es conveniente distinguir entre elementos de documentacin para uso interno y
los de uso externo (Figura 10.2). Las especificaciones para uso externo se relacionan con los objetivos
acordados con los clientes y el control del proceso de diseo. Estas especificaciones se desarrollan junto con
la organizacin de cliente, y forman la entrada de las especificaciones para uso interno.
Las especificaciones para uso interno se refieren a los objetivos internos de la organizacin TI que se deben
cumplir para satisfacer las demandas del cliente. Una vez que el proceso de Gestin de Niveles de Servicio se
encuentra en marcha puede resultar muy til establecer una separacin entre las especificaciones internas y las
externas. Esto significa que la organizacin TI no preocupa a los clientes con detalles tcnicos. Desde ese
momento, la gestin de niveles de servicio se relaciona con el mantenimiento de acuerdo a las
especificaciones internas y externas. El Control de Documento y las Revisiones Internas contribuyen llevando
el registro de los documentos, administrando las versiones y organizando auditoras regularmente.
Las hojas Espec (especificaciones de servicio) describen con detalles lo que quiere el cliente (elemento
externo) y su impacto en la organizacin TI (elemento interno). Las Hojas Espec no necesitan estar firmadas
por ambas partes, sin embargo estn sujetas al Control del Documento. El Catlogo de Servicios se puede
disear en base a las especificaciones de servicio; de esta manera, los cambios en los niveles de servicio se
pueden incluir inmediatamente en las Hojas Espec y en el Catlogo de Servicios. Luego se analiza el SLA
junto con las Hojas Espec revisadas.
110

Plan de Calidad de Servicio
Se recomienda incluir toda la informacin de gestin (indicadores de rendimiento claves) y las
especificaciones para los proveedores internos y externos en un solo documento con el objeto de proporcionar
ms informacin sobre las contribuciones que cada proceso de la Gestin de Servicios hace a los servicios TI.
10.4.3 Contrato
Una vez que se completa la fase de especificacin, la organizacin TI ha de traducir las necesidades del
negocio en recursos TI y configuraciones. Esta informacin se utiliza ms tarde para disear o modificar los
siguientes documentos.
Acuerdo de Nivel de Servicio
Cuando se desarrolla la estructura SLA, primero se recomienda definir los aspectos generales, tales como los
servicios de red para toda la empresa y el desarrollo de un modelo SLA basado en el servicio, antes de
comenzar con las negociaciones. Los SLAs pueden tener una estructura jerrquica como la de la organizacin
de cliente, en forma de acuerdo con cierto nmero de grados.
Cada grado cuenta con su propio nivel de detalle. Los grados superiores incluyen acuerdos sobre los servicios
generales a proveer a la organizacin. Los grados inferiores tienen informacin relevante a clientes
especficos.
La estructura del SLA depende de un nmero de variables:
-
Aspectos fsicos de la organizacin:

Extensin
Complejidad
Distribucin geogrfica
Aspectos culturales:
Idioma(s) del documento (para organizaciones internacionales)
Relacin entre la organizacin TI y el cliente
Poltica de fijacin de precio
Uniformidad de las actividades del negocio
Organizacin lucrativa o no lucrativa
Naturaleza de las actividades del negocio:

Condiciones y trminos generales
Horario del negocio - 5 x 8 horas o 7 x 24 horas
Contratos de Apoyo y Acuerdos de Nivel de Operaciones

Durante el proceso de diseo se debe revisar cualquier UCs u OLAs existente. Cada persona involucrada debe
conocer el UCs u OLAs para aplicarlo a la provisin de un servicio especfico. Los ndices de Control de
Documento pueden ayudar a clarificar los vnculos con las Hojas Espec.
Catlogo de Servicios
- Use el lenguaje de su cliente. Evite la terminologa tcnica y utilice trminos pertinentes al negocio.
- Trate de mirar las cosas desde el punto de vista del cliente y use este planteamiento para identificar la
informacin relevante.
- Presente un diseo atractivo ya que la organizacin TI usa este documento para presentarse ante los
clientes.
- Asegrese de que el documento est a disposicin de la mayor cantidad de stakeholders posible, por
ejemplo publicndolo en un sitio Intranet o en un CD-ROM.
111
10.4.4 Monitorizacin
La Gestin de Niveles de Servicio slo puede ser monitorizada si se definen por adelantado y con claridad los
niveles de servicio que deben corresponder con los objetivos acordados externamente. La monitorizacin no
debe limitarse a los aspectos tcnicos, tambin debe incluir temas de procedimiento.
Por ejemplo, hasta que se informa al usuario que se restableci el servicio, ste asumir que el servicio no est
disponible.
La Gestin de la Disponibilidad y la de Capacidad por lo general dan informacin sobre la implementacin de
los objetivos tcnicos asociados con el nivel de servicio. En algunos casos, la informacin tambin puede
venir de los procesos de Soporte de Servicio, especialmente de la Gestin de Incidentes. Sin embargo, no es
suficiente medir los parmetros internos porque no interesan al usuario. Tambin se deben medir los
parmetros como tiempo de respuesta, tiempo de escalamiento y soporte. Slo se obtiene una visin completa
si se combina la informacin de administracin de sistemas y la de la Gestin de Servicios.
10.4.5 Informes
Los informes de clientes (Informes de Servicio) se deben presentar a intervalos regulares como se acuerda en
el SLA. Estos informes comparan los niveles de servicio acordados y los niveles de servicio que se miden en
realidad. Los contenidos de los informes pueden incluir:
-
Disponibilidad y tiempo ocioso durante un periodo especfico.

Tiempos de respuesta promedio durante las horas pico.
Tiempos de transaccin durante los periodos pico.
Nmero de errores funcionales en el servicio TI.
Frecuencia y duracin de la degradacin de servicio (servicios que no alcanzan el nivel).
Nmero de usuarios promedio en las horas pico.
Nmero de intentos exitosos y fallidos al intentar violar la seguridad.
Proporcin de capacidad de servicio utilizada.
Nmero de cambios completos y abiertos.
Coste del servicio que se brinda.
10.4.6 Revisin
Se deben revisar los niveles de servicio a intervalos regulares. Es necesario considerar los siguientes aspectos:
-
Acuerdos de nivel de servicio desde la revisin anterior.

Problemas relacionados con los servicios.
Identificacin de las tendencias de los servicios.
Cambios a los servicios dentro de los niveles de servicio acordados.
Cambios en los procedimientos y estimacin del coste de los recursos adicionales.
Consecuencias que trae una fallo en el suministro de los niveles de servicio acordados.
Si los servicios TI no cumplen con los niveles de servicio acordados, se deben implementar acciones para
mejorarlo:
-
Desarrollo de un Programa de Mejora de Servicio.

Asignacin de personal y recursos adicionales.
Modificacin de los niveles de servicio definidos en el SLA.
Modificacin de los Acuerdos de Nivel de Operaciones y los Contratos de Apoyo.
En muchas organizaciones en los que se est introduciendo la Gestin de Niveles de Servicio hay discusiones
sobre si se deben aplicar sanciones en caso de no cumplir con los acuerdos del SLA. Este es un tema difcil ya
que la Gestin de Niveles de Servicio se basa en la interaccin entre el departamento TI y los usuarios de
servicio TI, a menudo dentro de la misma organizacin. En dicha situacin, donde canto el departamento TI
como los usuarios trabajan en pos de lograr los mismos objetivos corporativos, no es claro si las sanciones, en
especial las multas de dinero, contribuyen a los intereses corporativos. Puede resultar mucho ms til hacer
112

acuerdos basados en el inters comn sobre las medidas a tomar para evitar fallos y cumplir as con los
niveles de servicio. Sin embargo, pueden surgir sanciones si el proveedor de servicio TI obtiene un servicio de
un proveedor TI externo. Pero en ese caso es ms factible que legalmente exista un contrato provisional (UC)
y no un SLA.

Para optimizar el proceso y su control se deben identificar una serie de factores de xito crticos. Los
indicadores de rendimiento tambin son necesarios para medir el proceso.
10.5.1 Factores crticos de xito e indicadores clave de rendimiento

El xito de la Gestin de Niveles de Servicio depende de los siguientes factores:
-
Un Gestor de Nivel de Servicio capaz que tenga experiencia en el negocio y en el entorno TI, y una
organizacin que ayude cuando sea necesario.
Misin y objetivos claros.
Campaa de concienciacin para dar informacin a la gente sobre el proceso, para que comprendan y
presten ayuda.
Tareas bien definidas, autoridades y responsabilidades dentro del proceso; distinguiendo entre control del
proceso y tareas operativas (contactos con el cliente).
Los siguientes indicadores clave de rendimiento se pueden utilizar para determinar la eficacia y la eficiencia
del proceso de la Gestin de Niveles de Servicio:
-
Elementos de servicio incluidos en el SLA.

Elementos del SLA incluidos en OLAs y UCs.
Elementos de los SLAs que se monitorizan y donde en los que se informa sobre las fallos.
Elementos de los SLAs en los que se cumple con los niveles de servicio acordados.
Defectos que se identifican y se cubren en el plan de mejora.
Acciones que se toman para eliminar estos defectos.
Tendencias identificadas con respecto a los niveles de servicio verdaderos.

Los informes de gestin, a diferencia de los de nivel de servicio, no se muestran al cliente pero se utilizan
para controlar y mejorar los servicios internos. Pueden tener mtricas sobre los niveles de servicio que
soportan en realidad y sobre tendencias como:
-
Nmero de SIAs concluidos.

Cantidad de veces en las que no se cumpli con el SLA.
Coste de monitorizacin y medicin del SLA.
Satisfaccin del cliente, basndose en las quejas.
Estadsticas sobre incidentes, problemas y cambios.
Progreso de las acciones de mejora.

Roles
La Gestin de Niveles de Servicio debe estar controlada por un Gestor de proceso. Este Gestor debe
garantizar que el proceso sea eficaz y que proporcione los beneficios previstos. Esto no necesariamente
significa que esta posicin debe ser ocupada por una sola persona. Muchas organizaciones cuentan con
muchos Gestores de Nivel de Servicio, cada uno responsable de uno o ms servicios o de grupos de clientes.
113

Responsabilidades
El Gestor de Nivel de Servicio es responsable de:
-
Disear y actualizar el catlogo de servicios.

Definir y mantener un proceso de Gestin de Niveles de Servicio para la organizacin TI, incluyendo:
Estructura SLA
OLAs con los proveedores internos
UCs con los proveedores externos
Actualizar el Programa de Mejora de Servicio existente.
Negociar, concluir y mantener SLAs, OLAs y Ucs.
Revisar el rendimiento de la organizacin TI y mejorarla si es necesario.
10.6 Problemas y costes

10.6.1 Problemas
- La Gestin de Niveles de Servicio tiene que establecer una relacin formal con el cliente y necesita que
todo el personal TI se adhiera a los acuerdos. Para ello puede ser necesario un cambio de cultura.
- Los clientes pueden necesitar ayuda para especificar los Requisitos de Nivel de Servicio.
- Puede resultar muy difcil expresar las expectativas del cliente en trminos de estndares medibles y
costes asociados.
- El Gestor de Nivel de Servicio debe ser cuidadoso con los acuerdos demasiado ambiciosos en tanto no se
hayan desarrollado la planificacin, las herramientas de medicin y monitorizacin, el procedimiento, el
Plan de Calidad de Servicio, y los Contratos de Apoyo. Es mejor utilizar una estrategia de mejora
gradual.
- Los costes generales asociados con la monitorizacin y la medicin de los niveles de servicio son
fcilmente subestimados. En grandes organizaciones puede hacer falta gran cantidad de personal
dedicado.
- En la prctica, muchas organizaciones TI comienzan con el Acuerdo de Nivel de Servicio y se saltan los
anlisis de requisitos del cliente, la etapa de diseo y el desarrollo del Plan de Calidad de Servicio. Esto
puede dar como resultado un proceso difcil de manejar y que no proporciona estndares claros y
mensurables.
- Los documentos y procesos de la Gestin de Niveles de Servicio podran terminar siendo fines en si
mismos y no los medios para mejorar la relacin entre el proveedor de servicio TI y el cliente.
10.6.2 Costes
Los costes necesarios para implementar la Gestin de Niveles de Servicio pueden dividirse en las siguientes
categoras:
-
114
Costes de personal (Gestor de Nivel de Servicio y equipo de proyecto).

Costes de formacin.
Costes de documentacin.
Costes de instalaciones, hardware y software.
Costes de actividades de operacin relacionadas con la actualizacin del Plan de Calidad de Servicio, los
Acuerdos de Nivel de Servicio, y el Catlogo de Servicios.
Captulo 11:
11.1 Introduccin
Mucha gente ve a los servicios TI como una importante contribucin al soporte de las actividades rutinarias del negocio,
pero son muy pocos los que entienden que esos servicios cuestan dinero. A medida que aumenta el nmero de usuarios, se
incrementa el presupuesto T l . Los clientes se interesan ms por los gastos de TI cuando aumenta el presupuesto y, sin
ayuda, no pueden orientar este gasto al negocio. Si se cobra por servicios TI y no se brinda ayuda al cliente, ste no puede
relacionar los costes reales por cliente con los beneficios del negocio.
La metodologa ITIL fue desarrollada como una estructura de gestin de la infraestructura TI con el objetivo de promover
el uso eficaz y econmico de los recursos TI. Uno de los objetivos era transformar las organizaciones basadas en el
presupuesto -de presupuesto fijo- en organizaciones serias y conscientes de los costes.
Calidad y Costes
Proporcionar servicios TI a los usuarios a un coste razonable depende de tres factores:
-
Calidad - en trminos de operacin de:

Capacidad

Disponibilidad

Rendimiento

Recuperacin ante desastres

Soporte
Coste - en trminos de:

Gasto

Inversin
Requisitos del cliente

el coste y la calidad deben alinearse con las necesidades de los usuarios con relacin al negocio.
Los dos primeros factores se encuentran a menudo en conflicto porque la mejora de calidad en general significa
incremento de costes, en tanto que la reduccin de costes implica una reduccin de calidad.
Sin embargo, estos dos factores se pueden balancear al centrarse en las necesidades del cliente. El conocimiento de los
costes asociados con la provisin de servicios TI y la aplicacin de un sistema de cobro realista para esos servicios ponen
al aprovisionamiento del servicio TI en una slida posicin en el negocio. Los clientes tomarn ms conciencia de los
costes y sentirn que estn abonando un precio justo, y de esa forma no malgastarn los recursos TI.

Realizacin de Presupuestos
La realizacin de presupuestos involucra la prediccin de los costes y el control de gasto. Esto, a menudo comienza con la
preparacin de un plan, previa demanda del cliente, para los servicios y los costes relacionados.
Se puede hacer un pronstico en base a datos histricos, mientras se tienen en cuenta las actuales tendencias del negocio y
se confa en la experiencia del personal. De no contar con datos histricos, podra ser posible usar servicios similares
como modelo.
Contabilidad
Contabilidad significa controlar cmo gasta el dinero la organizacin IT. Es muy importante poder determinar los costes
para cada cliente, servicio, actividad, etc. En esta instancia, es vital comprender los temas ms que establecer el coste.
Precio
Con precio nos referimos a todas las actividades necesarias para facturar al cliente por los servicios que se prestan. El
precio incluye la determinacin de el/los objetivo(s) del precio, as como tambin el/los algoritmo(s) necesarios para
calcular el precio. Para esto es necesario un sistema confiable eficaz que cumpla las necesidades de detalle de los
diferentes niveles contables: anlisis, movimiento total, informes.
115

Categoras de coste
Para aplicar un control de coste eficaz hace falta entender la naturaleza de los costes. Los costes a pueden clasificar de
muchas formas.
Para cada producto o servicio se pueden determinar los costes que contribuyen con estos y los que no
-
Costes directos - costes relacionados especfica y exclusivamente a un servicio TI. Por ejemplo las actividades y los
materiales que se asocian en forma directa y nica con un servicio especfico (alquiler de lnea telefnica para
acceder a Internet).
Costes indirectos - los costes que no estn especfica y nicamente relacionados con un servicio TI. Ejemplos
incluyen instalaciones (p. ej. un escritorio), servicios de soporte (p. ej. administracin de redes) y costes
administrativos (incluyendo tiempo).
Una opcin para cobrar los costes indirectos es prorratearlos entre servicios o clientes.
Otra opcin es utilizar el Contabilidad de Costes Basada en la Actividad (ABC). Este mtodo comienza reuniendo todos
los costes generales y asignando los costes de las actividades a los productos y servicios necesarios para el desarrollo de
esas actividades.
En esencia los costes se cargan con base en criterios que no sean costes directos. ABC puede ser til como mtodo de
cobro si no hay muchos costes relacionados de manera directa con el volumen de servicio. En vez de asignar los costes
indirectos arbitrariamente, ABC lo hace en base a los productos y servicios necesarios para desarrollar las actividades.
Otra forma de entender los costes, es dividirlos en costes fijos y variables.
-
Costes fijos - son independientes del volumen de produccin; incluyen inversiones en hardware, software y edificios.
En muchos casos, se consideran la depreciacin y el inters mensual y anual ms que el precio de compra. Los costes
fijos continan aunque el volumen de produccin (servicio) est reducido o interrumpido.
Costes variables - son costes que cambian de nivel junto con los cambios en el volumen de produccin. Como
ejemplos tenemos el personal externo, los cartuchos de impresin, el papel, la calefaccin o la electricidad. Estos
costes se relacionan con los servicios proporcionados por lo que si se incrementa el volumen de produccin, tambin
se incrementan los costes. Los costes de capital y de operacin merecen cierta distincin:
Costes de capital - se relacionan con la compra de activos con la intencin de utilizarlos a largo plazo dentro de la
organizacin. Los costes se deprecian a lo largo de los aos. De esa manera, los costes se suman a la depreciacin
ms que al precio de compra.
Costes de operacin - son los costes diarios no asociados a los recursos de produccin tangibles. Como ejemplos
tenemos contratos de mantenimiento de hardware y software, costes de licencia, primas de seguro, etc.
Tipos de Coste
Una vez que se define el coste contable de la estructura (p. ej. por departamento, servicio o cliente), se pueden establecer
los tipos de coste a asignar el coste de los tem en las cuentas. Los tipos de coste deben tener una descripcin y estructura
clara y reconocible para que sea fcil ubicarlos.
Los tipos de coste se subdividen en elementos de coste. Los mtodos de cobro para cada elemento de coste se puede
definir en las etapas posteriores. Existen seis tipos de coste principales, algunos para los costes directos y otros para los
indirectos.
Figura 11.1 Tipos y elementos de coste (fuente: OGC)
116
Ejemplos de estos tipos de coste incluyen:

-
Unidad de Coste de Equipamiento (ECU) - todo el hardware TI como:

Servidores

Almacenamiento en disco

Comunicacin y redes

Impresoras
Unidad de Coste de Software (SCU) - costes directos e indirectos relacionados con el software, incluyendo:

Software del Sistema

Software de procesamiento de transaccin

Sistemas de administracin de base de datos

Sistemas de administracin de sistemas

Sistemas de desarrollo de aplicaciones

Aplicaciones
Unidad de Costes de Organizacin (OCU) - costes directos e indirectos de personal, que pueden ser fijos o
variables, como:

Salarios

Capacitacin

Viajes
Unidad de Coste de Instalaciones (ACU) - todos los costes directos e indirectos asociados con las instalaciones:

Salas de ordenadores

Oficinas

Otras instalaciones como habitaciones de prueba, de capacitacin, aire acondicionado, etc.
Coste de Transferencia de Unidad (TCU) - los costes asociados con los bienes y servicio de otro departamento. Es
decir, cargos internos entre los departamentos de una organizacin.
Costes Contables (CA) - costes asociados a las actividades de gestin financiera.
11.2 Objetivos
La Gestin Financiera tiene como objetivo ayudar a la organizacin TI interna administrando de una manera efectiva los
costes de los recursos TI necesarios para proporcionar los servicios TI. Por esta razn, el proceso tiende a desglosar los
costes del servicio TI y a relacionarlos con los distintos servicios TI provistos. De esta manera trata de ayudar con las
decisiones de gestin referentes a inversiones TI y alienta el uso consciente del coste de las instalaciones TI.
Al elegir los mtodos de precio se puede elegir entre la recuperacin total del coste, la recuperacin con ayuda financiera
(presupuestos), o la recuperacin para tener una ganancia predefinida.
Beneficios
Una vez que la organizacin TI introduzca la Gestin Financiera, ser capaz de:
-
Determinar los costes de los servicios TI.

Identificar y clasificar el coste de la estructura.
Asignar mejor los costes de los servicios TI que se dan a los clientes internos y externos.
Introducir mtodos de precio para el uso de los servicios T I , si corresponde.
Operar el departamento TI como unidad de negocio, si corresponde.
Recuperar todos los costes, incluidos los costes de capital (inversin, reembolso, depreciacin e intereses) del cliente.
Evaluar a menudo los cargos para determinar s todava son realistas y aceptables.
Modelar el comportamiento de los clientes y usuarios construyendo conciencia del coste y vinculando los costes
directamente con los servicios.
Dada la naturaleza diversa de los beneficios, hacemos una distincin entre la Elaboracin del Presupuesto (que tienen que
ver con el Coste) y la Fijacin de Precio.
La ventaja ms importante de la Elaboracin del Presupuesto es que ayuda a realizar la gestin con una mejor
informacin sobre los costes de provisin de los servicios TI. Esta informacin hace posible que la gestin TI equilibre los
costes y la calidad para dar un servicio financieramente justificable.
117
La Elaboracin del Presupuesto ayuda al Gestor de Servicios TI a:

-
Tomar decisiones para cada servicio, basndose en la efectividad del coste.

Desarrollar un planteamiento serio para decidir sobre los servicios TI y las inversiones relacionadas.
Dar ms informacin para dar soporte al gasto, por ejemplo mostrando los costes de evitar los gastos estratgicos.
Desarrollar presupuestos y planes en base a informacin fiable.
La ventaja principal de la Fijacin de Precios es la promocin de una relacin seria con el cliente. Un cliente que abona la
cuenta tiene derechos y puede presentar demandas, pero tambin hace uso ms responsable si es conciente del vnculo
entre las demandas que efecta y la factura que recibe.
La Fijacin de Precio permite que la Gestin de Servicios TI:
-
Revise los servicios TI seriamente y realice planes de inversin basados en la recuperacin del coste.
Recupere los costes TI vinculndolos con el uso que se hace de los servicios.
Influencie el comportamiento del cliente, por ejemplo fijando precios ms altos durante las horas pico, o simplemente
dando informacin sobre el coste y la utilizacin de los servicios sobre los que la gestin puede tomar medidas.
La introduccin de la Fijacin de Precio debe tender a influenciar el comportamiento del cliente y no a llegar a una
situacin en la que el cliente consiga lo que quiera solo porque paga. Por ejemplo, no es posible cumplir con los requisitos
de precio de cada usuario en particular, an cuando estos usuarios puedan abonar por ese servicio. La Fijacin de Precio
abre un ambiente serio para la negociacin.
Los clientes sern ms concientes de los costes asociados con el uso de las instalaciones TI.
11.3 El Proceso
El rol de TI en la industria se ha expandido mucho en los ltimos aos. As, la organizacin TI se enfrenta con requisitos
ms exigentes en trminos de calidad y eficiencia de coste de los servicios TI. Los desarrollos relacionados con Internet
implican que la organizacin TI tambin debe tratar cada vez ms con clientes y usuarios fuera del negocio.
Las libreras, p. ej. ponen sus catlogos en Internet y prestan servicios a los clientes alrededor del mundo. Esto aumenta la
escala de operacin y por lo general resulta necesario obtener ms informacin sobre los costes. La eficiencia de coste
tambin precisa de acuerdos sobre los servicios a brindar y los costes razonables a cobrar por tales servicios. Las
organizaciones TI deben ser ms serias, y establecer un sistema de control de costes eficiente es parte de ello.
Un sistema de control de coste eficiente debe cumplir con los siguientes criterios:
-
Ayudar al desarrollo de una estrategia de inversin que permita la flexibilidad que proporciona la tecnologa
moderna.
Identificar las prioridades en el uso de recursos.
Cubrir los costes de todos los recursos TI utilizados en la organizacin, incluyendo la actualizacin de la informacin
pertinente.
Ayudar a la gestin en las decisiones diarias para que las que son a largo plazo puedan tomarse con el menor riesgo
financiero posible.
Ser flexible y capaz de responder rpidamente a los cambios en las actividades del negocio.
La Gestin Financiera ayuda al negocio en el planeamiento y la realizacin de sus objetivos del negocio. Se debe utilizar
de manera consistente en todo el negocio, con un conflicto mnimo, para optimizar su eficiencia. En una organizacin TI,
la Gestin Financiera se implementa a travs de tres procesos principales:
Elaboracin de Presupuesto,
Contabilidad y
Fijacin de Precio.
Este ciclo se ilustra en la Figura 11.2.

La Gestin Financiera de los Servicios TI interacta con casi todos los otros procesos de la Gestin de Servicios TI, pero
depende y tiene ms responsabilidades con los procesos que se detallan ms adelante.
118
Figura 11.2 Ciclo Financiero (fuente OGC)
Relacin con los procesos del negocio

La Gestin de Niveles de Servicio es importante para definir la visin, estrategia y planeamiento de los procesos del
negocio (Figura 11.3). Aunque estas actividades caen fuera del alcance de la Gestin Financiera, contribuyen mucho con
esta rea. Esto se debe a que el negocio tiene una visin de futuro, que se utiliza para definir objetivos medibles que
afectan a todas las unidades del negocio y que tambin pueden utilizarse para establecer objetivos medibles para la
organizacin TI.
Figura 11.3 Relacin con el proceso del negocio
Por eso, la estrategia TI debe basarse en los objetivos del negocio. En tanto la organizacin TI se familiarice ms con los
negocios, se crearn oportunidades para hacer uso eficiente de los costes de la nueva tecnologa TL Los costes Tl de
implementacin y operacin se deben comparar con las ventajas del negocio en trminos de costes de operacin reducidos
y aumento del volumen de ventas.
119

Relacin con la Gestin de Niveles de Servicio
El SLA define las expectativas del cliente y las obligaciones de la organizacin de gestin TI. Los costes en los que se
incurre para cumplir con los requisitos del cliente tienen un gran impacto en la forma y escala de los servicios acordados
con el cliente. Ej. Gestor de Finanzas de la organizacin TI consulta al Gestor de Nivel de Servicio sobre temas tales
como el coste de alcanzar los requisitos los negocios actuales y futuros, la poltica de Fijacin de Precios de la
organizacin y su efecto en los clientes, y cmo la poltica afecta al comportamiento del cliente.
Cuanto ms niveles de servicio diferentes permita el SLA para los distintos clientes, ms importantes y amplios sern los
beneficios de la Fijacin de Precios para los servicios TI. Esto tambin aumentar los gastos generales resultantes de los
procesos de Elaboracin de Presupuesto, Contabilidad y facturacin de los servicios.
Relacin con la Gestin de la Capacidad
La provisin de la capacidad y la disponibilidad estarn influenciadas por la informacin de coste. Puede ser necesario
discutir el coste de provisin de una capacidad incrementada y de una disponibilidad mejorada con el cliente o el negocio
como un todo. La informacin de coste versus el beneficio del negocio pueden influenciar la decisin sobre la compra o
no de capacidad adicional o la mejora o no de la disponibilidad.
La Gestin de Configuraciones especifica, identifica y registra todos los cambios de todos los componentes de la
infraestructura. El uso de informacin, incluyendo la informacin de coste en la CMDB facilita la recopilacin de datos de
costes histricos. La Gestin de Configuraciones tambin puede utilizarse para conciliar los datos sobre activos con los
datos de los sistemas financieros.
11.4 Actividades
11.4.1 Elaboracin del Presupuesto
El objetivo de la Elaboracin del Presupuesto es planear y controlar las actividades de una organizacin.
La planificacin corporativa y estratgica tiene que ver con los objetivos a largo plazo del negocio. Los presupuestos
definen los planes financieros para los objetivos durante el periodo que cubre el presupuesto. Estos periodos por lo general
abarcan de uno a cinco aos.
Mtodos de elaboracin del Presupuesto
Dependiendo de la poltica financiera del negocio se selecciona uno de los siguientes mtodos:
-
Elaboracin del Presupuesto Incremental - se utilizan los nmeros del ao anterior como base para el nuevo
presupuesto. Luego se ajusta para reflejar los cambios que se esperan.
Elaboracin del Presupuesto con Base Cero - este mtodo comienza con un papel en blanco: la Base Cero. Se
ignora la experiencia pasada. Para ello cada Gestor debe justificar en sus presupuestos todas sus necesidades de
recursos en trminos de coste. Esto significa que se debe evaluar y decidir si se debe realizar cada gasto, como as
tambin a qu coste. Obviamente, este mtodo consume ms tiempo, y solo se utiliza cada ao o dos. El mtodo
incremental se usa para el resto de los aos.
Proceso de Elaboracin del Presupuesto

La elaboracin del presupuesto comienza identificando los factores clave que limitan el crecimiento de la empresa. En
muchos negocios, es por el volumen de ventas; sin embargo, tambin se puede deber a la falta de espacio o materiales. A
menudo, las restricciones financieras determinan el presupuesto. En este proceso se incluye la definicin de los siguientes
presupuestos secundarios (ignoraremos los procesos de aprobacin que se utilizan en cada negocio):
-
120
Presupuesto de ventas y marketing - si el volumen de ventas determina el presupuesto, entonces el departamento

de marketing es responsable de una parte amplia del proceso. Un correcto anlisis y evaluacin de los clientes,
mercados, regiones de venta, productos, etc. son esenciales para elaborar un buen presupuesto.
Presupuesto de produccin - el presupuesto de produccin brinda informacin detallada sobre los servicios a
ofrecer: cantidades, tiempos de entrega, personas por hora necesarias, materiales necesarios, etc.
Presupuesto administrativo - basados en el servicio a proveer, se deben determinar los gastos generales de
presupuesto para los departamentos que corresponda, tales como produccin, ventas y distribucin, investigacin y
desarrollo, etc.
Presupuestos de coste e inversin - el presupuesto de coste se obtiene de los planes de los presupuestos anteriores.
El presupuesto de inversin identifica los gastos asociados con el reemplazo y la compra de medios de produccin.
Los proyectos de inversin que se inician el ao anterior tambin pueden afectar el presupuesto de inversin.
Periodo Presupuestal
El ao financiero (fiscal) podra ser una opcin clara para fijar el periodo presupuestal. Para hacer una comparacin entre
los nmeros actuales y los del presupuesto, el periodo presupuestal se divide en meses u otro periodo particular, como
ventanas de cuatro semanas.
Algunos negocios, adems de disear un presupuesto anual detallado, hacen una previsin general para un periodo de
entre tres y cinco aos. Esto da informacin a la gestin senior sobre las expectativas en un periodo ms amplio.
11.4.2 Contabilidad
Para poder dirigir una organizacin TI como negocio, es esencial que se identifiquen y entiendan todos los costes por los
que la organizacin es responsable. Se deben determinar los costes aunque no se cobren al cliente. Los costes solo pueden
controlarse si se entienden claramente. Esto no trata de identificar costes menores sino ms bien las distintas formas en las
que se pueden estructurar los costes, lo cual incrementa la comprensin de la forma en la que se gasta el dinero.
Una de las actividades primarias de Contabilidad es definir los elementos de coste. Esta estructura es fija durante un ao,
tras el cual se puede modificar. En muchos casos, el mtodo de contabilidad de costes se selecciona al introducir una
estructura de elemento de coste en el negocio. De esta manera, la estructura de elemento de coste debe ser compatible con
los mtodos que adopta el negocio. En ocasiones se registran los costes para cada departamento, cliente o producto. Sin
embargo, sera ideal que la estructura refleje los servicios proporcionados. An cuando el proceso no se utiliza para fijar el
precio, resulta muy til basar el tipo de coste de la estructura en una estructura de servicio, como la que se usa en un
catlogo de servicios.
Aplicacin del Negocio

Contable

Gestin de Relaciones
Terminal Emulator entorno IBM

Datos de Marketing
Terminal Emulator otros entornos
Intranet, Extranet e Internet

Servicios de Informacin
Groupware
Mail & servicios de directorio
Aplicaciones de la oficina
Servicios de Archivo & Impresin
Sistema Operativo Windows 98
Estacin de trabajo
Lnea Base-A
PC de escritorio poderosa
Sistema Operativo Windows NT 4.0
Estacin de trabajo
Lnea Base-B
PC de escritorio estndar
Estacin de trabajo
Lnea Base-C
PC Laptop
Servicios de Conexin a la red (LAN & WAN)

Figura 11.4 Ejemplo de estructura de servicio
En el ejemplo de la Figura 11.4 hay una estructura jerrquica de los elementos de servicio que crea la organizacin para
proporcionar los servicios. En esta estructura, los elementos de servicio de los niveles inferiores ayudan a los niveles
superiores. Cuanto ms alta es la posicin de los elementos dentro de la estructura, ms relevante la funcin para el
negocio.
121

Despus de definir los elementos de servicio, se deben definir los elementos que se subdividen en unidad de coste para
personal, hardware, software y gastos generales. La ventaja de estructurar los elementos de coste y los de servicio es que
se torna visible el gasto en hardware, software y servicio de soporte.
Adems de una estructura basada en los costes directos como se muestra en la Figura 11.4, tambin se puede decidir cmo
asignar los costes indirectos a los servicios. Cuanto ms detallado es un servicio ms fcil ser entender los costes. De
manera alternativa, el catlogo solo puede tener en la lista tres estaciones de trabajo estndar que incluyan todo. En este
caso, el diagrama solo tendr tres columnas y muchos menos elementos de coste.
Esto puede resultar ms claro, pero tambin ser menor la cantidad de informacin detallada disponible. Por ejemplo, no
habr elementos de coste claros que el soporte de red pueda asignar y ser por lo tanto imposible determinar el soporte
necesario para la red.
Los presupuestos para el ao siguiente se elaboran para cada servicio y elemento de coste con base en la experiencia
pasada y a las estimaciones de crecimiento para el ao prximo. Estos presupuestos se monitorizan todos los meses para
identificar cualquier desarrollo nuevo, como crecimiento inesperado, y para responder de acuerdo con la poltica del
negocio, si corresponde.
11.4.3 Fijacin de precios

Llevar un informe de costes no es una idea nueva, pero se vuelve cada vez ms importante. Sin embargo, fijar el precio de
los costes internos es una tendencia nueva. La fijacin de precio interna es una herramienta importante para alentar a los
usuarios a usar la infraestructura TI con ms cuidado. Pero, la fijacin de precios para los servicios TI no resulta tan til si
no se cobra a los 'budget holders' en las organizaciones de cliente por otros servicios, como telfono, comodidad,
habitacin de mail, catering y administracin de personal. En otras palabras, la fijacin de precios debe ser compatible con
las polticas financieras de la empresa. Si la Fijacin de Precios es justa, los 'budget holders' pueden asignar los costes de
operacin que pueden trasladar al precio de sus productos y servicios.
Por lo general, al fijar el precio se tratan de recuperar todos los costes en los que se incurre. En ese caso, la organizacin
TI opera como unidad de negocio. Esto solo es factible si se conocen los costes de operacin reales de los servicios TI.
Poltica de Fijacin de Precios
Es til tratar las polticas de fijacin de precios antes de establecer una tasa.
Existen varios mtodos de fijacin de precios. El mtodo correcto puede seleccionarse segn los objetivos de la Gestin
Financiera. De manera alternativa, cuando se introduce la fijacin de precio en etapas, se puede utilizar una poltica
distinta para cada etapa. Las polticas de fijacin de precio son:
-
Comunicaciones de informacin - se informa a los gestores de clientes sobre los cargos para que tomen
conocimiento de los costes por el uso de los servicios TI de sus departamentos. Existen dos opciones para esto:

Calcular los costes que tienen que ver con cada unidad del negocio e informar a los gestores implicados.
Como arriba, pero incluyendo los cargos a pasar, basados en un mtodo de fijacin de precio especfico.
Flexibilidad de precio - las tarifas se determinan y se cobran en base anual. Si el proveedor de servicios toma la
iniciativa de invertir en un servicio que se usa con ms frecuencia, el contrato puede incluir una clusula para cobrar
costes adicionales. La alternativa es ofrecer capacidad en exceso a los otros clientes potenciales.
Cobro terico - los costes se facturan pero no es necesario pagarlos. Este mtodo permite a la organizacin TI ganar
experiencia con el proceso y corregir cualquier error del sistema de cobro.
Tambin da al cliente la oportunidad de acostumbrarse al cobro. Sin embargo, este mtodo de cobro solo resulta til si los
costes eventualmente se recuperan, ya que de ser as el coste de conocimiento disminuir.
Tarifas
A menudo es difcil establecer la tarifa de un servicio. Fijar la tarifa incluye las siguientes actividades:
-
122
Decidir el objetivo de precio.

Determinar costes directos e indirectos.
Determinar las tarifas de mercado.
Analizar la demanda de los servicios.
Analizar el nmero de clientes y la competencia.

Para determinar la tarifa de servicio, la organizacin primero debe determinar el objetivo y los beneficios previstos para
los clientes y el personal TI.
El precio es una de las cuatro Ps en marketing: Producto, Precio, Promocin y Plaza. El precio no es solo relevante en
trminos de recuperacin de coste incurrido, ya que tambin afecta la demanda del producto. Una estrategia de precio
flexible se puede utilizar para promover productos o para sacarlos del mercado. Un servicio nuevo con pocos usuarios
puede estar subsidiado por la ganancia de otro servicio. Antes de seleccionar la estrategia de precio se deben identificar
con claridad los costes del servicio.
Hay una amplia gama de polticas de precio como:
-
Coste Adicional - existen en muchas formas, y todas ellas se basan en el cobro de los costes en los que se incurri
ms un margen de ganancia (coste + % sobreprecio). Los costes y el margen de ganancia pueden definirse de muchas
maneras, como:

Costes totales incluyendo un margen de ganancia.

Costes marginales ms un margen (suficiente para cubrir los costes fijos promedio, costes por dem, y ganancia
sobre capital). Por ejemplo, si la disponibilidad LAN/WAN se incluye en los cargos por conexin de red, este
elemento no necesita ser incluido en otros servicios LAN.
Uno de los mtodos anteriores, con margen de 0%.
Tasa corriente - para servidos donde ya se acord el precio.
Meta de rendimiento - servicios que tienen un precio determinado por adelantado.
Tarifa del Mercado - los precios se emparejan con lo que cobran los proveedores externos.
Precio Negociado por Contrato - estos precios se discuten con el cliente. Si el cliente solicita un servicio nuevo, se
negocia si debe hacer cargo de todos los costes de inversin, o solo de una parte.
Se pueden otorgar descuentos por volmenes servicio, disminuyendo el precio s aumenta el volumen.
Para distribuir la demanda en los sistemas, se pueden utilizar tarifas para horarios pico y no pico.
11.4.4 Informe
El uso real de los servicios TI se factura o se comunica al cliente. Los costes se tratan en las reuniones regulares con el
cliente bajo el proceso de la Gestin de Niveles de Servicio. As, la Gestin de Niveles de Servicio obtiene la siguiente
informacin:
Gasto de servicio TI por cliente.
Diferencia entre los cargos reales y los estimados.
Mtodos de Precio y Mtodos Contables utilizados.
Cualquier conflicto por los cargos con las causas y soluciones.

La contabilidad forma parte de la estructura completa de la Gestin de Servicios TI y debe estar a cargo de un Gestor
Financiero. Este Gestor es responsable de la implementacin y administracin diaria de la contabilidad y el sistema de
cobro y de informar a la administracin TI. El Gestor de Finanzas no necesita ser parte de la organizacin TI.
Los informes, los factores de xito clave y los indicadores de rendimiento pueden usarse para optimizar la Gestin
Financiera.
11.5.1 Informes de Gestin

El proceso de la Gestin Financiera debe suministrar informes a menudo a la gestin TI sobre temas tales como:
-
Costes totales y beneficios de los servicios TI

Anlisis de costes para cada departamento TI, plataforma, u otra unidad relevante
Costes asociados al sistema de Gestin Financiera
Planeamiento de inversiones futuras
Oportunidad para reducir el coste
123
11.5.2 Factores de xito crticos e indicadores de rendimiento

Antes de utilizar la Gestin Financiera, los usuarios, el personal y la gestin TI deben recibir informacin del objetivo de
tal uso y de los costes, y problemas potenciales asociados con tal uso.
Los factores de xito crticos para usar un sistema de cobro eficaz incluyen:
-
Los usuarios deben saber por cules servicios se les cobra.

Los usuarios deben conocer los mtodos de cobro para que puedan as controlar sus costes (por ejemplo, a travs de
acuerdos o informes en trminos de unidades de rendimiento cuantificables).
El coste de comprobacin del sistema debe dar detalles y justificar el gasto.
La Gestin de Servicios TI debe dar sistemas equilibrados que ofrezcan servicios TI eficaces a un precio razonable.
La gestin TI debe ser consciente del impacto y los costes del uso de la Gestin Financiera y debe comprometerse
por completo a ello.
La Gestin de Configuraciones debe proporcionar informacin relevante sobre la estructura de los servicios para
establecer un sistema contable apropiado.
Los siguientes indicadores de rendimiento pueden ayudar a controlar el proceso:

-
Correcto anlisis de coste beneficio de los servicios prestados

Los clientes consideran justos los mtodos de cobro
La organizacin TI cumple con sus objetivos financieros
El cliente cambia el uso de los servicios
Informes oportunos a la Gestin de Niveles de Servicio

Algunas organizaciones TI cuentan con su propio Gestor de Finanzas, mientras que otras tienen acuerdos con
departamentos de finanzas que cooperan de cerca con la Gestin TI. Como en los otros procesos la Gestin Financiera
debe tener un propietario responsable del proceso y el departamento de finanzas debe establecer las pautas para elaborar
presupuestos, contabilidad y sistema de cobro.

11.6.1 Problemas
-
Las actividades necesarias para registrar y monitorizar los costes resultan una nueva disciplina para el personal T I, y
hay poca bibliografa al respecto.
Para monitorizar y calcular, y cobrar los costes a menudo se necesita informacin sobre la planificacin de servicios
no TI, por ejemplo edificios. Resulta casi imposible obtener detalles de planificacin.
Es difcil encontrar personal que est familiarizado con TI y la contabilidad.
Si la estrategia corporativa y los objetivos para el desarrollo de los Sistemas de Informacin no se han formulado y
documentado con claridad se vuelve difcil considerar las inversiones necesarias.
Si no se entienden las oportunidades que proporciona el proceso, la gente ser reticente a colaborar y/o cooperar.
La falta de compromiso puede significar que la organizacin no toma en serio el proceso.
Costes administrativos y de organizacin asociados con la planificacin, introduccin y puesta en marcha del
proceso.
Costes de las herramientas necesarias, como por ejemplo una aplicacin con hardware y base de datos.
11.6.2 Costes
Los costes de este proceso se pueden dividir en dos categoras:
-
124
Costes administrativos y de organizacin asociados con la planificacin, introduccin y puesta en marcha del
proceso.
Costes de las herramientas necesarias, como por ejemplo una aplicacin con hardware y base de datos.
Captulo 12:
12.1 Introduccin
La Gestin de la Capacidad se encarga de proporcionar la capacidad necesaria para procesar y guardar los datos, en el
momento justo y de manera eficiente en trminos de costes. Es un acto de equilibrio. Una buena Gestin de la Capacidad
elimina la compra en pnico o de ultimo minuto, o la compra de la caja ms grande y... a cruzar los dedos.
Ambas situaciones son costosas. Muchos centros de datos, por ejemplo, se manejan perpetuamente a un 30% o 40% o ms
de capacidad sin uso. Esto no es tan malo cuando se tienen algunos servidores. Pero cuando se tienen cientos de servidores
como tienen muchas empresas, estos porcentuales significan la prdida de grandes sumas de dinero.
La Gestin de la Capacidad se encarga de los siguientes temas:
-
Se puede justificar el coste de compra de capacidad de procesamiento a la luz de los requisitos del negocio, y si la
capacidad de procesamiento se usa de manera eficaz (coste versus capacidad)?
La capacidad de procesamiento actual cumple correctamente con las demandas actuales y de futuro del cliente
(oferta versus demanda)?
La capacidad de procesamiento disponible est rindiendo al completo (puesta a punto de la performance)?
Precisa con exactitud el momento en el que se debe adquirir capacidad adicional?
Pata implementar sus objetivos, la Gestin de la Capacidad debe contar con una estrecha relacin con el negocio y la
estrategia de procesos TI. De esta manera, este proceso es reactivo (mide y mejora) y preactivo (analiza y prev).

Conceptos importantes que incluye la Gestin de la Capacidad:
-
Gestin de Rendimiento - mide, monitoriza y pone a punto los componentes de rendimiento de la infraestructura TI.
Aplicacin del Alcance - determina la capacidad de hardware o de red para dar soporte a aplicaciones nuevas o
modificadas y la carga de trabajo prevista.
Modelado - utiliza modelos analticos o de simulacin para determinar los requisitos de capacidad de las
aplicaciones determinando las mejores soluciones de capacidad. El modelado permite analizar varios escenarios y
formular preguntas como "Qu pasa si...?"
Planificacin de capacidad - desarrolla un Plan de Capacidad, analiza la situacin actual (preferentemente usando
escenarios) y predice el uso futuro de la infraestructura y los recursos TI necesarios para satisfacer la demanda
esperada de los servicios TI.
12.2 Objetivos
La Gestin de la Capacidad tiende a proveer de manera consistente los recursos TI necesarios en el momento justo
(cuando se los necesita) y a un precio justo, alineados con los requisitos actuales y futuros del cliente.
As, la Gestin de la Capacidad necesita entender adems de los desarrollos del negocio que afectan al cliente, los
desarrollos tcnicos. Los procesos de la Gestin de la Capacidad cumplen un rol importante en la determinacin de las
ganancias por inversin y en la justificacin del coste.
Ventajas
Las ventajas de la Gestin de la Capacidad son:
-
Reduce riesgos asociados a los servicios existentes gracias a un manejo eficaz de los recursos y a la monitorizacin
continua del rendimiento de los equipos.
Reduce riesgos asociados a los servicios nuevos, ya que la Aplicacin de Alcance implica el conocimiento de
impacto de los sistemas existentes. Lo mismo se aplica con respecto a los servicios modificados.
Reduce costes porque las inversiones se realizan en el momento que corresponden, ni demasiado temprano ni
demasiado tarde que significa que el procedimiento de compras no tiene que hacer compras de ltimo minuto o
comprar capacidad de sobra con ms anterioridad de lo necesario.
125
Gestin de Capacidad
-
Reduce las interrupciones del negocio gracias a la estrecha colaboracin con la Gestin de Cambios cuando se
determina el impacto en la capacidad y cuando se proveen los cambios urgentes que resultan de la incorrecta
estimacin de capacidad.
Cuanto ms se utiliza la Gestin de la Capacidad se podrn hacer previsiones ms fiables, lo que significa que los
pedidos del cliente se pueden responder con mayor rapidez.
Mayor eficacia porque la demanda y la oferta se equilibran en una fase ms temprana.
Los gastos relacionados con la capacidad pueden ser controlados y hasta reducidos gracias al mejor uso de la
capacidad.
Estas ventajas mejoran la relacin con el cliente. La Gestin de la Capacidad se prepara con el cliente en etapas tempranas
y facilita la anticipacin de los pedidos. Tambin mejorarn las relaciones con los abastecedores. En definitiva, los
acuerdos de compra, entrega, instalacin y mantenimiento se pueden planear mejor.
12.3 El Proceso
Como muchos procesos ITIL la Gestin de la Capacidad se remonta a los tiempos de los ordenadores mainframe.
Desgraciadamente, esto significa que muchas personas piensan que la Gestin de la Capacidad slo es relevante en los
entornos mainframe. Esto se ve reforzado por la gran reduccin en los costes de hardware de los ltimos aos. El
resultado ha sido la compra de hardware en grandes cantidades sin considerar o sin tener en cuenta la Gestin de la
Capacidad. El peligro aqu es que la fuente ms grande de costes, riesgos, y posibles problemas en TI no se encuentran en
el hardware en si. En otras palabras, la proliferacin innecesaria de hardware crea un problema de administracin que es
mucho ms caro que el propio hardware.
Implementar la Gestin de la Capacidad ayudar a prevenir inversiones innecesarias y cambios de capacidad ad-hoc, ya
que este ltimo aspecto en particular puede tener un impacto negativo en la provisin de servicios. En la actualidad el
coste de TI no se relaciona tanto con las inversiones, o la capacidad, sino con su gestin.
Por ejemplo, un aumento excesivo en la capacidad de almacenamiento impactar en las operaciones de backup en cinta y
llevar ms tiempo encontrar los archivos guardados en la red.
Este ejemplo ilustra un aspecto importante de la Gestin de la Capacidad: una buena Gestin de la Capacidad es tal vez el
ingrediente ms importante para cambiar la percepcin (y la realidad) de una organizacin TI como un gasto fijo a al de
un proveedor de servicios.
Con una buena Gestin de la Capacidad, el proveedor de servicio TI ver, por ejemplo, que las dieciocho iniciativas
estratgicas que se impusieron para TI este ao dejar a los procesos de backup actuales obsoletos.
Teniendo esto en mente, el Gestor de Capacidad puede garantizar que se vea el coste verdadero de estas iniciativas -es
decir, que el coste de la nueva solucin de backup sea prorrateada entre las dieciocho iniciativas.
Esto es proactivo. Si, en cambio, no hay Gestin de la Capacidad, la organizacin TI reacciona slo cuando la ventana de
backup se encuentra excedida. En este caso, el cliente ve a la organizacin TI como un gasto general, que viene
"mendigando dinero", simplemente porque no me proactivo al establecer las expectativas y asignar los costes por
adelantado.
La Gestin de la Capacidad tiene como objetivo prevenir las sorpresas y las compras a las apuradas haciendo un mejor uso
de los recursos disponibles, e incrementando la capacidad en el momento justo, o controlando el uso de los recursos. La
Gestin de la Capacidad tambin puede ayudar a coordinar las capacidades de los diferentes aspectos de un servido para
garantizar que las inversiones costosas en ciertos componentes se utilicen eficazmente.
Las infraestructuras TI de hoy en da son muy complejas. Esto aumenta las dependencias de capacidad entre los
componentes. Por esa razn es cada vez ms difcil cumplir con los niveles de servicio acordados con el cliente. Una
organizacin TI profesional debe por lo tanto tomar un planteo integral para la Gestin de la Capacidad.
La Figura 12.1 muestra las actividades principales de la Gestin de la Capacidad.
126
Figura 12.1 Gestin de la Capacidad (fuente OGC)
La Gestin de la Capacidad tiene tres sub-procesos o niveles de anlisis en los que se puede considerar la capacidad:
-
Gestin de la Capacidad del Negocio ~ el objetivo de este sub-proceso es comprender las necesidades futuras del
usuario. Esto se puede hacer obteniendo informacin del cliente, por ejemplo de planes estratgicos o llevando a
cabo anlisis de tendencias.
Gestin de la Capacidad del Servicio - el objetivo de este sub-proceso es determinar y comprender el uso de los
servicios TI (productos y servicios que se dan a los clientes). Se debe comprender el rendimiento y las cargas pico
para garantizar la realizacin y el cumplimiento de los acuerdos de servicio correctos. Este sub-proceso es
principalmente preactivo, y tiene fuertes vinculaciones con la Gestin de Niveles de Servicios para lo relacionado
con la definicin y negociacin de Acuerdos de Servicio.
Gestin de la Capacidad de Recursos - el objetivo de este sub-proceso es determinar y comprender el uso de la
infraestructura TI. Ejemplos de recursos son el ancho de banda de la red, la capacidad de procesamiento, y la
capacidad de disco. Los problemas potenciales se deben detectar de antemano para manejar estos recursos
eficazmente. Tambin se debe estar a la delantera con los desarrollos tcnicos. Una activa monitorizacin de
tendencias es una Importante actividad dentro de este sub-proceso.
Cuando la Gestin de la Capacidad y las necesidades del negocio se relacionan, la Gestin de la Capacidad es un elemento
esencial del proceso de planificacin. Sin embargo, el soporte que proporcionan los procesos de operacin no debe ser
subestimado. Ms abajo se mencionan los vnculos con los procesos de la Gestin de Servicios.
Relacin con la Gestin de Incidentes
Gestin de Incidentes informa a la Gestin de la Capacidad de los incidentes relacionados con los problemas de
capacidad. La Gestin de la Capacidad puede dar informacin a la Gestin de Incidentes para diagnosticar o solucionar
los problemas de capacidad.
127
Gestin de Capacidad
Relacin con la Gestin de Problemas

La Gestin de la Capacidad ayuda a la Gestin de Problemas en sus roles reactivos y preactivos. Las herramientas, la
informacin, el conocimiento y la experiencia de la Gestin de la Capacidad se pueden utilizar para ayudar a la Gestin de
Problemas en distintas etapas.
Relacin con la Gestin de Cambios
La Gestin de la Capacidad puede ser parte del CAB. La Gestin de la Capacidad puede dar informacin sobre la
necesidad de capacidad y el impacto potencial de un cambio al proveer el servicio. La informacin sobre los cambios es
una entrada en el Plan de Capacidad. La Gestin de la Capacidad puede elevar RFCs durante la elaboracin del plan.
Relacin con la Gestin de Versiones
La Gestin de la Capacidad apoya a la planificacin de la distribucin cuando la red se utiliza para la distribucin
automtica o manual.
Existe una fuerte conexin entre la Base de Datos de Capacidad (CDB) y la CMDB. La informacin que proporciona la
Gestin de la Configuracin es esencial para desarrollar una CDB eficaz.
Relacin con la Gestin de Niveles de Servicio
La Gestin de la Capacidad aconseja a la Gestin de Niveles de Servicio sobre la factibilidad de los niveles de servicio
(por ejemplo tiempo y ciclo de respuesta). La Gestin de la Capacidad monitoriza los niveles de rendimiento y
proporciona informacin para evaluar y si es necesario cambiar los niveles de servicio acordados y los informes
asociados.
Relacin con la Gestin Financiera de los Servicios TI
La Gestin de la Capacidad ayuda en la elaboracin del presupuesto de inversin, anlisis coste/beneficio, y en las
decisiones de inversin. La Gestin de la Capacidad tambin da informacin muy importante para cobrar servicios
relacionados con la capacidad, como la asignacin de capacidad de la red.
Relacin con la Gestin de Continuidad de Servicios TI
La Gestin de la Capacidad especifica la capacidad mnima necesaria para continuar con el servicio en el caso de desastre.
Se deben revisar constantemente las necesidades de capacidad de la Gestin de Continuidad de Servicios TI para
garantizar que reflejen los cambios diarios del entorno de operacin.
Relacin con la Gestin de la Disponibilidad
La Gestin de la Capacidad y de la Gestin de Disponibilidad estn muy conectadas. El rendimiento y los problemas de
capacidad pueden ser causa de prdidas de servicios TI. De hecho, el cliente puede considerar que un rendimiento pobre
es equivalente a la falta de disponibilidad. Por la gran interdependencia que existe entre ambos procesos, se los debe
coordinar de manera eficaz. Los dos procesos usan las mismas herramientas y tcnicas, como Anlisis de Impacto de
Componentes de Fallo (CFIA) y Anlisis del rbol de Fallos (FTA).
12.4 Actividades
Las siguientes actividades de Gestin de Capacidad vienen descritas abajo y en menor o mayor medida son realizadas para
cada uno de los subprocesos de Gestin de la Capacidad del Negocio, los Servicios y los Recursos. Algunas actividades
ncleo dentro de esta rea vienen ilustradas en la Figura 12.2.
Figura 12.2 Actividades iterativas en Gestin de la Capacidad
128
12.4.1 Desarrollo del Plan de Capacidad

El Plan de Capacidad describe la capacidad actual de la infraestructura TI y los cambios que se esperan en la demanda de
los servicios TI, la sustitucin de los componentes antiguos y los desarrollos tcnicos. El Plan de Capacidad tambin
define los cambios necesarios para proporcionar los niveles de servicios acordados en los SLAs y aun coste aceptable. El
Plan de Capacidad describe por lo tanto no solo los cambios esperados sino tambin los costes asociados. Se debe disear
un plan todos los aos, y debe examinarse cada trimestre para confirmar su validez. En cierta manera, el Plan de
Capacidad es la produccin ms importante de la Gestin de la Capacidad.
Las producciones a menudo incluyen un plan anual que se sincroniza con el presupuesto o el plan de inversin, un plan a
largo plazo y planes trimestrales con detalles de los cambios de capacidad programados. Con esto se consigue un conjunto
de planes coherentes, donde el nivel de detalle aumenta al acercarse al horizonte proyectado.
12.4.2 Modelado
El Modelo es una herramienta poderosa de la Gestin de la Capacidad y se utiliza para prever el comportamiento de la
infraestructura. Las herramientas disponibles para la Gestin de la Capacidad van desde la estimacin hasta la prueba
extensiva de prototipos. La primera es barata y solo es til para las actividades de rutina. La ltima solo da resultado para
los proyectos de implementacin a gran escala.
Entre estos dos extremos, existen cierta cantidad de tcnicas que son ms veraces que la estimacin, y ms baratos que un
piloto extenso. En orden decreciente de coste son:
-
Anlisis de tendencias (ms barata)

Modelo analtico
Simulacin
Evaluacin con lnea de referencia (benchmark) (el ms exacto)
Los Anlisis de tendencia pueden utilizarse para obtener informacin de carga, pero no se pueden utilizar para predecir los
tiempos de respuesta. EL modelo analtico y la simulacin tienen sus ventajas y desventajas. Por ejemplo, la simulacin se
puede utilizar para predecir con exactitud el rendimiento de un host, posiblemente como elemento de dimensionamiento
de una aplicacin.
Sin embargo, es un mtodo que consume mucho tiempo. Los modelos matemticos analticos por lo general llevan menos
tiempo, pero el resultado no es tan fiable. El de lnea de referencia significa la creacin de un entorno operativo real, por
ejemplo en el centro de proceso de datos del abastecedor. Este entorno cumple con los requisitos de rendimiento y se
utiliza para simulaciones "qu pasa si...?" o de cambio, como "qu pasa cuando un componente de aplicacin se
transfiere a otro sistema?" o "qu pasa si duplicamos el nmero de transacciones?".
12.4.3 Dimensionamiento de la Aplicacin

El Dimensionamiento de la Aplicacin (Sizing) considera el hardware necesario hacer funcionar aplicaciones nuevas o
que fueron cambiadas, como aplicaciones en desarrollo o que estn en mantenimiento o que se puedan comprar a pedido
del cliente. Estas predicciones incluyen informacin sobre los niveles de rendimiento esperados, el hardware necesario y
los costes.
Esta disciplina es en particular relevante durante las etapas iniciales de desarrollo del producto. La informacin clara sobre
el hardware y los otros recursos TI necesarios y los costes esperados durante esta etapa son de mucho valor para la
administracin. Esta disciplina tambin contribuye al diseo de un nuevo SLA.
El Dimensionamiento de la Aplicacin puede necesitar de un gran esfuerzo en entornos grandes o complejos. En primer
lugar, la Gestin de la Capacidad acuerda con los desarrolladores los Requisitos de Nivel de Servicio que deber cumplir
el producto. Una vez que el producto alcanz la etapa de transmisin y aceptacin, se verifica si se puede cumplir con los
Niveles de Servicio acordados en trminos de CPU, I/O, red, disco y utilizacin de memoria.
Uno de los resultados del Dimensionamiento de la Aplicacin son las caractersticas de carga de trabajo. Estas se pueden
utilizar para predecir la capacidad necesaria, si por ejemplo el nmero de usuarios creciera 25%. Otras caractersticas de
carga de trabajo son los requisitos de capacidad en el tiempo (picos por da, semana, ao y crecimiento futuro).
12.4.4 Monitorizacin
La monitorizacin de los componentes de la infraestructura tiene como objetivo garantizar que se alcancen los niveles de
servicio acordados. Ejemplos de los recursos a monitorizar son: utilizacin de CPU, utilizacin de disco, de red, nmero
de licencias, etc. (es decir, solo hay 10 licencias libres disponibles).
129
Gestin de Capacidad
12.4.5 Anlisis
Se deben analizar los datos monitorizados. Los anlisis de tendencias se pueden utilizar para predecir la utilizacin futura.
Esto puede dar lugar a mejoras en la eficiencia o la adquisicin de componentes TI adicionales. Los anlisis de actividades
requieren una comprensin global de toda la infraestructura y el proceso del negocio.
12.4.6 Puesta a punto

En base a los datos de monitorizacin que se analizaron e interpretaron, la Puesta a Punto optimiza los sistemas para la
carga de trabajo esperada.
12.4.7 Implementacin
El objetivo de la implementacin es introducir la capacidad nueva o cambiada. Si esto significa un cambio, la
implementacin involucra el proceso de la Gestin de Cambios.
12.4.8 Gestin de la Demanda

La Gestin de la Demanda tiene como objetivo influenciar en la demanda de capacidad. Un ejemplo simple: un usuario
est utilizando un informe SQL mal escrito a mitad del da, sacando a otros usuarios de la base de datos y creando una
excesiva cantidad de trfico. El Gestor de Capacidad sugiere crear un trabajo para que "corra" a la noche para que el
usuario lo tenga en su escritorio a la maana.
Distinguimos entre gestin de la demanda a corto plazo y a largo plazo:
-
Gestin de la demanda a corto plazo - donde una falta de capacidad recurrente puede ser una amenaza en un futuro
cercano, y donde no es fcil disponer de capacidad adicional.
Gestin de la demanda a largo plazo - donde el coste de los upgrades no se puede justificar, aunque hay ciertos
momentos (ejemplo, entre las 10 AM y la tarde} en los que la capacidad puede resultar insuficiente.
La Gestin de la Demanda proporciona inputs importantes para el diseo, monitorizacin y ajuste tanto del Plan de
capacidad como de los Acuerdos de Nivel de Servicio.
La Gestin de la Demanda tambin puede proponer precios diferenciales (es decir, precios distintos a horas pico o no
pico) para influenciar en el comportamiento del cliente.
12.4.9 Poblando la Base de Datos de Capacidad (CDB)

Crear y poblar la CDB significa unir y actualizar la informacin tcnica, la informacin del negocio, y roda la otra
informacin que afecte a la Gestin de la Capacidad. Puede resultar imposible almacenar coda la informacin de
capacidad en una sola base de datos fsica. Los gestores de red y de computacin pueden utilizar sus propios
planteamientos. Por lo general, la CDB hace referencia a la coleccin de fuentes con informacin de capacidad.
Figura 12.3 Fuentes de Informacin CDB
130

La Gestin de la Capacidad es ms eficaz si mantiene vnculos estrechos con los otros procesos de planificacin, como
Gestin de la Disponibilidad y las actividades de Desarrollo de Aplicaciones. Esto alentar a que la Gestin de la
Capacidad tenga un planteamiento preactivo.

Los informes de gestin que da el proceso de la Gestin de la Capacidad incluyen por un lado, informacin de control del
proceso en trminos de caractersticas de Plan de Capacidad, recursos utilizados para implementar el progreso de las
actividades de mejora, y, por otro lado, los informes de excepcin sobre temas tales como:
-
Discrepancias entre la utilizacin de capacidad real y planeada.

Tendencias en las discrepancias.
Impacto en los niveles de servicio.
Incremento/disminucin de la utilizacin de capacidad esperada a corto y largo plazo.
Marcas que, cuando se alcancen, necesitarn de capacidad adicional.

La Gestin de la Capacidad depende de los siguientes factores de xito crticos:
-
Expectativas y previsiones del negocio correctas.

Comprensin de la estrategia y planificacin TI y su veracidad.
Apreciacin de los desarrollos tcnicos.
Cooperacin con los otros procesos.
El xito de la Gestin de la Capacidad depende de los siguientes indicadores de rendimiento claves:

Prediccin de la demanda del cliente - identificacin de los desarrollos de carga de trabajo y tendencias en el
tiempo, y la veracidad del Plan de Capacidad.
Tecnologa - opciones para medir el rendimiento de todos los servicios TI, el paso para implementar la nueva
tecnologa y la habilidad para lograr de forma contina los acuerdos establecidos en el SLA, an cuando se utiliza
tecnologa vieja.
Coste - reduccin en el nmero de compras de ltimo minuto, reduccin de sobrecapacidad innecesaria o cara, y
diseo de planes de inversin en etapas tempranas.
Operaciones - reduccin del nmero de incidentes debido a problemas de rendimiento, la habilidad para satisfacer la
demanda del cliente en todo momento, y el grado hasta el que se toma en serio a la Gestin de la Capacidad.

El rol del Gestor de Capacidad es gestionar el proceso y asegurar que el Plan de Capacidad es desarrollado y mantenido,
as como que la Base de Datos de Capacidad est al da.
Los Gestores de Red, de Sistemas y de Aplicaciones tienen un rol importante en la Gestin de la Capacidad. No solamente
son responsables de optimizar el performance, sino que se espera que usen su experiencia en trasladar las demandas del
negocio a cada uno de los sistemas que gestionan, y de ah a determinar la capacidad requerida.
131
Gestin de Capacidad
12.6 Problemas y Costes

12.6.1 Problemas
Los problemas potenciales en la Gestin de la Capacidad incluyen:
Expectativas no realistas - los desarrolladores, la administracin y los clientes a menudo tienen expectativas poco
realistas por su desconocimiento de las posibilidades tcnicas de las aplicaciones, los sistemas o las redes. Una de las
tareas de la Gestin de la Capacidad es orientar estas expectativas, por ejemplo, haciendo que los desarrolladores se
den cuenta del impacto de su diseo (por ejemplo para una base datos) en la capacidad y rendimiento. El efecto de la
Gestin de la Capacidad tambin se puede sobreestimar, en particular en lo que respecta a la puesta a punto del
sistema y programacin de la carga de trabajo. Si la operacin de los sistemas necesita de una excesiva puesta a
punto, es probable que se deba a un pobre diseo de aplicacin o una mala base de datos. Por lo general, la puesta a
punto no puede utilizarse para obtener un mayor nivel de rendimiento del que fue originalmente diseado el sistema.
La mayora de los sistemas grandes tienen algoritmos de programacin que a menudo son ms eficaces que la
intervencin de los administradores de sistemas. Y por supuesto, hay un coste asociado a la puesta a punto (no tiene
sentido que un ingeniero con un salario alto acumule solo el 3% de mejora de rendimiento tras semanas de esfuerzo
cuando con $100 de stick de memoria producira una mejora del 10%}. Hay un coste ms alto por depositar
demasiada confianza en la puesta a punto que en sistemas de administracin que no son, con razn, ordinarios. Los
parmetros "altamente retorcidos" en distintos productos, aplicaciones, o bases de datos provocan consecuencias no
intencionadas y agregan demoras a todos los procesos de gestin de servicios, mantenimiento, resolucin de
problemas, etc.
Falta de informacin correcta - a menudo es difcil conseguir la informacin necesaria, por ejemplo para el Plan de
Capacidad. Puede ser difcil obtener informacin fiable sobre la carga de trabajo esperada, porque se desconocen o
no hay mucha informacin sobre los planes del cliente, al menos no en detalle. Esto tambin resulta difcil para el
cliente, ya que el ciclo de vida de los productos es cada vez ms corto. La nica solucin es hacer la mejor
estimacin posible y actualizarla con frecuencia cuando se dispone de mayor informacin.
Inputs del abastecedor - si no existen datos histricos (por ejemplo, cuando se compra un sistema nuevo) la Gestin
de la Capacidad depende de la informacin que proporcionan los abastecedores. Los abastecedores generalmente
utilizan "benchmarks" para dar informacin de sus sistemas, pero dadas las grandes diferencias entre los mtodos de
prueba es a menudo muy difcil comparar la informacin y puede no reflejar el rendimiento real del sistema.
Implementacin en ambientes complejos - la implementacin en ambientes complejos distribuidos es difcil
porque la magnitud de las interfaces tcnicas crean gran cantidad de dependencias de rendimiento.
Determinacin del nivel de monitorizacin correcto - las herramientas de monitorizacin por lo general
proporcionan muchas opciones y pueden alentar a investigaciones demasiados detalladas. Cuando se compra y se
utilizan estas herramientas se debe decidir de antemano a qu nivel de monitorizacin se deben implementar.
Estos problemas son pertinentes a la Gestin de la Capacidad de los sistemas informticos y a las redes o a los grandes
sistemas de impresin y sistemas PABX. Esto puede resultar todava ms desafiante si hay muchos departamentos
responsables de estos dominios que pueden acarrear conflictos sobre las responsabilidades de la Gestin de la Capacidad.
12.6.2 Costes
Durante la preparacin se deben estimar los costes para establecer la Gestin de la Capacidad. Estos costes se pueden
dividir en:
-
132
Compra de herramientas de hardware y software tales como herramientas de monitorizacin, Base de Datos de
Capacidad (CDB), herramientas de modelado para simulaciones y anlisis de estadstica, y herramientas de
elaboracin de informes.
Costes de administracin de proyectos asociados con la gestin de los procesos.
Personal, capacitacin y costes de soporte.
Instalaciones y servicios.
Una vez que se estableci el proceso, hay costes de personal, contratos de mantenimiento, etc. que se repiten.
Captulo 13:
13.1 Introduccin
Muchos gestores consideran la Gestin de Continuidad de Servicios TI (ITSCM) como un lujo, para el cual no necesitan
ningn recurso. Sin embargo las estadsticas muestran que los desastres destructivos son bastantes comunes.
Desastre - un evento que afecta un servicio o sistema y para el que es necesario un gran esfuerzo para restaurar el nivel
de rendimiento original.
De esta manera, un desastre es mucho ms serio que un incidente. Un desastre no es una interrupcin del negocio. Esto
significa que todo o parte del negocio no "est comerciando" tras el desastre. Desastres familiares incluyen fuego,
relmpagos, dao por agua, robo, vandalismo y violencia, interrupcin de la energa en gran escala y fallo de hardware.
Los ataques terroristas, como el del Centro Mundial de Comercio en Nueva York, se vuelven ms comunes. Internet
tambin puede provocar desastres, como ataques de denegacin de servicio (DoS) que destruyen las comunicaciones de
toda una organizacin.
Algunas empresas podran haber prevenido serios problemas pensando y desarrollando Planes de Continuidad Del
Negocio. As mismo los negocios dependen cada vez ms de los servicios TI lo que significa que el impacto de la prdida
de los servicios tambin aumenta y se torna menos aceptable. De hecho, para muchas empresas hacer negocios equivale a
utilizar TI, y sin TI no pueden generar ganancia. Por lo tanto resulta imprescindible considerar de qu manera se puede
salvaguardar la continuidad del negocio.
Desde la publicacin del modulo de Planificacin de Contingencia de la CCTA ha habido muchos cambios en TI, y en la
forma en que las organizaciones la utilizan. Una planificacin de Contingencia tradicional sola ser parte del mandato de
la organizacin de TI. Sin embargo hoy en da TI se encuentra mucho ms integrado con los distintos aspectos del
negocio. Donde la Planificacin de Contingencia tradicional era primariamente reactivo (que hacer ante un desastre), el
nuevo proceso de la Gestin de Continuidad de Servicios TI pone nfasis en la prevencin, es decir evitar el desastre.
13.2 Objetivos
El objetivo de la Gestin de Continuidad de Servicios TI es ayudar a toda la Gestin de la Continuidad del Negocio
(BCM) garantizando que la infraestructura TI y los servicios TI necesarios, incluyendo Soportes y Centro de Servicios,
pueden restaurarse dentro de los lmites especificados tras un desastre. ITSCM puede tener un cierto nmero de objetivos
distintos.
Dado que ITSCM es parte integral de CBM, el alcance de ITSCM debe definirse en bases a los objetivos del negocio.
Cuando se evalan los riesgos se puede decidir si estn dentro o fuera de los procesos ITSCM.
Beneficios
En tanto los negocios se vuelven cada vez ms dependientes de los servicios TI, el coste de no planear y los beneficios de
planear slo se pueden identificar a travs de un anlisis de riesgo. Una vez que el riesgo del negocio, no tanto de los
servicios TI, ha sido identificado se pueden realizar inversiones en medidas preventivas y en medidas para ocuparse de los
desastres, tales como planes de recuperacin.
Las pautas de este captulo se pueden utilizar para limitar y manejar el impacto de los desastres.
En caso de desastres, los negocios con un proceso ITSCM tienen las siguientes ventajas:
-
Pueden manejar la recuperacin de sus sistemas.

Pierden menos tiempo y ofrecen mejor continuidad para los usuarios.
Minimizan la interrupcin de sus actividades del negocio.
133
13.3 El Proceso
La Gestin de Continuidad de Servicios TI es responsable de:
-
Evaluar el impacto de la interrupcin de los servicios TI tras un desastre.

Identificar los servicios crticos para el negocio que requieren de medidas y de prevenciones adicionales.
Definir los periodos dentro de los cuales se deben restaurar los servicios.
Tomar medidas para prevenir, detectar, preparar y mitigar los efectos de los desastres o para reducir su impacto.
Definir el plan a utilizar para restaurar los servicios.
Desarrollar, evaluar y mantener un plan de recuperacin con detalles suficientes para sobrevivir al desastre y
restaurar los servicios a la normalidad tras un periodo definido.
Dado que las operaciones del negocio en su totalidad e TI se entremezclan cada vez ms, se describen ambas reas dentro
del alcance ITIL:
-
Gestin de Continuidad del Negocio (BCM) cubre el anlisis de riesgo y la administracin para que la
organizacin pueda garantizar la capacidad de produccin mnima necesaria o la provisin de servicio en todo
momento. La BCM tiene como objetivo reducir los riesgos a un nivel aceptable y desarrollar planes para restaurar las
actividades del negocio si se interrumpen por un desastre.
Gestin de Continuidad de Servicios TI (ITSCM) es el proceso de manejar los desastres que afectan a los servicios
TI y de mantener los servicios para permitir que el negocio siga operando.
La Gestin de Continuidad de Servicios TI es parte de toda la Gestin de Continuidad del Negocio y depende de la
informacin que reciben del proceso BCM.
La disponibilidad de los servicios TI se garantiza al combinar las medidas de reduccin de riesgo (p. Ej. Instalando
sistemas fiables) y al proporcionar opciones de recuperacin (P. Ej. Sistema de back up y sistemas redundantes).
Una exitosa implementacin requiere la ayuda de toda la organizacin, el compromiso de la gestin y la cooperacin de
todo el personal.
La Gestin de Continuidad de Servicios TI interacta con todos los otros procesos de Gestin de Servicios TI y en
particular con los siguientes:
-
134
Gestin de Niveles de Servicio proporciona informacin sobre las obligaciones del servicio TI.
Gestin de la Disponibilidad ayuda a ITSCM desarrollando e implementando medidas de prevencin.
Gestin de Configuraciones define las configuraciones bsicas y la infraestructura TI para dar informacin a
ITSCM sobre la infraestructura a restaurar en caso de desastre.
Gestin de la Capacidad garantiza que los requisitos del negocio cuenten con el soporte de los recursos TI que
corresponda.
Gestin de Cambios garantiza que todos los planes ITSCM sean correctos y estn actualizados haciendo parte a
ITSCM de todos los cambios que puedan afectar las medidas preventivas y los planes de recuperacin.
13.4 Actividades
La figura 13.1 muestra las actividades 1TSCM. Los nmeros refieren a las sub-secciones de la seccin 13.4 en la que se
describen las actividades.
Figura 13.1 Modelo de proceso ITSCM (basado en el modelo OGC)
13.4.1 Definicin del alcance de ITSCM

Cuando se inicia ITSCM se debe considerar a la organizacin como un todo, debindose llevar a cabo las siguientes
actividades:
-
Definicin de la poltica - se debe definir lo antes posible la poltica y se debe comunicar a toda la organizacin para
que todos los involucrados sean conscientes de la necesidad de ITSCM. La gestin debe mostrar su compromiso.
Definicin del alcance y las reas relevantes - requisitos de seguridad, estndares de calidad como la serie
ISO9000, estndares de Gestin de la Seguridad como BS7799, y principios de poltica del negocio generales que se
usan para seleccionar el plan y los mtodos de evaluacin de riesgo y el anlisis de impacto del negocio. Tambin se
identifica la estructura de gestin correcta y la estructura de proceso para hacer frente a los desastres.
Asignacin de recursos - establecer un ambiente ITSCM necesitar de una inversin importante en personal y
recursos. Tambin ser necesario capacitar el personal para que este se encuentre preparado para implementar la
etapa 2 del proceso ITSCM (requisitos y estrategia).
Establecer la organizacin del proyecto - es aconsejable usar mtodos de gestin de proyecto formales, por
ejemplo PRINCE 2, soportado por software de planificacin.
13.4.2 Anlisis de impacto del negocio

Antes de analizar los servicios TI, es aconsejable identificar por un lado las razones que tiene la empresa para incluir a la
Gestin de Continuidad de Servicios TI en la Gestin de Continuidad del Negocio; y por otro el impacto en el negocio de
una interrupcin de servicios importante. En algunos casos, el negocio puede sobrevivir durante algn tiempo y el nfasis
se debe poner sobre la restauracin de los servicios, en otros casos el negocio no puede operar sin los servicios TI y el
nfasis debe estar en la prevencin. Muchos negocios tendrn que encontrar el balance entre los dos extremos.
Las razones potenciales incluyen:
-
Proteccin de los procesos del negocio

Rpida recuperacin del servicio
Competencia por la supervivencia
Mantenimiento de la participacin de mercado
Mantenimiento de la rentabilidad
Proteccin de la reputacin que perciben los clientes
135

Las razones antes mencionadas pueden combinarse. En la industria financiera, la prdida de informacin de mercado
significa que el negocio perder dinero porque se interrumpe la negociacin (el principal proceso del negocio). Peor es el
caso en el que exista un requisito establecido por ley para registrar toda la actividad del negocio utilizando un sistema
especfico; aunque se pueda seguir comerciando, tarde o temprano se infringir el requisito legal y se impondrn multas
(ganancia y necesidad de una rpida recuperacin del servicio). En ambos casos, la empresa puede perder clientes y
participacin de mercado.
Anlisis de servicio
Una vez que se identificaron las razones para dar inicio a ITSCM, se realiza un anlisis de los servicios TI esenciales para
el negocio (p. Ej. Sistema de informacin, aplicaciones office, de contabilidad, e-mail, etc.) y cules deben estar
disponibles de acuerdo con los SLAs. Para algunos servicios no esenciales, se puede acordar la provisin de un servicio de
emergencia con capacidad y disponibilidad limitadas. Los niveles de servicio durante la recuperacin ante un desastre slo
podrn ser modificados si el cliente est de acuerdo. Para los servicios crticos, se debe encontrar el balance entre
prevencin y opciones de recuperacin.
Infraestructura
A continuacin se debe hacer una evaluacin de las dependencias entre servicios y recursos TI. La informacin de la
Gestin de la Disponibilidad se usa para analizar hasta qu punto los recursos TI tienen una funcin crtica en el soporte
de los servicios TI que se describieron anteriormente. La Gestin de la Capacidad proporciona informacin sobre la
capacidad necesaria. Tambin se determina hasta que punto se pueden interrumpir los servicios, desde la prdida del
servicio hasta su restauracin. Mas tarde, sta informacin se utilizar para identificar las opciones de recuperacin para
cada servicio.
13.4.3 Evaluacin de riesgo

No hay estadsticas de desastre oficiales, pero algunos de los desastres mundiales han sido:
Gas venenoso:
Corte de energa:
Terremotos:
Ataques terroristas:
Inundaciones
Tokio Metro, Japn (Marzo 1995)

Auckland, Nueva Zelanda (Diciembre 1997)
Los ngeles, USA (Enero 1994)
Kobe, Japn (Enero 1995)
Centro Mundial de Comercio, Nueva York, USA (Febrero 1993)
Bishopsgate, Londres, Inglaterra (Abril 1993)
Ciudad de Oklahoma, Oklahoma, USA (Abril 1995)
Docklands, Londres, Inglaterra (Febrero 1996)
Manchester, Inglaterra (Junio 1996)
World Trade Center, Nueva York, USA (Septiembre 2001)
Bangladesh (Julio 1996)
Pakistan {Agosto 1996)
Un anlisis de riesgo puede ayudar a identificar los riesgos a los que est expuesto un negocio. Tal anlisis tambin dar
informacin valiosa a la gestin porque identificar las amenazas y vulnerabilidades y las medidas de prevencin que
correspondan. Ya que es bastante caro mantener un plan de recuperacin ante desastres, primero se deben tomar medidas
preventivas. Una vez que se tomaron tales medidas para la mayora de los riesgos, se determinar si an existen riesgos
que puedan necesitar de un plan de contingencia.
La figura 13.2 muestra los vnculos entre anlisis de riesgo y gestin de riesgo; se basa en la CCTA Risk Analysis and
Management Method (CRAMM).
Figura 13.2 Modelo de evaluacin de riesgo CCTA (fuente OGC)
136

El modelo soporta un planeamiento de contingencia eficaz al tomar un planteo en fases.
Anlisis de riesgo
Primero se deben identificar los componentes TI relevantes (activos), tales como edificios, sistemas, datos, etc. Una
identificacin de activos eficaz significa que se tiene que documentar el propietario y el propsito de cada
componente.
La prxima etapa es analizar las amenazas y las dependencias y estimar la probabilidad (alta, media o baja) de que
ocurra un desastre, por ejemplo una combinacin de provisin de energa poco fiable y un rea con muchas
tormentas o con tormentas elctricas.
A continuacin las vulnerabilidades se identifican y se clasifican (alta, media y baja). Un pararrayos brindar algo de
proteccin contra los rayos, pero todava pueden afectar seriamente a la red y a los sistemas.
Finalmente, se evalan las amenazas y vulnerabilidades en el contexto de los componentes TI, para dar una
estimacin de los riesgos.
Cuando se estiman los riegos se debe considerar el alcance del proceso; de hecho, esto forma parte de la iniciacin del
proceso ITCSM (Fase 1). Por ejemplo, los problemas menores pueden ser solucionados con medidas de la Gestin de la
Disponibilidad, y algunos de los riesgos del negocio se encuentran fuera del alcance de ITSCM.
13.4.4 Estrategia de Continuidad de Servicios TI

Muchos negocios intentarn alcanzar un balance entre reduccin de riesgo y planificacin de recuperacin. Se debe hacer
una distincin entre reduccin de riesgo, actividad de recuperacin de las actividades del negocio, y opciones de
recuperacin TI La relacin entre reduccin de riesgo (prevencin) y planificacin de recuperacin (opciones de
recuperacin) se analiza mas abajo.
Medidas de prevencin
Las medidas de prevencin se pueden tomar con base en el anlisis de riesgo, mientras se considera con mucho cuidado
costes y riesgos. Las medidas pueden tender a reducir la probabilidad o el impacto de las contingencias, y por lo tanto
reducir el alcance del plan de recuperacin. Se pueden tomar medidas contra el polvo, las temperaturas demasiado altas o
bajas, fuego, interrupcin de energa y robo. El resto de los riesgos estn cubiertos en el plan de recuperacin.
El planteamiento Fuerte/Fortaleza es la forma de prevencin ms amplia. Elimina la vulnerabilidad, por ejemplo,
construyendo un bunker con su propio abastecimiento de agua y energa. Sin embargo, esto puede traer otras
vulnerabilidades, como el riesgo de fallo de la red, o barricadas, ya que la recuperacin off-site ser todava ms difcil. El
planteamiento fuerte (fortaleza) es conveniente para los grandes centros de proceso de datos que son demasiado complejos
para un plan de recuperacin. Hoy en da resulta vital complementar el planteo fuerte/fortaleza con la capacidad de
escaramuza, es decir, una capacidad de organizacin para ir al lugar en el que est el problema y tratar el mismo antes de
que entre en un espiral fuera de control.
Seleccionar opciones de recuperacin
Si todava hay riesgos que no han sido eliminados con las medidas de prevencin, se tendrn que tratar con la
planificacin de recuperacin. Las opciones de recuperacin tendrn que suministrarse de la siguiente manera para
garantizar la continuidad del servicio.
-
Personal y comodidad - como hacer frente al alojamiento, mobiliario, transporte, y distancias de viaje, etc.
Sistema TI y redes - las opciones de recuperacin se discuten mas abajo.
Servicio de soporte - energa, agua, telfonos, correo, y servicios de mensajera.
Archivos - archivos, documentos, sistemas basados en papel, y materiales de referencia.
Servicios de terceros - proveedores de servicios de e-mail y Internet.
Hay un nmero de opciones disponibles para la rpida recuperacin de los servicios TI:
-
No hacer nada - pocos negocios pueden seguir este planteamiento. Es probable que esto indique una actitud de no
querer ver. Los departamentos que piensan que pueden sobrevivir sin instalaciones de recuperacin TI pueden dar la
impresin de que significan tan poco para el negocio que se los puede eliminar despus de una contingencia. Sin
embargo, se puede investigar para cada servicio si sta resulta una opcin aceptable.
Regreso al sistema manual (basado en papel) - esta opcin es por lo general imposible para los servicios crticos
del negocio, porque habr poca cantidad de personal con la experiencia necesaria para usar los sistemas tradicionales.
Adems los sistemas basados en papel que se utilizaron antes pueden ya no estar disponibles. Sin embargo, los
sistemas basados en papel pueden ser prcticos para servicios menores, no tan importantes. Muchos planes de
recuperacin incluyen algunas rutinas de backup basadas en papel. Por ejemplo, la opcin de recuperacin para una
terminal de tarjeta de crdito puede ser el uso de los cupones de papel de las tarjetas de crdito.
137
Acuerdos recprocos - esta opcin puede utilizarse si dos organizaciones tienen hardware similar y acuerdan
prestarse las instalaciones en caso de desastre. Para esta opcin, los dos negocios deben formalizar un acuerdo y
garantizar la coordinacin para que los dos entornos permanezcan sin cambios. La Gestin de la Capacidad debera
asegurar que la capacidad de reserva no se utilice para otros propsitos, o que se libere rpidamente. Hoy en da esta
opcin no es muy atractiva debido al incremento de los sistemas on line como los cajeros automticos y los sistemas
bancarios on line que tienen que estar disponibles las 24 horas, los 7 das de la semana.
Recuperacin gradual (stand-by fro) - esta opcin se puede utilizar en los negocios que pueden estar sin servicio
TI por un tiempo, p. Ej. 72 horas. Provee un centro de proceso de datos vaco en una instalacin fija acordada o uno
mvil que se entrega en el lugar del negocio, la instalacin porttil. El centro de proceso de datos se proporciona con
energa, aire acondicionado, instalacin de red y telfono. Esta opcin de recuperacin se puede realizar por contrato
con proveedores externos. Se tendrn que hacer contratos por separado con abastecedores de componentes TI para
garantizar que las entregas se realicen rpidamente. La ventaja de este sistema es que la instalacin se encuentra
siempre disponible. Las ventajas y desventajas son diferentes para las instalaciones fijas y las porttiles, y se
relacionan con temas aspectos como:

Distancia a la instalacin - pocos son los proveedores que ofrecen instalaciones fijas. Estas pueden ser remotas,
desventaja que se elimina con el uso de una instalacin porttil.
Tiempo - ubicaciones de instalaciones fijas que slo se encuentran disponibles durante un tiempo limitado.
Demora - en cualquier caso, la entrega del hardware necesario llevar algn tiempo.
Red- por lo general resulta difcil proporcionar las instalaciones de red como corresponde. Las conexiones para
una instalacin porttil pueden proveerse en el edificio que se usa para las operaciones normales.
Recuperacin Intermedia (stand-by clido) - esta opcin proporciona acceso a un ambiente de operacin similar al
utilizado habitualmente, en el que se puede continuar con los servicios con normalidad tras un corto periodo de
cambio (24-72 horas). Existen tres versiones para esta opcin:
Interna (retirada mutua) - si el negocio tiene muchos lugares o ambientes de test dedicados que se pueden usar
para la produccin. Esta opcin brinda recuperacin total tras un tiempo de recuperacin mnimo. Las
organizaciones con varios sistemas distribuidos a menudo usan una variacin de este planteamiento, en los que
se reserva la capacidad necesaria en cada sistema. Esta capacidad extra es monitorizada por la Gestin de la
Capacidad (similar al acuerdo recproco de opcin de recuperacin).
Externa - algunos proveedores de servicio dan esta opcin como servicio del negocio. Los costes se dividen
entre los clientes. Los costes de estos arreglos dependen del hardware y software necesarios y el periodo
acordado durante el que se proveen las instalaciones (p. Ej. 16 semanas). Estos arreglos a menudo se realizan
para unir el periodo necesario para establecer una instalacin stand-by fra. Este planteamiento es relativamente
ms caro y es probable que la instalacin se encuentre ms lejos.
Mvil - la infraestructura para esta opcin es un trailer listo para usar. El trailer sirve como centro de proceso de
datos y tiene comodidades ambientales controladas como aire acondicionado. La organizacin TI debe contar
con un lugar para estacionar el trailer. La provisin de energa, datos y conexiones de telecomunicaciones
deben estar disponibles en ciertos puntos cerca del edificio. Las ventajas de esta opcin incluyen el corto tiempo
de respuesta y la proximidad al lugar de negocio. Esta opcin slo est disponible para un nmero de
plataformas de hardware limitadas. Algunos de los abastecedores de hardware ms grandes ofrecen este servicio
con cierra cantidad de trailers con configuraciones de hardware estndar. En periodos acordados, por ejemplo
una vez al ao, el trailer visita el negocio para probar los planes de recuperacin. La ventaja de esto es que
tambin resulta posible evaluar el impacto de un upgrade a una versin nueva del sistema operativo.
Recuperacin Inmediata (comienzo caliente, stand-by caliente) - esta opcin brinda una recuperacin muy rpida
o inmediata de los servicios menos de 24 horas. Ofrece un entorno de produccin idntico y refleja los datos y hasta
los procesos de produccin. La ltima opcin se desarrolla por lo general con la cooperacin de la Gestin de la
Disponibilidad.
Combinacin de opciones - en muchos casos un Plan de Contingencia puede utilizar una opcin ms cara para
introducir una opcin ms barata. Por ejemplo, un trailer con un centro de proceso de datos operativo (comienzo
caliente mvil) puede ser una solucin temporal hasta que las instalaciones porttiles hayan sido establecidas y los
nuevos sistemas host hayan sido entregados (comienzo mvil fro). Las operaciones normales se restauran despus de
arreglar el edificio y mudar los nuevos ordenadores host al mismo.
138
13.4.5 Organizacin y planificacin de la implementacin

Una vez que se determin la estrategia del negocio y se opt por algo, se debe implementar el proceso ITSCM y se tienen
que desarrollar en detalle los planes para las instalaciones TI Se deber establecer una organizacin para implementar el
proceso ITSCM. Esto puede incluir la gestin (Gestor de Crisis), la coordinacin, y los equipos de recuperacin para cada
servicio.
En el nivel ms alto debe existir un plan de direccin total para los siguientes temas:
-
Plan de respuesta ante emergencia

Plan de evaluacin de dao
Plan de recuperacin
Plan de informes vitales (que hacer con los datos, incluyendo los informes en papel)
Gestin de Crisis y planes PR
Todos estos planes se usan para evaluar las emergencias y responderlas. Luego se puede decidir si se debe iniciar el
proceso de recuperacin del negocio, y en ese caso, se debe activar el siguiente nivel de planes, incluyendo:
-
Alojamiento y plan de servicios

Sistemas informticos y plan de red
Plan de telecomunicaciones (accesibilidad y vnculos)
Plan de seguridad (integridad de los datos y redes)
Plan de personal
Planes financieros y administrativos
13.4.6 Medidas preventivas y opciones de recuperacin

Se hace referencia a cuando se ponen en prctica las medidas de prevencin y las opciones de recuperacin que se
identificaron ms temprano.
Las medidas de prevencin para reducir el impacto de un incidente se toman junto con la Gestin de la Disponibilidad y
pueden incluir:
-
Uso de UPS y provisiones de energa de backup

Sistemas tolerantes a fallos
Almacenamiento en otro lugar y sistemas RAID, etc.
Tambin se debe empezar a introducir acuerdos stand-by. Estos deben cubrir personal, edificios y telecomunicaciones.
Aun durante el periodo de contingencia se debe empezar con la restauracin a la situacin normal y el pedido de
componentes nuevos. Se pueden hacer contratos en suspenso con los abastecedores, es decir, que estn disponibles los
pedidos firmadas con los componentes a entregar a un precio acordado. Cuando se produce el desastre, el abastecedor
puede procesar la orden sin tener que enviar cotizaciones. Esta clase de contratos se deben actualizar todos los aos
porque los precios y los modelos cambian. Al actualizar los contratos se deben tener en cuenta las lneas de referencia de
la Gestin de Configuraciones.
Para establecer los acuerdos stand-by se pueden llevar a cabo las siguientes actividades:
-
Negociar con terceros instalaciones de recuperacin en otro lugar.

Mantener y equipar las instalaciones de recuperacin.
Comprar e instalar hardware stand-by (contratos en suspenso).
Administrar contratos en suspenso.
13.4.7 Planes de desarrollo y procedimiento para la recuperacin

Deben ser planes de detallados y formales, ya que los interesados deben aprobar los cambios y el plan de recuperacin
debe contar con mantenimiento. Estos temas tambin se deben comunicar.
Los mayores problemas tienen que ver con los cambios en la infraestructura y los niveles de servicio acordados. Por
ejemplo, migrar a una nueva plataforma de rango medio puede significar que no hay unidad equivalente en la instalacin
de backup para un comienzo caliente, externo. Por esta razn, la Gestin de Configuraciones juega un rol muy importante
en la monitorizacin de las configuraciones de referencia a las que se hace referencia en el plan de recuperacin. El plan
tambin debe identificar los procesos que se necesitan para dar soporte.
139

Plan de recuperacin
El Plan de recuperacin debe incluir todos los elementos de la restauracin de las actividades del negocio y los servicios
TI, incluyendo:
Introduccin - describe la estructura del plan y las instalaciones de recuperacin que se prevn.
Actualizacin - discute los procedimientos y acuerdos para mantener el plan y rastrea los cambios en la
infraestructura.
Lista de enrutamiento - el plan esta dividido en secciones, cada una de las cuales especifica las acciones
desarrolladas por un sistema especfico. La lista de enrutamiento muestra qu secciones deben enviarse y a que
personal.
Iniciacin de recuperacin - describe cunto y en qu condiciones se invoca el plan.
Clasificacin de contingencia - si el plan describe procedimientos para distintas contingencias se las debe describir
aqu en trminos de seriedad (menor, medio, mayor), duracin {da, mes, semanas) y dao (menor, limitado, serio).
Secciones especialistas - el plan debe dividirse en secciones basadas en las seis reas y grupos que cubren el plan:

Administracin - cmo y cundo se invoca el plan, qu gestores y personal estn involucrados, y dnde tiene la
base el centro de control.

Infraestructura TI - hardware, software y telecomunicaciones a ser provistos por el sistema de recuperacin,
los procedimientos de recuperacin, y los contratos en suspenso de compra de nuevos componentes TI.

Personal - el personal necesario en la instalacin de recuperacin, posible transporte a la instalacin y
alojamiento si la instalacin se encuentra lejos del negocio.

Seguridad - instrucciones para proteccin contra robo, fuego y explosiones en el lugar habitual y en el remoto, e
informacin sobre las instalaciones de almacenamiento externo como depsitos y bvedas.

Lugares de recuperacin - informacin sobre contratos, personal y funciones especficas, seguridad y
transporte.

Restauracin - procedimiento para restaurar a la situacin normal (p. Ej. El edificio), condiciones entre las que
se invocan estos procedimientos, y contratos en suspenso.
Procedimientos
El plan de recuperacin proporciona un marco de trabajo para disear los procedimientos. Es esencial tener
procedimientos eficaces para que cualquiera pueda poner en marcha la recuperacin siguiendo los procedimientos. Se
debe mencionar:
-
La instalacin y evaluacin del hardware y los componentes de red.

La restitucin de las aplicaciones, base de datos y datos.
Estos y otros procedimientos relevantes se adjuntan al plan de recuperacin.
13.4.8 Evaluacin Inicial

La evaluacin inicial es un aspecto crtico de ITSCM. Las evaluaciones se deben hacer al principio, despus de cambios
importantes y anualmente. El departamento TI es el responsable de evaluar la eficacia de los planes y procedimientos de
los elementos TI del plan. Las evaluaciones pueden o no ser anunciadas.
13.4.9 Capacitacin y conocimiento

La capacitacin eficaz del personal TI y otro personal y el conocimiento de todo el personal de la organizacin son
esenciales para el xito de cualquier proceso de Continuidad de Servicios TI.
El personal TI tendr que capacitar personal no TI en equipos de recuperacin del negocio para garantizar que se
encuentren familiarizados con los temas para que puedan ayudar durante las operaciones de recuperacin. Las
instalaciones de contingencia reales, en el lugar o en otro lugar, tambin deben considerar la capacitacin y evaluacin.
13.4.10 Revisin y auditora

Se debe verificar a menudo que los planes estn actualizados. Esto se relaciona con todos los aspectos de ITSCM. En el
rea TI, tal auditora se debe realizar cada vez que se hace un cambio importante a la infraestructura TI, como
introduccin de nuevos sistemas, proveedores de redes y servicios.
Las auditorias tambin deben realizarse si hay un cambio de estrategia en el departamento TI o en el negocio. Las
organizaciones en las que hay cambios rpidos y frecuentes pueden implementar un programa regular de verificacin de
conceptos ITSCM. Cualquier cambio resultante en los planes y la estrategia se deben implementar bajo la direccin de la
Gestin de Cambios.
140
13.4.11 Evaluacin
El Plan de Recuperacin debe evaluarse regularmente como si fueran las instrucciones de emergencia de un barco. Si
todos tienen que estudiar el plan cuando se produce un desastre, habr ms posibilidades de que existan problemas. La
evaluacin tambin puede identificar las debilidades del plan o los cambios que se pasaron por alto. En algunos casos los
cambios se pueden evaluar de antemano utilizando instalaciones de recuperacin antes de introducirlos directamente en la
infraestructura.

La Gestin de Cambios cumple una funcin muy importante al mantener todos los planes al da. Se debe analizar el
impacto de cualquier cambio en el Plan de Recuperacin.
13.4.13 Seguridad
Seguridad significa verificar si la calidad del proceso (procedimientos y documentos) es adecuada para las necesidades del
negocio de la empresa.

El control del proceso eficaz depende de los informes de gestin, los factores de xito crticos y los indicadores de
rendimiento.

Ante un desastre habr informes sobre sus causas y efecto, y el nivel de xito al resolverlo. Cualquier debilidad observada
ser tratada en los planes de mejora. Los informes de gestin de este proceso tambin incluyen informes de evaluacin de
las pruebas de los planes de recuperacin. Estos son utilizados para la seguridad. El proceso tambin informa sobre los
planes de recuperacin como resultado de cambios significantes en cualquier otro lugar. Las amenazas nuevas tambin
deben quedar registradas.

El xito de la Gestin de Continuidad de Servicios TI depende de:
-
Un proceso de Gestin de Configuracin eficaz

Soporte y compromiso de toda la organizacin
Herramientas actuales y eficaces
Capacitacin dedicada de cualquier persona involucrada en el proceso
Pruebas regulares, no anunciadas en el plan de recuperacin
Los indicadores de rendimiento incluyen:

-
Nmero de fallos de los planes de recuperacin

Ganancia perdida tras un desastre
Coste del proceso

Tarea principal del Gestor de Continuidad de Servicios TI es implementar y mantener el proceso necesario para garantizar
que se cumpla con los requisitos de Gestin de Continuidad del Negocio en todo momento.
Se pueden identificar un nmero de roles y responsabilidades, diferencindose entre las responsabilidades durante
condiciones normales o condiciones de crisis.
Rol
Consejo
Gestin Mayor
Gestin
Lderes de grupo y
miembros de grupo
Responsabilidades en condiciones normales

Inicia BCM
Asigna personal y recursos
Define polticas
Define autoridad de proceso
Administra el proceso ITSCM
Acepta planes, informes de pruebas, etc.
Comunica y mantiene el conocimiento.
Integracin ITSCM dentro de BCM
Lleva a cabo el anlisis de riesgo
Define los entregables
Disea los contratos
Gestiona pruebas, evaluaciones e informes
Desarrolla los entregables
Negocia servicios
Implementa pruebas, evaluaciones e informes
Desarrollo e implementacin de procedimientos
Responsabilidades en condiciones crticas

Gestin de crisis
Toma de decisiones corporativas / del negocio
-
Coordinacin y arbitracin
Provisin de personal, recursos y fondos
Invocacin de mecanismos de recuperacin y continuidad

Dirige de direccin
Informes
Implementacin del plan de recuperacin
Tabla 3.1 Ejemplos de responsabilidades ITSCM
141

13.6.1 Costes
Los costes ms importantes al introducir la Gestin de Continuidad de Servicios TI son:
-
Tiempo y coste para iniciar, desarrollar, e implementar ITSCM.

Las inversiones asociadas a la introduccin de la gestin de riesgo y el hardware adicional resultante. Si en el
momento de disear las configuraciones nuevas, se consideran las medidas dentro del alcance de la Gestin de la
Disponibilidad, se pueden reducir los costes.
Costes de continuacin de los planes de recuperacin que dependen de la opcin seleccionada, tales como cuotas de
los contratos para el comienzo caliente externo, coste de las pruebas de restitucin, y el periodo durante el que las
instalaciones de recuperacin estn disponibles.
Costes operacionales de ITSCM, como pruebas, auditoria, y actualizacin del plan. Solo se puede incurrir estos
costes tras haber considerado la eleccin, y comparando los costes potenciales asociados con carecer de un plan de
recuperacin. Aunque los costes para mantener un plan de recuperacin pueden parecer elevados, a menudo son
razonables comparados con el gasto total de los seguros contra incendio y robo. Adems una ITSCM eficaz puede
reducir el coste de los stos.
13.6.2 Problemas
Cuando se implementa el proceso se deben considerar los siguientes problemas potenciales:
Recursos - para probar y desarrollar el plan, la organizacin TI deber contar con capacidad adicional para un equipo
de proyecto.
Compromiso - los costes anuales deben incluirse en los presupuestos de la organizacin, ello implica compromiso.
Acceso a las instalaciones de recuperacin - todas las opciones que se discutieron arriba necesitan de la prueba de
las instalaciones de recuperacin. As, los contratos debern brindar a la organizacin TI acceso regular a las
instalaciones de recuperacin.
Estimacin del dao - cierto dao, como prdida de reputacin, no se puede cuantificar en dinero.
Elaboracin de Presupuesto - no siempre se entiende la necesidad de instalaciones de contingencia caras, otras
veces los planes se recortan.
Falta de compromiso de la gerencia del negocio - esto da como resultado un fallo en el desarrollo de ITSCM,
aunque el cliente asuma que se han hecho los arreglos.
Eventualidad perpetua - todas o muchas partes de la gestin de Continuidad de Servicios TI no estn en su lugar y,
en consecuencia, se pospone el progreso. En tales casos, cuando se pregunta sobre ITSCM, la respuesta ser "si, nos
encontramos para eso la semana que viene...", "estamos a punto de nombrar un comit para esto...", etc.
Caja Negra - donde el proveedor de servicios TI ha abdicado responsabilidades, adems de dejar el control a
disponibilidad de ITSCM: "alguien se est ocupando de eso...". Dado que la organizacin ha gastado mucho dinero o
ha encargado a terceros parte de sus operaciones, la gestin espera que el dinero invertido garantice su capacidad de
recuperacin, o que el proveedor tambin tenga planes en el lugar que los ayudarn a recuperarse despus de una
interrupcin del negocio.
Departamento TI - debe guiarse por los deseos y requisitos actuales del negocio, y no por las suposiciones del
departamento TI sobre ellos mismos.
Familiaridad con el negocio - es imprescindible que el negocio ayude al desarrollo de ITSCM identificando los
temas principales.
Falta de conocimiento - es esencial que la organizacin como un todo conozca el valor ITSCM. Sin el conocimiento
y la ayuda de todo el personal, el proceso est condenado al fallo.
142
Captulo 14:
14.1 Introduccin
EI ritmo de desarrollo tecnolgico sigue creciendo. Por esa razn, dentro de muchas organizaciones el
hardware y software necesarios se mantienen en expansin y se diversifican ms, a pesar de los esfuerzos de
estandarizacin. Las tecnologas viejas y nuevas deben trabajar juntas. Esto da como resultado estructuras de
red, interfaces, e instalaciones de comunicaciones adicionales. Las operaciones del negocio dependen cada
vez ms de la tecnologa.
Unas pocas horas sin ordenador pueden tener un impacto serio en la produccin y la imagen de un negocio, en
particular ahora que Internet se est transformando en un mercado electrnico.
Ya que los negocios del competidor estn a slo unos clicks, la lealtad del cliente y su satisfaccin son ms
importantes que nunca. Esta es una de las razones por las que los sistemas estn disponibles los siete das de
la semana, las 24 horas del da.

La Figura 14.1 ilustra los conceptos bsicos de la Gestin de la Disponibilidad.
Figura 14.1 Conceptos bsicos de la Gestin de la Disponibilidad (fuente: OGC)
Disponibilidad
Una alta disponibilidad significa que el servicio TI est continuamente disponible para el cliente porque hay
pocos fallos y el servicio de recuperacin es veloz. La disponibilidad alcanzada se indica a travs de mtricas.
La disponibilidad del servicio depende de:
-
La complejidad de la arquitectura de la infraestructura TI

La fiabilidad de los componentes
Habilidad para responder rpido y eficazmente a las faltas
Calidad del mantenimiento y de las organizaciones de soporte y abastecedores
Calidad y alcance de los procesos de gestin de operacin
143
Gestin de Disponibilidad
Fiabilidad
Una Fiabilidad correcta significa que el servicio est disponible durante cierto tiempo sin interrupciones.
Este concepto tambin incluye la resistencia. La fiabilidad de un servicio aumenta si se puede prevenir la
interrupcin. La fiabilidad se calcula usando estadsticas. La fiabilidad de servicio se determine por la
combinacin de los siguientes factores:
-
Fiabilidad de los componentes usados para dar un servicio

Habilidad de un servicio o componente para operar eficazmente a pesar del fallo de uno o ms
subsistemas (resistencia)
Mantenimiento preventivo para evitar interrupciones
Mantenimiento
El mantenimiento y recuperacin se relacionan con las actividades necesarias para mantener el servicio en
operacin, y para restituirlo cuando falla, esto incluye mantenimiento preventivo e inspecciones programadas.
Estos conceptos incluyen las siguientes actividades:
-
Tomar medidas para prevenir fallos

Detectar fallos
Hacer Realizar el diagnstico incluyendo el diagnstico automtico que realizan los componentes
Resolver el fallo
Recuperacin tras un fallo
Restitucin del servicio
Capacidad de Servicio
La Capacidad de Servicio tiene que ver con las obligaciones contractuales de los proveedores de servicios
externos (contratistas, terceros). Los contratos definen el soporte que deben proveer a los servicios
externalizados. Ya que esto slo interesa a parte del servicio TI, el trmino no se refiere a la disponibilidad
total de un servicio. Si un contratista es responsable de los servicios como un todo (por ejemplo cuando
termina el contrato de la administracin de instalaciones), Capacidad de Servicio y disponibilidad son
sinnimos.
Una Gestin de la Disponibilidad eficaz necesita de una comprensin acabada de los negocios y el entorno TI.
Es importante ser conscientes de que la disponibilidad simplemente no se puede "comprar": la disponibilidad
debe incluirse en el diseo inicial. Finalmente, la disponibilidad depende de la complejidad de la
infraestructura, la fiabilidad de los componentes, el profesionalismo de la organizacin TI y sus contratistas, y
la calidad en si del proceso.
14.2 Objetivos
El objetivo de la Gestin de la Disponibilidad es proporcionar un nivel de disponibilidad de servicio TI
definido y eficiente en coste que permita al negocio alcanzar sus objetivos.
Esto significa que las demandas del cliente (el negocio) deben estar en lnea con lo que la infraestructura TI y
la organizacin TI son capaces de ofrecer. Si existe una diferencia entre oferta y demanda, la Gestin de la
Disponibilidad tendr que ofrecer una solucin. Adems, la Gestin de la Disponibilidad garantiza que se
midan los niveles de disponibilidad alcanzados y, si es necesario, se mejoren continuamente. Esto significa
que el proceso incluye actividades preactivas y reactivas.
Cuando se desarrolla el proceso se deben tener en cuenta las siguientes premisas:
-
La introduccin de Gestin de la Disponibilidad es esencial para obtener un alto grado de satisfaccin del
cliente. La disponibilidad y la fiabilidad determinan en gran medida cmo perciben los clientes el
servicio proporcionado por la organizacin.
144

-
Siempre habr fallos, aunque se disponga de un alto grado de disponibilidad. La Gestin de la

Disponibilidad es ampliamente responsable por la respuesta profesional a tales situaciones no deseadas.
El diseo del proceso demanda no solo una comprensin global d e TI, sino tambin una apreciacin de
los procesos y servicios del cliente. Combinando estos dos aspectos se pueden alcanzar los objetivos.
La Gestin de la Disponibilidad tiene un amplio alcance e incluye servicios a clientes nuevos y existentes,
relaciones con proveedores internos y externos, todos los componentes de la infraestructura (hardware,
software, redes, etc.) y los aspectos de organizacin que pueden afectar la disponibilidad, como la experiencia
del personal, los procesos de gestin, y los procedimientos y herramientas.
14.2.1 Beneficios
El mayor beneficio de la Gestin de la Disponibilidad es que los servicios TI que se disean, se implementan
y manejan, cumplan con los requisitos acordados de disponibilidad. Una comprensin acabada de los
procesos del negocio del cliente y de TI, combinado con una aspiracin para maximizar la disponibilidad y la
satisfaccin del cliente dentro de las necesidades puede aportar una importante contribucin a la realizacin
de un servicio de cultura eficaz. Otros beneficios de la Gestin de la Disponibilidad son:
-
Slo hay un contacto y una persona responsable de la disponibilidad de los productos y servicios.
Los productos y servicios nuevos cumplen con los requisitos y la disponibilidad estndar que se acord
con el cliente.
Los costes asociados son aceptables.
Los estndares de disponibilidad se monitorizan continuamente y se mejoran si corresponde.
Cuando un servicio no esta disponible, se toma una accin correctiva apropiada.
Se reducen la aparicin y duracin de la falta de disponibilidad.
El nfasis se traslada de remediar los fallos a mejorar el servicio.
Es ms fcil para la organizacin TI demostrar su valor agregado.
Los siguientes procesos ITIL tienen relacin con la Gestin de la Disponibilidad.

La Gestin de servicios es responsable de negociar y manejar los Acuerdos de Nivel de Servicio, en los que la
disponibilidad es uno de los elementos ms importantes.
La Gestin de Configuraciones tiene informacin sobre la infraestructura y puede dar informacin valiosa a la
Gestin de la Disponibilidad.
Los cambios en la capacidad a menudo afectan la disponibilidad de un servicio y los cambios a la
disponibilidad afectarn la capacidad. La Gestin de la Capacidad tiene disponible mucha informacin,
incluyendo informacin sobre la infraestructura TI. As, estos dos procesos por lo general intercambian
informacin sobre los escenarios para realizar una actualizacin o eliminar componentes TI, y sobre las
tendencias de disponibilidad que pueden necesitar cambios en los requisitos de capacidad.
Gestin de la disponibilidad no es responsable de la restitucin de los procesos del negocio despus de un
desastre. La Gestin de Continuidad de Servicios TI es responsable de esta tarea.
ITSCM da informacin a la Gestin de la Disponibilidad sobre los procesos del negocio crticos.
Tambin, en la prctica, muchas medidas que se toman para mejorar la Disponibilidad mejoran a su vez la
Continuidad del Servicio TI, y viceversa.
Gestin de Problemas
La Gestin de Problemas es responsable en forma directa de identificar y resolver las causas de problemas de
disponibilidad reales o potenciales.
145
La Gestin de Incidentes especifica cmo se deben resolver stas. Este proceso da requisitos con informacin
sobre los tiempos de recuperacin, de reparacin, etc. Esta informacin se utiliza para determinar la
disponibilidad alcanzada.
La Gestin de la Disponibilidad tiene fuertes vnculos con la Gestin de la Seguridad. Los tres temas bsicos
de la Gestin de la Seguridad son:
-
Confidencialidad
Integridad
Disponibilidad
Gestin de Cambios
La Gestin de la Disponibilidad informa a la Gestin de Cambios de los temas de soporte relacionados con
los servicios y elementos nuevos de la misma e inicia el proceso de Gestin de Cambios para implementar los
cambios que necesitan por necesidades de disponibilidad. La Gestin de Cambios informa a la Gestin de la
Disponibilidad sobre los cambios programados (FSC).
14.3 El Proceso
Donde es posible, los componentes esenciales se duplican y la deteccin de fallos y los sistemas de correccin
se utilizan para alcanzar elevados grados de disponibilidad. A menudo, los sistemas automticos de respaldo
operarn en caso de fallo. Sin embargo, tambin se debern tomar medidas de organizacin que pueden ser
proporcionadas introduciendo la Gestin de la Disponibilidad.
Figura 14.2 Entradas y produccin de la Gestin de la Disponibilidad
146

La Gestin de la Disponibilidad puede iniciarse una vez que el negocio defini con claridad sus requisitos de
disponibilidad para los servicios. Es un proceso en marcha que slo termina cuando se elimina un servicio.
Las entradas del proceso de la Gestin de la Disponibilidad (Figura 14.2) son:
-
Requisitos de disponibilidad del negocio.

Evaluacin del impacto para todos los procesos del negocio que soporta TI.
Requisitos de disponibilidad, fiabilidad, y capacidad de mantenimiento para los componentes TI de la
infraestructura.
Datos sobre fallos que afectan los servicios o componentes, por lo general en forma de registros e
informes de incidentes y problemas.
Datos de configuracin y monitorizacin sobre los servicios y componentes.
Niveles de servicio alcanzados comparados con los niveles de servicio acordados para todos los servicios
cubiertos en el SLA.
Salidas:
-
Disponibilidad y criterio de diseo de recuperacin para servicios TI nuevos y mejorados.

Tecnologa necesaria para obtener la resistencia de la infraestructura necesaria para reducir o eliminar el
impacto de los componentes fallados de la infraestructura.
Garantas de disponibilidad, fiabilidad, y capacidad de mantenimiento de los componentes de la
infraestructura necesarios para el servicio TI.
Informes sobre la disponibilidad, fiabilidad y capacidad de mantenimiento alcanzadas.
Requisitos de monitorizacin de la disponibilidad, fiabilidad y capacidad de mantenimiento alcanzadas.
Un plan de Disponibilidad para la mejora preactiva de la infraestructura TI.
14.4 Actividades
La Gestin de la Disponibilidad incluye un cierto nmero de actividades clave que tienen que ver con la
planificacin y la monitorizacin.
Estas actividades son:
-
Planificacin
Determinar los requisitos de disponibilidad
Diseo para la disponibilidad
Diseo para la recuperacin
Temas de seguridad
Gestin de mantenimientos
Desarrollo de un Plan de Disponibilidad
Monitorizacin
Medicin e informes
Estas actividades clave se discuten ms adelante.
14.4.1 Determinar los requisitos de disponibilidad

Estas actividades se deben llevar a cabo antes de terminar el SLA y debe mencionad los servicios TI nuevos y
los cambios a los servicios existentes. Se debe tratar de decidir cuanto antes si la organizacin TI puede
cumplir con los requisitos y cmo.
147
Estas actividades deben identificar:
-
Fundones claves del negocio

Definicin acordada de la interrupcin del servicio TI
Requisitos de disponibilidad cuantificables
Impacto cuantificable de las funciones del negocio en caso de interrupcin de servicio TI no programada
Horarios del negocio del cliente
Acuerdos sobre las ventanas de mantenimiento
Definir con claridad los requisitos de disponibilidad en las primeras etapas es muy importante para prevenir la
confusin y las diferencias de interpretacin en las siguientes etapas.
Se deben comparar los requisitos del cliente con lo que se puede ofrecer. Si existe una diferencia, se debe
determinar qu impacto de coste tendr.
14.4.2 Diseo para la disponibilidad

Las vulnerabilidades que afectan los estndares de disponibilidad deben identificarse cuanto antes. Con esto
se evitarn costes de desarrollo excesivos, gasto no planeado en etapas futuras, Puntos nicos de Fallo
(SPOF), costes adicionales facturados por los abastecedores y versiones demoradas.
Un buen diseo, basado en los estndares de disponibilidad correctos, har posible la firma de acuerdos de
mantenimiento con los abastecedores. El proceso de diseo emplea una gama de tcnicas tales como el
Anlisis de Impacto de Fallo de Componente (CFIA, ver seccin 14.4.9) para identificar SPOFs, CRAMM's
(ver captulo sobre Gestin de Continuidad de Servicios TI) y tcnicas de simulacin.
S no se pueden alcanzar los estndares de disponibilidad, la mejor opcin es determinar si se puede mejorar
el diseo. El uso de tecnologa adicional, otros mtodos, una estrategia de versiones diferente, un mejor
diseo o uno distinto, y las herramientas de desarrollo pueden ser de utilidad para alcanzar los estndares.
Si los requisitos son particularmente exigentes, se puede considerar el uso de otras tecnologas tolerantes a
fallos, otros procesos de servicio (incidentes, problemas y Gestin de Cambios) u otros recursos adicionales
de la Gestin de Servicios. Los recursos financieros de los que se dispone son los que determinan
principalmente las opciones y elecciones.
14.4.3 Diseo del Mantenimiento

Dado que es poco probable que la disponibilidad sea ininterrumpida, se deben considerar aquellos periodos
sin disponibilidad. Cuando se interrumpe un servicio TI, es importante arreglar rpida y correctamente el fallo
para cumplir con los estndares de disponibilidad acordados. El diseo de la recuperacin incluye temas tales
como un proceso de Gestin de Incidentes eficaz con escalados, comunicaciones, y procedimientos de soporte
y recuperacin apropiados.
Se deben definir claramente las tareas, las responsabilidades y la autoridad.
14.4.4 Temas clave de seguridad

La fiabilidad est ntimamente relacionada. Una pobre informacin de seguridad puede afectar la
disponibilidad del servicio. Se deben considerar los temas de seguridad y su impacto en la provisin de
servicios durante la fase de planificacin. Una elevada disponibilidad puede contar con un soporte de
seguridad de la eficaz.
Algunos de los temas son:
- Determinar quin se encuentra autorizado para acceder a reas de seguridad.
- Determinar autorizaciones crticas a emitir.
148
14.4.5 Gestin del Mantenimiento

Por lo general, siempre habr ventanas de faltas de disponibilidad programadas. Estos periodos se pueden usar
para realizar tareas preventivas, como actualizaciones de hardware y software. Tambin se pueden
implementar cambios durante este tiempo.
En una economa de 24 horas, sin embargo, resulta difcil determinar las ventanas de mantenimiento
correctas. Las actividades de definicin, implementacin, y verificacin de las actividades de mantenimiento
se han convertido en puntos importantes de la Gestin de la Disponibilidad.
El mantenimiento se debe realizar cuando el impacto en los servicios sea mnimo. Esto significa que debe
conocerse de antemano cules son los objetivos del mantenimiento, cundo se debe hacer el mantenimiento y
qu actividades de mantenimiento estn involucradas (puede basarse en la CFIA). Esta informacin resulta
muy importante para la Gestin de Cambios y para las otras actividades.
I4.4.6 Medicin e informes

La medicin y los informes son actividades importantes para la Gestin de la Disponibilidad, ya que son la
base de verificacin de los acuerdos de servicio, la resolucin de problemas y la definicin de propuestas de
mejora.
Si no lo mides, no puedes manejarlo.
Si no lo mides, no puedes mejorarlo.
Si no lo mides, probablemente no te interesa.
Si no puedes influenciar en ello, no lo midas.
El ciclo de vida de cada incidente incluye los siguientes elementos:
-
Momento del incidente - la hora a la que el usuario nota la falta, o cuando la falta se identifique por
otros medios (tcnica o fsicamente).
Deteccin - se informa al proveedor del servicio sobre el fallo. El estado del incidente es ahora
"informado". El tiempo que lleva esto se conoce como hora de deteccin.
Respuesta - el proveedor de servicio necesita tiempo para responder. Esto se conoce como hora de
respuesta. Este tiempo se utiliza para el diagnstico, que despus de la reparacin puede seguirse. El
proceso de la Gestin de Incidentes incluye la Aceptacin y Registro, la Clasificacin, la Asociacin, el
Anlisis y el Diagnstico.
Reparacin - el proveedor de servicio restaura el servicio o los componentes que provocaron el fallo.
Recuperacin del servicio - se restituye el servicio. Esto incluye actividades como la configuracin e
inicializacin, y restitucin del servicio al usuario.
La Figura 14.3 ilustra los periodos que se pueden medir.
Figura 14.3 Medicin de la Disponibilidad (fuente: OGC)
149
Tal como lo muestra la figura, el tiempo de respuesta de la organizacin TI y cualquier contratista externo es
uno de los factores que determinan la interrupcin. Dado que la organizacin TI puede controlar este factor, y
afecta la calidad del servicio en forma directa, se pueden incluir acuerdos al respecto del SLA. Se pueden
promediar las mediciones para dar una buena impresin de los factores relevantes. Los promedios se pueden
utilizar para determinar los niveles de servicio alcanzados y para estimar la disponibilidad futura esperada de
un servicio. Esta informacin tambin se puede utilizar para desarrollar planes de mejora.
La Gestin de la Disponibilidad usa por lo general las siguientes mtricas:
-
Tiempo Medio de Reparacin - MTTR - tiempo medio entre la aparicin del fallo y la recuperacin del
servicio, tambin conocido como Tiempo de Parada (downtime). Es la suma del tiempo de deteccin y el
de resolucin. Esta mtrica se relaciona con la recuperacin y la utilidad del servicio.
Tiempo Medio entre Fallos - MTBF - tiempo medio entre la recuperacin del incidente y la aparicin
del prximo, tambin conocido como Tiempo de Disponibilidad (uptime). Esta mtrica se relaciona con
la fiabilidad del servicio.
Tiempo Medio entre los Incidentes del Sistema - MTBSI - tiempo medio entre la aparicin de dos
incidentes consecutivos. El MTBSI es la suma de MTTR y MTBF.
La tasa de MTBF y la de MTBSI indican si hay muchos fallos menores o slo algunos mayores.
Los informes de disponibilidad incluyen las siguientes mtricas:
-
Tasa de disponibilidad (o falta de disponibilidad) en trminos de MTTR, MTBF y MTBSI.

Tiempo de disponibilidad y Tiempo de Parada total.
Nmero de fallos.
Informacin adicional sobre fallos que real o potencialmente dan como resultado una falta de
disponibilidad ms alta que la acordada.
El problema con los informes de disponibilidad es que las mtricas que se presentan pueden no corresponder
con la percepcin del cliente. Es por lo tanto importante informar sobre la disponibilidad desde el punto de
vista del cliente. El informe debe proporcionar en primer lugar informacin sobre la disponibilidad del
servicio para las funciones esenciales del negocio, los servicios de aplicacin, y la disponibilidad de los
componentes TI tcnicos. Los informes deben redactarse en un lenguaje que el cliente pueda entender.
14.4.7 Desarrollo del Plan de Disponibilidad

El Plan de Disponibilidad es uno de los documentos de ms largo alcance de la Gestin de la Disponibilidad.
Es un plan a largo plazo que tiene que ver con la disponibilidad para los prximos aos. No es un plan de
implementacin para la Gestin de la Disponibilidad.
El plan debera ser un documento vivo. Primero debera poner de manifiesto la situacin actual y en una etapa
futura se puede expandir para incluir actividades de mejora de los servicios y premisas existentes. Un plan
extenso y preciso requiere una cooperacin entre reas tales como la Gestin de Niveles de Servicio, la
Gestin de Continuidad de Servicios TI, la Gestin de la Capacidad, y la Gestin Financiera para los servicios
TI y el Desarrollo de Aplicaciones (en forma directa o a travs de la Gestin de Cambios).
14.4.8 Herramientas
Para ser eficaces, la Gestin de la Disponibilidad debe contar con un nmero de herramientas para las
siguientes actividades:
-
150
Determinacin del Tiempo de Parada

Registro de informacin histrica
Generacin de informes
Anlisis estadstico
Anlisis de impacto
La Gestin de la Disponibilidad utiliza la informacin de los registros de la Gestin de Incidentes, la CMDB y

la Base de Datos de Capacidad. La informacin se puede guardar en una Base de Datos de Gestin de la
Capacidad (AMDB) dedicada.
14.4.9 Mtodos y tcnicas

Ahora hay un amplio espectro de mtodos y tcnicas de Gestin de la Disponibilidad para la planificacin del
soporte, mejora e informacin. Ms adelante se discuten los ms importantes.
Anlisis de Impacto del Fallo de Componente (CFIA)
Este mtodo utiliza una matriz de disponibilidad con componentes estratgicos y sus roles en cada servicio.
Una CMDB eficaz, que define las relaciones entre servicios y recursos de produccin puede ser de utilidad
cuando se desarrolla esta matriz.
Un ejemplo de una matriz CFIA en la Figura 14.4 muestra que los Item de Configuracin que se marcan con
una "X" para muchos servicios son elementos importantes de la infraestructura TI (anlisis horizontal), y los
servicios que se marcan con frecuencia con "X" son complejos y sensibles a fallos (anlisis vertical). Este
mtodo tambin se puede aplicar a terceros (CFIA Avanzada).
Elemento de Configuracin:
PC #1
PC #2
Cable M
Cable #2
Outlet #1
Outlet #2
Segmento Ethernet
Router
Vnculo WAN
Router
Segmento
NIC
5ervdor
Sistema de software
Aplicacin
Base de datos
Servicio A
B
B
X
X
X
X
X
X
A
B
B
B
X
Servicio B
B
B
B
B
X
X
X
X
X
X
X
A
B
B
B
X
X = La falla significa que el sistema no est disponible

A = Configuracin autoprotectiva (Failsafe)
B = Autoprotectivo (Failsafe), con tiempo de alteracin
" " = Sin impacto
Figura 14.4 Matriz CFIA (Fuente: OGC)
Anlisis del rbol de Fallos (FTA)

El Anlisis del rbol de Fallos es una tcnica que se usa para identificar la cadena de eventos que producen el
fallo de un servicio.
Se disea un rbol de Fallos separado para cada servicio, utilizando smbolos Boolean. El rbol de Fallos se
atraviesa desde abajo hacia arriba.
El FTA distingue los siguientes eventos:
-
Eventos bsicos - entradas en el diagrama (crculos) como falta de energa y errores de los operadores.
Estos eventos no se investigan.
Eventos de resultado - nodos en el diagrama, resultado de una combinacin de eventos anteriores.
Eventos condicionales - los eventos que se producen bajo ciertas condiciones, como fallo del aire
acondicionado.
Eventos gatillo - eventos que provocan otros eventos, como un cierre automtico iniciado por un UPS.
151
Figura 14.5 Anlisis de Falla TREE (fuente: OGC)
Eventos que se pueden combinar con operaciones lgicas como:

- Operacin AND - el Evento de Resultado ocurrir si todas las entradas se producen al mismo tiempo.
- Operacin OR - el Evento de Resultado ocurrir si se presentan una o ms de las entradas.
- Operacin XOR - el Evento Resultante se producir si se presenta solo una de las entradas.
- Operacin de inhibicin/represin - el Evento Resultante ocurrir si no se cumplen las condiciones de
entrada.
Anlisis de Riesgo CCTA y Mtodo de Gestin (CRAMM)
Este mtodo se trata en el captulo sobre Gestin de Continuidad de Servicios T I.
152

Clculos de Disponibilidad
Las mtricas que se discuten ms arriba se pueden utilizar para concretar los acuerdos de disponibilidad de
servicio con el cliente. Estos acuerdos se incluyen en el Acuerdo de Nivel de Servicio.
La formula que se muestra a continuacin se puede utilizar para determinar si la disponibilidad alcanzada
cumple con los requisitos de disponibilidad acordados.
% Disponibilidad =
AST DT
100%
AST
Figura 14.6 Formula de disponibilidad (fuente: OCC)
Los montos de Tiempo de Disponibilidad alcanzados para la diferencia entre el Tiempo de Disponibilidad
Acordado (Agreed Service Time, AST) y Tiempo de Parada Actual durante el Tiempo de Disponibilidad
Acordado (Actual Downtime during agreed service time, DT).
Ejemplo: se acord que el servicio puede tener un 9 8% de disponibilidad los das de la semana entre las
07:00 y las 19:00 horas, y el servicio no funcion durante dos horas durante esta ventana, entonces el Tiempo
de Disponibilidad alcanzado (porcentaje de disponibilidad) sera:
(5 12) 2
100% = 96.7%
(5 12)
Anlisis de Interrupcin de Servicio (SOA)
SOA es una tcnica que puede emplearse para identificar las causas de los fallos para investigar la eficacia de
la organizacin TI y sus procesos, y para presentar e implementar las propuestas de mejoras.
Las caractersticas de un SOA son:
-
Tiene un alto alcance ya que no se limita a la infraestructura, tambin cubre procesos, procedimientos y
aspectos culturales.
Los temas se consideran desde la perspectiva del cliente.
Se implementa junto con los representantes del cliente y la organizacin TI {equipo SOA).
Los beneficios incluyen un planteamiento ms eficaz, unas comunicaciones directas con el cliente y el
abastecedor; y una base ms amplia para las propuestas de mejora.
Observacin de Tcnicas Post (TOP)
Cuando se usa el mtodo TOP, un equipo TI de especialistas dedicados pone toda su atencin en un solo
aspecto de la disponibilidad. Este mtodo puede ser til cuando las herramientas de rutina no proporcionan el
soporte necesario. El TOP tambin puede combinar la experiencia de los diseadores y de los gestores de
sistema.
Los aspectos clave de este mtodo son un planteamiento eficaz, efectivo e informal que ofrece resultados
rpidamente.
153

14.5.1 Presentacin de Informes
Ms arriba se mencionaron los informes de disponibilidad a entregar al cliente. Se puede informar sobre las
siguientes mtricas para el control del proceso:
-
Tiempo de deteccin
Tiempos de respuesta
Tiempos de reparacin
Tiempos de recuperacin
Uso exitoso de los mtodos correctos (CFIA, CRAMM, SOA)
Tiempo del procesado de implementacin: servicios, SLAs, y grupos de clientes cubiertos por los SLAs
Algunas mtricas se pueden determinar para cada servicio, equipo o dominio de infraestructura (red, centro de
proceso de datos, y entorno de la estacin de trabajo).

Los factores de xito crtico de la Gestin de la Disponibilidad son:
-
El negocio debe haber definido claramente los objetivos y deseos de disponibilidad.

Se debe haber constituido la Gestin de Niveles de Servicio para formalizar los acuerdos.
Ambas panes deben usar las mismas definiciones de disponibilidad y Tiempo de Parada.
El negocio y la organizacin TI deben ser conscientes de los beneficios de la Gestin de la Disponibilidad.
Los siguientes indicadores de rendimiento muestran la eficacia y eficiencia de la Gestin de la Disponibilidad:

-
Porcentaje de disponibilidad (uptime) por servicio o grupo de usuarios

Duracin del Tiempo de Parada
Frecuencia del Tiempo de Parada

La organizacin puede establecer el rol del Gestor de Disponibilidad para definir el control y el proceso. La tarea del
Gestor de Disponibilidad podra incluir los siguientes elementos:
-
154
Definir y desarrollar el proceso en la organizacin.

Garantizar que los servicios TI se diseen para los niveles de servicio alcanzados (en trminos de disponibilidad,
fiabilidad, utilidad, mantenimiento y recuperacin) se correspondan con los niveles de servicio acordados.
Producir informes.
Optimizar la disponibilidad de la infraestructura TI para proporcionar una mejora del coste del servicio para el
negocio.

14.6.1 Problemas
Muchos problemas tienen que ver con la organizacin. Los problemas a esperar incluyen:
-
La gestin senior divide la responsabilidad de la disponibilidad entre muchas disciplinas (gestores de

lnea, de proceso).
Cada gestor se siente responsable de su propia rea, y no existe coordinacin total.
La gestin TI no entiende el valor agregado que se proporciona a los procesos de Gestin de Incidentes,
Problemas, Cambios.
Se considera suficiente el nivel de disponibilidad actual.
No hay apoyo para designar un nico gestor responsable de proceso.
El gestor de proceso no tiene la autoridad necesaria.
An con apoyo suficiente de la gerencia, todava pueden haber problemas debido a:

-
Infravaloracin de los recursos.

Falta de herramientas de medicin eficaces y de elaboracin de informes.
Falta de otros procesos tales como Gestin de Niveles de Servicio, Gestin de Configuraciones, y
Gestin de Problemas.
Estos problemas se pueden solucionar con un buen apoyo de gestin, con la persona correcta con
responsabilidad total sobre el proceso, con herramientas apropiadas y con la resolucin rpida y eficaz de los
problemas existentes.
Si no se utiliza como corresponde a la Gestin de la Disponibilidad se pueden presentar los siguientes
problemas:
-
Ser difcil definir los estndares de disponibilidad apropiados.

Ser ms difcil guiar a los abastecedores internos y externos.
Ser difcil comparar los costes de disponibilidad y falta de disponibilidad.
Si durante la etapa de diseo no se consideraron los estndares de disponibilidad, la posterior
modificacin para alcanzar estos estndares puede resultar mucho ms cara.
No se cumple con los estndares de disponibilidad y se pueden provocar fallos al intentar alcanzar los
objetivos comerciales.
Puede disminuir la satisfaccin del cliente.
Apuntar a una disponibilidad excesiva es otro problema potencial. Los costes se elevarn mucho de una
manera no proporcional a los beneficios. Siempre habr posibilidad de que exista Tiempo de Parada. La
Gestin de la Disponibilidad juega un rol importante para resolver estos eventos no deseables.
155
14.6.2 Costes
Los costes de la Gestin de la Disponibilidad son:
-
Coste de implementacin
Costes de personal
Costes de instalacin
Herramientas de medicin y elaboracin de informes
La Gestin de la Disponibilidad debe identificar las inversiones necesarias para mejora la disponibilidad en
etapas tempranas. Se debe realizar un anlisis coste beneficio en todos los casos. En general, los costes
aumentarn cuando aumente la disponibilidad requerida. Encontrar una solucin ptima es una tarea
importante de la Gestin de la Disponibilidad. La experiencia muestra que lo ptimo se puede alcanzar ms a
menudo con recursos limitados que con una gran inversin.
La discusin sobre costes y beneficios puede guiarse preguntando cules sern los costes si se ignora por
completo a la Gestin de la Disponibilidad y se llega a una situacin en la que no se cumple con los requisitos
de disponibilidad acordados. Esto tendr el siguiente impacto en el cliente:
-
Productividad reducida
Rotacin y ganancia reducida
Costes de recuperacin
Demandas potenciales de terceros, etc.
Los siguientes aspectos son difciles de cuantificar pero resultan igualmente importantes:
-
Prdida de buena voluntad y clientes

Prdida de reputacin y confianza
Prdida de motivacin y satisfaccin del personal
El proceso de la Gestin de !a Disponibilidad puede contribuir a los objetivos de la organizacin TI en estas

reas proporcionando los servicios requeridos a un coste aceptable y justificable.
156
Captulo 15:
15.1 Introduccin
Los procesos del negocio ya no pueden operar sin la provisin de informacin. De hecho, cada vez ms
procesos del negocio consisten puramente de uno o ms sistemas de informacin. La Gestin de la Seguridad
de la Informacin es una actividad importante que tiene como objetivo controlar la provisin de informacin
y prevenir el uso sin autorizacin de la misma.
Durante muchos aos, se ignor a la Gestin de la Seguridad de la Informacin. Sin embargo, esto est
cambiando. La seguridad es considerada como uno de los principales desafos para los prximos aos.
Dado el amplio uso de Internet y del e-commerce est aumentando el inters en esta disciplina. Cada vez ms
negocios abren gateways electrnicos en sus instalaciones. Esto introduce el riesgo de intrusin y plantea
algunas preguntas importantes para el negocio. Qu riesgos queremos cubrir, y qu medidas se deben tomar
ahora y en el prximo presupuesto? La gestin profesional debe tomar decisiones y tales decisiones slo se
pueden tomar si se lleva acabo un completo anlisis del riesgo. Este anlisis debe servir a la Gestin de la
Seguridad para determinar los requisitos de sta.
Los requisitos de seguridad del negocio afectan a los proveedores de servicio TI y se deberan especificar en
los Acuerdos de Nivel de Servicio. La Gestin de la seguridad apunta a garantizar que se provean, en todo
momento, los aspectos de seguridad de los servicios al nivel que se acord con el cliente. La seguridad es
ahora un aspecto de calidad esencial de la gestin.
La Gestin de la Seguridad integra la seguridad en la organizacin desde el punto de vista del proveedor de
servicio. El Cdigo de Buenas Prcticas para la Gestin de la Seguridad de la Informacin (BS 7799) ofrece
una gua para desarrollar, introducir y evaluar las medidas de seguridad.
15.1.1 Conceptos Bsicos

La Gestin de la Seguridad se desarrolla bajo el paraguas de la Seguridad de Informacin que tiene como objetivo
garantizar la seguridad de sta. Seguridad se refiere a no ser vulnerable a los riesgos conocidos y a evitar los errores
conocidos cuando sea posible. El objetivo es proteger el valor de la informacin. Este valor depende de la
confidencialidad, integridad y disponibilidad.
-
Confidencialidad - proteger informacin contra el acceso y uso no autorizado.

Integridad - tener la informacin exacta, completa y a tiempo.
Disponibilidad - disponer de acceso a la informacin en el momento acordado. Esto depende de la continuidad que
brinden los sistemas de procesamiento de informacin.
Los aspectos secundarios incluyen la privacidad (confidencialidad, e integridad de la informacin relacionada con los
individuos), el anonimato, y la verificacin (poder verificar que la informacin se utiliza de manera correcta y que las
medidas de seguridad son eficaces).
15.2 Objetivos
En dcadas recientes, casi todos los negocios se han vuelto ms dependientes de los sistemas de informacin.
El uso de las redes tambin ha crecido, no slo dentro de los negocios sino tambin entre ellos, y entre los
negocios y el mundo exterior. La complejidad en aumento de la infraestructura TI implica que los negocios
ahora son ms vulnerables a fallos tcnicos, errores humanos, actos humanos malintencionados, hackers y
crackers, virus de ordenadores, etc. Esta creciente complejidad necesita un planteamiento de gestin
unificado. La Gestin de la Seguridad tiene vnculos con los otros procesos. Algunas actividades de seguridad
son realizadas por otros procesos ITIL, bajo la supervisin de la Gestin de la Seguridad.
157
La Gestin de la Seguridad tiene dos objetivos:
-
Cumplir con los requisitos de seguridad de los SLAs y con otros requisitos externos relacionados con
contratos, legislacin, y polticas impuestas desde el exterior.
Brindar Proporcionar un nivel de seguridad bsico, independiente de los requisitos externos.
La Gestin de la Seguridad es esencial para mantener la operatividad de la organizacin TI sin interrupciones.

Tambin ayuda a simplificar la Gestin de Niveles de Servido de la Seguridad de la Informacin, ya que es
mucho ms difcil manejar gran cantidad de diferentes SLAs que un nmero limitado.
Los SLAs especifican los requisitos de seguridad, complementados con documentos sobre polticas y otros
requisitos externos. El proceso tambin recibe informacin sobre temas de seguridad de otros procesos, como
por ejemplo de los incidentes de seguridad.
Las salidas de los SLAs incluyen informacin sobre la implementacin alcanzada, sobre los informes de
excepcin y sobre el planeamiento de seguridad de trabajo habitual.
En el presente muchas organizaciones tratan la seguridad de la informacin a nivel estratgico con polticas
de informacin y planes de informacin, y a nivel de operaciones comprando herramientas y otros productos
de seguridad. Se presta poca atencin a la gestin activa de la seguridad de la informacin, al anlisis
continuo, a la traduccin de polticas en opciones tcnicas, y a la certeza de que las medidas de seguridad
siguen siendo eficaces cuando cambian los requisitos y el entorno. La consecuencia de este vnculo perdido
entre el nivel estratgico y el tctico es que a nivel de gestin tctica se realizan importantes inversiones en
medidas que ya nos son relevantes, en el momento en que se deberan tomar medidas ms eficaces. La
Gestin de la Seguridad tiene como objetivo garantizar que se tomen medidas eficaces en la Seguridad de la
Informacin a niveles tcticos, estratgico y de operacin.
15.2.1 Beneficios
La Informacin no es un objetivo en s mismo, sino que tiende a servir a los intereses del negocio u
organizacin. Algunas informaciones y algunos servicios de informacin sern ms importantes que otros
para la organizacin. Una seguridad a medida se desarrolla al equilibrar las medidas de seguridad y el valor de
la informacin, y las amenazas del ambiente de procesamiento. Una provisin de informacin eficaz, con
seguridad de la informacin correcta es importante para la organizacin por dos razones:
-
Razones internas - una organizacin slo puede operar eficazmente si dispone cuando corresponde de la
informacin correcta y completa. El nivel de la seguridad de la informacin debe ser apropiado para esto.
Razones externas - los procesos en una organizacin crean productos y servicios que se ponen a
disposicin del mercado o sociedad para lograr objetivos definidos. Si no se dispone de la informacin
correcta, se ofrecern subproductos y servicios que no podrn utilizarse para alcanzar los objetivos y que
amenazarn la supervivencia de la organizacin. Una adecuada Seguridad de la Informacin es una
condicin importante para disponer de una provisin de informacin adecuada. La importancia de la
Seguridad de la Informacin externa por lo tanto, est determinada en parte por la importancia interna.
La Seguridad puede brindar un importante valor agregado a un sistema de informacin. Una seguridad eficaz
contribuye a la continuidad de la organizacin y ayuda a alcanzar sus objetivos.
15.3 El Proceso
La organization y sus sstemas de informacin cambian. Las listas de verificacin tales como el Cdigo de
Prcticas de la Gestin de la Seguridad de la Informacin son estticas y recomiendan de manera insuficiente
cambios rpidos en TT. For tal razn, las actvidades de la gestin de la seguridad se deben revisar
condnuamente para garantizar su eficacia. La Gestin de la Seguridad viene a ser un ciclo sin fin de
planificar, hacer, chequear y actuar. Mas adelante, se tratan las actividades que desarrolla la Gestin de la
Seguridad, o en otros procesos bajo el control de sta.
158
Figura 15.1 Proceso de la Gestin de la Seguridad (fuente: OGC)
La Figura 15.1 muestra el ciclo de la Gestin de la Seguridad. Los requerimientos del cliente aparecen en el
margen superior derecho, como entrada del proceso. La seccin de seguridad del Acuerdo de Nivel de
Seguridad define estos requerimientos en trminos de los servicios de seguridad y del nivel de seguridad a
proporcionar. El proveedor de servicio comunica estos acuerdos a la organizacin en forma de Plan de
Seguridad, definiendo los estndares de seguridad y los Acuerdos de Nivel de Operaciones. Se implementa el
plan y se evala la implementacin. Posteriormente, se actualizan. La Gestin de Niveles de Servicio informa
a los clientes sobre estas actividades.
As, el cliente y el proveedor de servicios forman un proceso cclico completo. El cliente puede modificar los
requisitos en base a los informes y el proveedor de servicio puede ajustar el plan o su implementacin
teniendo en cuenta estas observaciones o puede intentar cambiar los acuerdos que define el SLA. La funcin
de control aparece en el medio de la Figura 15.1, este diagrama se utilizar aqu para discutir las actividades
de la Gestin de la Seguridad.
15.3.1 Relaciones con los otros procesos

La Gestin de la Seguridad tiene relacin con los otros procesos ITIL (ver Figura 1 5.2). Esto es porque los
otros procesos llevan a cabo actividades relacionadas con la seguridad. Estas actividades se desarrollan
normalmente bajo la responsabilidad de los procesos pertinentes y del gestor de proceso.
Sin embargo, la Gestin de la Seguridad da instrucciones a los otros procesos sobre la estructura de las
actividades relacionadas con la seguridad. Por lo general, estos acuerdos se definen tras una consulta entre el
Gestor de Seguridad y los otros gestores de proceso.
159
Figura 152 Relaciones de la Gestin de la Seguridad con los otros procesos (fuente: OCC)
En el contexto de Seguridad de Informacin, la Gestin de Configuraciones es en primera instancia relevante

porque puede clasificar los tems de Configuracin (CI). Esta clasificacin vincula la CI con las medidas de
seguridad o procedimientos.
La clasificacin de un CI indica su confidencialidad, integridad y disponibilidad necesaria. Esta clasificacin
se basa en los registros de seguridad del SLA. El cliente de la organizacin TI determina la clasificacin ya
que solo el cliente puede decidir cun importante es la informacin o los sistemas de informacin para el
negocio. El cliente basa la clasificacin en el anlisis de hasta qu grado los procesos del negocio dependen
del sistema de informacin y de la informacin. Despus, la organizacin asocia la clasificacin con las CIs
que corresponda. La organizacin TI tambin debe implementar este conjunto de medidas de seguridad para
cada nivel de clasificacin.
Este conjunto de medidas se puede describir en los procedimientos. Ejemplo: "Procedimiento para manejar el
almacenamiento de datos a publicar con datos de personal". El SLA puede definir los conjuntos de medidas
de seguridad para cada nivel de clasificacin.
El sistema de clasificacin debe adaptarse siempre a la organizacin de clientes. Sin embargo, para simplificar
la gestin es aconsejable utilizar un sistema de clasificacin unificado, an si la organizacin TI tiene ms de
un cliente.
En resumen, la clasificacin es un tema clave. La CMDB debera indicar la clasificacin de cada CI. Esta
clasificacin vincula al CI con el conjunto de medidas de seguridad o procedimiento que corresponde.
La Gestin de Incidentes es un proceso importante para informar sobre los incidentes de seguridad.
Dependiendo de la naturaleza del incidente, los incidentes de seguridad pueden estar cubiertos por un
procedimiento distinto que los otros. Por lo canto, es esencial que la Gestin de Incidentes reconozca los
incidentes como tales.
Cualquier incidente que pueda interferir con el alcance de los requisitos de seguridad del SLA se clasifica
como incidente de seguridad. Resulta til incluir en el SLA una descripcin del tipo de incidentes a considerar
como incidente de seguridad.
Cualquier incidente que interfiera en el logro del nivel de seguridad bsico interno (lnea de referencia)
cambien se clasifica como incidente de seguridad.
Los usuarios no son los nicos que generan informes de incidentes. El proceso de gestin, posiblemente en
base a las alarmas o los datos de auditora de los sistemas Cambien genera informes.
160
Resulta imprescindible que la Gestin de Incidentes reconozca todos los incidentes de seguridad para
garantizar el comienzo de los procedimientos correctos para tratar stos. Es aconsejable incluir los
procedimientos para los diferentes tipos de incidentes de seguridad en los planes SLA y practicar el
procedimiento. Adems, es aconsejable acordar un procedimiento para comunicar la sucesin de stos. Es
comn que haya pnico por rumores desproporcionados. De igual manera, es comn que el dao resulte de un
fallo en comunicar a tiempo los incidentes de seguridad. Es aconsejable dirigir todas las comunicaciones
externas a travs del Gestor de Seguridad.
Gestin de Problemas
Gestin de Problemas es responsable de identificar y solucionar los fallos de seguridad estructurales.
Un problema tambin puede introducir un riesgo de seguridad. En ese caso, la Gestin de Problemas debe
incluir a la Gestin de la Seguridad para resolver el problema. Finalmente, la solucin o el workaround del
problema o error conocido se deben evaluar siempre para garantizar que no introduzca nuevos problemas de
seguridad. Esta verificacin se debe basar en el cumplimiento del SLA y en los requisitos de seguridad
interna.
Gestin de Cambios
Las actividades de la Gestin de Cambios generalmente se encuentran asociadas con la seguridad porque la
Gestin de Cambios y de la Seguridad son interdependientes. Si se ha alcanzado un nivel de seguridad
aceptable, y se maneja con el proceso de Gestin de Cambios, se puede garantizar que el mismo nivel de
seguridad se proporcionar despus de los cambios. Hay un nmero de operaciones estndar para garantizar el
mantenimiento de este nivel de seguridad. Cada RFC est asociada con cierta cantidad de parmetros que
gobiernan el proceso de aceptacin. Los parmetros de urgencia e impacto se pueden suplementar con un
parmetro de seguridad. S la RFC puede tener un impacto significativo en la informacin de seguridad
entonces se necesitarn pruebas de aceptacin y procedimiento ms extensos.
La RFC tambin debe incluir una propuesta para tratar los temas de seguridad. Otra vez, se deber basar en
los requisitos SLA y en el nivel bsico de seguridad interna que necesita la organizacin TI. As, la propuesta
incluir un conjunto de medidas de seguridad, basado en el cdigo de prcticas.
Preferentemente, el Gestor de Seguridad (y posiblemente el Oficial de Seguridad del Cliente) debe formar
parte del Consejo Asesor de Cambio (CAB).
Sin embargo, no se debe consultar al Gestor de Seguridad sobre todos los cambios. La seguridad por lo
general debera estar integrada en las operaciones de rutina. El Gestor de Cambios debera poder decidir si
ellos o el CAB necesitan informacin del Gestor de Seguridad. Asimismo, el Gestor de Seguridad no es
necesario que est involucrado en la seleccin de las medidas para las CIs cubiertas por un RFC. Esto es
porque el marco de trabajo de las medidas relevantes ya debera existir. Cualquier pregunta slo debera tener
relacin con la forma en que se implementan stas.
Cualquier medida de seguridad asociada a un cambio se debe implementar al mismo tiempo que ste, y debe
incluirse en las pruebas. Las pruebas de seguridad no son iguales a las evaluaciones normales. Las pruebas
normales tienden a investigar si las funciones definidas estn disponibles.
Las pruebas de seguridad, adems de mencionar la disponibilidad de las funciones de seguridad, tambin
mencionan la ausencia de otras funciones no deseables ya que podran reducir la seguridad del sistema.
En trminos de seguridad, la Gestin de Cambios es uno de los procesos ms importantes ya que esta gestin
introduce nuevas medidas de seguridad a la infraestructura TI al realizar cambios en la misma infraestructura.
161
Gestin de Versiones
Todas las nuevas versiones de hardware, software, equipos de comunicaciones de datos, etc., deben estar
controladas y puestas en funcionamiento por la Gestin de Versiones. Este proceso debera garantizar que:
-
Se utilice el hardware y el software que corresponde.

Se pruebe el hardware y el software antes de usarlos.
La introduccin est correctamente autorizada usando un cambio
El software es legal.
El software est libre de virus y que los virus no se introducen durante la distribucin.
Se conocen los nmeros de versin y que la Gestin de Configuraciones los registr en la CMDB.
El rollout est manejado eficazmente.
Este proceso tambin usa un procedimiento de aceptacin regular que debera incluir aspectos de Seguridad
de Informacin. Es muy importante considerar los aspectos de seguridad durante las pruebas y la aceptacin.
Esto significa que los requisitos y las medidas definidas en el SLA debern cumplirse en todo momento.
La Gestin de Niveles de Servicio garantiza que se definan y se alcancen los acuerdos sobre los servicios a
proveer al cliente. Los Acuerdos de Nivel de Servicio tambin deberan mencionar las medidas de seguridad.
El objetivo es optimizar el nivel de servicio provisto.
La Gestin de Niveles de Servicio incluye cierta cantidad de actividades de seguridad relacionadas, en las que
la Gestin de la Seguridad juega un rol muy importante.
1.
2.
3.
4.
5.
6.
Identificar las necesidades de seguridad del cliente. Naturalmente, determinar las necesidades de
seguridad es responsabilidad del cliente ya que estas necesidades se basan en los intereses del negocio.
Identificar la factibilidad de los requisitos de seguridad del cliente.
Proponer, discutir y definir el nivel de seguridad de los servicios TI en el SLA.
Identificar, desarrollar y definir los requisitos de seguridad internos para los servicios TI (Acuerdos de
Nivel de Operaciones).
Monitorizacin de los estndares de seguridad (OLAs).
Elaborar informes sobre los servicios TI a proveer.
La Gestin de la Seguridad proporciona entrada y soporte a la Gestin de Niveles de Servicio en lo

relacionado con las actividades 1-3. Las actividades 4 y 5 estn a cargo de la Gestin de la Seguridad.
La Gestin de la Seguridad y los otros procesos dan entrada a la actividad 6. El Gestor de Nivel de Servicio y
el de Seguridad deciden juntos quin desarrolla las actividades.
Cuando se define un SLA por lo general se asume que existe un nivel de seguridad general bsico (lnea de
referencia). Los requisitos de seguridad adicionales del cliente se deben especificar en el SLA.
Gestin de la Disponibilidad maneja la disponibilidad tcnica de los componentes TI en relacin a la
disponibilidad del servicio. Se asegura la calidad de disponibilidad por la continuidad, el mantenimiento, y la
resistencia. La Gestin de la Disponibilidad es el proceso ms importante relacionado con la disponibilidad.
Como muchas medidas de seguridad benefician tanto a la disponibilidad como a los aspectos de seguridad
relativos a confidencialidad e integridad, es esencial coordinar eficazmente las medidas entre la Gestin de la
Disponibilidad, la Gestin de Continuidad de Servicios TI y la Gestin de la Seguridad.
La Gestin de la Capacidad es responsable del mejor uso posible de los recursos TI, como se acord con el
cliente. Los requisitos de rendimiento se basan en los estndares cualitativos y cuantitativos definidos por la
Gestin de Niveles de Servicio. Casi todas las actividades de la Gestin de la Capacidad afectan la
disponibilidad y por lo tanto a la Gestin de la Seguridad.
162

La Gestin de Continuidad de Servicios TI garantiza que el impacto de cualquier contingencia se lmite a los
niveles acordados con el cliente. Las contingencias no necesariamente deben derivar en desastres. Las
actividades ms importantes son la definicin, mantenimiento, implementacin, y la prueba del plan de
contingencia as como la toma de medidas preventivas. Dados los aspectos de seguridad, hay vnculos con la
Gestin de la Seguridad. Por otro lado, la falta de cumplimiento de los requisitos de seguridad bsicos pueden
considerarse en si una contingencia.
15.3.2 Seccin Seguridad de los Acuerdos de Nivel de Servicio

El Acuerdo de Nivel de Servicio define los acuerdos con el cliente. El proceso de la Gestin de Niveles de
Servicio es responsable del SLA (ver tambin captulo 10). El SLA es el conductor ms importante de todos
los procesos IT1L.
La organizacin TI indica hasta qu punto se logran los requisitos del SLA. Los elementos de seguridad
mencionados en el SLA deben corresponderse con las necesidades de seguridad del cliente.
El cliente debe identificar el significado de todos los proceso del negocio (ver Figura 15.3).
Figura 15.3 Relaciones entre los procesos (fuente: OGC)
Estos procesos del negocio dependen de los servicios TI, y por ende de la organizacin TI. El cliente
determina los requisitos de seguridad (requisitos de Seguridad de Informacin SLA no incluidos en la Figura
15.3) en base al anlisis de riesgo.
La Figura 15.4 muestra cmo se definen los elementos de seguridad del SLA
163
Figura 15.4 Desarrollo de la seccin de seguridad del SLA
Los elementos de seguridad se discuten entre el representante del cliente y el proveedor de servicio.
El proveedor de servicio compara los Requisitos de Nivel de Servicio de cliente con su propio Catlogo de
Servicios que describe sus medidas de seguridad estndar (Lnea de Referencia de Seguridad). El cliente
puede tener requisitos adicionales.
El cliente y el proveedor comparan los Requisitos de Nivel de Servicio y el Catlogo de Servicios. La seccin
seguridad del SLA puede tratar temas como la poltica general de Seguridad de Informacin, una lista de
personal autorizado, procedimientos de proteccin activos, restricciones sobre el copiado de datos, etc.
15.3.3 Seccin Seguridad del Acuerdo de Nivel de Operaciones

El Acuerdo de Nivel de Operaciones es otro documento importante. Describe los servicios que proporciona el
proveedor de servicios. El proveedor debe asociar estos acuerdos con las responsabilidades dentro de la
organizacin. El Catlogo de Servicios da una descripcin general de los servicios. El Acuerdo de Nivel de
Operaciones traduce estas descripciones generales en todos los servicios y sus componentes, y la manera en la
que se garantizan los acuerdos de niveles de servido dentro de la organizacin.
Ejemplo: el Catlogo de Servicios menciona "manejar las autorizaciones por usuario y por individuo". Los
Acuerdos de Nivel de Operaciones detallan esto para todos los servicios relevantes que brinda la organizacin
TI. De esta manera, se define la implementacin de la medida para los departamentos que proveen servicios
UNIX, VMS, NT, Oracle, etc. Cuando es posible, los Requisitos de Nivel de Servicio del cliente se
interpretan en trminos del Catlogo de Servicios del proveedor, y se realizan acuerdos adicionales si es
necesario. Tales medidas adicionales exceden el nivel de seguridad estndar.
Cuando se disea el SLA, tambin se debe acordar los Indicadores Clave de Rendimiento (KPI) y el criterio
para la Gestin de la Seguridad. Los KPIs son parmetros medibles (mtricas) y se establecen criterios de
rendimiento a niveles alcanzables.
Esto es ms fcil para la disponibilidad porque por lo general se puede expresar en nmeros. Sin embargo, es
mucho ms difcil para la integridad y la confidencialidad. Por tal razn, la seccin seguridad del SLA es
normal que describa las medidas necesarias en trminos abstractos. El Cdigo de Prcticas para Gestin de la
Seguridad de Informacin se utiliza como set bsico de medidas de seguridad. El SLA tambin describe cmo
se mide el rendimiento. La organizacin TI (proveedor de servicio) debe proporcionar con regularidad
informes a la organizacin de usuarios (cliente).
164
15.4 Actividades
15.4.1 Control Poltica y organizacin de la Seguridad de Informacin
La actividad de control en el centra de la Figura 15.4 es el primer subproceso de la Gestin de la Seguridad y
se relaciona con la organizacin y la gestin del proceso. Esto incluye el marco de trabajo de la Gestin de la
Seguridad de la Informacin.
Este marco de trabajo incluye subprocesos: la definicin de los planes de seguridad, su implementacin, la
evaluacin de la implementacin y la incorporacin de la evaluacin en los planes de seguridad anuales
(planes de accin). Tambin se mencionan los informes que se dan al cliente va la Gestin de Niveles de
Servicio.
Esta actividad define el subproceso, las funciones de seguridad, y los roles y responsabilidades. Tambin
describe la estructura de la organizacin, los acuerdos de elaboracin de informes y la lnea de control (quin
instruye a quin, quin hace qu cosa, cmo se informa de la implementacin).
Esta actividad implementa las siguientes medidas del Cdigo de Prcticas.
Polticas
- Desarrollo e implementacin de la poltica, vnculos con las otras polticas.
- Objetivos, principios generales y significado.
- Descripcin de los subprocesos.
- Asignacin de las funciones y responsabilidades en el subproceso.
- Vnculos con otros procesos ITIL y su administracin.
- Responsabilidad general del personal.
- Manejo de los incidentes de seguridad.
Organizacin de la Seguridad de la Informacin:
- Marco de trabajo de la gestin.
- Estructura administrativa (estructura de organizacin).
- Asignacin de responsabilidad con ms detalles.
- Creacin de un Comit de Direccin de Seguridad de la Informacin.
- Coordinacin de la Seguridad de la Informacin.
- Herramientas acordadas (p. ej. para anlisis de riesgo y mejora de conocimiento).
- Descripcin del proceso de autorizacin de las instalaciones TI consultando al cliente.
- Consejo de especialistas.
- Cooperacin entre organizaciones, comunicaciones internas y externas.
- Auditora de los Sistemas de Informacin independientes.
- Principios de seguridad para acceso de terceros.
- Informacin de Seguridad en los contratos con terceros.
15.4.2 Plan
El subproceso de planificacin incluye definir la seccin de seguridad del SLA junto con la Gestin de
Niveles de Servicio, y las actividades en los Contratos de Apoyo relacionados con la seguridad.
Los objetivos en el SLA, que se definen en trminos generales, se detallan y se especifican en un Acuerdo de
Nivel de Operaciones. Un OLA puede ser considerado como el plan de seguridad de una unidad de
organizacin del proveedor de Servicio y como un plan de seguridad especfico, por ejemplo para cada
plataforma TI, aplicacin y red.
El subproceso de planeamiento no slo recibe entradas del SLA sino tambin de los principios de poltica de
proveedor (del subproceso de Control). Ejemplos de estos principios incluyen:
165
"Cada usuario debe ser identificable como nico", y "Se brinda un nivel de seguridad bsico a todos los
clientes en todo momento".
Los Acuerdos de Nivel de Operaciones para la Seguridad de la Informacin (planes de seguridad especficos)
se disean y se implementan utilizando los procedimientos normales. Esto significa que si se necesitan
actividades en otros procesos, tendr que haber coordinacin con estos procesos.
Cualquier cambio necesario a la infraestructura TI los realiza la Gestin de Cambios usando las entradas que
le da la Gestin de la Seguridad. El Gestor de Cambios es el responsable del proceso de Gestin de Cambios.
El subproceso de Planificacin se discute con la Gestin de Niveles de Servicio para definir, actualizar y
cumplir con la seccin de seguridad del SLA. El Gestor de Nivel de Servicio es responsable de esta
coordinacin.
El SLA debe definir los requisitos de seguridad, si es posible en trminos medibles. La seccin seguridad del
acuerdo debera garantizar que todos los requisitos y estndares de seguridad del cliente puedan ser
alcanzados y verificados.
15.4.3 Implementar
El subproceso de implementacin tiene como objetivo implementar todas las medidas especificadas en los
planes. Este subproceso puede contar con la ayuda de la siguiente lista de verificacin:
Clasificacin y Gestin de los recursos TI:
- Dar entradas para mantener las CIs en el CMDB.
- Clasificar los recursos TI de acuerdo con las lneas bsicas acordadas.
Seguridad Personal:
- Tareas y responsabilidades en las descripciones del trabajo.
- Screening.
- Acuerdos de confidencialidad para el personal.
- Formacin.
- Guas para el personal que maneja incidentes de seguridad y observa debilidades en seguridad.
- Medidas disciplinarias.
- Mayor conocimiento de seguridad.
Administrando la seguridad:
- Implementacin de las responsabilidades, implementacin de la separacin del trabajo.
- Instrucciones de operacin escritas.
- La seguridad debe incluir el ciclo de vida entero, debera haber guas de referencia para el desarrollo del
sistema, la prueba, aceptacin y operaciones de mantenimiento y eliminacin.
- Separacin de los ambientes de desarrollo y de pruebas de produccin.
- Procedimientos para tratar los incidentes (manejados por la Gestin de Incidentes).
- Implementacin de las instalaciones de recuperacin.
- Dar entradas a la Gestin de Cambios.
- Implementacin de medidas de proteccin contra virus.
- Implementacin de medidas de administracin para ordenadores, aplicaciones, redes y servicios de red.
- Manejo y seguridad de los datos a publicar.
Control de Acceso:
- Implementacin de la poltica de acceso y del control de acceso.
- Mantenimiento de los privilegios de acceso de los usuarios y las aplicaciones para redes, servicios e red,
ordenadores y aplicaciones.
- Mantenimiento de barreras de seguridad para la red (firewalls, servicios de discado, puentes y routers).
- Implementacin de medidas para la identificacin y autentificacin de los sistemas informticos,
estaciones de trabajo y PCs de la red.
166
15.4.4 Evaluar
Es esencial la evaluacin independiente de la implementacin de las medidas planeadas. Esta evaluacin es
necesaria para evaluar el rendimiento. Los resultados del subproceso de evaluacin pueden usarse para
actualizar las medidas acordadas con el cliente, y tambin pata su implementacin.
Los resultados de la evaluacin pueden sugerir cambios y en ese caso se define y se eleva una RFC al proceso
de Gestin de Cambios. Hay tres formas de evaluacin:
-
Auto-evaluaciones que se implementan primero por la lnea de organizacin de los procesos.

Auditoras internas llevadas a cabo por el auditor.
Auditoras externas llevadas a cabo por auditores externos.
A diferencia de las autoevaluaciones, las auditoras no son realizadas por el mismo personal que desempea
los otros subprocesos. Esto garantiza que se separen las responsabilidades. Las auditoras tambin pueden ser
hechas por un departamento de Auditora Interna.
Tambin se hacen evaluaciones cuando se producen incidentes de seguridad.
Las principales actividades son:
-
Verificacin del cumplimiento de la poltica de seguridad y la implementacin de los planes de

seguridad.
Desarrollo de auditoras de seguridad de los sistemas TI.
Identificacin y respuesta al uso inapropiado de los recursos TI.
Encargarse Responsabilizarse de los aspectos de seguridad de las otras auditoras TI.
15.4.5 Mantenimiento
La seguridad necesita mantenimiento, en tanto los riesgos cambian debido a los cambios en la infraestructura
TI, tambin lo hacen la organizacin y los procesos del negocio.
El mantenimiento de seguridad incluye el mantenimiento de la seccin de seguridad del SLA y el
mantenimiento de los planes de seguridad detallados (Acuerdos de Nivel de Operaciones).
El mantenimiento se lleva a cabo con base en los resultados del subproceso de Evaluacin y a una evaluacin
de los cambios en los riesgos.
Estas propuestas pueden introducirse en el subproceso de Planificacin o incluirse en el mantenimiento del
SLA como un todo.
En cualquier caso, las propuestas se pueden incluir en las actividades del plan de seguridad anual. Todos los
cambios estn sujetos al proceso normal de la Gestin de Cambios.
15.4.6 Presentacin de Informes

La presentacin de informes no es un subproceso, sino una produccin de los otros subprocesos.
Los informes se hacen para dar informacin sobre el rendimiento de seguridad alcanzado y para informar a
los clientes sobre temas de seguridad. Estos informes, por lo general, se piden bajo acuerdo con el cliente. La
presentacin de informes es importante, para el cliente y el proveedor de servido.
Los clientes deben estar bien informados sobre la eficacia y los esfuerzos (p. ej. con respecto a la
implementacin de medidas de seguridad) y la medidas de seguridad reales.
El cliente tambin debe tener informacin sobre los incidentes de seguridad.
167
A continuacin se incluye una lista con algunas sugerencias de opcin de informe:
El subproceso de Planificacin
- Informes sobre el grado de cumplimiento del SLA y los Indicadores de Rendimiento Clave acordados
para la seguridad.
- Informes sobre los Contratos de Apoyo y cualquier problema asociado a ellos.
- Informes sobre Acuerdos de Nivel de Operaciones (planes de seguridad internos) y los principios de
seguridad del proveedor (p. ej. en la lnea de referencia).
- Informes sobre los planes de seguridad anuales y los planes de accin.
- Implementacin del subproceso
- Informes de estado sobre la implementacin de la Seguridad de Informacin. Esto incluye informes de
progreso sobre la implementacin del plan de seguridad anual, posiblemente una lista de medidas que han
sido implementadas o estn por serlo, capacitacin, produccin de anlisis de riesgo adicionales, etc.
- Lista de incidentes de seguridad y respuestas a esos incidentes, en forma opcional una comparacin con
el periodo anterior de informes
- Identificacin de las tendencias en los incidentes.
- Estado del programa de conocimiento.
Subproceso de Evaluacin
- Informes sobre el rendimiento de los subprocesos.
- Resultados de las auditoras, revisiones y evaluaciones internas.
- Peligros, identificacin y amenazas nuevas.
Informes especficos
Para informar sobre los incidentes de seguridad definidos en el SLA, el proveedor de servicio debe contar con
un canal de comunicacin directo con el representante del cliente (posiblemente el Oficial de Seguridad de
Informacin Corporativo) a travs del Gestor de Nivel de Servicio, de Incidente o el Gestor de Seguridad.
Tambin se debe definir un procedimiento para comunicarse en circunstancias especiales.
Aparte de la excepcin en caso de circunstancias especiales, los informes se comunican a travs de la Gestin
de Niveles de Servicio.

Los factores de xito crtico son:
-
Compromiso y participacin total de la gerencia

Participacin del usuario en el desarrollo del proceso
Responsabilidades claras y separadas
Los indicadores de rendimiento de la Gestin de la Seguridad se corresponden con los de la Gestin de

Niveles de Servicio, en tanto que stos se relacionan con los temas de seguridad cubiertos en el SLA.

En las organizaciones TI pequeas, una misma persona puede hacerse cargo de muchos procesos.
En grandes organizaciones, muchas personas trabajarn para un proceso, como por ejemplo en la Gestin de la Seguridad.
En este caso, se nombra a una persona Gestor de Seguridad. El Gestor de Seguridad es responsable por la operacin eficaz
del proceso de la Gestin de la Seguridad. En la organizacin del cliente este cargo le pertenece al Oficial de Seguridad de
Informacin o al Oficial Corporativo de Seguridad de Informacin.
168

15.6.1 Problemas
Los siguientes temas son esenciales para la exitosa implementacin de la Gestin de la Seguridad:
Compromiso - las medidas de seguridad por lo general no cuentan con aceptacin inmediata, es ms
comn la resistencia que la aceptacin. A los usuarios no les gusta perder ciertos privilegios por las
medidas de seguridad, an si estas comodidades no son esenciales para su trabajo. Esto es as porque los
privilegios les proporcionan cierto estatus. Se deber realizar un esfuerzo especial para motivar a los
usuarios, y para garantizar el cumplimiento de las medidas de seguridad. En el campo de la Gestin de la
Seguridad en especial, la Gerencia debe ser un ejemplo ("mostrar el camino" y "dar el ejemplo"). Si no
hay incidentes de seguridad, la gestin puede verse tentada a reducir el presupuesto de la Gestin de la
Seguridad.
Actitud - los sistemas de informacin no son inseguros por las debilidades tcnicas, sino por los fallos al
usar la tecnologa. Esto por lo general se relaciona con la actitud y el comportamiento humano. Ello
significa que los procedimientos de seguridad se deben integrar a las operaciones de rutina.
Conocimiento - el conocimiento, o la comunicaciones es un concepto clave. A veces puede parecer un
conflicto de intereses entre la comunicacin y la seguridad las comunicaciones hacen el camino
mientras que la seguridad pone obstculos. Esto significa que la implementacin de las medidas de
seguridad necesitan del uso de todos los mtodos de comunicaciones para garantizar que los usuarios
adopten el comportamiento requerido.
Verificacin - es posible chequear y verificar la seguridad. Esto hace referencia a las medidas
introducidas, y a las razones necesarias para tomar esas medidas. Sera posible verificar que se han
tornado las decisiones correctas en ciertas circunstancias.
Gestin de Cambios - frecuentemente, la verificacin del cumplimiento continuo eficaz del nivel bsico
de seguridad desaparece con el tiempo cuando se evalan los cambios.
Ambicin - cuando una organizacin quiere hacer todo a la vez, se cometen errores. Cuando se introduce
la Gestin de la Seguridad, la implementacin de las medidas de organizacin es mucho ms importante
que las medidas tcnicas. Modificar una organizacin necesita un planteo gradual y llevar tiempo.
Falta de sistemas de deteccin - los sistemas nuevos como Internet no fueron diseados para la
deteccin de intrusin. Esto se debe a que el desarrollo de un sistema seguro lleva ms tiempo que
desarrollar uno inseguro y est en pugna con los requisitos del negocio de coste de desarrollo bajos y de
poco tiempo en el mercado.
Demasiada confianza en las tcnicas de fuerte/fortaleza - es cada vez ms comn que las amenazas de
seguridad vengan de lugares no anticipados. Considere el primer ataque con los virus ILOVEYOU y
Nimda, y la primera instancia de los ataques de Denegacin de Servicio (DOS). Es verdad que es muy
importante proteger los activos de informacin con planteamientos tradicionales fuerte/fortaleza, pero
tambin es importante tener una capacidad de lucha cuando se trata de eventos de seguridad. Es anlogo a
necesitar msculos de "contraccin nerviosa lenta" y de "contraccin nerviosa rpida" La organizacin
debe tener la capacidad de poner recursos rpidamente en el lugar del problema, antes de que ese
problema se saiga de control.
15.6.2 Costes
Asegurar la infraestructura TI demanda personal, y por lo tanto dinero, para tomar, mantener y verificar las
medidas. Sin embargo, no asegurar la infraestructura TI tambin tiene su coste (coste de prdida de
produccin, coste de reemplazo, dao de datos, software o hardware; prdida de reputacin, multas o
compensacin por la falta de cumplimiento de las obligaciones contractual es).
Como siempre, se debe encontrar el equilibrio.
169
170
Caso: Quick Couriers

El caso de estudio trata de una empresa joven en desarrollo que se enfrenta a todos los temas pertinentes de
la gestin de servicios. Al final de cada seccin se hacen preguntas sobre cmo guiar y fijar los
conocimientos del lector.
El trfico de la ciudad de Madrid es ahora tan pesado que es difcil proporcionar un servicio de mensajera
con camionetas. Por tal razn, despus de su graduacin, tres amigos, Eva, Antonio y Pablo decidieron crear
un servicio de mensajera con bicicletas. Fundaron para tal fin "Quick Couriers" (QC). Quick Couriers entrega
paquetes en el centro de la ciudad usando bicicletas reclinables.
Al principio los fundadores de Quick Couriers trabajaban solos, pero ahora tienen contratos con empresas de
mensajera internacionales para buscar y entregar paquetes en el centro por lo que ya no pueden trabajar solos.
Ahora emplean estudiantes part-time para realizar las entregas de los paquetes y utilizan bicicletas reclinables
de su empresa.
Eva es la responsable de contabilidad, facturacin, procesamiento de peticiones, y de mantener los contactos
del negocio. Quick Couriers ha comprado un EPR y un CRM.
Antonio responde el telfono, maneja las consultas de los clientes, hace la planificacin y logstica de los
mensajeros, y pasa los mensajes de los mismos a Eva o Pablo.
Pablo hace el mantenimiento de las bicicletas, administra los repuestos y herramientas, hace el planeamiento
de logstica y es el instructor de los mensajeros.
Los tres amigos revisaron recientemente la posicin de la empresa y definieron la visin y polticas de la
misma. La visin es la siguiente 'Quick Couriers debe convertirse en sinnimo de entregas express en el
centro de Madrid y sus alrededores'. Para implementar esto, la empresa ha iniciado una campaa de
publicidad y est incorporando ms mensajeros. Tienen planeado equipar a los mensajeros con pagers y
telfonos mviles. Adems tienen pedida la cotizacin de un sistema basado en Internet, para que los clientes
puedan solicitar y hacer seguimiento de servicios de mensajera por esta va. Otra opcin que est siendo
considerada es la expansin de sus operaciones comerciales, mediante la apertura de otra oficina en Barcelona
o Sevilla. Por eso, han decidido que esto ser crtico para el futuro de la empresa para lograr un
posicionamiento comercial ms profesional.
En consecuencia, ellos han definido las reas que requieren atencin.
171
Pablo lleva informes en papel de las herramientas, instrucciones de mantenimiento, bicicletas, trailers,
repuestos, ponchos y cascos. Si se enferma o se va de vacaciones, su primo, Jorge, se hace cargo del
mantenimiento.
La empresa tiene ahora 20 unidades de entrega (bicicletas y trailer), 16 de las cuales se usan constantemente.
Las otras cuatro se encuentran en mantenimiento o como repuesto. Quick Couriers usa dos modelos que
obtiene de diferentes abastecedores.
Para acelerar el mantenimiento, Pablo ha hecho una cierta cantidad de sub-repuestos de los componentes ms
caros y vulnerables. Por ejemplo, tiene un conjunto de frenos de disco, conjuntos de engranajes, ruedas
delanteras y traseras, y conjuntos de luces. Cuando tiene tiempo, repara los conjuntos reemplazando las partes
usadas o rotas, pero a veces externaliza su trabajo a su vecina, Mara una ciclista entusiasta que se ha jubilado
por adelantado.
En su taller, Pablo tiene una hilera de estantes con partes sueltas y tiene un registro para hacer un seguimiento
de pedidos pendientes que ha enviado a los abastecedores. Algunas partes son intercambiables con las de las
bicicletas de carrera comunes.
El garaje de las bicicletas est cerca del taller. Muchos mensajeros pasan por all para buscar el programa de
entregas o para reparar sus bicicletas.
Debido al incremento de volumen del negocio, Pablo ya no puede manejar sus papeles y le lleva mucho
tiempo hacer los informes. Eva se queja por las facturas de herramientas y repuestos y se pregunta si podrn
ahorrar.
Pablo ahora ha instalado una base de datos de paquetes para hacer un seguimiento del inventario. La base de
datos se llama ConFig. Tiene un informe impreso de los repuestos en el taller. Tambin ha comprado una
etiquetadora para el inventariado de los repuestos.
Preguntas:
1.
2.
3.
4.
5.
6.
7.
8.
172
Qu inici el desarrollo de este proceso?

Quin est involucrado en el proceso, adems de Pablo?
Disee el alcance y el nivel de detalle de la base de datos. Qu atributos de los Elementos de
Configuracin (CI/EC) son adecuados para Pablo?
Qu est involucrado en la monitorizacin del estado? Para qu se usa la historia del estado?
D ejemplos de algunas preguntas, p. ej. sobre tendencias, que Pablo pueda responder con la base de
datos, pero que no poda responder antes.
Cmo llenar Pablo su base de datos?
Cmo garantiza Pablo que su base de datos permanezca actualizada?
De qu debera Pablo informar a Eva?
Gestin de Incidentes y Centro de Servicios

Con diecisis mensajeros permanentemente en la calle, la carga de trabajo de Antonio de contestar el telfono
se incrementa cada vez ms. El recibe constantemente pedidos de clientes, quejas sobre la demora en la
entrega de los paquetes, y mensajes de los mensajeros a los que se les ha roto la bicicleta o que no pueden
entregar el pedido porque la direccin es incorrecta.
A Antonio le resulta muy difcil hacerse cargo de todo, y se olvida de devolver las llamadas. Eva tambin se
da cuenta de que se olvidan algunos pedidos. Hojas de papel que se pierden, falta de divisin del trabajo.
Mientras que se hace un gran esfuerzo para proporcionar un buen servicio, tambin es imposible determinar
con cunta rapidez se estn resolviendo los temas. Los clientes se han comenzado a quejar sobre los fallos del
servicio y todos en la empresa tienen la impresin de que la cantidad de pedidos est disminuyendo.
Mientras tanto, Pablo se enfrenta con una creciente cantidad de rutas y paquetes a incluir en la planificacin.
Ha creado una base de datos, RoutePlan, para los paquetes y las rutas, agrupados por cdigo postal. La ruta de
cada mensajero cubre cierta cantidad de cdigos postales y tiene una secuencia ptima. Muchos mensajeros
pueden cubrir la misma zona.
Se pidi a Antonio que manejara algunas llamadas en persona. Por ejemplo, informa a los clientes sobre la
gama de servicios que ofrece Quick Couriers, y registra las quejas. Adems se le encomend que identificara
qu ha sucedido con los paquetes, y que se asegure de volver a llamar a los clientes. Ahora puede acceder a la
base de datos RoutePlan en el ordenador de Pablo utilizando un segmento de red instalado hace poco que une
los dos ordenadores.
Para seguir el rastro de los mensajes y llamadas telefnicas, Antonio ha creado una nueva base de datos,
TelLog. Antonio utiliza TelLog para hacer un seguimiento de todas las llamadas y para asignarles una
categora y cdigo de prioridad.
Preguntas:
1.
2.
3.
4.
5.
6.
7.
Qu inici el desarrollo de este Centro de Servicios?

Para este proceso qu tipo de Centro de Servicios se us primero?
Qu informacin de incidentes es pertinente a una llamada de incidente?
D ejemplos de categoras y prioridades.
A quin puede llamar Antonio si no puede resolver un problema?
Una comunicacin eficaz con el taller es esencial. Qu trmino se utiliza para esto en ITIL?
De qu manera puede Quick Couriers asegurarse de que las llamadas por incidentes no se pasan por alto,
y quin es responsable de esto?
8. Se brinda soporte a las Operaciones del Negocio aqu? Si es as, explique cmo.
9. Qu vnculos de informacin querra crear para los otros sistemas, y con qu propsito?
10. De qu debera informar Antonio a Pablo y a Eva?
173
Gestin de Problemas
RoutePlan para enrutar el paquete, TelLog para registrar las llamadas y ConFig para los informes de stock. El
servicio ha mejorado y disminuy la presin de trabajo. Quick Couriers ahora tiene treinta mensajeros en la
calle, y Eva y Antonio se casaron, en una bicicleta para dos, por supuesto.
Antonio ahora tambin usa RoutePlan para la planificacin de rutas. Un estudiante se encarga de la central
telefnica y puede resolver muchos incidentes usando la documentacin que le dio Antonio.
La primera vez que se presenta un problema nuevo, el estudiante pide ayuda a Pablo, Antonio o Eva y luego
documenta la solucin para poder utilizarla la prxima vez.
Si un mensajero se atasca por un problema con su bicicleta, el estudiante de la central telefnica enva un
repuesto con el mensajero que se encuentra ms cerca. Si el mensajero no puede solucionar el problema,
Pablo utiliza el trailer para llevar la bicicleta de repuesto.
Sin embargo Pablo todava se ocupa del nmero de reparaciones de bicicletas. Las bicicletas de carrera son
ms frgiles y estn en constante uso. Todo depende de cmo los mensajeros toman las curvas y los pozos.
Quick Couriers tiene la impresin de que la marca A sufre menos desgaste que la marca B, pero no estn
seguros. Algunas partes se rompen con ms frecuencia que otras, pero no est claro si esto es por el uso, o la
marca.
Antonio se preocupa por la cantidad de paquetes que se pierden. Aunque por lo general se pueden localizar,
quieren saber cmo se puede hacer un sistema a prueba de fallos. Los mensajeros reciben un bonus por
desempeo y hay un premio para el mensajero que realice la mayor cantidad de entregas por hora. Pero
Antonio todava quiere informacin sobre la eficacia del mensajero y su trato con el cliente para mejorar su
capacitacin si es necesario.
A Antonio se le pidi que observara los datos en TelLog, RoutePlan y ConFig para identificar las causas
subyacentes de esos fallos. Espera tener para combinar muchos datos histricos y utilizarlos para disponer de
anlisis de tendencias.
Preguntas:
1.
2.
3.
4.
5.
6.
7.
174
Qu inici el desarrollo del proceso?

Quines estn involucrados y cules son sus roles?
Qu actividades realiza Antonio, y cules son los resultados?
Qu informacin quiere obtener Antonio de los otros sistemas?
D ejemplos de problemas y Errores Conocidos.
Cules son las responsabilidades de Antonio respecto a los Errores Conocidos?
De qu conclusiones informa Pablo a Eva y Antonio?
Gestin de Cambios
Antonio aprendi un poco en la prctica las causas raz de los incidentes. Por ejemplo encontr que los discos
de frenos de una marca se gastan ms rpido que los de otra. Hay algunos mensajeros que daan sus bicicletas
con mayor frecuencia que sus colegas, y algunos paquetes se pierden porque se ponen en el trailer del
mensajero equivocado.
Antonio ha hecho algunas recomendaciones sobre estos temas. Como estas recomendaciones tienen que ver
con las reas que cubren Eva y Pablo, discute el impacto potencial y la cantidad de trabajo que suponen. Los
eventos de la semana anterior se discuten en los encuentros semanales de los lunes por la maana. Como se
espera que Antonio presente propuestas para mejoras regularmente, ahora tiene una agenda y una lista de
acciones sobre cada elemento por separado.
A Pablo se le pidi que probara un tipo de freno nuevo. Despus de hacerlo va a disear un programa de
mantenimiento. Los frenos se podrn cambiar segn este esquema. Esto se combinar con otro mantenimiento
planificado para garantizar que las bicicletas no se retiren demasiado rpido o antes de lo previsto.
Se evaluar una propuesta de un planteamiento ms estructurado para clasificar y asignar los paquetes.
Adems se tendrn reuniones con los mensajeros que rompen sus bicicletas muy a menudo.
Preguntas:
1.
2.
3.
4.
5.
6.

Quines estn involucrados, y cules son sus roles?
Qu actividades se toman en las reuniones despus de las propuestas de Antonio?
Describa cmo evaluara las diferentes propuestas, y si sera necesario un plan de apoyo. Qu se podra
incluir en el plan de evaluacin?
Qu se involucra en las modificaciones de planificacin? Identifique las dificultades, los riesgos,
recursos necesarios e impacto esperado.
Qu se necesitara para cerrar las acciones pendientes? Qu otros procesos estn involucrados?
175
Gestin de Versiones
Cuando los mensajeros entregan el paquete al cliente, dejan sus bicicletas fuera en la acera. Antonio ha
comprado algunos candados de buena calidad para evitar los robos. Las bicicletas tambin tienen traba-ruedas
separados y candados para los trailers. Pablo guarda las llaves extra en un cajn del escritorio. Los mensajeros
a veces pierden las llaves y resulta bastante complicado encontrar la llave de repuesto que corresponde.
Despus de un tiempo resulta difcil establecer qu llaves de repuesto se han perdido. Quick Couriers tiene
que comprar a menudo nuevos candados, y ahora que su flota de bicicletas se est expandiendo, esto se est
transformando en un gasto importante.
Por esa razn Pablo ha decidido mejorar la gestin de las llaves y sus copias.
Se define un conjunto de candados por bicicleta. Los candados estn numerados y los nmeros se encuentran
en ConFig. Pablo compra una caja de seguridad para guardar las llaves originales y las copias.
Preguntas:
1.
2.
3.
4.
5.
6.
176

Qu pasos se deben tomar antes de usar un nuevo conjunto de candados?
Qu medidas se deben tomar antes de entregar un nuevo conjunto de copias de llave a un mensajero?
Reemplazara el conjunto completo si solo falla uno de los candados? Cmo se llama esto?
Qu pasos tomara si slo se reemplaza uno de los candados? Cmo se llama esto?
Quick Couriers tiene cada vez ms trabajo. Cuando se rompe una bicicleta lleva mucho tiempo arreglarla, y el
mensajero y el paquete quedan esperando en la calle- De igual forma, si el mensajero se enferma se altera
toda la programacin. Los clientes se empiezan a quejarse porque las entregas llevan mucho tiempo.
Eva quiere conseguir informacin de los desarrollos para poder incluirlos en los planes de la empresa.
Los contenidos incluirn mantenimientos, tiempos de entrega, y personal. El objetivo de la empresa es poder
garantizar tiempos de entrega lo ms cortos posibles. Algunas ideas posibles consisten en establecer un
equipo de reparacin mvil, comprar una centralita telefnica con sistema de mens, y establecer un
procesamiento de pedido y rastreo del sistema en Internet. Todo esto requerir de una inversin significativa.
Preguntas:
1.
2.
3.
4.
5.
6.

Haga una lista de los activos, las amenazas y vulnerabilidades.
Utilice esta informacin para identificar los riesgos.
En qu medidas de prevencin puede pensar?
Haga una lista a incluir en la planificacin en trminos de mantenimiento, abastecedores y personal.
177
El mercado cambia rpidamente. Quick Couriers est consiguiendo nuevos clientes en otros distritos y
piensan expandirse a Barcelona y Sevilla. Pablo tambin est pensando abrir otra oficina en el aeropuerto
Internacional de Madrid-Barajas.
Eva tiene informacin emprica sobre los niveles de personal necesarios para cada ruta. Ha utilizado el
sistema de RoutePlan para crear un informe que muestra, para cada ruta, cuntos paquetes se llevan cada da
de la semana, en qu horario la ruta est ms congestionada, y cuntos paquetes se pueden llevar en el trailer.
Ha utilizado el promedio como lnea de referencia, e identific un porcentaje por encima y por debajo de la
lnea de referencia para cada mes y hora del da.
Quiere utilizar esta informacin para el equipamiento y la planificacin del personal.
Eva utiliza esta informacin para hacer un informe sobre la expansin esperada y los costes de inversin
necesarios.
Preguntas:
1.
2.
3.
4.
5.
6.
178

D ejemplos de actividades de modelado.
Cmo se pueden acomodar las cargas pico sin desplegar capacidad adicional?
Qu actividades asisten en la estimacin de recursos para comenzar una nueva ruta?
Qu se debera incluir en el plan de capacidad?

La semana pasada, se incendi el edificio de al lado de Quick Couriers. Eva, Antonio y Pablo se asustaron
mucho. Su lugar actual es muy adecuado, y encontrar un lugar en la ciudad de Madrid es muy difcil. Se
dieron cuenta de que si pasa algo igual en su edificio, les llevara meses volver a la actividad.
Por este motivo, Quick Couriers decidi incluir opciones de recuperacin ante desastres en sus planes para
una nueva oficina en el sur de la ciudad de Madrid. Adems van a considerar alternativas en las vecindades de
la ubicacin actual que pueden usarse como base temporal para servir las rutas del rea central. En el plan se
incluyen los siguientes temas:
-
Edificio
Accesibilidad
Personal
Archivos electrnicos y sistemas
Equipamiento
Paquetes del cliente
Preguntas:
1.
2.
3.
4.
5.
6.

Cules son las razones de la empresa para mantener un plan de recuperacin ante desastres?
Cules son las amenazas, activos y vulnerabilidades?
Utilice esta informacin para identificar los riesgos.
Qu medidas preventivas se pueden tomar, y qu riesgos necesitan las instalaciones de recuperacin
ante desastres fuera de lugar?
7. Cul es el trmino ITIL para un plan de recuperacin ante desastres que incluye el apoyo de las
instalaciones TI de otra organizacin?
8. Identifique los temas a incluir en un plan de apoyo en otro lugar, y describa cmo se debera evaluar.
9. Cmo el plan de capacidad y los diversos planes influencian en el plan para mejorar la disponibilidad (p.
ej. la oficina nueva)?
10. Cul es el efecto de la Gestin de Cambios {Comit de Cambio)? D un ejemplo de este caso de
estudio.
179
Gestin Financiera
El rango de servicios que proporciona Quick Couriers se est expandiendo. Hay tarifas ms bajas para las
entregas fuera de horario pico, tarifas para entregas urgentes, y descuentos por volumen.
Los clientes pueden usar Internet para pedir una coleccin de paquetes, y rastrear la ubicacin de los suyos.
Sin embargo, algunos empleados de Quick Couriers se fueron y empezaron sus propios negocios lo que ha
puesto presin a la calidad y los precios de los servicios.
Los costes relacionados con el soporte del servicio tambin se ha incrementado. La empresa se vuelve cada
vez ms dependiente de las instalaciones TI. Eva se ha puesto en contacto con un proveedor de servicio de
Internet, ha contratado una lnea, y Quick Couriers ahora emplea un gestor de sistemas para garantizar la
continuidad. Hay un equipo de reparacin constantemente en la calle. Los costes de administracin se han
incrementado debido a la mayor cantidad de personal.
Se han hecho inversiones en edificios, por lo que la depreciacin se ha convertido en un tema relevante para
la contabilidad. Los mensajeros que operan los servicios express tienen que estar disponibles en todo
momento, lo que significa que a veces estn sin ocupacin.
Se est volviendo muy difcil establecer precios que cubran los costes. Eva quiere promover ciertos servicios
(los que los competidores tambin pueden ofrecer) cobrando menos, pero debe considerar el monto para que
los nuevos precios no resulten una prdida operativa.
Eva quiere introducir un sistema de centra de costes para conseguir informacin sobre los costes asociados
con la provisin de cada servicio. Ahora que va a tener ms informacin sobre los costes por servicio, espera
ser capaz de financiar las prdidas de ciertos servicios con las ganancias de otros.
Preguntas:
1.
2.
3.
4.
5.
180
Qu impidi el desarrollo de este proceso?

D ejemplos de costes fijos y variables, y de costes directos e indirectos.
D un ejemplo de catlogo de servicio y medios de produccin necesarios para los diferentes servicios.
Realice un resumen del plan de poltica de precio.

Eva quiere que los clientes regulares se comprometan con su negocio. Por tal razn, quiere mantener mejores
contactos con ellos y formalizar contratos de servicio a largo plazo. Los clientes fijos pagarn un monto fijo
por mes, en vez de pagar por separado por cada paquete o servicio. Esto le dar a la empresa una entrada fija
que les facilitar el planeamiento de los servicios.
Dado que Quick Couriers tiene tantas bicicletas en la calle, la empresa depende ms de los abastecedores de
repuestos y otros servicios. Por esta razn, Eva quiere formalizar los contratos para garantizar los tiempos de
entrega.
Quick Couriers contrata un nuevo empleado como contable. Su tarea es traducir las demandas del cliente en
planes para servicios nuevos o modificados. Despus de formalizar los contratos de Apoyo puede empezar a
desarrollar un catlogo nuevo.
Preguntas
1.
2.
3.
4.
5.
6.
7.
8.
9.

Describa la funcin del gestor contable.
D un ejemplo de un acuerdo de marco de trabajo con un cliente regular.
Cmo se garantizan los servicios acordados con el cliente?
Qu se podra incluir en el Plan de Calidad de Servicio para la empresa?
Si fuera gestor contable, con quin finalizara un SPA (u OLA)?
A quin informarla sobre los Logros de Servicio?
Cmo se planean los cambios para los servicios de bajo rendimiento?
181

GestiondeServiciosTI ITIL PDF

Загружено:

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

Оригинальное название

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

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

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

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

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

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

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

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

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

GestiondeServiciosTI ITIL PDF

Загружено:

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

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

Contenidos

GESTIN DE SERVICIOS IT-FUNDAMENTOS 3

13. GESTIN DE LA CONTINUIDAD

14. GESTIN DE LA DISPONIBILIDAD

15. GESTIN DE LA SEGURIDAD

16. ESTUDIO DE CASO Quick Couriers

Gestin de Servicios TI basado en ITIL

ITIL. es una marca registrada de CCTA/OGC

Gestin de Servicios TI basado en ITIL

2.1 Servicios y calidad

Gestin de Servicios TI - Fundamentos

Gestin de Servicios TI basado en ITIL

2.1.1 Aseguramiento de la calidad

Figura 2.1. Circulo de Calidad de Deming

'El cliente es la parte ms importante de la lnea de produccin'.

Gestin de Servicios TI - Fundamentos

2.1.2 Madurez de organizacin

Gestin de Servicios TI basado en ITIL

Figura 2.2Modelo EFQM

Gestin de Servicios TI - Fundamentos

Inicial - el proceso ocurre ad hoc.

Figura 2.3 Niveles de Comunicacin y madurez: cliente y proveedor

Gestin de Servicios TI basado en ITIL

2.2 Organizacin y polticas

2.2.1 Visin, objetivos y polticas

Figura 2.4 Visin, objetivos y polticas

Gestin de Servicios TI - Fundamentos

2.2.2 Horizonte de planificacin

Figura 2.5 Horizonte de planeamiento

Gestin de Servicios TI basado en ITIL

Tiempo - es el factor ms fcil de determinar. Lo define la fecha de comienzo y de finalizacin, y se

2.2.4 Gestin de Recursos Humanos

Gestin de Servicios TI - Fundamentos

Ofrecer a los empleados la posibilidad de desarrollar y utilizar sus habilidades beneficiar a la

Hay tres planteamientos para la HRM:

Gestin de Servicios TI basado en ITIL

Figura 2.6 Gestin de Relaciones con el Cliente

Gestin de Servicios TI - Fundamentos

2.3 Gestin de Procesos

Gestin de Servicios TI basado en ITIL

Figura 2.7 Modelo de mejora del proceso

Gestin de Servicios TI - Fundamentos

Figura 2.8 Diagrama de proceso

Gestin de Servicios TI basado en ITIL

Figura 2.9 Modelo de proceso genrico ITIL

2.3.2 Procesos y departamentos

Figura 2.10 Procesos y departamentos (ejemplo)

Gestin de Servicios TI - Fundamentos

2.3.3 Gestin de Servicios TI

Gestin de Servicios TI basado en ITIL

Ventajas de ITIL para el cliente/usuario:

Gestin de Servicios TI basado en ITIL

3.2.3 EXIN y ISEB

Foundation Certificate en Gestin de Servicios TI

Figure 3.1 Entorno de ITIL (fuente: OGC)

3.3 Los Libros de ITIL

Gestin de Servicios TI basado en ITIL

Figura 3.2 ITIL puzzle (fuente: OGC)

3.3.1 Perspectiva del Negocio

Gestin de la Continuidad del Negocio

3.3.2 Provisin del Servicio

Gestin de Niveles de Servicio

Gestin de Servicios TI basado en ITIL