Gestión de Servicios IT - Intoducción A ITIL - Final v2 - ES

i
GESTIÓN DE SERVICIOS IT
INTRODUCCIÓN A ITIL
i
i
Índice
1. ITIL Y LOS MODELOS DE GESTIÓN DE IT..............................................1
2. GESTIÓN DE SERVICIOS IT.........................................................................5

LOS RETOS DE LA ORGANIZACIÓN...............................................................................5
NECESIDADES DE LOS CLIENTES..................................................................................6
COMPROMISO DE LA DIRECCIÓN.................................................................................6
¿POR QUÉ FALLA LA IMPLEMENTACIÓN?.....................................................................7
El problema de soporte.......................................................................................8
EXPECTACIONES DEL CLIENTE....................................................................................9
¿POR QUÉ IMPLEMENTAR GESTIÓN DE SERVICIO?....................................................10
Gestión de Servicio.............................................................................................11
PROCESOS, DEPARTAMENTOS Y PROCEDIMIENTOS....................................................11
Procesos y Tareas...............................................................................................13
CALIDAD....................................................................................................................13
3. INTRODUCCIÓN A ITIL...............................................................................15
ESTRUCTURA DE ITIL...............................................................................................15
RAZONES DEL ÉXITO DE ITIL....................................................................................19
Dominio público..................................................................................................20
Mejores prácticas...............................................................................................20
Estándar de facto...............................................................................................20
Enfoque a la Calidad.........................................................................................21
itSMF.....................................................................................................................22
LA CONTINUA REESTRUCTURACIÓN DE ITIL............................................................22
¿A QUÉ ORGANIZACIONES VA DIRIGIDO?...................................................................23
¿QUIÉN DEBERÍA LEER ITIL?....................................................................................23
BENEFICIOS DE USAR ITIL........................................................................................23
CLIENTES Y USUARIOS..............................................................................................24
4. RELACIÓN ENTRE PROCESOS.................................................................26
GESTIÓN DE LA CONFIGURACIÓN..............................................................................27
GESTIÓN DEL CAMBIO...............................................................................................28
GESTIÓN DE LA DIFUSIÓN..........................................................................................28
GESTIÓN DE INCIDENCIAS..........................................................................................29
GESTIÓN DE PROBLEMAS...........................................................................................29
SERVICE DESK...........................................................................................................29
GESTIÓN DE NIVELES DE SERVICIO...........................................................................30
GESTIÓN DE LA CAPACIDAD......................................................................................30
GESTIÓN FINANCIERA PARA LOS SERVICIOS IT.........................................................31
GESTIÓN DE LA DISPONIBILIDAD...............................................................................31
GESTIÓN DE LA CONTINUIDAD DE LOS SERVICIOS IT................................................31
GESTIÓN DE LA INFRAESTRUCTURA IT.....................................................................32
GESTIÓN APLICACIONES............................................................................................32
GESTIÓN DE LA SEGURIDAD......................................................................................32
5. SERVICE DESK..............................................................................................33
i
ii
OBJETIVO...................................................................................................................33
ACTIVIDADES............................................................................................................33
DESCRIPCIÓN.............................................................................................................34
“Desks” Distintos.................................................................................................36
Inversiones y Rendimientos (Inputs y Outputs).....................................................37
Estructuras de Service Desk..................................................................................37
Consideraciones....................................................................................................39
6. GESTIÓN DE INCIDENTES.........................................................................41
OBJETIVO...................................................................................................................41
ACTIVIDADES............................................................................................................42
FUNCIONES Y RESPONSABILIDADES..........................................................................42
Encargado de Incidentes.......................................................................................42
Plantilla para la manejo de Incidentes.................................................................42
DESCRIPCIÓN.............................................................................................................43
Terminología.........................................................................................................43
Inversiones y Rendimientos (Inputs y Outputs).....................................................44
El Ciclo de vida de la Incidencia..........................................................................45
Clasificación: Prioridad y Categoría...................................................................46
Clasificación: Emparejamiento.............................................................................47
Dirigir incidencias................................................................................................47
Escalada y Referencia...........................................................................................48
Informes de Gestión..............................................................................................49
7. GESTIÓN DE PROBLEMAS.........................................................................51
OBJETIVO...................................................................................................................51
ACTIVIDADES............................................................................................................52
Encargado de Problemas......................................................................................52
Personal para el manejo de los problemas...........................................................53
DESCRIPCIÓN.............................................................................................................53
Inputs y Outputs....................................................................................................53
Control de Problemas............................................................................................54
Control de Errores.................................................................................................55
Gestión de Problemas Proactiva (Prevención Proactiva)....................................56
Incidencias versus Problemas...............................................................................57
Procesando Errores Conocidos desde el Entorno de Desarrollo.........................58
Reactivo- Pro-activo..............................................................................................58
8. GESTIÓN DE CAMBIOS...............................................................................61
OBJETIVO...................................................................................................................61
ACTIVIDADES............................................................................................................63
Encargado del Cambio..........................................................................................64
Consejo Asesor del Cambio..................................................................................65
Función Central de Gestión de Cambio, Configuración y Difusión.....................65
DESCRIPCIÓN.............................................................................................................66
Las tareas de la Gestión de Cambios....................................................................66
Inputs y Outputs....................................................................................................67
iii
Proceso de Gestión de Cambio.............................................................................68

Solicitud de Cambio (RFC)- Alcance....................................................................69
Fijar Prioridad......................................................................................................70
El Impacto del Cambio..........................................................................................71
La Junta de Asesoramiento de Cambios (CAB)....................................................71
Relaciones Importantes.........................................................................................73
9. GESTIÓN DE LA CONFIGURACIÓN.........................................................75
OBJETIVO...................................................................................................................75
ACTIVIDADES............................................................................................................76
Administrador de la configuración.......................................................................78
DESCRIPCIÓN.............................................................................................................79
Bienes versus Gestión de Configuración..............................................................79
Base de Datos de Gestión de Configuración CMDB............................................79
Las tareas de la Gestión de Configuración...........................................................80
Rango y Detalle (Profundidad).............................................................................81
Nombramiento y otros atributos............................................................................82
Relaciones en la CMDB........................................................................................83
Impacto de las interrelaciones..............................................................................84
Estados de CI’s......................................................................................................85
Línea Base (Baseline)............................................................................................86
10. GESTIÓN DE LA DIFUSIÓN........................................................................89
OBJETIVO...................................................................................................................89
ACTIVIDADES............................................................................................................91
Encargado de la Difusión......................................................................................92
DESCRIPCIÓN.............................................................................................................93
Proceso de distribución y Difusión.......................................................................93
Biblioteca Definitiva de Software (DSL)...............................................................94
Almacén Definitivo de Hardware (DHS)..............................................................94
Difusiones..............................................................................................................95
Despliegue y distribución de Software..................................................................96
11. GESTIÓN DE NIVELES DE SERVICIO.....................................................99
OBJETIVO...................................................................................................................99
¿Por qué la gestión de Nivel de Servicio?............................................................99
El objetivo.............................................................................................................99
Alcance..................................................................................................................99
Concepto básico del SLM....................................................................................100
¿Qué es un SLA?.................................................................................................100
ACTIVIDADES..........................................................................................................101
ACTIVIDADES..........................................................................................................101
FUNCIONES Y RESPONSABILIDADES........................................................................102
Encargado del Cambio........................................................................................102
Las Tareas...........................................................................................................102
iii
iv
Las Responsabilidades........................................................................................102
Habilidades básicas............................................................................................103
DESCRIPCIÓN...........................................................................................................103
Proceso de Gestión de Nivel de Servicio.............................................................104
12. GESTIÓN FINANCIERA DE LOS SERVICIOS IT..................................109
OBJETIVO.................................................................................................................109
¿Por qué introducimos la Gestión Financiera para los Servicios IT?...............109
Conceptos básicos de la Gestión Financiera de los Servicios IT........................110
Alcance de la Gestión Financiera.......................................................................112
El Objetivo...........................................................................................................113
Encargado de la Gestión Financiera IT..............................................................113
Tareas...................................................................................................................113
Responsabilidades...............................................................................................114
DESCRIPCIÓN...........................................................................................................115
Relaciones con otros procesos de Gestión de Servicios IT.................................115
Impacto en la organización.................................................................................116
Beneficios de la Gestión Financiera para los Servicios IT.................................116
Presupuestar (Budgeting)....................................................................................118
Contabilidad IT...................................................................................................119
Clasificación de Elementos de Coste..................................................................121
Cobros.................................................................................................................122
Opciones de Cobros y Precio..............................................................................122
Posibles Problemas.............................................................................................123
13. GESTIÓN DE LA CAPACIDAD..................................................................125
OBJETIVO.................................................................................................................125
¿Por qué la Gestión de la Capacidad?...............................................................126
El Objetivo...........................................................................................................127
Consejos y Advertencias......................................................................................128
Alcance de la Gestión de Capacidad..................................................................128
Tareas..................................................................................................................130
DESCRIPCIÓN...........................................................................................................131
Inputs y Outputs..................................................................................................131
Actividades..........................................................................................................132
Dar tamaño (Sizing) a la Aplicación...................................................................134
Modelización (Modeling)....................................................................................134
14. GESTIÓN DE LA CONTINUIDAD DEL SERVICIO IT..........................135
OBJETIVO.................................................................................................................135
¿Por qué ITSCM?................................................................................................135
El objetivo...........................................................................................................135
Alcance de ITSCM...............................................................................................136
Tareas..................................................................................................................136
Habilidades Clave...............................................................................................137
v
DESCRIPCIÓN...........................................................................................................137
Conceptos básicos de ITSCM..............................................................................137
Beneficios de ITSCM...........................................................................................137
Gestión de Riesgos..............................................................................................138
La Gestión de Continuidad Empresarial y el ITSCM.........................................139
Compromisos de Gestión.....................................................................................140
Relación con otras disciplinas de Gestión de Servicios IT.................................141
Proceso de Gestión de Continuidad....................................................................141
Las Opciones.......................................................................................................144
Las siete secciones del Plan................................................................................145
15. GESTIÓN DE DISPONIBILIDAD..............................................................147
OBJETIVO.................................................................................................................147
¿Por qué Gestión de Disponibilidad?.................................................................147
La necesidad de Negocio y centralización en el usuario....................................148
El Objetivo...........................................................................................................148
Alcance................................................................................................................149
Actividades..........................................................................................................150
TAREAS....................................................................................................................150
RESPONSABILIDADES...............................................................................................151
HABILIDADES CLAVE...............................................................................................151
DESCRIPCIÓN...........................................................................................................152
Análisis de Riesgo...............................................................................................152
Seguridad............................................................................................................152
Aspectos de Disponibilidad.................................................................................153
El Ciclo Vital de la No Disponibilidad................................................................154
Cuándo está Disponible un Servicio...................................................................155
Fórmula de Disponibilidad.................................................................................156
16. PLANIFICACIÓN PARA LA IMPLEMENTACIÓN DE GESTIÓN DE
SERVICIOS..............................................................................................................157
INTRODUCCCIÓN......................................................................................................157
USO DE LOS CONCEPTOS DE LA GESTIÓN DE PROYECTOS.......................................157
ESTUDIO DE VIABILIDAD.........................................................................................158
VALORACIÓN DE LA SITUACIÓN ACTUAL................................................................158
Introducción........................................................................................................158
Una Revisión.......................................................................................................161
DIRECTRICES GENERALES EN LA PLANIFICACIÓN DE PROYECTOS...........................162
Características del proyecto...............................................................................162
Caso Empresarial para el Proyecto....................................................................163
Factores críticos de éxito y posibles problemas..................................................163
Costes del Proyecto.............................................................................................164
La Organización..................................................................................................165
Productos.............................................................................................................166
Planificación.......................................................................................................166
Plan de Comunicación........................................................................................167
REVISIÓN DEL PROYECTO E INFORMES A LA DIRECCIÓN.........................................167
Informe de Progreso............................................................................................168
Evaluación del proyecto......................................................................................169
v
vi
Revisión post-proyecto........................................................................................169
Auditoría para la conformidad utlizando los parámetros de calidad.................170
Los parámetros genéricos para la Gestión de Servicio IT..................................170
Auditando para la mejora de uso de los indicadores de ejecución.....................170
Informando a la Dirección..................................................................................171
17. HERRAMIENTAS SOFTWARE DE GESTIÓN DE SERVICIOS..........173
INTRODUCCIÓN........................................................................................................173
TIPOS DE HERRAMIENTAS........................................................................................174
RESUMEN DE LOS CRITERIOS DE EVALUACIÓN PARA LAS HERRAMIENTAS..............174
Herramientas de Gestión de Servicios................................................................175
Formación en el producto...................................................................................177
18. EJEMPLOS DE HERRAMIENTAS DE GESTIÓN DE SERVICIOS.....179
INTRODUCCIÓN........................................................................................................179
HERRAMIENTAS.......................................................................................................181
Applix-ITSM........................................................................................................181
AXIOS- ASSYST...................................................................................................183
CLARITEAM- VISIBILITY TM...........................................................................183
MANAGESOFT- MANAGESOFT.......................................................................184
MARVAL- OPEN PURSUIT/ OPEN TRACKIT..................................................184
OGD SOFTWARE- TOP DESK..........................................................................186
PEREGRINE- SERVICE CENTRE/ ASSET CENTRE........................................187
SILVERBEAR- SURVEY MANAGER..................................................................187
TOUCHPAPER- HELP DESK/ CHANGE MANAGER.......................................188
HP-OpenView SERVICE DESK..........................................................................189
19. ESTUDIO DETALLADO DE UNA HERRAMIENTA: HP OPENVIEW
SERVICE DESK......................................................................................................191
INTRODUCCIÓN........................................................................................................191
CONSOLA DE USUARIO............................................................................................192
Definiciones de Service Desk..............................................................................192
Elementos y características de la consola de usuario........................................193
CONSOLA DE ADMINISTRADOR...............................................................................199
CONFIGURACIÓN DE HP OPENVIEW SERVICE DESK...............................................200
Lógica de Negocio...............................................................................................200
Información.........................................................................................................202
Seguridad............................................................................................................204
Opciones de configuración de Service Pages.....................................................206
ARQUITECTURA DE LA APLICACIÓN........................................................................207
Arquitectura física en tres niveles.......................................................................207
Abierto y Escalable.............................................................................................208
Requerimientos mínimos.....................................................................................209
Múltiples Servidores y Clientes de Aplicación....................................................209
Arquitectura lógica de cuatro niveles.................................................................210
Interfaces abiertos...............................................................................................211
API WEB.............................................................................................................212
Apertura de Formularios desde la Línea de Comandos.....................................213
Intercambio de Información................................................................................214
Eventos de Servicio.............................................................................................214
vii
Flujo de Datos en las Service Pages...................................................................216

20. Glosario por orden alfabético...........................................................................217
vii
viii
1
1
2
3
R2C (Regulation, Control and Continuity)

La metodología de gestión de IT de Roccade.
RPM (Recursive Process Management)

Modelo especialmente útil para las fusiones, grandes reorganizaciones o
como vehículo para un cambio de cultura.
SIMA (Standard Integrated Management Approach)

La aproximación creada y usada por InterProm para el diseño de la gestión y
seguridad de infraestructuras IT abiertas y multi-vendedor.
3
4
5
5
6
El problema de soporte
Hay muy pocos SLAs que consiguen su supuesto objetivo de mejorar la

calidad de servicio. Eso es si de verdad existen SLAs. Una gran causa de esto
es porque no tenemos una información de gestión disponible – las decisiones
se toman basadas en lo que “creo” en vez de en lo que “sé”. Medir la
gestión de servicio que conlleva a una mejora es muy difícil si no se puede
identificar la línea de base. Esto puede hacer muy difícil justificar un
programa de mejora de Gestión de Servicio. Si realmente algo vale lo que
cuesta no se puede juzgar sin un buen entendimiento de los costes
(incluidos los costes de los cambios). Un entendimiento de costes de servicio
también proporciona una base sólida para el desarrollo de IT.
En muchas organizaciones de IT no existe un mecanismo de soporte al

Cliente estructurado. Puede que exista Service Desk y algún tipo de apoyo
de línea secundario o terciario, pero todas aquellas organizaciones están
intentando resolver las mismas incidencias solas. No hay comunicación ni
cooperación que resulta en el hecho de que las incidencias no se resuelvan
con la suficiente rapidez y que nos enfrentemos a una calidad inconsistente
de respuesta a llamada y de tiempo de respuesta. Y desde luego, no hay
control. Esta es una de las razones por las que aquellas organizaciones
tienen un bajo nivel de percepción/confianza por parte de su cliente y
esos clientes empiezan a resolver sus propios asuntos que resulta en un nivel
de “peer support” (soporte de su propio grupo). Los costes son difíciles de
calcular, especialmente los de oportunidades, pero pueden ser altos,
afectando directamente al negocio.
La mayoría de organizaciones son dirigidas por acciones reactivas e

interrupciones. Los recursos de soporte están infragestionados y están
continuamente peleándose, resolviendo incidencias y problemas
repetidamente en lugar de eliminarlos definitivamente.
Cambios no coordinados y sin registrar ocurren cada día. Este mal control
del cambio cuesta mucho dinero y agota recursos porque debemos hacer las
cosas una y otra vez. Una falta de Gestión de Cambios puede tener efectos
negativos mayores en otros procesos porque no controlamos nuestro
entorno. Por ello, también nos incapacita para poder manejar los cambios
en nuestro negocio.
En el de tema de Personal, también tenemos asuntos. En primer lugar,

sobre dependemos de empleados clave porque no documentamos los
conocimientos que tienen en su cabeza. En segundo lugar, en muchos
empleados encontramos una falta de enfoque de los temas por los que nos
encontramos aquí. Por último, los recursos de personal y los requisitos de
coste relacionados son la mayor parte del tiempo muy poco claros. A
menudo, no sabemos lo que hacen muchas personas ni por qué están aquí.
No lo saben ni ellos mismos!
7
Expectaciones del Cliente
El nuevo entorno de empresa de IT es mucho más complicado debido a:

 La Adopción del paradigma del cliente - servidor- proporcionando
flexibilidad de aplicación y facilidad de manejo (para cliente)
 Aplicaciones adaptadas a Internet- entornos realmente integradores
de negocio e IT, pero aumentando la demanda de recursos de IT y
requisitos de seguridad.
 Intentos esporádicos de re-ingeniar IT- para servir mejor las
necesidades del servicio al cliente
 Islas de herramientas de “mejor-de-su-clase” - la mayoría de las
cuales han sido soluciones “punta”.
Mientras algunos o todos estos esfuerzos pueden haber sido intentados por
varias organizaciones IT, las corporaciones de hoy se dan cuenta que es la
combinación de “procesos +personas +tecnología” lo necesario para poder
entregar servicios de calidad de verdad a sus clientes.
¿Por qué implementar Gestión de Servicio?

Habiendo reconocido que los departamentos de IT están ahora en el negocio
de proveer servicio, deben adoptar una manera completamente nueva de
pensar y abrazar los mismos conceptos de negocio que aquellos utilizados
por todos los proveedores de servicios. Tienen mucho camino por recorrer
para alcanzar a los demás.
El enfoque de Gestión de Servicio para ITIL es esa nueva manera de pensar.
Pero, no debe implementarse porque ahora mismo esté de moda. Si no se
entiende por qué está implementando ITIL, no tendrá éxito. El factor motor
debe ser el deseo de hacer entrega de valor añadido y valor real al cliente.
Mientras hay beneficios a corto plazo, muchas organizaciones necesitarán
programar a largo plazo mejoras de proceso antes de poder considerarse
mejor de su clase. Es importante reconocer que esto es uno de los mayores
beneficios de implementar la metodología de la Gestión de Servicio para la
organización. Dará a la organización:
 Mejor calidad de servicio- soporte de empresa más fiable
 Procedimientos de Continuidad de Servicio de IT más enfocados, más
confianza en la habilidad de seguirlos cuando sea necesario.
 Visión más clara de la capacidad actual de IT
 Mejor información de servicios actuales (y posiblemente de dónde
Cambios traerían los mayores beneficios).
7
8
 Mayor flexibilidad para el negocio mediante mejor entendimiento de

soporte de IT
 Empleados más motivados; mayor satisfacción de trabajo mediante
mejor entendimiento de capacidad y mejor gestión de expectaciones
 Mayor satisfacción de Cliente al saber y entregar los proveedores de
servicio lo que se espera de ellos
 Es probable que exista mayor flexibilidad y adaptabilidad dentro de
los servicios
 Ventajas conducidas por el sistema, por ejemplo mejoras en
seguridad, exactitud, velocidad, disponibilidad según se requiera para
el nivel de servicio acordado.
 Tiempo de ciclo mejorado para Cambios y un mayor nivel de éxito.
 Los costes operativos bajarán a medida que menos esfuerzo se pierda
en dar a los Clientes productos y servicios que no quieren
 Los márgenes de beneficio mejorarán a medida que se consiga más
negocio de repetición, es mucho más barato vender a un cliente
existente que rondarle a uno nuevo.
 La eficacia mejorará a medida que el personal trabaje de forma más
efectiva como equipos.
 La moral y el movimiento de personal mejorará a medida que los
empleados consigan satisfacción de trabajo y seguridad de empleo.
 La calidad de servicio mejorará constantemente, resultando en una
reputación más favorecedora para el departamento de IT lo cual
tentará a nuevos clientes y animará a clientes existentes a comprar
más.
 El departamento de IT se hará más eficaz en soportar las necesidades
del negocio y se hará más interesado en cambios en la dirección de la
empresa.
La importancia y nivel de éstos variará entre organizaciones. Definir estos
beneficios para cualquier organización de una manera mesurable más tarde
puede convertirse en una cuestión. Seguir la guía de ITIL puede ayudar a
cuantificar algunos de estos elementos.
Gestión de Servicio
Gestión de Servicio es un enfoque orientado a entregar servicios de IT
enfocados al cliente que alcanzan los objetivos de coste y realización que se
marcan en asociación con clientes de “Line of Business” (LOB) y englobados
en los acuerdos de nivel de servicio (SLAs) y acuerdos de nivel operacional
(OLAs).
Gestión de Servicio trata de la entrega y apoyo de los servicios de IT que
cumplen los requisitos de negocio de la organización. Gestión de Servicio se
9
basa en implementar procesos, preferiblemente con la orientación de una

guía como ITIL que proporciona un conjunto comprensivo, consistente y
coherente de prácticas óptimas para los procesos de Gestión de Servicio,
promocionando un enfoque de calidad a alcanzar efectividad y eficacia en el
uso de los sistemas informáticos. Los procesos de ITIL tienen la intención de
ser implementados para que apoyen pero no dicten los procesos de negocio
de una organización. Los proveedores de servicio de IT alcanzarán mejorar
la calidad de servicio, pero a la vez estarán intentando reducir costes o, al
menos, mantener costes al nivel actual.
Procesos, Departamentos y Procedimientos

Tal y como se ha descrito anteriormente, Gestión de Servicio se basa en
procesos. Un proceso es un conjunto de actividades lógicas combinadas para
obtener cierto objetivo (resultado). Las ventajas de los procesos son:
 En un proceso describimos los objetivos (resultados) y la forma en
los que los vamos a alcanzar.
 Para cada proceso, definimos la inversión (input) y el rendimiento
(output) qué necesitamos para alcanzar nuestro objetivo y cuáles
son las cosas que otros procesos necesitan de nosotros para
alcanzar los suyos (dicho de otro modo: nuestro resultado).
 Describimos una organización entera en distintos procesos,
podemos monitorizar esos procesos uno a uno. Como efecto,
monitorizamos varias partes pequeñas de una gran organización
que es mejor que monitorizar la totalidad.
 Hacemos a las personas responsables de su eficiencia, efectividad
y del resultado de su proceso, como resultado de ello no sólo
monitorizamos sino controlamos nuestra organización.
 Podemos mejorar nuestra organización porque podemos relacionar
el resultado a un modelo que tenemos (si monitorizamos) y
podemos discutir las maneras de mejorar actividades en un
proceso para alcanzar el modelo si no lo hemos conseguido. Y lo
podemos elevar el modelo y así mejorar continuamente.
 Podemos crear mejores roles y responsabilidades; podemos dividir
responsabilidades para evitar conflictos de interés. Para que así
nadie priorice los problemas como más importantes porque no “le
guste resolver incidencias”
 Las actividades que tienen que ser ejecutadas en distintas
organizaciones pero que atañen a un resultado pueden ser
controladas mejor si hay un proceso.
Los procesos son el más alto nivel de definir sus actividades y son la mayor
parte del tiempo un estándar de toda la organización. Procedimientos
(instrucciones de trabajo) son más detallados y describen exactamente
9
10
quién ejecuta ciertas actividades en un proceso. Los procedimientos pueden

variar de departamento en departamento y de actividad en actividad. Por
ejemplo: en el proceso de Cambio exigimos que cada cambio será solicitado
por un RFC (Solicitud de Cambio), pero la información que queremos que
adjunten con este RFC puede ser distinta para el departamento A de la del
departamento B. Y la información para un cambio de categoría 1 puede ser
distinta que la información de un cambio de categoría 2.
La mayoría de organizaciones están estructuradas en departamentos. Y el
personal de IT que ejecuta distintas actividades en un proceso es parte de
ese departamento. Por ejemplo si queremos resolver una incidencia
tenemos primera línea de soporte, segunda y tercera y especialista. Todos
son - probablemente- parte de tres o cuatro departamentos, pero en “algún
momento en el tiempo” parte de este sólo proceso, con un sólo objetivo;
restaurar el servicio lo antes posible! Y el mismo personal de IT puede ser
parte de otros procesos en otros “momentos en el tiempo”. Esta es, claro
está, una de las mayores ventajas de los procesos pero puede estar
causando problemas si los encargados de procesos y directores de
departamentos no tienen acuerdos sobre cómo asignar recursos. Así qué por
último pero no por ello, con menor importancia tenemos que afrontar este
atasco en potencia.
Procesos y Tareas
Cada proceso puede desmigarse en una serie de tareas. Para cada tarea,
habrá Inversiones y Rendimientos “lnputs y Outputs” (mostrados como Real
World Objects, RWO, en el diagrama).
Cada tarea será ejecutada por un rol. Esto puede ser encarnado por un ser
humano o realizado por una pieza de software. Si es humano-céntrico,
entonces habrá una serie de competencias que un individuo necesita para
llevar a cabo ese rol.
La ejecución del rol está gobernada por un conjunto de normas. Estas irán
desde la sencilla (“Todas las casillas deben estar marcadas en este
impreso”) a la muy compleja (“Sólo se permitirá crédito si un conjunto de
criterios se cumplen de acuerdo con un algoritmo”).
A menudo, un proceso abarcará varios límites de organización. Es
importante, por lo tanto, que cada proceso tenga un propietario. Este es
otro rol.
El propietario del rol es responsable de la definición del proceso, que debe
ser tratado como un CI, sujeto al proceso de control de Cambio normal. El
dueño del proceso es el responsable de asegurar que todas las personas
involucradas en la ejecución del proceso estén informadas de cualquier
Cambio que ocurra.
11
Calidad
“Hemos aprendido a vivir en un mundo de errores y productos

defectuosos como sí fueran necesarios para vivir. Es hora de adoptar
una nueva filosofía...” (W. Edwards Deming, 1900-93)
La manera en la que una organización programa manejar sus operaciones

para que entregue servicios de calidad está especificada por su
departamento de Gestión de Calidad. El sistema de gestión de calidad
define la estructura de la organización, roles y responsabilidades, políticas,
procedimientos, procesos, estándares y recursos necesarios para la entrega
de servicios de calidad de IT. Sin embargo, un sistema de gestión de calidad
sólo funcionará como debe si dirección y personal están comprometidos a
alcanzar sus objetivos.
Extractos de los catorce puntos de Deming relevantes a Gestión de Servicio:
 Derribar barreras entre departamentos (mejora comunicaciones y
dirección)
 Los directores deben aprender sus responsabilidades y asumir
liderazgo (mejora de procesos requiere compromiso desde arriba;
buenos líderes motivan a las personas a mejorarse y por lo tanto la
imagen de la organización)
 Mejorar constantemente (un tema central para gestores de
Servicio es la mejora constante; Esto también es una cuestión para
gestión de calidad. Un enfoque orientado a los procesos es clave
para alcanzar este objetivo)
 Instalar educación y auto mejora (aprender y mejorar habilidades
ha sido el enfoque de Gestión de Servicio durante años)
 Formación en el puesto de trabajo (Training on the Job) ligado a
mejora continua.
 Transformación de los trabajos de todas las personas (el énfasis
estando en el trabajo en equipo y el entendimiento)
Para la mejora de calidad, Deming propuso el Ciclo o Círculo de Deming. Las
cuatro etapas clave son programar, hacer, comprobar y actuar, después de
lo cual una fase de consolidación evita que el “Círculo” “ruede cuesta
abajo”. La fase de consolidación permite a la organización darse cuenta de
lo que ha ocurrido y asegurar que las mejoras se asienten. A menudo, una
serie de mejoras han sido aplicadas a procesos que requieren
documentación (tanto como para permitir que se pueden repetir como para
facilitar el reconocimiento de haber alcanzado algún tipo de estándar de
calidad).
W. Edwards Deming se conoce mejor por su filosofía de gestión
estableciendo calidad, productividad y posición competitiva. Como parte de
11
12
esta filosofía, formuló catorce puntos de atención para directores. Algunos

de estos puntos son más adecuados para Gestión de Servicios que otros.
13
3.Introducción a ITIL
Las siglas de ITIL se corresponden a “Information Technology

Infrastructure Library”, que podíamos traducir como la biblioteca de la
infraestructura de las tecnologías de la información.
Como hemos visto en el capitulo anterior y a pesar no poder considerar a

ITIL como el modelo de referencia perfecto para la Gestión de Servicios IT,
sí podemos decir que es el estándar de facto en estos momentos a nivel
mundial y que ha sido adoptado como base por grandes compañía de gestión
de servicios como IBM, HP y Microsoft, tanto para la creación o ampliación
de sus propios modelos, como para consultoría, educación y herramientas de
software para el soporte, y es utilizado a parte de éstas en otras grandes
empresas como Barclays Bank, HSBC, Guinness y Procter & Gamble.
Fue desarrollado a finales de los años 80 por el Reino Unido dentro del
departamento llamado OGC (Office of Government Commerce),
antiguamente conocida como CCTTA (Central Computer and
Telecommunications Agency).
Estructura de ITIL
Inicialmente ITIL era un conjunto de 45 libros, que actualmente se
encuentran agrupados bajo 7 publicaciones, disponibles tanto en libro como
en CD. Cada una de estas publicaciones describe un conjunto principal de
procesos de Gestión de Servicios IT.
Estos son los 7 conjuntos de procesos:
13
14
Soporte a servicios
Se centra en asegurar en el cliente tiene acceso a los
servicios adecuados para soportar las funciones de
negocio. Los puntos que incluye son Service Desk,
Gestión de incidentes, gestión de problemas, gestión de
la configuración, gestión de cambios y gestión de la
difusión.
También cubre las necesarias interacciones entre estas

y otra disciplinas fundamentales de la gestión de
servicios, y actualiza las mejores prácticas para reflejar
los cambios recientes en la tecnología y las prácticas de
negocio.
Procesos tratados en esta publicación:

 Service Desk
 Gestión de incidencias
 Gestión de problemas
 Gestión de la configuración
 Gestión de cambios
 Gestión de difusión
Entrega de servicios
Es el segundo elemento de la reestructuración de los
procesos de ITIL. Los proveedores de servicios deben
ofrecer a los usuarios un adecuado soporte, la entrega
de servicios cubre todos los aspectos que se deben
tener en cuenta. El propósito de la entrega de servicios
es mostrar los vínculos y las principales relaciones entre
todos los procesos de gestión de servicios y de
infraestructura.

 Gestión de los niveles de servicio
 Gestión de la capacidad
 Gestión Financiera de los Servicios IT
 Gestión de la continuidad
 Gestión de la disponibilidad
 Gestión de las relaciones con el cliente
15
Planificación de la implementación de la gestión de

servicios
Explica los pasos necesarios para identificar como una
organización puede esperar beneficiarse de ITIL, y
como que hacer para recoger estos beneficios.

 Proceso de mejorar continua
Gestión de la Seguridad
Esta es una de las nuevas guías introducidas tras la
revisión de ITIL y explica los procesos de gestión de la
seguridad con la gestión de servicios IT. La guía se
centra en el proceso de implementación de los
requisitos de seguridad identificados en los acuerdos
de niveles de servicio IT más que en la consideración de
los políticas de seguridad para el negocio.

 Gestión de la seguridad
La perspectiva de negocio
Presta atención al conocimiento de la provisión de
servicios IT. Los temas tratados cubren la gestión de la
continuidad de negocio, el Outsourcing y asociaciones,
supervivencia a los cambios y la transformación de las
prácticas de negocio a través del cambio radical

 Gestión de la continuidad de negocio
 Outsourcing y asociaciones
 Sobrevivir a los cambios y Transformación de
las prácticas de negocio a través del cambio
radical
 Comprensión y mejora
15
16
Gestión de la infraestructura
La gestión de la infraestructura cubre la gestión del
servicio de red, la gestión de las operaciones, la gestión
de los procesadores locales, la aceptación e instalación
de los ordenadores y por primera vez, la gestión de los
sistemas.

 Gestión del servicio de red
 Gestión de las operaciones
 Gestión de los procesadores locales
 Aceptación e instalación de los ordenadores
 Gestión de los sistemas
Gestión de aplicaciones
Cubre el ciclo de vida del desarrollo de Software,
expandiendo los asuntos tratados en el soporte del ciclo
de vida del software y en las pruebas de los servicios IT.
También da más detalles sobre los Cambios de Negocios
con el énfasis puesto en la clara definición de requisitos
y la implementación de soluciones.

 Soporte del ciclo de vida del software
 Prueba de los servicios IT
Los más ampliamente implementados son los conjuntos de Entrega y

Soporte de Servicios, con todos sus procesos.
Los principales elementos de ITIL pueden ser comparados a la superposición

de las piezas dentadas de un puzzle (o incluso mejor como placas
tectónicas), en las que algunas ajustan perfectamente y otras en cambio se
solapan o no ajustan con precisión. Al nivel más alto, no hay líneas de
demarcación estrictas.
Ciertamente, si consideramos la analogía con las placas tectónicas, unas

deslizan sobre y bajo otras, uniéndose y separándose, haciendo surgir los
problemas de puntos de inestabilidad o fricción sobre la tierra causados por
el ajuste impreciso de las piezas, es aquí donde tiene su equivalencia en la
gestión de servicios. Es, precisamente, cuando los dominios de procesos se
solapan o las líneas de demarcación no pueden ser dibujadas claramente,
cuando muchos problemas de gestión salen a la luz. No se puede evitar que
17
los problemas ocurran (igual que no se puede parar los terremotos), pero se
puede dar recomendaciones sobre como prepararse y tratar con estos
problemas.
Los elementos de los procesos para la gestión de servicios pueden ser

definidos con precisión. En la práctica, cuando se analizan los procesos en
más detalle, los elementos se solapan.
Modelo en Piezas de Puzzle de los principales dominios de ITIL
Esta situación ilustra la necesidad de la consistencia tanto a través de la

guía como de la recomendación de cómo tratar con los problemas de gestión
que puedan surgir. La causa de estos problemas de gestión puede ser el
resultado de los límites marcados, que tal vez tengan más que ver con la
medida de control que con el agrupamiento lógico de los procesos
relacionados.
Razones del éxito de ITIL

Ya hemos comentado que ITIL se ha convertido en el estándar de facto a
nivel mundial para la gestión de Servicios IT, siendo utilizado como núcleo
para el propio desarrollo de las grandes compañías de gestión de servicios.
Las razones para este éxito se deben a las características de ITIL, que
comentamos en los siguientes puntos:
17
18
Dominio público
Desde sus comienzos ITIL has estado disponible a todos los públicos. Esto
significa que cualquier organización puede utilizar este marco descrito por
la CCTA en sus publicaciones.
Por este motivo ITIL has sido utilizado por una gran variedad de
organizaciones, tanto el gobierno central como autoridades locales, energía
como finanzas, comercio como fabricación. Desde organizaciones muy
grandes hasta organizaciones muy pequeñas, pasando por todos los tipos han
implementado ITIL.
Mejores prácticas
ITIL documenta las mejores prácticas de la industria. Esta guía ha probado
su valor desde sus inicios. Inicialmente, CCTA recopiló información sobre
cómo varias organizaciones llevaban la gestión de servicios, la analizó y
filtro aquellos puntos que podrían ser útiles para la CCTA y para sus clientes
en el gobierno central del Reino Unido. Otras organizaciones encontraron
que estas guías eran aplicables de manera general y la industria del servicio
creo muy rápido mercados fuera del gobierno.
Siendo un marco de trabajo, ITIL describe perfil de las organizaciones de

Gestión de Servicios. Los modelos muestran los objetivos, las actividades
generales, y las entradas y salidas de los varios procesos que pueden
incorporarse dentro de las organizaciones IT. ITIL no pretende escribir sobre
piedra cada una de las acciones que deben hacerse a diario, dado que
difieren mucho de una organización a otra. En su lugar se centra en las
mejores prácticas que pueden ser utilizas de distintos modos de acuerdo a la
necesidad.
Gracias a este marco de mejores prácticas comprobadas, ITIL puede ser

usado dentro de organizaciones con métodos y actividades de gestión de
servicio ya existentes. El uso de ITIL no implica una manera completamente
nueva de pensar y actuar, provee un marco de trabajo en el cual ubicar los
métodos y actividades existentes en un contexto estructurado. Resaltando la
importancia de las relaciones entre los procesos, cualquier deficiencia de
comunicación y cooperación entre varias funciones IT puede ser eliminada o
minimizada.
Estándar de facto
Para mediados de los años 90, ITIL era considerado como el estándar de
facto a nivel mundial para la gestión de servicios. Una de las mayores
ventajas generalmente reconocida a ITIL es el uso de un lenguaje común.
Los libros describen una gran número de términos que, usados
correctamente, pueden ayudar a la gente a comprenderse dentro de las
organizaciones IT.
19
Una parte importante de los proyectos de ITIL es conseguir que la gente

