Manual 2017-I 04 Gestioìn de Servicios de TI - Cibertec

Gestin de
Servicios de TI
2
GESTIN DE SERVICIOS DE TI 3
NDICE
Presentacin 5
Red de contenidos 6
Unidad de aprendizaje 1: Fundamentos de la Gestin de Servicios de TI

TEMA 1 : Introduccin a la Gestin de Servicios de TI 7
TEMA 2 : Gestin de Procesos 21
TEMA 3 : Introduccin a ITIL 27
Unidad de aprendizaje 2: Gestin de la Configuracin, Incidentes,

Problemas y Cambios.
TEMA 4 : Centro de Servicios 39
TEMA 5 : Gestin de la Configuracin 47
TEMA 6 : Gestin de Incidentes 57
TEMA 7 : Gestin de Problemas 67
TEMA 8 : Gestin de Cambios 77
TEMA 9 : Gestin de Versiones 87
Unidad de aprendizaje 3: La Transicin y Operacin de Servicios de TI.

TEMA 10 : Gestin de la Capacidad 95
TEMA 11 : Gestin de la Disponibilidad 105
TEMA 12 : Gestin de la Continuidad 113
Unidad de aprendizaje 4: Racionalizacin y Mejora Continua de los

Servicios de TI.
TEMA 13 : Gestin de Nivel de Servicio 122

TEMA 14 : Gestin de la Demanda 131
TEMA 15 : Gestin del Conocimiento 137
TEMA 16 : Gestin de Mejora Continua de Servicios de TI 144
CIBERTEC CARRERAS PROFESIONALES

4
PRESENTACIN
Gestin de Servicios de TI es un curso que pertenece a la lnea de Gestin

de Sistemas y se dicta en la carrera de Administracin de Sistemas. Brinda
los fundamentos de gestin que hacen eficiente la entrega y soporte de
servicios de TI, basndose en el enfoque de procesos de ITIL (Information
Technology Infraestructure Library).
El manual para el curso ha sido diseado bajo la modalidad de unidades de

aprendizaje, las que se desarrollan durante semanas determinadas. En cada
una de ellas, hallar los logros, que deben alcanzarse al final de la unidad; el
tema tratado, el cual ser ampliamente desarrollado; y los contenidos, que
deben desarrollarse, es decir, los subtemas. Por ltimo, encontrar las
actividades que debern desarrollarse en cada sesin, que le permitirn
reforzar lo aprendido en la clase.
El curso presenta en primer lugar los conceptos bsicos referidos a la gestin

de TI, tales como servicios, calidad, organizacin, polticas y procesos, as
como la estructura y los objetivos de ITIL. Luego se describen el centro de
servicios y los procesos que conforman el soporte del servicio. Finalmente se
desarrollan los procesos referidos a la entrega o provisin del servicio.

6
RED DE CONTENIDOS
CARRERAS PROFESIONALES CIBERTEC

UNIDAD DE
APRENDIZAJE
1
TEMA
INTRODUCCIN A LA GESTIN DE SERVICIOS DE TI

LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno describir los conceptos bsicos de la

gestin de servicios de TI, y la estructura y los objetivos de ITIL, identificando
con precisin sus caractersticas, componentes y ventajas.
TEMARIO
Servicios y Calidad
Organizacin y Polticas
ACTIVIDADES PROPUESTAS
Los alumnos seleccionarn una empresa y la describirn en base a los

conceptos tratados en el captulo.

8
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 en 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 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.
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 dilogo 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 ste 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 explcitas 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. ste 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, ms 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 slo requiere proporcionar una calidad adecuada al llevar a cabo
cada proceso, sino tambin una calidad consistente.
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 1.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.

10
Figura 1.1 Crculo de Calidad de Deming
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.
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.
El modelo de la Fundacin Europea para la Gestin de Calidad (European

Foundation for Quality Management - EFQM) (Figura 1.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 est 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 1.2 Modelo EFQM
Como herramienta adicional, la organizacin holandesa de calidad, INK, dividi el

modelo en etapas que indican hasta qu 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 que el ejercicio de una mejora continua y equilibrada ha adquirido el
carcter de instintivo.
En el sector de las TI, el proceso de mejora de la madurez ms conocido, es el

Modelo de Madurez de Capacidad (Capability Maturity Model - CMM). Este mtodo
de mejora de proceso fue desarrollado por el Instituto de Ingeniera de Software 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 tambin han sido creados
para la Gestin de Servicios TI.

12
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 1.3) tambin es
importante. Si existen grandes diferencias entre el abastecedor y el cliente, entonces
stas 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 ms bajo.
Figura 1.3 Niveles de Comunicacin y Madurez: Cliente y Proveedor
2. ORGANIZACIN Y POLTICAS
2.1 Visin, objetivos y polticas
Una organizacin es una forma de cooperacin entre personas. Cualquier

organizacin, desde un club 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 ms barato o el ms 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 1.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 fundamentales: 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 conseguirn los mismos. Por supuesto, las
prioridades pueden cambiar con el tiempo, segn las circunstancias. Cunto 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 1.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 est 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 el
Cuadro de Mando Integral (Balanced Score Card - BSC). En este mtodo, los
objetivos de la organizacin o los procesos se utilizan para definir Factores Crticos

14
de xito (Critical Success Factors - 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 (Key Performance
Indicators - KPI). Si es necesario se pueden subdividir en Indicadores de
Rendimiento (PI).
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. Cuanto ms 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 en base a 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 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 1.5 muestra un ejemplo
de las relaciones entre los diferentes planes.
Figura 1.5 Horizonte de planeamiento
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 se 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 perodo 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.
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 s 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.

16
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 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.
La Gestin de Recursos Humanos es la cumbre de la gestin de personal moderna.

La Gestin de Recursos Humanos est 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.
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:
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.
Autorizacin - dar a los empleados la oportunidad de organizar e implementar
sus tareas de acuerdo con la organizacin.
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.
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.
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 1.6, 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 1.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 representar, principalmente, un papel de soporte organizando, por
ejemplo, encuestas entre los clientes y los usuarios, proporcionando informacin, etc.
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. Esta puede ser la base de una
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 (Service Level
Agreement - 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
Peticin de Cambio (Request For Change - 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.

18
La Figura 1.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.

Resumen
La provisin de servicios TI implica la gestin total -mantenimiento y operacin-

de la infraestructura TI.
El proceso de proveer un servicio es la combinacin de produccin y uso, en la

que participan simultneamente el proveedor y el cliente.
La calidad es el conjunto de caractersticas de un producto o servicio que influyen

en la satisfaccin de las necesidades explcitas e implcitas.
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 usuario es la mano sobre el teclado, el cliente es aqul que paga la cuenta,

obviamente el cliente tambin puede ser el usuario.

20

UNIDAD DE
APRENDIZAJE
1
TEMA
GESTIN DE PROCESOS

TEMARIO
Introduccin
Procesos
Procesos y Departamentos
Gestin de Servicios TI


22
1. INTRODUCCIN
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 cmo cada grupo de actividades
contribuye a los objetivos del negocio, y cmo se relacionan.
Tales grupos de actividades se conocen como procesos. Si la estructura de

procesos de una organizacin est claramente descrita, mostrar:
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.1 surgen continuamente durante el tpico planteamiento

basado en el proceso de la Gestin de Servicios TI. Las herramientas para responder
a estas preguntas se encuentran a la derecha.
Figura 2.1 Modelo de mejora del proceso
2. 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 organizacin 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.2). 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 qu pasa dentro de la organizacin y cules 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.
Figura 2.2 Diagrama de proceso
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.
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

24
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 quin hace qu 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.3 muestra el modelo de proceso basado en la metodologa ITIL que es la

base del proceso de Gestin de Servicios TI que describe este manual.
Figura 2.3 Modelo de proceso genrico ITIL
3. 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.
La Figura 2.4 muestra un ejemplo bsico de las combinaciones de actividades en un

proceso (se indica con lneas punteadas).
Figura 2.4 Procesos y departamentos (ejemplo)
4. 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. 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.

26
Resumen
Un proceso es una serie de actividades relacionadas lgicamente que conducen

a definir un objetivo.
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 quin hace qu 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.

UNIDAD DE
APRENDIZAJE
1
TEMA
INTRODUCCIN A ITIL

TEMARIO
Fundamentos
Los Libros de ITIL


28
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, pblica o privada, con servicios
TI centralizados 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 que las organizaciones
utilizan esta metodologa.
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 la comunicacin 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 la comunicacin interna y la
comunicacin 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 s 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, cules son los indicadores de rendimiento, y cmo 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 que aparezcan.

30
2. 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 ms 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 comunicacin 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
especfica 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 las primeras colecciones y ha
mejorado la cohesin interna. Ilustra tambin la visin de la Gestin de Servicios TI
con ms claridad.
La estructura bsica de ITIL se ilustra en la Figura 3.1, que utiliza un conjunto de

piezas de rompecabezas como analoga, 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

Provisin del Servicio
Gestin de la Seguridad
Gestin de Infraestructuras TI Gestin de Aplicaciones
Planificacin para Implementar la Gestin de Servicios
Perspectiva del Negocio

Figura 3.1 ITIL puzzle
2.1 Soporte del Servicio
El libro ITIL sobre Soporte del Servicio describe cmo 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)
2.1.1 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 sta como Centro de Soporte
(Help Desk). La tarea ms 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.
2.1.2 Gestin de Incidentes
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.

32
2.1.3 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.
2.1.4 Gestin de Configuraciones
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.
2.1.5 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.
2.1.6 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 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.
2.2 Provisin del Servicio
Como se indic anteriormente, 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 proporcionarlos.

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 la Disponibilidad
Gestin de Continuidad de los Servicios TI
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.2 ilustra las principales generalidades.
Figura 3.2 Soporte del Servicio y Provisin del Servicio
2.2.1 Gestin de Niveles de Servicio
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. En base a esta informacin se determinan los KPI y se verifica la calidad
de los servicios.
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:

34
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.
2.2.2 Gestin Financiera de los Servicios 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 qu
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 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 dnde?) 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.
2.2.3 Gestin de la Capacidad
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.
2.2.4 Gestin de la Disponibilidad
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.
2.2.5 Gestin de Continuidad de los 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.

2.3 Gestin de la Seguridad
El objetivo de la Gestin de la Seguridad es proteger la infraestructura TI del uso sin

autorizacin (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.
2.4 Gestin de Infraestructuras TI
Los procesos de gestin de operaciones TI se desarrollan en el libro ITIL sobre

Gestin de Infraestructuras TI. Este libro cubre:
Gestin del Servicio de Redes Gestin de Operaciones

Gestin de Centros distribuidos
Instalacin y Aceptacin de Ordenadores Gestin de Sistemas
Gestin del Entorno
2.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 como 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.
2.6 Planificacin para Implementar la Gestin de Servicios
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 prctica, 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 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 s mismo, o una serie de proyectos. Una de las ventajas
es que la organizacin se topar con puntos decisivos y podr decidir si terminar,
continuar, o modificar el proyecto.
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 compararn
segn:
Conveniencia para la organizacin.

Riesgos, obstculos y problemas potenciales.
Costes de transicin y costes a largo plazo.

36
Costes por continuar con el planteamiento actual.

Identificar las alternativas potenciales puede resultar un proyecto en s mismo.
La experiencia nos demuestra que ITIL no es una frmula 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.
2.7 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 reemplazar la coleccin, incluye:
Gestin de la continuidad del negocio

Asociaciones y externalizacin (outsourcing)
Cambios para la supervivencia
Adaptacin del negocio a los cambios
radicales Gestin de recursos fsicos
Gestin de relaciones con abastecedores

Resumen
ITIL fue creada para comunicar las mejores prcticas en la Gestin de Servicios
TIsistemtica y coherentemente. Su planteamiento se basa en la calidad de
servicio y en el desarrollo eficaz y eficiente de los procesos.
Los siete libros de ITIL son:
- Soporte del Servicio

- Provisin del Servicio
- Gestin de la Seguridad
- Gestin de Infraestructuras TI
- Gestin de Aplicaciones
- Planificacin para Implementar la Gestin de Servicios
- Perspectiva del Negocio
El libro Soporte del Servicio 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)
El libro Provisin del Servicio cubre los siguientes temas:
- Gestin de Niveles de Servicio

- Gestin Financiera de los Servicios TI
- Gestin de la Capacidad
- Gestin de la Disponibilidad
- Gestin de Continuidad de los Servicios TI
Si desea saber ms acerca de estos temas, puede consultar la siguiente pgina:
http://itil.osiatis.es/Curso_ITIL/
Aqu hallar ms informacin sobre el presente captulo.

38

UNIDAD DE
APRENDIZAJE
2
TEMA
CENTRO DE SERVICIOS
Al trmino de la unidad, el alumno explicar las funciones del centro de

servicios o service desk y los procesos que conforman el soporte del servicio
de TI, identificando con precisin sus caractersticas, componentes, ventajas,
recomendaciones de implementacin y medicin, as como la interrelacin de
dichos procesos.
TEMARIO
Introduccin
Objetivos
Actividades
Estructura

Analizar el caso propuesto por el profesor en clase.

40
1. INTRODUCCIN
El Centro de Servicios (Service Desk) proporciona un punto de contacto a diario vital
entre los clientes, usuarios, servicios TI y organizaciones de soporte externas. La Gestin
de Nivel de Servicio es un habilitador de negocio primordial para esta funcin. Un Service
Desk proporciona valor a una organizacin ya que:
Acta como una funcin estratgica para identificar y reducir el coste de

propiedad de soportar la infraestructura de soporte e informtica
Soporta la integracin y la gestin de cambio a travs de los lmites del negocio
distribuido, la tecnologa y los procesos
Reduce costos con el uso eficiente de recursos y tecnologa
Soporta la optimizacin de inversiones y la gestin de servicios de soporte del
negocio
Ayuda a asegurar la satisfaccin del cliente y su retencin a largo plazo
Asiste en la identificacin de oportunidades de negocio
Estratgicamente, para los clientes el Service Desk es probablemente la funcin ms

importante de una organizacin. Para muchos, el Service Desk, es la nica ventana en el
nivel de servicio y profesionalismo ofrecida por toda la organizacin o un departamento,
lo cual constituye el componente ms importante de servicio de Satisfaccin y
Percepcin del Cliente. Dentro de las funciones TI, el Service Desk representa los
intereses del cliente para el equipo de servicio.
Cuando un servicio se ha interrumpido, el objetivo de algunos procesos es restaurar el

servicio. El Service Desk es la organizacin que facilita dichos procesos. Esto significa
que el Service Desk es responsable de un evento de servicio de principio a fin. Mientras
que otras funciones, como el soporte de segunda y tercera lnea, asistirn en la
resolucin, el Service Desk retiene el control administrativo de la incidencia.
El Service Desk no est programado con la tarea de encontrar la causa original de una
interrupcin de servicio, esta responsabilidad corresponde a la Gestin de Problemas.
2. OBJETIVOS
Proveer un nico Punto de Contacto (SPOC) con los Clientes

Facilitar la restauracin de un servicio normal de operaciones, con un mnimo
impacto en los negocios del cliente, dentro de los niveles de servicio acordados y
las prioridades del negocio
3. ACTIVIDADES
Recibir llamadas, primer enlace con el cliente Grabar y seguir los incidentes y las
quejas
Mantener a los clientes informados sobre el requerimiento y su evolucin
Hacer una valoracin inicial de los requerimientos, intentando resolverlos o
remitirlos a otra persona que puede atenderlos, basado en un nivel de servicio
acordado
Monitorear y escalar de acuerdo al SLA
Administrar el ciclo de vida del requerimiento, incluyendo el cierre y la verificacin
Comunicar a los clientes los cambios planificados y de corto plazo de los niveles
de servicio
Coordinar con los grupos de soporte de segunda lnea y externos

Generar informes de gestin y recomendaciones para el mejoramiento del
servicio
Identificar problemas
Destacar las necesidades de educacin y entrenamiento del
cliente Cerrar los incidentes y confirmacin con el cliente
Contribuir a la identificacin del problema
3.1 Interaccin con el cliente

La interaccin del cliente ya no se limita tan solo al contacto telefnico y personal. El
servicio puede mejorar enormemente y ser extendido al cliente, usuarios y personal
de soporte expandiendo los mtodos de registrar, actualizar y consultar las
solicitudes. Esto puede realizarse utilizando el e-mail y el lnternet/lntranet para
oficinas remotas, aunque el fax tambin puede ser una herramienta valiosa. Estos
mtodos son mejor explotados para actividades que no son crticas para el negocio,
que incluye el registro de incidentes o requerimientos no urgentes, tales como:
Adquisicin de productos
Consultas de aplicacin
Requerimientos para traslados, instalaciones, mejoras y actualizaciones de
equipamiento
Requerimiento de consumibles
Para el equipo de soporte, los beneficios incluyen:
Se libera al personal de soporte de interrupciones telefnicas

innecesarias Las cargas de trabajo se manejan mejor
El uso de formularios aumenta la integridad de los datos suministrados y ayudan con

la asignacin del especialista, equipo o departamento de soporte ms adecuado. La
herramienta del Service Desk debera automticamente proporcionar al cliente o al
usuario un nmero de referencia nico de recepcin, que tambin permita la consulta
en lnea del progreso del requerimiento.
Proporcionar a los clientes y usuarios la confirmacin que su requerimiento ha sido

aceptado y de su progreso, es uno de los roles ms importantes del Service Desk.
An muy pocas organizaciones tienen los recursos de personal para centrarse y
mantener esta actividad. Como se indic anteriormente, el uso de tecnologas, como
el e-mail, ayudarn con dicha actividad. Sin embargo, el reto real es crear un vnculo
personalizado con los clientes, aunque sea mediante la comunicacin electrnica.
4. ESTRUCTURA
4.1 Tipos de Mesas (Desks)
4.1.1 Centro Telefnico (Call Centre)
El nfasis de un Call Centre est en manejar grandes volmenes de transacciones

originadas por telfono. Normalmente, un Call Centre no reaccionar a esas
transacciones sino que slo las registrar y las referir a otras partes de la
organizacin.

42
4.1.2 Servicio al Cliente (Help Desk)
El principal propsito es gestionar, coordinar y resolver Incidentes lo antes posible y

asegurarse de que ningn requerimiento se pierda, olvide o ignore. Los vnculos con
la Gestin de Configuracin y las herramientas de conocimiento se utilizan
generalmente como tecnologas de soporte.
4.1.3 Centro de Servicios (Service Desk)
El Service Desk extiende el campo de servicios permitiendo que se integren procesos

de negocio en la infraestructura de Gestin de Servicio. No slo maneja Incidentes,
Problemas y consultas, tambin proporciona un nexo comn para otras actividades
como requerimientos de Cambio de los clientes, contratos de mantenimiento,
licencias de software, Gestin de Nivel de Servicio, Gestin de Configuracin,
Gestin de Disponibilidad, Gestin Financiera de los Servicios TI y Gestin de
Continuidad de Servicio TI.
Muchos Call Centres y Help Desks naturalmente evolucionan hasta convertirse en

Service Desks para mejorar y extender su servicio global a los Clientes y el negocio.
Las tres funciones comparten caractersticas comunes:
Representan el proveedor de servicio al Cliente y al Usuario (interno o externo).

Operan con el principio de que la satisfaccin y percepcin del cliente son
crticos.
Dependen de armonizar personas, procesos y tecnologa para entregar un
servicio del negocio.
4.2 Estructuras de Service Desk
4.2.1 Service Desk Local
Tradicionalmente, las organizaciones han creado desks de soporte locales (ver

Figura 4.1) para cumplir las necesidades locales del negocio. Esto es prctico hasta
que mltiples localidades requieran servicios de soporte. Duplicar habilidades y
recursos ser muy costoso. Si su organizacin est manteniendo varios desks de
soporte local, es importante introducir estndares operacionales.
Consideraciones para implementar una estructura de Service Desk Local incluyen:
Establecer procesos comunes para todas las localidades y, cuando sea

posible, procedimientos comunes.
Hacer que las habilidades locales se conozcan y estn disponibles a otros
Service Desks.
Asegurar compatibilidad de hardware, software e infraestructura de red.
Usar los mismos procesos de escalamiento, y los mismos cdigos de
impacto, severidad, prioridad y estatus en todas las localidades.
Usar mtricas de reportes de gestin comunes.
Usar una base de datos compartida comn.
Si es posible, pasar o escalar requerimientos entre Service Desks,
preferiblemente de forma automtica.

Figura 4.1 Service Desk Local
4.2.2 Service Desk Centralizado
En esta opcin, todos los requerimientos de servicio estn registrados en una

localizacin fsica central (ver Figura 4.2). Si su organizacin tiene mltiples
localidades, tener un servicio de soporte central tiene mayores ventajas para el
negocio, tales como:
Reduccin de costos operacionales

Visin global y consolidada de la gestin
Mejor uso de los recursos disponibles
Figura 4.2 Service Desk Centralizado

44
4.2.3 Service Desk Virtual
En gran medida la ubicacin fsica del Service Desk y los servicios asociados no son
materiales, debido a los avances en el rendimiento de la red y las
telecomunicaciones. ElService Desk Virtual (ver Figura 4.3) puede ubicarse y ser
accedido desde cualquier lugar del mundo.
Si su organizacin tiene mltiples localidades, tener un servicio de soporte global

nico tiene mayores ventajas para el negocio, tales como:
Reduccin de costos operacionales

El alcance para una visin global y consolidada de la
gestin
Mejor uso de los recursos disponibles
Sin embargo, la restriccin operacional primordial del Desk Virtual es la necesidad de

la presencia fsica de un especialista o un ingeniero de reemplazo.
Figura 4.3 Service Desk Virtual
Consideraciones para montar un Service Desk Virtual incluyen los siguientes puntos:
Todas las personas que acceden al Service Desk Virtual deberan usar
procesos, procedimientos y terminologa comunes.
Un lenguaje comn, acordado debera ser utilizado para la introduccin
de datos.
Clientes y Usuarios todava necesitan interactuar con un solo punto de
contacto. Considere nmeros de telfonos globales, nmeros locales que
enrrutan al Desk Virtual y la tecnologa de Distribucin de Llamada
Automtica (ACD).
Habr necesidad de la presencia fsica in situ de un especialista o
ingeniero de mantenimiento de vez en cuando.
El rendimiento de la red debera adecuarse a su propsito. Esto debe ser
revisado en trminos de previsiones de carga de trabajo. Por ejemplo, si el