hable un idioma común. Eso por esto que la educación es un fundamento
básico de un programa de implementación o mejora. Sólo cuando la gente
involucrada habla un idioma común el proyecto puede concluir con éxito.
Enfoque a la Calidad
En el pasado, muchas organizaciones IT estaban internamente centradas y
concentradas en los asuntos técnicos. En estos días, los negocios tiene
grandes expectaciones hacia la calidad de los servicios y estas expectaciones
cambian con el tiempo. Esto significa que para que las organizaciones IT
sobrevivan a estas expectaciones necesitan concentrarse en la calidad de los
servicios y en un enfoque más orientado al cliente. Los asuntos de costes
están tanto en las agendas como el desarrollo de actitudes semejantes al
negocio para la provisión de servicio.
ITIL se centra en la provisión de servicios de alta calida con el enfoque

particular sobre las relaciones con los clientes. Las organizaciones IT
deberían ofrecer lo que sea acordado con los clientes, lo que implica una
relación fuerte entre las organización IT y los compañeros clientes.
Los procesos tácticos están centrados en las relaciones entre las

organizaciones IT y sus clientes. La entrega de Servicios está parcialmente
orientada al establecimiento de acuerdos y la monitorización de los
objetivos de estos acuerdos. Mientras tanto, a nivel operacional, los
procesos de soporte de servicio pueden ser vistos como la entrega del
servicio tal y como se ha acordado en estos acuerdos. En ambos niveles se
puede encontrar una fuerte relación con los sistemas de calidad como
ISO9000 y marcos de calidad total como el la EFQM5.
ITIL apoyará este sistemas de calidad mediante la provisión de un procesos

definidos y unas mejoras prácticas para la gestión de Servicios IT,
habilitando una via rápida para la certificación ISO.
Los beneficios de la gestión de la calidad para los servicios It podemos

resumirlos en:
 Provisión de servicios de calidad mejorada
 Calidad de servicios a coste razonable
 Servicios que cumplen las demandas del negocio, los clientes y los
usuarios.
 Procesos integrados y centralizados.
 Todo el mundo conoce su función y sus responsabilidades en la
provisión de servicios.
 Se aprende de experiencias previas.
 Indicadores de rendimiento demostrables.
5
European Foundation for Quality Management (Fundación Europea
para la Gestión de la Calidad)
19
20
Queda por su puesto que esto aplica a otros estándares, pero la mayoría de
los estándares europeos y muchos otros en el mundo se han consolidado en
el nuevo estándar ISO9000-2000.
itSMF
El itSMF6 se estableció en 1991 para apoyar e influir en la industria de la
gestión de servicios IT. Es el único forum independiente reconocido
internacionalmente para los profesionales de la gestión de Servicios IT, es
una organización sin ánimo de lucro, cuyo objetivo es la promoción y el
desarrollo de estándares y calificaciones dentro de las mejores prácticas de
la gestión de servicios IT.
Mucha más información sobre el funcionamiento de este forum, estructura,

misión y beneficios pueden ser encontrados en su página web
www.itsmf.com.
La continua reestructuración de ITIL

El concepto de gestión de servicios IT para la mejora de las funciones de
negocio no es nuevo, es anterior a ITIL. La idea de incluir todas las mejoras
prácticas de la gestión de servicios para un único punto de referencia en
cambio si fue radicalmente nueva. La primera serie de ITIL reunía la gestión
de servicios desde un único punto de vista, pero podía haberse desarrollado
mucho más en el aspecto de los intereses de negocio. La perspectiva de
negocio fue publicada para cubrir el salto entre negocio y gestión, aunque
con acierto, la serie fue publicada cuando la guía original de ITIL estaba
comenzando a quedarse desfasada en algunas áreas. El impacto en el
mercado de los nuevos servicios fue por lo tanto limitado, pero se convirtió
en un catalizador en la industria de la gestión de servicios.
ITIL fue originalmente producido a finales de los años 80 y consistía en un

núcleo de 10 libros, cubriendo las dos principales áreas de Entrega y Soporte
de Servicios. Este núcleo de libros fue completado posteriormente con 30
libros complementarios que iban desde el Cableado hasta la Gestión de la
Continuidad de Negocio.
En esta revisión, ITIL había sido reestructurado para hacerlo más sencillo el
acceso a la información necesaria para gestionar los servicios. El núcleo de
los libros se había condensado en dos libros, que cubrían las áreas de
Entrega y Soporte de Servicios, para eliminar la duplicación y facilitar el uso
de la guía.
6
IT Service Management Forum (http://www.itsmf.com)
21
Últimamente el material ha sido revisado y actualizado para centrase en los

asuntos de negocio relativos a la gestión de la infraestructura, asegurando
una sinergia más cercana con la nueva guías de IS publicadas por OGC.
¿A qué organizaciones va dirigido?

Como ya hemos comentado anteriormente, la guía es útil para
organizaciones de cualquier tamaño, tanto públicas como privadas, dado
que intencionadamente, se describen funciones y roles de trabajo, y no
grupos de trabajo o puestos.
En definitiva, los libros son relevantes para cualquier organización implicada

en los Servicios IT.
¿Quién debería leer ITIL?

ITIL está principalmente dirigido a las personas a cargo de la gestión de la
entrega de servicios IT de calidad.
Extendiendo esto, todo el personal involucrado en la entrega de servicios IT

encontrará los libros útiles, dado que les ayudarán a mejorar su
conocimiento del contexto de trabajo.
Los directores de IT deben ser sabedores de su existencia, así como de los

aspectos que cubre. De este modo aseguran que el personal adecuado en la
organización es conocedor en detalle de los mismos.
Beneficios de usar ITIL

Con la aproximación sistemática y profesional a la provisión gestión de los
Servicios IT ofrecida por ITIL se pueden conseguir beneficios como:
 Incrementar la satisfacción de los usuarios con los servicios IT

 Reducir el riesgo de no encontrar los requisitos de negocio para los
servicios IT
 Reducir costes en el desarrollo de procedimientos y prácticas dentro
de una organización
 Mejor comunicación y flujo de información entre el personal de IT y
los clientes.
 Guía y estándares para el personal IT
 Mayor productividad y mejor uso de los niveles de experiencia
 Una aproximación de calidad a los servicios IT
21
22
También hay beneficios para los clientes de los servicios IT, como:
 Reafirmación que los servicios IT son dados de acuerdo a los
procedimientos documentados que pueden ser auditados
 La aptitud de depender de los servicios IT, haciendo posible a los
clientes encontrar los objetivos de negocio.
 Identificación de los puntos de contacto para preguntas o discusiones
sobre requerimientos de cambio
 Conocimiento que se produce información para la justificación de los
cargos de los servicios IT y el control de los acuerdos de niveles de
servicio.
Muchas organizaciones IT intentan orientarse hacia sus clientes, para

demostrar su compromiso con el negocio. ITIL destaca la importancia de
proveer los servicios IT para satisfacer las necesidades de negocio de una
manera efectiva en la relación a los costes, ayudando a las organizaciones a
conseguir la reducción de los costes.
Las organizaciones son instadas a adaptar la guía para ajustarla a sus

necesidades, del mismo modo, se le aconseja contra la omisión de
actividades sin someterlo a consideración, dado que ITSM es un conjunto de
procesos y funciones integrados y coordinados, y a largo plazo, el beneficio
de la implementación de todos es mayor que hacerlo de manera discreta.
La adopción de ITIL en una organización admite una aproximación a la

gestión de servicios, que se hace bajo un lenguaje común de términos que
permite una mejor comunicación entre IT y los proveedores.
Clientes y Usuarios
Para evitar confusión con respecto a los roles y terminología los términos
“cliente” y “usuario” se utilizan a los largo de esta documento para
diferenciar entre aquellas personas (generalmente directores de mayor
rango) que pagan por y son dueños de los Servicios de IT (los clientes) y
aquellas personas que utilizan los servicios a diario (los usuarios). La
semántica es menos importante que la razón para la diferenciación. El
punto de contacto primario para los clientes es el director de Atención al
Cliente, mientras que el punto de contacto primario para los usuarios es el
Service Desk. Un proceso de Gestión de Incidencias que funciona mal
afectará a la población de usuarios inmediatamente, Un servicio que no vale
lo que cuesta tendrá un impacto mayor en el cliente.
Por lo tanto, es importante que distingamos las distintas pero relacionadas

necesidades de Usuario y Clientes en la provisión de servicios. Ciertamente,
sus propósitos puede que estén enfrentados y necesiten ser equilibrados;
23
por ejemplo, los usuarios pueden exigir mayor disponibilidad mientras que
el cliente puede buscar mayor provecho a su dinero en distintos niveles de
disponibilidad. Hay procesos de información que se deben mantener y
elementos clave de proceso que ambas partes deben definir.
23
24
4.Relación entre procesos

Ahora que conocemos ITIL un poco más podemos ver que todos los procesos
descritos en ITIL se relacionan unos con otros. Estos principales procesos son
los que se describen detalladamente en aquí. Para conocer como se
interrelacionan estos procesos consideremos el siguiente ejemplo del ciclo
de vida de un Incidente:
1. Un usuario llama al Service Desk para informar sobre dificultades en

la respuesta con un servicio on-line.
2. El proceso de gestión de incidencias trata con el incidente.
3. El proceso de gestión de problemas investiga la causa subyacente e
invoca a la gestión de la capacidad para ayudar en este proceso. La
gestión de nivel de servicio es alertada que el SLA se ha roto.
4. El proceso de gestión de cambios pone en marcha y coordina una
petición de cambio (RFC)
5. El proceso de gestión financiera de IT ayuda con una justificación de
costes para la actualización de hardware mediante un “caso de
negocio”.
6. El proceso de gestión de la continuidad actúa junto con el proceso de
gestión de cambios para asegurar si la recuperación de la
configuración de back-up actual es posible.
7. El proceso de gestión de la difusión controla la implementación del
cambio mediante la presentación del hardware y software de
reemplaza. La gestión de la difusión actualiza a la gestión de la
configuración con los detalles de las nuevas versiones.
8. El proceso de gestión de la disponibilidad está involucrado en
considerar si la actualización de hardware asegura que pueden ser
cumplidos los niveles requeridos de disponibilidad y fiabilidad.
9. El proceso de gestión de la configuración asegura que la información
de la CMDB es actualizada a lo largo del proceso.
10.El proceso de gestión de la relación con el cliente se relaciona con
este a lo largo del proceso para mantenerle actualizado del progreso.
25
A continuación veremos en detalle como se relación todos esto procesos que

participan en la gestión de servicios.
Gestión de la configuración
La gestión de la configuración es una parte integral de todos los otros
procesos de la gestión de servicios. Con la información actualizada,
adecuada y comprensiva de todos los componentes de la infraestructura, la
gestión del cambio, en particular, es más efectiva y eficaz. La gestión del
cambio puede ser integrada con la gestión de la configuración. Como
mínimo es recomendable que el registro e implementación de los cambios
esté hecho bajo el control de un sistema de gestión de la configuración
comprensivo y que la valoración del impacto de los cambios esté hecha con
la ayuda del sistema de gestión de configuración. Todas las peticiones de
cambio deberían ser incluidas en la base de datos de la gestión de la
configuración, CMDB7, y los registros actualizados a medida que las
peticiones de cambio progresan a través de la implementación.
El sistema de gestión de la configuración identifica las relaciones entre los

objetos que van a ser cambiados y cualquier otro componente de la
infraestructura, permitiendo de esta manera a los propietarios de estos
componentes estar involucrados el proceso de valoración del impacto.
Cuando quiera que se realice un cambio en la infraestructura, los registros
asociados de la gestión de la configuración deberán ser actualizados en la
CMDB. Donde sea posible, la mejor opción es acompañarlo con el uso de
herramientas integradas que actualicen los registros automáticamente a
medida que los cambios son realizados.
La CMDB debería estar disponible para todo el grupo de soporte de servicios,

para que los Incidentes y los Problemas puedan ser resueltos más fácilmente
mediante el entendimiento de las posibles causas de fallo de los
componentes. La CMDB debería también ser usada para unir los registros de
incidentes y problemas a otros registros adecuados como el Objeto de
configuración (CI8) que está fallando y el usuario. La gestión de la difusión
será difícil y propensa a errores sin la integración del proceso de gestión de
configuración.
Los procesos de entrega de servicio también se apoyan en los datos de la

CMDB. Por ejemplo:
 La gestión de los niveles de servicio necesita identificar los
componentes que combinan juntos para la entrega del servicio para
7
CMDB: Configuration Management Database
8
CI: Configuration Item
25
26
que los acuerdos contratados puedan ser establecidos

oportunamente.
 La gestión financiera de IT necesita conocer los componentes
utilizados por cada unidad de negocio, especialmente cuando se
cobra por los servicios.
 La gestión de la continuidad y de la disponibilidad necesitan
identificar los componentes para realizar el análisis de riesgos y de
impacto de los componentes anómalos.
Gestión del Cambio

El proceso de gestión del cambio depende la precisión de los datos de
configuración para asegurar que todo el impacto es realizar los cambios es
conocido. Hay además una estrecha relación entre la Gestión de la
Configuración, la Gestión de la Difusión y la Gestión de Cambios.
Los detalles del proceso de Cambio son documentados en los SLA para
asegurar que el usuario conoce el procedimiento para solicitar cambios y los
tiempos de finalización proyectados y el impacto de la implementación de
los cambios.
Los detalles de los cambios deben ser mostrados al Service Desk. Incluso con
pruebas comprensivas, hay una probabilidad en aumento de ocurran
dificultades después de la implementación del cambio, bien porque el
cambio no está funcionando como era esperado o requerido, o por las
preguntas sobre el cambio en funcionamiento.
El consejo asesor del cambio (CAB 9) es un grupo de personas que pueden el

consejo experto al equipo de gestión del cambio sobre la implementación de
los cambios. Este consejo estará compuesto probablemente por
representantes de todas las áreas dentro de IT y presentantes de las
unidades de negocio.
Gestión de la difusión
Los cambios a menudo resultan en la necesidad de nuevo hardware, nuevas
versiones de software, y por supuesto de nueva documentación, creado
dentro o traído de fuera, para ser controlado y distribuido, como parte de
un nueva “versión empaquetada”. Los procesos para conseguir puesta en
marcha segura y gestionada deberían estar estrechamente integrados con
los de gestión de la Configuración y del Cambio. Los procedimiento de
gestión de la difusión debería ser también parte de integrante la gestión de
incidencias y de la gestión de problemas, y estar también muy unidos a la
CMDB para mantener los registros actualizados.
9
CAB: Change Advisory Board
27
Gestión de incidencias
Debería existir un interfaz cercano entre el proceso de gestión de
incidencias y los procesos de gestión de problemas y de cambios, así como
con la función del Service Desk. Si no son controlados adecuadamente, los
cambios pueden dar lugar a nuevos incidentes. Es recomendable que
registros de los incidentes se almacenen en la misma CMDB que los registros
de problemas, errores conocidos y cambios, o al menos unidos sin la
necesidad de volver a escribirlos, para mejorar las interfaces y la
información e interrogación sencilla.
Las prioridades de los incidentes y los procedimientos de escalación deben

ser acordados como parte del proceso de gestión de los niveles de servicio y
documentados en los SLA.
Gestión de problemas
El proceso de gestión de problemas requiere un registro adecuado y
comprensivo de los incidentes para poder identificar efectiva y
eficientemente la causa de los incidentes y las tendencias. La gestión
problemas necesita relacionarse estrechamente con el proceso de gestión de
la disponibilidad para identificar estas tendencias y buscar acciones
correctivas.
Service Desk
El Service Desk es el único punto de contacto entre los proveedores de
servicio y los usuarios, al nivel del día a día. Es también el punto donde
comunicar los incidentes y hacer las solicitudes de servicios. Como tal, el
Service Desk tiene la obligación de mantener a los usuarios informados de
los eventos, acciones y ocasiones de los servicios que van a impactar
probablemente su capacidad para realizar las tareas cotidianas. Por ejemplo
el Service Desk debería actuar como punto central para las peticiones de
cambio de los usuarios, publicando las programaciones de los cambios en
nombre de la gestión de cambios, y manteniendo a los usuarios informados
del progreso de los cambios. Además la gestión del cambio debería asegurar
que el Service Desk es constantemente conocedor de las actividades de
cambio.
El Service Desk esta en la línea directa de fuego de cualquier impacto sobre

el SLA y como tal necesita flujos de información rápidos.
El Service Desk debería ser delegado en la implementación de cambios para

solucionar indicentes dentro de su zona de autoridad. El objetivo de tales
cambios está predefinido y la función de gestión de cambios ser informada
27
28
de ellos. La aprobación anterior de la gestión de cambios es esencial antes

de que cambios de especificación de cualquier CI sean implementados.
Gestión de Niveles de Servicio

El proceso de Gestión de Niveles de Servicio es responsable de asegurar que
los Acuerdos de Niveles de Servicio (SLA 10), los Acuerdos de Niveles
Operacionales contratados o los contratos son cumplidos, y de asegurar que
los impactos adversos a la calidad del servicio se mantienen al mínimo. El
proceso cubre la valoración del impacto de los cambios sobre la calidad del
servicio y los SLA, una vez que los cambios son propuesto y después de que
hayan sido implementados. Algunos de los objetivos más importantes
establecidos en los SLA se relacionarán a la disponibilidad del servicio y de
esta manera requiere la resolución de los incidentes dentro de los periodos
acordados.
La gestión de los niveles de servicio es la bisagra del soporte de los servicios

y la entrega de los mismos. No puede funcionar aisladamente dado que se
basa en la existencia y funcionamiento efectivo y eficiente de otros
procesos. Un SLA sin procesos de soporte que lo apoyen es inútil, dado que
no hay fundamento para el acuerdo de su contenido.
Gestión de la capacidad
La gestión de la capacidad está directamente relacionada con los
requerimientos de negocio y no lo están simplemente con el rendimiento los
componentes de los sistemas, individual o colectivamente. La gestión de la
capacidad está involucrada en la resolución de incidentes y la identificación
de los problemas de aquellas dificultades relativas a los asuntos de
capacidad.
Las actividades de la gestión de la capacidad crean Solicitudes de Cambio

(RFC11) para asegurar que la capacidad adecuada está disponible. Estas RFC
esta sujetas al proceso de gestión del cambio, y su implementación puede
afectar a varios CI, incluyendo hardware, software y documentación,
requiriendo una Gestión de la difusión efectiva.
La gestión de la capacidad debería estar involucrada en la evaluación de

todos los cambios, para establecer el efecto sobre la capacidad y el
rendimiento. Esto debería ocurrir cuando los cambios son propuestos y
después de estar implementados.
10
SLA: Service Level Agreement
11
RFC: Request for Change
29
La gestión de la capacidad debería prestar una atención especial al efecto

acumulativo de los cambios en un periodo de tiempo. Los efectos
insignificantes de cambios individuales pueden a menudo combinar para
causar un tiempo de respuesta degradado, problemas de almacenamiento de
ficheros, y un exceso de demanda de la capacidad de proceso.
Gestión Financiera para los servicios IT

La gestión Financiera es responsable de la contabilización de los costes de
provisión de los servicios IT y de cualquier aspecto para recuperar estos
costes de los Clientes (cobrar). Requiere buenos interfaces con la gestión de
la capacidad y de la configuración (datos de activos) y con la gestión de los
niveles de servicio, para identificar el coste real del servicio. El directivo
financiero probablemente trabajara estrechamente con la dirección IT
durante la negociación de los presupuestos del departamento IT y los gastos
IT de los clientes individuales.
Gestión de la disponibilidad
La gestión de la disponibilidad está involucrada con el diseño,
implementación, medida y gestión de los servicios IT para asegurar que los
requerimientos de negocio indicados para la disponibilidad están
constantemente cumplidos. La gestión de la disponibilidad requiere un
conocimiento del motivo por el que los servicios IT fallan y el tiempo
necesario para continuar el servicio. La gestión de los incidentes y la gestión
de los problemas dan una información clave para asegurar que las acciones
correctivas oportunas son desarrolladas.
La medida y la información de la disponibilidad IT asegura que el nivel de

disponibilidad entregada cumple el SLA. La gestión de la disponibilidad da
apoyo al proceso de gestión de los niveles de servicio dando medidas e
información para las revisiones del servicio de soporte.
Gestión de la continuidad de los servicios IT

La gestión de la continuidad de los servicios IT está involucrada con la
gestión de la habilidad de una organización para continuar la provisión un
predeterminado y acordado nivel de los servicios IT para dar soporte a un
mínimo los requisitos de negocio después de una interrupción al negocio. La
continuidad efectiva de los servicios IT requiere un balance de las medidas
de reducción del riesgo tales como sistemas flexible y opciones de
recuperación incluyendo facilidades de back-up. Los datos de gestión de la
continuidad son requeridos para facilitar esta prevención y planificación.
Los cambios de negocio y de infraestructura necesitan ser evaluadas para su
impacto potencial en los plantes de continuidad, y los planes de negocio y
de IT deberían ser sujetos a los procedimientos de gestión del cambio. El
29
30
Service Desk tiene un papel importante en caso de que la continuidad del

negocio sea invocada.
Gestión de la infraestructura IT
La función de la infraestructura IT está involucrada con la mayoría de los
procesos de soporte de servicio y entrega de servicio en donde los asuntos
más técnicos están incluidos.
Gestión Aplicaciones
La gestión de aplicaciones expone los procesos principales requeridos para
gestionar las aplicaciones a través de su ciclo de vida. La gestión de
servicios está típicamente involucrada con un producto (hardware/software)
en un particular punto en el tiempo para dar apoyo a los requerimientos de
servicio del negocio.
Gestión de la Seguridad
La función de gestión de seguridad se relaciona con los procesos de gestión
de Servicios IT en los que hay asuntos de seguridad. Tales asuntos son sobre
Confidencialidad, Integridad y disponibilidad de los datos, así como la
seguridad de los componentes de hardware y software, documentación y
procedimientos. Por ejemplo, la gestión de la seguridad se relaciona con la
gestión de servicios para valorar el impacto sobre la seguridad de los
cambios propuestos, para plantear RFC en respuesta a los problemas de
seguridad, para asegurar la confidencialidad e integridad de la seguridad de
los datos y para mantener la seguridad cuando el sobre es puesto en marcha
en el entorno real.
31
31
32
33
33
34
Consideraciones para implementar una estructura de Service Desk Local

incluyen:
 Establecer procesos comunes para todas las localidades y, a ser
posible, procedimientos comunes
 Hacer que se conozcan y sean disponibles a otros Service Desks,
habilidades localizadas
 Asegurar compatibilidad de hardware, software e infraestructura de
red
 Usar los mismos procesos de escalada, y los mismos códigos de
impacto, severidad, prioridad y estatus en todas las localidades
 Usar medidas de informes de gestión común
 Usar una base de datos compartida (lógica) comúnmente
 De estar disponible, establecer la posibilidad de pasar o escalar
solicitudes entre Service Desks, preferiblemente de forma
automática.
Service Desk Centralizado
El Service Desk Local es práctico pero por sus múltiples localizaciones puede
duplicar habilidades y recursos y eso es costoso. Por lo tanto, es bueno
establecer un Service Desk central si el tipo de soporte lo permite y si es
técnicamente posible. En esta opción, todas las solicitudes de servicio están
registradas en una localización física central. Si su organización tiene
localizaciones múltiples, tener un servicio de soporte central tiene ventajas
mayores para su negocio, incluidos:
 Costes operacionales reducidos
 Visión global de gestión consolidada
 Uso mejorado de recursos disponibles
Claro que otras partes de los servicios siguen teniendo que ser soportados en
cada localización. Por ello, se ven muchas organizaciones con Desks
Centrales y Locales combinados.
Service Desk Virtual
Hasta un punto, la situación física del Service Desk y los servicios asociados
son inmateriales, debido a los avances en la realización de red y
telecomunicaciones. El” Service Desk Virtual” puede situarse y ser accedido
desde cualquier lugar del mundo. Si su organización tiene múltiples
localizaciones, un Service Desk de soporte global tiene ventajas mayores
para el negocio, incluidas:
 Costes operacionales reducidos

 El rango para la visión global de gestión consolidada
 Uso mejorado de recursos disponibles.
35
Sin embargo, la restricción operacional primordial del Desk Virtual es la

necesidad de la presencia física de un especialista o un ingeniero de
reemplazo.
Consideraciones para montar un Service Desk Virtual incluyen los siguientes

puntos:
 Todas las personas accediendo al Service Desk Virtual deberían usar
procesos, procedimientos y terminología comunes.
 Un lenguaje común, acordado debería ser utilizado para la
introducción de datos
 Clientes y Usuarios todavía necesitan interactuar con un solo punto
de contacto. Considere números de teléfonos globales, números
locales que dirigen al Desk Virtual y tecnología de Distribución de
Llamada Automática ( DLA / ACD)
 Habrá necesidad de la presencia física in situ de un especialista o
ingeniero de mantenimiento de vez en cuando.
 La realización de red debería “cumplir un propósito”. Esto debe ser
revisado en términos de previsión de carga de trabajo. Por ejemplo,
si el Service Desk de Holanda sólo se encarga de diez solicitudes al
día, entonces el volumen de red puede que no sea una consideración
mayor. Sin embargo, un ancho de banda estrecho no es práctico si se
procesan varios centenares de solicitudes al día.
 Para el Desk Virtual, las herramientas de soporte establecidas
deberían permitir la “partición de trabajo” y visiones autorizadas.
(Por ejemplo, si yo soy la persona encargada de soporte local,
digamos en Ámsterdam, sólo quiero ver las solicitudes de esa
localidad). Esto debería incluir otros procesos asociados y datos
relacionados, tales como Cambios programados, datos de
Configuración y bienes.
 Propiedad consistente y procesos de gestión para Incidencias deberían
ser utilizados en el Service Desk Virtual, con transferencias
automatizadas de Incidencias y visiones de Incidencias entre desks
locales.
Consideraciones
Establecer un Service Desk no es fácil. Por lo tanto, aquí hay algunos

consejos.
 Primero, establecer que la necesidad del negocio está claramente
identificada y entendida. Sin esto, es muy difícil implementar un
desk. Necesitamos saber qué tenemos que soportar, ¿no?•
 Asegurarnos que el compromiso, presupuesto y recursos de la
dirección están disponibles. Todo tipo de procesos y procedimientos
deben ser implementados, las herramientas deben ser despachadas y
las responsabilidades cambian. Sin el compromiso de la dirección,
esto no se va a realizar.
35
36
 Asegurar que la solución propuesta está en línea con la estrategia de

soporte de servicio.
 Identificar, alcanzar y comunicar victorias rápidas. Las buenas
relaciones públicas y resultados rápidos le ayudarán a promocionar el
desk.
 Definir objetivos claros y que se puedan entregar
 Empezar de modo sencillo; No intente hacer todo de golpe; Adopte
un enfoque en fases
 Involucrar /consultar a sus clientes y usuarios finales. No use argot
pero hábleles en su lenguaje. Hable con ellos de sus expectativas y
explíqueles sus objetivos y tareas
 Venda las ventajas al personal de soporte. Dígales que “un solo punto
de contacto” también les beneficia. Tendrán más tiempo para hacer
el trabajo “de verdad”.
 Forme al personal de IT para ser personal de servicio. La
comunicación es uno de los factores de éxito más críticos. El Service
Desk no debe estar centrado de modo técnico sino orientado al
servicio.
 Eduque a los clientes y usuarios en el uso del nuevo servicio y sus
beneficios.
 Anuncie y “venda” su servicio.
Al montar un Service Desk, tenga en cuenta las siguientes guías:
 A ser posible, tenga un cuarto /local apartado de la zona de soporte

principal con:
 Un área agradable y confortable para Clientes y Personal del Service
Desk
 Un entorno de bajo nivel de ruido
 Privacidad
 Instalar una biblioteca de todos sus productos, documentación de
hardware y software y material de referencia que utilizan los clientes
 Asegurar un Catálogo de Servicio actualizado disponible a todas horas
 Instalar facilidades telefónicas de conferencia y unidades manos
libres
 Proveer espacio de mesas y asientos para discusiones de mesa
redonda- esto ayuda a desarmar la situación de ‘ellos y nosotros”
 Proveer facilidades de refrescos para ofrecer a Clientes, o al menos
acceso fácil a ellos
 Publicar a la base de Clientes la localización de la unidad y sus
horarios operacionales
Al considerar el nivel de servicio y el entorno proporcionados,

pregúntese “¿Es así cómo me gustaría que me trataran?”
37
37
38
39
39
40
Comunicación a los Clientes

La comunicación durante el ciclo vital total de una incidencia es el
rendimiento más importante de este proceso mediante el Service Desk a los
clientes/usuarios finales
Información de Gestión (Informes)

Información de Gestión sobre los resultados y rendimiento del proceso.
El Ciclo de vida de la Incidencia

Aceptar el evento de servicio, Registrar y consultar la CMDB
La interacción del cliente ya no se restringe al contacto telefónico y
personal. El servicio se puede realzar mucho y se puede extender al Cliente,
los Usuarios y Personal de soporte al expandir los métodos para registrar,
actualizar y consultar solicitudes.
El registro de datos de acuerdo a la interrupción o reducción del servicio es
muy importante para:
 Localizar la incidencia a lo largo de la totalidad de su ciclo de vida
 Añadir información útil que puedan ayudar, informar y asistir
organizaciones de soporte para que puedan encontrar una solución o
un workaround (antes)
 Recoger información histórica para futuro uso
 Coleccionar información (p.ej. Para informes) sobre un número de
incidencias, eficiencia, disponibilidad y análisis de tendencias y otros
procesos de gestión
Consultar la CMDB es necesario para obtener información sobre el

servicio que se interrumpe, los datos de los Acuerdos de Nivel de
Servicio, los CI’s relacionados a este servicio y esperamos relacionados
con incidencias pasadas, errores conocidos y cambiar expedientes.
Clasificación
El Service Desk determina la prioridad de las incidencias a medida que las
recibe.
Consultando con el Cliente, el Service Desk calculará la prioridad a partir
del impacto y la urgencia de la incidencia.
Solucionar
41
Otros grupos de soporte empezarán a analizar la incidencia con el sólo

propósito de encontrar una solución permanente, o —de no ser esto posible-
encontrar un workaround
Cierre
Si se indica una solución permanente o un workaround esto lo
implementaremos y restauraremos el servicio. El grupo de solución
informará al Personal del Service Desk. El Personal del Service Desk
investigará con el cliente si la solución/workaround ofrecidos han
restaurado el servicio como se requiere. Si es el caso, entonces el Personal
puede cerrar la incidencia.
Clasificación: Prioridad y Categoría

El Service Desk determina la prioridad de las incidencias a medida que las
recibe.
Consultando con el Cliente, el Service Desk calculará la prioridad a partir
del impacto y urgencia de la incidencia, considerada frente al criterio
descrito en el Acuerdo de Nivel de Servicio y lo el Estatuto de Servicio...
El criterio típico debería incluir:

 Coste potencial de la no-resolución
 Amenaza de lesión a clientes o empleados
 Implicaciones legales
 Trastorno a clientes y empleados
El impacto no trata de la complejidad de la solución

Al priorizar las llamadas en este punto, el soporte de segunda línea puede
determinar fácilmente qué llamadas necesitan atención más urgente y en
qué orden. Prioridad no trata simplemente de poner las incidencias en cola
para su resolución; también trata sobre los recursos (tiempo, Personal,
destreza, investigación y soporte de terceros) que se asignarán a la
resolución. En términos prácticos, a veces una incidencia de baja prioridad
puede que se permita no alcanzar su tiempo objetivo de resolución, para
que una incidencia de más alta prioridad pueda tratarse dentro de su
objetivo.
La categorización se hace para agrupar incidencias en una categoría
específica. La ventaja más grande es que esto podría ayudar a indicar la
ruta de solución que se podría tomar, el grupo de solución que se debería
elegir (para referir a la incidencia también) y la posible solución.
41
42
Clasificación: Emparejamiento
Después de la categorización la incidencia se debe contrastar con la base de
datos de incidencias, problemas y errores conocidos para investigar si se
informaron de incidencias con los mismos síntomas antes y averiguar si
existen problemas y/o errores conocidos. Si existen, lo más probable es que
haya un workaround que podamos utilizar para restaurar el servicio.
Emparejar los síntomas con una base de datos de conocimientos existente
también es algo que se puede hacer aquí.
Si la incidencia no se puede emparejar entonces es una incidencia única. La
solución lo más probable es que no pueda encontrarse en el Service Desk y
por lo tanto, tenemos que referirlo al siguiente nivel de soporte.
Dirigir incidencias
A menudo, nos referimos a los departamentos y grupos de soporte
(especialistas) además Service Desk como grupos de soporte de segunda o
tercera línea, teniendo más habilidades especialistas, tiempo u otros
recursos para resolver incidencias. A este respecto, el Service Desk sería
soporte de primera línea. Para la dirección tenemos — podríamos decir- un
procedimiento tradicional:
Paso 1. Intento de resolución de la Incidencia por parte del Service
Desk: Llevar a cabo la evaluación inicial y buscar una solución o
workaround. Si se encuentra una solución, cerrar la incidencia. Si no,
referirlo al siguiente nivel.
Paso 2. Asignar la Llamada de Servicio al soporte de 2 línea: Si no se
puede encontrar ninguna solución en el Service Desk, referirlo al
soporte de segunda línea. Si el soporte de 2 línea puede encontrar
una solución, referir de nuevo al Service Desk que cerrará la
incidencia. Si no, referirlo al siguiente nivel.
Paso 3. Asignar la Llamada de Servicio al soporte de 3 línea: Si no se
puede encontrar ninguna solución en el soporte de segunda línea,
referirlo ¿1 soporte de tercera línea. Si el soporte de 3 línea puede
encontrar una solución, referir de nuevo al Service Desk que cerrará
la incidencia. Si no, referirlo al siguiente nivel.
Paso 4. Asignar la Llamada de Servicio al Especialista: Si no se puede
encontrar ninguna solución en el soporte de tercera línea, referir a un
especialista. Si el especialista puede encontrar una solución, referir
de vueltá al Service Desk que cerrará la incidencia.
ETC.
Si no está claro qué grupo de soporte debería investigar o resolver una

incidencia relacionada con un usuario, el Service Desk, como dueño de todas
las Incidencias, debería coordinar el proceso de Gestión de Incidencias. Si
43
hay diferencias de opinión o surgen otros asuntos, entonces el Service Desk

debería escalar la Incidencia al equipo de Gestión de Problemas.
Noten que soporte de tercera o x-línea puede incluir finalmente
proveedores externos que pueden tener acceso directo a la herramienta de
registro de la Incidencia (dependiendo en las normas de seguridad y asuntos
técnicos).
Escalada y Referencia
Dirigir se llama escalada horizontal o referencia. Referimos la incidencia
porque necesitamos más conocimiento.
Si necesitamos más soporte, más dinero y más poder (decisiones) para
resolver una incidencia y que más personas trabajen en esta incidencia, es
necesaria la escalada vertical. Pero también, informar a dirección de qué
ocurre y mantenerles al día, o pedir su soporte porque el progreso del
proceso falta, se llama escalada horizontal.
Debería haber un procedimiento para ambas escaladas. Y es muy importante
que el Personal del Service Desk monitorice el progreso de la escalada.
Escalada o Referencia NUNCA convierte una incidencia en un problema,
aunque pueda resultar en que la propiedad de una incidencia pase al
Director de Problemas por razones administrativas y con ello la
identificación de un problema asociado. Problemas no son sólo incidencias
muy serias.
Informes de Gestión
Informar es MUY importante. La Mejora de Calidad está basada
fundamentalmente en INFORMACION. Sin registro de alta calidad e informes
flexibles no tenemos la información que necesitamos y entonces mejora de
calidad no es posible, o al menos no al nivel que podríamos alcanzar.
La información, claro está también es importante:
 Para los Directores de Nivel de Servicio / Directores de Cuentas es
importante tener la información para sus clientes, para que puedan
en primer lugar dar toda la información acerca de nuestro
rendimiento en relación con el rendimiento acordado en los Acuerdos
de Niveles de Servicio. Pero esta información también nos da input
para la negociación de los niveles de servicio en futuros Acuerdos de
Nivel de Servicio. Por último pero no de menor importancia, podemos
comprobar cómo lo hicimos y a veces es importante por el hecho de
que la perspectiva del usuario no siempre es lo que hicimos en
realidad.
 Para la Dirección (incidencias) es importante saber cómo rinde el
proceso del Service Desk /gestión de Incidencias. ¿Cómo de efectivos
son los empleados al manejar las llamadas? ¿Referimos las llamadas al
43
44
grupo de soporte correcto? ¿Cuántas incidencias se resolvieron dentro

del Service Desk / soporte de 1 línea? ¿Conseguimos alcanzar los
términos de los Acuerdos de Nivel de Servicio? ¿Cómo rendimos al
referir el tema? ¿Cómo fue nuestro progreso en general pero también
con relación a los códigos de severidad?
 Para otras partes de la organización y los directores de procesos es,
por ejemplo, importante saber cómo de fiables son los CIs. ¿Cuál fue
el tiempo de Downtime de los CI’s? ¿Qué tipo de incidencias hemos
tenido? Si las incidencias tenían que ver con cambios malos. Si las
incidencias se relacionan con asuntos de capacidad. ¡O asuntos de
seguridad!
 Para la motivación de los empleados del Service Desk. Podría usar
todas las cifras de informe mencionado anteriormente para mostrar a
los empleados si mejoran y cuánto. ¡Esta es una herramienta muy
poderosa!
Informes sugeridos son:
Revisiones diarias de Incidencias individuales y estatus de Problemas con

referencia a niveles de Servicio
P.ej. áreas que requieren escalada en grupo, posibles faltas de seguridad;
todas las Incidencias pendientes.
Revisiones de gestión semanales
P.ej. disponibilidad de servicio; áreas mayores de Incidencias; Incidencias
relacionadas que requieren que se generen expedientes de Problema;
Errores conocidos y Cambios requeridos; faltas de servicio; satisfacción de
Cliente; tendencias, servicios mayores que afectan el negocio: carga de
trabajo de los empleados.
Revisiones de gestión mensuales
P.ej. disponibilidad de servicio; rendimiento general, análisis de objetivos
alcanzados y tendencias; alcance de objetivos de servicio individuales;
percepciones y niveles de satisfacción del Cliente; necesidades de educación
y formación del Cliente; Personal de soporte y rendimiento de terceros;
rendimiento de aplicación y tecnología; contenido de la matriz de revisión e
informes; coste de provisión /falta de servicio.
Informes de servicio pro-activos Consideren los siguientes informes para
ayudar a esto:
 Cambios programados para la siguiente semana
 Incidencias /Problemas /Cambios mayores de la semana anterior
 Incidencias de Clientes “No satisfechos” de semanas anteriores
 Artículos de semanas anteriores de infraestructura de bajo
rendimiento (p.ej. servidor, red, aplicación)
45
45
46
47
47
48
Un error se identifica cuando se detecta un CI roto. Un estatus de Error

Conocido se asigna cuando se encuentra la causa raíz de un Problema
Evaluación de Error
Este paso realiza una evaluación inicial de los medios de resolver el error,
en colaboración con personal especialista. El proceso de resolución para
cada Error Conocido debe ser grabado en el sistema de Gestión de
Problemas. Es vital que los datos de los CI’s, síntomas y acciones de
resolución o workaround relacionados con todos los Errores Conocidos se
registren en la base de datos de Errores Conocidos porque entonces está
disponible para emparejamiento de Incidencias, proporcionando una guía
para futuras investigaciones y para proporcionar información de gestión.
Registro de Error / resolución (envío de RFC)

El paso registra una resolución de un error y completa una RFC de acuerdo
con los procedimientos de Gestión de Cambio. La prioridad de la RFC se
determina por la urgencia e impacto del error en el negocio. El identificador
de la RFC debería incluirse en el registro del Error Conocido y viceversa a fin
de mantener un rastro de auditoria completo, o se debe ligar los dos
registros. Las etapas finales de la resolución de error- análisis de impacto,
evaluación detallada de la acción de resolución a llevar a cabo,
modificación del artículo en error, y la prueba del Cambio- están bajo el
control de Gestión de Cambio.
Cierre de Error
Tras implementar con éxito los Cambios (determinado por la Revisión Post
Implemento) para resolver errores, el Error Conocido relevante se cierra,
junto a los expedientes de Incidencias o Problemas relacionados.
Gestión de Problemas Proactiva (Prevención Proactiva)

La Gestión de Problemas Proactiva cubre las actividades dirigidas a
identificar y resolver Problemas antes de que ocurran Incidencias. Estas
actividades son:
 Análisis de tendencias
 Marcar objetivos de acción de soporte
 Proporcionar información a la organización.
Al redirigir los esfuerzos de una organización por reaccionar a un gran

número de Incidencias a prevenir Incidencias, una organización proporciona
un mejor servicio a sus Clientes y hace un uso más efectivo de los recursos
dentro de la organización de IT.
49
Incidencias versus Problemas

Incidencias y Problemas (y Cambios) son entidades separadas. NO es cierto si
hay un problema que la incidencia que inició el problema ha desaparecido.
Las incidencias, problemas e incluso cambios estarán vivas
simultáneamente.
Comienzo: Sólo una incidencia.
Cuando ocurre una incidencia, el proceso de gestión de incidencia intentará
resolver la incidencia cuanto antes. La incidencia sólo se puede cerrar una
vez resuelta la incidencia. Durante la fase de investigación de la incidencia,
no se encuentra ninguna solución. El proceso de gestión de incidencias
entonces busca la ayuda de gestión de problemas porque la causa raíz de las
incidencias se tiene que determinar en primer lugar.
Investigado y Escalada: Incidencia y Problema existen simultáneamente.
La gestión de problemas define un problema con alta urgencia e
inmediatamente asigna recursos. Esos recursos diagnostican el problema y
encuentran la causa raíz de la incidencia subyacente.
Diagnóstico: Incidencia, Problema y Error Conocido existen
simultáneamente.
Definen un error conocido y tras averiguar cómo resolverlo emiten una RFC a
gestión de cambio para resolver la situación.
Cambio en trámite: Incidencia, Problema, Error Conocido y Cambio
existen simultáneamente
El cambio se implementa con éxito. La Revisión Post implementación
muestra que el cambio de hecho ha eliminado el error conocido con éxito.
La investigación muestra también que la incidencia se ha resuelto y el
problema, por lo tanto, abierto por esta razón ahora se puede cerrar
también.
Final: Incidencia resuelta, cambio, problema y error conocido cerrados
Si en algún momento durante la fase de diagnóstico el equipo de problemas
encuentra un workaround, la incidencia se resolverá antes. Esto no significa
que el problema ya no exista. El único cambio en el expediente 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 en el
tiempo para perseguir el diagnóstico del problema o si esos recursos fuesen
mejor utilizados en otro lugar.
Procesando Errores Conocidos desde el Entorno de

Desarrollo
La segunda fuente de Errores Conocidos surge de la actividad del desarrollo.
Por ejemplo, la implementación de una nueva aplicación o Difusión
49
50
empaquetada es probable que incluya errores conocidos, pero sin resolver,

de la fase de desarrollo. Los datos relacionados con Errores Conocidos del
desarrollo necesitan estar a disposición del Service Desk del entorno vivo
cuando una aplicación o un paquete de Difusión se implementan.
Reactivo- Pro-activo
Las actividades descritas hasta ahora en el control de errores y Problemas
son principalmente reactivas. Las actividades de Gestión de Problema pro-
activa tratan de identificar y resolver Problemas y Errores Conocidos antes
de que ocurran Incidencias, dicho de otro modo minimizando-el impacto
adverso en el servicio y los costes relacionados con el negocio. La
prevención de problemas llega desde la prevención de Problemas
individuales hasta decisiones estratégicas. Las últimas puede que requieran
mayor gasto de implementar tal como una inversión en una mejor red de
conexión.
Las actividades principales dentro de los procesos de Gestión de Problemas
pro-activa son análisis de tendencias y el marcar objetivos de acción
preventiva. El análisis de tendencias puede llevar a la identificación de
fallos en la infraestructura de IT, los cuales pueden ser entonces analizados
y corregidos tal y como se describe en las secciones de Control de Errores y
Problemas. El análisis de tendencias también puede llevar a la identificación
de áreas de Problemas generales que necesitan más atención de soporte.
Debería ser posible hacer comparaciones significativas al expresar esto en
términos de coste financiero a la organización.
Los informes de análisis de Problemas e Incidencias proporcionan
información de medidas pro-activas para mejorar la calidad de servicio. El
objetivo es identificar los componentes ‘frágiles” de la infraestructura de IT
e investigar las razones para la fragilidad- en este contexto la ‘fragilidad” es
proporcional al impacto al negocio si falla el CI.
La categorización de Incidencias y Problemas y el análisis creativo pueden
desvelar tendencias y llevar a la identificación de áreas de Problemas
específicos (potenciales) que necesitan más investigación. Por ejemplo, el
análisis puede indicar que las Incidencias relacionadas con la utilidad de los
sistemas cliente-servidor recientemente instalados sean el área de
Problemas que tiene más crecimiento en términos de impacto negativo en el
negocio.
El análisis de datos de Gestión de Problemas puede desvelar: - que el
Problema que ocurre en una plataforma puede ocurrir en otra plataforma-
por ejemplo, un Problema que concierne al software de red en un sistema
de medio campo puede bien tener significado en un sistema principal- la
existencia de Problemas recurrentes- por ejemplo, si tres routers se
sustituyen secuencialmente, por el mismo fallo, puede indicar que el tipo de
router en cuestión no es apropiado y debería ser reemplazado por otro tipo,
o cuando se trata de una aplicación de software entonces puede que un
redesarrollo completo sea necesario que se clasificaría de Cambio mayor.
51
La información de gestión debería proporcionar una vista interna del
esfuerzo y recursos gastados por la organización en investigar, diagnosticar y
resolver Problemas y Errores Conocidos. Además de esto, es importante
proporcionar una percepción del progreso hecho y los resultados obtenidos
como resultado. Las medidas se tiene que seleccionar con cuidado. Sólo
mediante medidas cuidadosas y significativas puede la dirección formar una
opinión de la calidad de un proceso.
Algunas medidas sugeridas son:
 Los números de RFCs surgidos y el impacto de esas RFCs en la
disponibilidad y fiabilidad de los servicios cubiertos
 La cantidad de tiempo trabajado en investigaciones y diagnósticos por
unidad organizacional o de proveedor, dividido por tipos de problema
 El número e impacto de incidencias que ocurren antes de que se
cierre el problema de raíz o se confirme un error conocido
 La proporción de esfuerzo de soporte inmediato (reactivo) frente a
esfuerzo de soporte programado en gestión de problemas
 Los planes de resolución de problemas abiertos con relación a los
recursos:
 Personas
 Otros recursos utilizados
 Costes (contra presupuesto)
51
53
53
54
55
55
56
 Proporcionar consejo y guía para os estándares de la infraestructura.

 Proporcionar consejo de dónde deben estar situados los componentes
de difusión en la infraestructura.
 Comunicar e informar de los proyectos en los que está incluida la
gestión de la configuración y preparar planificaciones que aseguren
una transferencia de éxito hacia el servicio final.
Descripción
Las tareas de la Gestión de Cambios

Gestión de Cambios es responsable de dirigir el Proceso de Cambios. Este
proceso NO está al cargo de implementar cambios, sólo controlará que se
aprueben cambios y que se implementen de forma eficiente, de forma
efectiva en lo que se refiere a coste y con un mínimo riesgo para los
servicios nuevos y existentes. A fin de hacer esto de modo correcto,
necesitamos un proceso. Pero también procedimientos y guías muy
detallados de cómo hacer distintas cosas en el proceso. Para evaluar el
riesgo de cada cambio es muy importante que tengamos una idea de la
configuración que controlamos. Por eso, necesitamos Gestión de
Configuración.
También, una de las responsabilidades es alcanzar los cambios que se van a
programar. Solamente cambios programados y adecuadamente sincronizados
pueden ser controlados porque tenemos el tiempo de supervisar lo que se ha
de hacer y nos podemos asegurar que lo que se ha de hacer se haga! Claro
que necesitamos un plan y necesitamos herramientas para hacer planes. Lo
más importante es tener una percepción de los recursos que requerimos y
que están disponibles.
La comunicación es la clave en un proceso de cambio exitoso. Una falta de
comunicación es muy a menudo la razón para que los cambios no se
implementen bien y que ocurran incidencias. Cuantas más personas estén
informadas más posibilidad tenemos que el cambio se analice y monitorice
adecuadamente para que el implemento sea correcto. También, cuantas
más personas sepan del cambio, más podemos conseguir que IT pueda
contestar preguntas que surjan de acuerdo con el cambio. Una estructura de
comunicación (p.ej. el CAB) es por lo tanto necesaria. Otra cosa son los
informes, claro está. Ayudarán a comunicar los cambios que hacemos y
cómo los hacemos.
Inputs y Outputs
Los inputs principales del proceso de gestión de cambios son solicitudes de
cambio y el ITIL para averiguar el impacto del cambio. También el Programa
Adelantado de Cambio se considera un input porque con este programa uno
57
puede determinar si hay conflictos de asuntos de sincronización de

implementos.
El output del proceso es, claro, el mismo Programa Adelantado de Cambios,
en el que las fechas de implemento recién decididas se han marcado. Otro
output del proceso serán RFCs para crear RFCs más detalladas o ajustar RFCs
existentes, las minutas del CAB y las acciones resultantes de eso (las
minutas también mostrarán que el cambio se ha implementado con éxito, el
ITIL actualizado, etc.) Finalmente, de este proceso, los informes de gestión
de cambio serán entregados a las partes interesadas.
Cambios, RFC y FSC

Las definiciones de los términos son (también ver el glosario)
Cambio:
Añadir, modificar o eliminar hardware-de soporte, aprobado o de base, red,
software, aplicación, entorno, sistema, documentación de escritorio o
asociado.
Solicitud de Cambio:
Formulario, o pantalla, usado para grabar los detalles de una solicitud a
cualquier CI dentro de una infraestructura o a procedimientos o artículos
asociados con la infraestructura.
Programa Adelantado de Cambios:
Programa que contiene los detalles de todos los Cambios aprobados para
implementar y sus fechas propuestas de implemento.
Proceso de Gestión de Cambio

El proceso estándar de ITIL- de una visión generales:
1. Solicitud de Cambio
Una RFC es el comienzo de un ciclo de la vida de un cambio.
2. Registro y Clasificación
Recoger la información necesaria para tomar decisiones sobre qué se ha
de cambiar, la categoría y el impacto para que la autorización se pueda
hacer correctamente. Se asigna una prioridad y categoría que se basa en
el impacto del cambio. Evaluación de riesgo es de una importancia
crucial en este momento.
3. Monitorizar y Programar
Bajo responsabilidad de la Gestión de Cambios todos los cambios se
programarán y un plan (con hitos) será proporcionado si es necesario
para el control óptimo de (el / los) cambio(s).
4. Aprobar
57
58
Decidir si el cambio se va a manejar o no

5. Construir y Probar
Las RFC’s autorizadas deberían ser pasadas a los grupos técnicos
relevantes para la construcción de Cambios. La Gestión de Cambios tiene
un rol de coordinación, apoyado por Gestión de Difusión y la dirección de
línea normal, para asegurar tanto que las actividades tengan recursos,
como que se completen de acuerdo con el programa. Para prevenir que
los cambios impacten de manera seria la calidad de servicio, se
recomienda seriamente que los Cambios se prueben rigurosamente por
adelantado (incluidos procedimientos de retroceso a ser posible).
6. Autorizar Implementación
Después de una prueba adecuada y comprobación de que toda la acción
necesaria se ha llevado a cabo, se puede autorizar la difusión del
cambio.
7. Implementación
La Gestión de Cambio tiene la responsabilidad de asegurar que los
cambios se implementen según programa, aunque esto será en gran
medida un rol de coordinación ya que la implementación será la
responsabilidad de otros (p.ej. ingenieros llevando a cabo cambios de
hardware).
8. Evaluar
La Gestión de Cambio debe evaluar todos los cambios implementados
después de haber transcurrido un periodo predefinido. Esto se puede
hacer con la Revisión de Post Implementación. Este proceso puede
todavía involucrar miembros del CAB; La Gestión de Cambios solicita
ayuda en esta parte del proceso. La Gestión de Cambios debería también
evaluar y realizar acciones de seguimiento para corregir cualquier
problema o ineficiencias surgidas en el sistema de Gestión de Cambios
mismo como resultado de cambios no efectivos.
Solicitud de Cambio (RFC)- Alcance

Las solicitudes de cambio se inician por una amplia variedad de razones,
desde una amplia variedad de fuentes. Es el comienzo del ciclo vivo del
cambio. Las RFCs pueden tratar de cualquier parte de la infraestructura o
con cualquier servicio o actividad. Las RFCs pueden, claro está, ser de
papel, o como es cada vez más el caso- estar en forma electrónica, puede
que en la intranet de la compañía. Todas las RFCs se deberían registrar y
dar un número de identificación.
Los siguientes artículos se deberían incluir en el formulario de la RFC, bien
sea de papel o electrónico:
 El número de RFC (más la contra referencia al número de informe de
Problema, de ser necesario)
59
 Descripción e identidad de(l ¡los) artículo(s) a cambiar (incluidos las

identificaciones de los CI’s si el sistema de Gestión de Configuración
está en uso)
 Razón para el Cambio
 Efecto de no implementar el Cambio
 Versión del artículo a ser cambiado
 Nombre, localización y número de teléfono de la persona que
propone el Cambio
 Fecha en la que se propuso el Cambio
 Prioridad del Cambio
 Evaluación 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 autorización (podría ser electrónica)
 Fecha y hora de autorización
 Implementación programada (identificación y/o fecha y hora de
Difusión)
 Localización del plan de Difusión ¡Implementación
 Detalles del constructor ¡responsable de implementar el Cambio
 Plan de retroceso
 Fecha y hora de la implementación real
 Fecha de revisión
 Resultados de la revisión (incluida la contra referencia a la nueva RFC
de ser necesario)
 Gestión y evaluación de riesgo
 Impacto en la continuidad del negocio y planes de contingencia
 Estatus de la RFC- por lo tanto, “registrada”, “evaluada”,
‘rechazada”, ‘aceptada”, “dormida”
A medida que el cambio proceda por su ciclo de vida, la solicitud de cambio
debería ser actualizada, para que la persona que inició el cambio esté al
tanto de su estatus. Los recursos actuales utilizados y los costes incurridos
se deberían registrar como parte del expediente.
Fijar Prioridad
Una vez aceptada la RFC, se indica la prioridad y la categoría de la misma.
La prioridad indica la importancia del Cambio y se dirige por el impacto y la
59
60
urgencia. El código de prioridad ya puede estar atribuido por la Gestión de

Problema, pero los códigos definitivos están determinados desde la Gestión
de Cambio, considerando cualquier RFC pendientes de discusión. La
categoría la determina el Director de Cambios. Esta clasificación determina
cómo se procesará la aplicación en adelante y por lo tanto, se dirige desde
el “peso” del ajuste.
Subdivisión de la Prioridad
Los códigos de prioridad por ejemplo, son:
 Prioridad 0, la prioridad más 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 IT (por ejemplo una nueva
funcionalidad a causa de consideraciones de la compañía o una
pequeña ley de emergencia). Los cambios a esta prioridad caen bajo
la categoría de “Cambios Urgentes”. Los Cambios Urgentes se difieren
de los procedimientos normales porque los recursos necesarios
necesitan estar disponibles inmediatamente para este tipo. Una
reunión de emergencia del CAB o el comité dirigente de IT puede ser
necesaria.
 Prioridad 1, alta prioridad: causa problemas técnicos severos para un
gran grupo o un número de usuarios o concierne otras situaciones
urgentes. Este Cambio obtiene prioridad máxima en la próxima
reunión programada del CAB.
 Prioridad 2, prioridad normal: no una emergencia inmensa o de alto
impacto pero el Cambio no se puede posponer a un momento más
conveniente. Este Cambio dentro del CAB recibe prioridad media con
la atribución de recursos.
 Prioridad 3, baja prioridad: un Cambio es deseado pero podría
esperar hasta un momento más conveniente (por ejemplo la próxima
difusión o cita de mantenimiento programada).
El Impacto del Cambio
Subdivisión de la Categoría
Las categorías las atribuye el Director de Cambios, cuando es necesario en
deliberación con el CAB, que da una indicación del impacto del Cambio y la
carga en la organización de IT. Bajo, se relaciona un ejemplo subdivisión de
las categorías enumeradas:
 Estándar: la confianza de que el procedimiento escrito asegurará que
los riesgos son mínimos está ahí. El cambio se puede ejecutar sin
previo contacto con el director de cambios. Por esta razón, los
cambios estándar deben ser ordenados por el director de cambios.
61
 Categoría 1: pocas consecuencias; un Cambio que no conileva mucho

trabajo. El Director de Cambios puede aprobar este tipo de Cambios
sin consultar con el CAB.
 Categoría 2: consecuencias sustanciales; Cambios que requieren
esfuerzos mayores y que tienen mayor impacto en los servicios. Tales
Cambios se discuten en la próxima reunión del CAB para predecir los
esfuerzos necesarios y posibles consecuencias. Antes de la reunión, la
documentación necesaria será enviada a los miembros del CAB y
potencialmente a varios especialistas y encargados de desarrollo.
 Categoría 3: consecuencias inmensas: un Cambio que requiere una
gran cantidad de esfuerzo. Con un Cambio así el Director de Cambios
necesita obtener autorización de la dirección de IT o un comité
dirigente de IT y entonces debe discutirlo con el CAB.
La mayoría de los Cambios acaban en las dos primeras categorías.
La Junta de Asesoramiento de Cambios (CAB)

El término “Junta de Asesoramiento de Cambios” es un término de ITIL.
Para algunos, el término “Junta” crea la imagen de reuniones programadas
muy formales del mismo grupo de altos ejecutivos. Aunque una reunión del
CAB puede ser formal, también puede ser informal. En el mundo de negocios
de hoy, el término “equipo” puede que ilustre mejor la dinámica típica del
CAB. El ‘equipo” CAB puede reunirse de forma regular; las reuniones de CAB
pueden ser varias veces a la semana, con reuniones especiales convocadas
en cualquier momento. Algunos miembros del CAB probablemente tendrán
programado asistir a reuniones de CAB regularmente; Otras personas puede
que se les pida unirse a una sesión de CAB para proporcionar input sobre una
Solicitud de Cambio específica que está programada para discusión.
El CAB existe para aprobar la mayoría de los cambios y para asistir a la
Gestión de Cambio en la evaluación y priorización de cambios. Siempre y
cuando se convoque al CAB, los miembros elegidos deben ser capaces de
evaluar adecuadamente desde un punto de vista tanto técnico como de
negocio. Para alcanzar esta mezcla, el CAB necesita incluir personas con un
entendimiento claro de las necesidades de negocio del Cliente y de la
comunidad Usuaria, además de las funciones de desarrollo técnico y de
soporte.
Los miembros del CAB podrían ser el Gerente de Cambios, Cliente(s),
Director(es) de Usuarios, representante(s) del grupo de usuarios, encargados
de desarrollo /mantenimiento de aplicaciones (en su caso), consultores
técnicos! expertos, personal de servicio (según necesidad), personal de
servicios de oficina (donde los Cambios puedan afectar alojamiento y
viceversa), contractores y representantes de terceros (según demanda, por
ejemplo en contratar a terceros (outsourcing), situaciones).
Es importante enfatizar que el CAB:
 Estará compuesta de acuerdo con los Cambios considerados
61
62
 Puede variar considerablemente en su arreglo incluso a lo largo de

una sola reunión
 Debería involucrar a proveedores cuando sea de utilidad
 Debería reflejar los puntos de vista tanto del Cliente como del
usuario
 Es probable que ¡ncluya el Director de Problemas y el Director de
Nivel de Servicio y personal de Atención al Cliente por lo menos parte
del tiempo.
Cuando surjan Problemas mayores, puede que no haya tiempo de crear el

CAB entero, y por lo tanto es necesario identificar una organización más
pequeña con autoridad para tomar decisiones de urgencia. Tal cuerpo en
ITIL se conoce como el Comité de Emergencia del CAB (CAB/EC). Los
procedimientos de Cambio deberían especificar cómo el formato de CAB y
CAB/EC se determinará en cada instancia, basado en el criterio arriba
indicado y cualquier otro criterio que pueda ser apropiado para el negocio.
Esto se hace con la intención de asegurar que el formato del CAB sea
flexible, a fin de representar los intereses del negocio adecuadamente
cuando se proponen cambios. También asegurará que la composición de la
CAB/EC proporcionará la habilidad, tanto desde el punto de vista del
negocio como técnico, de tomar decisiones en cualquier eventualidad
concebible.
Relaciones Importantes
La Gestión de Cambio y de Configuración están muy relacionados una con la
otra. En primer lugar, por el hecho de que la Gestión de Configuración no
puede sobrevivir sin la Gestión de Cambio. No puedes controlar la CMDB si
no controlas la configuración misma. El proceso de Verificación es un
proceso que se puede usar para controlar la efectividad de la Gestión de
Cambio. Si —tras verificación- el Director de Configuración ha encontrado
CI’s en la configuración que no están en la base de datos hay dos opciones:
1) la base de datos no está actualizada que puede indicar que no se informó
a la Gestión de Configuración del cambio o 2) alguien ha ejecutado un
cambio ilegal- no-aprobado.
El campo más importante donde se relacionan los procesos es en el análisis
de impacto y riesgo de un cambio. La mayor parte de esto se tiene que
hacer con la ayuda de CMDB. Si alguien envió una RFC, una de las primeras
cosas que hacer es averiguar que CI o Cl’s se tienen que cambiar y cuál es el
impacto en la infraestructura existente. También tenemos que averiguar si
esta RFC resultará en más RFCs por el hecho de tener que cambiar más Cl’s
como resultado de esta solicitud. Y tenemos que averiguar si el cambio sólo
afecta a uno o más usuarios, uno o más dominios o uno o más servicios a fin
de asignar el código correcto de impacto a este cambio. Basado en todo
esto, podemos decidir si el CAB es necesario, a quién tenemos que invitar
63
para esto, en qué nivel tenemos que discutir y aprobar el cambio y podemos
generar la lista de “qué hacer” más completa.
La Gestión de Cambio (de modo ideal en consulta con los directores de
negocio) necesita pensar en medidas que tengan significado específico.
Mientras que es relativamente fácil contar el número de Incidencias que se
convierten en Problemas que se convierten en Cambios, es infinitamente
más valioso mirar a las causas subyacentes de tales Cambios e identificar
tendencias. Mejor aún poder medir el impacto de tales Cambios y demostrar
trastorno reducido a lo largó del tiempo por la introducción de Gestión de
Cambios y también medir la velocidad y efectividad con la que la
infraestructura de IT responde a necesidades de negocio identificadas.
Las medidas tomadas deberían estar ligadas a objetivos de negocio donde
sea práctico- y al coste, disponibilidad de servicio y fiabilidad. Cualquier
predicción debería compararse con medidas actuales.
Se deberían proporcionar resúmenes regulares de Cambios a la dirección de
servicio, Cliente y Usuario. Es probable que distintos niveles de dirección
requieran distintos niveles de información, desde el Director de Servicio que
puede necesitar un informe detallado semanal hasta los comités de
Dirección Superior que es probable que sólo necesiten un resumen trimestral
de dirección.
Considere los datos y estadísticas a continuación en los informes de
dirección:
 El número de Cambios implementados en el periodo, en total y por
CI, tipo de configuración, servicio, etc.
 Un desglose de razones para el Cambio (solicitudes de Usuarios,
mejoras, requisitos de negocio, arreglos de llamada de servicio /
Incidencias / Problemas, mejoras de procedimientos /formación,
etc.)
 El número de Cambios con éxito
 El número de Cambios retrocedidos, junto a las razones (p.ej.
evaluación incorrecta, mala construcción)
 El número de Incidencias que llevan a Cambios (desglosados por
niveles de severidad de problemas) y las razones ((p.ej. evaluación
incorrecta, mala construcción)
 El número de RFC5 (y tendencias en proceso de originarse)
 El número de Cambios implementados revisados, y el tamaño de
revisiones de atrasos (desglosados por tiempo)
 Altas incidencias de RFCs/PR5 relacionados a un CI (estos merecen
especial atención), dando las razones (p.ej. requisito de usuario
volátil, componente frágil, mala construcción)
63
64
 Cifras de periodos anteriores

 El número de RFCs rechazadas
 La proporción de Cambios implementados que no tienen éxito (en
total y desglosado por CI’s)
 Atrasos de Cambios, desglosados por CI y por etapa en el proceso de
Gestión de Cambios
65
65
66
67
67
68
Las tareas de la Gestión de Configuración

Las actividades básicas de Gestión de Configuración son las siguientes:
Programación. Planear y definir el propósito, rango, objetivos, políticas y
procedimientos, y el contexto de organización y técnico para la Gestión de
Configuración.
Identificación y nombramiento. Seleccionar e identificar las estructuras de
configuración para todas las infraestructuras de Cl’s, incluido su “dueño”,
sus interrelaciones y documentación de configuración. Incluye asignar
identificadores y números de versión para Cl’s, etiquetar cada artículo e
introducirlo en la Base de Datos de Gestión de Configuración
(CMDB).
Control. Asegurar que solo Cl’s autorizados e identificados son aceptados y
grabados desde recepción hasta su destrucción. Asegura que no se añade,
modifica, reemplaza o elimina ningún CI sin la documentación de control
apropiada, p.ej. una solicitud de Cambio aprobada y una especificación
actualizada.
Contabilidad de Estado. El informar de todos los datos históricos y actuales
que conciernen a cada CI a lo largo de su ciclo vital. Esto permite qué se
puedan localizar los Cambios a Cl’s y su historial, p.ej. localizar el estatus
de un CI a medida que cambia de un estado a otro tal como “en fase de
desarrollo”, “en fase de prueba”, “vivo” o “retirado”.
Verificación y Auditoria. Verificación y Auditoria de Configuración
comprenden una serie de revisiones y auditorias que verifican la existencia
física de Cl’s y comprueba que los Cl’s estén correctamente registrados en
la CMDB y en archivos controlados. Incluye la verificación de documentos de
Verificación y Configuración antes de cambiar el entorno vivo.
Información de gestión. Identificar informes y medidas e informar a la
organización y su dirección de la información requerida de los CI’s.
Rango y Detalle (Profundidad)

La Infraestructura de IT consiste en artículos de configuración. Un artículo
de configuración es un elemento documentado de la infraestructura de IT,
tal como hardware, software, alojamiento, personas y documentación
(Categoría).
Rango CMDB
El factor primordial al decidir tanto el rango como el detalle es la
información necesaria para gestionar el servicio al margen del coste o
dificultad de obtener y mantener esos datos. Un punto de vista más
pragmático es que no sólo se deben tener en cuenta esos factores sino
también, y puede que de modo más importante, los directores deben
69
considerar las consecuencias de almacenar datos poco exactos o desfasados

en la CMDB.
Antes de que la transición de montar una CMDB se lleve a cabo, se debe
decidir acerca de qué parte de la infraestructura de IT será controlada por
la Gestión de Configuración. La elección del Rango influye al rango de
diagnósticos de Gestión de Problemas, para la coordinación de Gestión de
Cambios, etc. Esta elección se recoge de las Declaraciones de Misiones que
se montan para los procesos. La elección del Rango también se monta en
parte de un análisis de los servicios y su contribución a, o su impacto en, las
actividades de negocio de los clientes. Aparte de esto, el Rango se puede
recoger de la determinación del Acuerdo de Nivel de Servicio.
Detalle CMDB
Con la subdivisión en niveles, se crea una jerarquía de componentes y
unidades. Se toman decisiones sobre qué son Cl’s principales y en cuántos
niveles estos Cl’s deben ser detallados. El nivel más alto es la
infraestructura de IT misma. El nivel útil más bajo es el nivel donde todavía
sea posible llevar control. La encarnación de un CI en la CMDB sólo es
efectiva cuando el control sobre el CI y la información que conlleva sea útil
para otros procesos de ITIL.
Con el establecimiento de la jerarquía de una CMDB, rigen las siguientes
normas:
Cuando hay más niveles, se debe mantener más información. Esto conlleva
más trabajo y
resulta en una CMDB más grande.
Cuando hay menos niveles, hay menos control e información sobre la
infraestructura de IT.
Cuando la CMDB no tiene profundidad suficiente, los cambios a los
componentes más bajos no se puede mantener adecuadamente. Cada ajuste
a componentes de un CI madre resultará en una versión alternativa del CI
madre; un PC que aparece con dos discos duros tendrá entonces una versión
A y una versión B. Si aparecen muchos ajustes en los componentes filiales,
entonces la numeración de variación se volverá opaca y difícil de seguir.
Nombramiento y otros atributos

Nombramiento
El nombre de un CI debe ser único. Cada CI en la infraestructura controlada
debe ser identificado y sólo podemos hacer esto, dando a cada CI un número
único. Como su automóvil. Este automóvil es único en- el mundo por una
combinación de números en su matrícula y el estado /país donde vive.
Nombramiento debe ser lógico y sencillo. Sencillo porque ¿qué necesidad
hay de hacerlo difícil? Personal de IT y clientes deben tener idea de cómo
69
70
leer y montar la identificación de CI. Así que intente encontrar una

identificación lo más lógica y sencilla como le sea posible: como Al 234567
en vez de PC_BUILDA_LOKI.4_ 1234.
A lo largo del ciclo vital de un CI, la primera identificación dada debe
permanecer. 1 que la excepción confirma la regla! Así que esta es otra
razón por la que no implementar números como PC_BUILDA_LOKI.4_ 1234
porque se relacione con el edificio donde se instaló.
Detalles de CMDB
Los siguientes atributos son ejemplos que se pueden utilizar en la CMDB.
Note que el hardware de los tipos de CI tendrá distintos atributos de los
tipos de CI de software.
Atributo Descripción
Nombre de CI El único nombre por el que se conocerá este tipo
de CI
Número de Copia o de El número que identifica de forma única las
Serie instancias particulares de este CI, por ejemplo, el
número de copia de software, para hardware el
número de serie
Categoría Clasificación de un CI (p.ej. hardware, software,
documentación, etc.)
Tipo Descripción del tipo de CI, ampliando la
información de “categoría” (p.ej. configuración de
hardware, paquete de software, aparato de
hardware o módulo de programa).
Número de modelo Modelo de CI (correspondiente por ejemplo al
número de modelo de proveedor (hardware) p.ej.
Dell model xxx, PC/aa model yyy).
Fecha de vencimiento Fecha en la que vence la garantía del proveedor
de Garantía
Número de Versión El número de versión 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 El nombre y/o designación del propietario
Responsable responsable del CI
Fecha de Fecha en la que el propietario arriba mencionado
Responsabilidad se hizo responsable del CI
Fuente / Proveedor La fuente del CI, p.ej. desarrollado en la misma
casa, importada de la empresa xxxx etc.
71
Licencia Número de licencia o referencia al acuerdo de

licencia
Fecha de Provisión Fecha cuando el CI fue dado a la organización.
Fecha de Fecha en la que el CI fue aceptado por la
Aceptación/Instalación organización como probado de modo satisfactorio.
Estatus (Actual) El estatus actual del CI; p.ej. bajo “prueba”,
“vivo”, “archivado”.
Estatus (programado) El próximo estatus programado del CI (con la fecha
o indicación del evento que provocará el cambio
de estatus).
Comentario Un campo de comentario a ser utilizado para
narrativa textual; por ejemplo, para proporcionar
una descripción de cómo esta versión del CI es
distinta de la versión anterior.
Relaciones en la CMDB
Se pueden llevar al día muchos distintos tipos de relaciones. Las relaciones
más frecuentes son:
 Es un componente de; esta es la relación de madre-hija del CI, como
un disco A es un componente de un PCy un módulo de software es un
componente de un programa.
 Es una copia de; una copia de un modelo estándar o de un programa.
 Se relaciona a un procedimiento, un SLA o un programa
 Se relaciona con; por ejemplo, un PC que está conectado con un
segmento LAN.
 Es utilizado por; como un CI que es utilizado por un servicio, para
que se puedan calcular los costes y la disponibilidad del servicio, o un
módulo de software que es necesario para varios programas para que
se pueda hacer un seguimiento de “cuál es el impacto de un ajuste”.
Igual que al determinar el número de niveles, es necesario sopesar de forma

meticulosa qué es necesario, la cantidad de trabajo que conlleva y los
recursos disponibles para ese trabajo, se debe hacer al determinar las
relaciones necesarias.
Otras relaciones:
RFC’s
71
72
La relación con todas las RFC’s afectando este CI.
Relación con Cambios

La relación con todos los archivos de cambios afectando a este CI
Relación con Problemas

La relación con todos los archivos de Problemas afectando este CI
Relación con Incidencias

La relación con todos los archivos de Incidencia afectando este CI
Impacto de las interrelaciones

Las relaciones que los CI’s tienen unos con los otros, entre otras cosas, son
útiles para muchas cuestiones. En primer lugar, podría ser de tremenda
ayuda para el Director de Gestión de Servicio. Para crear un SLA y OLA’s o
contrato, para analizar cómo se configuran servicios de punta a punta-es
muy importante saber cómo está construida la infraestructura y qué Cl’s son
parte de los servicios que producimos.
Si registramos un servicio como CI y relacionamos todos los componentes
que necesitamos para poder entregar este servicio, el Servie Desk puede
analizar mejor qué componente es el que puede causar la Incidencia. Si
hemos relacionado el CI del documento de SLA al servicio, el Service Desk
puede averiguar inmediatamente qué servicio es el que tiene que entregar
al cliente. Si relacionamos todas las incidencias habidas al CI al que
pertenece podríamos investigar si el actual está relacionado con los habidos
anteriormente y si se puede encontrar una solución.
En segundo lugar, para el diagnóstico de problemas técnicos, puede ser muy
útil también. Si tenemos incidencias relacionadas podemos investigarlas
también para encontrar la causa original. Si hemos relacionado el historial
de cambios anteriores podemos investigar si esos cambios son la causa de
este problema.
Si el Director de Disponibilidad quiere predecir la disponibilidad de los
servicios es necesario que esta persona pueda asignar los Cl’s necesarios
para poder entregar estos servicios. Basados en la información que él ¡ella
tenga de los Cl’s, se puede comenzar el cálculo.
Por último, pero no por ello de menor importancia, las relaciones son muy
importantes para analizar el impacto de un cambio. Sólo con relaciones
puede ver la relación entre el CI que se debe cambiar y otros CI’s. Basado
en la información el Director de Cambios puede fijar la categoría, puede
invitar el personal adecuado al CAB y puede decidir qué se debe hacer para
que este cambio sea un éxito.
73
Estados de CI’s
El ciclo de vida de un componente se puede dividir en muchas etapas
distintas. Cada etapa puede recibir un código de estatus. Esta información
se determina por los intereses que la organización ha hecho públicos con
respecto a los rasgos de la infraestructura de IT que necesitan ser
registrados. Al guardar la fecha de los cambios de estatus, se puede
desarrollar una buena visión del ciclo vital de un producto; las horas de
adquisición, las horas de instalación y la cantidad de mantenimiento y
soporte que se ha invertido.
El estatus de un componente también puede ser decisivo en lo que se pueda
hacer con él. Por ejemplo, cuando un estatus se mantiene al día de
provisiones (no operacionales) este equipamiento no se puede utilizar para
otras actividades sin consultar en general. El cambio del estatus puede estar
afiliado a un ajuste o cambio, permitido o no permitido, o a una incidencia.
Se puede considerar la siguiente subdivisión:
 Nuevos CI’s:
 En desarrollo/pedidos
 Probados
 Aceptados
CI’s Existentes:
 Recibidos.
 Aplicación no fijada de cambio para este CI, solicitada nueva versión.
 El cambio ha sido aprobado y se ha considerado en el plan, un nuevo
CI y documentación (que también es un CI) llega.
 Bajo mantenimiento.
 Fuera de servicio, problemas técnicos
 Fuera de uso, archivado
Todos los CI’s:

 La orden se ha recibido o la versión ajustada está disponible.
 Está siendo probado
 Liberado, se puede instalar
 Activo, el CI está siendo utilizado.
 Provisiones
73
74
Línea Base (Baseline)

Una línea base de configuración es la configuración de un producto o
sistema establecido en un momento concreto en el tiempo, que capta tanto
la estructura como los detalles de una configuración. Es una referencia para
más actividades. Una aplicación o línea de base de software proporciona la
habilidad de cambiar o reconstruir una versión concreta en una fecha más
adelante.
Las líneas base de configuración 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 configuración. Las líneas base
de configuración mas cambios aprobados a esas líneas de base, juntos,
constituyen la configuración actualmente aprobada. Ejemplos específicos de
líneas base que se pueden identificar son:
 Un CI estándar particular necesitado cuando se compran muchos
artículos del mismo tipo (p.ej. ordenador de escritorio) a lo largo de un
periodo protactado. Si unos servidores deben incluir teclados de circuito
impreso adicionales, esto podría corresponder a una “línea base plus”. Si
todos los ordenadores de escritorios en el futuro tendrán estos teclados,
se forma una nueva línea base.
 Una aplicación de Difusión y su documentación asociada
 A la que referirse (debe existir físicamente y poder referirse a ella
con facilidad)
 Como estado del software para distribución a locales remotos
 Como estado del software sobre el que trabajar en un futuro
 Como estado en el que debe estar un sistema antes de poder
mejorarlo aceptando nuevo hardware
 software
Varias líneas base correspondientes a distintas etapas en la vida de un

“artículo de línea base” pueden existir en un momento dado- por ejemplo,
la línea base para una difusión de software que ya está en “vivo”, la de que
estaba “vivo” anteriormente a éste y que ahora se encuentra archivado, el
próximo que se instalará (salvo cambios bajo control de Gestión de
Configuración) y uno o más bajo prueba. Más allá, si, por ejemplo, nuevo
software se está introduciendo gradualmente a nivel regional, más de una
versión de línea base podría estar “viva” a la vez. Por lo tanto, es mejor
referirnos a cada una por su número exclusivo de versión, mejor que como
“vivo”, “próxima” o “antigua”.
Una línea base de configuración es también una instantánea, o una postura,
que está grabada. Aunque la posición se pueda actualizar después, la línea
75
base de configuración se queda fijada como el estado original y por lo tanto,

está disponible para poder compararse con la posición actual. Una línea
base de configuración se utiliza para montar todos los componentes
relevantes en preparación para un Cambio o una Difusión, y para
proporcionar la base para una auditoria y regresión p.ej. después de un
Cambio. El sistema de Gestión de Configuración debería poder guardar,
proteger e informar de una línea base, su contenido y documentación.
Los informes de gestión deberían estar diseñados para soportar actividades
de Gestión de Servicio tales como monitorización de progreso, auditorias de
Configuración y programación de servicios. Los informes se deben poner a
disposición para interrogación y análisis de tendencias por parte de la
Dirección de Servicio de IT y otros grupos dentro de la estructura de
servicios de IT. En general, la Dirección de Gestión de Servicios debe marcar
la dirección futura de la Gestión de Configuración a la luz de estos informes
de gestión, teniendo en cuenta la carga de trabajo y crecimiento de la
Gestión de Configuración programada.
Informes de dirección de Gestión de Configuración deberían cubrir lo
siguiente.
 Resultados de auditorias de configuración
 Información sobre CI’s no-registrados o registrados de modo poco
exacto que se han detectado y la acción correctiva
 Información sobre el número de Cl’s registrados y versiones de CI’s,
divididos por categoría, tipo y estatus (y posiblemente también por
localización u otros atributos de CI)
 Información de crecimiento y capacidad
 Información sobre el ritmo de cambio de Cl’s/ CMDB y la DSL
 Detalles de trabajo acumulado (backlogs) de Gestión de Configuración
o atrasos causados por actividades de Gestión de Configuración y
remedios propuestos.
 La posición de personal de Gestión de Configuración
 La cantidad de trabajo autorizado realizado fuera de horario por
empleados de otros servicios de IT
 Los resultados de revisiones de eficiencia / efectividad, revisiones de
crecimiento y auditorias del sistema de Gestión de Configuración y
propuestas para atacar problemas reales o en potencia
 Datos y análisis del número de Cl’s por tipo (p.ej. servicios,
servidores, enrrutadores, conmutadores, licencias de software, CI’s
de escritorio, etc.)
 El valor de los Cl’s (o bienes)
75
76
 La localización de CI’s por unidad de negocio, grupo de soporte o

servicio.
77
77
78
79
79
80
Descripción
Proceso de distribución y Difusión

Los entornos se deben mantener separados con una ruta de migración
controlada y un rastro de auditoria de todas las difusiones y retrocesos. El
entorno de archivo puede ser considerado un sub-entorno de la DSL y ser
sujeta al mismo nivel de control. Si se encuentran errores inaceptables-
durante las pruebas (y cambios realizados) el número de versión debe ser
aumentado. Todo se hace bajo el control de Gestión de Cambios.
La Gestión de Difusión cubre la parte desde el momento en el que se adopta
el software en la DSL hasta que el software es trasladado a los archivos.
Durante el ciclo de vida de un programa, se pasan por los siguientes pasos:
 El proceso comienza o con la adquisición del software, o con la
asignación del desarrollo del software.
 Cuando se entrega el software se realizará una comprobación de
calidad.
 En la comprobación de calidad, el software se adopta a la DSL. Se
examina por ejemplo si éste realmente es el software pedido, si
nuevas versiones se han desarrollado de la fuente correcta, si todos
los ajustes han sido autorizados por Gestión de Cambios y si todos los
artículos están registrados en la CMDB.
 Una vez aceptado el software, un backup (soporte) de la DSL se hace
después del cual el software será aceptado en la DSL. Estos backups
deben ocurrir frecuentemente para que en caso de un desastre la
última versión correcta pueda ser montada con rapidez.
 La compilación y sincronización de cada difusión son decididas por
adelantado por la Gestión de Cambio, un “Registro de Difusión” se
hace en la CMDB y todos los detalles se registran. -
 Cuando todos los componentes del software están preparados, el
paquete se puede realizar en un área de prueba donde todos los tests
obligatorios se puedan ejecutar.
 Cuando se encuentran demasiados errores, el software se devuelve
para más desarrollo
 Cuando se apruebe el software, será difundida para su explotación.
La difusión entonces será distribuida y llevada a su explotación.
Se puede disponer de copias de los artículos de software de la DSL para

varias áreas diferentes, de los cuales los cuatro más habituales se detallan a
81
continuación. Una subdivisión diferente más detallada también es posible,

claro está.
 Desarrollo: cuando se desarrolla una nueva versión, se puede originar
de una anterior de la DSL. El área de desarrollo es la única área en el
que se puede ajustar o cambiar el software.
 Prueba: en un área de prueba, se pueden probar ciertas versiones
 Explotación: El área real (vivo) alrededor desde el cual se pone a
disposición a los usuarios el software.
 Archivos: aquí se guardan versiones originales (anteriores) de
artículos de software que ya no están en uso.
Estas copias sólo pueden estar presentes en un solo área en cada momento.
Biblioteca Definitiva de Software (DSL)

La Biblioteca Definitiva de Software (DSL) es una conglomeración de
Artículos de Configuración de software y documentación en un lugar seguro.
Físicamente, la DSL puede ser una colección de medios electrónicos (como
disquetes, cintas y CD5) en distintos formatos de software; archivos y
documentación electrónica (o de papel). La DSL es una biblioteca lógica. Eso
significa que “lógicamente” hay una sola entidad de software almacenada.
Físicamente, es posible que haya muchas copias de una entidad de software,
almacenadas en distintos lugares (en un banco, en un centro de
contingencia, cerca de desarrollo, etc.) Ya que todas estas entidades deben
ser la misma, “lógicamente” seguimos teniendo una sola entidad.
Cada artículo de Software autorizado se almacena (físicamente) en la DSL.
En la DSL, se guardan todas las versiones originales de software que han sido
transmitidas a explotación.
Almacén Definitivo de Hardware (DHS)

Se debe apartar un área para el almacenaje seguro de repuestos de
hardware definitivos. Estos son componentes y montajes de repuesto que se
mantienen al mismo nivel que los sistemas comparativos en el entorno vivo.
Detalles de estos componentes y sus respectivos contenidos y construcciones
se deben registrar comprensiblemente en la CMDB. Estos se pueden utilizar
entonces de manera controlada cuando se necesiten sistemas adicionales o
en la recuperación de Incidencias mayores. Una vez que su uso (temporal)
haya terminado, deben ser devueltos al DHS o se deben obtener sus
sustitutos.
81
82
Difusiones
EL Director de Difusión debe fijar una Política de Difusión por adelantado en
la que se decide cómo y cuándo se deben compilar las actualizaciones del
software. La primera elección que se hace ahí es la del nivel de Difusión de
Software. Se hace un inventario en el que los subartículos de un programa
todavía se pueden distribuir de forma independiente unos de otros.
Un ejemplo de un problema rodeando esta elección es la difusión de
expedientes de Dynamic Link Libraries (DLL- Bibliotecas de Nexos
Dinámicos), que a menudo requieren programas diferentes. A veces una
nueva versión de una DLL se entrega con un paquete y esto podría significar
que también le influye a otro software. La elección final depende de:
 La cantidad de trabajo que el ajuste de un componente del programa
cause a otros componentes del programa (incluido el software de
sistema).
 La cantidad de horas humanas y tiempo que hace falta para construir
y probar cambios individuales, en comparación con lo que costaría
guardar algunos y ejecutarlos todos a la vez.
 El grado de dificultad de una posible instalación con los usuarios;
puede por ejemplo, ser más fácil instalar un programa completo por
que los mecanismos estándar para ello ya existen.
 La complejidad de dependencias entre el nuevo software y la
infraestructura de IT; cuánto más fácil sea aislar el software, más
fácil es probarlo.
Es de gran importancia evaluar el número de ajustes que se pueden probar
todos juntos por adelantado en un cierto tiempo, una Difusión Empaquetada
(agrupación de cambios diferentes en un solo despliegue) puede ser tan
compleja que nunca pase la fase de prueba. Como resultado del rápido
desarrollo del nuevo software, la nueva Difusión puede que ya no esté
actualizada para cuando sea difundida. Por otro lado, una gran cantidad de
ajustes puede resultar en grandes molestias para el servicio.
Numeración de Difusión - asegura que cada difusión tenga asignada un
número de difusión para que pueda ser identificada de forma única. Debería
haber una frecuencia de difusión bien publicitada y predecible y un límite
acordado para el contenido de cambio. Los requisitos de negocio deberían
ser el factor determinante más que la conveniencia técnica. Las
especificaciones se deberían congelar con suficiente adelanto de la fecha de
difusión para permitir pruebas suficientes.
Unidad de Difusión — el nivel al que software de un nivel determinado se
difunde normalmente
Difusión Completa — significa que el programa entero se distribuirá una vez
más, incluidas las partes que no están presentes.
Difusión de Delta — en matemáticas, “Delta” significa “diferencia”, es una
difusión de ese software que ha sido ajustado exclusivamente. Esto
frecuentemente trata de una solución de urgencia o un “Arreglo Rápido”.
83
Difusión Empaquetada — Con una Difusión Empaquetada se enfatizan

periodos de estabilidad más largos para los usuarios.
Difusión Urgente — una Difusión Urgente ocurre cuando hay una razón
urgente para desplegar una nueva versión. Una Difusión Urgente es un
ajuste urgente y se lleva a cabo en nombre de la Dirección de Cambio.
Normalmente trata de una Difusión Delta.
Despliegue y distribución de Software

Los procedimientos se deben programar para la distribución de difusiones de
software del entorno de construcción de prueba al entorno de prueba, al
entorno vivo de construcción vivo y al entorno vivo. Debería incluir detalles
puntuales de cuándo un número de usuarios debe usar la misma versión en
varios lugares. El registro de difusión en la CMDB se debe actualizar a lo
largo de la implementación de las difusiones. Aparte del entorno técnico, el
entorno de negocio también influye, particularmente si 24x7 se desarrolla a
escala global.
A fin de mantener una buena política de distribución, nuevas versiones de
software se deberían programar con mucho adelanto. Cuando la
programación de una difusión de ciertas versiones de software se conoce,
las difusiones se pueden preparar de acuerdo con los principios del último
párrafo.
Algunas veces, los errores sólo ocurren cuando una nueva versión ya se ha
llevado a la explotación. En este caso, es muy importante que un buen
procedimiento de Fail Back esté presente para que una versión archivada se
pueda utilizar inmediatamente. Esta también es una razón por la que un
Back up de la DSL debe ocurrir frecuentemente.
Cuando más lugares múltiples aparecen con dirección local, entonces estas
localidades deben tener una copia de la DSL para poder desplegar software.
Antes de cada despliegue, es importante que un plan de distribución e
implementación se haga. En este plan, se deben considerar el impacto para
los usuarios y las fuentes necesarias.
Se deben monitorizar un número de indicadores de rendimiento claves
(KPI’s) para evaluar la efectividad del proceso de Gestión de Difusión.
Considere elegir algunas medidas que muestran un claro indicativo de lo
siguiente:
 Difusiones construidas e implementadas según programa, y dentro de
los recursos presupuestados
 Un número muy bajo (de forma ideal ninguna) de Incidencias de
Difusiones que se han tenido que retroceder debido a errores
inaceptables
83
84
 Baja incidencia de fallos de construcción

 Gestión 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 retoques en
cualquier software extraído de la DSL
 Tamaño 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
 Distribución precisa de Difusiones a lugares remotos
 Implementación puntual de Difusiones a todos los lugares, incluidos
los remotos
 Ninguna evidencia de reversión no autorizada a versiones anteriores
en ninguna ubicación
 Ninguna evidencia del uso de software no autorizado en ninguna
ubicación
 Ninguna evidencia del pago de multas de licencia o esfuerzo de
mantenimiento malgastado, por software que no está actualmente en
uso en ninguna ubicación
 Ninguna evidencia de duplicación malgastada en el edifico de Difusión
(p.ej. Construcciones múltiples de ubicaciones remotas, cuando
copias de una sola construcción serían suficiente)
 Registro puntual y preciso de toda actividad de construcción,
distribución e implementación dentro de la CMDB
 Un post mortem desarrollado sobre todas las actividades de Difusión y
todas las acciones correctivas o de seguimiento necesarias realizadas,
junto con cualquier mejora de proceso
 La composición programada de Difusiones de acuerdo con la
composición actual
 Recursos de IT y humanos requeridos por la Gestión de Difusión siendo
sujetos a buena programación por adelantado
Otras medidas que se pueden monitorizar incluyen:
 El número de Difusiones mayores y menores por periodo de informe
 El número de Problemas en un entorno vivo que se pueden atribuir a
nuevas difusiones, que sólo necesitan ser medidos durante los
primeros meses de vida de una difusión, clasificados por su causa de
raíz (p.ej. ‘versión errónea en expediente”, o “falta expediente”)
 El número de objetos nuevos, cambiados o eliminados introducidos
por la nueva difusión- p.ej. cuántos módulos y programas
85
 El número de Difusiones completadas en el horario acordado; esto

requiere la función de Gestión de Difusión central para publicar
objetivos predefinidos (niveles de servicio o SLA’s) para distribuciones
de software y otras tareas comunes.
85
87
87
88
89
89
90
El proceso es un ciclo completo de calidad. Una vez que se han definido los
SLAs, empieza el ciclo.
Establecimiento de Función
Si todavía no se ha establecido la Gestión de Nivel de Servicio entonces el

primer paso es programar el proceso. Actividades tales como diseñar
procedimientos, crear catálogos de servicio, editar SLAs y campañas de
concienciación son entre otras, las cosas que se tienen que planear. Las
siguientes cosas se tienen que planificar:
 Planning Inicial de Actividades

 Plan de Capacidades de Monitorizar
 Establecimiento de la Percepción Inicial de los Servicios
 Comprobación de los Acuerdos de Nivel Operacional y los Contratos
Subyacentes
Implementar SLAs
En la fase de implementación, se ha de establecer lo siguiente:
 Producción de un Catálogo de Servicios

 Gestión de Expectativas
 Planificación de la Estructura de SLA
 Establecimiento de los Requerimientos de Nivel de Servicio y Edición de
los SLAs
 Elección del texto y los términos de los SLA
 Búsqueda de acuerdos
 Establecimiento de las Capacidades de Monitorización
 Revisión de los Contratos Subyacentes y Acuerdos de Nivel Operacional
 Definición de los Procesos de Revisión e Informes
 Anuncio de la existencia de SLAs
Gestionar el proceso continuado
En esta fase, se ha de dirigir lo siguiente de forma estructurada:
 Monitorización e Informes
 Reuniones de Revisión de Servicios Ad-hoc
Revisión Periódica
En esta fase, se ha de dirigir lo siguiente de forma estructurada:

91
 Reuniones de revisión de servicio periódicas

 Creación de programas de mejora de servicio (SIP)
 Mantenimiento de SLA, contratos y OLA
Contratos y Acuerdos
Contratos de soporte y OLA’s se deben desarrollar para permitir alcanzar los

objetivos de los SLAs. Los proveedores internos normalmente estarán
proporcionando servicios de alojamiento y varias formas de soporte técnico. Si
es necesario, puede que haga falta modificar los SLAs para alinearlos con los
contratos existentes pero es preferible renegociar el contrato. Las ventajas
claras surgen de alinear con la organización responsable de la dirección de
contratación de proveedores con la dirección de SLAs.
Un Acuerdo de Nivel Operacional es una conformidad con un otro

departamento de IT interno en el que se determinan acuerdos sobre el
mantenimiento de ciertos componentes de un servicio, por ejemplo un SPA
sobre la disponibilidad de la red o la disponibilidad de los servidores de
impresión. Un SPA sirve de soporte para la organización de IT que entrega el
servicio.
Un Contrato Subyacente es un contrato con un proveedor externo en el que se

determinan los acuerdos del mantenimiento de ciertos componentes de un
servicio. Esto es comparable con un rendimiento externo de un SPA con el
objetivo de, por ejemplo, alcanzar un acuerdo con un proveedor externo
sobre la exterminación de problemas técnicos en puestos de trabajo o sobre la
disponibilidad de una conexión permanente.
Programa de Calidad
El proceso de Gestión 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 subyacente que impacta de modo

adverso en la calidad de servicio, El Director de Nivel de Servicio debe, en
conjunción con la Gestión de Problemas y Disponibilidad, instigar un SIP para
identificar e implementar las acciones necesarias para sobrellevar las
dificultades y restaurar la calidad de servicio. Las iniciativas de SIP también
pueden centrarse en asuntos tales como formación del usuario, pruebas
(testing) de sistemas y documentación. En estos casos, las personas relevantes
se deben implicar y el feed-back adecuado se debe proporcionar para hacer
mejoras en el futuro.
En cualquier momento, un número de iniciativas separadas que forman parte

del SIP pueden ir en paralelo para afrontar las dificultades con un número de
servicios.
91
92
Elementos de un Acuerdo de Nivel de Servicio
Los Acuerdos de Nivel de Servicio son conformidades en las que se determinan

los acuerdos entre la organización de IT y el cliente sobre los servicios que se
deben entregar. El Acuerdo de Nivel de Servicio describe el servicio en
términos no técnicos y sintoniza con el mundo del cliente. El Acuerdo de Nivel
de Servicio, durante tiempos operacionales, sirve como norma para la medida
y dirección de un servicio de IT.
El rango y tono de un SLA cambiará a medida que se desarrolle la relación. Las

cláusulas deberían reflejar el hecho de que hay obligaciones tanto para el
proveedor y el cliente. Las medidas incluidas en el SLA deberían ser
significativas y se debe expresar claramente si las medidas incluidas en el SLA
representan niveles de servicio mínimos aceptables, en el peor caso,
esperados o de objetivo. Puede ser tan importante especificar qué servicios
no se proporcionan, por ejemplo, el cliente necesita saber si el servicio tiene
implícito una seguridad limitada.
Monitorizar e Informar
A fin de proteger la Gestión de Nivel de Servicio, las medidas de Nivel de

Servicio tienen que ser correctamente definidas por adelantado y tienen que
cumplir con los valores objetivos fijados de forma externa. Los Niveles de
Servicio tienen que medirse desde la perspectiva del cliente. Esta protección
no sólo trata de asuntos técnicos, pero también de asuntos de procedimiento;
siempre y cuando no se haya informado al cliente que el servicio se ha
restaurado, entenderá que sigue sin funcionar. Los valores objetivos internos
(técnicos) normalmente son protegidos por la Gestión de Disponibilidad y
Gestión de Capacidad y para algunas áreas de atención por procesos del
Conjunto de Soporte de Servicio (específicamente Gestión de Incidencia). Sin
embargo, la medida de valores internos no es suficiente ya que, con eso, se
sigue sin haber establecido un nexo con la experiencia del usuario. También
datos como tiempos de reacción, tiempos de escalada y soporte se deben
volver mensurables. A fin de recibir una visión completa, la información de
gestión de tanto los sistemas como de la Gestión de Servicio deben ser
combinados.
Los informes de Gestión se deben producir de forma regular. En los informes

de gestión se hace una comparación de los Logros de Nivel de Servicio y los
valores medidos realmente. Ejemplos de un informe sobre:
 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 transacción durante las horas punta
 El número de errores funcionales en el servicio de IT
93
 Frecuencia y duración de la degradación, cuando los servicios rinden

por debajo de un nivel determinado.
 El número medio de usuarios en horas punta de carga de trabajo
 El número de intentos con o sin éxito de evitar seguridad
Los informes de gestión pueden contener al margen de esto, valores de

medida centrados en los niveles de soporte actualizados y los desarrollos de
tendencias, tales como:
 El número de SLA’s acabados

 El número de veces que no se alcanzó un SLA
 Los costes de protección y medida de los SLA
 La satisfacción del cliente al realizar encuestas y registros de quejas
 Estadísticas de incidencias, problemas y ajustes
93
95
95
96
97
97
98
Tareas
 Trabajar, en un nivel apropiado, con representaciones de la gestión de la

organización y del Departamento Financiero, para el desarrollo de las
políticas del Presupuesto, la Contabilidad IT y los Cobros.
 Implementar y mantener los procesos de la Gestión Financiera IT,
cubriendo los presupuestos, la Contabilidad IT y los Cobros.
 Asistir en el desarrollo de los planes contables y casos de inversión para la
organización IT y sus clientes.
Responsabilidades
Presupuestos:
 Gestionar el presupuesto de la organización IT

 Preparar las previsiones del presupuesto y asistir a los clientes en la
preparación de los elementos IT en sus presupuestos
 Reportar regularmente a los directivos de IT y a los clientes lo realizado,
de acuerdo con el presupuesto
Contabilidad IT
 Seleccionar las herramientas y los procesos más apropiados para obtener el

coste de la información.
 Desarrollar los modelos de costes apropiados
 Acordar las políticas de Contabilidad IT más apropiadas (ej. Depreciación)
 Asistir en el desarrollo de los casos coste-beneficio para las inversiones IT
 Avisar a los directivos del coste-efectividad de las soluciones IT
Cobros
 Identificar los métodos de cobros de acuerdo con las políticas de cobros de

la organización
 Proveer de justificaciones y comparaciones para los cobros
 Preparar regularmente facturas para los clientes
 Preparar una lista de precios para los servicios, si es necesario
Otros
 Proveer de soporte a la Gestión del Nivel del Servicio, la Gestión de la

Capacidad, y la Gestión de la Relación Empresarial, especialmente durante
el presupuesto y la planificación de las inversiones IT
99
 Recomendar la envergadura en las auditorias internas

 Asistir las auditorias externas
Habilidades claves
 Habilidades numéricas y financieras

 Habilidad para interactuar con todos los niveles de cliente y gestión de la
organización IT
 Aproximación a la documentación y las planificaciones
 Excelentes habilidades de comunicación y negociación
 Buena presencia
Conocimientos relevantes y experiencia
 Comprensión de la empresa del cliente y como IT puede afectar en la

entrega de sus productos o servicios
 Reportar la contabilidad y los datos financieros de la compañía
 Gestión de contratos o proveedores
 Principios y procesos estadísticos y analíticos
Descripción
Relaciones con otros procesos de Gestión de Servicios IT
La Gestión Financiera de los Servicios IT, interactúa con la mayoría de los

procesos que tienen dependencias y responsabilidades sobre:
 Gestión del Nivel de Servicio: El SLA especifica las expectativas del

Cliente y los obligaciones del Servicio IT. EL coste para obtener los
requerimientos del cliente puede tener un mayor impacto en la forma y
envergadura de los servicios, que lo que se ha acordado. La Gestión
Financiera IT se enlaza con la Gestión del Nivel de Servicio en los costes
para obtener demandas de negocio actuales y nuevas, las políticas de
costes en una organización, sus efectos en el cliente y como las políticas
tienden a influenciar los comportamientos del cliente y del usuario.
Cuanto más permita el SLA a los Clientes solicitar variaciones en los
niveles de servicio, mayor será la envergadura de los Cobros para los
Servicios IT, pero también serán mayores los presupuestos, la Contabilidad
IT y los Cobros.
 Gestión de Capacidad: La información de Costes se puede utilizar para
estimar los costes deseados de Capacidad y Disponibilidad del sistema.
Para planificar la capacidad puede ser necesario estudiar los costes con el
cliente o con la organización como conjunto. La información recopilada,
de tal forma que los costes se puedan determinar, también pueden ser
99
10
relevantes para las valoraciones de la Capacidad, como por ejemplo el

esfuerzo del personal, la utilización de las máquinas.
 Gestión de Configuración: La Gestión Financiera requiere ventajas y
costes de información que pueden ser dirigidos por una organización
grande- sistema amplio. La Gestión de Configuración es responsable de
gestionar la información relacionada con las ventajas (Elementos de
Configuración CIs) y sus atributos (ej. Costes).
Impacto en la organización
Los cambios en el presupuesto y la Contabilidad IT la introducción de Cobros

para los Servicios IT son decisiones empresariales estratégicas. Pueden
impactar los niveles de servicio, percepciones del valor, y la utilidad de los
servicios. Estos también requieren una inversión en planificación y
mantenimiento de los procesos. Los jefes de las empresas deberían estar al
tanto de los cambios producidos en la organización y de la implementación de
los mismos.
Es importante que la organización reconozca los costes de introducir y

mantener el presupuesto, la contabilidad IT o los cobros, así como los
beneficios. Los beneficios propuestos deberán estar aclarados a ambos, a la
organización y a los clientes. La evaluación de estos costes y beneficios antes
de la implementación de nuevos sistemas, es esencial si los sistemas
queremos que sean fácilmente aceptados por los clientes y el personal del
Servicio IT.
Los cambios para los Servicios IT deberán ser simples, justos y precisos, y esto
a su vez requiere precisión y una eficiente Contabilidad IT. La organización
debe ser clara con sus políticas de cobros, por ejemplo sin perdidas ni
beneficios, subsistir o tener beneficios. En cualquier caso, es importante que
la organización sea consciente de los beneficios y sus caídas del sistema de
cobros propuesto.
Raramente, la Contabilidad IT se puede introducir únicamente para los

Servicios IT toda la organización debe estar preparada para contabilizar de la
misma manera el dinero gastado. Si los cobros se introducen en una
organización, donde no existe otra forma de realizar los cobros
interdepartamentales, se deberán dirigir las anomalías. Un ejemplo claro
puede ser cuando IT realiza un cargo al Departamento de Personal por la
gestión de la Base de Datos de personal, pero el Departamento de Personal no
puede cobrar a la organización IT por los servicios prestados.
Beneficios de la Gestión Financiera para los Servicios IT
El término “Cliente” se utiliza cuando nos referimos a la organización,

departamento o división que “compra” el Servicio.
10
El “Usuario” es la persona que utiliza día a día el servicio, por ejemplo un

comercial o un cliente de servicio representativo. La mayoría de los beneficios
de los que hablamos, son beneficios de la organización en conjunto, o de los
clientes de la organización IT. Los beneficios para los usuarios se perciben a
través de mejoras en el servicio, que se reflejan gracias a la utilización
eficiente de IT. El dibujo refleja como la Gestión financiera se ve como un
tirante que une IT al negocio, previniendo que la organización IT se aleje de
las necesidades del negocio, y previniendo al negocio de que pierda la pista
de las negociaciones realizadas fuera de la organización.
101
10
OPORTUNIDADES
EMPRESARIALES
EMPRESA
OPORTUNIDADES
TECNOLOGICAS GESTION
FINANCIERA
IT
Los beneficios del presupuesto, de la Contabilidad IT y de los Cobros para los

Servicios IT son los detallados a continuación:
 Mayor confidencia a la hora de realizar y gestionar los presupuestos

 Información de costes más precisa para soportar las decisiones de inversión
en IT
 Información de costes más precisa para determinar los costes de posesión
de los servicios
 Una mayor eficiencia en la utilización de los recursos IT en la organización
 Incrementa la profesionalidad del personal en la organización
Presupuestar (Budgeting)
Presupuestar es el proceso de asegurar que el dinero correcto se aparte para

la provisión de servicios de IT y que durante el periodo de presupuesto no se
gaste en exceso.
El proceso de presupuestos es una influencia clave en planes estratégicos y

tácticos. También es el medio para delegar control y monitorizar el
rendimiento contra objetivos predefinidos. Es de suma importancia que los
presupuestos estén integrados dentro de la empresa y que la responsabilidad
de la dirección y de la contabilidad se equipare y comunique de modo
eficiente.
Como todo gasto afecta a la rentabilidad, se deben reconocer las decisiones

sobre inversión en servicios de IT y la función de gestión integrada de
10
Contabilidad IT puede ayudar a proporcionar el punto competitivo necesario

para la supervivencia de una empresa.
Todas las empresas tienen una sesión anual de negociaciones entre los
departamentos de negocio y el departamento de IT cubriendo planes de
gastos y programas de inversión acordados que, en última instancia, fija el
presupuesto para IT.
Presupuestar permite a una organización

 Predecir el dinero requerido para llevar los servicios de IT durante un
periodo establecido
 Asegurar que el gasto actual se pueda comparar con la predicción de gasto
en cualquier punto
 Reducir el riesgo de gastar en exceso
 Asegurar que los ingresos estarán disponibles para cubrir el gasto previsto
(cuando la Gestión de Cobros esté establecida)
Las ventajas de Presupuestar deberían ser evidentes, pero en resumen son:
 Asegurar que el negocio proporcione fondos suficientes para llevar los

servicios de IT que requiere
 Asegurar que los Niveles de Servicio de IT se puedan mantener a lo largo
del año
 Proporcionar avisos preactivos de infra o sobre-consumo de servicios
(siempre y cuando haya alguna forma de Contabilidad de IT establecida).
Contabilidad IT
La ventaja fundamental de Contabilidad de Servicios IT (Contabilidad IT) es

que proporciona información de gestión de los costes de proporcionar
servicios de IT que soportan las necesidades del negocio. Esta información se
necesita para permitir a los directores de negocio de IT tornar decisiones que
asegurarán que la sección de Servicios de IT se lleve de manera de coste
efectivo.
La efectividad de coste se define aquí como la garantía de que hay un

equilibrio adecuado entre la calidad de servicio, por una parte, y el gasto por
la otra. Cualquier inversión que aumente los costes de provisión de servicios
IT siempre debería resultar en la mejora de la calidad o cantidad de servicio.
Contabilidad IT ayuda al negocio a:
 Basar decisiones sobre los servicios y a proporcionar en evaluaciones de

efectividad de coste, servicio a servicio.
 Tomar decisiones más formales de negocio sobre servicios de IT y las
inversiones en ellas
 Proporcionar información para justificar sus gastos
103
10
 Planear y Presupuestar con seguridad

 Demostrar sobre o infra consumo de servicio en términos financieros
En resumen, no hay perspectivas de que los proveedores de servicio

maximicen su gasto si los costes de provisión de servicios no se conocen con
precisión. Una justificación clave para la inversión en más recursos de IT es
soportar procesos nuevos o mejoras de negocio. Contabilidad IT proporciona
la base de coste para análisis de coste-beneficio.
Distintos Elementos de coste
Si se requiere más detalle para calcular costes, los Tipos de Coste principales
elegidos de Hardware, Software, Empleo, Alojamiento y Transferencia se
pueden dividir más. Por ejemplo, Hardware se puede dividir en, Oficina, Red
y Servidores Centrales. El propósito de esto es asegurar que cada coste
identificado en el departamento de IT se pueda situar en una tabla de costes,
por tipo. Esto permite que el análisis se pueda realizar por tipos, p.ej. todos
los costes de Red
La decisión de si identificar unidades de coste más detalladas a menudo

dependerá de si se requieren más detalles para dividir cobros. En general, los
Elementos de Coste serán los mismos que los artículos de línea de presupuesto
donde el propósito del modelo sea la recuperación sencilla de costes.
Si se requiere un análisis más detallado de costes, p.ej. para organizaciones

proporcionando servicios compartidos, entonces se deberán identificar
Elementos de Coste más detallados. Los Elementos de Coste típicos dentro de
cada Tipo de Coste son:
Tipo de Coste Elementos de Coste

Hardware CPUs, almacenaje de discos, periféricos, WANs,
PC’s, portátiles, servidores,...
Software Sistemas operativo, herramientas de programación,
aplicaciones, bases de datos, herramientas de
productividad personal. herramientas de
monitorización,...
Empleo Costes de nóminas, Coches de empresa, costes de
situación,...
Alojamiento Oficinas, Almacenaje, Áreas seguras,...
Transferencias Asesoramiento, Servicios de seguridad, recuperación
de Desastre, servicios externos, utilidades,...
Para organizaciones que proporcionan servicios basados en mainframes

centrales, los costes de hardware pueden ser la proporción más grande pero
es más común ver un equilibrio aproximado entre hardware, software y
empleo. Cada vez más, la proporción de costes atribuida a mecanismos y
servicios de red se hace más significativa y se puede identificar como un Tipo
de Coste separado.
10
Las organizaciones que adquieren productos software, en vez de

desarrollarlos, encontrarán una proporción más alta de costes categorizados
como Software. Por otra parte las organizaciones que utilizan servicios
externos tales como desarrollo “offshore” o servicios de computación verán
sus costes de Transferencia como su proporción más grande de costes.
Clasificación de Elementos de Coste
Costes Fijos son aquellos que no se pueden cambiar, serán los mismos incluso
cuando el servicio pare. Ejemplos son: Renta, salarios, seguros, costes de
licencias de software, gastos mínimos de utilidades, contratos de precio fijo,
mainframes, contratos de mantenimiento de hardware, depreciación.
Costes Variables siguen cambios en función de la actividad del negocio. P.ej.

horas extra (overtime), consumibles, cobros de telecomunicación, costes de
subcontratas, gastos de consumo, leasing, ... Ya que los costes variables
siguen los cambios que sufre la actividad del negocio, ha habido una
tendencia en los últimos tiempos consistente en convertir costes fijos en
costes variables.
Costes Directos son aquellos que se puede asignar a un solo departamento o

servicio como algunas aplicaciones de software, hardware dedicado, recursos
identificables, equipos dedicados de soporte.
Costes Indirectos son aquellos que no se pueden asignar a un departamento o

servicio específico pero que se tienen que dividir entre varios departamentos
y servicios. Dirección, Central, sistemas de software, recursos no
identificables, Service Desk, alojamiento, redes, depreciación y
mantenimiento. Identificar correctamente si un coste es directo o indirecto es
importante para definir presupuestos. Es fácil demostrar que un recorte de
costes directos afectará directamente la calidad del servicio entregado. Los
Costes indirectos se prestan a ser recortados en un porcentaje fijo del
presupuesto actual y es difícil demostrar cómo tal recorte afectará los
servicios. Un detalle de una encuesta reciente en Computer Finance sugiere
que muchos directores de negocio quieren que a algunos servicios de IT, tales
como el correo electrónico y los sistemas PCs se les trate como gastos de
negocio, con sólo los servicios de valor añadido tratados como costes directos.
Costes Capitales son típicamente aquellos aplicables a los bienes

(sustanciales) físicos de la organización. Tradicionalmente, esto era el
alojamiento y maquinaria necesarios para producir el producto de la empresa.
Los Costes Capitales son la adquisición o mejora importante de bienes fijos,
por ejemplo, el equipamiento informático (edificio y planta y también a
menudo se refiere a ellos como costes “de una sola vez”). Es importante
recordar que normalmente no es el coste actual de los artículos adquiridos
durante el año que se incluyen en el cálculo del coste de los servicios pero la
depreciación para el año.
105
10
Costes Operacionales son aquellos resultantes del día a día de mantener la

sección de Servicios de IT, p.ej. costes de Personal, mantenimiento de
hardware y electricidad, y relacionados a pagos repetidos cuyos efectos se
pueden medir dentro de un tiempo a corto plazo, normalmente menos de un
año financiero de doce meses.
Cobros
El beneficio fundamental para la empresa es cobrar a los clientes, ya que así

se proporciona un método seguro de equilibrar la forma y cantidad de
servicios de IT con las necesidades y recursos de los clientes. A los clientes se
les cobra por los servicios que reciben y puesto que pagan, tienen derecho a
influir las decisiones de su provisión. Si no opinan que los servicios
representan buen valor por su dinero, pueden dejar de usarlos y quejarse
formalmente pero los departamentos profesionales de IT invertirán tiempo en
discutir el balance de cargos y niveles de servicio con sus clientes.
Los servicios se pueden mejorar gastando más, si hay una justificación de

negocio para ello. La introducción formal de Cobros, a menudo proporciona
más evidencia para soportar esto y de ahí que, más empresas eligen invertir
en IT. Por el contrario, si los clientes creen que pueden ahorrar dinero (de
modo directo o indirecto, al reducir gastos de empresa generales) cambiando
su manera de utilizar los servicios de IT, podrán discutir esto más
abiertamente con el departamento de IT.
Los Cobros permiten a la dirección de Servicios de IT:
 Hacer evaluaciones formales de servicios de IT y planear inversión basados

en recuperación de costes y beneficios de negocio
 Recuperar costes de IT de una manera justa
 Influir en el comportamiento del cliente
Opciones de Cobros y Precio
Poner precios es el proceso que requiere la mayor parte del tiempo, siendo
además un ejercicio muy complejo. Se debe considerar lo siguiente:
 Cuál es el propósito de poner precio, por qué lo hacemos

 Cuáles son los costes del servicio de principio a fin (y por lo tanto, los
componentes)
 Cuáles son los precios en general (para poder marcar precios de
referencia)
 Analizar la demanda (de ese servicio) en general
 Analizar sus clientes y aquellos de la competencia
Hay un par de opciones si se habla de poner precio. Son:

10
 Precio de coste: recuperar el coste entero pero nada más

 Precio de Coste plus: Recuperar el coste pero además obtener una
ganancia
 Precios de mercado: precios que se fijan conforme a los precios del
mercado actual
La mayoría de las organizaciones tienen una política de implementación. Esta

política consiste generalmente en los siguientes pasos:
 Sin cobros (IT tratado como centro de soporte): la mayoría de las veces
utilizado como comunicación e información donde se informa a los clientes
del coste de los servicios que IT entrega. El cliente no paga por los
servicios y no lo hará.
 Cobros con noción (IT tratado como centro de coste): Esto se usa como
primer paso de la Gestión de Cobros, crea la factura y se entrega al
cliente pero no tienen que pagar (todavía). Esto da a la organización la
oportunidad de obtener más experiencia y de afinar las facturas. Y le da a
la organización la oportunidad de habituarse a cobrar. Esto a veces se
llama “soft charging” en que el dinero no cambia de manos.
 Cobros reales (IT tratado como un centro de servicio): ahora la factura
debe pagarse.
 Cobros por centros de Soporte, Coste y Servicio: se basan en el coste de
provisión de servicio.
 Los Centros de beneficio se centran en el valor del servicio de IT al
cliente.
Posibles Problemas
Hay un número de posibles problemas a la hora de implementar la

Contabilidad IT y los Cobros:
 La Contabilidad IT y los Cobros son normalmente nuevas disciplinas en los

Servicios IT, y hay un entendimiento limitado de las prácticas en
Modelización de Costes y Mecanismo de Cobros, que nos pueden llevar a
sistemas no eficientes o complejos
 La Contabilidad IT confía en la información de planificación ofrecida por
otros procesos y fuera de la Gestión de Servicios IT, que puede que no esté
disponible por rutina, produciendo el retraso del proyecto
 Es raro encontrar personal que tenga conocimientos de contabilidad y
experiencia en IT a la vez, por lo que muchas actividades necesitan ser
compartidas con personal de fuera del Servicio IT, que no tendrán esta
tarea de ayudar a IT como primordial
 Las estrategias IT y los objetivos de la organización puede que no estén
bien formuladas y documentadas, y la predicción de la Capacidad
requerida no es precisa
107
10
 Los directivos de la empresa, puede que no reconozcan los beneficios de la

Contabilidad IT y los Cobros
 La organización IT puede que no sea capaz de responder a los cambios en
las demandas de los usuarios
 Los procesos de la Contabilidad IT y los Cobros están tan elaborados que el
coste del sistema excede al valor de la información recibida
 Las herramientas de monitorización que proveen recursos de información
no precisos, irrelevantes o tienen un coste elevado para su desarrollo y
mantenimiento
10
109
11
11
111
11
Este dibujo nos muestra que la Gestión de la Capacidad está cerrada, tiene
una relación de dos direcciones con las estrategias empresariales y la
planificación de procesos, dentro de la organización. En una base regular, la
estrategia a largo plazo está encapsulada en la parte superior de los planes
empresariales. Los planes empresariales se desarrollan, desde el
entendimiento de la organización de factores externos, como la posición en el
mercado competitivo, legislación y apariencia económica, y su capacidad
interna en términos de poder, capacidad de entrega, etc.
La Gestión de la Capacidad necesita entender las estrategias empresariales a

largo plazo, mientras que proveen información de las últimas ideas,
tendencias, y tecnologías que han sido desarrolladas por los proveedores del
hardware y del software.
Los planes empresariales de la organización dictan las estrategias especificas

de IT/IS y los planes empresariales, los contenidos sobre la Gestión de
Capacidad que necesita estar familiarizado, y a que Gestión de Capacidad
necesita tener mayor número de entradas.
En los planes empresariales específicos de IT/IS, concretamente las

tecnologías, el software y el hardware son identificados junto con algunas
indicaciones de la escala de tiempos en la que no son implementados.
Funciones y Responsabilidades
Tareas
La Gestión de la Capacidad tiene sobre todo la responsabilidad de asegurar

que hay una adecuada Capacidad IT, para alcanzar los niveles de servicio y
para asegurar que los directivos de IT están avisados de cómo casar la
Capacidad con las demandas, y para asegurar también que el uso de la
Capacidad existente es la optima.
La Gestión de Capacidad es también responsable de avisar a los procesos SLM
sobre los niveles de servicio apropiados o las opciones del nivel de servicio.
Por tanto la persona o personas encargadas de este proceso tendrán que tener
capacidad para que su proceso gestione las siguientes responsabilidades del
proceso.
11
Responsabilidades
La Gestión de la Capacidad:
 Asegura que los niveles apropiados de la monitorización de recursos y la

ejecución de los sistemas son establecidos, y que la información grabada
se mantiene actualizada y utilizada por todas las partes de los procesos de
la Gestión de Capacidad
 Produce planes de Capacidad alineados con los planes empresariales
cíclicos de la organización, identificando los requerimientos de la
capacidad lo suficientemente temprano como para tener en cuenta los
tiempos de obtención
 Documenta las necesidades de cualquier incremento o decremento en
hardware basado en SLRs y costes de reserva
 Produce informes de gestión regulares, que incluyen la utilidad de los
recursos actuales, tendencias y previsiones
 Mide todos los nuevos sistemas propuestos para determinar los recursos del
ordenador y de red requeridos, para determinar la utilización del
hardware, la ejecución de los niveles de servicio y los costes implicados
 Valora la nueva tecnología y su relevancia en la organización en términos
de ejecución y costes
 Valora los nuevos productos de hardware y software para el uso de la
Gestión de Capacidad que pueden mejorar la eficiencia y efectividad de
los procesos
 Lleva a cabo la ejecución de los testeos de los nuevos sistemas
 Reporta ejecuciones frente a objetivos que contienen SLAs
 Mantiene el conocimiento de la demanda futura para los Servicio IT y
predice los efectos de la demanda en la ejecución de los niveles de
servicio
 Determina la ejecución de los niveles de servicio que son mantenidos y sus
costes son justificables
 Recomienda la afinación de los sistemas y realiza recomendaciones a la
dirección de IT en el diseño y uso de los sistemas, de forma que ayuda a
asegurar el uso optimo de todo el hardware y el sistema operacional de los
recursos del software
 Recomienda resoluciones para ejecutar – las incidencias y los problemas
relacionados
 Recomienda a la dirección IT cuando contratar la Gestión de la Demanda,
para plasmar las demandas de los clientes en el sistema
 Lleva adelante la ejecución ad-hoc y los estudios de la capacidad bajo
demanda de la gestión IT
 Asegura los requerimientos para la veracidad y disponibilidad que se llevan
a cabo en la planificación de la capacidad
 Está representada en CAB, asesorando y autorizando los cambios
 Asegura que las auditorias regulares y las ad-hoc se llevan acabo en los
procesos de la Gestión de Capacidad
113
11
Descripción
Inputs y Outputs
Los inputs
Hay un número de fuentes de información que son relevantes al proceso de

Gestión de Capacidad. Algunos de estos son los siguientes:
 Suministradores externos de nueva tecnología

 Los planes y estrategia del negocio de la organización y planes financieros
 La estrategia de IT y planes y presupuestos actuales
 Los procesos de gestión de incidencias y problemas con incidencias y
problemas relacionados con bajo rendimiento
 El proceso de gestión de nivel de servicio con detalles del contenido de los
acuerdos de niveles de servicio y requisitos de niveles de servicio, y
posiblemente de la monitorización de los SLA, revisiones de servicio e
incumplimiento de los SLA
 El proceso de gestión de cambios con un programa por adelantado de
cambios y una necesidad de evaluar todos los cambios por su impacto en la
capacidad de la infraestructura.
 El equipo de operaciones de IT con programas de todo el trabajo que
necesita hacerse e información de las dependencias entre servicios
diferentes, y las interdependencias dentro de un servicio.
Los outputs
Los outputs de Gestión de Capacidad se usan dentro de otras partes del

proceso, por otros procesos de Gestión de Servicio y por otras partes de la
organización:
 Dentro de otras partes del proceso de Gestión de Capacidad. Por

ejemplo, los datos monitorizados y recogidos como parte de Gestión de
Capacidad de Recursos y Servicio se utilizarán en la Gestión de
Capacidad de Negocio para determinar qué actualizaciones de
hardware o software son necesarias, y cuándo. La Base de Datos de
Capacidad sostendrá información necesitada por todos los subprocesos
dentro de Gestión de Capacidad.
 Por otros procesos de Gestión de Servicio. Por ejemplo, el proceso de
Gestión de Capacidad verificará nuevos Requisitos de Niveles de
Servicio y asistirá al proceso de Gestión Financiera al identificar cuándo
se necesita presupuestar dinero para actualizaciones de hardware o
software, o para la adquisición de nuevo equipamiento.
 Por otras partes de la organización. Por ejemplo, que Operaciones de
IT cuando necesite implementar cualquier cambio que la Gestión de
11
Capacidad pueda recomendar al programa de cuándo deben llevarse a

cabo servicios, para asegurar el uso más eficiente y efectivo de los
recursos disponibles. El Plan de Capacidad necesitará actuación de la
Dirección del proveedor de servicio de IT y la dirección ejecutiva de la
organización.
Actividades
La Gestión de Capacidad consiste en un número de subprocesos, dentro de los

cuales hay varias actividades. Los subprocesos de Gestión de Capacidad son:
 Gestión de Capacidad de Negocio: Este subproceso es responsable de

asegurar que se consideren, programen e implementen de modo puntual
los requisitos de negocio futuros para los servicios de IT. Esto se puede
alcanzar usando los datos existentes de la utilización de recursos actual de
varios servicios para marcar tendencias, predecir o modelar futuros
requisitos. Estos requisitos futuros vendrán de planes de negocios
marcando nuevos servicios, mejoras y crecimiento en servicios existentes,
planes de desarrollo, etc.
 Gestión de Capacidad de Servicio: El enfoque de este subproceso es la
gestión del rendimiento de los servicios de IT utilizados por los clientes. Es
responsable de asegurar que el rendimiento de todos los servicios, tal y
como se detallan en los objetivos de los SLA’s y SLR’s, es monitorizado y
medido, y que los datos recogidos son registrados, analizados e
informados. Según sea necesario, se tomará acción para asegurar que el
rendimiento de los servicios se ajuste a los requisitos de negocio. Esto se
lleva a cabo por el Personal con conocimientos de todas las áreas de la
tecnología utilizados en la entrega del servicio desde el inicio hasta el
final, y a menudo conllevará buscar el asesoramiento de especialistas
involucrados en la Gestión de Capacidad de Recursos.
 Gestión de Capacidad de Recursos: El enfoque en este subproceso es la
gestión de los componentes individuales de la infraestructura de IT. Es
responsable de asegurar que todos los componentes dentro de la
infraestructura que tienen recursos finitos son monitorizados y medidos, y
que los datos recogidos se registren, analicen e informen. Según sea
necesario, se tomará acción para gestionar los recursos disponibles para
asegurar que los servicios de IT que soportan alcanzan los requisitos de
negocio. Al realizar este trabajo, el proceso de Gestión de Capacidad será
asistido por personas especializadas en determinadas áreas de tecnología.
Cada uno de estos subprocesos realizan muchas de actividades comunes, pero

cada subproceso tiene un enfoque muy diferente: La Gestión de Capacidad de
Negocio se centra en los requisitos de negocio actuales y futuros, mientras
que la Gestión de Capacidad de Servicio se centra en la entrega de los
servicios existentes que soportan el negocio y la Gestión de Capacidad de
Recursos se centra en la tecnología que mantiene toda la provisión de
servicio.
115
11
La Gestión de Rendimiento asegura y guarda los recursos técnicos en la

infraestructura para que sean los más efectivos de coste. Se hace mediante la
monitorización, recolección de datos, análisis de tendencias y afinamiento. Se
relaciona con la Gestión de Problemas mediante monitorización porque puede
prevenir incidencias y problemas en la infraestructura.
El Plan de Capacidad proporciona un sistema de información y asegura una

programación adecuada. Depende de la Base de Datos de Gestión de
Capacidad (CDB) para generación de informes de datos técnicos de servidor y
red, detalles y predicciones de clientes, detalles y predicciones de servicios, y
volúmenes de negocio y datos financieros. Otros informes son el Plan de
Capacidad e informes de Gestión y técnicos. Pero el plan de Capacidad
también es el plan en el que se analiza la situación actual, se declaran las
necesidades esperadas de acuerdo con el cliente y el director de
disponibilidad, se describe el plan de cómo llegar a la nueva situación y se
declaran los costes esperados de acuerdo con los cambios.
Dar tamaño (Sizing) a la Aplicación
El Sizing de la Aplicación tiene una vida finita. Se inicia en la etapa de

Iniciación de Proyecto de una nueva aplicación o cuando hay un cambio serio
de una aplicación existente, y se completa cuando la aplicación se acepta en
el entorno operacional.
El objetivo primario del Sizing de la Aplicación es estimar los requisitos de

recursos para soportar el cambio propuesto de una aplicación o de una nueva
aplicación y para asegurar que alcanza los niveles de servicio requeridos. Para
conseguir esto el Sizing de Aplicación tiene que ser una parte integral del
ciclo vital de las aplicaciones.
Modelización (Modeling)
Un objetivo primario de la Gestión de Capacidad es predecir el

comportamiento de los sistemas informáticos bajo un volumen dado y
variedad de trabajo. La Modelización es una actividad que se puede utilizar de
manera beneficiosa en cualquiera de los subprocesos de Gestión de
Capacidad.
Los distintos tipos de Modelización varían desde hacer presupuestos basados

en experiencia e información de utilización de recursos actuales, hasta
estudios pilotos, prototipos y cotas de referencia de escala completa. Lo
primero es un enfoque económico y razonable de decisiones pequeñas diarias,
mientras que lo segundo es caro pero puede ser aconsejable al implementar
un nuevo proyecto. Algunas técnicas de modelización son:
11
 Análisis de tendencias
 Modelación analítica
 Modelación de Simulación
Es necesario que los modelos de línea base se usen como punto de partida.
117
11
119
12
12
121
12
ITSCM interactúa con otras disciplinas de los servicios IT como:
 La gestión de Nivel de Servicio, entendiendo las obligaciones de la entrega

del Servicio IT
 Gestión de Disponibilidad. Entregando medidas de reducción los riesgos
para mantener el negocio como siempre
 Gestión de Configuración. Definiendo el núcleo de la Infraestructura
 Gestión de la Capacidad. Asegurando que los requisitos empresariales
están completamente soportados a través de apropiados recursos de
hardware IT
 Gestión de Cambios. Asegurando Planes de Continuidad a través de
procesos establecidos, y Revisiones regulares
 Service Desk-Gestión de Incidencias Utilizando datos históricos
(estadísticas)
Proceso de Gestión de Continuidad
Etapa 1- Iniciación
Las actividades a considerar durante el proceso de iniciación dependen del

punto hasta el cual se hayan aplicado las facilidades de contingencia dentro
de la organización. Algunas partes del negocio pueden haber establecido
planes de continuidad individuales basados alrededor de workarounds
manuales e IT puede haber desarrollado planes de contingencia para sistemas
que se perciben como críticos. Esto es buen input para el proceso, sin
embargo, ITSCM efectiva depende de soportar funciones de negocio críticas y
asegurar que el presupuesto disponible se aplica de la manera más apropiada.
Etapa 2- Análisis de Requisitos y definición Estrategia
Esta etapa constituye la fundación de ITSCM y es un componente crítico a fin

de determinar cómo de bien sobrevivirá una organización una interrupción de
negocio o desastre y los costes que incurrirán.
Esta etapa se puede dividir en efecto, en dos secciones:
 Requisitos: realizar análisis de Impacto de Negocio y evaluación de riesgos.
 Estrategia: determinar y acordar medidas de reducción del riesgo y
opciones de recuperación para soportar los requisitos.
Etapa 3- Implementación
Una vez acordada la estrategia el ciclo vital de la Continuidad de Negocio se

mueve a la etapa de Implementación, involucrando a IT. La etapa de
implementación consiste en los siguientes procesos:
12
 Establecer la organización y desarrollar planes de implementación

 Implementar medidas de reducción de riesgo
 Desarrollar planes de recuperación de IT
 Desarrollar procedimientos
 Encargarse del testeo iniciales
Cada uno de los procesos arriba mencionados se considera con respecto a las
responsabilidades especificas que IT debe asumir.
Análisis de Impacto de Negocio
El encargado de determinar los requisitos de ITSCM es la probabilidad de que

un desastre o trastorno serio de servicio ocurra. Esta es una evaluación del
nivel de riesgo y del punto hasta el cual una organización es vulnerable a ese
riesgo.
Como mínimo, las siguientes actividades de evaluación de riesgo se deben

realizar:
Identificar riesgos, es decir, riesgos a componentes específicos del servicio de

IT (bienes) que soportan el proceso de negocio y, que de fallar, causarán una
interrupción de servicio. Los riesgos típicos de IT incluyen:
 daño o denegación de acceso al edificio

 pérdida de sistemas IT, redes, sistemas de Distribución de Llamada
Automática (CTIs), firewalls, sistemas criptográficos, Infraestructura de
Clave Pública (ICP/PKI), etc.
 pérdida de datos o pérdida de integridad de datos;
 pérdida de servicios de red incluidos problemas de telecomunicaciones;
 no disponibilidad de Personal clave, p.ej. sólo una persona que sabe cómo
mantener un servidor de red crítico o una aplicación de negocio y que no
exista documentación
 fallo de partners o proveedores de servicio, p.ej. organizaciones externas
proveedoras de sistemas o servicio de IT (p.ej. soporte, desarrollo,
mantenimiento);
 pérdida de servicio de un partner debido a una excesiva demanda de
servicio (p.ej. visitas o volúmenes excesivos de una página web);
 falta de seguridad (p.ej. fraude, sabotaje, viruses informáticos o software
malicioso) pérdida de elementos entorno (p.ej. aire acondicionado)
 pérdida de expedientes de papel críticos o medios (p.ej. manuales,
documentos, backups, etc.)
 pérdida de elementos estructurales de negocio básicos (p.ej. luz, gas,
agua).
Evaluar los niveles de amenaza y vulnerabilidad la amenaza se define como

“la probabilidad de que un trastorno serio ocurrirá” y la vulnerabilidad se
define como “si, y hasta qué punto, le afectará a la organización la
123
12
materialización de la amenaza”. Una amenaza depende de factores tales

como:
 Motivación, capacidad y recursos probables para recuperarse de trastornos
de servicio.
 Para trastornos accidentales de servicio, la situación de la organización,
entorno y calidad de sistemas internos y procedimientos.
 Los procesos de negocio son vulnerables cuando hay puntos singulares de
fallo para la entrega de sus servicios.
Evaluar los niveles de riesgo lo que permite medir el riesgo general.
Después del análisis de riesgo, es posible determinar contramedidas

apropiadas o medidas de reducción de riesgo (mecanismos de ITSCM) para
gestionar los riesgos, es decir, reducir el riesgo a un nivel mínimo aceptable o
mitigar el riesgo.
Gestión de Riesgo trata de la identificación y selección de acciones que

reducen los riesgos a un nivel aceptable. El Plan de Contingencia afronta el
riesgo residual, por ejemplo cuando un nuevo tipo de virus ataca PC’s.
Etapa 4- Gestión Operacional
Una vez que la implementación y previsión (planning) se han completado, hay

necesidad de asegurar qué se mantiene como parte del negocio a diario. Esto
se consigue a través de gestión operacional e incluye:
 Educación y conciencia de la organización y, en particular, del

departamento de IT, de artículos específicos de continuidad de servicio.
Esto asegurará que todo el personal esté concienciado de las implicaciones
de Continuidad de Negocio y de Continuidad de Servicio y considerará
estos como parte de su rutina de trabajo y presupuesto normal.
 Formación IT puede estar involucrado en la formación de miembros del
equipo de recuperación de negocio no-IT para asegurar que tengan el nivel
de competencia necesario para facilitar la recuperación.
 Revisión. Hace falta la revisión regular de todos los objetos entregables
del proceso de ITSCM para asegurar que se mantienen actualizados. Con
respecto a IT esto se requerirá cada vez que haya un cambio importante
en la infraestructura de IT, sus bienes o dependencias tales como sistemas
nuevos o redes o cambio de proveedores de servicio, así como cuando hay
un cambio en la dirección del negocio, estrategia de negocio o estrategia
de IT. Como las organizaciones típicamente, sufren cambios rápidos, es
necesario invertir en un programa de revisión continua e incorporar ITSCM
a los procesos de justificación de negocio de la organización. Se
implementarán nuevos requisitos de acuerdo con el proceso de control de
cambios.
 Testeo - tras el testeo inicial es necesario establecer un programa de
testeo regular para asegurar que los componentes críticos de la estrategia
se prueben. al menos anualmente o como se mande por dirección
12
ejecutiva o auditoria. Es importante que cualquier cambio a la

infraestructura de IT se incluya en la estrategia, se implemente de la
manera apropiada y se pruebe para asegurar que funcionan correctamente
dentro de la provisión general de servicios de IT.
 Control de Cambios - después de las pruebas y revisiones y en respuesta a
los cambios de día a día, hace falta actualizar los planes de ITSCM. ITSCM
se debe incluir como parte del proceso de gestión de cambio para asegurar
que cualquier cambio en la infraestructura se refleje en los acuerdos de
contingencia proporcionados por IT o terceros. Planes inexactos o
capacidades de recuperación inadecuadas pueden resultar en el fallo de
ITSCM.
 Garantía. El proceso final en el ciclo de vida de la ITSCM trata de obtener
la confianza de que la calidad de los entregables de ITSCM es aceptable a
la dirección ejecutiva y que los procesos de gestión operacionales
funcionen de forma satisfactoria.
Las Opciones
Sería difícil justificar la opción de “No hacer nada”, ya que si el sistema no se

tiene que recuperar, se debe considerar su necesidad. ¡Se tiene que informar
a los Clientes cuando se adopta esta opción!
 Workarounds, Manuales
 Los Acuerdos Recíprocos se han hecho menos populares (con menos
sistemas mantenidos en mainframe) ya que dependen de configuraciones
idénticas, procedimientos de gestión de cambio integrados y tiempo de
procesamiento compartido, que es menos práctico con sistemas on-line.
 La Recuperación Gradual es cuando reconstruimos (una parte de) la
infraestructura a partir de cero en un local que se acuerde por la
dirección. Hay un almacén o podemos alquilar uno inmediatamente y este
local se equipa con luz, teléfonos y nueve de cada diez veces con
facilidades de red. Tenemos contratos con suministradores que instalarán
hardware y software en menos de 4 días y nosotros mismos instalaremos
las aplicaciones y los datos justo después.
 La Recuperación Inmediata es cuando tenemos más locales o construimos
un segundo local. En tiempos de desastre, podemos cambiar al otro local,
a veces en segundos! Estos locales se usan mayoritariamente como locales
de prueba.
 Recuperación Intermedia es cuando no tenemos nuestro propio local pero
alquilamos capacidad y espacio de una compañía especial que asumirá
nuestros servicios.
Elegir una de estas opciones normalmente depende mucho del dinero que la
compañía se quiera gastar (con relación al impacto de negocio, etc.) Cuánto
más dinero se quiera gastar, más caras las opciones que puede tomar y más
rápido se restaurará después de cualquier incidencia.
125
12
Las siete secciones del Plan
Administración. Cuándo y cómo ejecutar el plan. Programas de acción y

Personal involucrado.
La Infraestructura de IT. Las partes de la infraestructura que estén sujetas a

gestión de continuidad. Ej: detalles de hardware, telecomunicaciones y
software que incluye el sistema de repuesto y contratos -y acuerdos de
soporte de recuperación.
Procedimientos de Operación de Gestión de Infraestructura de IT.

Instrucciones requeridas para recomenzar operaciones, incluidos detalles de
SLA y manuales.
Personal. Información sobre el Personal a transferir al establecimiento, quién

va a sustituir Personal que no vendrá al local de contingencia o, en el peor de
los casos, ha muerto. En tiempos de desastre, el Personal está más interesado
en cómo está su propia familia y propiedad que cómo está IT. Tenemos que
idear un plan para reponer Personal.
Seguridad. Detalles del establecimiento original, establecimiento de

contingencia y almacenamiento remoto.
Establecimiento de contingencia. Situación, contactos, facilidades, acuerdos
de seguridad y transporte al establecimiento, cómo construir el local, cómo
implementar infraestructura y aplicaciones, cómo restaurar datos, etc.
Vuelta a la Normalidad. Cómo, dónde, cuánto tardará en restaurarse la

infraestructura entera especialmente si no restauramos el establecimiento
entero sino sólo los servicios más importantes.
12
127
12
12
129
13
Descripción
Análisis de Riesgo
Para evaluar la vulnerabilidad de fallo dentro de la configuración y capacidad

de la organización de soporte de IT, se recomienda que el diseño propuesto de
la infraestructura de IT y la organización de soporte (proveedores internos y
externos) estén sujetos a un análisis formal de riesgo.
El riesgo es una evaluación del nivel de la amenaza y la extensión hasta la

cual una organización sea vulnerable a esa amenaza.
Como mínimo, se deben realizar las siguientes actividades de evaluación de

riesgo:
Identificar riesgos Riesgos a componentes específicos del servicio de IT

(bienes) que soportan el proceso de negocio que causarán una interrupción al
servicio. Evaluar niveles de amenaza y vulnerabilidad- la amenaza se define
como “cómo de probable es que ocurra un trastorno de servicio” y la
vulnerabilidad se define como “hasta qué punto se vería, si la organización se
viera, afectada por la materialización de la amenaza”.
Evaluar los niveles de riesgo Entonces se puede medir el riesgo total. Esto se
puede hacer como medida si se han recogido datos cuantitativos, o usando
una evaluación subjetiva de, por ejemplo, bajo, medios o altos, datos
cualitativos.
Seguridad
El objetivo de la Gestión de Seguridad es el de gestionar un nivel definido de
seguridad en un servicio, incluida la gestión de la reacción a incidentes de
seguridad. Al hacer esto, la Gestión de Seguridad puede asegurar la
continuidad y la protección del servicio y sus clientes y puede ayudar a
minimizar el daño al servicio por faltas de seguridad.
La Gestión de Seguridad tiene la intención de asegurar la salvaguarda de la

información. Más específicamente, el valor de la información se debe
proteger. Este valor se define en términos de:
 Confidencialidad: proteger información sensible de revelación no

autorizada o interceptación inteligible
 Integridad: salvaguardando la exactitud y totalidad de información y
software
 Disponibilidad: Asegurar que la información y servicios estén disponibles
cuando se requiera.
13
La función de la Gestión de Seguridad se junta con los procesos de Gestión de

Servicio de IT cuando se trata de cuestiones de seguridad. Tales cuestiones
tienen que ver con la Confidencialidad, la Integridad y Disponibilidad de los
datos, así como con la seguridad de los componentes del hardware y software,
documentación y procedimientos. Por ejemplo, la Gestión de Seguridad se
junta con la Gestión de Cambio para estimar el impacto de Cambios
propuestos en seguridad, para plantear RFCs en respuesta a problemas de
seguridad, para asegurar confidencialidad e integridad de los datos de
seguridad y para mantener la seguridad cuando se lanza software a un entorno
vivo.
El proceso de Gestión de incidencias el principal punto de encuentro para las

incidencias de segundad. Las incidencias de seguridad deben ser definidas de
acuerdo con los requisitos de seguridad de SLA que se declaran en la sección
de seguridad del SLA, para que se puedan identificar dentro del proceso de
gestión de incidencias.
Cada SLA debe tener una sección de seguridad.
Aspectos de Disponibilidad
Fiabilidad La habilidad del componente de entregar la funcionalidad deseada

durante un periodo de tiempo dado y bajo ciertas circunstancias. Pero la
fiabilidad no sólo considera la «tecnología”. También considera personas y
procesos, ya que un servicio será más fiable si la Gestión de Cambio estabiliza
el entorno controlándolo y la Gestión de Problemas consigue eliminar las
causas de raíz.
Los siguientes tres aspectos se combinan en recuperabilidad, definiendola
como la capacidad de un servicio de recuperarse.
Sostenibilidad La habilidad de un componente o servicio de volver a un

estado en el que se proporcione la funcionalidad deseada de nuevo. Aquí, nos
apoyamos mayoritariamente en procesos y personas ya que el componente
puede volver antes si tenemos un Proceso eficiente de Problemas e
Incidencias y el Personal tiene conocimientos suficientes para enmendar la
interrupción
Resistencia La habilidad de un componente o servicio de seguir funcionando

cuando uno o más componentes han fallado. La Disponibilidad siempre reduce
los componentes a series y aumenta los componentes en paralelo. Por eso, la
resistencia es la UNICA solución muchas veces cuando los clientes solicitan
una disponibilidad muy alta.
Serviciabilidad Es un término contractual utilizado para definir el soporte a

recibir de un proveedor externo en el que queda cubierto lo que se soportará
en caso de no disponibilidad de uno o más servicios.
131
13
El Ciclo Vital de la No Disponibilidad
Durante el análisis y la programación de los servicios, ciertos valores de

medida se dirigen de las fases por las que pasa un servicio debido a problemas
técnicos.
Ocurrencia de la incidencia. El usuario genera el problema técnico.

Detección. Se informa al servicio del problema técnico.
Diagnóstico. El servicio toma la acción de localizar la causa del problema
técnico.
Reparación. El servicio repara el servicio. El tiempo necesario para esto se
calcula desde el momento en el que se ha informado al servicio del problema
técnico y se puede dividir en:
Tiempo de desplazamiento (en caso de que se requiera una parte externa)
que se necesita para que llegue.
Tiempo necesario de diagnóstico y reparación.
Restauración. Tiempo que se necesita para conseguir que vuelva a funcionar
el servicio, incluidas todas las actividades de configuración e inicialización, y
el tiempo necesario para que el servicio vuelva a estar disponible para el
usuario.
El tiempo depende en parte de la velocidad de reacción de la organización de
IT y posibles proveedores externos. Para conseguir una buena perspectiva de
eso, se toman los valores medios de las medidas. Estas medias 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 más
comunes en Gestión de Disponibilidad:
 Tiempo Medio de Reparación (MTTR); el tiempo medio entre la ocurrencia

del problema técnico y su reparación, también llamado “Downtime”. El
tiempo específico es la suma del tiempo de detección y de procesamiento.
Este valor concierne la elasticidad y Serviciabilidad de un servicio. MTTR
mide la Sostenibilidad y la Serviciabilidad.
 Tiempo Medio Entre Fallos (MTBF);. el tiempo medio entre la reparación
de un incidente y el aviso del próximo incidente, también llamado
“Uptime”. Este valor concierne la fiabilidad de un servicio. MTBF mide la
Disponibilidad.
 Tiempo Medio Entre Incidencias de Sistema (MTBSI); el tiempo medio entre
el aviso de dos incidentes ocurridos secuencialmente, la suma de MTTR y
MTBF. El MTBSI mide Fiabilidad.
De la relación entre MTBF y MTBSI es posible sustraer información de si hay

muchos problemas técnicos pequeños o algunos problemas técnicos grandes.
Cuándo está Disponible un Servicio
La percepción del Cliente del downtime puede diferir de la de un

departamento de IT debido a atrasos en la información de incidencias y la
13
percepción del negocio de restauración de servicio extendiéndose al

procesamiento de cualquier atraso de negocio. Los proveedores pueden
también hablar de MTTR de forma diferente a la de un departamento interno
de IT.
También, para el cliente los puntos de entrega son en el escritorio y no dentro

del departamento lo que también resulta en una percepción diferente de la
disponibilidad entregada. IT piensa que entrega un 98% pero en realidad, en el
escritorio del cliente, sólo es un 94% por el hecho de que un servicio de
principio a final se construye sobre varios componentes y de que la
disponibilidad del servicio es por lo tanto un resultado de la disponibilidad de
todos esos componentes juntos.
Al informar al negocio de los datos de disponibilidad, deberíamos usar el

lenguaje que usa el negocio. Para el negocio, downtime significa: plantilla
perezosa, ingresos perdidos, clientes insatisfechos, amenaza de acciones
legales e incumplimiento de la legislación. Estos están claramente
relacionados con los códigos de impacto utilizados para incidencias.
Tanto la duración total del downtime y la frecuencia del downtime afectan a

la calidad del servicio.
Lo siguiente es un cálculo de ejemplo:
Servicio A tiempo de servicio acordados 5x8h/semana
En semana 43,. el servicio estuvo interrumpido 4 horas
Entonces la disponibilidad = (40-4)/40x100%= 90%
Esto parece sencillo pero, de nuevo, en realidad no lo es en absoluto. Todo

depende de lo que esté acordado, qué medimos, cómo lo medimos, cuántos
clientes medimos y cuándo medimos. Ej. si sólo uno de nuestros 1000 clientes
es interrumpido durante 4 horas entonces el servicio ¿se interrumpe en
realidad un 10% o un 0,01%? Para ese cliente único, es el 10% pero para la
compañía entera mucho menos.
Fórmula de Disponibilidad
Se puede evitar la complejidad excesiva al calcular la predicción de

disponibilidad decidiendo el grado de granularidad. El cálculo se podría
mantener al nivel de:
Disponibilidad de PC x Disponibilidad de Red x Disponibilidad del Mainframe
La disponibilidad siempre reduce los componentes en serie y aumenta los

componentes en paralelo. Sin embargo, notese que estas son predicciones a
133
13
largo plazo y no son garantías del nivel de disponibilidad que se alcanzará en

realidad. También notese que algunos componentes deben estar en serie.
Al hacer cálculos de elementos en paralelo, la disponibilidad = 100% - no-

disponibilidad. La no-disponibilidad es sólo cierta si todos los componentes en
paralelo están desglosados. Así al tener dos elementos con disponibilidad A y
disponibilidad B en paralelo, la disponibilidad del sistema se convertiría en:
100% - (A y B interrumpidos) = 100% - (100%-A x (100%-B)
Observes que la predicción de tasa de fallos cambiará a lo largo del ciclo vital
del CI.
13
135
13
13
COMO LLEGAR
DONDE
DONDE
COMO
VISION Y
QUEREMOS
137
QUEREMOSQUE
ESTAMOS
SABEMOS
OBJETIVOS
PROCESO
VALORACION
METRICAS DE
ESTAR?
ESTAR?
AHORA?
HEMOS
EMPRESARIALE
CAMBIO
LLEGADO?
S
13
13
Una Revisión
Una revisión basada en los procedimientos se puede usar como una manera
objetiva de valorar las efectividad de los procesos en la Gestión del Servicio
en una organización. Esta valoración debería apuntar a la identificación de
esos aspectos que están funcionando correctamente, y de este modo
determinar cuales son las mejores prácticas que están en uso actualmente, y
deberían ser retenidas, y también destacar las áreas de problemas.
Resumiendo, una revisión debería ser:
 Objetivamente valora la efectividad de los procesos de la Gestión de

Servicios
 Identifica las fuerzas y las áreas problemáticas
 Proporciona avisos de cómo realizar los procesos más efectivamente
 Proporcionan avisos de cómo rediseñar y mejorar los procesos
Los temas no relacionados con IT que pueden influenciar la ejecución de la

distribución de servicios, como gestión de personal y gestión de servicios,
pueden ser valorados por evaluaciones realizadas por los métodos de la
Gestión de Calidad Total. Tendremos que tener cuidado porque en muchos
casos, son estos factores los que tienen más efecto sobre la ejecución actual
de los procesos de Gestión de Servicios.
Algunos ejemplos sobre los temas generales que deben ser cuestionados en
una revisión son los siguientes:
 La existencia de un plan empresarial estratégico

 Como soporta el plan una planificación IT
 La extensión en la que IT soporta las necesidades de la empresa
 La alineación de IT y los planes de crecimiento empresarial
Algunos ejemplos de temas de procesos, que deberían ser cuestionados en una

revisión son:
 Las actividades de cada proceso

 La organización de tareas y responsabilidades
 Líneas de comunicación entre procesos
 El control global de la Gestión de Servicios
 Descripción de la infraestructura IT
 Control sobre los cambios de la infraestructura IT
 El nivel de satisfacción de los clientes con los servicios de IT
Algunas mejoras requieren grandes cambios en los procesos actuales, dentro

de la organización y puede pasar un tiempo considerable antes de que se
puedan implementar. Donde quiera que sea posible, las “victorias rápidas”
deben ser implementadas y comunicadas, de tal forma que cualquiera pueda
139
14
ver y notar las mejoras que se están llevando acabo con respecto a la
implementación final. Utilizando la revisión pueden identificar las áreas de
“victorias rápidas”.
Las revisiones y las auto evaluaciones también pueden ayudar a determinar el

nivel de madurez de las organizaciones. Esto es importante si el objetivo es
una mejor IT y el alineamiento empresarial. La madurez del proceso es una
tema importante, pero debe ser modificado en función del conocimiento de
qué requiere la empresa y si está preparada para pagar las implementaciones
en periodos de madurez del proceso.
Directrices generales en la planificación de proyectos

La versión PRINCE2 (Entorno Controlado de proyectos IN) de la gestión de
proyectos OGC está adaptado internacionalmente, y se usa para describir una
aproximación a los proyectos dentro del contexto ITIL. Las directrices, abajo
detalladas, son coherentes con la aproximación a PRINCE2.
Características del proyecto
Un proyecto puede ser definido como:
Una organización temporal que necesita alcanzar un resultado predefinido en

un tiempo predefinido utilizando recursos predefinidos.
Una “ organización temporal” significa que un proyecto tiene un comienzo y

un final claro, y está conducido por las actividades del día a día. Realizando
esto, la actividad del proyecto puede ser aislada del trabajo que sigue
funcionando.
PRINCE2 se concentra en la creación de un entorno de gestión apropiado para

conseguir el propósito del proyecto. Para poder conseguir esto, el proyecto
PRINCE2 requiere los siguientes puntos para existir:
 Vida útil, finita y definida para el proyecto

 Un conjunto de productos empresariales definidos y mesurables (para
alcanzar los requerimientos de calidad)
 Un conjunto de actividades para alcanzar los productos empresariales ( por
ejemplo “el hacer” del proyecto)
 Definir la cantidad de recursos
 Un proyecto de estructura organizativa, con responsabilidades definidas,
para gestionar el proyecto
Antes de comenzar el proyecto, una organización deberá tener una visión

sobre como deben de ser los resultados. Mediante la definición de los
14
términos necesarios para llevar a cabo los resultados del proyecto, es posible
aislar estas valoraciones (personal, presupuesto, ...) de las actividades del día
a día. Esto aumenta el ratio de éxito en el proyecto.
Antes de que comience un proyecto, la gestión debe tener una visión general
del proyecto y debe ser capaz de documentar:
 La definición de proyecto, explicando que necesita alcanzar el proyecto,

esto debería dar información previa, objetivos del proyecto y campo de
aplicación, y debería trazar el resultado deseado y resaltar las fuerzas del
proyecto.
 El asunto empresarial, describiendo como el resultado del proyecto deberá
soportar las necesidades empresariales y justifica su existencia- incluyendo
las razones para la selección de la aproximación.
 Las conocidas expectativas de calidad de las soluciones empresariales
 El criterio de aceptación para el resultado final
 Los riesgos conocidos
 Un plan de alto nivel identificando los roles necesarios y, si es posible,
asignándolos a los individuos, así como identificando las decisiones de
seguir adelante o no.
Caso Empresarial para el Proyecto
Los casos empresariales describen los valores del proyecto para la

organización: ¿Por qué este proyecto debe ser llevado adelante? Por
supuesto, para establecer una respuesta, el coste del proyecto y los
beneficios deben ser comparados. La dificultad de realizar esto, es que
mientras los costes son relativamente fáciles de cuantificar (personal,
presupuestos, ....), éste no es el caso de los beneficios.
Concretamente con proyectos de procesos orientados, que valoran y describen

los ingresos, es una tarea difícil. Esto tiene que ver con el hecho de que la
implementación de procesos resulta ser una provisión de servicios de mayor
calidad, niveles de servicio más elevados, y una organización más flexible;
esto no siempre proporciona resultados financieros cuantificables. Algunas
inversiones se realizan ( o incurren en costes, dependiendo del punto de vista)
sin saber claramente el beneficio, ya que no es de mucha ayuda decirle
solamente a un responsable de presupuestos que se tienen que tomar
decisiones de riesgo, para alcanzar el éxito. El caso empresarial debería
ayudar al lector a entender el valor de las inversiones en las mejoras de los
procesos de la Gestión de Servicios.
Factores críticos de éxito y posibles problemas
Para que los procesos de la Gestión de Servicios sea satisfactorio debe:
141
14
 Tener diseño, adaptado a la cultura de la organización en cuestión, pero a

su vez riguroso con su expectación de disciplina.
 Proveer de una buena compresión de los requerimientos del cliente, las
actividades de la empresa, y entregar servicios dirigidos al negocio en
lugar de dirigidos hacia la tecnología.
 Realzar la satisfacción del cliente
 Mejorar el valor del dinero, la utilización de recursos, y la calidad del
servicio
 Entregar una infraestructura para las operaciones controladas del servicio
puesto en marcha mediante procesos disciplinados y formalizados
 Fijar al equipo unas metas y darles a entender las necesidades del cliente
Por otro lado, nos podemos encontrar con los siguientes problemas en los
procesos de la Gestión de Servicios:
 Procesos excesivamente burocráticos, con un alto porcentaje de soporte

dedicado a la administración de la Gestión de Servicios
 Rendimiento de un equipo inconsistente para el mismo proceso, muchas
veces acompañado de una falta de compromiso por parte de las partes
responsables del equipo
 Falta de entendimiento en quien debe entregar el proceso
 No hay beneficios reales, reducciones de costes del servicio, o mejoras de
calidad que nacen de la implementación de los procesos de la Gestión de
Servicios
 Expectativas no reales, de tal forma que los objetivos son alcanzados
raramente
 Mejora no perceptible
Costes del Proyecto
Cuando se realiza un estudio empresarial para un proyecto, es importante

tener claro cuales son los costes del proyecto y cuales son los costes de
puesta en marcha de los procesos de la Gestión de Servicios. Los costes del
proyecto son costes de desembolso en una vez, mientras que los costes de
puesta en marcha están atados a un compromiso por parte de la organización,
donde se ve envueltos en contratos a largo plazo con los proveedores.
Los costes de implementación de procesos en las librerías de la

infraestructura IT, varían en función de la escala de operaciones. Los costes
asociados con la implementación y la puesta en marcha de los procesos están
vagamente categorizados como describimos a continuación:
 Costes de Gestión de proyectos

 Costes de entrega de proyectos ( facturas de consultaría, equipo de
proyectos para la implementación, dueño de procesos)
 Equipamiento y software
14
 Costes de los cursos ( incluyendo conocimientos, cursos de herramientas

especificas, y cursos de conocimientos empresariales)
 Costes de documentación
 Equipo de puesta en marcha del proyecto, y costes de acomodamiento
( para la puesta en marcha de los procesos, incluyendo las consecuentes
necesidades de aprendizaje)
Los costes de fallo para proveer de procesos efectivos son considerables.
La Organización
Un proyecto necesita ser gestionado, igual de bien que si se fuese a crear

algo, con objeto de obtener el resultado fijado. La gestión de un proyecto se
necesita tenerlo en cuenta desde los tres puntos de vista mencionados a
continuación:
 Empresa: Es realmente el soporte una necesidad real para el negocio?

 Usuario: Mientras se está utilizando el producto, llegaremos al objetivo
que el usuario quiere?
 Proveedor/Técnicos: Se puede crear el producto (bajo las necesidades
demandadas)? Se puede dar soporte al producto mientras está en
funcionamiento?
Un proyecto necesita ser estudiado bajo estos tres puntos de vista, si alcanza
un resultado viable que encaje dentro de los objetivos de la empresa, y que
también sea viable en tiempo y coste.
Normalmente los gerentes experimentados proveen la dirección a tomar en

estas tres áreas, pero desean liberarse de la actividad rutinaria que conlleva
la gestión de este proyecto. PRINCE2 identifica un gabinete de proyecto para
cubrir estos tres intereses, y provee de la dirección a tomar y avisa al jefe de
proyecto, sin necesidad de que esté involucrado en las actividades del día a
día.
El gabinete de proyecto, responsable de asegurar que los resultados de

proyecto y de asegurar las garantías de calidad, deben trabajar en el proyecto
de una manera adecuada. Esta actividad necesita separarse del jefe de
proyecto, para asegurar que el gabinete llega a una respuesta objetiva a la
siguiente pregunta: Las cosas están funcionando tan bien como nos habían
comentado?
En un proceso de la Gestión de Servicios – implementación y mejora del

proyecto, los tres puntos de vista comentados deben ser representados por:
 Un ejecutivo de la empresa: representa los intereses de la organización

(al cliente), donde se el proyecto se está realizando
 El usuario
143
14
 El proveedor
Productos
Muchos de los métodos de la gestión de proyectos tienen una aproximación al

producto. La ventaja es que los productos pueden ser descritos incluso antes
de que el proyecto comience. De esta manera, el comienzo del proyecto se
puede garantizar, mediante el establecimiento de normas para que los
productos sean entregados.
El principio de la planificación de los productos presupone la buena

descripción del producto y su gestión.
Planificación
Después de haber definido los resultados en términos del producto, el jefe del
proyecto debe trabajar sobre los productos que deben ser creados para
obtener el objetivo final. Una visión clara de las actividades se puede crear
para aquellos productos que se necesitan a corto plazo (normalmente entre
tres o seis meses) con una visión de lo que es necesario a largo plazo.
El jefe de proyecto sin dejar de preocuparse por el proyecto final, realiza un

plan detallado de la actividad a corto plazo. En esta etapa del proyecto, los
recursos pueden asignarse a las actividades para crear los productos a corto
plazo y los requerimientos técnicos a largo plazo también deben ser
valorados.
Mientras se acepta que la efectividad de la planificación y gestión del

proyecto son esenciales para el éxito del mismo, muchos proyectos IT siguen
siendo pobres en la planificación y están mal gestionados. Normalmente, a las
personas no les gusta recordar una vez que la inversión ya se ha realizado. La
frase: “ Ya hemos invertido fuertemente en este proyecto, no podemos parar
ahora!” , se ha utilizado más de una vez en la mayoría de las organizaciones.
Algunas veces los costes pierden el control, y esta es una razón de
insatisfacción, y suele conllevar la posterior cancelación del proyecto, lo cual
debería haberse decidido antes. Para evitar esta situación de fracaso en un
proyecto que ya se había puesto en marcha, un jefe de proyecto
experimentado debe decidir si siguen adelante con el proyecto o no, en estos
momentos del proyecto.
Esto significa que antes del comienzo de un proyecto, puede suceder que
nunca se termine. Realmente, con los momentos de decisión de seguir
adelante o parar el proyecto, el caso empresarial del proyecto debe de ser re-
evaluado. En PRINCE2 estas decisiones no se tienen que tomar nunca de esa
forma, ya que los progresos de proyecto son valorados día a día, y la
viabilidad de la puesta en marcha para el futuro del caso empresarial (el
proyecto), es revisado antes de comenzar la siguiente fase.
14
Plan de Comunicación
El cambio de gestión únicamente puede tener éxito mediante el correcto uso

de la comunicación. Un proyecto de Gestión de Servicios involucra a mucha
gente, pero la puesta en marcha afectará la vida de muchas más personas. La
implementación o mejora de la Gestión de Servicio dentro de una
organización, requiere un cambio del entendimiento por la dirección de IT, y
sus empleados, así como los clientes IT y los usuarios. La comunicación dentro
de esta transformación es esencial para el éxito.
Con objeto de enfatizar que todas las partes deben estar al tanto de lo que
está sucediendo y debido a que pueden ocupar una parte relevante en el
proyecto, se avisa de cómo el proyecto deberá comunicarse con todas las
partes involucradas. Un plan bien organizado y un buen plan de
comunicación, realizará una contribución positiva y directa sobre el éxito del
proyecto.
Un buen plan de comunicación debe ser construido bajo el concepto de qué es

la comunicación. La comunicación es algo más que una única forma de
información. Requiere una atención continua a las señales, tanto positivas
como negativas, de todas las partes involucradas. La gestión de la
comunicación está involucrada en estos nueve pasos:
 Descripción de los procesos de comunicación en el proceso de cambio

desde el comienzo
 Analiza la estructura de la comunicación y la cultura
 Identifica los grupos objeto que son importantes
 Valora las metas de la comunicación para cada grupo objeto
 Formula la estrategia de comunicación para cada grupo objeto
 Elige el medio de comunicación correcto para cada grupo objeto
 Escribe un plan de comunicación
 Comunica
 Y lo mide y lo redirecciona si es necesario
Un plan de comunicación describe como los grupos objeto, los contenidos y el

medio están conectados en un espacio temporal. Los planes de comunicación,
así como los planes de proyecto, nos muestran cómo las acciones, la gente,
los propósitos y los presupuestos están distribuidos en el proceso de
comunicación.
Revisión del proyecto e informes a la dirección

Cuando un proyecto ya está creado es importante que consideremos las
necesidades de creación de informes. La gestión de proyectos se debe
considerar para asegurar que se toman las decisiones apropiadas. Mientras
145
14
ejercitamos el control sobre un proyecto, es posible demostrar los siguientes

puntos:
 Que está produciendo los resultados requeridos, que alcanzan los criterios
de calidad predefinidos
 Se está llevando adelante para planificar y de acuerdo con los recursos
acordados previamente y los planes de costes
 Se mantiene viable con respecto al caso empresarial (balance de
beneficios vs costes/ riesgos)
Para soportar la decisión sobre la realización de los procesos, las

organizaciones deben prever un número de informes a lo largo de la vida del
proyecto. Como mínimo un proyecto debe cumplir los siguientes requisitos:
 informes de procesos regularmente

 Evaluación tras realizar el proyecto (la manera en la que se realizó el
proyecto)
 Repaso del proyecto realizado para valorar si los beneficios esperados han
sido materializados
A parte de la necesidad de evaluar el proyecto, es esencial mantener la

documentación que permite que el proyecto sea auditado. La auditoria
muestra conformidad y eficacia, y también nos muestra las mejoras que se
han llevado a cabo, así como las mejoras que quedan pendientes de realizar.
Una vez finalizado el proyecto, la dirección exigirá informes regulares para

demostrar lo bien que funcionan los procesos de Gestión de Servicios, que
soportan las necesidades del negocio.
Informe de Progreso
Los progresos y los planes deben ser valorados sobre una base regular, de tal
forma que los problemas puedan ser identificados pronto y puedan ser
tratados de manera oportuna. El jefe de proyecto se debe asegurar, de que
los informes de progreso se realicen en los intervalos de tiempo acordados,
para entregárselos al gabinete del proyecto.
Estos informes deberán incluir las siguientes afirmaciones:
 Logros en el periodo actual

 Los logros esperados en el próximo periodo
 Problemas actuales o potenciales, y sugerencias para su prevención o
resolución
Los informes de progreso deben mostrar un boceto claro del estado de

proyecto, con respecto a los planes y el caso empresarial, de tal forma que las
decisiones informadas adecuadamente, puedan llevarse a cabo, así como si se
14
continua o no consumiendo recursos en el proyecto. Es importante estudiar

los riesgos, de cualquier cambio que se realiza en el periodo actual, y si se
considera necesario, identificar su impacto en las actividades del proyecto.
Si surge un problema entre los informes de progreso, que un jefe de proyecto,

no está autorizado a resolver, entonces se debe compilar un informe interno
para el gabinete del proyecto, sin esperar al próximo informe de progreso.
Gracias a este informe mencionado, el jefe de proyecto informa sobre la
naturaleza y la envergadura del problema que ha surgido, identifica las
posibles opciones para su resolución, y recomienda una forma de acción.
Evaluación del proyecto
Mientras el proyecto llega a su fin, es importante analizar como ha sido

gestionado el proyecto, e identificar las lecciones aprendidas durante su
creación. Esta información se puede utilizar para beneficiar al equipo del
proyecto, así como a la totalidad de la organización. Un informe típico de un
proyecto finalizado debe mostrar los siguientes puntos:
 Logros de los objetivos del proyecto

 La realización con respecto a lo planeado (tiempo estimado y costes vs los
actuales)
 El efecto en el plan original y el caso empresarial frente al tiempo del
proyecto
 Estadísticas de los temas realizados y los cambios realizados
 El impacto total de los cambios aprobados
 Lecciones aprendidas
 Un plan de revisión, tras haber finalizado el proyecto
Revisión post-proyecto
El caso empresarial debe haber sido creado desde la premisa que la

realización del proyecto, debe dar beneficios a la empresa a lo largo de un
periodo de tiempo. De este modo, la entrega de las necesidades de los
beneficios debe ser valorado hasta después de haber puesto en uso los
productos del proyecto. La revisión del post- proyecto se utiliza para valorar
si los beneficios esperados se ven, así como para investigar si los problemas
han aparecido desde que se ha utilizado el producto.
Cada uno de los beneficios mencionados en el caso empresarial deben ser

valorados para ver que se han obtenido. Otros temas que debemos considerar,
es si hay beneficios adicionales o problemas no esperados. Ambos pueden
utilizarse para mejorar el futuro de los casos empresariales.
Si es necesario, las acciones se deben identificar para mejorar la situación

que existe.
147
14
Auditoría para la conformidad utlizando los parámetros de

calidad
Los parámetros de calidad de procesos se pueden comparar con “un

termómetro operacional” de las organizaciones IT. Utilizando estos
parámetros, es posible determinar si la organización IT es efectiva y eficiente.
Los parámetros de calidad que necesitan ser cuantificados para circunstancias
puntuales. No obstante, esta tarea es más sencilla una vez que se han
determinado los niveles de servicio requeridos y los requerimientos de servicio
interno. Hay dos tipos de parámetros de calidad, el proceso especifico y el
genérico.
Los parámetros genéricos para la Gestión de Servicio IT
Los parámetros genéricos que necesitan ser considerados incluyen:
 La satisfacción del cliente

 Satisfacción del equipo
 Eficacia
 Efectividad
Se debe recabar la información apropiada para valorar la ejecución de la

organización según estos parámetros. La naturaleza de la información
requerida puede variar dependiendo de cómo se decida juzgar cada aspecto,
pero la información que es requerida debe ser pensada claramente a lo largo
del comienzo del proyecto, de tal forma que pueda se medida a lo largo de la
revisión post proyecto.
Auditando para la mejora de uso de los indicadores de

ejecución
Introducción a la “SCORECARD equilibrada”
La “Scorecard” (tarjeta de puntuación) equilibrada es una ayuda para la

gestión de la ejecución organizacional. Sirve de ayuda, no solo en los
objetivos financieros sino también en los procesos internos, los clientes, el
aprendizaje y el crecimiento de los temas.
Las cuatro perspectivas están enfocadas alrededor de las siguientes

preguntas:
1. Clientes: ¿ Qué es lo que nuestros clientes desean?

14
2. Procesos internos: ¿ Cómo generamos el valor añadido para nuestro

cliente?
3. Aprendizaje y crecimiento: ¿ Cómo garantizamos que mantendremos el
valor añadido en el futuro?
4. Financiero: ¿ Cómo realizamos la financiación?
Como podemos ver, las primeras tres preguntas están enfocadas hacia un
futuro, y la última pregunta revisa lo que sucedió anteriormente. A
continuación hablaremos sobre la “Scorecard” equilibrada:
 Esta no es compleja, pero sin embargo si es complejo implementarla

satisfactoriamente. En la práctica, a una organización le puede llevar
alrededor de tres años para ver los beneficios de la “Scorecard”
equilibrada
 La “Scorecard” equilibrada no es una característica exclusiva de IT.
Muchas organizaciones las utilizan en otros departamentos- incluso a nivel
de gabinete jurídico.
 Cuando implementamos esta tarjeta, se comienza de una forma muy
conservadora. Comienza con tres o cuatro metas para cada perspectiva.
Para realizar esto, una organización tiene que crear varias opciones, para
muchos esto es realmente difícil y consume mucho tiempo.
 La parte más difícil al utilizar esta tarjeta, no es la implementación sino la
consolidación. Normalmente, los consultores trabajan para asistir en la
introducción de la “Scorecard”. El reto es continuar midiendo, una vez que
los consultores ya no trabajan.
 El peligro es caer en la tentación de medir las técnicas prioritariamente o
no medir ninguna.
La “Scorecard” equilibrada es complementaria a ITIL. Es una manera de

medir la efectividad de la ejecución de la organización. Algunos de los puntos
importantes son:
 Perspectiva del cliente: Esta información es relevante para la mayoría de

los procesos, y particularmente, es relevante para la Gestión de los
Niveles de Servicio, cuando está documentada en los Acuerdos de los
Niveles de Servicio.
 Procesos internos: Cubren los procesos de ITIL
 Financiero: La Gestión Financiera cubre la manera en la cual los costes se
cargan a la organización del cliente
 Aprendizaje y crecimientos: Se refiere al equipo, a los cursos, y a las
inversiones en Software
Informando a la Dirección
Tras la implementación del Sistema de Gestión de Servicios, o de algunas

mejoras realizadas, se tiene que fijar un sistema regular para realizar el
informe de gestión. Deberemos considerar los siguientes informes de gestión:
149
15
 La Gestión de IT reporta que son utilizados para la planificación y control

de los servicios
 Reporta uniendo los niveles de servicios internos conseguidos, con los
niveles de servicios descritos en los acuerdos de los niveles de servicios
 Los informes de gestión de los procesos internos, que utiliza la Gestión de
Servicios para el control de procesos de alto nivel
15
151
15
15
153
15
Para asegurar el uso efectivo de las herramientas software, es necesario la

formación en dichos productos. Por tanto la previsión presupuestaria debería
realizarse en la fase de planificación del proyecto de implementación. Más
aún, la empresa contratada para la formación debe tener un portfolio
adecuado de programas de formación para cubrir las necesidades de los
usuarios, supervisores y gerentes.
15
18. Ejemplos de Herramientas de Gestión de

Servicios
Introducción
Pink Elephant, es una empresa canadiense con sede en Toronto, pero está
extendida a nivel mundial. Es a dia de hoy la empresa líder en la consultoría
de ITIL. Uno de los productos que ofrece es PinkVerify, que es el servicio de
prueba de herramientas basadas en ITIL para ver cuales de ellas se ajustan a
las propuestas de ITIL, en qué grado y si son dignas de obtener algún
certificado de PinkVerify en alguno de los procesos, en que se basan las
mejores prácticas de ITIL.
http://www.pinkelephant.com/
En el sitio web de Pink Elephant mantienen una lista actualizada de los
principales productos de gestión de servicios con sus certificaciones.
155
15
15
157
15
OGD SOFTWARE- TOP DESK
TOPDESK es una solución de Service Desk, que ha sido desarrollada por OGD.
OGD Software es una compañía mediana con trabajadores que están siempre
dispuestos a ayudarte a trabajar con TOPDESK. OGD software y su TOPDESK
están especializados en la estructuración y registro de procesos.
Miles de profesionales IT trabajan diariamente con TOTAL TOPDESK en más de

1100 compañías. La aplicación básica del TOTAL TOPDESK soporta los procesos
de ITIL de la gestión de incidencias, de gestión de configuración y de niveles
de acuerdos de servicios. La aplicación tiene una estructura modular ,
permitiendo amoldar el software a cada necesidad. Proveen de módulos
adicionales como Gestión de problemas, Gestión de cambios, Gestión de
proyectos y un interfaz web.
TOPDESK ofrece muchas funcionalidades, así como asistentes de ayudas, 150

informes predefinidos, integracion de e-mail, gestión de localización,
inventario hardware, gestión de licencias, y gestión de valoraciones. A parte
de todos estos puntos mencionados, TOPDESK ofrece una excelente relación
calidad-precio.
El servidor de Aplicaciones TOPDESK añade un gran valor a TOPDESK. Esta

interfaz web para Total TOPDESK ofrece a los clientes e ingenieros la
oportunidad de comunicarse vía web. Los clientes son capaces de poner
llamadas de servicio, monitorizar estas llamadas y utilizar una base de
conocimiento para resolver sus propias llamadas antes de contactar con el
help desk. Esto disminuye el bloqueo de las líneas telefónicas de helpdesk.
Los ingenieros pueden acceder al servidor de aplicaciones TOPDESK para

ayudar a la realización de las tareas operacionales. La interfaz web ofrece la
posibilidad de acceder a la base de datos desde cualquier lugar o estación de
trabajo y ayudar a sus clientes inmediatamente.
TOPDESK ofrece una solución total para ayudar a soportar todos los procesos.
Gracias a esta potente herramienta es posible disminuir el número de
llamadas recibidas o cuál de los artículos de hardware debe sustituirse, siendo
estas sus principales virtudes.
Si se tiene la sensación que su compañía es muy pequeña para garantizar una

herramienta de soporte se servicio tan extensivo, deberemos echar un vistazo
TOPDESK lite. Esta aplicación esta en consonancia con la filosofía de todos los
productos TOPSDESK, que combina software fácil para el usuario con una
extensa funcionalidad.
TOPDESK lite registra todas las solicitudes de servicio recibidas. Está claro
quien atiende la llamada, cuando se debe resolver y que solución se ha
tomado. La base de datos de Gestión de Configuración está totalmente
15
integrada con los procesos de gestión de Incidencias, permitiendo trazar la

historia de la incidencia por objeto. La herramienta de Inventario TOPDESK,
TOPsis, permite escanear la infraestructura IT directamente mientras se
procesan las incidencias. El TOPdesk lite, al igual que el TOPdesk Total se
puede integrar mediante herramientas de control remoto como VNC y la
aplicación de e-mail existente.
PEREGRINE- SERVICE CENTRE/ ASSET CENTRE
Peregrine es una compañía mediana que opera en Richmond, Surrey.

Actualmente, han absorbido Remedy, y han incrementado su cuota de
mercado considerablemente. Los productos de Peregrine son centros de
servicios para gestión de incidencias, problemas y cambios, y un centro de
valoración para la gestión de configuración.
El Centro de Servicios y el Centro de Valoración de Servicios son

personalizables, lo cual permite al usuario decidir, cual es la mejor manera
para utilizar el producto. Aunque este producto no es tan fácil de manejar
como otros productos, y requiere mucha consultoría.
Ambos Centros, el de Servicios y el de la valoración de Servicios se basan en

ITIL, y trata de adaptarse a sus guiones al máximo. Esto significa que el
producto está integrado totalmente, y todos sus módulos están unidos entre
sí, con la unión entre incidencias a problemas y a su vez a los cambios.
Peregrine tiene interfaces a todas las herramientas generadoras de alertas, y

puede crear incidencias desde las mismas.
SILVERBEAR- SURVEY MANAGER
Está basado en aplicaciones web y de e-mail, que le permite tener una

Gestión de Soporte para crear y publicar informes personalizados en la
intranet, extranet o en internet. Esto permite a los departamentos de soporte
comunicarse entre ellos, de una forma rápida y directa con todos sus clientes.
Esta mejora en la comunicación, nos permite reducir el volumen de llamadas,
mejorar la percepción del valor por parte del cliente, facilidad en la
planificación por parte de la dirección y mejorar la facilidad de trabajo para
el personal de soporte.
Survey Manager puede crear informes tanto transaccionales como lineales
Los informes lineales pueden realizarse para realizar auditorías utilizando la

herramienta de segmentación, con recolección de resultados del momento
en el que se realiza en informe, para realizar análisis de ese momento o para
que aparezcan generadas automáticamente en una página web. Esta es una
manera rápida y efectiva de gestionar los informes de satisfacción del cliente,
o valoraciones “ Servicio del mejor valor” , aunque también se utiliza para
159
16
realizar simples preguntas como: “ Cuando será mejor para nosotros que
tiremos el servidor abajo para realizar el mantenimiento?”
Utilizando Survey Manager en unión con un paquete de servicios o soporte se

pueden realizar informes individuales, que se creen en función de una
transacción determinada, como una incidencia solucionada o una entrega
realizada.
Survey Manager puede también realizar respuestas a los informes e

introducirlos en la base de datos de la aplicación de soporte, que
normalmente se utiliza para direccionar el flujo de trabajo.
Por ejemplo: Una llamada se soporte se ha registrado, se ha gestionado y

resuelto, creando un “cuestionario de llamada cerrada” que debe ser enviada.
Si el receptor está de acuerdo la incidencia se cierra, y Survey Manager puede
cerrar la llamada automáticamente. Si el receptor está en desacuerdo,
entonces Survey Manager resumirá la respuesta dada, y adjudicará la llamada
que no ha sido resuelta a un supervisor o al agente de servicio de ese cliente
en concreto.
Con la arquitectura XML, Survey Manager se puede integrar fácilmente a

cualquier aplicación de soporte o incluso se puede instalar en solitario.
TOUCHPAPER- HELP DESK/ CHANGE MANAGER
Es una compañía mediana establecida en Woking, Surrey. Tienen una cuota de

mercado considerable.
Touchpaper ha lanzado una nueva versión para su producto Help Desk (versión
6), donde han realizado una mejora sustancial sobre la versión 5.
Touchpaper Help Desk tiene una buena GUI. Sin embargo a manera de
trabajar del Help Desk fuerza a que el usuario tenga que utilizar módulos
diferenciados para las distintas tareas. Si un usuario está trabajando en un
módulo de Help Desk y quiere actualizar un cambio, tiene que cambiar a un
modulo diferente. Algunos usuarios dicen que esto les lleva mucho tiempo, y
que sería mejor si el producto estuviera todo en uno.
El Help Desk tiene interfaces a todas las herramientas de alerta, y puede

generar incidencias de las alertas recibidas.
La interfaz web es clara y ordenada, y ofrece gran parte de la funcionalidad

que encontramos en el cliente.
Help Desk permite modificar desde la manera en que el usuario ve las listas
hasta el permitir al administrador añadir nuevos campos , permitiendo
adaptar el Help Desk a las necesidades y requerimientos de la organización.
16
HP-OpenView SERVICE DESK
Service Desk es una herramienta sólida. La GUI se parece mucho a Microsoft

Outlook, lo cual hace la herramienta más familiar y puede ayudar a reducir
los costes de aprendizaje. Este producto es altamente personalizable , desde
como los usuarios quieren trabajar a que campos son necesarios, a través de
la estructura de la base de datos. Un punto a tener en consideración es que el
Service Desk funciona sobre Windows NT/ 2000, HP-UX, y Solaris.
Service Desk funciona con una base de datos Oracle o Microsoft SQL server
2000, lo cual realiza el soporte para la base de datos mucho más sencilla, ya
que la mayoría de las compañías disponen de bases de datos SQL u Oracle ya
instaladas.
Service Desk soporta Gestión de Incidencias, Gestión de Problemas, Gestión

de Cambios, Gestión de Nivel de Servicios y Gestión de Configuración. Cada
uno de estos módulos son altamente personalizable con el objeto de llegar a
cada individuo y a cada organización. El módulo del Help Desk es muy
compacto, y requiere poco tiempo de implementación, debido a que ya viene
pre-configurado. La escalabilidad está controlada a través el módulo de
Gestión de Nivel de Servicios, con ramas de alertas, o ramas potenciales,
llegando al usuario mediante una gran variedad de medios: e-mail, alertas en
pantalla, páginas, mensajes de texto SMS, u otros formatos.
La Gestión de Problemas realiza un interfaz a los módulos de Help Desk, con

objeto de permitir múltiples incidencias que están asociadas a problemas, así
como permitiendo resolver problemas o causarlos.
El módulo de Gestión de Cambios está muy bien ordenado, y se puede generar

un proyecto que muestran múltiples cambios dependientes entre sí,
simplificando el seguimiento de los procesos.
Service desk tiene interfaces a HP Openview, y otros paquetes de

monitorización, BMC Patrol, … y puede generar incidencias de las alertas
recibidas de estos paquetes.
Además dispone de un interfaz web con todas las funcionalidades del cliente.
161
16
163
16
16
165
16
Restricciones de consulta: Las restricciones de consulta permiten limitar el

tipo de ítems y número de registros enviados a un usuario de Service Desk,
Evitando asi sobrecargas de la red y exceso de información para el usuario.
Éstas restricciones podrían confundir a un usuario al faltarle registros de por
ejemplo, una misma incidencia. Pero para solucionarlo la herramienta avisa
siempre que ha eliminado una serie de registros y, si el usuario posee los
permisos necesarios, podría obtener la información restante sobre la
incidencia.
Ventana de Opciones de Usuario
Informes: Service Desk , trae una potente herramienta de informes,

subconjunto de HP OpenView Reporter. Pero la integración con otras
herramientas comerciales de informes como Crystal Reports también esta
soportada. Se pueden crear informes de todos los tipos de ítems de
configuración y mostrarlos en un gran número de formas. Gráficos, tablas,
tarjetas son algunos ejemplos de informes. Además soporta la exportación de
estos informes en HTML, texto plano, Excel, ...
16
Ventana de Informes
Service Today: Service Today (Servicio para Hoy) es una vista detallada del
trabajo asignado a un determinado operador de la herramienta. Service Today
muestra todas las llamadas de servicio, incidentes, ordenes de trabajo,
problemas y cambios ( que estan todavía pendientes) que tiene asignado el
usuario. Service Desk dispone de una importante herramienta de asignación
para poder asignar a cada operador las tareas en las que está mas
especializado. Con esta herramienta además cualquier operador puede ver
quién es la persona especialista en algún campo y si hablamos de soporte de
primer nivel, estos podrán enviar la incidencia, llamada de servicio, problema
o cambio a la persona adecuado. Mejorando de esta forma sensiblemente el
rendimiento del equipo de Help Desk.
Aunque se puede pensar en Service Today como un item. No lo es. No se

pueden crear nuevos registros de item desde aquí ya que en realidad no es
más que una vista que reune los elementos de varios ítems en la misma vista
para facilitar la visión de las tareas pendientes del usuario.
167
16
Ventana de Service Today
Consola de Administrador
Para acceder a la consola de administración solo se necesita la herramienta
cliente y hacer la autenticación en la servidora con una cuenta de
administrador.
La herramienta Service Desk de administador es aparentemente idéntica a la
del cliente exceptuando la posibilidad de acceder a elementos de
configuración de la herramienta como la consola de administración, que al
cliente no se le muestran.
La consola de administración permite la configuración de la aplicación, así

como las Service Pages que son las páginas web que permiten el uso de
Service Desk.
Está dividida en dos subconjuntos:
 hp OpenView Service Desk: Datos analizados, Lógica de Negocio, Datos,

Presentación y Sistema de Seguridad
16
 Service Pages: Acceso, Datos, Presentación y Sistema.
Consola de Administrador
Configuración de HP OpenView Service Desk
Lógica de Negocio
Acciones: Mediante esta opción el administrador puede seleccionar las

acciones que se muestran en el menú acciones de los usuarios. Se configuran
las acciones en función del item: Llamada de servicio, incidente, persona,...
Existen tres tipos de acciones que se pueden configurar: Acciones de Vista

General, Smart Actions y Acciones de Sistema.
 Acciones de Vista General: definen las consultas de la base de datos. Están

pensadas para ofrecer acceso rápido a la información que se necesita
frecuentemente. Por ejemplo para mostrar las llamadas abiertas por un
determinado cliente
 Smart Actions: Como anteriormente se comentó, estas acciones estan
orientadas a la ejecución de aplicaciones externas a Service Desk. Un
ejemplo de estas acciones sería “ping CI”, es decir, hacer un ping a un
elemento de configuración para ver si tiene conectividad a la red.
Evidentemente este caso sería solo para PCs, servidores o dispositivos con
tarjeta de red.
169
17
 Acciones de Sistema: Están definidas por los desarrolladores y de esta

forma no se configuran directamente desde la consola de administración
como las anteriores acciones. Un ejemplo de estas serían el “Wizard” de
creación de un CI y la acción de Respuesta que devuelve la asignación de
un registro a quién previamente lo pasó a otro.
Aplicaciones: En este área se definen las aplicaciones que se utilizarán en las

Smart Actions. Las definición de estas aplicaciones incluyen el nombre del
usuario nominal del cliente de Service Desk, El nombre de la aplicación a
ejecutar, el directorio de la misma y la descripción. Si el nombre o ruta de la
aplicación a ejecutar son diferentes para algún usuario en particular, éste
puede modificarlos localmente.
Reglas de la base de datos: La herramienta para configurarlas es el

Gestor de Reglas. Las reglas de la base de datos se utilizan para realizar
acciones automáticas, inmediatamente o configurarlas para que se realicen en
un determinado momento, cuando se introduce, elimina o borra información
de la base de datos. Existen tres tipos de acciones que se pueden realizar:
Acción de ejecución de comando, acción de envío de un correo electrónico,
acción de actualización de información en Service Desk. La ejecución de un
comando utilizará el agente de Service Desk para iniciar el comando. Las
notificaciones tales como la aplicación de notificación “banner” de Service
Desk, se pueden lanzar mendiante reglas de la base de datos. Así mismo se
puede enviar información a un sistema de paging o SMS por poner algún
ejemplo.
Reglas de la interfaz de usuario:Se utilizan para lanzar acciones o

actualizaciones de información basadas en la actividad dentro del interfaz de
usuario.
La mayor utilidad que tienen es la aceleración de procesos con criticidad en el

tiempo. Se utilizan para ejecutar acciones cuando unos campos determinados
de la interfaz de usuarios son modificados. La acción predefinida se ejecuta
automáticamente en el formulario del usuario. La principal diferencia entre
las reglas de la Interfaz de Usuario y las reglas de la base de datos es que las
reglas de la base de datos son evaluadas en base a eventos en la base de
datos, mientras que las de interfaz de usuario se activan debidas a eventos en
el interfaz gráfico de usuario.
Se pueden realizar distintos tipos de acciones que incluyen la ejecución de

comandos, Actualización de información en la base de datos, limitar el valor
de un campo dentro de un rango, o ejecutar acciones de vista general, Smart
Actions o acciones de Sistema.
Información
17
Campos calculados: Los campos calculados son campos personalizados

disponibles para definir horarios, duración y precios en función de otros
campos o un valor relativos (de “offset”). Para usar un campo calculado se
tiene que seleccionar el tipo dentro de la lista de posibilidades, el nombre
que se desea para dicho campo, formato de salida, y valor según convenga.
Entonces este se activa.
El campo de precios es especial, ya que depende de la opción Moneda del

panel de sistema.
Lista de Comprobación: Sirve para definir lo que los usuarios de Service Desk
verán cuando seleccionen el “Wizard” de lista de comprobación para las
llamadas de servicio. Ayuda al personal de Service Desk a seguir una serie de
preguntas y respuestas para la correcta resolución del problema del cliente.
Es una utilidad de gran importancia para las llamadas de servicio,

especialmente para la plantilla de Help Desk que carezca de experiencia. La
información del “Wizard” es copiada automáticamente en el formulario del
registro de la llamada de servicio. Pueden ser de diversos tipos, que incluyen
General, de Clasificación o Servicio.
Códigos: Se basan en las Tablas de Códigos. Existen varias tablas de códigos

asociadas a cada Item como por ejemplo la tabla de códigos de llamadas de
servicio. Sin embargo algunas que se utilizan en varios Ítems, se categorizan
en un grupo General. La mayoría de las tablas de códigos son listas sencillas,
pero algunas tienen una estructura jerárquica como la Categoría de un CI.
También existen algunas tablas de códigos especiales. Localización (General),
Opción de Duración de Prioridad de Incidencia (Incident), Opción de Duración
de Prioridad de Llamada de Servicio (Llamada de Servicio), Nivel de Servicio
(Acuerdo de Nivel de Servicio).
Las tablas de códigos de Service Desk permiten extender la configurabilidad y

personalización de la aplicación para adaptarla a los procesos propios de cada
empresa. Incluye muchas tablas de códigos predefinidas que se pueden
utilizar sin necesidad de modificarlas. Sin embargo, y con intención de
adaptarlas a cada empresa se pueden modificar los valores de estado, los
códigos de cierre, las prioridades, los niveles de impacto, los niveles de
servicio, etc. Por ejemplo la tabla de códigos de impactos predefinida de
Service Desk tiene los siguientes valores Nada, Bajo (1 persona afectada),
Medio (Un Grupo afectado), Alto (Un departamento afectado), Top (Oficina o
Empresa entera afectada). Si esto no es de nuestro agrado lo podemos
modificar según convenga.
Copia de campos: Service Desk permite la copia de registros, como

anteriormente se comentó, pero en el caso de que se quieran copiar solo unos
determinados campos del registro, tenemos la opción Pegado Especial que
permite seleccionar una serie de campos dentro del formulario del registro
que son los que podemos pegar. Desde aquí configuraremos que campos de
171
17
los formularios pueden ser pegados sueltos, sin necesidad de la creación de un

nuevo registro-copia.
Campos personalizados: Service Desk proporciona muchos campos por cada

Item, pero si los procesos de nuestra empresa requieren información
adicional. Una serie de tipos de datos esta disponible en la herramienta. De
tal forma que nos permite añadir los campos que deseemos con un tipo de
datos (moneda, fecha, ...) predefinido al formulario del Item.
Es importante tener en cuenta que luego tendremos que ir a la opción de

configuración de tablas de códigos, para configurar los valores en las tablas. Y
ya podremos insertarlo en el formulario.
También existe la posibilidad de, desde aquí , eliminar los campos de los
formularios que no estimemos necesarios en nuestra organización.
Plantillas: Las plantillas se utilizan para acelerar el proceso de introducción

de datos. Se predefine el contenido de los campos de un formulario, de tal
forma que el número de campos a rellenar sea menor, con el consiguiente
aumento de rendimiento en el manejo de Ítems.
Presentación
Formularios: Service Desk proporciona una herramienta muy potente de

creación de formularios. El Diseñador de Formularios. Mediante técnicas de
arrastrar y soltar se puede crear un formulario en pocos minutos. El interfaz
de esta aplicación es similar a la utilizada en Delphi o Visual Basic.
Una vez creada la Interfaz de Usuario del Formulario solo se tendrá que
registrar el formulario y ya puede estar desde ese momento a disposición de
los usuarios.
Iconos: Desde esta opción se puede elegir el icono para los Ítems. Esto
permite una adaptación a los estándares corporativos de una empresa. Una
vez definidos se mostraran en la barra de accesos directos con el icono aquí
seleccionado.
Búsqueda: También podemos seleccionar el formato de visualización de la

información cuando se utilizan las opciones de búsqueda de Service Desk. Nos
permite seleccionar si queremos ver los resultados de la búsqueda de forma
tabular, en tarjetas, ...
Además es la utilidad que permite al administrador restringir en función de las

competencias de usuarios la muestra de determinada información. También se
pueden limitar los resultados de las búsquedas por cuestiones de rendimiento
de la base de datos, la red y la máquina cliente.
17
También se pueden seleccionar que campos de los registros pueden ser

utilizados para hacer búsquedas y cuales no. Por ejemplo: Se puede permitir
realizar búsquedas por fechas y por clientes, pero no por coste.
Barra de Accesos Directos: La barra de accesos directos se diseña con el

Diseñador de Base. Es una herramienta gráfica similar a la herramienta de
creación de formularios que permite la creación y modificación de las
categorías de las barra de accesos directos. Así como de los ítems mostrados
en la misma.
La barra de accesos directos que puede ser creada con el Diseñador de Base
no se distribuye de forma automática. La definición de la barra se encuentra
almacenada en las carpetas de repositorio de la aplicación. Se puede
distribuir enviando el fichero ShortcutBar.DAT a los usuarios y pidiendo que lo
copien en la ruta correcta. Este fichero se encuentra en el directorio \repo
del directorio raiz de Service Desk. La barra personalizada se deberá guardar
en el directorio \repo del perfil del usuario en cuestión.
Texto: Permite cambiar el texto de los siguientes elementos: El texto

utilizado en las acciones, El texto utilizado en la tabla de códigos, Los títulos
de los fomularios, las etiquetas de los campos y los botones, Mensajes de
error, Etiquetas, Títulos de las Vistas, ....
Por tanto podemos cambiar completamente el texto de todos los elementos

que conforman la aplicación. Aunque Service Desk viene distribuido en: Inglés,
Japonés, Coreano, Francés, Alemán, Español y Chino Simplificado, se podrí
mediante esta utilidad conseguir localizar la aplicación a cualquier idioma.
Aunque en la práctica muchas empresas asociadas a HP tienen los ficheros de
idiomas de la región de venta del producto, y por tanto esta herramienta se
utilizará más para la configuración de determinados mensajes o etiquetas
personalizadas.
Seguridad
Acceso: Dentro de estas opciones podremos seleccionar los roles y las cuentas
de usuario de Service Desk.
Para la selección de roles, se presenta un árbol de elementos que comienza a

nivel de Item y luego se desglosa en grupos y subgrupos hasta llegar al nombre
de un usuario. Desde aquí podremos configurar que usuarios tienen acceso a
que Ítems y que pueden realizar sobre ellos, visualizar, modificar, crear,
borrar, añadir.
Las selecciones que realicemos desde la raiz del árbol se propagan

automáticamente hacia los hijos facilitando la tarea de configuración de
permisos y roles.
173
17
Además les podemos añadir la opción de configuración de la herramienta, de

personalización barras de herramientas, vistas, acceso al navegador de
internet, etc.
Las cuentas de Service Desk se dividen en dos tipos: Usuarios Nominales y

Usuarios Concurrentes. Una cuenta de usuario Nominal permite al propietario
el acceso al cliente de Service Desk, con independencia absoluta de cuantas
personas estén conectadas al servidor. Es un tipo de cuenta que se suele
utilizar para los administradores de la herramienta o personas de soporte de
último nivel que tienen que tener garantizado el acceso a la herramienta
siempre que se precise.
Las cuentas Concurrentes permiten que se conecten usuarios simultánemente

hasta que se alcance el límite licenciado, independientemente del número de
usuarios nominales que estén conectados.
Se deben definir los roles tanto a los usuarios Nominales como a los
Concurrentes en la fase de creación de usuario.
Auditoría: Aquí tenemos la información de los servidores de aplicación que

estan activos y cuantos clientes están conectados a cada uno. Se configuran
los campos de esta vista en el fichero sd.conf
También se nos muestran las reglas de auditoría, que permiten definir que
cambios en los registros son auditados. De tal forma que luego se muestre la
cantidad de información aquí definida en la etiqueta Historia de los
Formularos.
También podemos ver desde aquí que usuarios están conectados, así com el
tiempo que llevan de conexión.
Panel de Sistema: Desde esta opción se mostrarán y configurarán las opciones

generales de seguridad de Service Desk, esta dividida en:
 Identificación después de la creación, URL desde la que se pueden

descargar las actualizaciones los usuarios, el nombre del servidor de
Service Pages, la página de bienvenida de los usuarios, etc. Es decir, desde
aquí podemos configurar la información general que se muestra a los
usuarios, así como la configuración de la pantalla de login.
 Licencias: Existen tres tipos de licencias, licencias de usuarios Nominales,
licencias de usuarios Concurrentes, licencias de Módulos. Cómo se comentó
anteriormente existen tres módulos que se pueden licenciar por separado,
siendo esta la opción que permite visualizar e introducir las licencias
pertinentes.
 Opciones Regionales: Tales como idioma, zonas horarias, símbolo de
monetario.
 Opciones de ficheros adjuntos
 Opciones de Password: límites mínimos y máximos de longitud, tipo,...
17
 E-Mail: Opciones de servidores de correo electrónico.

 Opciones de informes.
Opciones de configuración de Service Pages
Acceso: Desde aquí configuraremos las cuentas de usuario que tienen acceso
a la interfaz web de la aplicación. Notese que estas cuentas son
independientes de las cuentas nominales o concurrentes anteriormente
descritas. Existen dos tipos de cuentas de Service Pages. Usuarios Finales de
Service Pages (Cuentas SP) e Ingenieros de Soporte (Cuentas SD). Sólo estas
últimas tienen que estar incluidas en las cuentas nominales o concurrentes
anteriormente comentadas.
Plantillas de información: En esta opción podremos seleccionar a qué

plantillas tienen acceso los distintos tipos de usuario de Service Pages en
función de su rol. Es importante definir si los usuarios finales pueden abrir
incidencias directamente desde el navegador.
Opciones de vistas y vistas: Tanto para los usuarios de cuentas SP como para
los usuarios de cuentas SD, podremos definir el aspecto y el límite de la
información mostrada en las Service Pages. Por ejemplo: Un usuario final
(cuenta SP) de la gerencia puede no querer, ni necesitar tener una vista
detallada de la incidencia, mientras que un ingeniero de soporte necesita el
máximo de información disponible para resolverla.
Opciones de Contraseña: Al igual que en las cuentas de Service Desk

podremos definir las opciones de mínimo y máximo de longitud de las
contraseñas, así como el tipo, que no contengan determinados caracteres, ...
También se puede definir el período de validez de las mismas.
175
17
Arquitectura de la Aplicación
Arquitectura física en tres niveles
Service Desk posee una arquitectura física basada en tres niveles:
1. El cliente que es independiente y soporta la interfaz gráfica de

usuario java.
2. El servidor de la aplicación, que se encuentra en el nivel medio.
Puede haber más de un servidor de aplicación. La lógica de la
aplicación reside en este nivel que es el que tiene los objetos COM
3. La base de datos, que solo almacena la información. La base de
datos no contiene nada de la lógica de la aplicación.
El servidor Web, se conecta al servidor de aplicación, pero no es necesario
que se encuentren en la misma máquina.

ARQUITECTURA FISICA EN TRES NIVELES
1 CLIENTE CLIENTE JAVA SERVICE PAGES

(Microsoft) Windows 98/ NT/ 2000/ XP
Netscape 6.01/ IE 5.5 and up
TCP/IP
2 SERVIDOR DE SERVIDOR DE APLICACIÓN SERVIDOR WEB

APLICACION (Java) Apache o IIS
Windows NT/2000
TCP/ IP
3 SERVIDOR DE BASES DE
DATOS Almacén de
(Oracle, SQL, servidor) Información y
Repositorio
17
Abierto y Escalable
ABIERTO Y ESCALABLE
Cliente Java Cliente Java Cliente Java Service Pages

(Multi- hilo) (Multi- hilo) (Multi- hilo)
Cache de Datos Cache de Datos Cache de Datos
TCP/ IP
Servidor de Aplicación
(Java) Servidor
Web
Java API
Cache de Reposición
Balanceo de
Carga TCP/ IP
Event
o Almacén de ODBC
Información y
Reposición
ODBC XML Personalización Directa
Arquitectura General:
Base de Datos: Oracle (8.0.5.2.1 mínimo) o Microsoft SQL Server (7.0

mínimo)
Servidor de Aplicación: Windows NT 4.0 / Windows 2000
Cliente: Windows 98 / NT 4.0 / 2000 / XP
Elementos que lo hacen un sistema abierto:
- ODBC para acceso a nivel de tabla/campo (por ejemplo para crear informes
especiales)
- WEB API para acceso de búsqueda, lectura o escritura a nivel de objeto
- ODBC/XML para importar la información (como personas e inventarios)
- Entrada de eventos para crear, modificar o borrar Ítems (como llamadas de
servicio)
- Salida de eventos para enviar correos electrónicos o ejecución de comandos
con parámetros desde Service Desk (ejemplo smssend)
177
17
Escalabilidad:
-La comunicación entre el cliente y el servidor está comprimida para mejorar

la velocidad
-Los clientes de Service Desk tienen una cache de datos que reduce el tráfico
en la red
-Los clientes de Service Desk son multihilo (mientras realiza una búsqueda, se
puede trabajar en una llamada de servicio)
-Service Desk soporta balanceo automático de carga entre servidores de
aplicación múltiples para mejorar la velocidad y disponibilidad en el supuesto
de que uno de los servidores caiga.
Requerimientos mínimos
Servidor de Aplicación:
Pentium 700 Mhz

MS Windows NT 4.0 Server (SP6a), 2000 Advanced Server (SP1)
MS Internet Explorer 5
256 Mb RAM
80 Mb de espacio en disco
Conectividad por TCP/IP
Cliente de Service Desk:
Pentium 166 Mhz

MS Windows 98, NT 4.0 Workstation (SP6a), 2000 Professional (SP1)
MS Internet Explorer 5.5
64 Mb RAM
55 MB de espacio en disco
Conectividad por TCP/IP
Cliente de Service Pages:
Cualquier sistema que ejecute MS Internet Explorer 5.5, Netscape Navigator

6.01, o equivalente (Mozilla, Opera, ...)
Múltiples Servidores y Clientes de Aplicación

17
Se deben utilizar varios servidores de apliación cuando se tiene un número

elevado de usuarios ( > 100) o existe un uso elevado de intercambio de
información o eventos de servicios.
El balanceo de carga es posible entre varios servidores de aplicación usando la

opción itp.weight dentro del fichero de configuración de Service Desk sd.conf.
Además si no se desea que un servidor de aplicación admita a usuarios de
cliente Service Desk es posible. En este caso el servidor será utilizado
exclusivamente para el intercambio de información.
También es posible la ejecución de múltiples clientes en una misma máquina.

Se pueden tener abiertas distintas sesiones de Service Desk en la misma
máquina siempre y cuando las conexiones ser realicen a distintos servidores
de aplicación con bases de datos distintas.
Arquitectura lógica de cuatro niveles
ARQUITECTURA LÓGICA DE CUATRO NIVELES
GUI
La Capa de Flujo de
Capa de
Trabajo valida las
Presentación
peticiones de la
(1)
GUI. Puede también
residir en el Capa de Work
servidor de Flow (2)
Aplicación
REGLAS EMPRESARIALES (3)

Capa de Acceso a los datos
(4)
La capa de Reglas
de Negocio procesa
las peticiones
Base de datos
Observando el gráfico anterior podemos apreciar cuatro niveles
Esto, entre otras cosas, explica las ventajas que esta arquitectura tiene para
generar un uso bajo de tráfico en red, siendo éste uno de los objetivos
principales de la aplicación.
179
18
 El primer nivel, es el nivel de Presentación, que maneja la “inteligencia”

de la interfaz gráfica de usuario. Por ejemplo, describe que ocurre cuando
un control se mueve por la pantalla o que icono debe cambiar cuando
realizamos “drag & drop”.
 La capa de Flujo de Trabajo maneja la lógica subyacente a una acción
como las anteriores. Por ejemplo, cuando un objeto es arrastrado y
soltado en otra ubicación, la capa de Flujo de Trabajo traduce esto en el
cambio real que se produce en el objeto y comprueba si este cambio es
legal.
 Las Reglas de Negocio (contienen la lógica real de la aplicación) realizan el
cambio indicado en la capa de Flujo de Trabajo. A través del acceso a la
capa de Acceso a la Información y al final se almacena el cambio en la
base de datos
 La independencia de la base de datos se consigue utilizando una capa de
Acceso a la Información (permitiendo escribir y leer en distintos tipos de
base de datos).
Interfaces abiertos
API JAVA de Service Desk
Java SD API
Lenguaje APLICACIONES DE
SE Java TERCEROS
DESCONTINUARA!
Integración Cliente Java SD API

Capa de Work Flow
Capa del Negocio
SERVIDOR DE Capa de Acceso de

APLICACION Información
Base de Datos
API como todos sabemos se refiere a la interfaz de aplicación para

programación. La API de Service Desk permite la comunicación con cualquier
entidad de la aplicación. Esta API está escrita en Java, pero desde la versión
4.0 de Service Desk esta interfaz tiene un sucesor muy mejorado que es la
API Web
18
API WEB
El API WEB de Service Desk está disponible además del API Java. Consiste en
interfaces de Java puro a las entidades del modelo de objetos de Service
Desk. Las interfaces se pueden utilizar en cualquier plataforma que ejecute
Java. La API WEB provee de conocimiento del modelo de objetos de la
aplicación, que hace que sea sencilla de usar. Cada entidad tiene su propio
conjunto de métodos para cada uno de sus campos. También permite
manipular la información de Service Desk desde cualquier aplicación que se
conecte al servidor de aplicación de Service Desk. Está especialmente
indicado para aplicaciones web que manejen la información de Service Desk
desde el servidor web http al que se conectan los clientes. Esta interfaz
soporta interfaces distribuidos y ofrece acceso a múltiples usuarios a la vez,
además asegura la integridad de la información y conformidad con las reglas
de negocio.
181
18
Apertura de Formularios desde la Línea de Comandos
Esta característica permite abrir formularios desde la línea de comandos. Se

puede utilizar en varias integraciones, tales como CTI (Computer Telephony
Integration) donde el número de teléfono del cliente (llamante) se añade
automáticamente a la línea de comandos y un formulario de llamada de
servicio se abre con el llamante rellenado, en el momento en el que el
operador de Help Desk descuelga el teléfono.
La apertura de formularios desde la línea de comandos accede a la capa de

Flujo de Trabajo, por tanto todos los comandos creados son manejados de la
misma forma que cuando se ejecutan desde la interfaz gráfica de usuario. Las
reglas y opciones creadas en la capa de Negocio son válidas.
APERTURA DE FORMULARIOS DESDE LA LINEA DE COMANDOS
LINEA DE COMANDO
Capa de Work Flow
Capa de Negocio
Capa de Acceso a la
Información
Base de Datos
18
Intercambio de Información
El intercambio de información consiste en dos pasos:
- Exportación: Desde una aplicación de terceros a un fichero XML

- Importación: Desde un fichero XML a la base de datos de Service Desk
Se puede realizar el intercambio de información desde la interfaz gráfica de

usuario de Service Desk o desde la línea de comandos.
Service Desk ofrece intercambio predefinido entre HP OpenView Network

Node Manager, OpenView Operations, Microsoft Systems Managemente Server,
LDAP, Radia Novadigm, etc.
Eventos de Servicio
Podemos distinguir entre eventos de entrada y de salida
Eventos de servicio de entrada:
EVENTOS DE SERVICIO !
APLICACIÓN DE TERCEROS
Evento de Servicio
Interface Línea de Comandos
Servidor HTTP
Java SD API
Capa Work Flow
Capa de Negocio
Aplicación Capa de Acceso a

la Información
Servidor
Base
de
Dat
os
183
18
Ejemplos de estos son el acto de dar de alta un nuevo empleado en el

sistema de Recursos Humanos, Un fallo en un Router detectado por una
aplicación de gestión de red o el simple hecho de que un empleado este de
vacaciones en unas determinadas fechas.
Eventos de servicio de salida:
EVENTOS DE SERVICIO
Aplicación de
Terceros
Agente Service Desk
Gestión de Acciones Capa Work Flow
Capa de Negocio
Gestión de
Condiciones Gestión de Reglas
Capa de Acceso a la
Información
Aplicación Servidor
Base de Datos
En la aplicación Service Desk se pueden definir reglas para, por ejemplo, el

evento “insertar llamada de servicio”, la regla consistiría en una condición y
una acción.
Condición: Cuando el Departamento sea X y la prioriad sea Top

Acción: Avisar al Responsable del Departamento X
Por ejemplo el llamante ABC del Departamento X pone una petición con
prioridad TOP
 La capa de Flujo de Trabajo valida la petición y la capa de Negocio

introduce la petición en la capa de Acceso a la Información. A la vez, la
capa de Negocio pone la petición en la cola de eventos.
 El gestor de reglas mira en la cola de eventos y comprueba si hay
condiciones para el evento. Si los hay, maneja la petición a través del
gestor de condiciones; si no el evento se elimina,
 El gestor de condiciones determina si la condición se cumple. Si no, ignora
el evento, y si lo cumple devuelve la petición al gestor de reglas.
 El gestor de reglas envía la acción al gestor de acciones. El gestor de
acciones determina la acción adecuada y da al agente apropiado la orden
para ejecutar dicha acción.
18
Este proceso se utiliza para hacer la integración bidireccional.
Flujo de Datos en las Service Pages
FLUJOS DE DATOS EN LAS SERVICE PAGES

Red
Procesos del Servidor HTTP (Java)
Capa Work Flow (Java)
Capa de Negocio (Java) Motor XSLT
Gestión de Consulta (Java) Servidor Web
Paquete Wrapper de Java wfc.data
Red
ADO DB
Base de Datos
Service Desk
Navegador
Web del
Cliente
 El cliente del navegador Web se comunica con el Servidor Web a través de
la red.
 El Servidor Web pasa la petición de nuevo a la capa de Flujo de Trabajo y
la petición es procesada a través de las capas usuales
 Cuando la petición es procesada, la capa de Flujo de Trabajo pasa la
definición XML de nuevo al servidor Web
 El motor XSLT transforma los datos XML usando definiciones de estilo XSL
en HTML (los ficheros XSL residen en la misma máquina que el servidor
Web).
185
18
20. Glosario ITIL por orden alfabético

Termino Descripción Proceso
.AAF Ver Análisis de Árbol de Fallos Disponibilidad
.CI Ver Artículo de Configuración Configuración
.CIS Ver Artículo de Configuración de Software Difusión
.DHS Ver Almacén Definitivo de Hardware Difusión
.AIFC Análisis de Impacto de Fallos de Componentes Disponibilidad
.OLA Ver Acuerdo de Nivel Operacional SLM
.SLA Ver Acuerdo de Nivel de Servicio SLM
.CDB Ver Base de Datos de Capacidad Capacidad
.DSL Ver Biblioteca Definitiva de Software Difusión
.CMDB Ver Base de Datos de Gestión de Configuración Configuración
.ITIL La Biblioteca de Infraestructura de IT de CCTA – un Todos
conjunto de directrices de la gestión y provisión de
servicios de IT operacionales.
.CCU Ver Centro de Costes de Unidades Financiera
.CS Ver Contrato Subyacente o contrato Disponibilidad
.FGSIT Foro de Gestión de Servicios IT, Grupo de Usuarios de Todos
ITIL
.GAC Ves Gestión de Relación de Negocio CRM
.GCN / BCM Gestión de Continuidad de Negocio Continuidad
.GNS / SLM Ver Gestión de Nivel de Servicio SLM
.IPWTM Implementación de un proceso Workflow Orientado, un Todos
modelo de proceso Creado por Quint Wellington
Redwood y Dutch Telecom (KPN) Stadia Model que
describe vencimientos, cómo medirlos y cómo
realizarlos, para los distintos procesos de BITI. Ver
www.quintgroup.com para un artículo completo en
inglés.
.ISEB Información System Examination Borrad (UK), que Todos
administra y concede los premios de cualificaciones de
IT incluidos FC en Gestión de Servicio IT
.CAB Ver Junta de Asesoramiento de Cambios Cambios
.CAB / EC Ver Junta de Asesoramiento de Cambios Comité de Cambios
Emergencia
.CRAMM Método de Gestión y Análisis de Riesgo CCTA Todos
187
18
.FSC Programación Adelantada de Cambios Cambios

.SLR Ver Requisitos de Nivel de Servicio SLM
.PIR Ver Revisión Post Implementación Problemas
.RFC Ver Solicitud de Cambio Cambios
.SPOF Ver Sólo Punto de Fallo Disponibilidad
.TIC La convergencia de Tecnología de Información, Todos
Telecomunicaciones y Tecnologías de Data Networking
en una sola tecnología
.MTTR Ver Tiempo Medio de Reparación Disponibilidad
.MTBF Ver Tiempo Medio Entre Fallos Disponibilidad
.MTBSI Ver Tiempo Medio Entre Incidencias de Sistema Disponibilidad
Actividad de Una acción o serie de acciones como parte del proceso Continuidad
BCM de BCM
Acuerdo de Un acuerdo interno cubriendo la entrega de servicios, SLM
Nivel que soporta la suministración de IT en la entrega de sus
Operacional servicios.
Acuerdo de nivel Acuerdo escrito entre un proveedor de servicios y el SLM
de servicio cliente que documentan los niveles de servicio cordados
para un servicio.
Acuerdo 2 organizaciones que utilizan infraestructura compatible Continuidad
Recíproco se proporcionan una a la otra recusrsos de TI en una
emergencia
Acuerdos de Las gestiones necesarias para que haya bienes Continuidad
Standby disponibles, que se han identificado, como repuestos de
no estar disponibles los bienes primarios tras un
trastorno de negocio. Típicamente, estos incluyen
alojamiento, sistemas de IT y redes, telecomunicaciones
y a veces personas.
Administración La parte de la organización encargada de desarrollar y Todos
de IT entregar los servicios IT
Almacén El área para el almacenaje seguro de repuestos Difusión
Definitivo de definitivos de hardware. Estos son componentes de
Hardware ADH repuesto y montajes que se mantienen al mismo nivel
que los sistemas comparativos del entorno vivo.
Amenaza Un evento que podría ocurrir y que podría degradar el Disponibilidad
funcionamiento de un componente o servicio.
Amenaza Un evento que podría ocurrir y que podría degradar el Continuidad
funcionamiento de un componente o servicio.
Análisis de Árbol Técnica para analizar la disponibilidad de un sistema Disponibilidad
de Fallos
Análisis de La identificación de procesos de negocio críticos, y el Cambios
Impacto daño o pérdida potencial que puede causar a una
organización un trastorno de esos procesos. Al Análisis de
impacto de negocio identifica la forma en que tomará la
pérdida o daño, cómo es probable que escale ese grado
de pérdida o daño con el tiempo tras una incidencia; la
plantilla, facilidades y servicios mínimos necesarios para
permitir a los procesos de negocio continuar operando a
un nivel mínimo aceptable; y el tiempo dentro del cual
deberían ser recuperados. El tiempo dentro del cual se
debe alcanzar la plena recuperación de los procesos de
negocio también se identifica.
Análisis de La identificación y valoración de bienes y amenazas; la Disponibilidad
Riesgo evaluación de vulnerabilidades y riesgos considerando las
amenazas a los bienes.
Análisis de La identificación y valoración de bienes y amenazas; la Continuidad
Riesgo evaluación de vulnerabilidades y riesgos considerando las
18
amenazas a los bienes.
Análisis de Una varianza es la diferencia entre coste, programado, Financiera

Varianza presupuestado o estándar y coste actual (o ingresos).
Análisis de varianza es un análisis de los factores que han
causado la diferencia entre los estándares
predeterminados y los resultados reales. Varianzas
pueden ser desarrolladas específicamente relacionadas a
las operaciones realizadas en añadidura a las arriba
mencionadas.
Año Financiero El año financiero es el periodo contable que cubre 12 Financiera
meses consecutivos. En el sector público este año
financiero generalmente coincidirá con el año fiscal, que
va desde el 1 Abril hasta el 31 Marzo.
Artículo de Componente de una infraestructura – o un artículo, tal Configuración
Configuración como una Solicitud de Cambio, asociado con una
(CI) infraestructura – que es (o estará) bajo el control de
Gestión de Configuración. CI’s pueden variar mucho en
complejidad, tamaño y tipo- desde un sistema entero
(incluido todo el hardware, software y documentación) a
un módulo suelto o un componente de hardware menor
Artículo de Como “Artículo de Configuración” excluyendo hardware Difusión
Configuración y servicios.
de Software
(SCI)
Asíncrono / Asíncrono en el sentido de comunicaciones es la Tecnología
Síncrono habilidad de transmitir cada carácter como una unidad
auto contenida de información, sin información adicional
en el tiempo. Este método de transmisión a veces se
llama Start / Stop. Trabajar de forma síncrona conlleva
el uso de la información se hace en bloques. La
transmisión síncrona es normalmente más eficiente que
el método asíncrono.
Atributo Característica de un CI sostenida en la CMDB Configuración
Auditoria Una prueba para asegurar que una función o proceso Todos
funciona de acuerdo a las prescripciones
Auto asegurar Una decisión de soportar las pérdidas que podrían Continuidad
resultar de un trastorno al negocio opuesto a asegurar el
riesgo de forma extra
Autoridad de Un grupo al que se le da la autoridad para aprobar Cambios
Cambio Cambio, p.ej. por la junta de proyectos. A veces se
refiere a ello, como la Junta de Configuración
Base de Datos Una base de Datos que contendrá toda la información Capacidad
de Capacidad necesitada por todos los sub procesos dentro de la
CDB Gestión de capacidad
Base de Datos Una base de datos, que contiene todos los detalles Configuración
de Gestión de relevantes de cada CI y detalles de las relaciones
Configuración importantes entre CI.
(CMDB)
Biblioteca La biblioteca en la que las versiones autorizadas Difusión
Definitiva de definitivas de todos los CI de software se almacenan y
Software SDL protegen. Es una biblioteca física o repositorio donde se
sitúan copias maestras de versiones de software. Esta
área lógica puede en realidad consistir de uno o más
bibliotecas de software físicas o almacenes de archivos.
Deberían estar separados de las áreas de desarrollo y
almacén de archivos de pruebas. Las BDS también
pueden incluir un almacén físico para guardar copias
189
19
maestras de software incorporado de fuera P. ej. a

prueba de fuego. Sólo software autorizado debería ser
aceptado en la SDL, controlado de forma estricta por
Gestión de Cambio y Difusión.
La SDL existe no directamente por las necesidades del
proceso de Gestión de Configuración, pero como base
común para los procesos de Gestión de Difusión y
Gestión de Configuración.
Biblioteca de Una colección controlada de SCI diseñados para Difusión
Software mantener los de tipo y estatus similar juntos y
segregados de los distintos, para ayudar en el desarrollo,
operación y mantenimiento.
Bien Asset. Componente de un proceso de negocio. Bienes Configuración
pueden incluir personas, alojamiento, sistemas
informáticos, redes, historiales en panel, máquinas de
fax, etc.
Cambio La añadidura, modificación o eliminación de hardware Cambios
de línea base o soportado, network, software,
aplicación, entorno, sistema, construcción de desktop o
documentación asociada
Cambio Urgente Un cambio que debido a la importancia crítica para el Cambios
negocio de una Incidencia se ha de implementar con
urgencia
Canal Canal es la conexión física de la CPU a un mecanismo de Cambios
I/O, normalmente un controlador, o de hecho otro CPU
Capitalización Muchas organizaciones eligen identificar sus gastos Financiera
mayores como Capital, haya un bien sustancial o no,
para reducir el impacto en el año financiero actual de
tal gasto y a esto se refiere como Capitalización. El
artículo más común para aplicar a esto es software, sea
desarrollado de forma interna o adquirido.
Carga de Las Cargas de Trabajo dentro del contexto de Modeling Capacidad
Trabajo de Gestión de Capacidad son un conjunto de
predicciones que detallan el uso de recursos estimados a
lo largo de los horizontes de planning acordados. Las
cargas de trabajo generalmente representan
aplicaciones de negocio discretas y se pueden subdividir
más allá en tipos de trabajo (interactivo, de tiempo
compartido, lote)
Cargo Cobrar a clientes de negocio distintas tarifas por el Financiera
diferencial mismo trabajo, típicamente para bajar la demanda o
para generar rentas para capacidad obrante. Esto
también se puede utilizar para incitar a funcionamiento
off peca o de noche.
Cargo Duro Descriptivo de una situación donde, dentro de una Financiera
organización, los fondos actuales son transferidos del
cliente a la organización de IT como pago de la entrega
de servicios de IT
Catálogo de Extractos escritos de servicios de IT, niveles de defecto y SLM
Servicio opciones
Categoría Clasificación de un grupo de Artículos de Configuración, Configuración
Documentos de Cambio o problemas
Categoría Clasificación de un grupo de Artículos de Configuración, Cambios
Categoría Clasificación de un grupo de Artículos de Configuración, Incidencias
Categoría Clasificación de un grupo de Artículos de Configuración, Problemas
19
Centro de IT se gestiona como un negocio con objetivos de Financiera

Beneficio beneficio
Centro de Coste IT tiene un presupuesto y hay cobro suave de servicios Financiera
específicos; trata de un coste de inputs y outputs
Centro de Coste Un centro de coste para la provisión de servicios de Financiera
de Utilidad soporte a otros centros de coste
(CCU)
Ciclo Vital Una serie de estados, conectados por transiciones Configuración
permitidas. El ciclo vital representa un proceso de
aprobación de Artículos de Configuración, Informes de
Incidencias, Informes de Problemas y documentos de
Cambio
Ciclo Vital Una serie de estados, conectados por transiciones Cambios
Cambio
Ciclo Vital Una serie de estados, conectados por transiciones Incidencias
Cambio
Ciclo Vital Una serie de estados, conectados por transiciones Problemas
Cambio
Ciclo Vital de El conjunto completo de actividades y procesos Continuidad
BCN necesarios para gestionar la continuidad de negocio-
individuo en cuatro etapas.
Ciclo Vital de Todas las Actividades desde el momento que ocurre una Incidencias
Una Incidencia incidencia hasta el momento en el que se cierra la
incidencia
Cierre Cuando el Cliente está satisfecho de que una incidencia Incidencias
se ha resuelto
Clasificación Proceso de agrupar formalmente Artículos de Configuración
Configuración por tipo, p.ej. software, hardware,
documentación, entorno, aplicación
Clasificación Proceso de formalmente identificar incidencias, Cambios
problemas y errores conocidos por origen, síntomas y
causa
Clasificación Proceso de formalmente identificar incidencias, Incidencias
causa
Clasificación Proceso de formalmente identificar incidencias, Problemas
causa
Cliente Recipiente del servicio; normalmente la Gestión del Todos
Cliente tiene la responsabilidad del coste del servicio, o
directamente a través de cobros o indirectamente en
términos de la necesidad de negocio demostrable
Cliente El comprador (como distinto al proveedor) de servicios. SLM
Inteligente El término a menudo se usa con relación a la
externalización outsourcing del IT/IS
Cobros El proceso de establecer cobros con respecto de Financiera
unidades de negocio, y creando las estructuras
relevantes para recuperación de los clientes.
Computer Arded Una herramienta de programación de software. Todos
191
19
Systems Proporciona ayuda en el planning, análisis, diseño y

Engineering documentación de software de ordenador
Conciencia de La medida en que una organización es consciente de su Seguridad
Seguridad situación de seguridad
Construcción La etapa final de producir una configuración utilizable. Configuración
El proceso conlleva coger uno o más artículos de
Configuración de input y procesarlos (construirlos) para
crear uno o más artículos de Configuración p.ej.
compilar y cargar software
Contabilidad de Proceso que graba el estado de un AC en cualquier Configuración
Estatus momento dado
Contabilidad de El conjunto de procesos que permiten a la organización Financiera
IT de IT contabilidad completamente la manera en la que
se gasta su dinero (en particular la habilidad de
identificar costes por cliente, servicio, actividad)
Normalmente, conlleva el uso de registros y debería ser
supervisado por alguien formado en Contabilidad
Contrato Documento entre dos entidades (dos proveedores Disponibilidad
externos) con existencia legal separada
Contrato Documento entre dos entidades (dos proveedores SLM
externos) con existencia legal separada
Contrato Un contrato con un proveedor externo cubriendo la Disponibilidad
Subyacente entrega de servicios que soporta la administración de IT
en la entrega de sus servicios
Control de El procedimiento para asegurar que todos los Cambios Cambios
Cambio son controlados, incluidos la sumisión, análisis, toma de
decisiones, aprobación, implementación y post
implementación del Cambio
Control de Control de errores cubre los procesos involucrados en Problemas
Errores progresando Errores Conocidos hasta que se eliminan con
la implementación exitosa de un Cambio bajo el control
del proceso de Gestión de Cambios. El objetivo de
control de errores es ser consciente de los errores,
monitorizarlos y eliminarlos cuando sea plausible y el
coste justificable
Control de Actividades que comprenden el control de Cambios a Configuración
Configuraciones Artículos de Configuración tras establecer formalmente
sus documentos de configuración. Incluye la evaluación,
coordinación, aprobación o rechazo de Cambios. La
implementación de Cambios incluye Cambios,
desviaciones y renuncias que impactan en la
configuración
Control de El proceso de control de Problemas trata del manejo de Problemas
Problemas Problemas de manera efectiva y eficiente. El objetivo de
control de problemas es identificar la causa de raíz,
como los CI’s responsables, y proporcionar al Service
Desk de información y asesoramiento de los Workarounds
cuando se puede.
Control de El proceso de planear y regular, con el objetivo de Todos
Procesos realizar el proceso de manera efectiva y eficiente
Controlador de Los controladores de Caché de Disco tienen memoria, Tecnología
Caché de Disco que se utiliza para almacenar bloques de datos, que se
han leído de los mecanismos de disco conectados a ellos.
Si un I/O (E/S) consecutiva requiere el expediente que
está todavía residente en la memoria de caché, se
recogerá de ahí, evitando así otro I/O (E/S) físico.
Coste La cantidad de gastos (actuales o de noción) incurridos Financiera
en, o atribuibles a una actividad específica o unidad de
negocio
19
Coste Un coste que comparten un número de unidades de Financiera

Aporcionado negocio (un coste indirecto). Este coste se debe repartir
entre estas unidades de forma equiparable
Coste Asignado Un coste que se puede identificar directamente con una Financiera
unidad de negocio
Costes Capitales Típicamente aquellos aplicables a los bienes físicos Financiera
(sustanciales) de la organización. Tradicionalmente, esto
era el alojamiento y maquinaria necesaria para producir
el producto de la empresa. Costes capitales son la
adquisición o mejora importante de bienes fijos, por
ejemplo, equipamiento informático (construcción y
planta y a menudo también referidos como costes de una
sola vez)
Coste Directo Un coste, que se incurre, y que se puede localizar de Financiera
lleno a un producto, servicio, centro de coste o
departamento. Esto es un coste asignado. Costes
Directos son materiales directos, sueldos directos y
gastos directos.
Coste Entero Coste Entero es el coste total de todos los recursos Financiera
utilizados al suministrar un servicio es decir, la suma de
los costes directos de producir el output, una parte
proporcional de los costes generales y cualquier gasto de
venta y distribución. Tanto costes de efectivo y de
noción (no efectivo) deberían ser incluidos, incluyendo
el coste de capital.
Calculado como el coste total de propiedad, incluida la
depreciación / renovación prevista)
Coste Estándar Un cálculo predeterminado de cuántos costes deberían Financiera
estar bajo las condiciones de trabajo especificadas. Se
calcula de la evaluación del valor de elementos de coste
y correlaciona las especificaciones técnicas y la
cuantificación de materiales, mano de obra y otros
costes a los precios y/o salarios que se esperan aplicar
durante el periodo en el que se tiene intención de usar
el coste estándar. Sus propósitos principales son
proporcionar bases de control mediante contabilidad de
varianza, para la valoración de trabajo en progreso y
para fijar precios de venta
Coste Indirecto Un coste indirecto es un coste incurrido al hacer un Financiera
producto proporcionando un servicio o llevando un
centro de costes o departamento, pero que no se puede
rastrear directamente o totalmente al producto, servicio
o departamento, porque ha sido incurrido para un
número de centros de coste o unidades de coste. Estos
costes son aprocionados a las unidades de coste coste /
coste. También se refieren a los costes indirectos como
Overheads o Gastos Generales.
Coste de También llamado coste continuada, el valor disminuye Financiera
Ingresos con el uso, tal como papel o salarios. Normalmente es un
coste variable
Coste Marginal El coste variable de producir una unidad extra de Financiera
producto o servicio. Esto es, el coste que se habría
evitado si la unidad / servicio no se hubiera producido /
proporcionado
Costes Aquellos resultantes de día a día de la sección de Financiera
Operacionales Servicios de IT, p.ej. costes de Personal, mantenimiento
de hardware y electricidad, y relacionado a pagos
repetidos cuyos efectos se pueden medir dentro de un
marco de tiempo corto, normalmente menos que el año
193
19
financiero de 12 meses
Coste de El valor de un beneficio sacrificado a favor de un curso Financiera

Oportunidad (o de acción alternativo. Ese es el coste de utilizar recursos
coste en una operación particular expresado en términos de
verdadero) sobreponer al beneficio que se podría derivar al mejor
uso alternativo de esos recursos.
Coste Primo El coste total de los materiales directos, mano de obra Financiera
directa y gastos directos. El término coste primo se
restringe comúnmente a costes de producción directa así
que no incluye costes directos de marketing o
investigación y desarrollo.
Coste de Este término se utiliza para describir la cantidad de Financiera
Recurso recursos de máquina que consumirá una tarea dada. Este
recurso normalmente se expresa en segundos para la
CPU o el número de I/Os para un mecanismo de disco o
cinta.
Coste de Unidad Costes de unidad son costes distribuidos para el uso de Financiera
componentes individuales para establecer el coste d
unidad. Por ejemplo, se pueden entender, que si la caja
de papel de 1000 vale £10, entonces obviamente una
hoja cuesta 1 penique. De forma similar, si una CPU
cuesta £1 mill por año y se usa para procesar 1,000
trabajos en ese año, cada trabajo cuesta £1,000
Coste de Unidad La unidad de recurso puede ser calculada en una base de Financiera
de Recurso coste estándar para identificar el coste esperado
(estándar) para usar un recurso en particular. Como
recursos informáticos vienen en muchas formas, las
unidades se tienen que establecer por agrupaciones
lógicas. Ejemplos son: a) tiempo de CPU o instrucciones,
b) I/Os de disco, c) líneas impresas, d) transacciones de
comunicación.
Costing El proceso de identificar los costes de negocio y de Financiera
desglosarlos y relacionarlos con las varias actividades del
negocio
Costing the Un principio mediante el cual costes tanto fijos como Financiera
Absorción variables se asignan a unidades de coste y gastos totales
son absorbidos de acuerdo con el nivel de actividad. El
término se puede aplicar donde se asignan costes de
producción o costes de todas las funciones
Costing Estándar Una técnica que utiliza estándares de costes e ingresos Financiera
para los propósitos de control mediante análisis de
varianza.
Costing de Plena Un principio donde los costes fijos y variables son Financiera
Absorción asignados a unidades de coste y los costes generales son
absorbidos de acuerdo a los niveles de actividad
Datos de Información que soporta los planes y listas de acción, Todos
Referencia tales como nombres y direcciones o inventarios, que
llevan índices dentro del plan
Dependencia La dependencia, o directa o indirecta, de un proceso o Todos
actividad de otro
Depreciación La depreciación es la pérdida de valor de un bien debido Financiera
a su uso y/o el paso de tiempo. El cargo de depreciación
anual en cuentas representa la cantidad de bienes
capitales en el periodo contable. Se carga en las cuentas
de costes para asegurar que el coste del equipamiento
capital se refleje en los costes de unidad de los servicios
proporcionados utilizando el equipo. Hay varios métodos
de calcular la depreciación para el periodo, pero la
19
Tesorería normalmente recomienda el uso de validación