Service Desk de Holanda slo se encarga de diez requerimientos al da, entonces

el volumen de red puede que no sea de mayor consideracin. Sin embargo, un
ancho de banda reducido no es prctico si se procesan varios centenares de
requerimientos al da.
Para el Desk Virtual, las herramientas de soporte establecidas deberan permitir la
particin del trabajo y las vistas autorizadas. (Por ejemplo, si yo soy la persona
encargada del soporte local en Amsterdam, slo quiero ver los requerimientos de
esa localidad). Esto debera incluir otros procesos asociados y datos relacionados,
tales como Cambios programados, bienes y datos de configuracin.
Propiedad consistente y procesos de gestin para Incidentes deberan ser

utilizados en el Service Desk Virtual, con transferencias automatizadas de
Incidentes y vistas de Incidentes entre desks locales.
4.3 Consideraciones para la implementacin de un Service Desk
Primero establecer que la necesidad del negocio est claramente identificada y

entendida.
Asegurarse que el compromiso de la direccin, el presupuesto y los recursos estn
disponibles.
Asegurarse que la solucin propuesta se alinea con la visin y la estrategia del
Soporte de Servicio.
Identificar, alcanzar y comunicar triunfos rpidos (ej. mantener a los clientes
informados, mejora en los tiempos de instalacin).
Definir objetivos y entregables claros.
Empezar de modo sencillo; no intente hacer todo de golpe; adopte un enfoque en
fases.
Involucrar/ consultar a sus Clientes y Usuarios finales, especialmente a los ms
importantes; no use jerga.
Venda los beneficios al personal de soporte.
Capacite al personal de TI para ser personal de servicio.
Eduque/ capacite a los Clientes y Usuarios en el uso del nuevo servicio y sus
beneficios.
Anuncie y venda su servicio.
4.3.1 Consideraciones para el ambiente del Service Desk
Si es posible, proveer un cuarto/ local alejado del rea de soporte principal con:
- Un rea agradable y confortable para Clientes y personal del Service Desk
- Un ambiente de bajo nivel de ruido
- Privacidad
Instalar una biblioteca de todos sus productos, documentacin de hardware y
software y material de referencia que utilizan los Clientes.
Asegurar que un Catlogo de Servicio actualizado est disponible en todo
momento.
Instalar facilidades telefnicas de conferencia y unidades de manos libres.
Proveer espacio de mesas y asientos para discusiones de mesa redonda- esto
ayuda a calmar la situacin de ellos y nosotros.
Proveer facilidades de refrescos para ofrecer a Clientes, o al menos acceso
fcil a ellos.
Publicar a la base de Clientes la ubicacin de la unidad y sus tiempos de
operacin.

46
Resumen
El Centro de Servicios (Service Desk) provee un nico Punto de Contacto

(SPOC) con los Clientes.
Tipos de Mesas (Desks):
- Centro Telefnico (Call Centre)

- Servicio al Cliente (Help Desk)
- Centro de Servicios (Service Desk)
Estructuras de Service Desk
- Service Desk Local

- Service Desk Centralizado
- Service Desk Virtual

UNIDAD DE
APRENDIZAJE
2
TEMA
GESTIN DE LA CONFIGURACIN

dichos procesos.
TEMARIO
Objetivos Actividades
Descripcin del Proceso
Roles y Responsabilidades


48
1. OBJETIVOS
Proporcionar a todas las personas que trabajan en Gestin y Soporte de

Servicios informacin correcta y exacta de las configuraciones actuales con
sus especificaciones fsicas y funcionales.
Definir y documentar los procedimientos y prcticas del trabajo a seguir.
Identificar, etiquetar y registrar los nombres y versiones de los Cls
(Configuration Item o Elemento de Configuracin) que constituyen los
servicios TI, infraestructura y sus relaciones.
Controlar y almacenar copias definitivas, autorizadas y fiables de
especificaciones, documentacin y software.
Informar del estatus actual e historial de todos los elementos en la
infraestructura TI.
Asegurar que todos los Cambios a CIs se registran inmediatamente.
Localizar y reconciliar el estado actual de la infraestructura TI con los
historiales de configuracin autorizados y los datos.
Educar y formar a la organizacin en procesos de control.
Informar de mtricas en CIs, Cambios y Versiones.
Auditar e informar de excepciones a los estndares de infraestructura y los
procedimientos de Gestin de Configuracin.
Proporcionar informacin exacta de configuraciones y su documentacin para
soportar todos los dems procesos de Gestin de Servicio.
Proporcionar una base slida para Gestin de Incidentes, Gestin de
Problemas, Gestin de Cambios y Gestin de Versiones.
Contabilizar todos los bienes y configuraciones de IT dentro de la
organizacin y sus servicios.
Verificar los historiales de configuracin con la infraestructura y corregir las
excepciones si las hubiera.
2. ACTIVIDADES
La Gestin de Configuracin cubre la identificacin, registro, y reportes de los
componentes TI, incluyendo sus versiones, componentes constituyentes y relaciones.
Los elementos que deben estar bajo el control del la Gestin de Configuracin
comprenden hardware, software y documentacin asociada.
La Gestin de Configuracin no es sinnimo con la Gestin de Activos, aunque las

dos disciplinas estn relacionadas. La Gestin de Activos es un proceso reconocido
de contabilidad que incluye la depreciacin contable. Los sistemas de Gestin de
Activos mantienen detalles sobre un cierto valor, sus unidades de negocio y sus
localizaciones. La Gestin de Configuracin tambin mantiene relaciones entre
activos, lo cual la Gestin de Activos usualmente no hace. Algunas organizaciones
empiezan con la Gestin de Activos y luego pasan a la Gestin de Configuracin.
Las actividades bsicas de la Gestin de Configuracin son las siguientes:
Planificacin. Planificar y definir el propsito, alcance, objetivos, polticas y

procedimientos, y el contexto de organizacin y tcnico para la Gestin de
Configuracin.
Identificacin. Seleccionar e identificar las estructuras de configuracin para
todos los CIs de la infraestructura, incluyendo sus propietarios, sus
interrelaciones y la documentacin de configuracin. Esto incluye asignar

identificadores y los nmeros de versin para CIs, etiquetar cada elemento e

introducirlo en la Base de Datos de Gestin de Configuracin (CMDB).
Control. Asegurar que solo CIs autorizados e identificados son aceptados y
registrados desde la recepcin hasta la eliminacin. Esto garantiza que
ningn CI es aadido, modificado, reemplazado o eliminado sin la
documentacin de control apropiada, por ejemplo una solicitud de Cambio
aprobada, y una especificacin actualizada.
Registro de estado. Informar de todos los datos histricos y actuales que
conciernen a cada CI a lo largo de su ciclo de vida. Esto permite hacer un
seguimiento de los Cambios a CIs y de sus registros, por ejemplo rastrear el
estado de un CI y sus cambios de un estado a otro tales como en
desarrollo, en prueba, en produccin o retirado.
Verificacin y auditora. Una serie de revisiones y auditoras que verifican la
existencia fsica de CIs y que comprueban que estn correctamente
registrados en el sistema de Gestin de Configuracin.
La Gestin de Configuracin se comunica directamente con desarrollo de sistemas,

pruebas, Gestin de Cambios y Gestin de Versiones para incorporar productos
actualizados y nuevos. El pase a produccin debe ser en el tiempo planificado con
los registros precisos de configuracin.
3. DESCRIPCIN DEL PROCESO

3.1 Conceptos Bsicos
3.1.1 Bien
Componente de un proceso tal como personas, instalacin, sistemas informticos,

expedientes de papel, mquinas de fax, etc.
3.1.2 Elemento de Configuracin (CI)
Componente de una infraestructura, o un elemento, tal como una Solicitud de

Cambio, asociado con una infraestructura, y servicios, que estn (o han de estar)
bajo el control de Gestin de Configuracin. Cls pueden variar mucho en
complejidad, tamao y tipo, desde un sistema entero a un componente de hardware
menor. Ejemplos son: hardware, software, documentacin, procedimientos,
funciones, instalaciones, servicios, servidores, entornos, equipamiento, componentes
de red, escritorios, unidades mviles, aplicaciones, licencias, telecomunicacin.
3.1.3 Base de Datos de Gestin de Configuracin (CMDB)
Muchas organizaciones ya utilizan algunos elementos de Gestin de Configuracin, a

menudo usando hojas de clculo, bases de datos locales o sistemas basados en
papel. En las infraestructuras de hoy en da, grandes y complejas, la Gestin de
Configuracin requiere el uso de herramientas de soporte, que incluye la Base de
Datos de Gestin de Configuracin (CMDB). Son necesarios archivos electrnicos y
fsicos junto al CMDB para almacenar copias definitivas de software y
documentacin. Es probable que la CMDB se base en tecnologa de base de datos
que proporciona facilidades de consultas flexibles y poderosas. La CMDB debe
contener todas las relaciones entre los componentes del sistema, incluidos
Incidentes, Problemas, Errores Conocidos (KE), Cambios y Versiones. La CMDB
tambin contiene informacin sobre Incidentes, Errores Conocidos (KE) y Problemas
y datos corporativos de empleados, proveedores, localidades y unidades de negocio.

50
La CMDB tambin se puede utilizar para almacenar y controlar los detalles de los
Usuarios de TI, empleados de TI y unidades de negocio, aunque las implicaciones
legales de almacenar informacin sobre personas en la CMDB se deben considerar.
Almacenar tal informacin en la CMDB permitira que Cambios de Personal se
relacionaran con la propiedad de Cambios de CI.
3.2 Alcance y Detalle de la CMDB
3.2.1 Alcance o extensin de la CMDB
Cuando se establece una CMDB y cuando se actualiza el modelo de datos, se debe

decidir qu parte de la infraestructura TI debe controlar la Gestin de Configuracin.
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 CMDB afecta el
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. Tambin se pueden analizar los servicios TI y su
contribucin o impacto en las actividades comerciales del cliente.
El alcance se puede dividir en reas con sus propios requisitos y planteamientos (ver
Figura 5.1). Ejemplos de estas reas son estaciones de trabajo, comunicacin de
datos, archivos, servicios de impresin y aplicacin, procesamiento central, base de
datos y sistemas TI, y servicios de telefona. El alcance de la CMDB tambin puede
incluir documentacin, como SLAs, procedimientos, manuales, especificaciones
tcnicas, etc.
3.2.2 Nivel de detalle o profundidad de la CMDB
Cuando se define el nivel del sistema, se crea una jerarqua de componentes y

elementos. Se seleccionan los Cls principales o padres y se define el nmero de
niveles utilizados para el detalle. El nivel ms alto est conformado por la
infraestructura TI en s misma. El nivel ms bajo es el nivel ms detallado que se
debe controlar. Incorporar un CI a la CMDB solo resulta til si su control y la
informacin relacionada tienen algn beneficio para los procesos ITIL.
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.
Cunto menos niveles haya, menor control e informacin se tendr sobre la
infraestructura TI.
Si la CMDB no tiene muchos detalles, no se pueden monitorear los cambios de los

componentes principales. En ese caso, ante cualquier cambio a los componentes de
un CI padre se crear una variante del mismo. Por ejemplo, una PC disponible con
dos tipos de disco duro aparecer como una Variante A y una Variante B. Si hay
demasiados cambios en los componentes hijos, ser difcil y complejo mantener el
nmero de variantes.

Figura 5.1 Alcance y Detalle de la CMDB
3.3 Identificacin y atributos de CIs
3.3.1 Identificacin de CIs
El nombre de un CI debe ser nico. Cada CI en la infraestructura controlada debe ser

identificado y slo podemos hacer esto, dando a cada CI un nmero nico. Como su
automvil. Este automvil es nico en el mundo por una combinacin de nmeros en
su matrcula y el estado/ pas donde vive.
El nombre debe ser lgico y sencillo. Sencillo porque qu necesidad hay de hacerlo
difcil? Personal TI y Clientes deben tener idea de cmo leer la identificacin de un
CI. As que intente encontrar una identificacin lo ms lgica y sencilla como le sea
posible: como A1234567 en vez de PC_BUILDA_LOKI.4_ 1234.
A lo largo del ciclo vital de un CI, la primera identificacin dada debe permanecer.
Claro que la excepcin confirma la regla. As que esta es otra razn por la que no se
debe implementar nmeros como PC _BUILDA_LOKI.4_ 1234 debido a que se
relaciona con el edificio donde se instal.
3.3.2 Atributos de CIs
Los siguientes atributos (ver Tabla 5.1) son ejemplos que se pueden utilizar en la
CMDB. Note que los tipos de CI de hardware tendrn distintos atributos de los tipos
de CI de software.

52
Atributo Descripcin
Nombre de CI El nico nombre por el que se conocer este tipo de CI
Nmero de Copia o de El nmero que identifica de forma nica las instancias
Serie particulares de este CI, por ejemplo, el nmero de copia
de software, para hardware el nmero de serie
Categora Clasificacin de un CI (p.ej. hardware, software,

documentacin, etc.)
Tipo Descripcin del tipo de CI, ampliando la informacin de
categora (p.ej. configuracin de hardware, paquete de
software, aparato de hardware o mdulo de programa).
Nmero de modelo Modelo de CI (correspondiente por ejemplo al nmero
de modelo de proveedor (hardware) p.ej. Dell model
xxx, PC/aa model yyy).
Fecha de vencimiento de Fecha en la que vence la garanta del proveedor
Garanta
Nmero de Versin El nmero de versin del CI.
Localidad La localidad del CI, p.ej. la biblioteca o medio donde
reside el software del CI, el sitio/cuarto donde se
encuentra un servicio.
Propietario Responsable El nombre y/o designacin del propietario responsable
del CI
Fecha de Fecha en la que el propietario arriba mencionado se
Responsabilidad hizo responsable del CI
Fuente / Proveedor La fuente del CI, p.ej. desarrollado en la misma casa,
importada de la empresa xxxx etc.
Licencia Nmero de licencia o referencia al acuerdo de licencia
Fecha de Provisin Fecha cuando el CI fue dado a la organizacin.
Fecha de Fecha en la que el CI fue aceptado por la organizacin
Aceptacin/Instalacin como probado de modo satisfactorio.
Estatus (Actual) El estatus actual del CI; p.ej. bajo prueba,
produccin, archivado.
Estatus (programado) El prximo estatus programado del CI (con la fecha o
indicacin del evento que provocar el cambio de
estatus).
Comentario Un campo de comentario a ser utilizado para narrativa
textual; por ejemplo, para proporcionar una descripcin
de cmo esta versin del CI es distinta de la versin
anterior.
Tabla 5.1 Atributos de CIs

3.4 Relaciones en la CMDB
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.
3.4.1 Relaciones fsicas
Forma parte de, esta la relacin padre/hijo del CI, por ejemplo un disco duro
forma parte de una PC y un mdulo de software forma parte de un programa.
Est conectado a, por ejemplo una PC est conectada a un segmento LAN
Es necesario para, por ejemplo el hardware es necesario para realizar una
aplicacin
3.4.2 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, por ejemplo un CI necesario para brindar un servicio, o un
mdulo de software que comparten cierto nmero de programas
3.5 Estados de los CIs
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.
El estado de un componente tambin puede determinar lo que se puede hacer con l.