de coste de bienes actual como base para el cargo de
depreciación.
Service Desk El único punto de contacto dentro de la administración Service Desk
de IT para usuarios de servicios de IT
Difusión Una colección de CI nuevos y/o cambiados, que se Difusión
prueban e introducen al entrono vivo juntos.
Difusión Todos los componentes de la unidad de Difusión son Difusión
Completa construidos, probados, distribuidos e implementados
juntos – Ver también “Difusión Delta”
Difusión Delta Una Difusión Delta, o parcial, es la que incluye sólo esos Difusión
CI dentro de la unidad de Difusión que han cambiado de
hecho o son nuevas desde la última Difusión Delta o
completa. Por ejemplo, si la unidad de Difusión es el
programa, una Difusión Delta contiene sólo esos módulos
que han cambiado, o son nuevos desde la última difusión
completa del programa o la última difusión Delta de los
módulos-ver también “Difusión Completa”
Difusión de Una difusión implementada urgentemente. Difusión
Emergencia Mayoritariamente, por una incidencia pendiente
Difusión de Un número de unidades de difusión empaquetadas junas Difusión
Paquete
Discounting Discounting es ofrecer a los clientes tasas reducidas para Financiera
el uso de recursos off peca (fuera de horas punta) (ver
también Sobretasar)
Disponibilidad Habilidad de un componente o servicio para realizar su Disponibilidad
función requerida en un instante dado a lo largo de un
período dado de tiempo. Normalmente se expresa como
el ratio de disponibilidad, es decir la proporción de
tiempo que el servicio está disponible realmente para
uso de los Clientes dentro de las horas de servicio
acomodadas.
Dispositivos de Los Discos de estado sólido son mecanismos de memoria Tecnología
Estado Sólido a los que se les hace aparecer como mecanismos de
disco. Las ventajas de tales mecanismos son que los
tiempos de servicio son mucho más rápidos que los discos
reales ya que no hay tiempo de búsqueda o latencia. La
desventaja principal es que son mucho más caros.
Documentación Documentos que definen requisitos, diseño de sistema, Configuración
de construcción, producción y verificación de un artículo de
Configuración configuración
Documento de Solicitud de Cambio, formulario de control de Cambio, Cambios
Cambio orden de Cambio, expediente de Cambio
Downtime El tiempo en el que un servicio acordado no está Disponibilidad
disponible
Downtime El tiempo en el que un servicio acordado no está Incidencias
disponible
Dúplex Un canal/línea duplex completa permite la transmisión Tecnología
(completo y simultánea en ambas direcciones. Canal/línea duplex
medio) media es capaz de transmitir en ambas direcciones, pero
sólo en una dirección a la vez.
Echoing (EI) Echoing (eco) es un reflejo de la señal transmitida Tecnología
de la parte receptora, un método visual de detección de
error en la que la señal del mecanismo originario se
enlaza de nuevo a ese mecanismo para que se pueda
mostrar
Efectividad de Asegurar que hay un equilibrio adecuado entre la calidad Todos
coste de servicio por un aparte y el precio por otra. Cualquier
195
19
inversión que aumenta los costes de proporcionar

servicios de IT siempre debería resultar en la mejora de
calidad o cantidad de servicio.
Elementos de Las partes constituyentes de costes de acuerdo a los Financiera
Coste factores sobre los que se incurren con materiales, mano
de obra y gastos
Emulación de Una emulación de terminal se alcanza al ejecutar Tecnología
Terminal software en un mecanismo inteligente, típicamente un
PC o puesto de trabajo, que permite a ese mecanismo
funcionar como terminal interactiva conectada al
sistema host. Ejemplos de tal software de emulación
incluyen IBM 3270BSC o SNA, ICL C03 o Digital VT100
Enfoque de Local de IT tan a pruebas de desastre como sea posible Continuidad
Fortaleza
Entorno Una colección de hardware, software, comunicaciones Difusión
de red y procedimientos que trabajan juntos para
proporcionar un tipo discreto de servicio informático.
Puede haber uno o más entornos en una plataforma
física p.ej. test, producción. Un entorno tiene rasgos
únicos y características que dictan cómo se administran
en maneras similares pero distintas.
Entorno Live (Parte del) sistema informático utilizado para construir Difusión
Building difusiones de software para uso en vivo
Entorno de Software utilizado para soportar la aplicación tal como Difusión
Software el sistema operativo, sistema de gestión de base de
datos, herramientas de desarrollo, compliadores, y
software de aplicaciones.
Entorno de Test (Parte de) sistema informático utilizado para construir Difusión
Build difusiones de software para testing de aceptación
operacional
Entorno de Test (Parte de) sistema informático utilizado para construir Difusión
difusiones de software para testing de aceptación
operacional
Entorno Vivo (Parte del) sistema informático utilizada para usar Difusión
software en uso vivo
Equipo de Un grupo definido de Personal con un rol definido y un Continuidad
Recuperación de rango suborinado de acciones para facilitar la
Negocio recuperación de una función o proceso de negocio
Error Conocido Una Incidencia o Problema del cual no se conoce la causa Problemas
de raíz y para el cual se ha identificado un Workaround
temporal o una alternativa permanente. Si existe un
caso de negocio, un RFC se hará, pero, en cualquier caso
permanece como Error Conocido hasta que se arregle
permanentemente con un Cambio
Escala Funcional Escala o Referencia a más u otros conocimientos Incidencias
Escalada Escalada a un nivel más alto en la jerarquía Incidencias
Jerárquica
Escenario de Descripción del tipo de impacto en el negocio que podría Incidencias
Impacto seguir un trastorno de negocio. Normalmente, estará
relacionado con el proceso de negocio y siempre se
referirá a un periodo de tiempo, p.ej. atención al cliente
no podrá operar durante dos días
Estructura de En estructuras de datos, una serie de nodos conectados Tecnología
Árbol sin ciclos. Un nodo se denomina la raíz y es el punto de
partida de todas las rutas, otros nodos denominados
hojas terminan las rutas
Estructura de Una jerarquía de todos los Cl que constituyen una Configuración
Configuración configuración.
19
Evaluación de El proceso de evaluar la inversión propuesta en bienes Financiera