Por ejemplo, si se rastrea el estado de partes no operacionales, este hardware no
puede cambiar de lugar sin previa consulta (podra ser 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 estado:
3.5.1 Nuevos CIs
En desarrollo/pedido
valuado
Aceptado
3.5.2 CIs Existentes
Recibido
Solicitud de Cambio (RFC) abierta para la CI, nueva versin pedida
El cambio ha sido aprobado y se ha considerado en el plan, se proveer un
nuevo CI y documentacin (que tambin es un CI)
Mantenimiento en progreso Fuera de servicio

54
3.5.3 CIs Archivados
Obsolet
Borrado
Eliminado
Robado
Vendido o alquiler vencido
En almacenamiento de archivo a la espera de donacin, venta o
destruccin Destruido
3.5.4 Todos los CIs
En stock
El pedido ha sido recibido o la versin cambiada est disponible.
A prueba
Liberado para instalar
Activo, el CI est en uso
Provisin
3.6 Lnea Base (Baseline)
Una lnea base de configuracin es la configuracin de un producto o sistema

establecido en un momento concreto en el tiempo, que capta tanto la estructura como
los detalles de una configuracin. Es una referencia para ms actividades. Una
aplicacin o lnea de base de software proporciona la habilidad de cambiar o
reconstruir una versin concreta en una fecha ms adelante.
Las lneas base de configuracin se deben establecer mediante un acuerdo formal en

momentos concretos del tiempo y se deben utilizar como puntos de referencia para el
control formal de una configuracin. Las lneas base de configuracin y sus cambios
aprobados constituyen la configuracin actualmente aprobada.
Ejemplo de lnea base: un CI estndar particular que se necesita cuando se compran

muchos artculos del mismo tipo (p.ej. PC de escritorio) a lo largo de un periodo
pactado. Si unos servidores deben incluir teclados de circuito impreso adicionales,
esto podra corresponder a una lnea base plus. Si todas las PCs de escritorios en
el futuro tendrn estos teclados, se forma una nueva lnea base.
Varias lneas base correspondientes a distintas etapas en la vida de un artculo de

lnea base pueden existir en un momento dado, por ejemplo la lnea base para una
versin de software que ya est en produccin, la versin que estuvo en
produccin anteriormente y que ahora se encuentra archivada, la prxima versin
que se instalar (salvo cambios bajo control de Gestin de Configuracin) y una o
ms versiones bajo prueba. Adems, si por ejemplo una nueva versin de software
se est introduciendo gradualmente a nivel regional, ms de una versin de lnea
base podra estar en produccin a la vez.
3.7 Informes de gestin e indicadores de rendimiento
Informacin sobre la calidad de los procesos.

Cantidad de diferencias observadas entre los informes y la situacin
encontrada durante una auditora (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 auditora.
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 alcance y detalle de los CIs rastreados por la Gestin de
Configuraciones, debido a cambios del negocio, tcnicos, de precio de
mercado y otros.
Lista de costos de personal cuando se implementa el proceso.
3.8 Factores crticos de xito
Recibir la informacin necesaria para mantener la base de datos al da. Esto

significa que los vnculos con la Gestin de Cambios deben ser fuertes.
Al introducir el proceso es esencial que la implementacin se divida en
etapas. Generalmente se producen fallos porque no se puede instaurar de
una sola vez la disciplina requerida en la Gestin de Configuracin.
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 Configuracin (ganancias rpidas).
Es importante que los elementos registrados del proceso sean entregados al
personal que tenga las habilidades necesarias y la actitud correcta.
4. ROLES Y RESPONSABILIDADES
4.1 Gestor de Configuracin
Propuestas de cambio al alcance y nivel de detalle de la CMDB.

Asegurar que los procesos de la Gestin de Configuracin 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.

56
Resumen
La Gestin de Configuracin cubre la identificacin, registro, y reportes de

loscomponentes TI, incluyendo sus versiones, componentes constituyentes y
relaciones. Los elementos que deben estar bajo el control de la Gestin de
Configuracin comprenden hardware, software y documentacin asociada.
Un Elemento de Configuracin (CI) es un elemento de la infraestructura necesario

para brindar un servicio: hardware, software, documentacin, personal, etc.
La Base de Datos de Gestin de Configuracin (CMDB) es un repositorio donde

se almacenan todos los CIs junto con sus datos, trazabilidad y relaciones.

UNIDAD DE
APRENDIZAJE
2
TEMA
GESTIN DE INCIDENTES

dichos procesos.
TEMARIO
Objetivos
Actividades


58
1. OBJETIVOS
Restablecer la operacin normal del servicio tan pronto como sea

posible.
Minimizar el impacto adverso en las operaciones del negocio.
Asegurar que los niveles de calidad y disponibilidad de los servicios se
mantengan en lo establecido.
2. ACTIVIDADES
Deteccin y registro del incidente. Clasificacin y soporte inicial.

Investigacin y diagnstico. Resolucin y recuperacin.
Cierre del incidente.
Propiedad, monitoreo, seguimiento y comunicacin.

3.1 Terminologa
3.1.1 Incidente
Un Incidente es cualquier evento que no es parte de la operacin estndar de un

servicio y que causa, o puede causar, una interrupcin o una reduccin de la calidad
del servicio.
3.1.2 Workaround
Un Workaround es un mtodo de evitar un Incidente o un Problema, orientado a

restablecer el servicio. Es una solucin temporal que habitualmente reducir el
servicio. Redirigir trabajos de impresin a otra impresora en el mismo edificio es un
Workaround, el usuario puede obtener los impresos pero tendr que caminar una
distancia para obtenerlos.
3.1.3 Solicitud de Servicio

Una Solicitud de Servicio (RFC) es cada evento que no es un fallo en la
infraestructura TI, podra ser una solicitud de informacin o una solicitud de cambio
relacionado con uno de los servicios que entrega la organizacin.
3.2 Entradas y Salidas
3.2.1 Entradas
Detalles de Incidentes provenientes del Service Desk, redes u operaciones de

computadores.
Detalles de configuracin de la Base de Datos de Gestin de la Configuracin
(CMDB).
Respuesta de emparejar Incidentes con Problemas y Errores Conocidos
(KE). Detalles de resolucin.
Respuesta de RFC para resolucin de Incidentes.

3.2.2 Salidas
RFC para resolucin de Incidentes; registro de Incidentes actualizado

(incluyendo resolucin o Workaround).
Incidentes resueltos y cerrados.
Comunicacin a los Clientes.
Informacin de gestin (reportes).
3.3 El Ciclo de Vida de un Incidente
La Figura 5.1 ilustra las actividades durante el ciclo de vida de un Incidente.
Figura 6.1 Ciclo de Vida de un Incidente
3.3.1 Deteccin y Registro del Incidente
El registro de datos de acuerdo a la interrupcin o reduccin del servicio es muy

importante para:
Localizar el Incidente a lo largo de la totalidad de su ciclo de vida.

Aadir informacin til que puedan ayudar, informar y asistir a los grupos de
soporte para que puedan encontrar una solucin o un Workaround.
Recoger informacin histrica para uso futuro.
Coleccionar informacin (p.ej. para reportes) sobre nmero de Incidentes,
eficiencia, disponibilidad y anlisis de tendencias y otros procesos de gestin.

60
3.3.2 Clasificacin y Soporte Inicial
El Service Desk determina la prioridad de los Incidentes a medida que los recibe.
Consultando con el Cliente y de acuerdo a las disposiciones del SLA, el Service Desk
determinar la prioridad a partir del impacto y la urgencia de los Incidentes.
Consultar la CMDB es necesario para obtener informacin sobre el servicio que se

interrumpe, los datos de los Acuerdos de Niveles de Servicio (SLA), los Elementos de
Configuracin (CI) relacionados a este servicio y los relacionados con Incidentes
pasados y Errores Conocidos (KE).
3.3.3 Investigacin y Diagnstico
Otros grupos de soporte empezarn a analizar el Incidente con el propsito de

encontrar una solucin permanente o un Workaround.
3.3.4 Resolucin y Recuperacin
Despus de haber completado el anlisis y de haber resuelto el Incidente

satisfactoriamente, se registra la solucin en el sistema. Para algunas soluciones, se
tendr que emitir una Solicitud de Cambio (RFC) a la Gestin de Cambios. En el peor
de los casos, si no se encuentra la solucin, el Incidente permanece abierto.
3.3.5 Cierre del Incidente
Una vez que se implement una solucin satisfactoria para el Usuario, el grupo de
soporte direcciona el Incidente otra vez al Service Desk. Se contacta a la persona
que inform sobre el Incidente para verificar que todo est 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.
3.3.6 Propiedad, Monitoreo, Seguimiento y Comunicacin
En muchos casos, el Service Desk, como dueo de todos los Incidentes, es

responsable del monitoreo del progreso y debe informar al Usuario sobre el estado
del Incidente. Durante el seguimiento y monitoreo pueden haber escalamientos.
3.4 Impacto, urgencia y prioridad
3.4.1 Impacto del Incidente
Grado de desviacin sobre las operaciones normales, en trminos de nmeros de

Usuarios o de procesos del negocio afectados.
3.4.2 Urgencia
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 Incidentes

con la misma prioridad, el esfuerzo (personas, recursos, tiempo) que se deba poner
en cada uno determinar el orden.
El impacto y la urgencia se pueden combinar en una matriz como la de la Figura 5.2.

Figura 6.2 Ejemplo de un sistema de codificacin de una prioridad
3.5 Primera, segunda y subsiguientes lneas de soporte
Con frecuencia, los departamentos y grupos de soporte (especialistas), que no sea el

Service Desk, son referidos como grupos de soporte de segunda o tercera lnea, que
tienen ms habilidades especialistas, tiempo u otros recursos para resolver
Incidentes. En este sentido, el Service Desk sera el soporte de primera lnea.
Se tiene el siguiente procedimiento tradicional para el escalamiento del Incidente en

las diferentes lneas de soporte (ver Figura 5.3):
Paso 1. Intento de resolucin del Incidente por parte del Service Desk. Llevar
a cabo la evaluacin inicial y buscar una solucin o Workaround. Si se
encuentra una solucin, cerrar el Incidente. Si no, referirlo al siguiente nivel.
Paso 2. Asignar el Incidente al soporte de segunda lnea. Si no se puede
encontrar ninguna solucin en el Service Desk, referirlo al soporte de
segunda lnea. Si el soporte de segunda lnea puede encontrar una solucin,
referir de nuevo al Service Desk que cerrar el Incidente. Si no, referirlo al
siguiente nivel.
Paso 3. Asignar el Incidente al soporte de tercera lnea. Si no se puede
encontrar ninguna solucin en el soporte de segunda lnea, referirlo al soporte
de tercera lnea. Si el soporte de tercera lnea puede encontrar una solucin,
referir de nuevo al Service Desk que cerrar el Incidente. Si no, referirlo al
siguiente nivel.
Paso 4. Asignar el Incidente al especialista. Si no se puede encontrar
ninguna solucin en el soporte de tercera lnea, referir a un especialista. Si el
especialista puede encontrar una solucin, referir de nuevo al Service Desk
que cerrar el Incidente.
Si no est claro qu grupo de soporte debera investigar o resolver un Incidente

relacionado con un Usuario, el Service Desk, como dueo de todos los Incidentes,
debera coordinar el proceso de Gestin de Incidentes o referirlo al equipo de Gestin
de Problemas.

62
Notar que el soporte de tercera o n-lnea puede eventualmente incluir proveedores

externos que pueden tener acceso directo a la herramienta de registro del Incidente
(dependiendo de las normas de seguridad y aspectos tcnicos).
Figura 6.3 Escalamiento del Incidente en lneas de soporte
3.6 Escalamiento
3.6.1 Escalamiento funcional (horizontal)
Significa involucrar ms personal especializado o privilegios de acceso (autoridad tcnica)

para solucionar el Incidente, pudindose exceder los lmites del departamento.
3.6.2 Escalamiento jerrquico (vertical)
Significa que se realiza un movimiento vertical (a niveles ms altos) en la

organizacin porque la autoridad (autoridad de la organizacin, poderes) o recursos
necesarios para resolver el Incidente son insuficientes.
3.7 Informes de gestin
El control del proceso se basa en los informes de los diferentes grupos designados.
El Gestor de Incidentes es responsable de estos informes, de la elaboracin de la
lista de distribucin y del calendario de informes. Los informes deben ser muy
detallados y adaptados a las necesidades de los siguientes gestores:

3.7.1 Gestor de Incidentes
Partes faltantes en el proceso

Conflictos con los acuerdos
Desarrollo de los procesos
Tendencias
3.7.2 Gestor del grupo de soporte
Control dentro de cada departamento Progreso de

resolucin del proceso
Ciclo horario del Incidente en los distintos grupos de
soporte
3.7.3 Gestor de los Niveles de Servicio
Calidad de los servicios brindados

Todos los informes necesarios para que Nivel de Servicios los informe a los
Clientes
Innformacin para los Clientes que especifique si se han cumplido los acuerdos
con respecto a Niveles de servicio dentro del proceso de Gestin de Incidentes
3.7.4 Gestores de otros procesos de Gestin de Servicios
Nmero de Incidentes informados y registrados

Nmero de Incidentes resueltos, subdivididos por la resolucin de tiempo
Estado de Incidentes sin resolver y el nmero de 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.
Una CMDB actualizada 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
Problemas y Errores Conocidos que describa cmo 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.
3.9 Indicadores de rendimiento
La evaluacin de procesos de rendimiento necesita de parmetros claramente

definidos y objetivos mensurables, a menudo llamados Indicadores de Rendimiento
(PKI). 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:

64
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 Service
Desk Incidentes resueltos sin visitar al Usuario
Nmero de Incidentes (o porcentaje) con clasificacin inicial
incorrecta Nmero de Incidentes (o porcentaje) mal direccionados
Los procesos abarcan la jerarqua de la organizacin. Por consiguiente es importante
definir las responsabilidades asociadas con las actividades que tienen que realizarse
en el proceso. Para ser flexibles, es aconsejable usar el concepto de roles; en
muchas organizaciones los roles pueden ser combinados debido al tamao pequeo
de la organizacin o por razones de costos. Por ejemplo, muchas organizaciones
combinan los roles de Gestin del Cambio y de Gestin de la Configuracin. Una rol
abarca un conjunto de responsabilidades, tareas y niveles de autorizacin.
4.1 Gestor de Incidentes
En muchas organizaciones, el rol de Gestor de Incidentes es asignado al Supervisor

del Service Desk.
Conducir la eficiencia y la efectividad del proceso de la Gestin de

Incidentes Producir informacin de gestin
Gestionar el trabajo del personal de soporte de Incidentes (primera y segunda
lnea)
Monitorear la efectividad de la Gestin de Incidentes y recomendar
mejoras Desarrollar y mantener los sistemas de Gestin de Incidentes.
4.2 Personal de soporte para el manejo de Incidentes
4.2.1 Soporte de primera lnea (Service Desk)
Registro de Incidentes
Encaminamiento de los requerimientos de servicio a grupos de soporte
cuando los Incidentes no estn cerrados
Soporte inicial y clasificacin
Propiedad, monitoreo, seguimiento y comunicacin
Resolucin y restablecimiento de los Incidentes no asignados al soporte de
segunda lnea
Cierre de los Incidentes
4.2.2 Soporte de segunda lnea
Grupos de especialistas que pueden ser parte del Service Desk.
Manejo de los requerimientos de servicio

Monitoreo de los detalles de los Incidentes, incluyendo los Elementos

de Configuracin (CI)
Investigacin de Incidentes y diagnstico (incluyendo la resolucin si
es posible)
Deteccin de posibles Problemas y el encargo a ellos de la gestin del
problema, con tal de aumentar los registros de problemas
La resolucin y restablecimiento de los incidentes asignados

66
Resumen
La Gestin de Incidentes busca restablecer la operacin normal del servicio tan

pronto como sea posible.
Un Incidente es cualquier evento que no es parte de la operacin estndar de un

servicio y que causa, o puede causar, una interrupcin o una reduccin de la
calidad del servicio.
Un Workaround es un mtodo de evitar un Incidente o un Problema, orientado a

restablecer el servicio. Es una solucin temporal que habitualmente reducir el
servicio.

UNIDAD DE
APRENDIZAJE
2
TEMA
GESTIN DE PROBLEMAS

dichos procesos.
TEMARIO
o Objetivos
o Actividades


68
1. OBJETIVOS
Minimizar el impacto adverso de Incidentes y Problemas en el negocio

causados por errores en la infraestructura TI.
Prevenir la recurrencia de Incidentes relacionados con estos errores.
Encontrar la causa raz de los Incidentes e iniciar las acciones para mejorar o
corregir la situacin.
2. ACTIVIDADES
2.1 Control de Problemas
Esta funcin realizar anlisis de tendencias, registrar problemas y realizar anlisis

de causas de raz a fin de encontrar una solucin permanente.
2.2 Control de Errores Conocidos
Controla los Errores Conocidos (Known Errors-KE) y genera RFCs a Gestin de

Cambios para eliminar los Errores Conocidos de la infraestructura. Mantiene las
bases de datos de conocimiento de Errores Conocidos y Workarounds. Publica los
Errores Conocidos para que Gestin de Incidentes pueda resolverlos si vuelven a
ocurrir. Investiga si Problemas o Errores Conocidos estn presentes en otras partes
de la infraestructura controlada.
2.3 Prevencin Proactiva
Previene la introduccin de nuevos Incidentes y Problemas.
2.4 Identificar Tendencias
Esta funcin monitorea activamente los Incidentes y con el uso de mtodos

estadsticos intenta identificar tendencias para que se puedan reconocer Problemas.
Las tendencias por s solas habitualmente no son suficientes para identificar un
Problema, es necesaria la destreza humana para determinar si la tendencia lleva a
un Problema.
2.5 Informacin de Gestin
Crea informes sobre la efectividad y el rendimiento de la Gestin de Problemas y

proporciona esta informacin a la Direccin y otros procesos.
2.6 Revisin de Post Implementacin (PIR)
Gestin de Problemas archiva las Solicitudes de Cambios (RFC). Slo despus de

implementar un Cambio, puede determinar si el Cambio ha producido la reduccin o
la eliminacin del Incidente. La Revisin de Post Implementacin (PIR) comprueba si
se da el caso.


3.1 Terminologa
3.1.1 Problema
Un Problema describe una situacin no deseada, indicando la causa raz

desconocida de uno o ms Incidentes existentes o potenciales.
3.1.2 Error Conocido
Un Error Conocido es un problema del que se ha determinado la causa. El Error es

eliminado mediante la implementacin de un Cambio.
3.2.1 Entradas
Detalles de Incidentes
Detalles de configuracin
Workarounds efinidos
3.2.2 Salidas
Errores Conocidos
Solicitudes de Cambio
Registro de Problemas actualizado, incluyendo soluciones o Workarounds
Respuesta del emparejamiento de Incidentes con Problemas y Errores
Conocidos
Informacin de gestin
3.3 Control de Problemas
Las actividades de Control de Problemas se pueden observar en la Figura 8.1.
3.3.1 Identificacin y Registro
Si hubo un Incidente con considerable impacto que se ha solucionado, lo ms

probable es que el Gestor de Problemas registre el inconveniente donde
iniciar una investigacin para encontrar la raz del problema.
Durante el anlisis de tendencias se puede encontrar un nmero de
Incidentes con sntomas similares.
Si se descubre una fuente potencial de Problemas.
Si un Incidente se cierra con el cdigo Workaround.
3.3.2 Clasificacin
Qu CIs estn involucrados;

Cules son los Incidentes relacionados; Cules son los sntomas;
Cules son las causas;
Cules son las resoluciones/ Workaround;
Cules son los Cambios relacionados a este CI;

70
Qu niveles de servicio estn relacionados; Cul es el peligro;

Qu Clientes estn implicados;
Cunto tiempo necesitamos (esperamos) para encontrar una solucin (tanto
de duracin como de esfuerzo);
Con cunta urgencia necesitamos resolver el problema;
Cunto es el posible beneficio si solucionamos el problema (impacto); Basado
en esta informacin se asigna Impacto y urgencia (=prioridad).
Figura 8.1 Control de Problemas
3.3.3 Asignar Recursos
Despus de la clasificacin, se pueden priorizar los problemas ms importantes con

el impacto de negocio ms alto. Basado en el nmero de recursos que se tienen, se
pueden asignar o reasignar problemas a los recursos disponibles.
3.3.4 Investigacin y Diagnstico
El objetivo de la investigacin y diagnstico es detectar la causa subyacente de uno o

ms Incidentes. Las actividades de investigacin deberan incluir los Workarounds
disponibles para los Incidentes relacionados con el Problema, los Cambios recientes
y la informacin histrica de Cls de la CMDB.
3.3.5 Establecer el Error Conocido
Despus de la fase anterior, se determinar el Error Conocido. Esta fase registra que
un Error es Conocido y pasa el Error al proceso de Control de Errores.

3.4 Control de Errores
Las actividades de Control de Errores se pueden observar en la Figura 8.2.
Figura 8.2 Control de Errores
3.4.1 Identificacin y Registro
Un error se identifica cuando se detecta un CI roto. Un estado de Error Conocido se

asigna cuando se encuentra la causa raz de un Problema.
3.4.2 Evaluacin
Este paso realiza una evaluacin inicial de los medios para resolver el Error, en
colaboracin con personal especialista. El proceso de resolucin para cada Error
Conocido debe ser grabado en el sistema de Gestin de Problemas. Es vital que los
datos de los CIs, sntomas y acciones de resolucin o Workaround relacionados con
todos los Errores Conocidos se registren en la base de datos de Errores Conocidos
para que estn disponibles para emparejamiento de Incidentes, proporcionando una
gua para futuras investigaciones y para proporcionar informacin de gestin.
3.4.3 Registro de Resolucin
El paso registra una resolucin de un Error y completa una RFC de acuerdo con los
procedimientos de Gestin de Cambio. La prioridad de la RFC se determina por la
urgencia e impacto del Error en el negocio. El identificador de la RFC debera
incluirse en el registro del Error Conocido y viceversa a fin de mantener un rastro de
auditora completo, o se deben enlazar los dos registros. Las etapas finales de la
resolucin de un Error (anlisis de impacto, evaluacin detallada de la accin de
resolucin a llevar a cabo, modificacin del CI con Error, y la prueba del Cambio)
estn bajo el control de Gestin de Cambio.

72
3.4.4 Cierre
Tras implementar con xito los Cambios (determinado por la Revisin Post
Implementacin) para resolver Errores, el Error Conocido relevante se cierra, junto a
los expedientes de Incidentes o Problemas relacionados.
3.5 Incidentes versus Problemas
Incidentes y Problemas (y Cambios) son entidades separadas. No es cierto que

cuando hay un Problema, el Incidente que inici el Problema ha desaparecido. La
Figura 8.3 muestra un modelo en el que Incidentes, Problemas e incluso Cambios
estarn vivos simultneamente.
Figura 8.3 Incidentes versus Problemas
3.5.1 Comienzo: Solo un Incidente
Cuando ocurre un Incidente, el proceso de Gestin de Incidentes intentar resolverlo

cuanto antes. El Incidente solo se puede cerrar una vez resuelto. Durante la fase de
Investigacin del Incidente no se encuentra ninguna solucin. El proceso de Gestin
de Incidentes entonces busca la ayuda de Gestin de Problemas porque la causa
raz de los Incidentes se tiene que determinar en primer lugar.
3.5.2 Investigacin y Escalamiento: Incidente y Problema existen simultneamente
La Gestin de Problemas define un Problema con alta urgencia e inmediatamente

asigna recursos. Esos recursos diagnostican el Problema y encuentran la causa raz
del Incidente subyacente.
3.5.3 Diagnstico: Incidente, Problema y Error Conocido existen simultneamente
Definen un Error Conocido y tras averiguar cmo resolverlo emiten una RFC a
Gestin de Cambio para resolver la situacin.

3.5.4 Cambio en trmite: Incidente, Problema, Error Conocido y Cambio existen

simultneamente
El Cambio se implementa con xito. La Revisin Post Implementacin muestra que el

Cambio realmente ha eliminado el Error Conocido con xito. La investigacin muestra
tambin que el Incidente se ha resuelto y el Problema, por lo tanto, se puede cerrar
tambin.
3.5.5 Final: Incidente resuelto, Cambio, Problema y Error Conocido cerrados
Si en algn momento durante la fase de diagnstico el equipo de Problemas

encuentra un Workaround, el Incidente se resolver antes. Esto no significa que el
Problema ya no exista. El nico cambio en registro del Problema ser que la urgencia
caer de urgente a no urgente. El proceso de Problemas decidir si hay recursos
suficientes libres en ese momento para realizar el diagnstico del Problema o si esos
recursos sern mejor utilizados en otro lugar.
3.6 Gestin de Problemas Proactiva
Las actividades descritas hasta ahora en el Control de Errores y Problemas son

principalmente reactivas. Las actividades de Gestin de Problemas Proactiva tratan
de identificar y resolver Problemas y Errores Conocidos antes de que ocurran
Incidentes, dicho de otro modo minimizan el impacto adverso en el servicio y los
costos relacionados con el negocio. La prevencin de Problemas va desde la
prevencin de Problemas individuales hasta decisiones estratgicas que requieran
mayor gasto de implementacin, tal como una inversin en una mejor red de
conexin.
Las actividades principales dentro de los procesos de Gestin de Problemas

Proactiva son el anlisis de tendencias y el marcar objetivos de accin preventiva. El
anlisis de tendencias puede llevar a la identificacin de fallos en la infraestructura TI,
los cuales pueden ser analizados y corregidos como se describe en las secciones de
Control de Errores y Problemas. El anlisis de tendencias tambin puede llevar a la
identificacin de reas de Problemas generales que necesitan ms atencin de
soporte. Debera ser posible hacer comparaciones significativas al expresar esto en
trminos de costo financiero para la organizacin.
Los informes de anlisis de Problemas e Incidentes proporcionan informacin de

medidas proactivas para mejorar la calidad de servicio. El objetivo es identificar los
componentes frgiles de la infraestructura TI e investigar las razones para la
fragilidad. En este contexto la fragilidad es proporcional al impacto al negocio si falla
el CI.
La categorizacin de Incidentes y Problemas y el anlisis de los mismos pueden

revelar tendencias y llevar a la identificacin de reas de Problemas especficos
(potenciales) que necesitan ms investigacin. Por ejemplo, el anlisis puede indicar
que los Incidentes relacionados con la utilidad de los sistemas cliente-servidor
recientemente instalados sean el rea de Problemas que tiene ms crecimiento en
trminos de impacto negativo en el negocio.
El xito de la Gestin de Problemas se demuestra a travs de:

74
La reduccin de la cantidad de Incidentes, resolviendo

problemas.
La reduccin del tiempo necesario para resolver problemas.
Disminucin de otros costos asociados con la resolucin.
Los informes de la Gestin de Problemas pueden cubrir los siguientes temas:
Informe de tiempo
Calidad del producto
Eficacia de la Gestin de Problemas
Relacin entre la Gestin de Problemas reactiva y proactiva Calidad de los
productos en desarrollo
Estado y planes de accin para problemas abiertos Propuestas para mejorar la
Gestin de Problemas
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.
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.
4.1 Gestor de Problemas
Desarrollar y mantener el Control de Problemas y Control de Errores

Evaluar la eficiencia y la eficacia del 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
4.2 Personal para el manejo de Problemas
4.2.1 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

4.2.2 Responsabilidades proactivas
Identificar las tendencias

Elevar RFCs
Prevenir que los Problemas no se extiendan a otros sistemas

76
Resumen
La Gestin de Problemas busca encontrar la causa raz de los Incidentes e iniciar

las acciones para mejorar o corregir la situacin.
Un Problema describe una situacin no deseada, indicando la causa raz

desconocida de uno o ms Incidentes existentes o potenciales.
Un Error Conocido es un problema del que se ha determinado la causa. El Error

es eliminado mediante la implementacin de un Cambio.

UNIDAD DE
APRENDIZAJE
2
TEMA
GESTIN DE CAMBIOS

dichos procesos.
TEMARIO
Objetivos
Actividades


78
1. OBJETIVOS
El objetivo del proceso de Gestin de Cambios es asegurar que se utilizan

procedimientos y mtodos estandarizados para el manejo eficiente y puntual de
todos los Cambios, a fin de minimizar el impacto de stos sobre la calidad de
servicio y como consecuencia mejorar las operaciones cotidianas de la
organizacin.
2. ACTIVIDADES
La Gestin de Cambios es responsable de dirigir el proceso de Cambios. Este
proceso no est a cargo de implementar Cambios, slo controlar que se aprueben
stos y que se implementen de forma eficiente y efectiva en lo que se refiere a costos
y con un mnimo riesgo para los servicios nuevos y existentes. Para evaluar el riesgo
de cada Cambio es muy importante tener una idea de la Configuracin que
controlamos, por lo cual necesita de la Gestin de Configuracin.
La Gestin de Cambios tambin es responsable de alcanzar los Cambios que se van

a programar. Solamente Cambios programados y adecuadamente sincronizados
pueden ser controlados. Lo ms importante es tener una percepcin de los recursos
que se requieren y que estn disponibles.
La comunicacin es la clave en un proceso de Cambio exitoso. Una falta de

comunicacin es muy a menudo la razn para que los Cambios no se implementen
bien y que ocurran Incidentes.
El proceso de Gestin de Cambios posee las siguientes actividades:
2.1 Solicitud de Cambio
Una RFC es el comienzo de un ciclo de la vida de un Cambio.
2.2 Registro y Clasificacin
Recoger la informacin necesaria para tomar decisiones sobre qu se ha de cambiar

y cul ser la categora y el impacto para que la autorizacin se pueda hacer
correctamente. Se asigna una prioridad y categora que se basan en el impacto del
Cambio. La evaluacin de riesgo es de una importancia crucial en este momento.
2.3 Monitorear y Programar
Todos los cambios se programarn y un plan (con hitos) ser proporcionado si es

necesario para el control ptimo de los Cambios.
2.4 Aprobar
Decidir si el Cambio se va a manejar o no.
2.5 Construir y Probar
Las RFCs autorizadas debern ser pasadas a los grupos tcnicos relevantes para la
construccin de Cambios. La Gestin de Cambios tiene un rol de coordinacin,
apoyado por la Gestin de Versiones y la Direccin para asegurar que las actividades
tengan recursos y se completen de acuerdo con el programa. Para prevenir que los

Cambios impacten en la calidad de servicio, se recomienda que los Cambios se

prueben rigurosamente por adelantado (incluidos procedimientos de retroceso, vuelta
atrs o backout).
2.6 Autorizar Implementacin
Despus de una prueba adecuada y la comprobacin de que todo lo necesario se ha

llevado a cabo, se puede autorizar la implementacin del Cambio.
2.7 Implementacin
La Gestin de Cambios tiene la responsabilidad de asegurar que los Cambios se

implementen segn programa, aunque esto ser en gran medida un rol de
coordinacin ya que la implementacin ser la responsabilidad de otros (p.ej.
ingenieros llevando a cabo Cambios de hardware).
2.8 Evaluar
La Gestin de Cambios debe evaluar todos los Cambios implementados despus de

haber transcurrido un periodo predefinido. Esto se puede hacer con la Revisin de
Post Implementacin. Este proceso puede involucrar miembros del Comit de
Asesoramiento de Cambios (CAB).

3.1 Terminologa
3.1.1 Cambio
Adicin, modificacin, eliminacin o retorno a la lnea base aprobado de cualquier CI.
3.1.2 Solicitud de Cambio (RFC)
Formulario usado para registrar los detalles de un requerimiento de Cambio.
3.1.3 Programa Adelantado de Cambios (FSC)
Programa que contiene los detalles de todos los Cambios aprobados para
implementar y sus fechas propuestas de implementacin.
3.1.4 CAB
Comit de Asesoramiento de Cambios o Change Advisory Board.
3.1.5 CAB/EC
Comit de Emergencia del CAB.
3.2 Inputs y Outputs
3.2.1 Inputs
RFCs
CMDB

80
FSC
3.2.2 Outputs
FSC
RFCs
Acciones y minutas del CAB Informes de gestin
3.3 Solicitud de Cambio (RFC)
Las Solicitudes de Cambio son el comienzo del ciclo de vida del Cambio y pueden
referirse a cualquier parte de la infraestructura, servicio o actividad. Todas las RFCs
se deben registrar y contar con un nmero de identificacin.
Los siguientes elementos se pueden incluir en el formulario de la RFC:
El nmero de RFC (ms la referencia al nmero de informe de Problema, de

ser necesario)
Descripcin e identidad de los elementos a cambiar (incluidas las
identificaciones de los CIs )
Razn para el Cambio
Efecto de no implementar el Cambio
Versin del CI a ser cambiado
Nombre, localizacin y nmero de telfono de la persona que propone el
Cambio
Fecha en la que se propuso el Cambio
Prioridad del Cambio
Evaluacin del impacto y recursos (que pueden estar en formularios
separados de ser necesario)
Recomendaciones del CAB en caso de ser apropiado (que se pueden tener
por separado, con impactos y recursos donde sea conveniente)
Firma de autorizacin (podra ser
electrnica) Fecha y hora de autorizacin
Implementacin programada (identificacin, fecha y
hora) Localizacin del plan de implementacin
Detalles del constructor / responsable de implementar el
Cambio Plan de retroceso o marcha atrs
Fecha y hora de la implementacin
real Fecha de revisin
Resultados de la revisin (incluida la contra referencia a la nueva RFC de ser
necesario)
Gestin y evaluacin de riesgo
Impacto en la continuidad del negocio y planes de contingencia
Estado de la RFC: registrada, evaluada, rechazada, aceptada,
dormida
A medida que el Cambio transcurra por su ciclo de vida, la RFC debe ser actualizada
para que la persona que inici el Cambio est al tanto de su estado. Los recursos
actuales utilizados y los costos incurridos se deben registrar como parte de la RFC.

3.4 Determinacin de la prioridad
Una vez aceptada la RFC, se indica la prioridad y la categora de la misma. La

prioridad indica la importancia del Cambio y se dirige por el impacto y la urgencia. El
cdigo de prioridad ya puede estar atribuido por la Gestin de Problemas, pero los
cdigos definitivos estn determinados por la Gestin de Cambios, considerando
cualquier RFC pendiente de discusin.
A continuacin se presenta un ejemplo de cdigos de prioridad:
Prioridad 0, la prioridad ms alta: La RFC trata de un Problema, lo que causa

una inmensa molestia en el uso de servicios esenciales, o concierne un
ajuste urgente de TI (por ejemplo una nueva funcionalidad a causa de
consideraciones de la compaa o una pequea ley de emergencia). Los
Cambios en esta prioridad caen bajo la categora de Cambios Urgentes. Los
Cambios Urgentes se difieren de los procedimientos normales porque los
recursos necesarios necesitan estar disponibles inmediatamente. Una
reunin de emergencia del CAB o el comit dirigente de TI puede ser
necesaria.
Prioridad 1, alta prioridad: Causa problemas tcnicos severos para un gran
nmero de usuarios o concierne otras situaciones urgentes. Este Cambio
obtiene la prioridad ms alta en la prxima reunin programada del CAB.
Prioridad 2, prioridad normal: No representa una emergencia o alto impacto
pero el Cambio no se puede posponer. Este Cambio dentro del CAB recibe
prioridad normal con la atribucin de recursos.
Prioridad 3, baja prioridad: Un Cambio es deseado pero podra esperar hasta
un momento ms conveniente (por ejemplo la prxima implementacin o
mantenimiento programado).
3.5 Determinacin de la categora
Las categoras las atribuye el Gestor de Cambios, cuando es necesario en

deliberacin con el CAB, e indican el impacto del Cambio y la demanda de recursos
que tiene para la organizacin TI.
A continuacin se presenta un ejemplo de categoras:
Categora 1, pocas consecuencias: Un Cambio que no conlleva mucho trabajo. El

Gestor de Cambios puede aprobar este tipo de Cambios sin consultar con el
CAB.
Categora 2, consecuencias sustanciales: Cambios que requieren esfuerzos
mayores y que tienen mayor impacto en los servicios. Tales Cambios se discuten
en la prxima reunin del CAB para predecir los esfuerzos necesarios y posibles
consecuencias. Antes de la reunin, la documentacin necesaria ser enviada a
los miembros del CAB y potencialmente a varios especialistas y encargados de
desarrollo.
Categora 3, consecuencias inmensas: Un Cambio que requiere una gran
cantidad de esfuerzo. El Director de Cambios necesita obtener autorizacin de la
Direccin TI o un Comit Dirigente TI y luego debe discutirlo con el CAB.
3.6 Comit de Asesoramiento de Cambios (CAB)
El CAB existe para aprobar la mayora de los Cambios y para asistir a la Gestin de
Cambios en la evaluacin y priorizacin de Cambios. Siempre y cuando se convoque
al CAB, los miembros elegidos deben ser capaces de evaluar adecuadamente desde

82
un punto de vista tanto tcnico como de negocio. Para alcanzar esta combinacin, el
CAB necesita incluir personas con un entendimiento claro de las necesidades de
negocio del Cliente y de la comunidad Usuaria, adems de las funciones de
desarrollo tcnico y de soporte.
Los miembros del CAB podran ser el Gestor de Cambios, Cliente(s), Director(es) de
Usuarios, representante(s) del grupo de Usuarios, encargados de desarrollo
/mantenimiento de aplicaciones, consultores tcnicos, expertos, personal de servicio
(segn la necesidad), personal de servicios de oficina (donde los Cambios puedan
afectar las instalaciones), contratantes y representantes de terceros segn demanda,
por ejemplo en contratar a terceros (outsourcing).
Es importante enfatizar que el CAB:
Estar compuesto de acuerdo con los Cambios considerados

Puede variar considerablemente en su composicin incluso a lo largo de una
sola reunin
Debera involucrar a proveedores cuando sea de utilidad
Debera reflejar los puntos de vista tanto del Cliente como del usuario
Es probable que incluya al Gestor de Problemas y el Gestor de Nivel de Servicio
y personal de Atencin al Cliente segn la situacin y en funcin del tiempo
Cuando surjan Problemas mayores, puede que no haya tiempo de crear el CAB
entero, y por lo tanto es necesario identificar una organizacin ms pequea con
autoridad para tomar decisiones de urgencia, la cual se conoce como el Comit de
Emergencia del CAB (CAB/EC). Los procedimientos de Cambio deben especificar
cmo el formato del CAB y CAB/EC se determinar en cada instancia. La
composicin del CAB/EC proporcionar la habilidad, tanto desde el punto de vista del
negocio como tcnico, de tomar decisiones en cualquier eventualidad concebible.
3.7 Relaciones con otros procesos
La Gestin de Cambios y de Configuracin estn muy relacionados. El proceso de

Verificacin de la Gestin de Configuracin se puede usar para controlar la efectividad de
la Gestin de Cambios. Si, tras la verificacin, el Gestor de Configuracin ha encontrado
CIs que no estn en la base de datos hay dos opciones:
La base de datos no est actualizada, que puede indicar que no se inform a

la Gestin de Configuracin del Cambio.
Alguien ha ejecutado un Cambio ilegal no aprobado.
El campo ms importante donde se relacionan los procesos es en el anlisis de

impacto y riesgo de un Cambio (ver Figura 9.1). La mayor parte de esto se tiene que
hacer con la ayuda de la CMDB. El envo de una RFC implica averiguar:
Qu CI o Cls se tienen que cambiar y cul es el impacto en la infraestructura

existente.
Si esta RFC resultar en ms RFCs por el hecho de tener que cambiar ms
Cls como resultado de esta solicitud.
Si el Cambio slo afecta a uno o ms usuarios, una o ms reas o uno o ms
servicios a fin de asignar el cdigo correcto de impacto a este Cambio.

Basado en todo esto, se puede decidir si el CAB es necesario, a quin se tiene

que invitar, en qu nivel se tiene que discutir y aprobar el Cambio y poder
generar la lista de actividades ms completa.
Figura 9.1 Relaciones con otros procesos
Considere los datos y estadsticas a continuacin en los informes de Gestin de

Cambios y como indicadores de rendimiento:
El nmero de Cambios implementados en el periodo, en total y por CI, tipo de

configuracin, servicio, etc.
Un desglose de razones para el Cambio (solicitudes de Usuarios, mejoras,
requisitos del negocio, llamadas de servicio, Incidentes, Problemas, mejoras
de procedimientos, etc.).
El nmero de Cambios con xito.
El nmero de Cambios retrocedidos, junto a las razones (p.ej. evaluacin
incorrecta, mala construccin).
El nmero de Incidentes que llevan a Cambios (desglosados por niveles de
severidad de Problemas) y las razones (p.ej. evaluacin incorrecta, mala
construccin).
El nmero de RFCs (y tendencias en proceso de originarse).
El nmero de Cambios implementados revisados.
Cifras de periodos anteriores.
El nmero de RFCs rechazadas.
La proporcin de Cambios implementados que no tienen xito (en total y
desglosado por CIs)
Atrasos de Cambios, desglosados por CI y por etapa en el proceso de
Gestin de Cambios.

84
4.1 Gestor de Cambios
Recibir, registrar y asignar una prioridad, en colaboracin con el solicitante,

de todas las RFCs. Rechazar cualquier RFC que no sea completamente
prctica.
Presentar todas las RFCs para una reunin del CAB, publicar una agenda y
hacer circular todas las RFCs a los miembros del CAB antes de las reuniones
para permitir consideraciones previas.
Decidir qu personas irn a qu reuniones, dependiendo de la naturaleza de
la RFC.
Convocar CAB urgentes o reuniones CAB/EC para todas las RFCs
urgentes. Presidir todas las reuniones CAB y CAB/EC.
Despus de la consideracin del consejo dado por CAB o CAB/EC, autorizar
cambios aceptables.
Publicar FSCs, via Service Desk.
Comunicar con todos los grupos para coordinar la construccin de Cambios,
prueba e implementacin, de acuerdo con los programas.
Actualizar el registro de Cambios con todos los avances que ocurran,
incluyendo cualquier accin para corregir Problemas y/o aprovechar para
mejorar la calidad del servicio.
Revisar todos los Cambios implementados para asegurar que hayan
conseguido los objetivos completamente. Remitir de vuelta cualquiera que
haya retrocedido o haya fallado.
Revisar todas las RFCs importantes que esperan consideracin o accin.
Analizar los registros de Cambios para determinar cualquier tendencia o
Problema aparente que ocurra. Buscar rectificaciones con los grupos
relevantes.
Cerrar RFCs.
Producir informes de gestin regulares y exactos.

Resumen
Un Cambio es una adicin, modificacin, eliminacin o retorno a la lnea base

aprobado de cualquier CI.
Una Solicitud de Cambio (RFC) es un formulario usado para registrar los detalles
de un requerimiento de Cambio.
El CAB es el Comit de Asesoramiento de Cambios o Change Advisory Board

que aprueba la mayora de los Cambios y asiste a la Gestin de Cambios en la
evaluacin y priorizacin de stos.

86

UNIDAD DE
APRENDIZAJE
3
TEMA
GESTIN DE VERSIONES

dichos procesos.
TEMARIO
Objetivos
Actividades


88
1. OBJETIVOS
Planificar y supervisar el despliegue de software y hardware.

Disear e implementar procedimientos eficientes para la distribucin e instalacin
de Cambios en los sistemas TI.
Asegurar que el hardware y el software que se cambia se puedan localizar, sean
seguros y que solo se instalen versiones correctas, autorizadas y probadas.
Comunicar y gestionar las expectativas del Cliente durante la planificacin y
despliegue de nuevas Versiones.
Acordar el contenido exacto y plan de despliegue de la Versin con la Gestin de
Cambios.
Implementar nuevas Versiones de software y hardware en el ambiente operativo
usando los procesos de control de Gestin de Configuracin y Gestin de
Cambios. Una Versin debe estar bajo la Gestin de Cambios y puede consistir
de cualquier combinacin de hardware, software, firmware y documentos CI.
Asegurar que las copias maestras de todo el software estn seguras en la
Biblioteca de Software Definitiva (DSL) y que la Base de Datos de Gestin de
Configuracin (CMDB) est actualizada.
Asegurar que todo el hardware desplegado o cambiado est seguro y puede ser
localizado, usando los servicios de Gestin de Configuracin.
2. ACTIVIDADES
Las actividades de la Gestin de Versiones son:
Poltica y planificacin de las Versiones

Diseo, construccin y configuracin de las Versiones
Aceptacin de las Versiones
Planificacin del despliegue
Extensas pruebas de los criterios de aceptacin predefinidos
Visto bueno de la Versin a implementar
Comunicacin, preparacin y capacitacin
Auditoras de hardware y software antes y despus de la implementacin de
Cambios
Instalacin de hardware nuevo o actualizado
Almacenamiento de software controlado en sistemas centralizados y distribuidos
Despliegue, distribucin e instalacin de software

Figura 10.1 Principales actividades en la Gestin de Versiones

3.1 Proceso de despliegue de software
El proceso comienza con la adquisicin del software o con la asignacin del

desarrollo del software.
Cuando se entrega el software se realizar una comprobacin de calidad.
En la comprobacin de calidad, el software se adopta en la DSL. Se examina por
ejemplo si este realmente es el software pedido, si nuevas versiones se han
desarrollado de la fuente correcta, si todos los ajustes han sido autorizados por
Gestin de Cambios y si todos los CIs estn registrados en la CMDB.
Una vez aceptado el software, se hace un backup de la DSL, despus del cual
el software ser aceptado en la DSL. Estos backups deben ocurrir
frecuentemente para que, en caso de un desastre, la ltima Versin correcta
pueda ser cargada con rapidez.
La compilacin y sincronizacin de cada Versin son decididas por adelantado
por la Gestin de Cambio, un Registro de Versin se hace en la CMDB y
todos los detalles se registran.
Cuando todos los componentes del software estn preparados, el paquete se
enva a un rea de prueba donde todos los tests obligatorios se puedan
ejecutar.
Cuando se encuentran demasiados errores, el software se devuelve para ms
desarrollo.
Cuando se aprueba el software, la Versin ser distribuida y llevada a
produccin.

90
Las copias del software se pueden distribuir desde la DSL hacia los otros ambientes
que corresponda:
Ambiente de Desarrollo: El desarrollo de una nueva Versin se puede originar

de una Versin anterior de la DSL. El nmero de Versin se incrementa con
cada nueva Versin. El software solo se puede cambiar en el ambiente de
desarrollo.
Ambiente 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.
Ambiente de Explotacin: El ambiente real (en vivo) donde se ponen a

disposicin del usuario los sistemas de informacin.
Archivos: Aqu se guardan las Versiones originales (anteriores) de software

que ya no estn en uso.
3.2 Biblioteca de Software Definitiva (DSL)
La Biblioteca de Software Definitiva (DSL) es un conjunto de CIs de software y

documentacin en un lugar seguro. Fsicamente, la DSL puede ser una coleccin de
medios electrnicos en distintos formatos de software, archivos y documentacin
electrnica. La DSL es una biblioteca lgica y representa una sola entidad de
software almacenada, la cual fsicamente puede tener muchas copias almacenadas
en distintos lugares.
Cada CI de software autorizado se almacena (fsicamente) en la DSL. En la DSL, se

guardan todas las Versiones originales de software que han sido distribuidas al
ambiente de produccin.
3.3 Almacn de Hardware Definitivo (DHS)
Se debe apartar un rea para el almacenaje seguro de repuestos de hardware. Estos

son componentes y piezas que se mantienen en el mismo nivel que sus contrapartes
en el ambiente de produccin. Detalles de estos componentes y sus respectivos
contenidos y estructuras se deben registrar exhaustivamente en la CMDB. Estos se
pueden utilizar entonces de manera controlada cuando se necesiten sistemas
adicionales o en la recuperacin de Incidentes mayores. Una vez que su uso
(temporal) haya terminado, deben ser devueltos al DHS o se deben obtener sus
remplazos.
3.4 Poltica de Versiones
El Gestor de Versiones debe fijar una Poltica de Versiones en la que se decide cmo
y cundo se configuran y despliegan las actualizaciones del software. Esto implica
especificar a qu nivel se pueden distribuir unos CIs independientemente de otros
(unidades de Versin), lo cual depende de:
La cantidad de trabajo que el ajuste de un componente del programa cause a

otros componentes del programa (incluido el software del sistema).

La cantidad de horas/hombre para construir y probar los Cambios por separado

comparndolo con el esfuerzo asociado para juntarlos e implementarlos
simultneamente.
El grado de dificultad de la instalacin con los usuarios. Puede ser ms fcil
instalar un programa completo porque se dispone de los mecanismos estndar
para ello.
La complejidad de las dependencias entre el software, hardware nuevo y el resto
de la infraestructura TI; cunto ms fcil es separar el hardware del software,
ms fcil es probarlo.
Es de gran importancia evaluar el nmero de ajustes que se pueden probar todos

juntos en un cierto tiempo, una Versin Empaquetada (agrupacin de Cambios
diferentes en un solo despliegue) puede ser tan compleja que nunca pase a la fase
de prueba. Como resultado del rpido desarrollo del nuevo software, la nueva
Versin puede que ya no est actualizada para cuando sea desplegada. Por otro
lado, una gran cantidad de ajustes puede resultar en grandes molestias para el
servicio.
3.5 Tipos de Versiones
Segn el nivel de Versin, las Versiones a menudo se dividen en:
Versiones mayores: Despliegue importante de hardware y software,

generalmente derivado de modificaciones sustanciales en las
funcionalidades. Estas versiones suelen eliminar gran cantidad de Errores
Conocidos, incluyendo soluciones temporales y soluciones rpidas.
Versiones menores: 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.
Reparaciones de emergencia: Normalmente implementado como una

reparacin rpida para un Problema o Error Conocido.
Segn el nmero de Cambios (ver Figura 10.2), se pueden seleccionar algunas de

las siguientes opciones:
Versin Delta: Una versin Delta solo 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 ambiente TI, 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 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
evaluar si se alcanzarn los criterios de rendimiento esperados. La ventaja de
una Versin Total es que se pueden implementar simultneamente varios

92
Cambios. Sin embargo, una Versin Total requiere de una mayor preparacin
y mayor 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 y la incorporacin de nuevas
funcionalidades son actividades que se pueden combinar. Las
actualizaciones programadas de software de terceras partes como el
software del sistema y las aplicaciones de ofimtica son las que por lo
general se tratan con el Paquete de Versiones.
Figura 10.2 Tipos de Versiones
Versiones construidas e implementadas segn programa, y dentro de los

recursos presupuestados
Un nmero muy bajo (de forma ideal ninguna) de Incidencias de Versiones
que se han tenido que retroceder debido a errores inaceptables
Baja incidencia de fallas de construccin
Gestin segura y precisa de la DSL
Ninguna evidencia de software en la DSL que no ha pasado las
comprobaciones de calidad y ninguna evidencia de retrabajos en cualquier
software extrado de la DSL
Tamao de la DSL de acuerdo con la demanda de espacio y mantenimiento
preciso y puntual de la DSL
Cumplimiento de todas las restricciones legales relacionadas con el software
comprado
Distribucin precisa de las Versiones a lugares remotos
Implementacin puntual de Versiones a todos los lugares, incluidos los
remotos

Ninguna evidencia de retroceso no autorizado a Versiones anteriores en

ninguna ubicacin
Ninguna evidencia del uso de software no autorizado en ninguna ubicacin
Ninguna evidencia del pago de multas de licencia o esfuerzo de
mantenimiento malgastado, por software que no est actualmente en uso en
ninguna ubicacin
Ninguna evidencia de duplicacin malgastada en la construccin de
Versiones (p.ej. construcciones mltiples de ubicaciones remotas, cuando
copias de una sola construccin seran suficiente)
Registro puntual y preciso de toda actividad de construccin, distribucin e
implementacin dentro de la CMDB
La composicin programada de Difusiones de acuerdo con la composicin
actual
Recursos TI y humanos requeridos por la Gestin de Versiones de acuerdo a
lo planeado
El nmero de Versiones mayores y menores por perodo de informe
El nmero de Problemas en el ambiente de produccin que se pueden atribuir
a nuevas Versiones, lo cual solo necesita ser medido durante los primeros
meses de vida de una nueva Versin, clasificados por su causa de raz (p.ej.
Versin errnea de archivo, o archivos faltantes)
El nmero de objetos nuevos, cambiados o eliminados introducidos por la
nueva Versin- p.ej. cuntos mdulos y programas
El nmero de Versiones completadas en el tiempo acordado
4.1 Gestor de Versiones
Planear y supervisar la evolucin satisfactoria del software y el hardware

relacionado.
Disear e implementar eficientemente procedimientos para la distribucin e
instalacin de Cambios para los sistemas TI.
Asegurar que el hardware y el software que estn siendo cambiados puedan
ser controlados, son seguros y que slo sean instaladas versiones correctas y
autorizadas.
Comunicar y gestionar las expectativas del Cliente durante la planificacin y
presentacin de nuevas Versiones.
Aprobar el contenido exacto y plan de presentacin para el despliegue, con la
colaboracin de Gestin de Cambios.
Implementar nuevas Versiones de software y hardware en el ambiente
operativo usando los procesos de Gestin de la Configuracin y Gestin de
Cambios.
Asegurar que las copias maestras de todo el software estn seguras en la
DSL y que la CMDB est actualizada.

94
Resumen
La Biblioteca de Software Definitiva (DSL) es un conjunto de CIs de software y

documentacin en un lugar seguro. Fsicamente, la DSL puede ser una coleccin
de medios electrnicos en distintos formatos de software, archivos y
documentacin electrnica.
El Almacn de Hardware Definitivo (DHS) es un rea para el almacenaje seguro

de repuestos de hardware. Estos son componentes y piezas que se mantienen en
el mismo nivel que sus contrapartes en el ambiente de produccin.
Tipos de Versiones: mayores, menores, de emergencia, delta, completa y

paquete de Versiones.

UNIDAD DE
APRENDIZAJE
3
TEMA
10
GESTIN DE LA CAPACIDAD
Al trmino de la unidad, el alumno explicar las funciones de los procesos

que conforman la entrega del servicio de TI, identificando con precisin sus
caractersticas, componentes, ventajas, recomendaciones de implementacin
y medicin, as como la interrelacin de dichos procesos.
TEMARIO
Objetivos
Alcance


96
1. OBJETIVOS
La Gestin de la Capacidad es responsable de asegurar que la Capacidad de la
infraestructura TI est alineada con las demandas de la empresa de la manera ms
efectiva en costo y tiempo. El proceso abarca:
El monitoreo del rendimiento de los Servicios TI y los componentes de soporte de

la infraestructura
Encargarse de las actividades de ajuste para utilizar los recursos existentes de la
manera ms eficiente
Entender las demandas actuales de recursos TI y realizar pronsticos de
requerimientos futuros
Influir en la demanda de recursos, puede ser en coordinacin con la Gestin
Financiera
La produccin de un Plan de Capacidad (Capacity Plan) que permita proporcionar
servicios TI de la calidad definida en los Acuerdos de Nivel del Servicio (SLAs)
La Gestin de la Capacidad equilibra:
Costos con Capacidad: Por ejemplo, la necesidad de asegurar que la

Capacidad de procesamiento que se compra no solo es justificable
econmicamente en trminos de la necesidad del negocio, sino tambin la
necesidad de usar de la manera ms eficiente dichos recursos.
Suministro con demanda: Por ejemplo, asegurarnos que el suministro

disponible de potencia de procesamiento est alineado con las demandas del
negocio, ahora y en el futuro. Puede tambin ser necesario gestionar o influir en
la demanda de un recurso particular.
2. ALCANCE
El proceso de la Gestin de la Capacidad debe ser el centro de coordinacin de todos los
temas de Capacidad y rendimiento de TI. Otras reas tcnicas, como el Soporte de Red,
puede llevar a cabo la mayor parte de las obligaciones cotidianas relevantes, pero la
responsabilidad total recae en el proceso de Gestin de la Capacidad. Tanto para el
ambiente de produccin como el de desarrollo, el proceso debe abarcar:
Todo el hardware (PCs, servidores, mainframes y supercomputadoras)

Todo el equipamiento de red (LANs, WANs, routers, etc.)
Todos los perifricos (dispositivos de almacenamiento, impresoras, etc.)
Todo el software (sistemas operativos y software de red, desarrollos internos y
paquetes comprados)
Recursos humanos, pero solamente donde la falta de recursos humanos podra
resultar en un retraso del tiempo de respuesta del servicio.
Sin embargo, el motor de la Gestin de Capacidad debe ser los requerimientos del
negocio.
La Figura 11.1 muestra que la Gestin de la Capacidad tiene una relacin bidireccional
con los procesos de estrategia y planificacin del negocio. Normalmente la estrategia a
largo plazo est contenida en los planes de negocio actualizados. Los planes de negocio
se desarrollan en base al entendimiento de la organizacin sobre factores externos como
el mercado competitivo, el panorama econmico y la legislacin, y su capacidad interna
en trminos de recursos humanos, capacidad de entrega, etc.

La Gestin de la Capacidad necesita entender la estrategia del negocio a largo plazo

para proveer informacin sobre las ltimas ideas, tendencias y tecnologas que han
sido desarrolladas por los proveedores del hardware y del software.
Los planes de negocio de la organizacin dictan la estrategia y los planes de negocio

especficos de TI/SI, los cuales deben contar con la participacin y conocimiento de la
Gestin de la Capacidad. En los planes de negocio especficos de TI/SI se identifican las
tecnologas, el hardware y el software y sus tiempos de implementacin.
Figura 11.1 Gestin de la Capacidad y el negocio

3.1.1 Entradas
Tecnologa
Acuerdos de Niveles de Servicio (SLAs), Requisitos de Niveles de Servicio
(SLRs) y Catlogo de Servicios
Planes y estrategia del negocio Planes y estrategia de TI/SI
Requisitos y volumen del negocio Calendarios de operaciones
Planes y programas de desarrollo y despliegue FSC

98
Incidentes y Problemas Revisiones del servicio

Incumplimientos de SLA Planes financieros
Presupuestos
3.1.2 Salidas
Plan de Capacidad (Capacity Plan)

Base de Datos de Capacidad (Capacity Data Base CDB) Lneas de base y
perfiles
Umbrales (thresholds) y alarmas
Informes de Capacidad (regulares, ad hoc y excepcionales) Recomendaciones
de SLA y SLR
Recomendaciones de costos y precios
Cambios proactivos y mejoras del servicio Calendario de operaciones revisado
Revisiones de efectividad Informes de auditora
3.2 Subprocesos
La Gestin de Capacidad consiste de tres subprocesos, dentro de los cuales hay

varias actividades (ver Figura 11.2).
3.2.1 Gestin de Capacidad de Negocio
Este subproceso es responsable de asegurar que se consideren, programen e

implementen de modo puntual los requerimientos futuros del negocio sobre servicios
TI. Esto se puede alcanzar usando los datos existentes de la utilizacin actual de los
recursos de varios servicios para definir tendencias, pronosticar o modelar
requerimientos futuros. Estos requerimientos futuros provienen de los planes de
negocio esbozando nuevos servicios, mejoras y crecimiento en servicios existentes,
planes de desarrollo, etc.
3.2.2 Gestin de Capacidad de Servicio
El enfoque de este subproceso es la gestin del rendimiento de los servicios TI

utilizados por los Clientes. Es responsable de asegurar que el rendimiento de todos
los servicios, como se detalla en los objetivos de los SLAs y SLRs, es monitoreado y
medido, y que los datos recogidos son registrados, analizados e informados. Segn
sea necesario, se tomar accin para asegurar que el rendimiento de los servicios
cumpla con los requerimientos del negocio. Para llevar a cabo este trabajo, el
proceso de la Gestin de la Capacidad. Esto se lleva a cabo por el personal que
posee conocimiento de todas las reas de tecnologa utilizadas en la entrega del
servicio, y frecuentemente implica buscar asesoramiento de especialistas
involucrados en la Gestin de Capacidad de Recursos.
3.2.3 Gestin de Capacidad de Recursos
El enfoque en este subproceso es la gestin de los componentes individuales de la

infraestructura TI. Es responsable de asegurar que todos los componentes dentro de
la infraestructura TI son monitoreados y medidos, y que los datos recogidos son
registrados, analizados e informados. Segn sea necesario, se tomar accin para

gestionar los recursos disponibles para asegurar que los servicios TI cumplan con los
requerimientos del negocio. Al realizar este trabajo, el proceso de Gestin de
Capacidad es asistido por personas especializadas en determinadas reas de
tecnologa.
Cada uno de los subprocesos realizan muchas actividades comunes, pero cada
subproceso tiene un enfoque muy diferente: La Gestin de Capacidad de Negocio se
centra en los requerimientos de negocio actuales y futuros, mientras que la Gestin
de Capacidad de Servicio se centra en la entrega de los servicios existentes que
soportan el negocio y la Gestin de Capacidad de Recursos se centra en la
tecnologa que soporta toda la provisin del servicio.
Figura 11.2 Subprocesos y sus actividades
3.3 Plan de Capacidad (Capacity Plan)
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 a un costo aceptable. 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.
3.4 Base de Datos de Capacidad (CDB)
Crear y poblar la CDB significa unir y actualizar la informacin tcnica, la informacin

del negocio y toda informacin que afecte a la Gestin de la Capacidad. Puede
resultar imposible almacenar toda la informacin de Capacidad en una sola base de
datos. Los administradores de red pueden utilizar sus propios planteamientos. Por lo
general, la CDB hace referencia a la coleccin de fuentes con informacin de
Capacidad.

100
3.5 Modelamiento (Modelling)
El objetivo principal de la Gestin de Capacidad es predecir el comportamiento de los

Servicios TI bajo un volumen dado y variedad de trabajo. El modelamiento es una
actividad que puede beneficiar a cualquiera de los subprocesos de Gestin de la
Capacidad.
Los distintos tipos de modelamiento varan desde hacer estimados basados en la

experiencia y en informacin de utilizacin de recursos actuales, hasta estudios
pilotos, prototipos y benchmarks a gran escala. Lo primero es un enfoque
econmico y razonable para decisiones pequeas diarias, mientras que lo segundo
es costoso pero puede ser aconsejable al implementar un nuevo proyecto grande.
Algunas tcnicas de modelamiento son:
Anlisis de tendencias
Modelamiento analtico
Modelamiento de simulacin
Modelos de lnea de base
3.6 Dimensionamiento (Sizing) de la aplicacin
El dimensionamiento de la aplicacin tiene una vida finita. Se inicia en la etapa de

Iniciacin del Proyecto de una nueva aplicacin o cuando hay un Cambio mayor de
una aplicacin existente, y se completa cuando la aplicacin se acepta en el
ambiente de produccin.
El objetivo principal del dimensionamiento de la aplicacin es estimar los

requerimientos de recursos para soportar un Cambio propuesto de la aplicacin o
una nueva aplicacin, y para asegurar que alcanza los niveles de servicio requeridos.
Para conseguir esto el dimensionamiento de la aplicacin tiene que ser una parte
integral del ciclo vida de las aplicaciones.
Los informes de gestin que da el proceso de Gestin de la Capacidad incluyen por

un lado, informacin de control del proceso en trminos de caractersticas del 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 la Capacidad real y la

planeada Tendencias en las discrepancias
Impacto en los niveles de servicio
Incremento/disminucin de la utilizacin de la Capacidad esperada a corto y largo
plazo
Umbrales o marcas que, cuando se alcancen, necesitarn de capacidad adicional
3.8 Factores crticos de xito e indicadores de rendimiento
La Gestin de la Capacidad depende de los siguientes factores crticos de xito:
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 Gestin de la Capacidad depende de los siguientes indicadores de

rendimiento:
Prediccin de la demanda del Cliente: Carga de trabajo, tendencias en el tiempo

y veracidad del Plan de Capacidad.
Tecnologa: Rendimiento de todos los servicios TI, implementacin de nueva

tecnologa (tiempo, costo y funcionalidad) y cumplimiento de los SLAs.
Costos: Reduccin en el nmero de compras, reduccin de sobrecapacidad y

diseo de planes de inversin.
Operaciones: Reduccin del nmero de Incidentes debido a Problemas de

rendimiento y satisfaccin de la demanda del Cliente.
4. Roles y Responsabilidades
4.1 Rol
La Gestin de la Capacidad tiene la responsabilidad de asegurar que hay una

adecuada Capacidad TI para alcanzar los niveles de servicio requeridos y que los
directivos TI estn asesorados correctamente de cmo emparejar la Capacidad con
la demanda, y asegurar tambin que el uso de la Capacidad existente es ptimo.
La Gestin de la Capacidad es tambin responsable de recomendar al proceso de

Gestin de Niveles de Servicio (SLM) sobre los niveles de servicio apropiados o las
opciones del nivel de servicio.
4.2 Responsabilidades
Asegura que los niveles apropiados de monitoreo de recursos y rendimiento del

sistema son establecidos, y que la informacin registrada en una CDB se
mantiene actualizada y utilizada por todas las partes del proceso de la Gestin de
la Capacidad.
Produce Planes de Capacidad alineados con el ciclo de planeamiento del
negocio, identificando los requerimientos de Capacidad con suficiente antelacin
para tener en cuenta los plazos de entrega.
Documenta la necesidad de cualquier incremento o reduccin en hardware
basada en SLRs y restricciones de costos.
Produce informes de gestin peridicos, que incluyen el uso actual de los
recursos actuales, tendencias y pronsticos.
Dimensiona todos los nuevos sistemas propuestos para determinar los recursos
de cmputo y de red requeridos, para determinar la utilizacin del hardware,
niveles de servicio de rendimiento y los costos implicados.
Evala la nueva tecnologa y su relevancia en la organizacin en trminos de
rendimiento y costos.
Evala los nuevos productos de hardware y software para el uso de la Gestin de
Capacidad que pueden mejorar la eficiencia y efectividad del proceso.
Lleva a cabo pruebas de rendimiento de los nuevos sistemas.
Informa sobre el rendimiento vs los objetivos que contienen los SLAs.
Mantiene un conocimiento de la demanda futura para los Servicios TI y predice
los efectos de la demanda en los niveles de servicio de rendimiento.

102
Determina los niveles de servicio de rendimiento que pueden mantenerse con

costos justificables.
Recomienda el ajuste de los sistemas y da recomendaciones sobre el diseo y el
uso de los sistemas para asegurar un uso ptimo de todos los recursos de
hardware y software.
Recomienda resoluciones para Incidentes y Problemas relacionados con el
rendimiento.
Recomienda cuando gestionar la demanda de los clientes sobre sistemas.
Lleva a cabo estudios de Capacidad y rendimiento ad-hoc.
Asegura que los requerimientos de confiabilidad y disponibilidad son
considerados en el planeamiento y dimensionamiento de la Capacidad.
Est representada en el CAB, evaluando y autorizando los Cambios.
Asegura la realizacin de auditoras peridicas y ad-hoc.

Resumen
La Gestin de la Capacidad es responsable de asegurar que la Capacidad de la

infraestructura TI est alineada con las demandas de la empresa de la manera
ms efectiva en costo y tiempo.
La Gestin de Capacidad consiste de tres subprocesos:
- Gestin de Capacidad de Negocio

- Gestin de Capacidad de Servicio
- Gestin de Capacidad de Recursos
El Plan de Capacidad (Capacity Plan) 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.

104

UNIDAD DE
APRENDIZAJE
3
TEMA
11
GESTIN DE LA DISPONIBILIDAD

TEMARIO
Objetivos
Alcance
Responsabilidades y Habilidades


106
1. OBJETIVOS
Asegurar que los Servicios TI son diseados para entregar los niveles de
Disponibilidad requeridos por el negocio.
Proveer una variedad de informes de Disponibilidad TI para asegurar que los
niveles acordados de Disponibilidad, confiabilidad y mantenimiento son medidos
y monitoreados continuamente.
Optimizar la Disponibilidad de la Infraestructura TI para entregar mejoras
rentables (efectivas en costo) que proporcionan beneficios tangibles al negocio y
a los Usuarios.
Lograr, durante un periodo de tiempo, una reduccin en la frecuencia y en la
duracin de los Incidentes que impactan la Disponibilidad TI.
Asegurar que las cadas en la Disponibilidad TI se reconozcan y que se
identifiquen y realicen las acciones correctivas apropiadas.
Crear y mantener un plan de Disponibilidad cuyo objetivo sea la mejora de la
Disponibilidad total de los Servicios TI y los componentes de la Infraestructura,
para asegurar la satisfaccin de los requerimientos actuales y futuros de la
Disponibilidad del negocio.
2. ALCANCE
La Gestin de la Disponibilidad se refiere al diseo, implementacin, medicin y
gestin de la Disponibilidad de la Infraestructura TI para asegurar que los
requerimientos del negocio sobre Disponibilidad se cumplan. La Gestin de la
Disponibilidad:
Debe aplicarse a todos los nuevos Servicios TI y para los servicios existentes que
tengan definidos los Requerimientos del Nivel de Servicio (SLRs) o Acuerdos de
Nivel de Servicio (SLAs).
Puede aplicarse a aquellos Servicios TI que son crticos para el negocio y que no
tengan definido un SLA.
Debe aplicarse a los proveedores (internos y externos) que forman la
organizacin de soporte TI, antes de la definicin de un SLA.
Considera todos los aspectos de la Infraestructura TI y su organizacin de
soporte que puede impactar a la Disponibilidad, incluyendo capacitacin,
habilidades, polticas, efectividad de los procesos, procedimientos y
herramientas.
No es responsable de la Gestin de Continuidad del Negocio y la reanudacin de
los procesos del negocio despus de un desastre (lo cual es responsabilidad de
la Gestin de Continuidad del Servicio TI ITSCM), pero provee de entradas
clave a ITSCM, teniendo ambos una relacin muy estrecha.

3.1 Terminologa
Disponibilidad (Availability): Es la capacidad de un Servicio TI o componente

para realizar sus funciones en un periodo de tiempo definido.
Confiabilidad (Reliability): Es la capacidad de un Servicio TI de no presentar

fallas operativas.

Sostenibilidad (Maintainability): Es la capacidad del componente de la

Infraestructura TI de mantenerse en el estado operativo o recuperarse de una
falla.
Servicialidad (Serviciability): Describe los acuerdos contractuales definidos

con proveedores externos sobre disponibilidad, confiabilidad y sostenibilidad
de los Servicios TI y componentes bajo su responsabilidad.
3.2.1 Entradas
Requerimientos de Disponibilidad del negocio

Evaluacin del impacto para todos los procesos del negocio que soporta TI
Requerimientos de Disponibilidad, confiabilidad y sostenibilidad para los
componentes de la Infraestructura TI
Informacin sobre fallas de los Servicios TI y componentes, normalmente en
la forma de registros de Incidentes y Problemas
Datos de configuracin y monitoreo de los Servicios TI y componentes
Niveles de servicio alcanzados comparados con los niveles de servicio
acordados para cada Servicio TI que tenga un SLA
3.2.2 Salidas
Criterios de diseo de Disponibilidad y recuperacin para cada Servicio TI

nuevo o mejorado
Detalles de las tcnicas de Disponibilidad que sern desplegadas para
proveer mayor resistencia (resilience) a la Infraestructura con la finalidad de
prevenir o minimizar el impacto de las fallas en los Servicios TI
Objetivos acordados de Disponibilidad, confiabilidad y sostenibilidad de los
componentes de la Infraestructura TI que soportan los Servicios TI
Informes sobre Disponibilidad, confiabilidad y sostenibilidad para reflejar las
perspectivas del negocio, del Usuario y de la organizacin de soporte TI
Los requerimientos de monitoreo de los componentes TI para asegurar que
se detecten e informen las desviaciones en Disponibilidad, confiabilidad y
sostenibilidad
Plan de Disponibilidad para la mejora proactiva de la Infraestructura TI
3.3 Actividades
Las actividades claves del proceso son las siguientes:
Determinar los requerimientos de Disponibilidad del negocio para un Servicio TI

nuevo o mejorado y formular los criterios de diseo de Disponibilidad y
recuperacin para la Infraestructura TI.
En coordinacin con la ITSCM, determinar las funciones vitales del negocio y el
impacto que surge del fallo de los componentes TI.
Definir los objetivos de Disponibilidad, confiabilidad y sostenibilidad para los
componentes de la Infraestructura TI que soportan el Servicio TI para permitir que
stos se documenten y estn de acuerdo con los SLAs, OLAs y contratos.
Establecer medidas e informes de Disponibilidad, confiabilidad y sostenibilidad que
reflejen las perspectivas del negocio, el Usuario y la organizacin de soporte TI.
Monitorear y analizar las tendencias de Disponibilidad, confiabilidad y
sostenibilidad de los componentes TI.

108
Revisar la Disponibilidad de los Servicios TI y de los componentes e identificar

niveles inaceptables.
Investigar las razones subyacentes de Disponibilidad inaceptable.
Producir y mantener un Plan de Disponibilidad que priorice y planifique las
mejoras de Disponibilidad TI.
3.4 El ciclo de vida de la no Disponibilidad
Las fases por las que pasa un servicio debido a problemas tcnicos son (ver Figura
12.1):
Inicio: El Usuario reconoce un problema tcnico en el servicio.
Deteccin: Se informa al proveedor del servicio sobre el problema tcnico.
Diagnstico: El proveedor del servicio toma la accin de localizar la causa del

problema tcnico.
Reparacin: El proveedor del servicio repara el servicio. El tiempo necesario para

esto se calcula desde el momento en el que se ha informado al proveedor del
servicio sobre el problema tcnico.
Recuperacin Restauracin: Tiempo que se necesita para conseguir que vuelva

a funcionar el servicio, incluidas todas las actividades de configuracin e
inicializacin, y el tiempo necesario para que el servicio vuelva a estar disponible
para el Usuario.
El tiempo depende en parte de la velocidad de reaccin de la organizacin TI y

posibles proveedores externos. Para conseguir una buena perspectiva de esto, se
toman los valores medios de las medidas. Estos valores medios se utilizan para
predecir las expectativas de la Disponibilidad de un servicio en el futuro y para
discutir si las mejoras son urgentes. Los valores siguientes son los ms comunes en
la Gestin de la Disponibilidad:
Tiempo Medio de Reparacin (MTTR): Es el tiempo medio entre la aparicin del

incidente y su restauracin, tambin llamado tiempo de parada o Downtime.
Este valor mide la sostenibilidad y la servicialidad.
Tiempo Medio Entre Fallos (MTBF): Es el tiempo medio entre la restauracin del
Incidente y la aparicin del prximo, tambin llamado tiempo de Disponibilidad o
Uptime. Este valor mide la Disponibilidad.
Tiempo Medio Entre Incidentes del Sistema (MTBSI): Es el tiempo medio entre la
aparicin de dos Incidentes consecutivos. Es la suma de MTTR y MTBF. Este
valor mide la confiabilidad.
La relacin entre MTBF y MTBSI indica si hay muchas fallas menores o solo algunas
fallas mayores.

Figura 12.1 Ciclo de vida de la no Disponibilidad
3.5 Clculo de la Disponibilidad
Para determinar la Disponibilidad bsica de un Servicio TI o componente como un

porcentaje de Disponibilidad se puede usar la siguiente frmula bsica:
Disponibilidad = (Horas Acordadas de Servicio Downtime) X

100 Horas Acordadas de Servicio
3.5.1 Configuracin en serie
Esta configuracin de la Infraestructura TI se caracteriza por no tener componentes

adicionales que provean de mayor resistencia a la infraestructura (ver Figura 12.2) .
El porcentaje de Disponibilidad para esta configuracin se basa en el producto de los
porcentajes de Disponibilidad de todos los componentes individuales.
3.5.2 Configuracin en paralelo
Esta configuracin de la Infraestructura TI se caracteriza por tener componentes

adicionales que proveen de mayor resistencia a la infraestructura (ver Figura 12.2),
de tal manera que los componentes de respaldo (backup) comienzan a funcionar
automticamente. El porcentaje de Disponibilidad se calcula multiplicando la no-
Disponibilidad (recproco de la Disponibilidad) de cada componente.

110
Figura 12.2 Disponibilidad en serie y en paralelo
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 de parada total.
Nmero de fallas.
Informacin adicional de fallas que real o potencialmente dan como resultado una
falta de Disponibilidad ms alta que la acordada.
Tiempos de deteccin, respuesta, reparacin y recuperacin
Tiempo de procesamiento de implementacin de servicios, SLAs y grupos de
Clientes cubiertos por SLAs.
Algunas mtricas se pueden determinar para cada servicio, equipo o dominio de

infraestructura (red, centro de cmputo y ambiente de las estaciones de trabajo).
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.
3.7 Factores crticos de xito e indicadores de rendimiento
3.7.1 Factores crticos de xito
El negocio debe haber definido claramente los objetivos de Disponibilidad.

Se debe haber constituido la Gestin de Niveles de Servicio para formalizar los
acuerdos.

El negocio y la organizacin TI 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.
3.7.2 Indicadores de rendimiento
Porcentaje de Disponibilidad (Uptime) por servicio o grupo de

Usuarios.
Duracin del tiempo de parada.
Frecuencia del tiempo de parada.
4. RESPONSABILIDADES Y HABILIDADES
Desplegar el proceso de Gestin de la Disponibilidad y los mtodos y tcnicas

asociadas.
Asegurar que el proceso de Gestin de la Disponibilidad, sus tcnicas y mtodos
asociados son regularmente revisados, auditados, y mejorados continuamente.
Determinar los requerimientos de Disponibilidad del negocio para nuevos y
mejorados Servicios TI.
Crear los criterios de diseo de Disponibilidad y recuperacin a ser aplicados a
un nuevo o mejorado diseo de Infraestructura.
Asegurar que los niveles de Disponibilidad TI requeridos tienen costos
justificados Definir los objetivos de la Disponibilidad requerida por la
Infraestructura TI y sus
componentes que soportan un nuevo o mejorado Servicio TI.
Establecer las medidas y los informes que reflejan los requerimientos del
negocio, del Usuario y de la organizacin de soporte TI.
Monitorear la Disponibilidad TI real alcanzada vs los objetivos y asegurar que las
cadas son direccionadas correctamente.
Producir y mantener el Plan de Disponibilidad, que prioriza y planifica las mejoras
de la Disponibilidad TI.
Promocionar el conocimiento y el entendimiento de la Gestin de la
Disponibilidad dentro de la organizacin de soporte TI.
Mantener un conocimiento de los avances de la tecnologa y la mejor prctica TI,
por ejemplo ITIL.
4.2 Habilidades clave
Tener experiencia prctica en gestin de procesos.

Tener un buen entendimiento de las disciplinas de ITIL.
Tener experiencia prctica de tcnicas y mtodos de mejora continua.
Tener un buen entendimiento de principios y procesos estadsticos y analticos.
Poseer buenas habilidades interpersonales para la comunicacin escrita, oral y
cara a cara.
Poseer habilidades en tcnicas y mtodos de
negociacin. Tener habilidad numrica.
Tener un buen conocimiento de las tecnologas TI disponibles y emergentes.
Tener la habilidad para entender cmo la tecnologa TI soporta el negocio.
Tener un conocimiento razonable de la Gestin de Costos.

112
Resumen
La Disponibilidad (Availability) es la capacidad de un Servicio TI o componente

para realizar sus funciones en un periodo de tiempo definido.
La Gestin de la Disponibilidad trabaja con los siguientes valores:
- Tiempo Medio de Reparacin (MTTR)

- Tiempo Medio Entre Fallos (MTBF)
- Tiempo Medio Entre Incidentes del Sistema (MTBSI)
La configuracin en paralelo de la Infraestructura TI ofrece mayor Disponibilidad

que la configuracin en serie por tener componentes adicionales que proveen de
mayor resistencia a la Infraestructura.

UNIDAD DE
APRENDIZAJE
3
TEMA
12
GESTIN DE LA CONTINUIDAD

TEMARIO
Introduccin
Objetivos
Habilidades Clave


114
1. INTRODUCCIN
Han habido cambios significativos en la tecnologa y la forma en la que se utiliza sta
en el negocio. Las dependencias entre los procesos del negocio y la tecnologa estn
tan unidas actualmente que la Planificacin de la Contingencia (tambin llamada
Gestin de la Continuidad del Negocio o Business Continuity Management BCM)
incorpora un elemento del negocio (Planificacin de la Continuidad del Negocio) y un
elemento de tecnologa (Planificacin de la Gestin de la Continuidad del Servicio TI).
Sus dependencias determinan que una es un subconjunto de la otra, dependiendo de
la naturaleza del negocio y en la medida en que la tecnologa se ha extendido en la
organizacin. Se asume que la Continuidad del Negocio es lo principal y que la
Gestin de la Continuidad del Servicio TI (ITSCM) es un subconjunto de los procesos
de la Gestin de la Continuidad del Negocio (BCM).
2. OBJETIVOS
El objetivo principal de la ITSCM es dar soporte a los procesos del BCM asegurando
que las facilidades tcnicas y servicios TI requeridos (incluyendo computadoras,
redes, aplicaciones, telecomunicaciones, soporte tcnico, y Service Desk) pueden
recuperarse en los plazos requeridos y acordados con el negocio.
La ITSCM 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.

La Figura 13.1 muestra las etapas y las actividades del proceso ITSCM.
3.1 Etapa 1 - Iniciacin
Las actividades a considerar durante el proceso de iniciacin dependen de la medida en

que las facilidades de contingencia se han aplicado dentro de la organizacin. Algunas
partes del negocio pueden haber establecido Planes de Continuidad individuales basados
en Workarounds manuales y TI puede haber desarrollado planes de contingencia para
sistemas crticos. Esto es una buena entrada para el proceso, sin embargo, una ITSCM
efectiva depende de soportar funciones crticas del negocio y asegurar que el
presupuesto disponible se aplica de la manera ms apropiada.
El proceso de iniciacin considera a la organizacin como un todo y consiste de las

siguientes actividades:

Figura 13.1 Modelo del Proceso ITSCM
3.1.1 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 la ITSCM. La
gestin debe mostrar su compromiso.
3.1.2 Definicin del alcance y las reas relevantes
Requisitos de seguridad, estndares de calidad como la serie ISO 9000, estndares

de Gestin de la Seguridad como ISO 27001, 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.
3.1.3 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 (Requerimientos y
Estrategia).

116
3.1.4 Establecer la organizacin del proyecto
Es aconsejable usar mtodos de gestin de proyecto formales, por ejemplo PMI,

soportado por software de planificacin.
3.2 Etapa 2 - Anlisis de Requerimientos y Definicin de Estrategia
Esta etapa constituye el fundamento de la ITSCM y es un componente crtico para

determinar qu tan bien sobrevivir una organizacin ante una interrupcin del
negocio o un desastre y los costos que incurrirn.
Las actividades de esta etapa se dividen en dos secciones:
Requerimientos: Realiza el Anlisis de Impacto del Negocio (Business Impact

Analysis BIA) y la evaluacin de riesgo.
Estrategia: Determina y acuerda las medidas de reduccin del riesgo y las
opciones de recuperacin para soportar los requerimientos.
3.2.1 Anlisis de Impacto del Negocio
El propsito del Anlisis de Impacto del Negocio es identificar el dao o prdida

potencial que puede sufrir la organizacin como consecuencia de una interrupcin de
los procesos crticos del negocio. Para ello se realiza un anlisis de los servicios TI
esenciales para el negocio (p.e. 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 solo podrn ser modificados si el Cliente est de
acuerdo. Para los servicios crticos, se debe encontrar el balance entre prevencin y
opciones de recuperacin.
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. Ms tarde, esta informacin se utilizar para identificar las opciones de
recuperacin para cada servicio.
3.2.2 Evaluacin del Riesgo
Un anlisis de riesgo puede ayudar a identificar los riesgos a los que est expuesto
un negocio. Tambin dar informacin valiosa a la gestin porque identificar las
amenazas y vulnerabilidades y las medidas de prevencin que correspondan. Ya que
es bastante costoso 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 el Anlisis del Riesgo y la Gestin del
Riesgo, se basa en la CCTA Risk Analysis and Management Method (CRAMM).

Figura 13.2 Evaluacin del Riesgo
El modelo est formado por las siguientes actividades:
Identificar riesgos: Es decir riesgos de componentes (activos o bienes)

especficos del servicio TI que soportan el proceso del negocio y, que de fallar,
causarn una interrupcin del servicio. Los riesgos tpicos de TI incluyen:
Dao o denegacin de acceso al edificio.

Prdida de sistemas TI, redes, sistemas de Distribucin de Llamada
Automtica (ACDs), firewalls, sistemas criptogrficos, Infraestructura de
Clave Pblica (PKI), etc.
Prdida de datos o prdida de integridad de datos.
Prdida de servicios de red incluidos problemas de telecomunicaciones.
No disponibilidad de Personal clave, p.e. solo una persona que sabe
cmo mantener un servidor de red crtico o una aplicacin de negocio y
que no exista documentacin.
Falla de partners o proveedores de servicio, p.e. organizaciones externas
proveedoras de sistemas o servicio TI (p.e. soporte, desarrollo,
mantenimiento).
Prdida de servicio de un partner debido a una excesiva demanda de
servicio (p.e. visitas o volmenes excesivos de una pgina web).
Falta de seguridad (p.e. fraude, sabotaje, virus informticos o software
malicioso) y prdida de elementos del ambiente de operaciones (p.e. aire
acondicionado).
Prdida de expedientes de papel crticos o medios (p.e. manuales,
documentos, backups, etc.).
Prdida de elementos bsicos del negocio (p.e. luz, gas, agua).
Evaluar los niveles de amenaza y vulnerabilidad: La amenaza se define como la

probabilidad de que una interrupcin del servicio ocurrir y la vulnerabilidad se
define como si, y en qu medida, le afectar a la organizacin la materializacin
de la amenaza. Ejemplo de amenaza es la combinacin de provisin de energa
poco fiable y un rea con muchas tormentas o con tormentas elctricas. Un

118
pararrayos brindar algo de proteccin contra los rayos, pero todava pueden
afectar seriamente a la red y a los sistemas, es decir todava son vulnerables.
Evaluar los niveles de riesgo: Se evalan las amenazas y vulnerabilidades en el

contexto de los componentes TI para dar una estimacin de los riesgos.
Determinar contramedidas: Despus del anlisis del riesgo, es posible determinar

contramedidas apropiadas o medidas de reduccin del riesgo (mecanismos de la
ITSCM) para gestionar los riesgos, es decir reducirlos a un nivel mnimo
aceptable o mitigarlos.
3.2.3 Estrategia de Continuidad del Negocio
La mayora de las organizaciones tienen que adoptar un balance entre la reduccin

del riesgo (prevencin) y las opciones de recuperacin (plan de recuperacin), las
cuales son tratadas a continuacin.
Medidas de reduccin del riesgo: Estas medidas de prevencin se pueden tomar

en base al anlisis del riesgo, considerando con mucho cuidado costos 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. Las medidas de reduccin del riesgo se toman junto con la
Gestin de la Disponibilidad y pueden incluir el uso de UPS y provisiones de
energa de backup, sistemas tolerantes a fallos, almacenamiento en otro lugar,
sistemas RAID, equipos y componentes de repuesto, etc.
Opciones de recuperacin: Las opciones de recuperacin deben considerar:
Personal y alojamiento cmo hacer frente al alojamiento, mobiliario,

transporte, distancias de viaje, etc.
Sistemas TI, hardware, aplicaciones, software, redes y la informacin.
Servicios crticos como energa, telecomunicaciones, agua, correo y servicios
de mensajera.
Activos crticos como registros en papel y material de referencia.
Hay un nmero de opciones disponibles para la recuperacin de los servicios TI:
No hacer nada.
Sistema manual basado en papel.
Acuerdos Recprocos esta opcin puede utilizarse si dos organizaciones
tienen hardware similar y acuerdan prestarse las instalaciones en caso de
desastre. Hoy en da esta opcin no es muy atractiva debido a los sistemas
on-line.
Recuperacin Gradual (stand-by fro) es cuando se reconstruye (una parte
de) la infraestructura a partir de cero en un local que se acuerde por la
direccin. Este local se equipa con energa, telfonos y facilidades de red. Se
puede realizar por contrato con proveedores externos.
Recuperacin Intermedia (stand-by clido) es cuando se alquila la capacidad y
el espacio de una compaa especial que asumir los servicios del negocio.
Recuperacin Inmediata (stand-by caliente) es cuando se tiene ms locales o
se construye un segundo local. En tiempos de desastre, se puede cambiar al

otro local a veces en segundos. Estos locales se usan mayormente como

locales de prueba.
3.3 Etapa 3 - Implementacin
Una vez acordada la estrategia el ciclo vida de la Continuidad del Negocio pasa a la
etapa de Implementacin, involucrando a TI. La etapa de implementacin consiste de
los siguientes procesos:
Establecer la organizacin y desarrollar planes de implementacin Implementar

arreglos de stand-by
Implementar medidas de reduccin del riesgo Desarrollar planes de recuperacin
de TI
Desarrollar procedimientos
Realizar pruebas iniciales
Cada uno de los procesos mencionados se considera con respecto a las

responsabilidades especficas que TI debe asumir.
3.3.1 Secciones del plan de recuperacin
Administracin: Cundo y cmo ejecutar el plan, programas de accin y personal

involucrado.
Infraestructura TI: Las partes de la infraestructura que estn sujetas a la Gestin

de la Continuidad. Ej.: detalles de hardware, software y telecomunicaciones,
incluyendo repuestos, contratos y acuerdos de soporte de recuperacin.
Procedimientos de Operacin de Gestin de Infraestructura TI: Instrucciones

requeridas para recomenzar operaciones, incluidos detalles de SLA y manuales.
Personal: Informacin sobre el personal a transferir al local de contingencia,

quin va a sustituir al personal que no asistir al local de contingencia o, en el
peor de los casos, ha muerto. En tiempos de desastre, el personal est ms
interesado en cmo est su propia familia y propiedad que cmo est TI. Se tiene
que idear un plan para reponer personal.
Seguridad: Instrucciones para proteccin contra robo, fuego y explosiones en el

local principal y de contingencia, e informacin sobre las instalaciones de
almacenamiento externo como depsitos y bvedas.
Local de contingencia: Situacin, contactos, facilidades, acuerdos de seguridad y

transporte al local, cmo construir el local, cmo implementar infraestructura y
aplicaciones, cmo restaurar datos, etc.
Restauracin: Procedimiento detallando cmo, dnde y cunto tardar en

restaurarse la infraestructura completa, especialmente si solo se restauran los
servicios ms importantes.

120
3.4 Etapa 4- Gestin Operacional
Una vez que la implementacin se ha completado, hay necesidad de asegurar que el

proceso se mantiene como parte del negocio. Esto se consigue a travs de la gestin
operacional e incluye:
Educacin y previsin: Todo el personal debe tener conocimiento de las

implicancias de la Continuidad del Negocio y de la Continuidad del Servicio y
considerarlos como parte de su rutina de trabajo normal y presupuesto.
Capacitacin: Personal TI tendr que capacitar a miembros no-TI del equipo de
recuperacin de negocio no-TI para asegurar que tengan el nivel de competencia
necesario para facilitar la recuperacin.
Revisin: Revisar regularmente todos los entregables del proceso de ITSCM para
asegurar que se mantienen actualizados. Con respecto a TI se requerir cada
vez que haya un cambio importante en su infraestructura, elementos o
dependencias tales como sistemas nuevos o redes o cambio de proveedores de
servicio, as como cuando hay un cambio en la direccin del negocio, estrategia
de negocio o estrategia TI.
Pruebas: Luego de las pruebas iniciales es necesario establecer un programa de
pruebas peridicas para asegurar que los componentes crticos de la estrategia se
prueben al menos anualmente o como lo indique la direccin ejecutiva o auditora.
Control de Cambios: Despus de las pruebas y revisiones y en respuesta a los
Cambios del da a da, los planes de la ITSCM se deben actualizar. La ITSCM se
debe incluir como parte del proceso de Gestin de Cambios para asegurar que
cualquier Cambio en la Infraestructura se refleje en los acuerdos de contingencia
proporcionados por TI o terceros. Planes inexactos o capacidades de
recuperacin inadecuadas pueden resultar en el fracaso de la ITSCM.
Garanta: El proceso final en el ciclo de vida de la ITSCM implica obtener la
garanta de que la calidad de los resultados de la ITSCM es aceptable para la
direccin ejecutiva y que los procesos de la gestin operacional funcionan en
forma satisfactoria.
4. HABILIDADES CLAVE
Las habilidades que debe presentar la persona encargada de la Gestin de la
Continuidad son:
Experimentado Nivel de Gestin TI. Experiencia en ITSCM.

Conocimiento y experiencia de las tareas de Gestin de Contratos.
Habilidad para trasladar los requerimientos de recuperacin del negocio a
requerimientos tcnicos y especificaciones.
Buenos conocimientos tcnicos de TI para asegurar la calidad de los
procedimientos a realizarse.
Habilidad para comunicarse a todos los niveles dentro de la organizacin.

Resumen
El objetivo principal de la ITSCM es dar soporte a los procesos del BCM

asegurando que las facilidades tcnicas y servicios TI requeridos (incluyendo
computadoras, redes, aplicaciones, telecomunicaciones, soporte tcnico, y
Service Desk) pueden recuperarse en los plazos requeridos y acordados con el
negocio.
El proceso ITSCM consta de cuatro etapas:
- Iniciacin
- Requerimientos y Estrategia
- Implementacin
- Gestin Operacional
Un anlisis de riesgo puede ayudar a identificar los riesgos a los que est
expuesto un negocio. Tambin dar informacin valiosa a la gestin porque
identificar las amenazas y vulnerabilidades y las medidas de prevencin que
correspondan.
Si desea saber ms acerca de estos temas, puede consultar la siguiente pgina.

UNIDAD DE
APRENDIZAJE
4
TEMA
13
GESTIN DE NIVELES DE SERVICIO


TEMARIO
Objetivos
Conceptos Bsicos


123
1. OBJETIVOS
El objetivo de la Gestin de Niveles de Servicio (o Service Level Management SLM)
es mantener y mejorar la calidad del Servicio TI, a travs de un ciclo constante de
acuerdos, monitoreo e informes de los logros del Servicio TI y la realizacin de
acciones para erradicar un servicio pobremente alineado con el negocio o la
justificacin de costos. A travs de estos mtodos, se puede desarrollar una mejor
relacin entre TI y sus Clientes.
2. CONCEPTOS BSICOS
Requerimientos de Nivel de Servicio (Service Level Requirement - SLR):
Cubren las definiciones detalladas de las necesidades del Cliente, y se utilizan
para desarrollar, modificar y comenzar los servicios. Pueden servir como guas
para el servicio y sus SLAs.
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 brindan una especificacin
detallada del servicio. Traducen los SLR (especificaciones externas) a
definiciones tcnicas necesarias para prestar el servicio (especificaciones
internas). Son una herramienta importante para monitorear la correspondencia
entre las especificaciones internas y externas.
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 Servicios
TI y no solo como la que implementa y mantiene la tecnologa. 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. Es una herramienta de comunicacin muy importante. 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 de Especificacin
y por lo tanto debe redactarse en un lenguaje sencillo para el Cliente, y no en
forma de especificaciones tcnicas.
Acuerdo de Nivel de Servicio (Service Level Agreement - SLA): 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 (Service Improvement Program SIP): Se

implementa a menudo como un proyecto, define las actividades, fases e hitos
asociados con la mejora de un servicio TI.

El Plan de Calidad de Servicio (Service Quality Plan - SQP): Es un documento

importante ya que tiene toda la informacin administrativa necesaria para manejar
la organizacin TI. Define los parmetros del proceso de la Gestin de Servicios y
de la administracin de las operaciones. El SLA define qu se entregar, a
diferencia del SQP que define cmo se entregar. 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 costos de los Cambios
estndar. Se definen los informes y los intervalos de los mismos para todos los
procesos. Los Indicadores de Rendimiento derivan de los SLRs y se documentan
en las Hojas de Especificaciones de Servicio. Cuando estn implicados
proveedores externos en la entrega del servicio, como la gestin externa de un
Service Desk o el mantenimiento de PCs, entonces los Indicadores de
Rendimiento tambin se registran en los Contratos de Soporte (UC).
Acuerdo de Nivel Operacional (Operational Level Agreement - OLA): 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, escalamiento, etc.,
objetivos para que el Soporte de Red comience a investigar y resolver Errores
relacionados con la red que se les asign, etc.). los OLAs ayudan a la
organizacin a proporcionar los servicios.
Contrato de Soporte (Underpinning Contract - UC): 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 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.

El proceso es un ciclo completo de calidad. Una vez que se han definido los SLAs,
empieza el ciclo (ver Figura 13.1).
3.1 Establecer Funcin
Si todava no se ha establecido la Gestin de Nivel de Servicio entonces el primer

paso es programar el proceso. Actividades tales como disear procedimientos, crear
catlogos de servicio, editar SLAs y campaas de concientizacin son entre otros, los
temas que se tienen que planificar. Esta fase comprende:
Planificacin inicial de actividades

Plan de capacidad de monitoreo
Establecimiento de la percepcin inicial de los servicios
Establecimiento y comprobacin de los OLAs y UCs

125
Figura 13.1 Proceso SLM
3.2 Implementar SLAs
Esta fase comprende:
Produccin de un Catlogo de Servicios Gestin de expectativas

Planificacin de la estructura del SLA
Establecimiento de los SLRs y edicin de los SLAs Eleccin del texto y los
trminos de los SLAs
Bsqueda de acuerdos
Establecimiento de las capacidades de monitoreo Revisin de los OLAs y UCs
Definicin de los procesos de revisin e informes Anuncio (publicidad) de la
existencia de SLAs
3.3 Gestionar el proceso continuado
Monitoreo e informes
Reuniones de revisin de servicios ad-hoc
3.4 Revisin peridica
Reuniones de revisin de servicio peridicas Creacin del SIP

Mantenimiento de SLAs, UCs y OLAs

3.5 Contratos y Acuerdos
Los UCs y los OLAs se deben desarrollar para permitir alcanzar los objetivos de los
SLAs. Los proveedores internos normalmente estarn proporcionando servicios de
instalaciones (alojamiento) y varias formas de soporte tcnico. Si es necesario, puede
que haga falta modificar los SLAs para alinearlos con los contratos existentes pero es
preferible renegociar el contrato. Ventajas claras surgen de alinear la direccin de
contratacin de proveedores con la direccin de SLAs.
Figura 13.2 Contratos y Acuerdos
3.6 Programa de Mejora de Servicio
El proceso de Gestin de Nivel de Servicio a menudo genera un buen punto de

partida para un Programa de Mejora de Servicio (SIP).
Cuando se ha identificado una dificultad que impacta negativamente la calidad del

servicio, la Gestin de Nivel de Servicio debe, conjuntamente con la Gestin de
Problemas y Disponibilidad, iniciar un SIP para identificar e implementar las acciones
necesarias para superar las dificultades y restaurar la calidad del servicio. Las
iniciativas de SIP tambin pueden centrarse en aspectos como capacitacin del
Usuario, pruebas (testing) de sistemas y documentacin. En estos casos, se
involucran a las personas relevantes y se proporciona el feedback adecuado para
hacer mejoras en el futuro.
En cualquier momento, un nmero de iniciativas separadas que forman parte del SIP
se pueden realizar en paralelo para afrontar las dificultades de varios servicios.

127
3.7 Elementos de un SLA
3.7.1 General
Introduccin
Partes en el acuerdo
Ttulo y breve descripcin del acuerdo Signatarios o firmantes
Fechas: inicio, fin, revisin
Alcance del acuerdo: qu cubre y qu excluye
Responsabilidades del proveedor del servicio y del Cliente Una descripcin
de los servicios que cubre
Informes y revisiones del servicio: Contenido, frecuencia y distribucin de

informes del servicio, y la frecuencia de reuniones de revisin del servicio.
Incentivos y penalidades por rendimiento: Detalles de los acuerdos respecto a

incentivos o penalidades financieras, basados en el rendimiento contra los
niveles de servicio.
3.7.2 Soporte del servicio
Horas de servicio: 24x7, 8x5, requerimiento de extensiones del servicio, horas

especiales (feriados), calendario del servicio.
Soporte: Horas de soporte, requerimiento de extensiones del soporte, horas

especiales (feriados), tiempos de respuesta y de reparacin (segn prioridad).
Cambios: Objetivos para aprobar, manejar e implementar RFCs (segn

categora o urgencia/prioridad).
3.7.3 Entrega del servicio
Disponibilidad: Objetivos de disponibilidad dentro de las horas acordadas

(normalmente expresados en porcentajes), periodo y mtodo de medicin.
Confiabilidad: Nmero de interrupciones del servicio, MTBF, MTBSI.
Rendimiento: Nmero de transacciones a ser procesadas, nmero de

usuarios concurrentes, cantidad de datos a ser transmitidos por la red.
Tiempo de respuesta por transaccin: Percentiles (p.e. 95% <= 2 seg.).
Contingencia y seguridad: Breve mencin de los Planes de Continuidad del

Servicio TI, cmo invocarlos, y cobertura de aspectos de seguridad (p.e.
backups, passwords).
Cobros: Detalles de la frmula y periodos de cobro.

3.8 Monitoreo
Las mediciones del Nivel de Servicio tienen que ser correctamente definidas y tienen
que cumplir con los valores objetivos fijados. Los Niveles de Servicio tienen que
medirse desde la perspectiva del Cliente, no solo trata de asuntos tcnicos, sino
tambin de asuntos de procedimiento, p.e. siempre y cuando no se haya informado al
Cliente que el servicio se ha restaurado, entender que sigue sin funcionar. Tambin
datos como tiempos de respuesta, tiempos de escalamiento y soporte se deben
volver mensurables. A fin de obtener una visin completa, la informacin de gestin
de los sistemas como de la Gestin de Servicios deben ser combinados.
3.9 Informes de servicio y de gestin
Los informes de servicio (de Clientes) se deben producir de forma regular como se
acuerde en el SLA. Estos informes comparan los niveles de servicio acordados y los
niveles de servicio que se miden en realidad. Estos informes pueden incluir:
La disponibilidad o no-disponibilidad medida durante una cierta cantidad de

tiempo (Downtime)
Los tiempos de respuesta medios durante las horas punta de carga de
trabajo Las velocidades de transaccin durante las horas punta
El nmero de errores funcionales en el servicio TI
Frecuencia y duracin de la degradacin del servicio (cuando los servicios
rinden por debajo de un nivel determinado)
El nmero medio de usuarios en horas punta de carga de trabajo
El nmero de intentos con o sin xito de violacin de la seguridad
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 SLAs concluidos

Nmero de veces en las que no se cumpli con el SLA Costo de monitoreo y
medicin del SLA
Satisfaccin del Cliente al realizar encuestas y registros de quejas
Estadsticas de Incidentes, Problemas y Cambios
4.1 Rol del Gestor de Nivel de Servicio
Implementar y mantener el proceso de la SLM en el nivel requerido por la

organizacin.
Crea y mantiene un catlogo de los servicios existentes ofrecidos por la

organizacin.
Formula, acuerda y mantiene una estructura SLM apropiada para la
organizacin. Negocia, acuerda y mantiene los SLAs con el Cliente.
Negocia, acuerda y mantiene los OLAs con el proveedor TI.
Negocia y acuerda con el Cliente y el proveedor TI los SLRs.

129
Analiza y revisa el rendimiento del servicio contra los SLAs y OLAs.

Realiza informes peridicos sobre el rendimiento y los logros del servicio para el
Cliente y el proveedor TI en un nivel apropiado.
Organiza y mantiene el proceso peridico de revisin de Nivel del Servicio
regularmente con el Cliente TI y el proveedor TI.
Inicia las acciones requeridas para mantener o mejorar los niveles del servicio.
Conduce las revisiones anuales del proceso de Nivel del Servicio y negocia,
acuerda y controla las enmiendas necesarias.
Coordina los cambios temporales de los niveles del servicio (p.e. horas extra de
soporte requeridas por el cliente, reduccin de los Niveles de Servicio durante un
periodo de mantenimiento requerido por el proveedor TI, etc.).
4.3 Habilidades clave
Habilidades de Gestin de Relaciones.

Buen conocimiento de los servicios de los Proveedores TI para entender como
los requerimientos del Cliente afectarn la entrega.
Conocimiento del negocio del Cliente y cmo TI contribuye con el
mismo. Excelentes habilidades de comunicacin y negociacin.
Paciencia, tolerancia y capacidad para adaptarse.
Conocimiento y experiencia en la gestin de proveedores y contratos.
Buenas habilidades administrativas y de gestin de personal.
Buenos conocimientos de los principios y procesos estadsticos y
analticos. Buenas habilidades para la realizacin de presentaciones.
Buenas habilidades numricas.
Habilidad de interactuar satisfactoriamente en todos los niveles de la
organizacin del Cliente y del proveedor TI.
Conocimientos tcnicos y habilidades para traducir los requerimientos y
especificaciones tcnicas en conceptos fcilmente entendibles por el negocio y
viceversa.
Innovador con respecto a la calidad del servicio y formas de mejorarlo, teniendo
en cuenta los lmites de la organizacin (recursos, presupuestos, leyes, etc.).

Resumen
El Acuerdo de Nivel de Servicio (Service Level Agreement - SLA) 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.
El Acuerdo de Nivel Operacional (Operational Level Agreement - OLA) 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.
El Contrato de Soporte (Underpinning Contract - UC) 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.

UNIDAD DE
APRENDIZAJE
4
TEMA
14
GESTIN DE LA DEMANDA
Al trmino de la unidad, el alumno explicar la principal funcin de la

Gestin de la Demanda, priorizando los activos de TI segn la demanda del
servicios.
TEMARIO
Objetivos
Conceptos Bsicos


Al contrario que los bienes materiales, los servicios no pueden producirse con
antelacin y almacenarse hasta que el cliente los solicita. Es un proceso simultneo:
la produccin y el consumo tienen lugar al mismo tiempo, circunstancia que
complica enormemente la planificacin de la demanda.
La Gestin de la Demanda se encarga de predecir y regular los ciclos de consumo,

adaptando la produccin a los picos de mayor exigencia para asegurar que el
servicio se sigue prestando de acuerdo a los tiempos y niveles de calidad acordados
con el cliente.
Por lo general, cuanto mejor funciona un servicio, mayor demanda genera. sta, a
su vez, provoca exigencias de capacidad que los responsables compensan, como
es natural, incrementando los activos del servicio. Se genera as un ciclo de
consumo-produccin en el que el consumo es un estmulo positivo para la
produccin y viceversa.
1. OBJETIVOS
El objetivo principal de la Gestin de la Demanda es optimizar y racionalizar el uso
de los recursos TI. Su papel cobra especial protagonismo cuando existen problemas
de capacidad en la infraestructura TI, tanto por exceso como por defecto.
El origen de los problemas que la Gestin de la Demanda debe subsanar a corto

plazo se puede encontrar en:
Degradacin del servicio por aumentos no previstos de la demanda.

Interrupciones parciales del servicio por errores de hardware o software.
Incremento innecesario de costes ocasionado por un exceso de capacidad
pensado para compensar los picos de demanda pero que realmente no
aporta valor al servicio.
La Gestin de la Demanda es la encargada en estos casos de redistribuir la

capacidad para asegurar que los servicios crticos no se ven afectados o, cuando
menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma
eficiente es imprescindible que la Gestin de la Capacidad conozca las prioridades
del negocio del cliente y pueda actuar en consecuencia.
Pero una tarea no menos importante es la Gestin de la Demanda a medio y largo

plazo. Un aumento de la capacidad siempre conlleva costes que muchas veces
resultan innecesarios. Una correcta monitorizacin de la capacidad permite
reconocer puntos dbiles de la infraestructura TI o cuellos de botella y evaluar si es
posible una redistribucin a largo plazo de la carga de trabajo que permita dar un
servicio de calidad sin aumento de la capacidad.
Por ejemplo, una incorrecta distribucin de tareas puede provocar que el ancho de
banda contratado por la organizacin se muestre insuficiente en horas punta porque
se estn enviando miles de correos electrnicos asociados a procesos automticos
(tales como campaas de marketing promocional, informes de rendimiento para
clientes, etctera). En la mayora de los casos esos procesos pueden desplazarse
fuera de horas punta sin degradar la calidad del servicio, ahorrando a la
organizacin una gravosa ampliacin del ancho de banda.
2. CONCEPTOS BSICOS
Paquete de Servicio (SP)
Es una descripcin completa de un servicio TI que ya est disponible para ser
entregado a los clientes.
Los SP comprenden un Paquete de Nivel de Servicio (SLP), uno o ms servicios

esenciales y uno o ms servicios de soporte.
Paquete de Nivel de Servicio (SLP)

Consiste en la definicin de un nivel de utilidad y garanta especficos para un
Paquete de Servicio concreto. Los SLP se disean conforme a las necesidades de
un Patrn de Actividad de Negocio (PBA) particular.
Paquete de Servicio Esencial (CSP)

Es una descripcin detallada de un servicio bsico que puede ser compartido por
dos o ms Paquetes de Nivel de Servicio.
Lnea de Servicio (LOS)

Es un servicio esencial o de soporte comn a varios Paquetes de Nivel de Servicio
(SLP). Cada LOS tiene asignado un Gestor de Producto.
3. DESCRIPCIN DEL PROCESOS

3.1 Anlisis de actividad
El primer paso a la hora de acometer la racionalizacin de los recursos de una

organizacin TI consiste en conocer cules son las necesidades de rendimiento
ocasionadas por los servicios que presta.
El enfoque ms extendido para predecir la demanda es el basado en actividades, y

consiste en analizar los patrones de actividad del negocio (PBAs) y predecir la
demanda tomando como referencia los activos del servicio que soportan esas
actividades.
Figura 14.1 Anlisis de actividades basado en actividades

La Gestin de la Demanda basada en actividades se encarga de:
Monitorizar y analizar los patrones de actividad del proceso de negocio con

el fin de predecir la demanda de servicios.
Asignar las unidades de demanda adicionales generadas por la actividad del
negocio a elementos de la capacidad del servicio.
Asegurarse de que, en lo que se refiere a patrones de demanda, los planes
de negocio del cliente estn alineados con los planes de gestin del servicio
del proveedor.
Por otro lado, tambin es clave para que la Gestin de la Demanda pueda tomar
decisiones estratgicas acertadas que en esta primera etapa se recabe y analice
informacin sobre el mercado en el que opera el servicio:
Necesidades de los clientes a los que se dar servicio, agrupndolos por

segmentos de mercado.
Alternativas de las que disponen los clientes de esos segmentos, tanto si se
trata de servicios ofrecidos por sus propias organizaciones como de otros
proveedores de la competencia.
3.2 Desarrollo de la Oferta
Una vez realizado un anlisis del negocio y concretados una serie de patrones de
demanda del mismo, es el momento de racionalizar los servicios. El punto de partida
consiste en distinguir dos grandes grupos de servicios:
Servicios esenciales, sin los que el negocio no puede satisfacer las

necesidades del cliente. Representan el valor que el cliente desea y por tanto,
por lo que est dispuesto a pagar.
Servicios de soporte, que pueden estar orientados a dar continuidad al

servicio o a mejorar su propuesta de valor (p.ej. Centro de Atencin al Usuario).
Representan aquellas caractersticas que diferencian nuestro producto de otros
similares ofrecidos por la competencia.
La Gestin de la Demanda toma estos elementos y, con la informacin que tiene a

su alcance acerca del mercado y las necesidades de los clientes, define una serie
de paquetes de servicio adaptados a los distintos segmentos de clientes.
Los paquetes de servicio contienen una descripcin detallada del servicio TI, que ha
de incluir necesariamente:
Paquete de nivel de servicio (SLP). En l se especifican los niveles de

utilidad y garanta de los que disfrutarn los usuarios de los servicios.
Uno o ms servicios esenciales y su descripcin.
Uno o ms servicios de soporte y su descripcin.
Este proceso, que podemos llamar empaquetado o paquetizacin, permite a la

organizacin adaptar el suministro de un mismo servicio a distintos casos de
negocio, con diferentes niveles de servicio, precios, etc.

Adicionalmente, al definir una serie de servicios esenciales, se crea un Paquete de

Servicio Esencial (CSP) cuyos activos son compartidos para todos los paquetes de
servicio.
Figura 14.2 Empaquetado de Servicios
La Gestin de la Demanda debe comprobar, por ltimo, que los distintos paquetes
de servicio deben ajustarse debidamente a las restricciones financieras (p.ej.
polticas de precios y facturacin), tcnicas (p.ej. conexin) y fsicas (p.ej.
disponibilidad) a las que est sometida la organizacin TI.
Dado el caso, la Gestin de la Demanda puede introducir desde la raz algunas

tcnicas que ayuden a regular el consumo y racionalizar los recursos. Algunas de
estas tcnicas son:
Escalonar el inicio de la jornada laboral

Dar prioridad a los informes y procesos por lotes
Ejecutar durante la noche (o fuera de las horas de trabajo) aquellos
informes y trabajos que no sean crticos.
Restringir aquellas actividades que no sean urgentes durante los periodos de mayor
actividad.

Resumen
Encargada de predecir y regular el consumo de los servicios adaptando la

produccin del servicio segn os picos de mayor exigencia y consumo para
asegurar que el servicio se sigue prestando de acuerdo a los tiempos y niveles
de calidad acordados con el cliente
El proceso cuenta con dos principales actividades:
Anlisis de la actividad
Consiste en conocer cules son las necesidades de rendimiento ocasionadas

por los servicios que presta.
Desarrollo de la oferta
Consiste en racionalizar los servicios en funcin del anlisis de la demanda, los
servicios que cuenten con mayor demanda contaran con mayor capacidad en
cuanto a sus recursos, cuando estos servicios bajen en cuanto a su demanda ya
no ser necesario el aumento de la capacidad permitiendo mejorar la capacidad
de otros servicios ms urgentes.

UNIDAD DE
APRENDIZAJE
4
TEMA
15
GESTIN DEL CONOCIMIENTO

Al trmino de la unidad, el alumno ser capaz de reconocer la importancia

de gestionar el conocimiento o experiencias vividas para las decisiones o
soporte en el futuro.
TEMARIO
Objetivos
Conceptos Bsicos


El aspecto ms beneficioso de trabajar en equipo reside en la oportunidad de

compartir el saber, las ideas y la experiencia acumulada de todos los integrantes del
mismo. Este fenmeno se reproduce, a mayor escala, cuando son todos los
miembros de una organizacin los que contribuyen a crear un acervo comn de
conocimientos.
La experiencia y conocimientos del personal, informacin de contacto y servicios

ofrecidos por los proveedores, as como detalles sobre la rutina diaria
(comportamiento de los usuarios, rendimiento de la organizacin, etc.) constituyen
informacin muy til para ahorrar tiempo y esfuerzo.
La cantidad de informacin que una organizacin puede generar, incluso una de

dimensiones modestas, es suficientemente voluminosa como para que resulte
imprescindible una gestin centralizada de la misma. La Gestin del Conocimiento
se encarga de establecer unos criterios de registro y de acometer labores peridicas
de clasificacin, evaluacin y mejora de los datos disponibles.
Una buena Gestin del Conocimiento ha de colaborar estrechamente con los

procesos de las otras fases del Ciclo de Vida para documentar y analizar:
Los errores detectados y las soluciones aportadas en cada caso,

principalmente desde la Gestin de Incidencias y Errores. De esta manera,
puede confeccionarse un registro que recibe el nombre de KEDB y que
ayuda a minimizar el tiempo de catalogacin y solucin de los mismos en el
futuro. Asimismo, la Gestin de Problemas puede hacer un seguimiento del
histrico de errores, establecer relaciones y determinar con mayor facilidad
las causas de los mismos.
La Gestin de Cambios aportar documentacin sobre las propuestas de

cambio llegadas desde la fase de Mejora Continua del Servicio, tanto si han
sido preaprobadas como si se han desechado.
La informacin relativa a las posibles consecuencias del error, que puede

proporcionar al Centro de Servicios la posibilidad de anticiparse al cliente.
La Gestin del Conocimiento es la encargada, por ltimo, de centralizar toda esta

informacin en un repositorio denominado Sistema de Gestin del Conocimiento del
Servicio (SKMS).
1. OBJETIVOS
La Gestin del Conocimiento es la encargada de reunir, analizar, almacenar y
compartir el conocimiento e informacin de la organizacin. El objetivo principal del
proceso consiste en mejorar la eficiencia, reduciendo la necesidad de redescubrir el
conocimiento.
La Gestin del Conocimiento contribuye a mejorar la calidad de las decisiones que

se adoptan en una organizacin, al garantizar que aquellos a quien corresponde
tomarlas disponen de informacin segura y fiable.

Sin embargo, una organizacin puede tener las herramientas adecuadas para
registrar y organizar los datos, pero los buenos propsitos pueden no llegar a
materializarse nunca si no existe una unidad de Gestin del Conocimiento que
impulse, coordine y estructure el proceso para:
Garantizar que el personal hace uso de las herramientas, tanto para registrar
como para consultar los datos disponibles.
Evaluar los datos recogidos, velando por que estn permanentemente
actualizados.
Analizar las necesidades de informacin de ciertos departamentos y
coordinar la correcta transferencia de conocimiento desde aquellos que
poseen los datos.
Estas funciones requieren, de quienes desempean las labores de Gestin del

Conocimiento, un entendimiento profundo de los procesos que se desarrollan en la
organizacin, as como una constante monitorizacin del registro, organizacin y
aprovechamiento de los datos.
Los beneficios obtenidos de una correcta Gestin del Conocimiento son numerosos:
No se duplica el trabajo innecesariamente. Si surge un problema que ya se

present en el pasado, pueden recuperarse con facilidad los detalles de la
solucin aplicada entonces, ahorrando tiempo y esfuerzo.
Mejor aprovechamiento de los recursos existentes.
Prevencin de situaciones de desinformacin en caso de faltar los
propietarios de los datos de acceso a una aplicacin, de contacto con un
cliente, etc.
Las principales dificultades que se presentan a la hora de abordar la Gestin del

Conocimiento consisten en:
Los miembros del personal estn saturados de trabajo y no disponen de

tiempo para documentar los datos o dan prioridad a otras tareas ms
urgentes.
Los miembros del personal no confan en los datos registrados, de modo
que recurren a otras vas a la hora de buscar informacin.
Los datos estn mal estructurados, son incompletos o no estn adaptados a
la audiencia a la que van destinados, por lo que en la prctica resultan
inservibles.
Los datos se registran pero no se revisan, por lo que la informacin
disponible est desactualizada o incompleta.

2. CONCEPTOS BSICOS
Sistema de Gestin del Conocimiento del Servicio (SKMS)
Un Sistema de Gestin del Conocimiento del Servicio o SKMS es una herramienta

que proporciona funcionalidades de presentacin, procesamiento y gestin para
interactuar con la Base de Datos de Gestin del Conocimiento del Servicio de la
organizacin IT.
Un SKMS est estructurado de forma estratificada, en varias capas que se articulan

en torno a la base de datos donde se almacena la informacin propiamente dicha:
Capa de presentacin. Es la interfaz que permite buscar, explorar,

almacenar, recuperar y actualizar los datos a travs de una serie de
interfaces especficas para cada proceso interesado: vista de Gestin de la
Calidad, vista de Activos y Configuracin, etc.
Capa de procesamiento de conocimiento. Las funciones asociadas a esta
capa incluyen el anlisis de los datos, la elaboracin de informes, la
planificacin, el modelado de los datos y la monitorizacin de los cambios a
travs de paneles de control.
Capa de Integracin de la Informacin. Es donde est la Base de Datos de
Gestin, propiamente dicha, y donde se desarrollan todas las actividades de
integracin de datos: minera de datos, gestin de metadatos,
sincronizacin, etc.
Herramientas y fuentes de datos e informacin. En esta capa es donde se
estructura la informacin
Figura 15.1 SKMS y su alcance en el ciclo de vida del Servicio

3. DESCRIPCIN DEL PROCESOS

3.1 Estrategia del conocimiento
A la hora de planificar el proceso de Gestin del Conocimiento es preciso definir,

desarrollar y difundir:
Una serie de polticas generales referentes a los datos: qu registrar, cundo

hacerlo, cmo estructurar los datos, etc.
Las condiciones de administracin: qu clase de informacin es susceptible
de ser corregida o eliminada.
Los roles: quin registra la informacin, quin la revisa, quin la valida,
quienes la pueden consultar libremente.
Procedimientos de registro, revisin y validacin de la informacin.
3.2 Transferencia del conocimiento
Es tarea de la Gestin del Conocimiento, en primera instancia, transmitir a todos los

miembros de la organizacin TI la importancia de registrar la informacin
relacionada con su trabajo en las herramientas dispuestas para ello.
Por otro lado, es tambin su labor instalar una cultura de aprendizaje constante
entre los miembros del personal. No slo se trata de hacer que los empleados
registren los datos, sino tambin motivarlos a que acudan a las fuentes de
conocimiento para completar aquello que no saben.
Asimismo, la Gestin del Conocimiento se ocupa de:
Detectar las necesidades de conocimiento existentes en la organizacin,

tanto a nivel particular como grupal.
Conocer en todo momento quin o quines poseen esa informacin.
Establecer el canal adecuado para que los propietarios del conocimiento
puedan transferirlo a quienes lo necesitan: seminarios, anuncios, boletn,
peridico.
3.3 Gestin del conocimiento
La Gestin del Conocimiento debe garantizar que la informacin disponible sea

completa y est puntualmente actualizada, ya que de otro modo puede resultar
intil.
Las labores de gestin comportan una monitorizacin exhaustiva de los cambios

registrados en el SKMS, y una serie de tareas asociadas a esta revisin:
Iniciar y gestionar procesos de borrado de informacin.

Determinar la periodicidad de las revisiones.
Detectar y subsanar incoherencias en los datos registrados.

3.3 Uso del SMKS
En el SKMS han de estar disponibles todos los documentos generados por el resto
de procesos:
Gobierno de TI: Cartera de Servicios, informes, CSI, Riesgos y otras

cuestiones.
Calidad: Polticas, procesos, procedimientos, formularios, plantillas, listas de
comprobacin.
Servicios: Catlogo de Servicios, SPs, informes del servicio.
Activos y Configuracin: Activo financiero, informacin del CMS, informes de
estado, datos de la CMDB, fuentes definitivas.
Centro de Servicios / Soporte: Catlogo de Servicios, clientes, usuarios,
grupos de inters, CIs, incidencias, problemas, cambios, entregas,
rendimiento de las configuraciones.
3.3 Control del Proceso
Las mtricas de referencia para evaluar si la Gestin del Conocimiento est

desarrollando correctamente su labor son:
Nmero de solicitudes de entradas nuevas recibidas en un periodo

especfico.
Nmero de solicitudes de modificaciones/actualizaciones enviadas en un
periodo especfico.
Nmero de entradas nuevas publicadas en la base de datos del SKMS en un
periodo especfico.
Nmero de entradas modificadas en la base de conocimiento en un periodo
especfico.
Nmero de incidentes que recurrieron a entradas existentes en la base de
conocimiento en un periodo especfico.
Tiempo ahorrado gracias al uso de la base de conocimiento. Se calcula
comparando el tiempo medio de resolucin de incidentes que se cerraron
empleando la base de conocimiento con los que no la usaron.
Nmero de peticiones de autoayuda que declararon que la base de
conocimiento ayud en la resolucin de un asunto en un periodo
determinado.

Resumen
Encargada de gestin el conocimiento de gestin de TI de toda la organizacin,

estructurando la informacin, experiencia, documentos, incidentes, problemas
ubicacin de activos, comportamientos los cuales podrn ser de mucha utilidad
en el futuro.
El proceso cuenta con dos principales actividades:
Estrategia del conocimiento
Polticas generales asociado a los datos y como estos deben de

estructurarse, condiciones de administracin, definicin de roles y procesos.
Transferencia del conocimiento
Transmite a todos los miembros de la organizacin de TI la importancia de

registrar toda la informacin relacionada.
Gestin del conocimiento
Garantiza que la informacin est disponible y sea completa y actualizada.
Uso de SMKS
Se refiere al uso de toda la informacin estructurada, permite elaborar

informes

UNIDAD DE
APRENDIZAJE
4
TEMA
16
MEJORA CONTINUA DE LOS SERVICIOS

DE TI
Al trmino de la unidad, el alumno reconoce el proceso de mejora continua

necesario para los servicios de TI pueden alinearse al negocio o cambios
en los procesos de la organizacin.
TEMARIO
Objetivos
Definiciones


Los tiempos modernos nos exigen continuos cambios y stos deben tener un solo
objetivo en el campo de la gestin de servicios TI: ofrecer mejores servicios
adaptados a las siempre cambiantes necesidades de nuestros clientes y todo ello
mediante procesos internos optimizados que permitan mayores retornos a la
inversin y mayor satisfaccin del cliente.
Pero este objetivo de mejora slo se puede alcanzar mediante la continua

monitorizacin y medicin de todas las actividades y procesos involucrados en la
prestacin de los servicios TI:
Conformidad: los procesos se adecan a los nuevos modelos y protocolos.

Calidad: se cumplen los objetivos preestablecidos en plazo y forma.
Rendimiento: los procesos son eficientes y rentables para la organizacin TI.
Valor: los servicios ofrecen el valor esperado y se diferencian de los de la
competencia.
Los resultados de esta fase del ciclo de vida han de verse reflejados en Planes de
Mejora del Servicio que incorporen toda la informacin necesaria para:
Mejorar la calidad de los servicios prestados.

Incorporar nuevos servicios que se adapten mejor a los requisitos de los
clientes y el mercado.
Mejorar y hacer ms eficientes los procesos internos de la organizacin TI.
1. OBJETIVOS
Los principales objetivos de la fase de Mejora Continua del servicio se resumen en:
Recomendar mejoras para todos los procesos y actividades involucrados en

la gestin y prestacin de los servicios TI.
Monitorizar y analizar los parmetros de seguimiento de Niveles de Servicio
y contrastarlos con los SLAs en vigor.
Proponer mejoras que aumenten el ROI y VOI asociados a los servicios TI.
Dar soporte a la fase de estrategia y diseo para la definicin de nuevos
servicios y procesos/ actividades asociados a los mismos.
2. DEFINICIONES
2.1 Ciclo de Deming
El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar (Act),
tambin conocido como ciclo de Deming en honor a su creador, Edwards Deming,
constituye la columna vertebral de todos los procesos de mejora continua:
Planificar: definir los objetivos y los medios para conseguirlos.

Hacer: implementar la visin preestablecida.
Verificar: comprobar que se alcanzan los objetivos previstos con los
recursos asignados.

Actuar: analizar y corregir las desviaciones detectadas as como proponer

mejoras a los procesos utilizados.
Las fases del ciclo de vida del servicio son un reflejo de esta estructura bsica:
Figura 16.1 Ciclo de Deming
En cierta medida todos y cada uno de los procesos de gestin de los servicios TI
deben reproducir esa estructura asegurando que cada una de estas fases se
encuentra correctamente documentada.
La fase de Mejora Continua del Servicio juega un papel esencial en las etapas de
verificacin y actuacin aunque tambin debe colaborar en las otras etapas de
planificar y hacer:
Ayudando a definir los objetivos y las mtricas de cumplimiento asociadas.

Monitorizando y evaluando la calidad de los procesos involucrados.
Definiendo y supervisando las mejoras propuestas.
2.2 Mtricas
No se puede mejorar aquello que no se conoce y no se puede llegar realmente a

conocer aquello que no se puede medir. Es indispensable que la organizacin TI
defina una serie de mtricas que permitan determinar si se han alcanzado los
objetivos propuestos as como la calidad y rendimiento de los procesos y tareas
involucrados.
Una organizacin TI debe utilizar tres tipos de mtricas:

Tecnolgicas: que miden la capacidad, disponibilidad y rendimiento de las

infraestructuras y aplicaciones.
De procesos: que miden el rendimiento y calidad de los procesos de gestin
de los servicios TI.
De servicios: que evalan los servicios ofrecidos en trminos de sus
componentes individuales.
Las mtricas deben adaptarse a los Factores Crticos de xito (CSFs) que describen
aquello que debe pasar para que se cumplan los objetivos preestablecidos.
Asociados a cada CSF es necesario definir una serie de Indicadores Crticos de
Rendimiento (KPIs) que permitan evaluar el rendimiento y la calidad de los procesos

as como su valor y adecuacin.
Los KPIs deben medir aspectos cualitativos y cuantitativos y deben permitir evaluar
el cumplimiento de los objetivos.
Si la organizacin TI se ha propuesto, por ejemplo, como CSF la mejora en la

atencin al usuario los KPIs incluiran:
Tiempo medio de resolucin de los incidentes.

Adecuacin de los procesos de escalado.
Percepcin de los usuarios respecto a la atencin prestada mediante
encuestas de satisfaccin.
Es importante que los KPIs no obvien aspectos clave y que su cumplimiento sea
una medida objetiva del cumplimiento de los CSFs asociados. Por ejemplo, en el
caso anterior no se hace mencin a los costes y una reduccin de los mismos
podra ser parte de los objetivos preestablecidos por lo que en ese caso los KPIs
utilizados no proporcionaran todas las mtricas necesarias.
2.3 DIKW
DIKW es el acrnimo de:
Datos (Data): o materia prima, que est compuesta de mensajes o smbolos

sin procesar, por ejemplo, la lista de elementos de configuracin de una
infraestructura TI.
Informacin (Information): que proviene del anlisis de un conjunto de datos,
que, por ejemplo, se correspondera en el caso anterior a una distribucin de
proveedores por inversiones y tecnologas utilizadas.
Conocimiento (Knowledge): este proviene del proceso de interpretacin de la
informacin en trminos de experiencia y reflexin. Por ejemplo, ciertos
proveedores tecnolgicos involucrados en servicios clave corren riesgo por
no saberse adaptar al mercado y utilizar tecnologas que pueden tornarse en
obsoletas.
Sabidura (Wisdom): la capacidad de tomar la mejor decisin posible basada
en el conocimiento, informacin y datos disponibles. Por ejemplo, optar por
cambiar de proveedor tecnolgico para minimizar los riesgos asociados a
depender de proveedores que no estn correctamente alineados con las
necesidades futuras del negocio.

Figura 16.2 Flujo de DIKW
La sabidura es el componente esencial en lo que respecta al proceso de Mejora

Continua. A partir de los datos, informacin y conocimiento obtenidos durante todas
las fases del ciclo de vida del servicio se deben elaborar unos Planes de Mejora que
incorporen los cambios necesarios para aumentar la satisfaccin del cliente
mejorando el rendimiento, calidad y gestin de todos los procesos implicados.
2.4 Modelos CSI
Nunca podremos saber si hemos llegado si primero no decidimos adnde queremos

ir.
El proceso de Mejora Continua requiere de una serie de metas y objetivos que

determinen la direccin de avance y sirvan de pilares para el resto de las
actividades involucradas en el mismo.
Pero la determinacin de esas metas y objetivos est asimismo sometido a un

proceso de constante revisin que forma parte de un ciclo descrito por el modelo
CSI.
Este ciclo continuo se compone de 6 fases:
1. Establecer la visin: se deben establecer metas y objetivos alineados con el

modelo de negocio de la organizacin.
2. Conocer el estado actual: saber de dnde partimos (organizacin, recursos,
capacidades, procesos,) para poder utilizar ese estado como referencia de base.
3. Establecer objetivos cuantificables: a partir de la visin establecer hitos y
entregables que permitan realizar un seguimiento del proceso.
4. Planificar: establecer un Plan de mejora del Servicio (SIP) que determine qu
acciones son necesarias para obtener los objetivos deseados en los plazos
previstos y con el nivel de calidad predeterminado.
5. Comprobar: determinar si se han cumplido los planes y se han seguido lo
procesos establecidos.
6. Integrar los cambios: asegurase de que los cambios realizados forman parte de
la cultura de la organizacin permitindonos as reiniciar el ciclo con nuevo impulso.

Figura 16.3 Modelos CSI
2.5 Herramientas y Metodologas
Una mejora propuesta no siempre implica una mejora real. Incluso tras exhaustivos
procesos de anlisis y planificacin de las posibles mejoras se han podido obviar
aspectos crticos o imponderables que pueden afectar negativamente a los servicios
y procesos. Es indispensable disponer de metodologas y herramientas que
permitan valorar las mejoras introducidas y comparar el estado de situacin antes
y despus de la introduccin de los cambios.
Es imposible enumerar todas las herramientas y metodologas disponibles por lo

que aqu nos centraremos en algunas de las ms populares. ste listado, puede
servirnos como punto de partida para ahondar en el tema.
2.5.1 Anlisis comparativo
Consiste en comparar el rendimiento de las actividades y procesos llevados a cabo

por la organizacin con aquellos que han sido considerados como mejores
prcticas.
Este anlisis puede ser realizado a distintos niveles:
Interno: comparando con otros procesos o funciones de la propia

organizacin.
Externo: comparando con otras organizaciones competidoras o directamente
con los estndares del sector.

Los resultado de este anlisis deben incluir:
Informacin sobre el rendimiento de la organizacin.

Factores de xito y riesgos.
Propuestas sobre nuevas lneas de actuacin.
2.5.2 Anlisis de brechas (Gap analysis)
El anlisis de brechas se basa en contrastar el estado de la situacin actual y el

estado esperado o ideal. Las diferencias entre ambas situaciones suponen las
brechas que se desea eliminar.
Este anlisis se puede realizar a diferentes niveles: estratgico, tctico y operativo.
2.5.3 Anlisis DAFO
Se centra en el anlisis de las Debilidades, Amenazas, Fortalezas y Oportunidades.
Las Debilidades y Fortalezas son de carcter interno y dependientes en este caso

de la propia organizacin TI mientras que las Amenazas y Oportunidades provienen
de factores de mercado u otros factores externos.
El anlisis DAFO puede realizarse a diferentes niveles, desde una componente o

funcin hasta englobar a toda la organizacin TI.
Sus principales objetivos consisten en:
Determinar las Debilidades y buscar mtodos para eliminarlas.

Valorar las Amenazas e intentar minimizar su impacto.
Conocer las propias Fortalezas y buscar la mejor manera de rentabilizarlas.
Estudiar las Oportunidades y desarrollar estrategias que permitan
aprovecharlas.
2.5.4. Cuadro de Mando Integral (CMI)
Es un mtodo diseado por Robert Kaplan y David Norton para evaluar la actividad
de una organizacin en trminos de cumplimiento de su plan estratgico.
El Cuadro de Mando Integral (CMI) propone analizar la actividad de una

organizacin respecto a diferentes perspectivas:
Financiera
Clientes
Procesos
Innovacin y Aprendizaje
Es imprescindible determinar los KPIs asociados a cada una de estas perspectivas y

cules son los objetivos buscados. Se recomienda buscar un conjunto reducido de
KPIs que luego pueda ir amplindose con el tiempo para evitar CMIs excesivamente
complejos que dificulten su implementacin.

Resumen
Objetivos:
Recomendar mejoras para todos los procesos y actividades

involucrados en la gestin y prestacin de los servicios TI.
Monitorizar y analizar los parmetros de seguimiento de Niveles de
Servicio y contrastarlos con los SLAs en vigor.
Dar soporte a la fase de estrategia y diseo para la definicin de nuevos
servicios y procesos/ actividades asociados a los mismos.
Definiciones:
Ciclo de Deming
El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar

(Act), tambin conocido como ciclo de Deming en honor a su creador,
Edwards Deming, constituye la columna vertebral de todos los procesos
de mejora continua
Mtricas
Es indispensable que la organizacin TI defina una serie de mtricas

que permitan determinar si se han alcanzado los objetivos propuestos
as como la calidad y rendimiento de los procesos y tareas involucrados.
DIKW
DIKW es el acrnimo de: Datos (Data), Informacin (Information),

Conocimiento (Knowledge), Sabidura (Wisdom).

Manual 2017-I 04 Gestioìn de Servicios de TI - Cibertec

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual 2017-I 04 Gestioìn de Servicios de TI - Cibertec

Enviado por

Direitos autorais:

Formatos disponíveis

Gestin de

Unidad de aprendizaje 1: Fundamentos de la Gestin de Servicios de TI

Unidad de aprendizaje 2: Gestin de la Configuracin, Incidentes,

Unidad de aprendizaje 3: La Transicin y Operacin de Servicios de TI.

Unidad de aprendizaje 4: Racionalizacin y Mejora Continua de los

TEMA 13 : Gestin de Nivel de Servicio 122

CIBERTEC CARRERAS PROFESIONALES

Gestin de Servicios de TI es un curso que pertenece a la lnea de Gestin

El manual para el curso ha sido diseado bajo la modalidad de unidades de

El curso presenta en primer lugar los conceptos bsicos referidos a la gestin

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

INTRODUCCIN A LA GESTIN DE SERVICIOS DE TI

Al trmino de la unidad, el alumno describir los conceptos bsicos de la

Los alumnos seleccionarn una empresa y la describirn en base a los

CIBERTEC CARRERAS PROFESIONALES

Los proveedores de servicios TI ya no pueden permitirse el lujo de centrarse en la

Antes de comprar un producto, generalmente evaluamos su calidad, tanto como su

El servicio cumple con mis expectativas?

Si el servicio cumple o no con las expectativas depende, ante todo, de cuan

Un dilogo continuo con el cliente es esencial para refinar los servicios y

La calidad de un servicio es la capacidad que tiene ste para satisfacer las

CARRERAS PROFESIONALES CIBERTEC

acostumbrar a lo que consideraba especial al principio. Los resultados de la

As, cuando se presta un servicio, la calidad total es resultado del conjunto de

1.1 Aseguramiento de la calidad

Suministrar productos o servicios requiere actividades. La calidad de un producto o

Planificar (Plan) - Qu se debe hacer, cundo, quin debe hacerlo, cmo, y

CIBERTEC CARRERAS PROFESIONALES

Figura 1.1 Crculo de Calidad de Deming

La Gestin de Calidad es responsabilidad de todos los que trabajan en la

Aseguramiento de la calidad es un aspecto poltico dentro de la organizacin. Se

Un sistema de calidad es la estructura orgnica relacionada con responsabilidades,

La serie de estndares ISO 9000 es la que se usa generalmente para desarrollar,

1.2 Madurez de organizacin

La experiencia en la mejora de calidad de los servicios TI ha demostrado que no es

El modelo de la Fundacin Europea para la Gestin de Calidad (European

El crculo de Calidad de Deming est incorporado en el modelo EFQM. Las medidas

CARRERAS PROFESIONALES CIBERTEC

Figura 1.2 Modelo EFQM

Como herramienta adicional, la organizacin holandesa de calidad, INK, dividi el

Existen cinco etapas:

Orientada al producto - tambin conocida como ad hoc, orientada a la

En el sector de las TI, el proceso de mejora de la madurez ms conocido, es el

Inicial - el proceso ocurre ad hoc.

CIBERTEC CARRERAS PROFESIONALES

Desarrollar y mantener un sistema de calidad que cumpla con los requisitos de la

Cuando se evala la madurez de una organizacin no podemos restringirnos al

Figura 1.3 Niveles de Comunicacin y Madurez: Cliente y Proveedor

Una organizacin es una forma de cooperacin entre personas. Cualquier

Los objetivos de la organizacin describen en detalle lo que desea conseguir. Los

La poltica de la organizacin es la combinacin de todas las decisiones y medidas

CARRERAS PROFESIONALES CIBERTEC

necesidad de definir de qu manera el personal debe hacer su trabajo. En vez de

Figura 1.4 Visin, objetivos y polticas

La planificacin es necesaria para implementar las polticas en forma de actividades

Cuando se traduce la misin de la organizacin en objetivos, polticas, planificacin y

CIBERTEC CARRERAS PROFESIONALES

El resultado de las mediciones y las circunstancias cambiantes pueden llevar a la

Si el departamento TI soporta los intereses del negocio, los objetivos del

2.2 Horizonte de planificacin

Cuando se consideran las polticas y la planificacin del departamento TI, debemos

Figura 1.5 Horizonte de planeamiento

La infraestructura tcnica tiene un amplio horizonte de planificacin y su papel de