Inversión Capital fijos específicos y los beneficios que se pueden obtener
de su adquisición. Las técnicas utilizadas en la
evaluación se pueden resumir como métodos de no
descuento (es decir, simplemente, reembolso), beneficio
en capital empleado y métodos de flujo de efectivo de
descuento (es decir, beneficio, valor presente neto y
reembolso descontado).
Expediente de Un expediente conteniendo detalles de qué AC se ven Cambios
Cambio afectados por un cambio autorizado (programado o
implemententado) y cómo.
Fallo de Hard Fallos de hard (hard faults) describen la situación en un Tecnología
(hard fault) sistema de memoria virtual cuando la página requerida
de códigos o datos, que está utilizando un programa, he
sido redistribuida por el sistema operativo para otro
propósito. Esto significa que otra parte de la memoria se
debe encontrar para alojar el código o datos, y
conllevará la lectura/escritura física de páginas al
archivo de páginas.
Fallo de Página Una interrupción de programa que ocurre cuando una Tecnología
página activa se refiere a una página que está marcada
“no en memoria real”
Fallo de Soft Un fallo de soft describe la situación en un sistema de Tecnología
(Soft Fault) memoria virtual cuando el sistema operativo ha
detectado que una página de código o datos se tenía que
reutilizar, es decir está en una lista de páginas “libres”
pero en realidad está todavía en la memoria. Se rescata
y devuelve al servicio
Fase de Alerta La primera fase del plan de continuidad de negocio en Continuidad
el que se activan los procedimientos de emergencia y
evaluaciones de daños
Fase de La segunda fase del plan de continuidad de negocio en el Continuidad
Invocación y que se activan los procedimientos de emergencia y
Recuperación evaluaciones de daños.
Fiabilidad Habilidad de un componente de entregar una Disponibilidad
funcionalidad deseada durante un periodo de tiempo
dado y bajo ciertas condiciones.
Flujo de Una evaluación de los flujos de efectivo netos futuros Financiera
Efectivo generados por un proyecto capital al descontarlos a su
Descontado valor de hoy día. Los dos métodos más comúnmente
utilizados son: a) método de rédito, por el que el cálculo
determina la Tasa Interna de rendimiento TIR en forma
de porcentaje b) método de valor presente neto (VPN),
en el que la tasa de descuento se elige y la respuesta es
una cantidad de dinero.
Función de Una unidad de negocio dentro de una organización, p. Todos
Negocio ej. un departamento , una división, una sucursal
Garantía Los procesos mediante los cuales una organización puede Continuidad
verificar la exactitud e integridad de su Gestión de
Capacidad de Negocio
Gasto Absorbido Gasto general que, por medio de las tasas de absorción, Financiera
se incluye en los costes de productos específicos o
servicios vendibles, en un periodo de tiempo dado. Gasto
infla o sobre absorbido. La diferencia entre coste
general incurrido y coste general absorbido: se puede
dividir en sus dos partes constituyentes a propósito de
controles
Gateway Un gateway es equipamiento, que se utiliza para hacer Tecnología
nexo entre (interface) redes para que una terminal en
197
19
una red pueda comunicar con servicios o una terminal de

otra.
Gestión de Ver Gestión de Relación de Negocio CRM
Atención al
Cliente IT
Gestión de La Gestión de Bienes Configuración
Bienes
Gestión de Proceso de controlar Cambios a una infraestructura o a Cambios
Cambios cualquier aspecto de los servicios, de manera
controlada, permitiendo cambios aprobados con un
trastorno mínimo
Linea de Base Instantánea del estado de un CI (CMDB) y CI relacionados Configuración
en un punto en el tiempo
Listas de acción Acciones definidas, asignadas a equipos de recuperación Todos
e individuales, dentro de las fases de un plan. Estos son
soportados por datos de referencia.
Llamada Un contacto con el Service Desk. Service Desk
Logro de Los niveles de servicio que realmente entregan la SLM
Servicio administración de IT al cliente con una duración de vida
limitada.
Mando, Control Los procesos mediante los cuales una organización Continuidad
y retiene coordinación general de su esfuerzo de
comunicaciones recuperación durante la invocación de planes de
recuperación de negocio.
Marco de Plan Una plantilla de plan de recuperación de negocio ( o Continuidad
de Recuperación conjunto de planes) producidos para permitir que la
de Negocio estructura y contenido propuesto sean acordados antes
de producirse el plan de recuperación de negocio.
Medida de Medidas tomadas para reducir la probabilidad de que Disponibilidad
Reducción de ocurra un trastorno de negocio (como opuesto a planear
Riesgo la recuperación después de un trastorno).
Medida de Medidas tomadas para reducir la probabilidad de que Continuidad
Reducción de ocurra un trastorno de negocio (como opuesto a planear
Riesgo la recuperación después de un trastorno).
Modeling Una actividad para predecir el comportamiento de Capacidad
sistemas informáticos bajo un volumen y variedad de
trabajo dados.
Modeling Modeling Simulado como implica el nombre, emplea un Capacidad
Simulado programa, que simula el procesamiento de ordenador al
describir en detalles la ruta de un trabajo o transacción.
Puede dar resultados extremadamente precisos.
Desgraciadamente, exige una gran cantidad de tiempo y
esfuerzo del modeling. Es más beneficioso en sistemas
extremadamente grandes o críticas de tiempo donde el
margen de error es muy pequeño.
Monitorización El registro y guardar de la utilización de cada recurso y Capacidad
servicio en una base continuada para asegurar el uso
óptimo de los recursos de hardware y software, que se
puedan alcanzar los niveles acordados de servicio y que
los volúmenes de negocio son los esperados.
Multiplexor Los multiplexor dividen canales de datos en dos o más Tecnología
canales de datos fijos de velocidad más baja.
Nivel de CI El nivel de detalle de un CI. Configuración
Nivel de Ver IPWTM. El grado hasta el cual las actividades y Todos
madurez/ Hito procesos de BCM se han convertido en práctica habitual
dentro de una organización. Ver IPW Stadia Model
(www.quintgroup.com)
Nivel de El nivel en el que se ha asegurado una organización. Seguridad
19
Seguridad
Numeración de La política que determina cómo se deben numerar Difusión
Difusión difusiones. El número de una difusión.
Objetivo Una de las medidas contra las cuales se compara un Financiera
Externo servicio de IT entregado, expresado en términos de
negocio del cliente.
Objetivo Interno Una de las medidas contra la que procesos de soporte SLM
para el servicio de IT se comparan, normalmente
expresada en términos técnicos relacionados
directamente con el servicio subyacente que se mide.
Objetivo de El tiempo deseado dentro del cual los procesos de Continuidad
Recuperación de negocio se deben recuperar y el Personal, bienes y
negocio servicios mínimos requeridos durante este tiempo.
Ocupación de Ocupación de Almacén es una unidad de medida definida Capacidad
Almacén que se usa para equipo de tipo almacén para medir su
uso. El valor de la unidad equivale al número de bytes
guardados.
Outsourcing El proceso por el cual las funciones realizadas por la SLM
organización son subcontratadas para la operación por
parte de la organización a terceros.
Overheads El total de materiales, sueldos y gastos indirectos Financiera
(Gatos
generales)
Package Un mecanismo de paquete de montaje / desmontaje que Tecnología
Assembly permite terminales que no tienen un interface adecuado
/Disassembly para la conexión directa de una red de paquetes
Device conmutados para acceder a tal red. Un PAD convierte
datos a/de paquetes y maneja configuración de llamadas
y direccionamiento.
Paginamiento La reacción del sistema operativo a memoria real Tecnología
(swapping) insuficiente: los paginamientos ocurren cuando se
percibe que demasiadas tareas compiten por recursos
limitados. Es el movimiento físico de una tarea completa
(p.ej. todas las páginas de memoria real de un espacio
de dirección se pueden mover de una vez del almacén
principal al almacén auxiliar).
Paging Paging (paginado) es el I/O (E/S) necesario para leer de Tecnología
(Paginado) y escribir a los dispositivos de paging: se necesita
memoria real (no virtual) para procesar datos. Con
memoria real insuficiente, el sistema operativo escribe
páginas viejas al disco y lee nuevas páginas del disco
para que los datos e instrucciones requeridas estén en la
memoria real.
PD0005 Título alternativo para la publicación BSI “El Código de Todos
Práctica para Gestión de servicio de IT”.
Perfil de El Perfil de Recurso describe los costes totales de Capacidad
Recurso recursos, que se consumen por una transacción online
individual, lote o programa. Normalmente, se expresa en
términos de segundos CPU, número de I/Os y utilización
de memoria.
Phantom Line Un error de linea fantasma es un error de comunicación Tecnología
Error informado por un sistema informático, que no se detecta
con equipo de monitorización en red. A menudo es
causado por cambios a circuitos y equipo en red (p.ej.
circuitos de redireccionamiento a escala física en una
red de columna) mientras la comunicación de datos está
en progreso.
Plan de Calidad El plan escrito y especificación de objetivos internos SLM
de servicio diseñados para garantizar los niveles de servicio
199
20
acordados.
Plan de Plan detallando las acciones y procedimientos a seguir Continuidad

Contingencia en caso de un desastre importante.
Plan de Gestión Documento marcando la organización y procedimientos Configuración
de para la Gestión de Configuración de un producto
Configuración específico, proyecto, sistema, grupo de soporte o
servicio.
Planes de Documentos describiendo los roles, las responsabilidades Continuidad
Recuperación de y acciones necesarias para resumir los procesos de
Negocio negocio tras un trastorno de negocio.
Planning de Proceso para proporcionar planes e informes para cubrir Capacidad
Capacidad cargas de negocio actuales y futuras.
Planning de Planning para afrontar ocurrencias no deseadas que Continuidad
Contigencia pueden ocurrir más tarde. Tradicionalmente, el término
se ha utilizado para referirse a planning de la
recuperación de sistemas de IT más que procesos enteros
de negocio.
Planning de Una serie de procesos que se centran sólo en procesos de Continuidad
Recuperación de recuperación, principalmente en respuesta a desastres
Desastre físicos que se contienen dentro de BCM.
Política de La política que determina cómo se deben tratar las Difusión
Difusión difusiones. Engloba tamaño, numeración y frecuencia.
Poner Precio La política que determina cómo se valoran unidades Financiera
(Pricing) cargables.
Presupuestar Budgeting. El proceso de predecir y controlar el gasto de Cost
dinero dentro de la empresa y consiste en un ciclo de
negociación periódica para fijar presupuestos
(normalmente anual) y la monitorización diaria de los
presupuestos actuales.
PRINCE2 El método estándar del gobierno de Reino Unido para Todos
gestión de proyecto.
Prioridad Secuencia en la que se necesita resolver una Incidencia o Incidencias
Problema, basado en el impacto y la urgencia.
Prioridad Secuencia en la que se necesita resolver una Incidencia o Problemas
Problema, basado en el impacto y la urgencia.
Problema Causa subyacente desconocida de una o más Incidencias. Problemas
Procedimiento Una serie conectada de acciones, actividades, realizadas Todos
por agentes, lo suficientemente detallada para que un
agente tenga claro qué ha de hacer.
Proceso Una serie de acciones, actividades, cambios, etc. Todos
realizados por agentes con la intención de satisfacer un
propósito o alcanzar un gol.
Proceso de BCM Un conjunto de actividades con entregables definidos Continuidad
formando una parte discreta del ciclo vital de la BCM.
Proceso de Un grupo de actividades de negocio apropiadas por una Todos
negocio organización con el fin de conseguir un objetivo común.
Procesos típicos de negocio incluyen recibir pedidos,
servicios de marketing, venta de productos, entrega de
servicios, distribución de productos, facturación de
servicios, contabilización de dinero recibido. Un proceso
de negocio normalmente dependerá de varias funciones
de negocio para soporte, p.ej. it, personal, alojamiento.
Un proceso de negocio, rara vez operará de forma
aislada, es decir, otros procesos de negocio dependerán
de él y él dependerá de otros procesos.
Programa Una colección de actividades y poyectos que Tecnología
colectivamente implementan un nuevo requisito
20
corporativo o función.
Programa de Un proyecto formal encargado dentro de una Todos
Mejora de organización para identificar e introducir mejoras
Servicio mesurables dentro de un área específica o proceso de
trabajo.
Programación Contiene detalles de todos los cambios aprobados para Cambios
Adelantada de implementación y sus fechas de implementación
Cambios propuestas. Se debería acordar con los clientes y el
negocio, Gestión de Nivel de servicio, el Service Desk y
Gestión de Disponibilidad. Una vez acordados, el Service
Desk debería comunicar a la comunidad de Usuarios en
general cualquier downtime programado adicional que
surja de implementar los cambios, utilizando los
métodos más efectivos disponibles.
Proveedor de Organización externa que suministra servicios o Disponibilidad
servicio productos a clientes
Puente (bridge) Un puente es el equipamiento y las técnicas utilizadas Tecnología
para ligar circuitos unos a los otros para asegurar el
mínimo daño de transmisión.
Punto Único de Un componente que causará la no-disponibilidad de un Disponibilidad
Fallo servicio cuando falle.
Recuperabilidad La habilidad de un sistema de recuperarse. Este término Disponibilidad
combina sostenibilidad, serviciabilidad y resistencia.
Recuperación Anteriormente llamado Standby Frío, es aplicable a Continuidad
Gradual organizaciones que no necesitan la restauración
inmediata de procesos de negocio y pueden funcionar
por un periodo de hasta 72 horas o más sin el re
establecimiento de las facilidades plenas de IT. Esto
puede incluir la provisión de alojamiento vacío
completamente equipado con electricidad, controles de
entorno e infraestructura de cableado de red local,
conexiones de telecomunicaciones y disponible en una
situación de desastre para que una organización pueda
instalar su propio equipo informático.
Recuperación Anteriormente llamado Standby Caliente, proporciona la Tecnología
Inmediata inmediata restauración de servicios tras un incidente
irrecuperable. Es importante distinguir entre la
definición anterior de “standby caliente” y
“recuperación inmediata”. Standby caliente típicamente
se refiere a disponibilidad de servicios dentro de un
marco de tiempo corto tal como 2 a 4 horas mientras
que recuperación inmediata implica la disponibilidad
instantánea de los servicios.
Recuperación Anteriormente llamado “Warm Standby”, conllevará Continuidad
Intermedia típicamente el reestablecimiento de los sistemas y
servicios críticos dentro de un plazo de 24 a 72 horas, y
será utilizado por organizaciones que necesitan
recuperar las facilidades de IT dentro de un periodo de
tiempo predeterminado para prevenir de impactos al
proceso de negocio.
Recursos El término recursos se refiere a los medios que necesita Capacidad
la sección de Servicios de IT para proporcionar a los
clientes los servicios requeridos. Los recursos son
típicamente equipo de ordenador y relacionado,
software, facilidades o organizacional (personas).
Registro El registro inicial y continuado de un CI. Configuración
Registro El registro inicial y continuado de una llamada Service Desk
Registro de Un registro de Solicitudes para Cambio surgidos durante Cambios
Cambio el proyecto, mostrando información de cada Cambio, su
201
20
evaluación, qué decisiones se han tomado y su estatus

actual, p.ej. Surgido, Revisado, Aprobado,
Implementado y Cerrado.
Requisito de Requisitos, expresados por el cliente que son inputs a las SLM
Nivel de Servicio negociaciones hacia los SLA
Resistencia Habilidad de un servicio de continuar cuando uno o más Disponibilidad
de sus componentes han fallado.
Resolución Acción que resolverá una Incidencia. Esto puede ser un Incidencias
Workaround.
Restauración de El momento que un cliente ha confirmado que el servicio Disponibilidad
Servicio se puede volver a utilizar otra vez tras una incidencia o
contingencia.
Restauración de El momento que un cliente ha confirmado que el servicio Continuidad
Servicio se puede volver a utilizar otra vez tras una incidencia o
contingencia.
Revisión Post Una revisión para ver si el cambio ha conseguido lo que Cambios
Implementación tenía que conseguir.
Revisión Post Una revisión para ver si el cambio que debería resolver Problemas
Implementación el problema ha conseguido de hecho resolver el
problema.
Riesgo Una medida de la exposición a la que puede estar sujeta Disponibilidad
una organización. Esta es una combinación de la
probabilidad de que ocurra un trastorno de negocio y la
posible pérdida que pueda resultar de tal trastorno o de
negocio.
Riesgo Una medida de la exposición a la que puede estar sujeta Continuidad
una organización. Esta es una combinación de la
probabilidad de que ocurra un trastorno de negocio y la
posible pérdida que pueda resultar de tal trastorno o de
negocio.
Rol Un conjunto de responsabilidades, actividades y Todos
autorizaciones.
Roll in roll out RIRO es un término que se utiliza en algunos sistemas Tecnología
(RIRO) para describir intercambios.
Rollout El momento o período en el que se implementa un Difusión
sistema o conjunto de sistemas. Este término
normalmente se usa cuando se implementan múltiples
sistemas en distintos momentos.
Rotacional RPS es una facilidad que se emplea en la mayoría de los Tecnología
Position Sensing mainframes y en algunos mini ordenadores. Cuando se ha
iniciado una búsqueda el sistema puede liberar la ruta
del disco al controlador para el uso de otro disco
mientras espera los datos requeridos bajo las cabezas de
lectura/escritura (latencia). Esta facilidad normalmente
mejora el rendimiento general del sistema I/O (E/S).
Sección de LA sección en el SLA que describe el nivel de seguridad Seguridad
seguridad necesario.
Sección de La sección en el SLA que describe el nivel de seguridad SLM
Seguridad necesario.
Seguridad Confidencialidad, Integridad y Disponibilidad de CI.º Seguridad
Servicios Servicios son los entregables de la sección de Servicios Todos

de IT tal y como los perciben los clientes; los servicios no
consisten meramente poner a disposición de los clientes
los recursos informáticos.
Servicios de IT Servicios son los entregables de la sección de Servicios Todos
de IT tal y como los perciben los clientes; los servicios no
consisten meramente poner a disposición de los clientes
los recursos informáticos.
20
Sistema Un composito integrado que consiste en uno o más de los Todos

procesos, hardware, software, facilidades y personas que
proporciona una capacidad de satisfacer una necesidad
expresada u objetivo.
Sistema de Se desarrollaron los sistemas de memoria virtual para Tecnología
Memoria Virtual aumentar el tamaño de la memoria al añadir una capa
de almacenamiento auxiliar, que reside en el disco.
Sizing de El proceso que estima los requisitos de recursos para Capacidad
aplicación soportar un cambio de aplicación propuesto o una nueva
aplicación, para asegurar que alcanza sus niveles de
servicio requerido.
Sobre tasar Sobretasar es cobrar a los usuarios de negocio una tasa Financiera
Premium por utilizar recursos en horas punta.
Solicitud de Formulario, o pantalla, utilizada para registrar detalles Cambios
Cambio (RFC) de una solicitud de cambio o cualquier CI dentro de una
infraestructura o a procedimientos y artículos asociados
con la infraestructura.
Solicitud de Cada incidencia que no es un fallo dentro de la Service Desk
Servicio infraestructura de IT.
Soporte de A menudo, se refiere a los departamentos y grupos de Incidencias
Primera Línea soporte (especialistas) distintos al Service Desk como
grupos de soporte de segunda –o tercera- línea, teniendo
más habilidades especialistas, tiempo y otros recursos
para resolver incidencias. A este respecto, el Service
Desk sería soporte de primera línea.
Soporte de A menudo, se refiere a departamentos y grupos de Service Desk
Segunda Línea soporte (especialistas) distintos al Service Desk, como
grupos de soporte de segunda o tercera línea, teniendo
más habilidades especialistas, tiempo u otros recursos
Soporte de A menudo, se refiere a departamentos y grupos de Incidencias
Tercera Línea soporte (especialistas) distintos al Service Desk, como
grupos de soporte de segunda o tercera línea, teniendo
más habilidades especialistas, tiempo u otros recursos
Sostenibilidad Habilidad de un componente o servicio para volver a un Disponibilidad
estado en el que la funcionalidad deseada se volverá a
proporcionar.
Specsheet Especifica en detalle lo que quiere el cliente (externo) y SLM
qué consecuencias esto tiene para el proveedor de
servicio (interno) tal como los recursos requeridos y
habilidades.
Standby Frío Ver “Recuperación Gradual” Continuidad
Standby Ver “Recuperación Inmediata” Continuidad

Caliente
Standby Ver “Recuperación Inmediata” Continuidad
Templado
Súper Usuario En algunas organizaciones, es común utilizar Usuarios Service Desk
“expertos” (comúnmente conocidos como Súper Usuarios
o Usuarios Expertos) para tratar con problemas o
consultas de soporte de primera línea. Típicamente, esto
es en áreas de aplicación específicas, o situaciones
geográficas, donde no hay el requerimiento de
empleados de soporte a tiempo completo. Este recurso
valioso sin embargo, se debe coordinar y utilizar de
manera cuidadosa.
203
20
Terminal I/O Terminal I/O (E/S) es un mecanismo online de lectura de Tecnología

(E/S) o escritura a tal como un VDU o impresora remota.
Trashing Una condición en un sistema de almacenamiento virtual Tecnología
donde una promoción excesiva de tiempo de CPU se pasa
en mover datos entre el almacén principal y auxiliar.
Tiempo de Tiempo de búsqueda ocurre cuando las cabezas de Tecnología
búsqueda lectura/escritura no están posicionadas en la pista
correcta. Describe el tiempo transcurrido tardado en
mover las cabezas a la pista correcta.
Tiempo de Tiempo de espera ocurre cuando el mecanismo, que Tecnología
Espera desea utilizar un programa, ya está ocupado. E programa
por lo tanto tendrá que esperar e una cola para obtener
el servicio de ese mecanismo.
Tiempo Medio Tiempo medio entre la restauración de servicio tras una Disponibilidad
entre Fallos incidencia y que ocurra otra incidencia.
Tiempo Medio Tiempo medio entre ocurrencias de incidencias. Disponibilidad
entre
Incidencias de
Sistema
Tiempo Medio Downtime medio entre la ocurrencia de una incidencia y Disponibilidad
de Reparaciones la restauración del servicio/sistema.
Tiempo de Tiempo de transferencia de datos es la cantidad de Tecnología
Transferencia tiempo que tarda un bloque o sector de datos en ser
de datos leído de o escrito a un mecanismo de I/O (E/S), tal como
un disco o cinta.
Tiempo Tiempo desde el principio del inicio de una incidencia, Disponibilidad
Transcurrido mientras que no se resuelva todavía.
Unidad Cargable Unidades de Trabajo de negocio a los que pueden Financiera
atribuir cobros.
Unidad de Coste La unidad de coste es una unidad de coste funcional que Financiera
establece coste estándar por elemento de carga de
trabajo, basado en los ratios de actividad calculados
convertidos a ratio coste.
Unidad de El nivel al que software de un tipo dado se difunde Difusión
Difusión normalmente.
Unidad de Un segmento de la entidad de negocio por la que tanto Todos
Negocio se reciben ingresos como se causan o controlan gastos,
utilizándose tales ingresos y gastos para evaluar el
rendimiento segmental.
Unidad de Trabajo de Software es un término genérico pensado Capacidad
Trabajo de para representar una base común en la que todos los
Software cálculos para el uso de carga de trabajo y la capacidad
de recursos IT se basan. Una unidad de trabajo de
software para el equipo de tipo I/O equivale al número
de bytes transferidos; y para procesadores centrales se
basa en el producto de electricidad y tiempo-cpu.
Urgencia Medida de importancia crítica para el negocio de una Incidencias
Incidencia o Problema basado en el impacto y en las
necesidades del Cliente.
Urgencia Medida de importancia crítica para el negocio de una Problemas
Incidencia o Problema basado en el impacto y en las
necesidades del Cliente.
Usuario La persona que utiliza el servicio a diario. Service Desk
Usuario Experto Ver “Súper Usuario” Service Desk
Usuario final Ver “Usuario” Service Desk

20
Utilización de Utilización de porcentaje describe la cantidad de tiempo Capacidad

Porcentaje que un mecanismo de hardware está ocupado en periodo
de tiempo dado. Por ejemplo, si la CPU está ocupado
1800 segundos en un período de una hora, su utilización
se dice que es de un 50%.
Variante CI con la misma funcionalidad que otro CI pero diferente Configuración
en algún detalle pequeño.
Ventana de Horas/tiempos en los que un servicio está disponible. Disponibilidad
Servicio
Ventana de Horas/tiempos en los que un servicio está disponible. SLM
Servicio
Verificación Proceso que asegura que la CMDB y los CI físicos están Configuración
sincronizados
Versión Una instancia identificada de un Artículo de Configuración
Configuración dentro de una estructura de desglose de
un producto o en la estructura de configuración para el
propósito de localizar y auditar el historial del cambio.
También se utiliza para Artículos de Configuración de
Software para definir una identificación específica
difundida en desarrollo para edición, revisión o
modificación, test o producción.
Versión Una instancia identificada de un Artículo de Difusión
Configuración dentro de una estructura de desglose de
un producto o en la estructura de configuración para el
propósito de localizar y auditar el historial del cambio.
También se utiliza para Artículos de Configuración de
Software para definir una identificación específica
difundida en desarrollo para edición, revisión o
modificación, test o producción.
VSI (Visual VSI (Virtual Storage Interrupt) es un término ICL VME Tecnología
Storage para un fallo de página.
Interrupt)
Vuelta a Fase La fase dentro de un plan de recuperación de un negocio Continuidad
normal que reestablece operaciones normales.
Vulnerabilidad La mediad en la que se verá afectado un componente o Disponibilidad
un servicio por una amenaza.
Vulnerabilidad La mediad en la que se verá afectado un componente o Continuidad
un servicio por una amenaza.
Waterline El nivel más bajo de detalle relevante al cliente. SLM
Workaround Método de evitar una Incidencia o Problema, o desde un Incidencias

arreglo temporal o de una técnica que significa que el
Cliente no depende de un aspecto particular del servicio
que se sabe tiene un problema.
WORM WORM o CD WORM es el término que a menudo se utiliza Tecnología
para describir discos ópticos de sólo lectura,
representando Write Once Read Memory.
205

Gestión de Servicios IT - Intoducción A ITIL - Final v2 - ES

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Gestión de Servicios IT - Intoducción A ITIL - Final v2 - ES

Caricato da

Copyright:

Formati disponibili

i

1. ITIL Y LOS MODELOS DE GESTIÓN DE IT..............................................1

2. GESTIÓN DE SERVICIOS IT.........................................................................5

Proceso de Gestión de Cambio.............................................................................68

Flujo de Datos en las Service Pages...................................................................216

R2C (Regulation, Control and Continuity)

RPM (Recursive Process Management)

SIMA (Standard Integrated Management Approach)

Hay muy pocos SLAs que consiguen su supuesto objetivo de mejorar la

En muchas organizaciones de IT no existe un mecanismo de soporte al

La mayoría de organizaciones son dirigidas por acciones reactivas e

En el de tema de Personal, también tenemos asuntos. En primer lugar,

Expectaciones del Cliente

El nuevo entorno de empresa de IT es mucho más complicado debido a:

¿Por qué implementar Gestión de Servicio?

 Mayor flexibilidad para el negocio mediante mejor entendimiento de

basa en implementar procesos, preferiblemente con la orientación de una

Procesos, Departamentos y Procedimientos

quién ejecuta ciertas actividades en un proceso. Los procedimientos pueden

“Hemos aprendido a vivir en un mundo de errores y productos

La manera en la que una organización programa manejar sus operaciones

esta filosofía, formuló catorce puntos de atención para directores. Algunos

Las siglas de ITIL se corresponden a “Information Technology

Como hemos visto en el capitulo anterior y a pesar no poder considerar a

Estos son los 7 conjuntos de procesos:

También cubre las necesarias interacciones entre estas

Procesos tratados en esta publicación:

Procesos tratados en esta publicación:

Planificación de la implementación de la gestión de

Procesos tratados en esta publicación:

Procesos tratados en esta publicación:

Procesos tratados en esta publicación:

Procesos tratados en esta publicación:

Procesos tratados en esta publicación:

Los más ampliamente implementados son los conjuntos de Entrega y

Los principales elementos de ITIL pueden ser comparados a la superposición

Ciertamente, si consideramos la analogía con las placas tectónicas, unas

Los elementos de los procesos para la gestión de servicios pueden ser

Modelo en Piezas de Puzzle de los principales dominios de ITIL

Esta situación ilustra la necesidad de la consistencia tanto a través de la

Razones del éxito de ITIL

Siendo un marco de trabajo, ITIL describe perfil de las organizaciones de

Gracias a este marco de mejores prácticas comprobadas, ITIL puede ser

Una parte importante de los proyectos de ITIL es conseguir que la gente

ITIL se centra en la provisión de servicios de alta calida con el enfoque

Los procesos tácticos están centrados en las relaciones entre las

ITIL apoyará este sistemas de calidad mediante la provisión de un procesos

Los beneficios de la gestión de la calidad para los servicios It podemos

Mucha más información sobre el funcionamiento de este forum, estructura,

La continua reestructuración de ITIL

ITIL fue originalmente producido a finales de los años 80 y consistía en un

Últimamente el material ha sido revisado y actualizado para centrase en los

¿A qué organizaciones va dirigido?

En definitiva, los libros son relevantes para cualquier organización implicada

¿Quién debería leer ITIL?

Extendiendo esto, todo el personal involucrado en la entrega de servicios IT

Los directores de IT deben ser sabedores de su existencia, así como de los

Beneficios de usar ITIL

 Incrementar la satisfacción de los usuarios con los servicios IT

Muchas organizaciones IT intentan orientarse hacia sus clientes, para

Las organizaciones son instadas a adaptar la guía para ajustarla a sus

La adopción de ITIL en una organización admite una aproximación a la