Manual+Completo+Alumno Fundamentos

®
Fundamentos
GUIA PARA EL ALUMNO
Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

Curso Fundamentos de ITIL® Versión 5.1 – Plaityl s.l.
INDICE
1 INTRODUCCIÓN ............................................................................................................. 11
1.1 PRESENTACIÓN DE LOS ALUMNOS .............................................................................. 12

1.2 OBJETIVOS DEL CURSO ................................................................................................ 13
1.3 CARACTERÍSTICAS DE ITIL® ........................................................................................... 14
1.4 MEJORES PRÁCTICAS DE GESTIÓN (BMP) ..................................................................... 15
2 MEJORES PRÁCTICAS DE ITIL® ......................................................................................... 16
2.1 OBJETIVOS DE APRENDIZAJE ....................................................................................... 17

2.2 ESQUEMA DE CERTIFICACIÓN ...................................................................................... 18
2 GESTIÓN DEL SERVICIO COMO PRÁCTICA ....................................................................... 22
2.1 MEJORES PRÁCTICAS EN EL DOMINIO PÚBLICO ........................................................... 23

2.2 ÉXITO DE ITIL® ............................................................................................................. 24
2.3 SERVICIO Y SERVICIO TI ............................................................................................... 25
2.4 SERVICIO Y PRODUCTO................................................................................................ 26
2.5 TIPOS DE SERVICIOS .................................................................................................... 27
2.6 GESTIÓN DEL SERVICIO ................................................................................................ 29
2.7 GESTIÓN DEL SERVICIO TI ............................................................................................ 29
2.8 RECURSOS Y CAPACIDADES ......................................................................................... 30
2.9 ACTIVOS DEL SERVICIO Y ACTIVOS DEL CLIENTE ........................................................... 31
2.10 TIPOS DE PROVEEDOR ............................................................................................... 32
2.11 PARTES INTERESADAS EN LA GESTIÓN DEL SERVICIO.................................................. 34
2.12 PROCESOS ................................................................................................................. 35
2.13 FUNCIONES ............................................................................................................... 37
2.14 ROLES ....................................................................................................................... 39
2.15 COMPETENCIAS Y HABILIDADES ................................................................................ 41
2.16 COMPETENCIA Y MARCO DE HABILIDADES ................................................................ 42
2.17 FORMACIÓN ............................................................................................................. 42
2.18 MODELO RACI ........................................................................................................... 43
2.19 GOBIERNO ................................................................................................................ 45
2.20 RIESGOS .................................................................................................................... 46
2.21 RIESGOS Y COSTES ..................................................................................................... 47
3 CICLO DE VIDA DEL SERVICIO ......................................................................................... 50
3.1 INTEGRACIÓN A TRAVÉS DEL CICLO DE VIDA ................................................................ 52

3.2 INTRODUCCIÓN A LA ESTRATEGIA DEL SERVICIO ......................................................... 54
3.3 INTRODUCCIÓN AL DISEÑO DEL SERVICIO.................................................................... 55
3.4 INTRODUCCIÓN A LA TRANSICIÓN DEL SERVICIO ......................................................... 56
3.5 INTRODUCCIÓN A OPERACIÓN DEL SERVICIO .............................................................. 57
3.6 INTRODUCCIÓN A LA MEJORA CONTINUA DEL SERVICIO (CSI) ...................................... 58

INDICE
4 ESTRATEGIA DEL SERVICIO ............................................................................................. 60
4.1 INTRODUCCIÓN DE LA ESTRATEGIA ............................................................................. 61

4.2 PROPÓSITO DE LA ESTRATEGIA ................................................................................... 62
4.3 OBJETIVOS DE LA ESTRATEGIA ..................................................................................... 63
4.4 VALOR DE LA ESTRATEGIA ........................................................................................... 64
4.5 VALOR DE UN SERVICIO ............................................................................................... 65
4.6 UTILIDAD Y GARANTÍA ................................................................................................ 70
4.7 GESTION DE LA ESTRATEGIA DE TI................................................................................ 76
4.7.1 INTRODUCCIÓN ............................................................................................................... 76
4.7.2 PROPÓSITO ...................................................................................................................... 76
4.7.3 OBJETIVOS ....................................................................................................................... 77
4.7.4 ESTRATEGIA DE NEGOCIO Y TI ......................................................................................... 78
4.7.5 ALCANCE.......................................................................................................................... 79
4.7.6 ACTIVIDADES ................................................................................................................... 80
4.8 GESTIÓN DE LA CARTERA DE SERVICIOS (SPM) ............................................................. 82
4.8.1 INTRODUCCIÓN ............................................................................................................... 82
4.8.2 PROPÓSITO ...................................................................................................................... 83
4.8.3 OBJETIVOS ....................................................................................................................... 83
4.8.4 ALCANCE.......................................................................................................................... 84
4.8.5 COMPONENTES ............................................................................................................... 85
4.8.6 ACTIVIDADES ................................................................................................................... 89
4.9 GESTIÓN FINANCIERA DE SERVICIOS TI ........................................................................ 91
4.9.1 INTRODUCCIÓN ............................................................................................................... 91
4.9.2 PROPÓSITO ...................................................................................................................... 92
4.9.3 OBJETIVOS ....................................................................................................................... 92
4.9.4 ALCANCE.......................................................................................................................... 93
4.9.5 ACTIVIDADES ................................................................................................................... 94
4.9.6 CASO DE NEGOCIO .......................................................................................................... 95
4.10 GESTIÓN DE LA DEMANDA ........................................................................................ 97
4.10.1 INTRODUCCIÓN ............................................................................................................. 97
4.10.2 PROPÓSITO .................................................................................................................... 98
4.10.3 PATRONES DE ACTIVIDAD DE NEGOCIO (PBA) .............................................................. 98
4.10.4 OBJETIVOS ..................................................................................................................... 99
4.11 GESTIÓN DE RELACIONES CON EL NEGOCIO (BRM) ................................................... 101
4.11.1 INTRODUCCIÓN ........................................................................................................... 101
4.11.2 PROPÓSITO .................................................................................................................. 102
4.11.3 OBJETIVOS ................................................................................................................... 103
4.11.4 ALCANCE...................................................................................................................... 104
4.11.5 BRM Y SLM (COMPARATIVA) ........................................................................................... 105
4.11.6 RELACIONES CON OTROS PROCESOS .......................................................................... 106
4.12 AUTOMATIZACIÓN DEL SERVICIO ............................................................................ 107
5 DISEÑO DEL SERVICIO .................................................................................................. 109

INDICE
5.1 INTRODUCCIÓN Y PROPÓSITO ................................................................................... 110

5.2 OBJETIVOS DEL DISEÑO DEL SERVICIO ....................................................................... 110
5.3 VALOR PARA EL NEGOCIO.......................................................................................... 111
5.4 ALCANCE EL DISEÑO DEL SERVICIO ............................................................................ 112
5.5 ASPECTOS DEL DISEÑO .............................................................................................. 113
5.5.1 SOLUCIÓN DEL SERVICIO ............................................................................................... 114
5.5.2 HERRAMIENTAS Y SISTEMAS DE GESTIÓN DE INFORMACIÓN....................................... 116
5.5.3 ARQUITECTURA TECNOLOGICA ..................................................................................... 117
5.5.4 DISEÑO DE PROCESOS ................................................................................................... 119
5.5.5 METODOS DE MEDICIÓN Y METRICAS........................................................................... 120
5.6 LAS 4 P´S DEL DISEÑO ................................................................................................ 122
5.7 CRITEROS DE ACEPTACIÓN DEL SERVICIO (SAC).......................................................... 123
5.8 COMPOSICIÓN DEL SERVICIO .................................................................................... 124
5.9 PAQUETE DE DISEÑO DEL SERVICIO (SDP) .................................................................. 126
5.10 RESTRICCIONES DEL SERVICIO ................................................................................. 127
5.11 COORDINACIÓN DEL DISEÑO ................................................................................... 131
5.11.1 INTRODUCCIÓN ........................................................................................................... 131
5.11.2 PROPÓSITO .................................................................................................................. 131
5.11.3 OBJETIVOS ................................................................................................................... 131
5.11.4 ALCANCE...................................................................................................................... 132
5.11.5 ACTIVIDADES ............................................................................................................... 133
5.12 GESTIÓN DEL CATÁLOGO DEL SERVICIO ................................................................... 135
5.12.1 INTRODUCCIÓN ........................................................................................................... 135
5.12.2 PROPÓSITO .................................................................................................................. 135
5.12.3 OBJETIVO ..................................................................................................................... 135
5.12.4 ALCANCE...................................................................................................................... 136
5.12.5 VISTAS DEL CATÁLOGO DE SERVICIOS ......................................................................... 136
5.13 GESTIÓN DE NIVEL DE SERVICIO ............................................................................... 140
5.13.1 INTRODUCCIÓN ........................................................................................................... 140
5.13.2 DEFINICIONES BÁSICAS ............................................................................................... 141
5.13.3 PROPÓSITO .................................................................................................................. 142
5.13.4 OBJETIVOS ................................................................................................................... 142
5.13.5 ALCANCE...................................................................................................................... 142
5.13.6 ACTIVIDADES ............................................................................................................... 143
5.13.7 REQUERIMIENTOS DE NIVEL DE SERVICIO (SLR) .......................................................... 145
5.13.8 MARCOS DEL ACUERDO DE NIVEL DE SERVICIO (SLA) ................................................. 145
5.13.9 SLA MULTINIVEL .......................................................................................................... 146
5.13.10 GENERAR INFORMES DE SERVICIO ............................................................................ 147
5.13.11 REVISIÓN DEL SERVICIO ............................................................................................. 149
5.13.12 PROGRAMA DE MEJORA (SIP) ................................................................................... 149
5.14 GESTIÓN DE LA DISPONIBILIDAD ............................................................................. 151
5.14.1 INTRODUCCIÓN ........................................................................................................... 151
5.14.2 PROPÓSITO .................................................................................................................. 151
5.14.3 OBJETIVO ..................................................................................................................... 152
5.14.4 ALCANCE...................................................................................................................... 153

INDICE
5.14.5 CONCEPTOS BÁSICOS .................................................................................................. 155

5.14.6 FUNCIONES VITALES DEL NEGOCIO (VBF) ................................................................... 156
5.15 GESTIÓN DE CAPACIDAD ......................................................................................... 158
5.15.1 INTRODUCCIÓN ........................................................................................................... 158
5.15.2 PROPÓSITO .................................................................................................................. 158
5.15.3 OBJETIVO ..................................................................................................................... 159
5.15.4 ALCANCE...................................................................................................................... 160
5.15.5 SUB PROCESOS ............................................................................................................ 162
5.15.6 PLAN DE CAPACIDAD ................................................................................................... 163
5.16 GESTIÓN DE CONTINUIDAD ..................................................................................... 165
5.16.1 INTRODUCCIÓN ........................................................................................................... 165
5.16.2 PROPÓSITO .................................................................................................................. 165
5.16.3 OBJETIVO ..................................................................................................................... 166
5.16.4 ALCANCE...................................................................................................................... 167
5.16.5 ACTIVIDADES ............................................................................................................... 169
5.16.6 ANALISIS DE IMPACTO DEL NEGOCIO (BIA) ................................................................. 173
5.17 GESTIÓN DE SEGURIDAD ......................................................................................... 175
5.17.1 INTRODUCCIÓN ........................................................................................................... 175
5.17.2 PROPÓSITO Y OBJETIVO .............................................................................................. 176
5.17.3 ALCANCE...................................................................................................................... 177
5.17.4 POLÍTICAS .................................................................................................................... 178
5.17.5 MARCO DE TRABAJO ................................................................................................... 179
5.18 GESTIÓN DE PROVEEDORES ..................................................................................... 183
5.18.1 INTRODUCCIÓN ........................................................................................................... 183
5.18.2 PROPÓSITO .................................................................................................................. 184
5.18.3 OBJETIVO ..................................................................................................................... 184
5.18.4 ALCANCE...................................................................................................................... 185
5.18.5 CATEGORIZACIÓN DE PROVEEDORES.......................................................................... 188
6 TRANSICIÓN DEL SERVICIO ........................................................................................... 191
6.1 INTRODUCCIÓN A LA TRANSICIÓN ............................................................................. 192

6.2 PROPÓSITO DE LA TRANSICIÓN ................................................................................. 192
6.3 OBJETIVOS DE LA TRANSICIÓN DEL SERVICIO ............................................................. 193
6.4 VALOR PARA EL NEGOCIO.......................................................................................... 194
6.5 CONCEPTOS BÁSICOS ................................................................................................ 195
6.6 ALCANCE DE LA TRANSICIÓN ..................................................................................... 196
6.7 PLANIFICACIÓN Y SOPORTE DE LA TRANSICIÓN ......................................................... 199
6.7.1 INTRODUCCIÓN Y PROPÓSITO ...................................................................................... 199
6.7.2 OBJETIVOS ..................................................................................................................... 199
6.7.3 ALCANCE........................................................................................................................ 200
6.8 GESTIÓN DE CAMBIOS ............................................................................................... 202
6.8.1 INTRODUCCIÓN ............................................................................................................. 202
6.8.2 PROPÓSITO .................................................................................................................... 202
6.8.3 OBJETIVOS ..................................................................................................................... 203

INDICE
6.8.4 ALCANCE........................................................................................................................ 203

6.8.5 VALOR............................................................................................................................ 205
6.8.6 TIPOS DE CAMBIO .......................................................................................................... 206
6.8.7 MODELOS DE CAMBIOS ................................................................................................. 207
6.8.8 PROPUESTAS DE CAMBIO .............................................................................................. 207
6.8.9 PLANIFICACION DE CORRECCIONES .............................................................................. 208
6.8.10 ACTIVIDADES ............................................................................................................... 209
6.8.11 AUTORIZACIÓN DE UN CAMBIO .................................................................................. 214
6.8.12 COMITÉ DE CAMBIOS (CAB) ........................................................................................ 215
6.8.13 CAMBIOS ESTÁNDAR ................................................................................................... 216
6.8.14 CAMBIOS DE EMERGENCIA ......................................................................................... 217
6.8.15 INTERFACES CON GESTIÓN DE LA CONFIGURACIÓN ................................................... 217
6.9 GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS DEL SERVICIO ........................................ 220
6.9.1 INTRODUCCIÓN ............................................................................................................. 220
6.9.2 PROPÓSITO .................................................................................................................... 220
6.9.3 OBJETIVOS ..................................................................................................................... 221
6.9.4 ALCANCE........................................................................................................................ 221
6.9.5 MODELO DE CONFIGURACIÓN ...................................................................................... 222
6.9.6 SISTEMA DE GESTIÓN DE LA CONFIGURACIÓN (CMS) ................................................... 223
6.9.7 BIBLIOTECA DEFINITIVA DE MEDIOS (DML) ................................................................... 224
6.9.8 ACTIVIDADES ................................................................................................................. 225
6.10 GESTIÓN DE VERSIONES Y DESPLIEGUES .................................................................. 228
6.10.1 INTRODUCCIÓN ........................................................................................................... 228
6.10.2 PROPÓSITO .................................................................................................................. 228
6.10.3 DEFINICIONES .............................................................................................................. 228
6.10.4 OBJETIVOS ................................................................................................................... 229
6.10.5 ALCANCE...................................................................................................................... 229
6.10.6 POLÍTICAS DE VERSIONES ............................................................................................ 230
6.10.7 OPCIONES Y MÉTODOS DE DESPLIEGUES .................................................................... 231
6.10.8 ACTIVIDADES ............................................................................................................... 232
6.11 GESTIÓN DE VALIDACIÓN Y PRUEBAS ...................................................................... 234
6.11.1 INTRODUCCIÓN ........................................................................................................... 234
6.11.2 PROPÓSITO .................................................................................................................. 234
6.11.3 OBJETIVOS ................................................................................................................... 235
6.11.4 ALCANCE...................................................................................................................... 235
6.12 GESTIÓN DE EVALUACIÓN DEL CAMBIO ................................................................... 237
6.12.1 INTRODUCCIÓN ........................................................................................................... 237
6.12.2 PROPÓSITO .................................................................................................................. 237
6.12.3 OBJETIVOS ................................................................................................................... 237
6.12.4 ALCANCE...................................................................................................................... 238
6.13 GESTIÓN DEL CONOCIMIENTO ................................................................................. 240
6.13.1 INTRODUCCIÓN ........................................................................................................... 240
6.13.2 PROPÓSITO .................................................................................................................. 240
6.13.3 OBJETIVOS ................................................................................................................... 241
6.13.4 ALCANCE...................................................................................................................... 242

INDICE
6.13.5 SISTEMA DE GESTIÓN DEL CONOCIMIENTO (SKMS).................................................... 243

6.13.6 MODELO DIKW ............................................................................................................ 244
7 OPERACIÓN DEL SERVICIO ........................................................................................... 246
7.1 INTRODUCCIÓN ........................................................................................................ 247

7.2 PROPÓSITO DE OPERACIÓN ...................................................................................... 247
7.3 OBJETIVOS DE OPERACIÓN ........................................................................................ 247
7.4 ALCANCE DE OPERACIÓN .......................................................................................... 248
7.5 COMUNICACIÓN ....................................................................................................... 249
7.6 IMPLICACIÓN DE OPERACIONES EN EL CICLO DE VIDA ................................................ 250
7.7 GESTIÓN DE EVENTOS ............................................................................................... 253
7.7.1 INTRODUCCIÓN ............................................................................................................. 253
7.7.2 PROPÓSITO .................................................................................................................... 254
7.7.3 OBJETIVOS ..................................................................................................................... 254
7.7.4 ALCANCE........................................................................................................................ 254
7.7.5 VALOR............................................................................................................................ 255
7.7.6 DEFINICIONES ................................................................................................................ 255
7.8 GESTIÓN DE INCIDENCIAS.......................................................................................... 258
7.8.1 INTRODUCCIÓN ............................................................................................................. 258
7.8.2 PROPÓSITO .................................................................................................................... 258
7.8.3 OBJETIVOS ..................................................................................................................... 259
7.8.4 ALCANCE........................................................................................................................ 259
7.8.5 ESCALAS DE TIEMPO ...................................................................................................... 260
7.8.6 MODELOS DE INCIDENCIAS ........................................................................................... 260
7.8.7 INCIDENCIAS MAYORES ................................................................................................. 261
7.8.8 ACTIVIDADES ................................................................................................................. 261
7.9 PETICIONES DE SERVICIO ........................................................................................... 265
7.9.1 INTRODUCCIÓN ............................................................................................................. 265
7.9.2 PROPÓSITO .................................................................................................................... 265
7.9.3 OBJETIVOS ..................................................................................................................... 266
7.9.4 ALCANCE........................................................................................................................ 266
7.9.5 MODELOS DE PETICIONES ............................................................................................. 266
7.10 GESTIÓN DE PROBLEMAS ........................................................................................ 268
7.10.1 INTRODUCCIÓN ........................................................................................................... 268
7.10.2 PROPÓSITO .................................................................................................................. 268
7.10.3 OBJETIVOS ................................................................................................................... 268
7.10.4 ALCANCE...................................................................................................................... 269
7.10.5 ACTIVIDADES REACTIVAS Y PROACTIVAS DE PROBELMAS .......................................... 270
7.10.6 SOLUCIÓN PROVISIONAL (WORKAROUND) ................................................................ 270
7.10.7 DEFINICIONES .............................................................................................................. 271
7.10.8 ACTIVIDADES ............................................................................................................... 271
7.11 GESTIÓN DE ACCESOS .............................................................................................. 276
7.11.1 INTRODUCCIÓN ........................................................................................................... 276
7.11.2 PROPÓSITO .................................................................................................................. 276

INDICE
7.11.3 OBJETIVOS ................................................................................................................... 276

7.11.4 ALCANCE...................................................................................................................... 277
7.11.5 DEFINICIONES .............................................................................................................. 277
7.12 CENTRO DE SERVICIO AL USUARIO (CSU) ................................................................. 280
7.12.1 INTRODUCCIÓN ........................................................................................................... 280
7.12.2 OBJETIVOS ................................................................................................................... 281
7.12.3 BENEFICIOS.................................................................................................................. 281
7.12.4 CSU LOCAL ................................................................................................................... 282
7.12.5 CSU CENTRALIZADO .................................................................................................... 283
7.12.6 CSU VIRTUAL ............................................................................................................... 284
7.12.7 CSU SIGUIENDO AL SOL Y ESPECIALIZADO ................................................................... 285
7.13 GESTIÓN TÉCNICA ................................................................................................... 287
7.13.1 INTRODUCCIÓN ........................................................................................................... 287
7.13.2 OBJETIVOS ................................................................................................................... 287
7.13.3 ACTIVIDADES ............................................................................................................... 288
7.14 GESTIÓN DE OPERACIONES TI .................................................................................. 290
7.14.1 INTRODUCCIÓN ........................................................................................................... 290
7.14.2 OBJETIVOS ................................................................................................................... 291
7.14.3 SUBFUNCIONES DE OPERACIONES TI .......................................................................... 292
7.15 GESTIÓN DE APLICACIONES ..................................................................................... 294
7.15.1 INTRODUCCIÓN ........................................................................................................... 294
7.15.2 OBJETIVOS ................................................................................................................... 294
7.15.3 CICLO DE VIDA DE UNA APLICACIÓN ........................................................................... 295
7.15.4 DESARROLLO DE APLICACIONES Y GESTIÓN DE APLICACIONES .................................. 297
8 MEJORA CONTINUA DEL SERVICIO ............................................................................... 299
8.1 INTRODUCCIÓN ........................................................................................................ 300

8.2 PROPÓSITO DE CSI .................................................................................................... 301
8.3 OBJETIVOS DE CSI ...................................................................................................... 302
8.4 ALCANCE DE CSI ........................................................................................................ 303
8.5 VALOR ...................................................................................................................... 304
8.6 LÍNEA BASE ............................................................................................................... 305
8.7 CICLO DE DEMING ..................................................................................................... 305
8.8 MODELO DE MEJORA CONTINUA .............................................................................. 307
8.9 PROPIEDAD DE CSI .................................................................................................... 309
8.10 REGISTRO DE CSI ..................................................................................................... 309
8.11 METRICAS ............................................................................................................... 310
8.12 FACTORES CRITICOS DE ÉXITO (CSF) ......................................................................... 310
8.13 PROCESO 7 PASOS DE MEJORA ................................................................................ 313
8.13.1 PROPOSITO .................................................................................................................. 313
8.13.2 OBJETIVOS ................................................................................................................... 313
8.13.3 ALCANCE...................................................................................................................... 313
8.13.4 ACTIVIDADES ............................................................................................................... 314

®
Fundamentos
1 – INTRODUCCIÓN

UNIDAD 1 – INTRODUCCIÓN ITIL®
TEMAS DE LA UNIDAD 1
 INTRODUCCIÓN
 PRESENTACIÓN DE LOS ALUMNOS
 OBJETIVOS DEL CURSO
 CARACTERÍSTICAS DE ITIL®
 MEJORES PRÁCTICAS DE GESTIÓN (BMP)
 MEJORES PRÁCTICAS DE ITIL®
 OBJETIVOS DE APRENDIZAJE
 ESQUEMA DE CERTIFICACIÓN

1 INTRODUCCIÓN
Esta guía de aprendizaje está Orientada a la certificación de fundamentos de ITIL®, aunque

bien es cierto que algunos de los contenidos incluidos son una pequeña ampliación del
material que nos encontraremos en los cursos de nivel más avanzado, tanto por la carrera del
Ciclo de Vida como por la de los Módulos de Capacidades.
Nuestra intención no es solo crear una guía basada en las buenas prácticas de ITIL® orientada a
la certificación, sino ir un poco más allá y ayudar a que el alumno entienda cual es el alcance
de estas prácticas y el impacto que pueden llegar a tener en un proveedor de servicio TI.
Gracias a la experiencia que hemos ido adquiriendo a lo largo de estos años, hemos
desarrollado este contenido que esperamos sea útil y cumpla las expectativas de todas las
personas que quieran introducirse en el ámbito de la Gestión del servicio basado en las
prácticas de ITIL®.
Esperamos y deseamos que estas páginas os ayuden a alcanzar sus objetivos en cuanto a la
formación y sea el inicio de una carrera culminada con la certificación de Experto en ITIL®.
En la mayoría de las páginas de esta guía existen espacios en blanco en la parte inferior para
tomar anotaciones importantes realizadas por los formadores. Recuerde la importancia de:
 SER PUNTUALES
 MANTENER LOS DISPOSITIVOS MÓVILES EN SILENCIO
 INVOLUCRARSE EN EL CURSO
Y por supuesto:
 PREGUNTAR.

1.1 PRESENTACIÓN DE LOS ALUMNOS
Antes de empezar la formación es conveniente que nos conozcamos todos, haciendo una
pequeña presentación de nuestra experiencia, conocimientos, objetivos etc..
Las experiencias de los alumnos son fundamentales en este tipo de formación, ya que junto
con la experiencia del formador nos dan una idea de que estamos haciendo en la actualidad y
que podríamos hacer en un futuro para poder aplicar las prácticas de itil® en nuestro día a día,
pero recordar:
“Esto es un curso y nuestro objetivo es aprender los fundamentos”.
Itil® son buenas prácticas y cada organización deberá establecer su propio criterio para
implementarlas.
 NOMBRE.
 EMPRESA.
 DESCRIPCIÓN DEL TRABAJO.
 EXPERIENCIA EN GESTIÓN DE SERVICIOS.
 OPINIÓN SOBRE ITIL®.
 OBJETIVOS A CONSEGUIR CON EL CURSO

1.2 OBJETIVOS DEL CURSO
El objetivo del certificado de Fundamentos de ITIL® en Gestión de los Servicios de TI es

certificar que el candidato ha obtenido el conocimiento de la terminología, la estructura y los
conceptos básicos de ITIL® y ha comprendido los principios fundamentales de las prácticas de
ITIL® para la Gestión del Servicio.
Como hemos mencionado anteriormente la implementación de ITIL® nunca seguirá un orden

que puedas encontrar en las guías oficiales de ITIL® , ni en esta publicación, pero si llegaras a
conocer todos los procesos, funciones, actividades, y conceptos que te ayudaran a saber cuál
es el mejor método de hacer esa implementación.
Recordar que este curso es el primer paso, en cuanto a las certificaciones y alcance de las
buenas prácticas. No pretendáis ser Expertos en ITIL® leyendo, estudiando y aprobando este
curso, pero si será una base muy sólida y fundamental para ir ampliando conocimientos en la
materia.

1.3 CARACTERÍSTICAS DE ITIL®
 Mejores prácticas para la gestión de servicios de TI.

 Orientación al proveedor en la prestación de servicios con calidad.
 Marco más amplio reconocido dentro de ITSM.
 No es un estándar.
 El estándar mundial es ISO 20000
 2007 (Segunda Actualización).
 2011 (Tercera actualización).
ITIL® es parte de una serie de publicaciones de mejores prácticas para la gestión de servicios
de TI. Proporciona orientación a los proveedores de servicios en la prestación de servicios de TI
de calidad, y en los procesos, funciones y otras capacidades necesarias para apoyarlos.
ITIL® es utilizado multitud de organizaciones de todo el mundo y ofrece orientación sobre las
mejores prácticas a todos los tipos de organizaciones que prestan servicios.
ITIL® no es un estándar mundial, es una guía que debe ser leída y comprendida, y se utiliza
como creación de valor para el proveedor de servicios y sus clientes.
ITIL® es el marco más amplio reconocido por ITSM en el mundo y En los 20 años desde su
creación, ha evolucionado y cambiado su amplitud y profundidad igual que las tecnologías y
prácticas de negocios se han ido desarrollando.
ISO / IEC 20000 proporciona un estándar formal y universal para las organizaciones que buscan
tener sus capacidades de gestión de servicios auditados y certificadas. ISO / IEC 20000 es un
estándar e ITIL® ofrece un conjunto de conocimientos útiles para la consecución de la norma.
En 2007, se publica seguramente la actualización más importante de ITIL® en respuesta a los

avances significativos en la tecnología y los nuevos retos para los proveedores de servicios de
TI. Nuevos modelos y arquitecturas como la subcontratación, servicios compartidos, cloud
computing, virtualización, los servicios web y el comercio móvil, los cuales se han generalizado
dentro de TI.
En 2011, como parte de su compromiso con la mejora continua, la Cabinet Office publicó esta
actualización mejorando los conceptos de la versión anterior e incorporando un mejor
entendimiento de las prácticas de ITIL®.

1.4 MEJORES PRÁCTICAS DE GESTIÓN (BMP)
Es importante tener en cuenta que ITIL® está alineado con múltiples prácticas de Gestión y
todas ellas son válidas a la hora de implementarlas complementando la Gestión del Servicio.
El siguiente cuadro representa un ejemplo de Prácticas dentro del ámbito de la Gestión:
 MoR® (Risk Management of Risk) ofrece un marco para la administración de riesgos,

teniendo en cuenta los aspectos diferentes de una organización
 El MoV® (Management of Value) ofrece orientación sobre maximizar el valor y hacer

mejor uso de los recursos
 P3O®. (Portfolio,Programme and Project Offices) ofrece orientación para realizar

proyectos y programas enfocados a los objetivos estratégicos de la organización
 MoP® (Management of Portfolios) ofrece orientación sobre manejar o cambiar

proyectos y programas
 MSP® (Managing Successful Programmes) consiste en un grupo de procesos y

principios que pueden ser usados en Gestión de Programas

2 MEJORES PRÁCTICAS DE ITIL®
A la hora de entender el concepto de ITIL® y asimilar lo que puede aportar su implementación

a una organización es importante tener una idea global de lo que significa y el impacto que va
a tener en el proveedor de Servicios.
Una consideración importante es tener en cuenta que sin la implicación de la dirección de la

organización en las Unidades de Negocio o Departamentos de TI, están buenas prácticas no
tendrán éxito.
Este cuadro nos indica aspectos fundamentales en la implementación de ITIL® y el impacto que
va a tener en las personas, procesos y la tecnología.

2.1 OBJETIVOS DE APRENDIZAJE
Durante la formación se hará referencia a muchos conceptos y todos ellos son clave a la hora
de entender el alcance de ITIL®. Este es una breve lista de objetivos que pretendemos
entender durante el curso.
 Gestión del Servicio. Comprender la definición y significado de este concepto
 Ciclo de Vida del Servicio. La propia gestión del servicio se basa en él y son
seguramente los primeros conceptos que deberemos aprender.
 Principios y Modelos Clave. ITIL® se fundamenta en una

serie de principios y modelos, que nos ayudaran a entender
la Gestión del servicio
 Conceptos Genéricos. Son muchos pero fáciles de asimilar.
 Procesos Seleccionados. Después del Ciclo de Vida, será

fundamental tener en mente todos los procesos incluidos.
 Roles Seleccionados. Es fundamental la definición de Roles.

Definir la estructura Organizativa de una compañía ayudara
a vencer muchos retos en cuanto a las responsabilidades.
 Funciones Seleccionadas. La parte Humana unida a la

tecnología.
 Tecnología y Arquitectura. TI sin Tecnología no se concibe.

ITIL® no aconseja ni patrocina ninguna herramienta, pero
las tenemos que tener en cuenta para Gestionar los
servicios
 Esquema de Cualificaciones. La carrera de ITIL® es importante para aquello que

quieran avanzar en el mundo de las buenas prácticas. El punto siguiente de la guía nos
asesorara sobre cómo realizarla.

2.2 ESQUEMA DE CERTIFICACIÓN
Este esquema representa la carrera para alcanzar la certificación de Experto en ITIL® y con
experiencia y un poco más de preparación llegaremos a ser Master en ITIL®.
La primera certificación es esta que estamos realizando. El examen consiste en 40 preguntas

tipo test, de las cuales tendremos que responder bien un mínimo de 26 respuestas para
aprobar, lo que corresponde a un 65%.
Una vez aprobado este examen podremos decidirnos por dos vías: Los 5 Módulos del Ciclo de
Vida o los 4 módulos de Capacidades, cuyo examen consiste en 8 escenarios y 4 respuestas
posibles en cada uno. La mejor opción serán 5 puntos, la segunda mejor opción 3, la tercera 1
punto y todos los escenarios tienen una respuesta errónea con 0 puntos. En estos exámenes la
puntuación mínima para aprobar son 28 puntos, lo que equivale a un 70%.

Cuando hayamos completado cualquiera de los dos módulos u obtenido los créditos
suficientes entre los dos (Cuidando la compatibilidad entre los dos módulos), podremos
realizar el MALC (Certificado Gestionando a través del Ciclo de Vida). Esta vez nos enfrentamos
a 10 preguntas de 4 respuestas cada una, referente a un escenario común. La puntuación
mínima para aprobar son 35 puntos, lo que equivale a un 70%.
Para obtener la certificación Master en Itil® no existe examen. Se deberán cumplir una serie de
requisitos como ser Experto en ITIL® y una experiencia mínima de 5 años desarrollando labores
de Líder o Gerente en el ámbito de las TIC.
MODULOS DEL CICLO DE VIDA
 SS. Estrategia del Servicio

 SD. Diseño del Servicio
 ST. Transición del Servicio
 SO. Operación del Servicio
 CSI. Mejora Continua del Servicio
MODULOS DE CAPACIDADES
 OSA. Soporte y Análisis Operacional

 PPO. Planificación, Protección y Optimización
 RCV. Versión, Control y Validación
 SOA. Ofertas y Acuerdos de Servicio

UNIDAD 2 – GESTIÓN DEL SERVICIO COMO PRÁCTICA
Fundamentos
2-GESTIÓN DEL SERVICIO COMO PRÁCTICA

 MEJORES PRÁCTICAS EN EL DOMINIO PÚBLICO

 ÉXITO DE ITIL®
 SERVICIO Y SERVICIO TI
 SERVICIO Y PRODUCTO
 TIPOS DE SERVICIOS
 GESTIÓN DEL SERVICIO
 GESTIÓN DEL SERVICIO TI
 RECURSOS Y CAPACIDADES
 ACTIVOS DEL SERVICIO Y ACTIVOS DEL CLIENTE
 TIPOS DE PROVEEDOR
 PARTES INTERESADAS EN LA GESTIÓN DEL SERVICIO
 PROCESOS
 FUNCIONES
 ROLES
 COMPETENCIAS Y HABILIDADES
 COMPETENCIA Y MARCO DE HABILIDADES
 FORMACIÓN
 MODELO RACI
 GOBIERNO
 RIESGO
 RIESGOS Y COSTES

2 GESTIÓN DEL SERVICIO COMO PRÁCTICA
En esta unidad veremos todos los conceptos básicos y definiciones necesarios para profundizar
en todos los demás aspecto del curso.
Aprenderemos que es un servicio y la diferencia con producto así como los tipos de servicio
que podemos ofrecer. Es importante tener claro los tipos de proveedores que nos podemos
encontrar en las organizaciones y que son los activos que nos van a permitir entregar los
servicios requeridos.
El núcleo de ITIL® se basa en los procesos y las funciones por lo tanto es importantísimo saber
la diferencia entre ambos así como los roles principales que deben intervenir y las partes
interesadas dentro de cada ámbito.
Acabaremos esta Unidad entendiendo como podemos asignar los roles comentados
anteriormente y la importancia de entender y saber gestionar los riegos.

2.1 MEJORES PRÁCTICAS EN EL DOMINIO PÚBLICO
Para hacer frente a la presión que sufren las empresas como, clientes internos, clientes
externos, mercados, competencia, conformidad con normas reguladoras, etc.., las propias
organizaciones se comparan con sus homólogos y buscan cerrar los gaps en sus capacidades.
Una forma de cerrar tales gaps es la adopción de buenas prácticas de uso generalizado en la
industria. Existen muchas fuentes de buenas prácticas entre las que se incluyen marcos de
trabajo públicos, estándares y el conocimiento propietario de las organizaciones y los
individuos.

2.2 ÉXITO DE ITIL®
ITIL® abarca un enfoque práctico para la gestión del servicio, básicamente hacer lo que
funciona. Y lo que funciona es la adaptación de un marco común de las prácticas que unen a
todas las áreas de prestación de servicios de TI hacia un único objetivo: Entregar valor al
Negocio. La siguiente lista define las características clave de ITIL que contribuyen a su éxito
mundial:
 Independiente del Proveedor. Las prácticas de gestión de servicios ITIL son aplicables
en cualquier organización de TI, ya que no se basan en una plataforma tecnológica o
tipo de industria.
 No prescriptivo. Prácticas robustas, maduras y probadas en el tiempo, que son

aplicables a todo tipo de organizaciones de servicios.
 Mejores Prácticas. ITIL representa las experiencias de aprendizaje y liderazgo

intelectual de los mejores proveedores de servicios del mundo.
ITIL® tiene éxito porque describe las prácticas que permiten a las organizaciones ofrecer
beneficios, retorno de la inversión y sostenibilidad.
ITIL® permite a las organizaciones:
 Entregar valor a los clientes a través de servicios

 Integrar la estrategia de servicios con la estrategia de negocio y las necesidades
del cliente
 Medir, Monitorizar y optimizar los servicios de TI y desempeño de los
proveedores de servicios
 Administrar la inversión en TI y el presupuesto
 gestionar el riesgo
 gestionar el conocimiento
 Administrar las capacidades y los recursos para prestar servicios con eficacia y
eficiencia
 Permitir la adopción de un enfoque estándar para el servicio de gestión en toda
la Organización
 Cambiar la cultura de la organización para apoyar el logro del éxito sostenido
 Mejorar la interacción y la relación con los clientes
 Coordinar la entrega de bienes y servicios a través de una red de valor
 Optimizar y reducir los costos.

2.3 SERVICIO Y SERVICIO TI
Los servicios son un medio de entrega de valor a los clientes facilitando los resultados que los
clientes desean lograr sin la responsabilidad de costes y riesgos específicos. Los resultados se
obtienen a través del desempeño de tareas y se ven limitados por la presencia de ciertas
restricciones. En líneas generales, los servicios proporcionan resultados mediante la mejora del
rendimiento y la reducción de las limitaciones de las restricciones. El resultado es un
incremento de las posibilidades de obtener los resultados deseados. Aunque algunos servicios
mejoran el desempeño de las tareas, otros presentan un efecto más directo. Realizan la propia
tarea.
 Servicio. Es un medio de entrega de valor a los clientes facilitando los resultados que
los clientes desean lograr sin la responsabilidad sobre los costes y riesgos específicos.
 Servicio TI. Está formado por las tecnologías de la información, personas y procesos.
Un Proveedor de Servicios de TI ofrece este servicio a uno o más clientes para prestar
apoyo a sus procesos de negocio.

2.4 SERVICIO Y PRODUCTO
La siguiente tabla muestra las diferencias entre un Servicio y un producto.
Servicio Producto
• Interacciones dinámicas entre proveedor • Son entidades físicas que se producen por
de servicios y cliente. tratamiento de materias primas o el montaje
de componentes.
• Se proporcionan en tiempo real ya que los • Son creados en cualquier momento y se

clientes los necesitan y los utilizan. almacenan antes de su distribución al cliente.
• Se producen y consumen al mismo tiempo • Se producen por una entidad y pueden ser
y no pueden ser separados de sus almacenados, distribuidos y vendidos por
proveedores. diferentes entidades en diferentes momentos.
• La salida de un servicio es volátil, • La salida de la producción es predecible, y los

cambiando a menudo en tiempo real en productos no debe desviarse de una norma
función del entorno del cliente predefinida.
• El valor de un servicio sólo se percibe • El valor se percibe cada vez que cambia de
cuando está siendo utilizado por un manos.
cliente.

2.5 TIPOS DE SERVICIOS
 Servicios Internos. Son los que prestamos dentro de la misma organización. El valor
que recibimos suele traducirse en inversión de Recursos y Capacidades.
 Servicio Externos. Son los servicios que prestamos para una Organización externa y el
tipo de Retorno suele ser económico
 Servicios de Soporte. Es un servicio que no usa directamente el Negocio, pero si es

requerido por el proveedor para prestar otros tipos de Servicio, como pueden ser los
servicios de Directorios o los servicios de Redes de Comunicación

Todos los servicios, ya sean internos o externos, pueden clasificarse en términos de cómo se
relacionan entre sí y sus clientes. Los servicios pueden ser Principales, de Apoyo y de Mejora
como se muestra en la siguiente tabla.
Tipos de servicios
Principales • Entregan los resultados básicos deseados por uno a más clientes.
Apoyo • Son necesarios para que un servicio básico sea entregado.

• Pueden o no ser visibles para el cliente, pero no los percibe como servicio en pleno
derecho.
• Son factores básicos que permiten al cliente recibir el servicio principal.
Mejora • Hacen que un servicio sea más atractivo para el cliente.

• No son esenciales para la prestación del servicio.
• Estimulan al cliente a usar un servicio principal

2.6 GESTIÓN DEL SERVICIO
 Gestión del Servicio. Un conjunto de capacidades organizativas especializadas para

proporcionar valor a los clientes en forma de servicios
Las capacidades adoptan la forma de funciones y procesos para gestionar servicios durante un
ciclo de vida, con especializaciones en estrategia, diseño, transición, operación y mejora
continua. Las capacidades representan la capacidad, competencia y confianza de acción de una
organización del servicio. El acto de transformación de recursos en servicios de valor se
encuentra en el centro de la gestión del servicio. Sin estas capacidades, una organización del
servicio es simplemente un conjunto de recursos que, por sí mismos, tienen un valor intrínseco
relativamente bajo para los clientes.
 Proveedor de Servicios. Una organización que suministra servicios a uno o más

clientes internos o externos
2.7 GESTIÓN DEL SERVICIO TI
 Gestión de Servicios TI (ITSM). La implantación y gestión de los servicios de TI de

calidad que satisfacen las necesidades del negocio. La gestión de servicios de TI la
realizan los proveedores de servicios de TI mediante la mezcla apropiada de personas,
procesos y tecnología de la información.
 Proveedor de Servicios TI. Una Proveedor proporciona servicios TI a uno o más

clientes internos o externos

2.8 RECURSOS Y CAPACIDADES
Los recursos y capacidades son tipos de activos. Las organizaciones los utilizan para crear valor
en forma de bienes y servicios. Los recursos son entradas directas para la producción. La
gestión, la organización, las personas y el conocimiento sirven para transformar los recursos.
Las capacidades representan la aptitud de una organización para coordinar, controlar y
desplegar los recursos para generar valor. Normalmente están impulsados por la experiencia,
son intensos en conocimiento, se basan en la información y se integran firmemente dentro de
las personas, los sistemas, los procesos y las tecnologías de la organización. Resulta
relativamente sencillo adquirir recursos en comparación con las capacidades.
Las Capacidades se desarrollan a lo largo del tiempo y sin recursos no generan valor. Por otro
lado, los recursos son entradas directas para la producción.

2.9 ACTIVOS DEL SERVICIO Y ACTIVOS DEL CLIENTE
 Activo. Cualquier Recurso o Capacidad
 Activos del Servicio. Cualquier Recurso o Capacidad usado por el Proveedor de

Servicios a la hora de entregar servicios al cliente.
 Activos del cliente. Cualquier Recurso o Capacidad del cliente que utiliza para lograr
los resultados de Negocio
En este diagrama se muestra como los activos del Servicio del Proveedor Incrementan el
potencial de rendimiento del Servicio y el rendimiento de la Unidad negocio, obteniendo
demanda para utilizar la capacidad no usada o invertir en Recursos o Capacidades.

2.10 TIPOS DE PROVEEDOR
Es necesario diferenciar entre los distintos tipos de proveedores de servicio. Aunque la

mayoría de los aspectos de la gestión del servicio se aplican de forma similar a todos los tipos
de proveedores de servicio, otros aspectos como los clientes, los contratos, la competencia, los
mercados, los ingresos y la estrategia adoptan significados diferentes en función del tipo.
Existen tres arquetipos de modelos de negocio de proveedores de servicio:
 Tipo I - Proveedor de servicio Interno

 Tipo II - Unidad de Servicios Compartidos
 Tipo III - Proveedor de Servicio Externo
 Proveedor de servicio Interno. Los proveedores del Tipo I son habitualmente

funciones de negocio integradas dentro de las unidades de negocio a las que sirven.
Las propias unidades de negocio pueden formar parte de una empresa u organización
principal más grande. Las funciones de negocio, como finanzas, administración,
logística, recursos humanos y TI proporcionan servicios que solicitan diferentes partes
del negocio. Están financiadas por los gastos generales y deben operar estrictamente
dentro de los mandatos del negocio.
Los proveedores de Servicio Interno cuentan con la ventaja de estar fuertemente

vinculados con su propietario-clientes, lo que evita ciertos costes y riesgos asociados
con la realización de la actividad de negocio con partes externas.

 Unidad de Servicios Compartidos. Funciones como finanzas, TI, recursos humanos y

logística no siempre se encuentran en el centro de la ventaja competitiva de una
organización. Por consiguiente, no es necesario mantenerlas dentro del nivel
corporativo en el que se requiere la atención del equipo del presidente ejecutivo." En
lugar de esto, los servicios de estas funciones compartidas se consolidan en una
unidad autónoma especial que se denomina unidad de servicios compartidos (SSU).
Este modelo permite una estructura de gobierno más descentralizada en la que la SSU
puede centrarse en el servicio a las unidades de negocio como clientes directos.
 Proveedor de Servicio Externo. Las estrategias de negocio de los clientes a menudo

requieren capacidades fácilmente disponibles de un proveedor de Servicio Externo.
Los riesgos adicionales que los proveedores de Tipo III asumen con respecto a los de
Tipo I y Tipo II se justifican por el incremento de la flexibilidad y la libertad para buscar
otras oportunidades.
Los proveedores de Tipo III pueden ofrecer precios competitivos y reducir los costes
unitarios mediante la consolidación de la demanda. Ciertas estrategias de negocio no
son cubiertas de forma adecuada por proveedores de servicio de Tipo I y Tipo II. Los
clientes pueden seguir estrategias de aprovisionamiento que requieran servicios de
proveedores externos. La motivación puede ser el acceso a conocimiento, experiencia,
escala, ámbito, capacidades y recursos que se encuentran fuera del alcance de la
organización o fuera del ámbito de una cartera de inversiones cuidadosamente
pensada.

Las estrategias de negocio requieren con frecuencia reducciones en la base de activos,

costes fijos, riesgos operativos o la redistribución de activos financieros. Los entornos
de negocio competitivos a menudo requieren que los clientes tengan estructuras
flexibles y ajustadas. En tales casos, es preferible adquirir servicios en lugar de poseer y
operar los activos necesarios para ejecutar ciertas funciones y procesos de negocio.
2.11 PARTES INTERESADAS EN LA GESTIÓN DEL SERVICIO
Las partes interesadas o “Stakeholders” son las que tienen algún tipo participación en una
organización, proyecto, servicio, etc., y pueden estar interesados en las actividades, objetivos,
recursos o resultados de la gestión del servicio.
Pueden ser las organizaciones, proveedores de servicios, clientes, consumidores, usuarios,

socios, empleados, accionistas, propietarios y proveedores externos.
Partes Interesadas Externas
Clientes • Compran bienes o Servicios.

• Persona o Grupo que define y acuerda los objetivos de Nivel de Servicio.
• A veces se les llama informalmente Usuarios cuando utilizan el servicio.
Usuarios • Personas que utilizan el servicio a diario.

• Los usuarios son distintos de los clientes, ya que algunos clientes no utilizan el
servicio directamente.
Suministradores • Son terceras partes responsables de suministrar los productos o Servicios

necesarios para ofrecer Servicios de TI.

2.12 PROCESOS
 Proceso. Conjunto estructurado de actividades diseñado para lograr un objetivo

específico.

Los Procesos definen acciones, dependencias y secuencias. Si están bien definidos pueden
mejorar la productividad de las organizaciones y de las funciones .Los procesos tienen las
siguientes características:
Características
Medibles • Podemos medir el proceso de una forma apropiada

• Orientado al rendimiento
Obtienen resultados • Existen para obtener resultados

Específicos • Identificable y cuantificable
Orientados al cliente • Entregan el resultado a un cliente

• Satisface las expectativas
Responden a eventos • Aunque puede ser continuo o iterativo, debe ser fácil definir un
Específicos disparador concreto

2.13 FUNCIONES
Una función es un equipo o grupo de personas y las herramientas u otros recursos que utilizan
para llevar a cabo uno o más procesos o actividades.
En las organizaciones más grandes, una función puede ser llevada a cabo por varios
departamentos, equipos y grupos, o puede ser realizada dentro de una sola unidad de
organización. En las organizaciones más pequeñas, una persona o grupo puede realizar
múltiples funciones, por ejemplo, un departamento de gestión técnica también podría
incorporar la función de CSU (Centro de Servicio al Usuario).
Para que el Ciclo de Vida del Servicio tenga éxito, una organización tendrá que definir
claramente las funciones y responsabilidades necesarias para llevar a cabo los procesos y
actividades que intervienen en cada una de sus etapas, para ello, asignar roles será
fundamental. También necesitara establecer y administrar una estructura de la organización
definiendo equipos, grupos, etc., como se muestra en la siguiente tabla:
Grupo • Número de personas que realizan actividades similares.

• Diferentes tecnologías, estructuras o empresas.
Equipo • Grupo más formal.

• Trabajan en conjunto, juntos o en múltiples ubicaciones (desarrollo de
aplicaciones).
Departamento • Estructuras organizativas formales.

• Ordenadas jerárquicamente.
División • Un número de departamentos agrupados.
 Grupo. Número de personas que son similares de alguna manera. En ITIL, los grupos se
refieren a las personas que realizan actividades similares - a pesar de que pueden
trabajar en diferentes tecnologías o informe en diferentes estructuras organizativas o
incluso diferentes empresas.
Los grupos normalmente no son estructuras organizativas formales, pero son muy
útiles en la definición de los procesos comunes a través de la organización - por
ejemplo, asegurar que todas las personas que resuelven incidentes completar el
registro de incidentes de la misma manera.
 Equipo. Es un tipo más formal de grupo. Estas son las personas que trabajan en
conjunto para lograr un objetivo común, pero no necesariamente en la misma
estructura organizativa. Los miembros del equipo pueden ser colocados junto a, o
trabajar en múltiples ubicaciones y operan de forma virtual. Los equipos son útiles
para la colaboración, o para hacer frente a una situación de carácter temporal o
transitorio. Ejemplos de equipos incluyen equipos de proyecto, los equipos de

desarrollo de aplicaciones (a menudo compuesto por personas de varias unidades de

negocio diferentes) y los equipos de incidentes o de resolución de problemas.
 Departamentos. Son las estructuras organizativas formales que existen para llevar a
cabo un conjunto específico de actividades definidas en forma permanente.
Departamentos tienen una estructura de información jerárquica con los gerentes que
son generalmente responsables de la ejecución de las actividades, así como para la
gestión del día a día de los empleados en el departamento.
 División. Se refiere a un número de departamentos que se han agrupado juntos,

a menudo por la geografía o línea de productos. Una división es normalmente
autónomo.

2.14 ROLES
 Rol. Conjunto de responsabilidades, actividades o autorizaciones otorgadas a una

persona o a un equipo. Un Rol se define en un proceso o en una función.
Los roles se confunden a menudo con títulos de trabajo, pero es importante entender que no
son lo mismo. Cada organización definirá los títulos de trabajo apropiados y descripciones de
trabajo que se ajusten a sus necesidades, y los individuos que sostienen estos títulos de
trabajo puede llevar a cabo una o más Roles.
A continuación vamos a definir los roles genéricos más comunes que propone ITIL®.
Características
Propietario del Servicio • Es el responsable de la prestación de un servicio específico de TI.

• Es el máximo responsable ante el cliente
Propietario del Proceso • Es el responsable de asegurar que el proceso se lleva a cabo de

acuerdo con los estándares acordados, y cumple con los objetivos
definidos
Gestor del Proceso • Es el responsable de la gestión operativa del proceso.

• En algunas organizaciones puede ser el propietario del proceso
Participante del Proceso • Es el responsable de llevar a cabo una o más actividades del
proceso.
• En algunas organizaciones puede ser el Gestor del Proceso
 Propietario del servicio. Es responsable de la prestación de un servicio específico de

TI. El propietario del servicio es responsable ante el cliente para el inicio, la transición y
el mantenimiento continuo y el apoyo de un determinado servicio y responsable ante
el director de TI o el director de gestión de servicios para la prestación del servicio.
La responsabilidad del propietario del servicio para un servicio específico dentro de
una organización es independiente de la que los componentes de tecnología
apuntalamiento, procesos o capacidades profesionales residen. Propiedad El servicio
es tan crítica para la gestión de servicios como el establecimiento de la propiedad para
procesos que atraviesan múltiples silos verticales o departamentos. Es posible que una
sola persona puede cumplir el servicio
 Dueño del proceso. Responsable de asegurar que un proceso es adecuado para el

propósito. Esta función a menudo se asigna a la misma persona que lleva a cabo el
papel gestor de procesos, pero los dos papeles puede ser separada en mayor
organización de. El papel dueño del proceso es responsable de asegurar que el proceso
se lleva a cabo de acuerdo con el estándar acordado y documentado y cumple con los
objetivos de la definición del proceso.

 Gestor de procesos. Responsable de la gestión operativa de un proceso. Puede haber

varios gerentes de procesos para un proceso, por ejemplo, gestores del cambio
regionales o administradores de continuidad de servicios de TI para cada centro de
datos. El papel gestor de procesos a menudo se asigna a la persona que lleva a cabo el
papel dueño del proceso, pero las dos funciones puede ser separada en organizaciones
más grandes.
 Participante del Proceso. Responsable de llevar a cabo una o más actividades del
proceso. En algunas organizaciones, y para algunos procesos, el papel Participante del
proceso se puede combinar con el papel de Gestor de procesos, en otras puede haber
un gran número de profesionales que llevan a cabo las diferentes partes del proceso.

2.15 COMPETENCIAS Y HABILIDADES
Los roles específicos dentro de Gestión del Servicio de ITIL requieren habilidades, atributos y
competencias de las personas implicadas para permitirles trabajar eficaz y eficientemente. Sin
embargo, independientemente de su rol, es importante que la persona que lleva a cabo ese
papel tenga las siguientes cualidades:
Atributos
Habilidades de gestión • Desde la perspectiva de gestión de una persona y desde la
perspectiva del control general del proceso
Habilidades de reunión • Para organizar, coordinar, documentar y garantizar que se realicen
las actividades
Comunicaciones • Será fundamental disponer de la capacidad para comunicarse en
todos los niveles dentro de la organización
Lenguaje articulado • Tanto por escrito, para informes, etc., y verbal

Negociación • Requerida para varios aspectos, como por ejemplo compras y
contratos
Analítico • Para analizar métricas generadas de la actividad.

2.16 COMPETENCIA Y MARCO DE HABILIDADES
Normalizar los títulos de trabajo, funciones, roles y responsabilidades pueden simplificar la

gestión del servicio y la gestión de recursos humanos. Muchos proveedores de servicios
utilizan un marco común de referencia para las competencias y habilidades a la hora de
apoyar actividades tales como, la planificación de las necesidades futuras, programas de
desarrollo de la organización y asignación de recursos. Por ejemplo, los modelos de recursos y
costes son más simples y más fáciles de usar si los trabajos y roles son estándar.
El Marco de Habilidades para la Era de la Información (SFIA) es un ejemplo de un modelo de

referencia común para la identificación de las habilidades necesarias para desarrollar servicios
de TI eficaces, sistemas de información y tecnología. SFIA define siete niveles genéricos y qué
tareas se pueden realizar, con las competencias profesionales asociadas requeridas para cada
nivel.
2.17 FORMACIÓN
La formación en gestión de servicios ayuda a los proveedores de servicios a construir y

mantener su capacidad de gestión del servicio.
Las necesidades de formación deben adaptarse a los requisitos para ser competentes y
favorecer el desarrollo profesional.

2.18 MODELO RACI
La matriz RACI, se utiliza a menudo dentro de las organizaciones, para definir las funciones,
responsabilidades en relación con los procesos y actividades.
Definiciones claras de rendición de cuentas y las responsabilidades son esenciales para la

gestión de un servicio efectivo.
Para ayudar con esta tarea el modelo RACI o "matriz de autoridad" se utiliza a menudo dentro
de las organizaciones con el fin de asegurar las funciones y responsabilidades en relación con
los procesos y actividades.
La matriz RACI ofrece un método fácil, conciso y compacto, de seguimiento indicando quién
hace qué en cada proceso y permitiendo que se tomen decisiones con confianza.
La Matriz RACI es acrónimo de Responsible, Accountable, Consulted e Informed y ayuda a

definir la estructura Organizativa de una compañía.
Responsable • Persona responsable de la ejecución del trabajo
Accountable • Responsable del resultado final.

• Rendición de cuentas
Consulted • Personas consultadas sobre aspectos de una actividad, en busca de una opinión.
Informed • Personas informadas sobre el progreso de una actividad
 Responsable. La persona o personas responsables de la ejecución correcta del trabajo
 Accountable. La persona que tiene la propiedad de calidad y el resultado final. Sólo

una persona puede ser Accountable de cada tarea
 Consulted. Las personas que son consultados en busca de una opinión. Ellos tienen
la participación a través de la entrada de conocimientos e información
 informed. Las personas que se mantienen al día sobre los avances. Ellos reciben
información acerca de la ejecución de procesos y calidad.
La siguiente tabla muestra un ejemplo de cómo se aplicaría la Matriz RACI a un conjunto de

actividades

Director de Gestor de Nivel de Gestor de Gestor de Gestor de

Gestión de Servicio Problemas Seguridad Proveedores
Servicios
Actividad 1 AR C I I C
Actividad 2 A R C C C
Actividad 3 I A R I C
Actividad 4 I A R I I
Actividad 5 I R A C I

2.19 GOBIERNO
El Gobierno asegura que las políticas y la estrategia están implementadas, y que los procesos
requeridos se ejecutan correctamente.
El Gobierno define funciones y responsabilidades. Mide, informa, y toma medidas para

resolver los problemas identificados
El gobierno es la zona global única que une TI y Negocio, y los servicios son una forma de
garantizar que la organización es capaz de ejecutar y cumplir las normas de Gobierno.
El gobierno es quien define la dirección, políticas y normas que tanto el negocio y TI utilizan
para realizar negocios. Muchas estrategias de ITSM fracasan porque tratan de construir una
estructura o procesos de acuerdo a cómo les gustaría que la organización trabaje en vez de
trabajar dentro de las estructuras de gobernanza existentes.

2.20 RIESGOS
El riesgo habitualmente se percibe como algo a evitar debido a su vinculación con las
amenazas. Aunque esto es cierto en general, el riesgo también puede vincularse con la
oportunidad. El fallo a la hora de aprovechar las oportunidades es un riesgo en sí mismo.
43
Los costes de oportunidad de los mercados marginados y de la demanda insatisfecha es un

riesgo a evitar. El Porfolio de Servicios puede corresponderse con un portfolio subyacente de
riesgos que se debe gestionar. Cuando la gestión del servicio es eficaz, los servicios en el
Catálogo y Flujo de creación representan oportunidades para crear valor para los clientes y
capturar valor para los interesados. De lo contrario, esos servicios pueden ser amenazas que
surjan de la posibilidad de fallo vinculada a los patrones de demanda que atraen, los
compromisos que requieren y los costes que generan. La implementación de estrategias
requiere en muchos casos cambios en el Porfolio de Servicios, que implican la gestión de los
riesgos asociados.
Existen 3 etapas fundamentales para tratar los riegos en una Organización:
Identificación del riesgo • Es la parte donde identificamos el riego pero no es necesario

cuantificarlo
Análisis del riesgo • Cuantificamos el impacto y la probabilidad
Gestión del riesgo • Establecemos las medidas adecuadas

2.21 RIESGOS Y COSTES
El cliente está principalmente interesado en el resultado que va a recibir relacionando precio y

Fiabilidad sin preocuparse por los costes y riesgos específicos a los que el proveedor del
servicios deberá hacer frente, con el fin de prestar el servicio.
El cliente sólo estará expuesto al precio total del servicio, que incluirá todos los costes del
proveedor y las medidas de mitigación de riesgos. El cliente puede entonces juzgar el valor de
servicio basado en una comparación de precio y fiabilidad con el resultado deseado.
Una buena relación entre un proveedor de servicios y sus clientes se basa en el cliente que
recibe un servicio que satisfaga sus necesidades, a un nivel aceptable de rendimiento y a un
coste que se pueda permitir. El proveedor de servicios tiene que encontrar la manera de lograr
un equilibrio entre estas tres áreas, y comunicarse con el cliente si hay algo que les impide
poder prestar el servicio al nivel requerido de rendimiento o precio.
Alterar cualquier lado del triángulo implicara el desequilibrio

de otro o ambos lados restantes. Menor precio implicara
menor rendimiento o menor funcionalidad y mayor
funcionalidad implicara mayor coste.

UNIDAD 3 – CICLO DE VIDA DEL SERVICIO
Fundamentos
3- CICLO DE VIDA DEL SERVICIO

 CICLO DE VIDA DEL SERVICIO

 INTEGRACIÓN A TRAVÉS DEL CICLO DE VIDA
 INTRODUCCIÓN A LA ESTRATEGIA DEL SERVICIO
 INTRODUCCIÓN AL DISEÑO DEL SERVICIO
 INTRODUCCIÓN A LA TRANSICIÓN DEL SERVICIO
 INTRODUCCIÓN A OPERACIÓN DEL SERVICIO
 INTRODUCCIÓN A LA MEJORA CONTINUA DEL SERVICIO (CSI)

3 CICLO DE VIDA DEL SERVICIO
El Núcleo de ITIL se compone de cinco FASES representadas en la siguiente figura. Cada una de
ellas proporciona la guía necesaria para un enfoque integrado, tal y como requiere la
especificación del estándar ISO/IEC 20000:
 Estrategia del Servicio

 Diseño del Servicio
 Transición del Servicio
 Operación del Servicio
 Mejora Continua del Servicio.
Cada fase se centra en las capacidades que representan un impacto directo en el rendimiento
de un proveedor de servicio. La estructura del núcleo se representa en la forma de un ciclo de
vida. Es iterativa y multidimensional. Garantiza que las organizaciones se configuren para
aprovechar las capacidades en un área para obtener aprendizaje y mejoras en otras.
Se espera que el núcleo proporcione estructura, estabilidad y fortaleza a las capacidades de

gestión del servicio con principios, métodos y herramientas duraderos. Esto sirve para
proteger las inversiones y proporcionar el fundamento necesario para medir, aprender y
mejorar.
La tabla de la siguiente hoja muestra una vista de todos los procesos y funciones de ITIL®.
Estudiar esta estructura nos ayudara a entender de mejor manera el ámbito de ITIL® .

Mejora continua
Estrategia Diseño Transición Operación
(CSI)
Gestión de la Estrategia de Coordinación del Planificación y

Gestión de Eventos 7 pasos de mejora
TI Diseño Soporte
Gestión del Catálogo de

Gestión de la demanda Gestión del Cambio Gestión de Incidencias
servicios
Gestión de la
Gestión de la Cartera o Gestión de Nivel de
Configuración y Gestión de Problemas
Portfolio del servicio servicio (SLM)
Activos del Servicio
Gestión Financiera de Gestión de Versiones y Gestión de Peticiones de

servicios TI Disponibilidad Despliegues servicio
Gestión de relaciones con

Gestión de Capacidad Validación y Pruebas Gestión de Accesos
el Negocio (BRM)
Evaluación del Función Centro de servicio al

Gestión de Continuidad
Cambio Usuario ( CSU)
Gestión del
Gestión de Seguridad Función Gestión Técnica
Conocimiento
Función Gestión de
Gestión de Proveedores
Operaciones
Función Gestión de
aplicaciones
Es importante saber que la estructura de esta tabla nos permite conocer los procesos y en qué
fase de vida puede tener su inicio o desarrollarse, pero lo principal es entender las entradas y
las salidas de los procesos así como que un proceso puede tener diferentes actividades en
distintas fases del Ciclo de vida.

3.1 INTEGRACIÓN A TRAVÉS DEL CICLO DE VIDA
Como hemos explicado en el punto anterior, cada fase del ciclo de vida de ITIL incluye
orientación sobre los procesos de gestión de servicios, como se muestra en la Tabla de
procesos.
La gestión de servicios es más eficaz si la gente tiene una idea clara de cómo los procesos
interactúan a lo largo del ciclo de vida del servicio, dentro de la organización y con otras partes
(usuarios, clientes, proveedores). La integración de procesos en todo el ciclo de vida del
servicio depende del propietario del servicio, los dueños del proceso, los profesionales de
proceso y otras partes interesadas para entender:
 El contexto de uso, alcance, finalidad y los límites de cada proceso
 Las estrategias, políticas y normas que se aplican a los procesos y la gestión de las
interfaces entre los procesos
 Autoridades y responsabilidades de las personas involucradas en cada proceso
 La información proporcionada por cada proceso que se deriva de un proceso a otro,

que la produce y cómo es utilizado por procesos integrados.
La integración de los procesos de gestión de servicios depende del flujo de información entre
ellos y los límites de la organización. Esto a su vez depende de la implementación de sistemas
de información de apoyo a la tecnología y la gestión a través de fronteras organizativas.
Si los procesos de gestión de servicios se implementan o cambian de forma aislada, pueden

convertirse en una carga burocrática que no entregue la relación calidad-precio esperada y
podrían dañar o anular la operación o el valor de otros procesos y servicios.
La siguiente figura muestra como es la integración y relaciones entre las diferentes fases del
Ciclo de Vida.


3.2 INTRODUCCIÓN A LA ESTRATEGIA DEL SERVICIO
A continuación enumeraremos una serie de puntos que caracterizan a las diferentes fases del
ciclo vida. Todas ellas se estudiaran con más profundidad en los temas asociados a cada una de
ellas.
 Es el Núcleo del ciclo de vida del servicio.
 La creación de valor comienza en esta fase.
 Comprensión de los objetivos organizacionales y necesidades del cliente.
 Cada activo organizacional, como personas, procesos y productos deben apoyar la

estrategia.
 Permite ver la gestión de servicios no sólo como una capacidad organizativa, sino
como un activo estratégico.
 Define las políticas de gestión de servicios y directrices
 Desarrollo de espacios de mercado.
 Objetivos y expectativas para servir a los clientes y los espacios de mercado
 Identificar, seleccionar y priorizar las oportunidades.
 Manejar los costos y riesgos asociados a sus carteras de servicios.
 Pensar por que hacer las cosas antes de cómo hacerlas

3.3 INTRODUCCIÓN AL DISEÑO DEL SERVICIO
 Diseñar servicios que ofrezcan valor en función a los objetivos de Negocio.
 Diseño abarca toda la organización TI, desde la creación hasta el soporte.
 Convierte la estrategia en un plan.
 Proporciona una guía para el diseño, el desarrollo y prácticas de gestión de servicios.
 Engloba los principios y métodos de diseño para convertir los objetivos. estratégicos
en las carteras de servicios y activos del servicio.
 El alcance del Diseño del Servicio son los nuevos servicios, cambios y mejoras
necesarias para aumentar o mantener el valor a los clientes, la continuidad de los
servicios, cumplimiento de los niveles de servicio, y la conformidad con las normas
regulatorias.

3.4 INTRODUCCIÓN A LA TRANSICIÓN DEL SERVICIO
 Transición del Servicio proporciona una guía para el desarrollo y la mejora de las
capacidades a la hora de introducir servicios nuevos y modificados en
entornos de producción.
 Cómo realizar la transición de una organización de un estado a otro
 Controlar los riegos
 Apoyar con el conocimiento las tomas de decisiones
 Asegurar que el valor identificado en la estrategia de servicio, y codificado en el diseño

del servicio, consigan una transición efectiva con el fin de realizar una correcta
operación del servicio.
 Evitar consecuencias no deseadas en relación a los cambios y a los procesos de gestión

de servicios
 Permitir la innovación
 Aprender y ayudar a mejorar la eficiencia y la eficacia

3.5 INTRODUCCIÓN A OPERACIÓN DEL SERVICIO
 Operación del Servicio orienta sobre el logro de la eficacia y la eficiencia
 La entrega y soporte de los servicios garantizando el valor para el cliente, los usuarios y
el proveedor de servicios.
 Los objetivos estratégicos se concretan a través de la operación del servicio.
 Mantener la estabilidad en la operación del servicio.

3.6 INTRODUCCIÓN A LA MEJORA CONTINUA DEL SERVICIO (CSI)
 Mejora Continua del Servicio proporciona orientación sobre la creación y el

mantenimiento de valor para los clientes a través de una mejor estrategia, diseño,
transición y operación del servicio.
 Combina principios, prácticas y métodos de gestión de la calidad, gestión del cambio y

mejora de capacidades.
 Mejora Continua del Servicio describe las mejores prácticas para lograr mejoras
incrementales y de gran escala, en la calidad del servicio, la eficiencia operativa y la
continuidad del negocio.
 Garantiza que la cartera de servicios sigue estando alineado con las necesidades del
negocio.
 Se proporciona orientación para vincular los esfuerzos de mejora y resultados con la

estrategia de servicio, diseño, transición y operación.
 La retroalimentación de cualquier etapa del ciclo de vida de servicio puede ser usada
para identificar oportunidades de mejora en cualquier otra etapa del ciclo de vida.

UNIDAD 4 – ESTRATEGIA DEL SERVICIO
Fundamentos
4 – ESTRATEGIA DEL SERVICIO

4 ESTRATEGIA DEL SERVICIO
 INTRODUCCIÓN DE LA ESTRATEGIA
 PROPÓSITO DE LA ESTRATEGIA
 OBJETIVOS DE LA ESTRATEGIA
 VALOR DE LA ESTRATEGIA
 VALOR DE UN SERVICIO
 UTILIDAD Y GARANTÍA
 PROCESO GESTION DE LA ESTRATEGIA DE TI
 PROCESO GESTIÓN DE LA CARTERA DE SERVICIOS (SPM)
 PROCESO GESTIÓN FINANCIERA DE SERVICIOS TI
 PROCESO GESTIÓN DE LA DEMANDA
 PROCESO ESTIÓN DE RELACIONES CON EL NEGOCIO (BRM)
 AUTOMATIZACIÓN DEL SERVICIO

4.1 INTRODUCCIÓN DE LA ESTRATEGIA
 La estrategia del Servicio proporciona la guía para diseñar, desarrollar e implementar

la gestión del servicio, no sólo como una capacidad organizativa, sino también como
un activo estratégico.
 Se proporciona una orientación sobre los principios que sustentan la práctica de la

gestión del servicio y que resultan útiles para el desarrollo de las políticas, guías y
procesos de gestión del servicio durante todo el Ciclo de Vida del Servicio de ITIL. La
guía Estrategia del Servicio resulta útil en el contexto de Diseño del Servicio, Transición
del Servicio, Operación del Servicio y Mejora Continua del Servicio.
 Los temas recogidos en Estrategia del Servicio incluyen el desarrollo de mercados

internos y externos, activos del servicio, Catálogo de Servicios y la implementación de
la estrategia a través del Ciclo de Vida del Servicio. Gestión Financiera, Gestión de la
Cartera de Servicios, Desarrollo Organizativo y Riesgos Estratégicos son algunos de los
temas principales.
 La estrategia nos ayuda a establecer los objetivos y las expectativas de rendimiento

para servir a los clientes y a los mercados, e identificar, seleccionar y priorizar las
oportunidades.
 Estrategia del Servicio trata de garantizar que las organizaciones puedan gestionar los
costes y riesgos asociados con sus Portfolios de Servicios, y estén preparadas no sólo
para lograr la eficacia operativa, sino para conseguir un rendimiento diferenciador.
 El objetivo de esta unidad es entender el concepto de valor en todos sus ámbitos así
como los procesos necesarios para poder cumplir los objetivos estratégicos de una
organización.

4.2 PROPÓSITO DE LA ESTRATEGIA
El propósito de la Estrategia del Servicio es definir la perspectiva, posición, planificación y

patrón, que un proveedor de servicios necesita para el cumplimiento de los resultados de
Negocio de una organización.
Perspectiva • Describe la visión y dirección de la organización. Una perspectiva estratégica

articula lo que es el negocio de la organización , cómo interactúa con el cliente y
cómo se proporcionará sus servicios o productos.
Posición • Describe como el proveedor de servicios tiene la intención de competir con otros
proveedores de servicios en el mercado. La posición se refiere a los atributos y
capacidades que distingue al proveedor de la competencia. algún ejemplo podría
ser (bajo coste, servicios especializados o exclusivos, conocimiento especializado
del cliente)
Planificación • Describe cómo el proveedor de servicios evolucionara de un estado actual a un

estado deseado. Los planes describen las actividades que el proveedor de
servicios realizara para alcanzar la posición deseada.
Patrón • Describir las acciones que deberá realizar el proveedor para conseguir sus
objetivos estratégicos

4.3 OBJETIVOS DE LA ESTRATEGIA
 Proporcionar un entendimiento de que es la Estrategia
 Una identificación clara de la definición de los servicios y clientes que los usan
 La capacidad de definir cómo se crea y se entrega el valor
 Un medio para identificar oportunidades para prestar servicios y cómo explotarlas
 Un modelo claro de prestación de servicio que indique cómo se prestarán y financiarán

los servicios, así como a quién se prestarán y con qué propósito
 Un medio para entender la capacidad organizativa necesaria de como ofrecer la

estrategia
 Documentación y coordinación de cómo los activos de servicios se utilizan para prestar

servicios, y cómo optimizar su rendimiento.
 Qué nivel de Inversión se requiere, cual es la demanda y asegurar una relación de

trabajo entre el cliente y el proveedor de servicios

4.4 VALOR DE LA ESTRATEGIA
La selección y la adopción de las mejores prácticas ayudarán a las organizaciones en la entrega

de beneficios significativos. La aplicación de normas y enfoques coherentes para la estrategia
de servicio deberá:
 Vincular las actividades realizadas por el proveedor de servicios, a los resultados de

negocio, aportando VALOR y no únicamente costes para la organización
 Desarrollar una visión clara al proveedor, del tipo y niveles de servicio necesarios para
que sus clientes tengan éxito.
 Responder de una manera rápida y eficaz a los cambios del entorno empresarial,
asegurando ventajas competitivas para el proveedor y sus clientes.
 Facilita una comunicación funcional y transparente entre el proveedor de servicio y sus

clientes.
 Proporcionar los medios para que el proveedor de servicios pueda prestar servicios de
manera eficiente y eficaz

4.5 VALOR DE UN SERVICIO
El valor de un servicio puede ser considerado como el nivel del cumplimiento de las
expectativas de los clientes. A menudo, se mide por lo que el cliente está dispuesto a pagar por
el servicio. Básicamente decimos que se entrega valor cuando la satisfacción del cliente es
superior al coste del servicio.
El valor tiene una serie de características que vamos a describir a continuación:
 El valor se define por los clientes. No importa lo mucho que el proveedor de servicios
proclame el valor de sus servicios, la decisión final sobre si ese servicio es valioso o no
la tiene el cliente.
 Es una mezcla de características asequibles. Es posible influir en la percepción del

cliente en cuanto al valor que ofrece nuestro servicio a través de la comunicación y la
negociación, pero en esa fase el cliente todavía no puede tomar la decisión final acerca
de lo que es valioso para ellos.
Un buen vendedor puede convencer a un cliente para cambiar las prioridades e influir
en su compra, pero el cliente seleccionará el servicio o producto que representa la
mejor combinación de características en función del precio que están dispuestos a
pagar.
 Consiste en la consecución de los objetivos. Los clientes no siempre miden el valor en

términos financieros, a pesar de que pueden indicar cuánto están dispuestos a pagar
por un servicio que ayude a alcanzar sus resultados deseados.
Muchos servicios no están diseñados para producir ingresos, pero si para cumplir con
algún otro objetivo de la organización, tales como los programas de responsabilidad
social, o gestión de recursos humanos.
Si bien las organizaciones comerciales tienden a medir la mayoría de servicios por

rendimientos financieros, las organizaciones gubernamentales tienden a centrarse en
otros objetivos. Por ejemplo, la policía podría centrarse en la reducción de la
delincuencia o la detención de delincuentes; Los departamentos de bienestar social
podría centrarse en la cantidad de fondos desembolsados a las familias necesitadas;
Una organización de rescate de montaña podría centrarse en el número de personas
advertidas o rescatadas de avalanchas.
 El valor cambia a lo largo del tiempo y las circunstancias. lo que es valioso para un
cliente hoy no sea valioso en dos años. A medida que cada cliente se enfrenta al
desafío del cambio de su entorno, también lo hacen sus necesidades y valores de
servicio. Por ejemplo, los puntos de venta podrían centrarse en la venta de un
porcentaje mayor de artículos de lujo cuando la economía está bien, pero durante una
recesión habría que cambiar el enfoque de las líneas de productos y vender un menor
número de artículos de lujo.

Como hemos mencionado anteriormente, los servicios contribuyen valor a una organización
sólo cuando su valor es percibido es mayor que el coste de obtener el servicio. Por lo tanto, la
comprensión del valor de las TI requiere tres tipos de información:
 ¿Qué servicio ofrecemos? Si el servicio sólo se percibe como la gestión de un conjunto

de servidores, redes y PC será muy difícil para el cliente entender cómo éstos
contribuyen a valor. Para que un cliente pueda calcular el valor de un servicio, deben
ser capaces de discernir un servicio discreto específico y vincularlo directamente a las
actividades y resultados de negocio específicas. Por ejemplo, una organización de TI
afirma que el alojamiento de aplicaciones ofrece valor para el negocio. La empresa, sin
embargo, no sabe lo que es alojamiento de aplicaciones, o qué aplicaciones están
alojadas. Si la organización de TI quiere comunicar su valor, debe ser capaz de
identificar lo que el cliente realmente percibe, y luego vincular sus actividades a ese
servicio. La Cartera de servicios, y el Catálogo de servicios, en particular, la ayudará a
cuantificar esto.
 ¿Qué han logrado esos servicios? El cliente deberá identificar lo que son capaces de
hacer con el servicio, y lo importante que es para ellos y su organización.
 ¿Cuánto cuestan los Servicios? Cuando un cliente compara el coste o el precio de un

servicio con los logros del servicio, será capaz de juzgar el valor que el servicio aporta
en realidad. Si no es capaz de determinar el coste del servicio, será muy difícil afirman
que entrega valor, y que el cliente lo perciba
El Cálculo del valor de un servicio puede a veces ser sencillo en términos financieros. Por
ejemplo, un cliente necesita un servicio para apoyar la venta de una nueva línea de productos.
Si el servicio hace lo que se requiere, y su coste no repercute negativamente en la rentabilidad
de la línea de productos, y el precio sigue siendo competitivo, el cliente será más probable que
lo perciba como valioso.
En los casos en que los resultados no tienen carácter económico es más difícil de cuantificar el
valor a pesar de que todavía puede ser posible para calificarlo. Por ejemplo, El Ayuntamiento
de la ciudad necesita un servicio que les permita realizar un seguimiento del tráfico en el
centro de la ciudad para que puedan ajustar las señales de tráfico a fin de mejorar el flujo de
tráfico. Si el servicio les permite hacer esto, encaja dentro del presupuesto de la ciudad, lo más
probable es que se perciba como valioso.
Sin embargo, hay más a valorar, no sólo la función del servicio y su coste. El valor necesita ser
definido en términos de tres áreas: los resultados empresariales alcanzados, las preferencias
del cliente y la percepción del cliente de lo que fue entregado.
El valor se define no sólo estrictamente en términos de resultados de negocio del cliente;

También es altamente dependiente de las percepciones y preferencias del cliente. Las
percepciones están influenciadas por los atributos de un servicio, presentes o experiencias
previas con atributos similares y la capacidad relativa de los competidores y otros compañeros.

Las percepciones también son influenciados por la propia imagen del cliente o posición real en
el mercado, tales como las de ser un innovador, líder en el mercado y el riesgo-tomador.
El valor de un servicio tiene muchas formas, y los clientes tienen preferencias influenciado por
sus percepciones. Las preferencias y percepciones de los clientes afectarán la forma en que se
diferencian el valor de una oferta o prestador de servicios sobre otro.
Los clientes son reacios a comprar cuando hay ambigüedad en la relación causa-efecto entre la
utilización de un servicio y la realización de beneficios. Los proveedores de servicios necesitan
para proporcionar a los clientes, información para influir en su percepción de valor, al influir en
las percepciones, y respondiendo a las preferencias.

La siguiente figura representa el valor económico de un servicio.
Los clientes tienen valores de referencia en los que basan sus percepciones del valor añadido
de un servicio. El valor de referencia puede estar definido vagamente o puede basarse en
datos objetivos. Un ejemplo de valor de referencia es la línea de referencia que los clientes
mantienen sobre el coste de las funciones o servicios internos. La clave reside en que es
importante que el proveedor de servicio entienda y obtenga información sobre cuál es el valor
de referencia. Esto puede obtenerse a través de un diálogo exhaustivo con el cliente, de la
experiencia previa con el mismo o con un cliente similar, o a través de la investigación y el
análisis disponible en el mercado. El valor económico del servicio es la suma de este valor de
referencia y la diferencia neta de valor que el cliente asocia al servicio ofrecido (Figura 3.2). La
diferencia positiva proviene de la utilidad y la garantía del servicio. La diferencia negativa
proviene de las pérdidas sufridas por el cliente al utilizar el servicio, debido a una calidad
deficiente o a los costes ocultos. Tal y como se afirmaba anteriormente, el valor se define
estrictamente en el contexto de los resultados del negocio.

El enfoque en los resultados de negocio es, por encima de todo, un avance crítico que buscan
muchos proveedores de servicio. Representa un cambio de énfasis desde la utilización
eficiente de los recursos hasta la realización eficaz de los resultados. La eficiencia en las
operaciones se guía por la necesidad de ayudar a los clientes a realizar los resultados con
eficacia. Los clientes no adquieren servicios; adquieren la satisfacción de necesidades
concretas. Esta distinción explica la desconexión habitual entre las organizaciones de TI y los
negocios a los que sirven. Con frecuencia, aquello que el cliente valora es diferente de lo que la
organización de TI cree que proporciona.

4.6 UTILIDAD Y GARANTÍA
Desde la perspectiva del cliente, el valor se compone de dos elementos principales: utilidad o
idoneidad para el propósito y garantía o idoneidad para el uso.
El cliente percibe la utilidad a partir de los atributos del servicio que presentan un efecto
positivo sobre el rendimiento de las tareas asociadas con los resultados deseados. La
eliminación o relajación de restricciones sobre el rendimiento también se percibe como un
efecto positivo.
La garantía proviene del efecto positivo de encontrarse disponible siempre que sea necesario,
con la capacidad o magnitud suficiente y con seguridad en términos de continuidad y
certidumbre.
La utilidad es qué consigue el cliente, y garantía es cómo se provee.
Utilidad • Adecuado al propósito – La funcionalidad ofrecida por un producto o servicio para

satisfacer una necesidad en particular
Garantía • Adecuado al Uso - Asegurar que un producto o servicio satisface los requisitos
acordados.
 Disponibilidad
 Capacidad
 Seguridad
 Continuidad
 Disponibilidad. La disponibilidad es el aspecto principal que permite asegurar valor

para los clientes. Garantiza a los clientes que los servicios estarán disponibles para el
uso en los términos y condiciones acordados. La disponibilidad de un servicio es el
atributo que el usuario percibe con mayor facilidad. Un servicio sólo está disponible si
los usuarios pueden acceder al mismo de la forma acordada. Las percepciones y las
preferencias difieren en función del cliente y del contexto de negocio. El cliente es
responsable de la gestión de las expectativas y las necesidades de sus usuarios. Dentro
de las condiciones especificadas, como el área de cobertura, los periodos y los canales
de entrega, se espera que los servicios estén a disposición de los usuarios que el
cliente autorice.
La disponibilidad de un servicio es algo más sutil que la evaluación binaria entre

disponible y no disponible. La tolerancia del cliente con respecto a una leve
degradación de la disponibilidad debería determinarse y considerarse en el diseño del
servicio. Por ejemplo, si un subconjunto de usuarios es responsable de una función
vital del negocio, las instancias de servicio para estos usuarios pueden alojarse en
recursos dedicados, robustos ante los fallos, para que el cliente conserve cierta
capacidad crítica para operar.

 Capacidad. La capacidad es la garantía de que el servicio soportará un nivel de

actividad de negocio o demanda con un nivel de calidad especificado. Los clientes
realizan la actividad de negocio con la seguridad de que contarán con la capacidad
adecuada. Las variaciones de la demanda son asumidas dentro de un rango acordado.
Los proveedores de servicio se comprometen a mantener recursos que liberen a los
clientes de las deficiencias en la capacidad y de los activos infrautilizados. La capacidad
adquiere una importancia particular cuando la utilidad del servicio proviene del acceso
a recursos compartidos. Los proveedores de servicio ayudan a los clientes que
experimentan carencias durante los picos de demanda.
La capacidad garantizada durante periodos particulares o en ubicaciones particulares

también es valiosa para los clientes que necesitan iniciar o ampliar operaciones y para
los que un plazo breve de comercialización es un factor crítico de éxito. Tales planes de
negocio requieren bajos costes de puesta en marcha y plazos de entrega reducidos.
Adicionalmente, debido a los elevados riesgos que plantean las operaciones nuevas o
la ampliación de las operaciones, los clientes pueden preferir no realizar las
inversiones necesarias para poseer y operar activos de negocio. Los negocios que se
enfrentan a una demanda incierta de sus propios clientes también perciben valor en
los servicios bajo demanda con poca o nula latencia. Los costes de oportunidad debido
a los clientes perdidos son elevados.
Los proveedores de servicio no podrán proporcionar la utilidad de la mayoría de los

servicios si no cuentan con una gestión eficaz de la capacidad. La Gestión de la
Capacidad es un aspecto crítico de la gestión del servicio debido a que afecta
directamente a la disponibilidad de los servicios. La capacidad disponible para soportar
a los servicios también afecta directamente al nivel de continuidad del servicio
comprometido o proporcionado. La gestión eficaz de la capacidad del servicio puede
por tanto plantear efectos de primer y segundo orden sobre la garantía del servicio.
 Seguridad. La seguridad garantiza el uso seguro de los servicios por parte de los
clientes. Esto implica que los activos del cliente que se encuentran dentro del ámbito
de la entrega del servicio y soporte no estarán expuestos a ciertos riesgos. Los
proveedores de servicio se comprometen a implementar controles generales y de nivel
de servicio que asegurarán que el valor proporcionado a los clientes sea completo y no
se vea perjudicado por ningún coste y riesgo evitable. La seguridad del servicio cubre
los siguientes aspectos de la reducción de riesgos:
 Uso autorizado y responsable de los servicios según lo especificado por el

cliente
 Protección de los activos de los clientes frente al acceso no autorizado o
malicioso
 Áreas de seguridad entre los activos del cliente y los activos del servicio.
 Continuidad. La continuidad asegura que el servicio continuará soportando al negocio

cuando se produzcan fallos importantes o eventos perjudiciales. El proveedor de
servicio se compromete a mantener activos del servicio que proporcionarán un nivel
suficiente de recuperación y contingencia. Los sistemas y procesos especializados se

activarán para asegurar que los niveles de servicio que reciben los activos del cliente
no caigan por debajo de un nivel predefinido. El aseguramiento también incluye la
restauración o vuelta a la normalidad en un plazo de tiempo definido previamente
para limitar el impacto general de un fallo o evento. La continuidad se asegura
principalmente a través de la redundancia y los recursos dedicados que se mantienen
aislados de los efectos perniciosos.
La creación de valor es el efecto combinado de la utilidad y la garantía. Cualquiera de los dos

factores puede aumentar el valor para los clientes. Ambos son necesarios: ninguno es
suficiente por sí mismo. Cada uno debería ser considerado como un factor independiente de
creación de valor como veremos en la siguiente figura.
Esto es particularmente cierto cuando los servicios son de consumo masivo o están
estandarizados. En tales casos, resulta difícil diferenciar el valor, principalmente en lo que
respecta a la utilidad para los clientes. Cuando los clientes pueden elegir entre proveedores de
servicio cuyos servicios proporcionan más o menos la misma utilidad pero diferentes niveles
de garantía, entonces prefieren obtener la mayor certidumbre en el soporte de los resultados
del negocio.
La habilidad para proporcionar un cierto nivel de garantía a los clientes es un factor

fundamental para que los proveedores de servicio obtengan una ventaja competitiva.


Procesos Estrategia del Servicio

GESTIÓN DE LA ESTRATEGIA DE TI

4.7 GESTION DE LA ESTRATEGIA DE TI
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ESTRATEGIA DE NEGOCIO Y TI
 ALCANCE
 ACTIVIDADES
4.7.1 INTRODUCCIÓN
La Gestión de la estrategia nos permite definir los objetivos de TI, asegurando que estén
alineados y formen parte de los objetivos de la organización.
4.7.2 PROPÓSITO
El propósito de del Proceso de Gestión de la estrategia lo definiremos en los siguientes puntos.
 Definir y mantener la perspectiva, la posición, los planes y los patrones de una

organización con respecto a sus servicios y la gestión de los mismos.
 Articular cómo un proveedor de servicios permitirá a una organización alcanzar sus

resultados de negocio
 Establecer los criterios y mecanismos para decidir qué servicios serán los más
adecuados para cumplir con los resultados del negocio
 Establecer la forma más eficaz y eficiente a la hora de gestionar los servicios
 Asegurar que la estrategia se define se realiza y cumple su PROPÓSITO.

4.7.3 OBJETIVOS
Los objetivos del proceso de Gestión de la Estrategia son los siguientes:
 Analizar el entorno internos y externo del proveedor de servicios para identificar

oportunidades.
 Identificar las restricciones que impidan el logro de los resultados del negocio, la
entrega de los servicios o la gestión de los servicios.
 Eliminar las restricciones o reducir sus efectos.
 Acordar y mantener la perspectiva del proveedor de servicios permitiendo una misión

y visión claras.
 Establecer la posición del proveedor del servicio.
 Producir y mantener documentos de planificación de la estrategia.
 Asegurar que los planes estratégicos se han traducido a planes tácticos y operativos.

4.7.4 ESTRATEGIA DE NEGOCIO Y TI
Gestión de la estrategia es responsabilidad de los directivos de la organización. Les permite

establecer los objetivos de la organización, especificar cómo la organización va a cumplir con
esos objetivos y dando prioridad a las inversiones. Sin embargo, en las grandes organizaciones
es poco probable que los mismos ejecutivos lleven a cabo las evaluaciones, la elaboración de
los documentos de la estrategia y su ejecución. Esto se realiza normalmente mediante una
estrategia y planificación del consejo de administración.
La estrategia de una organización no se limita a un solo documento o departamento. La

estrategia global de una organización se divide en una estrategia para cada unidad de negocio.
El siguiente cuadro muestra un ejemplo de cómo una Estrategia de Negocio podría ser dividida
en estrategias para TI y para la fabricación de Productos. Gestión de la estrategia de la
Organización se debe asegurar que el resto de las estrategias son coherentes, están vinculas a
la estrategia global.

4.7.5 ALCANCE
El ámbito de gestión de la estrategia en ITIL Estrategia del Servicio se ilustra en la siguiente

figura. Este diagrama muestra cómo se utiliza una estrategia de negocios para desarrollar un
conjunto de tácticas (enfoques detallados, procesos y técnicas que se utilizarán para lograr los
objetivos estratégicos) y operaciones (procedimientos específicos, tecnologías y actividades
que serán ejecutadas por personas y equipos).
La estrategia de TI (y por lo tanto también la estrategia de servicios de TI) no solo se deriva de

la estrategia de negocio, sino que también proporciona su validación. La estrategia de TI puede
determinar si un objetivo estratégico es tecnológicamente posible, y qué nivel de inversión se
requiere para cumplir con ese objetivo. El negocio es capaz de decidir sobre si el objetivo debe
ser incluido y en qué prioridad.

4.7.6 ACTIVIDADES
El siguiente cuadro representa un esquema de las actividades que realizará el proceso de

Gestión de la Estrategia de TI. Empezando por una evaluación Estratégica donde
principalmente analizaremos los entornos externos e internos, pasaremos a una fase de
definición o Generación donde apoyados, por las cuatros P´s de la Estrategia (Perspectiva,
Posición, Planificación y Patrón), nos permitirá ejecutar la estrategia a través del ciclo de vida.
Este tema se trata en profundidad en el curso del Ciclo de Vida (Estrategia del servicio)

GESTIÓN DE LA CARTERA DE SERVICIOS (SPM)

4.8 GESTIÓN DE LA CARTERA DE SERVICIOS (SPM)
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 COMPONENTES
 ACTIVIDADES
4.8.1 INTRODUCCIÓN
Una cartera de servicios describe los servicios de un proveedor en términos de valor del
negocio. Articula las necesidades del negocio y la respuesta del proveedor a esas necesidades.
Por definición, los términos de valor de negocio se corresponden con términos de marketing,
proporcionando un medio para comparar la competitividad de servicios entre proveedores
alternativos.
Al actuar como como la base fundamental para un marco de trabajo, un Portfolio de Servicios
clarifica o ayuda a clarificar las siguientes preguntas estratégicas:
 r
¿Por qué debería adquirir un cliente estos servicios?
 ¿Por qué debería comprárnoslos a nosotros?
 ¿Cuáles son los modelos de establecimiento de precios o reintegro?
 ¿Cuáles son nuestras fortalezas y debilidades, prioridades y riesgo?
 ¿Cómo deberían asignarse nuestros recursos y capacidades?

4.8.2 PROPÓSITO
 Asegura que el proveedor de servicios tiene la combinación adecuada de servicios para

equilibrar la inversión en TI con la capacidad para cumplir con los resultados del
negocio.
 Realiza un seguimiento de la inversión en los servicios durante todo su ciclo de vida.
 Trabaja con otros procesos de gestión de servicios para asegurar que se alcanzan los
rendimientos adecuados.
 Garantiza que los servicios están claramente definidos y vinculados a la consecución

de los resultados del negocio.
 Garantiza que todas las actividades de diseño, transición y operación del servicio están
alineadas con el valor de los servicios.
4.8.3 OBJETIVOS
 Proporcionar los mecanismos para que una organización pueda decidir qué servicios
ofrecer en base a un análisis del retorno potencial y nivel de riesgo aceptable.
 Mantener el portfolio de servicios ofrecidos, articulando las necesidades del negocio y

los resultados que cada servicio soporta.
 Proporcionar una forma para que una organización pueda evaluar cómo los servicios le
permiten poner en práctica su estrategia.
 Controlar cuáles de los servicios ofrecer, en qué condiciones y a qué nivel de inversión.
 Realizar un seguimiento de la inversión en servicios a lo largo de su ciclo de vida.
 Analizar cuáles de los servicios ya no son viables y cuando deben ser retirados.

4.8.4 ALCANCE
El ámbito de la gestión de la Cartera de servicios consiste en todos los servicios que un

proveedor de servicios tiene previsto entregar, los que actualmente entrega y los que han sido
retirados del servicio. La principal preocupación de la gestión de la cartera de servicios es si el
proveedor de servicios es capaz de generar valor a partir de los servicios. Por lo tanto, la
gestión de la Cartera de servicio hará un seguimiento de las inversiones en los servicios y loa
comparara con los resultados de negocio deseados.
Los proveedores de servicios internos tendrán que trabajar con las unidades de negocio en la
vinculación cada servicio a los resultados del negocio antes de que puedan comparar la
inversión con retornos. Los proveedores de servicios externos tienden a evaluar el valor de
forma más directa, ya que cada servicio tiene que ser capaz de generar ingresos directamente,
o apoyar otros servicios que generan ingresos. Esa generación de ingresos de una manera
eficiente, a su vez, facilita la rentabilidad. Gestión de la Cartera de servicios evalúa el valor de
los servicios en todo su ciclo de vida, y debe ser capaz de comparar lo que los nuevos servicios
han ofrecido en relación a los servicios retirados.
Como hemos mencionado anteriormente los Servicios que componen la Cartera son todos los
activos e inactivos:
 Servicios que se planean entregar (Flujo de creación o Pipeline)

 Servicios que se entregan en la actualidad (Catálogo de Servicios)
 Servicios retirados

4.8.5 COMPONENTES
La cartera de servicios incluye los compromisos e inversiones realizados por un proveedor de

servicios a través de todos los clientes y los espacios de mercado. Representa compromisos
contractuales actuales, desarrollo de nuevos servicios y planes de mejora de servicios en curso
iniciados por CSI. La cartera también incluye los servicios de terceros, que son una parte
integral de la oferta de servicios a los clientes. Algunos servicios de terceros son visibles para
los clientes (por ejemplo reparaciones de escritorio), mientras que otros no lo son (por
ejemplo, los servicios de red de área amplia).
En otras palabras, la Cartera de servicios es el conjunto completo de servicios que son

administrados por un proveedor de servicios. La Cartera de servicios también identifica los
servicios en una etapa conceptual, es decir, todos los servicios que la organización
proporcionaría si tuviera recursos ilimitados, capacidades y financiación. Este ejercicio de
documentación facilita la comprensión de los costes de oportunidad de la cartera existente y
una mayor disciplina fiscal. Si un proveedor de servicios comprende lo que no puede hacer,
entonces es la mejor condición para evaluar si se debe seguir haciendo lo que está haciendo o
reasignar sus recursos y capacidades.
En resumen:
 Conjunto completo de servicios
 La cartera de servicios incluye los compromisos e inversiones realizados por un

proveedor de servicios a través de todos los clientes y los espacios de mercado
 Representa compromisos contractuales actuales, desarrollo de nuevos servicios y

planes de mejora de servicios en curso iniciados por CSI.
 La cartera también incluye los servicios de terceros, que son una parte integral de la
oferta de servicios a los clientes

La siguiente figura muestra esquemáticamente la composición de la Cartera de Servicios.
Servicios en • Base de datos o documento estructurado, con todos los servicios que están
desarrollo bajo consideración o desarrollo, pero aún no estén disponibles para los
(Pipeline) clientes
Catálogo de • base de datos o documento estructurado con información sobre todos los
Servicios servicios operacionales, incluso los que están disponibles para su
despliegue
Servicios • Servicios retirados o eliminados que ya no se entregan a los clientes nuevos

Retirados aunque se pueden entregar a los clientes existentes.
 Servicios Pipeline. Una base de datos o documento estructurado con una lista de
todos los servicios que están bajo consideración o desarrollo, pero aún no estén
disponibles para los clientes. También incluye cualquier oportunidad importante de
inversión, tales como la reubicación del centro de datos o proyecto de virtualización.
Los Servicios Pipeline proporcionan una visión empresarial de posibles servicios futuros
y es la parte de la cartera de servicios que no se publica normalmente a los clientes.
Representan el crecimiento del proveedor de servicios, la visión estratégica para el
futuro y el estado general de salud del proveedor. También reflejan el grado en que los
nuevos servicios e ideas de mejora están siendo alimentados por la Estrategia del
Servicio, el Diseño del servicio y la Mejora Continua del Servicio.
Es necesaria una buena Gestión financiera de los servicios de TI, para garantizar la
financiación adecuada de los servicios Pipeline.

Hay muchas formas de entradas para los servicios Pipeline, por ejemplo:
 Un cliente solicita un servicio nuevo.

 La estrategia ha identificado una nueva oportunidad.
 Un cliente ha identificado una nueva oportunidad de negocio que requerirá el
apoyo de TI.
 Un resultado negocio es insuficientemente atendido por los servicios actuales.
Una nueva tecnología está disponible y tiene el potencial de crear nuevas
oportunidades de negocio.
 Procesos de gestión de servicios (como la gestión de la capacidad, la gestión de
nivel de servicio o gestión de problemas) identifican una mejor solución a los
servicios que se ofrecen actualmente.
 La Mejora Continua del servicio identifica un vacío en la actual cartera de
servicios.
 Catálogo de Servicios. El catálogo de servicios es una base de datos o documento

estructurado con información sobre todos operacionales o disponibles para su
despliegue. El catálogo de servicios es la única parte de la cartera de servicios
publicados a los clientes, y se utiliza para apoyar la venta y la entrega de servicios de
TI. El catálogo de servicios incluye información sobre entregas, precios, puntos de
contacto, pedidos y procesos de solicitud.
Los Servicios que pueden entrar en el Catálogo de servicios sólo lo harán después de
haber sido validados en cuanto a riesgos y Costes. Sólo se pueden encontrar en el
catálogo de servicios los servicios operativos y recursos que se se dedican a apoyar
plenamente los servicios activos.
El catálogo de servicios es una herramienta importante para la estrategia del servicio,

ya que representa las capacidades reales y actuales del proveedor de servicios.
Muchos clientes sólo están interesados en lo que el proveedor puede comprometerse
actualmente, en lugar de en el futuro.
 Servicios Retirados. Son los servicios de la Cartera de servicios que han sido
retirados o eliminados. Después de una revisión de Servicio la organización debe
tomar la decisión de que servicios retirar o eliminar. Algunas organizaciones hacen
esto cuando el servicio ya no está disponible para nuevos clientes, a pesar de
que el servicio aún se está entregando a los clientes existentes. Otras
organizaciones sólo mueven el servicio de catálogo cuando ya no se entrega a
los clientes.
Los servicios retirados se mantienen en la cartera de servicios por una serie de

razones entre las cuales tenemos:

 El servicio de sustitución podría no cumplir con todos los requisitos, y es

importante ser capaz de utilizar el servicio anterior.
 Al definir un nuevo servicio, Gestión de la cartera de servicios puede descubrir
que algunas funciones están disponibles en un servicio retirado, por tanto el
servicio jubilado puede ser parte del nuevo servicio.
 Pueden existir requisitos regulatorios para mantener los datos archivados que
sólo pueden ser usados por el servicio retirado, en ese caso la información se
puede exportar a una base de datos de sólo lectura para un uso futuro.
Por otro lado podemos tener diferentes tipos de Porfolios, un ejemplo seria el siguiente:
Portfolio de • Base de datos o documento estructurado que se utiliza para gestionar las
Aplicaciones aplicaciones a lo largo de su ciclo de vida. La cartera de aplicaciones
contiene atributos clave de todas las aplicaciones. La cartera de
aplicaciones se implementa a veces como parte de la cartera de servicios
o, si todavía no existe, como parte del sistema de gestión del conocimiento
del servicio
Portfolio de • Se gestiona mediante el proceso de gestión de relaciones con el negocio

clientes (BRM), pero es una entrada importante para el proceso de gestión de la
cartera de servicios.
Portfolio de • Base de datos o documento estructurado utilizado para gestionar los

Proyectos proyectos que han sido instituidos (Alcance, términos y referencias). La
cartera de proyectos se utiliza para coordinar los proyectos y asegurar que
cumplan sus objetivos en tiempo y coste.

4.8.6 ACTIVIDADES
La Cartera de Servicios consiste en cuatro fases o actividades:
Definir • Esta fase se centra en documentar y comprender los servicios existentes y nuevos.
Cada servicio debe tener un modelo de negocio documentado. Los datos para cada
servicio, como activos requeridos e inversiones necesitan ser validados
Analizar • El análisis de los servicios de la cartera indicará si el servicio es capaz de optimizar el

valor, y como se puede priorizar y equilibrar la oferta y la demanda
Aprobar • Cada servicio tiene que ser aprobado y autorizado para asegurar recursos suficientes y
ofrecer los niveles de servicio esperados
Instituir • Documento que autoriza el proyecto e indica su alcance, términos y referencias. Los
servicios tienen que ser instituidos formalmente, y las partes interesadas
(stakeholders),deben mantenerse al día con la información sobre las decisiones,
asignación de recursos y las inversiones realizadas

GESTIÓN FINACIERA DE SERVICIOS TI

4.9 GESTIÓN FINANCIERA DE SERVICIOS TI
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES
 CASO DE NEGOCIO
4.9.1 INTRODUCCIÓN
Gestión financiera va a proporcionar la viabilidad económica de un servicio. La visibilidad

operativa, el entendimiento y una toma de decisiones superior son las capacidades esenciales
aportadas a la empresa a través de la aplicación rigurosa de Gestión Financiera.
Gestión Financiera proporciona al negocio y a TI la cuantificación, en términos financieros, del

valor de los Servicios de TI, el valor de los activos que son la base para la provisión de esos
servicios, y la cualificación de previsiones operativas.
Gestión Financiera, como herramienta estratégica, se aplica por igual a los tres tipos de
proveedores de servicio. Cada vez más se pide a los proveedores internos de servicio que
operen con los mismos niveles de visibilidad y responsabilidad financiera que sus unidades de
negocio y homólogos externos. Además, la tecnología y la innovación se han convertido en las
capacidades centrales de generación de ingresos de muchas compañías.

4.9.2 PROPÓSITO
Los propósitos principales de Gestión Financiera son:
 Asegurar financiación para diseñar, desarrollar y entregar servicios que cumplan con la
estrategia de la organización.
 Asegurar que el proveedor de servicios de TI no se compromete con la entrega de

servicios que no es capaz de proveer
 Equilibrar el coste y la calidad del servicio.
 Equilibrar la oferta y la demanda entre el proveedor y sus clientes
4.9.3 OBJETIVOS
Al igual que en el proposito los siguientes son los objetivos principales de gestión Financiera:
 Definir y mantener un marco para identificar, gestionar y comunicar el coste de la

prestación de servicios.
 Evaluar el impacto financiero de las nuevas o modificadas estrategias en el proveedor

de servicios.
 Asegurar financiación para gestionar la prestación de servicios.
 Comprender la relación entre gastos e ingresos.
 Ejecución de las políticas y prácticas financieras en la prestación de servicios.
 Contabilidad del dinero gastado en la creación, entrega y soporte de servicios.
 Previsión de los recursos financieros.
 Cuando proceda, definir un marco de trabajo para recuperar los costes de la

prestación del servicio (Facturación y cobro).

4.9.4 ALCANCE
La gestión financiera es normalmente una parte bien establecida y bien entendida de cualquier
organización. Los Gestores financieros deben dedicarse a establecer las políticas financieras,
procedimientos presupuestarios, las normas de información financiera, las prácticas contables
y reglas de generación de ingresos o de recuperación de costes.
La gestión financiera de los proveedores internos desempeña un rol fundamentas entre los
sistemas financieros corporativos y la gestión de servicios. El resultado es una función de
contabilidad orientada al servicio con la cual se alcanza un nivel de detalle y comprensión
mucho mayor con respecto a la prestación y consumo de los servicios.
Existen tres áreas principales dentro de Gestión Financiera:
Presupuestos • Predecir y controlar los ingresos y gastos dentro de la organización. Consiste

en un ciclo periódico de negociación para establecer los presupuestos
(generalmente anual) y un seguimiento mensual
Contabilidad • Permite a la organización de TI explicar la forma en que se gasta el dinero.
Cargos o • Permite facturar a los clientes por los servicios que se les prestan o imputar
Facturación cargos a la Unidad de negocio en caso de ser proveedor interno.
 Planificación de Presupuestos. Este es el proceso de predecir y controlar los ingresos y

gastos de dinero dentro de la organización. Planificación de presupuestos consiste en
un ciclo de negociación periódica para establecer los presupuestos (generalmente
anuales) y la monitorización mensual de los presupuestos actuales.
 Contabilidad. Este es el proceso que permite a la organización de TI rendir cuentas

sobre la forma en que gasta su dinero (particularmente la capacidad para identificar
los costes por cliente, servicio y actividad). Generalmente se trata de sistemas de
contabilidad, incluyendo libros contables, cuentas, bitácoras etc. y debe ser
supervisado por alguien formado en contabilidad.
 Cargos o Cobros. Este es el proceso necesario para facturar a los clientes por los
servicios prestados. Esto requiere prácticas y sistemas contables de TI sólidos. Los
clientes externos pagarán en efectivo por los servicios que compran. Sin embargo,
cuando se factura a clientes internos, no existe transferencia de efectivo ya que el
proveedor y el cliente pertenecen a la misma organización. En estos casos por lo
general se divide el coste del Departamento de TI entre los departamentos que
reciben los servicios. Cuando los departamentos tienen responsabilidad de pérdidas y
ganancias, esto último de dividir los costes se convierte en un tema de conflicto.

4.9.5 ACTIVIDADES
El siguiente cuadro representa las tres áreas descritas anteriormente y actividades propias de
cada una de ellas. Simplemente es un cuadro orientativo que no se estudiara en profundidad,
ya que corresponde al curso del ciclo intermedio Estrategia del Servicio. No obstante
definiremos algunos de los conceptos incluidos en el.
 Modelo de Costes. Un modelo de costes es un marco que permite al proveedor de

servicios determinar los costes de la prestación de servicios y asegurar que se asignen
correctamente. Un modelo de costes identifica dónde se gasta el dinero, y vincula ese
gasto a los servicios y / o clientes específicos.
 Centro de Costes. Un centro de costes es algo a lo que se le asigna un coste,

por ejemplo, un Servicio, Ubicación, Departamento, Unidad de Negocio, etc.
 Unidad de Coste. Es el nivel más bajo al que se asigna un coste, básicamente

los elementos más fáciles de medir incorporados el centro de Costes.

4.9.6 CASO DE NEGOCIO
Un caso de negocio es una herramienta de soporte y planificación de las decisiones que

muestra las posibles consecuencias de una acción de negocio. Las consecuencias pueden
adoptar dimensiones cualitativas y cuantitativas. Un análisis financiero, por ejemplo, suele ser
clave para realizar un buen caso de negocio.
La siguiente tabla muestra un ejemplo de la estructura de un caso de Negocio:
Introducción • Presenta los objetivos de negocio abordados por el servicio.
Método y Suposiciones • Define los límites del caso de negocio, como período de tiempo,
quién paga los costes y quién recibe los beneficios
Impacto en el negocio • Los resultados, financieros y no financieros, previstos para la

iniciativa.
Riesgos y Contingencias • La probabilidad de lograr resultados inesperados.

Recomendaciones • Acciones específicas recomendadas.

GESTIÓN DE LA DEMANDA

4.10 GESTIÓN DE LA DEMANDA
 INTRODUCCIÓN
 PROPÓSITO
 PATRONES DE ACTIVIDAD DE NEGOCIO (PBA)
 OBJETIVOS
4.10.1 INTRODUCCIÓN
Gestión de la demanda es el proceso que busca comprender, anticipar e influir en la demanda

de servicios y la provisión de capacidad para satisfacer dicha demanda.
La Gestión de la Demanda es un aspecto crítico de la gestión del servicio. La demanda

gestionada deficientemente es una fuente de riesgo para los proveedores de servicio debido a
la incertidumbre en la demanda. El exceso de capacidad genera costes sin crear valor que
proporciona una base para la recuperación del coste. Los clientes son reacios a pagar por la
capacidad inactiva, a menos que represente un valor para ellos.
Existen casos en los que se necesita una cierta cantidad de capacidad sin utilizar para
proporcionar niveles de servicio. Tal capacidad crea valor a través del mayor nivel de
aseguramiento que se posibilita con una mayor capacidad. Esta capacidad no puede ser
considerada como capacidad inactiva, debido a que se encuentra en uso activo para un
propósito.
La capacidad insuficiente afecta a la calidad de los servicios provistos y limita el crecimiento del
servicio. Los acuerdos de nivel de servicio, las previsiones, la planificación, y la coordinación
estrecha con el cliente pueden reducir la incertidumbre con respecto a la demanda, pero no la
eliminan por completo.

4.10.2 PROPÓSITO
El propósito de gestión de la demanda es comprender, anticipar e influir en la demanda de

servicios del cliente y asegurar que el proveedor de servicios tiene capacidad para satisfacer
dicha demanda.
Gestión de la demanda funciona en todas las etapas del ciclo de vida para asegurar que los
servicios están diseñados, probados y entregados para apoyar los resultados del negocio en los
niveles adecuados de actividad.
4.10.3 PATRONES DE ACTIVIDAD DE NEGOCIO (PBA)
Patrón que recoge el tipo de actividades que realizan determinados activos del cliente como ,
personas, procesos o aplicaciones, determinando la frecuencia, volumen, ubicación, duración,
etc.
Las actividades de negocio impulsan la demanda de servicios. Los activos del cliente, como las
Personas, Procesos y Aplicaciones, generan modelos de actividades de negocio (PBA). PBA
define la dinámica de un negocio e incluye interacciones con clientes, suministradores, socios y
otros interesados. Los servicios a menudo respaldan directamente los PBA. Debido a que los
PBA generan ingresos, ganancias y costes, justifican una gran parte de los resultados del
negocio.
Clasificación • Tipo de PBA
Atributos • Frecuencia, volumen, ubicación, etc..
Requisitos • Disponibilidad, seguridad, rendimiento, etc..
Requisitos de activos del servicio • Recursos utilizados

4.10.4 OBJETIVOS
Los principales objetivos de Gestión de la Demanda se describen a continuación.
 Identificar patrones de actividad del negocio (PBAs) y comprender los niveles de

demanda para cada servicio.
 Definir y Analizar los perfiles de usuario para entender la demanda en los diferentes
tipos de usuarios
 Asegurar que los servicios están diseñados para satisfacer los PBAs y los resultados del
negocio.
 Trabajar con la gestión de capacidad para asegurar que los recursos adecuados estén
disponibles en los niveles adecuados de capacidad, para satisfacer la demanda de
servicios, manteniendo así un equilibrio entre el coste del servicio y el valor que
genera

GESTIÓN DE RELACIONES CON EL NEGOCIO (BRM)

4.11 GESTIÓN DE RELACIONES CON EL NEGOCIO (BRM)
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 BRM y SLM (Comparativa)
 RELACIONES CON OTROS PROCESOS
 Gestión de las relaciones con el negocio (BRM), es el proceso que permite a los BRM
proporcionar una relación entre el proveedor de servicios y el cliente a un nivel
estratégico y táctico.
 El objetivo de esta relación es asegurarse de que el proveedor de servicios comprende

los requisitos de negocio del cliente y es capaz de proporcionar servicios que
satisfagan estas necesidades.
 La principal medida para lograr este objetivo es el nivel de satisfacción del cliente.
 En muchas organizaciones, se establece el papel del gerente de relaciones de negocio

(BRM) para ejecutar ciertas actividades de cara al cliente en varios procesos, tales
como la gestión de nivel de servicio.

4.11.2 PROPÓSITO
El siguiente listado muestra los principales propósitos del proceso Gestión de Relaciones con el
Negocio.
 Establecer y mantener una relación comercial entre el proveedor de servicios y el

cliente basado en la comprensión del cliente y sus necesidades de negocio
 Identificar las necesidades del cliente y asegurarse de que el proveedor de servicios es

capaz de satisfacer estas necesidades.
 Comprender como las necesidades del negocio cambian con el tiempo y las
circunstancias.
 Asegura que las expectativas de los clientes no exceden de lo que están dispuestos a
pagar
 Asegurar que el proveedor de servicios es capaz de satisfacer las expectativas del

cliente antes de aceptar la prestación del servicio.

4.11.3 OBJETIVOS
A continuación vamos a describir los objetivos de este proceso.
 Asegurar que el proveedor de servicios entiende la perspectiva del cliente.
 Lograr altos niveles de satisfacción del cliente como indicador de satisfacción de las
necesidades del cliente.
 Establecer y mantener una relación constructiva entre el proveedor de servicios y el

cliente.
 Identificar los cambios que podrían afectar el tipo, nivel o utilización de los servicios
proporcionados.
 Articular requerimientos del negocio para servicios nuevos o cambios en los servicios
existentes.
 Identificar tendencias tecnológicas con impacto potencial en los tipos y niveles de

servicio.
 Trabajar con los clientes para asegurar que los servicios y los niveles del servicio
proporcionan valor.
 Servir de mediador allí donde existan requisitos contradictorios para los servicios de
distintas unidades de negocio.
 Establecer procesos formales de reclamaciones y escalado para el cliente.

4.11.4 ALCANCE
El alcance de este proceso lo tenemos que considerar desde el punto de vista de proveedor
Internos y externo. La siguiente tabla nos muestra la diferencia entre ambos.
Cliente • El proceso de gestión de las relaciones con negocios se lleva a cabo entre un alto
Interno representante de TI y altos directivos (cliente) de las unidades de negocio.
• El foco está en la alineación de los objetivos del negocio con la actividad del
proveedor de servicios.
Cliente • El proceso lo llevan a cabo los BRMs o gestores de cuentas, cada uno dedicado a un
externo cliente o grupo de clientes.
• El foco está en maximizar el valor del contrato a través de la satisfacción del cliente
BRM hace foco en como los servicios cumplen con los requerimientos del cliente y para
conseguir esto deben entender y comunicar los siguientes aspectos:
 Resultados de negocio que el cliente quiere lograr
 Servicios que se ofrecen actualmente a los clientes, y la forma en que son utilizados
 La forma en que se ofrecen actualmente los servicios incluyendo quién es el

responsable de los mismos, que niveles de servicio se han acordado, la calidad de los
servicios prestados y los cambios que se prevén en el futuro.
 Tendencias tecnológicas que podrían afectar a los servicios actuales y al cliente.
 Los niveles de satisfacción del cliente, y qué planes de acción se han puesto en marcha
para hacer frente a las causas de la insatisfacción.
 Cómo optimizar los servicios para el futuro.
 Cómo está representado el proveedor de servicios ante el cliente

4.11.5 BRM y SLM (Comparativa)
En muchas ocasiones podemos confundir el proceso de BRM con el proceso de Gestión de

nivel de Servicio (SLM). Aunque no son iguales si tenemos que considerar que puede haber
alguna actividad que pueda quedar solapada.
La siguiente tabla nos muestra la diferencia entre ambos procesos, la cual se entenderá mejor
cuando abordemos el proceso de SLM (Gestión de Nivel de Servicio)
Gestión de Relaciones con el Negocio Gestión de Nivel de Servicio

(BRM) (SLM)
Propósito Para establecer y mantener una relación Para negociar acuerdos de nivel de Servicio
comercial entre el proveedor y el cliente (SLA) (condiciones de garantía) con los
en base a la comprensión del cliente y sus clientes y asegurar que todos los procesos
necesidades de negocio. de gestión de Servicios, acuerdos de nivel
Para identificar las necesidades del operativo (OLAs) y de los contratos (Ucs)
cliente (utilidad y garantía) y asegurarse que sustentan, son apropiados para los
de que el proveedor de Servicios es capaz objetivos de nivel de Servicio acordado
de satisfacer estas necesidades
Foco Estratégico y táctico - el foco está en la Táctico y operacional - la atención se centra

relación general entre el proveedor de en alcanzar un acuerdo sobre el nivel del
Servicios (SP) y sus clientes, y que los Servicio que se entrega para Servicios
Servicios del SP son ofrecidos para nuevos y existentes, y si el proveedor de
satisfacer las necesidades de los clientes Servicios es capaz de cumplir esos acuerdos
Primera La satisfacción del cliente, también una Alcanzar los niveles acordados de Servicio
medida mejora en la intención del cliente de (que conduce a la satisfacción del cliente)
utilizar mejor y pagar por el Servicio. Otro
indicador es si los clientes están
dispuestos a recomendar el Servicio a
otros (potenciales) clientes

4.11.6 RELACIONES CON OTROS PROCESOS
BRM tienen muchas interfaces con otros procesos. La siguiente tabla muestra las relaciones
más importantes:
OTROS PROCESOS
ESCENARIO PROCESO PRINCIPAL
INVOLUCRADOS
Desarrollo de requerimientos del Gestión de las relaciones con el Gestión del Portfolio de
cliente de alto nivel para un negocio. servicios.
nuevo servicio Propuesto.
Creación de un caso de negocio Gestión de las relaciones con el Gestión del Portfolio de
para un nuevo servicio negocio. servicios.
propuesto.
Confirmación de los Coordinación del diseño. Gestión de las relaciones con

requerimientos funcionales el negocio.
detallados del cliente un nuevo
servicio.
Confirmación de los Gestión de nivel del servicio. Gestión de las relaciones con
requerimientos de disponibilidad el negocio, gestión de la
del cliente para un nuevo disponibilidad.
servicio.
Establecer patrones de actividad Gestión de la demanda. Gestión de las relaciones con

del negocio el negocio
Evaluar el caso de negocio para Gestión del Portfolio de Gestión de las relaciones con
la solicitud de nuevo servicio del servicios. el negocio, gestión financiera
cliente y decidir si seguir o no para servicios de TI.
adelante.
Presentar informes Gestión de nivel del servicio Gestión de las relaciones con
comparativos del rendimiento el negocio.
del servicio con los
objetivos de nivel del servicio

4.12 AUTOMATIZACIÓN DEL SERVICIO
Cuando se aplica juiciosamente, la automatización de procesos de servicio contribuye a

mejorar la calidad del servicio, reducir costes y mitigar riesgos reduciendo la complejidad e
incertidumbre, resolviendo de forma eficiente los pros y contras.
La aplicación indiscriminada de la automatización puede provocar más problemas o agravar los

existentes. Deberán seguirse las siguientes directrices:
 Simplifique los procesos del servicio antes de automatizarlos.

 Clarifique el flujo de actividades,
 En las situaciones de autoservicio, reduzca la superficie de contacto que los
usuarios tienen con los sistemas y procesos subyacentes
A continuación describimos una serie de consideraciones sobre la automatización:
 La automatización puede tener un impacto particularmente significativo en el

rendimiento de los activos de servicios como la gestión, organización, personas,
procesos, conocimientos e información.
 La capacidad de los recursos automatizados se puede ajustar más fácilmente en

respuesta a las variaciones en los volúmenes de demanda.
 Los recursos automatizados pueden evitar restricciones a la hora de acceder en

horarios diferentes.
 Los sistemas automatizados presentan una buena base para medir y mejorar los
procesos de servicio
 Los sistemas automatizados pueden tener potencia de cálculo que está más allá de la
capacidad de las personas y reducen la depreciación del conocimiento cuando los
empleados se mueven dentro de la organización o la abandonan.
Las siguientes son áreas especialmente susceptibles de ser automatizadas:
 Diseño y modelado
 Catálogo de servicios
 Reconocimiento y análisis de patrones
 Clasificación, priorización y encaminamiento
 Detección y monitorización Optimización.

UNIDAD 5 – DISEÑO DEL SERVICIO
Fundamentos
5 – DISEÑO DEL SERVICIO

5 DISEÑO DEL SERVICIO
 INTRODUCCIÓN Y PROPÓSITO
 OBJETIVOS DEL DISEÑO DEL SERVICIO
 VALOR PARA EL NEGOCIO
 ALCANCE EL DISEÑO DEL SERVICIO (I)
 ASPECTOS DEL DISEÑO
 LAS 4 P´S DEL DISEÑO
 CRITEROS DE ACEPTACIÓN DEL SERVICIO (SAC)
 COMPOSICIÓN DEL SERVICIO
 PAQUETE DE DISEÑO DEL SERVICIO (SDP)
 RESTRICCIONES DEL SERVICIO
 GESTIÓN DE COORDINACIÓN DEL DISEÑO
 GESTIÓN DEL CATÁLOGO DEL SERVICIO
 GESTIÓN DE NIVEL DE SERVICIO
 GESTIÓN DE LA DISPONIBILIDAD
 GESTIÓN DE LA CAPACIDAD
 GESTIÓN DE CONTINUIDAD
 GESTIÓN DE SEGURIDAD
 GESTIÓN DE PROVEEDORES

5.1 INTRODUCCIÓN Y PROPÓSITO
 El objetivo principal de la etapa de Diseño del Servicio del ciclo de vida es el diseño de
servicios nuevos o modificados para su introducción en el entorno de producción.
 Es importante que se adopte un método integral para todos los aspectos del diseño, y
que al modificar o cambiar cualquier elemento individual del diseño, se consideren
todos los demás aspectos.
 El objetivo de esta unidad es que el alumno entienda, cuales son todos los procesos
que intervienen en el diseño de un servicio, así como los aspectos y actividades
necesarios para poder ofrecer una garantía a la hora de desplegar y entregar el
servicio al cliente.
 El propósito de la fase de diseño del servicio es diseñar servicios de TI, junto con las
prácticas de Gobierno TI, procesos y políticas requeridas, para implementar la
estrategia del proveedor de servicios y facilitar la introducción de dichos servicios en
un entorno operativo.
5.2 OBJETIVOS DEL DISEÑO DEL SERVICIO
A Continuación enumeramos los objetivos de esta fase del Ciclo de vida:
 Diseñar servicios de TI que requieran una mínima mejora en el futuro.
 Diseñar servicios que satisfagan los objetivos del negocio y que estén alineados con las
necesidades del negocio.
 Diseñar infraestructuras y aplicaciones de TI que satisfagan las necesidades del

negocio y del cliente.
 Diseñar métricas y métodos de medición para la evaluación de los procesos de diseño

y sus entregables.
 Producir y mantener procesos, políticas, arquitecturas, marcos de trabajo y

documentación de TI para el diseño de soluciones de TI.
 Coordinar las actividades de diseño para servicios de TI.
 Diseñar servicios que se puedan desarrollar y mejorar de forma sencilla y eficiente.
 Identificar y gestionar los riesgos.

5.3 VALOR PARA EL NEGOCIO
Un buen diseño del servicio hace posible la entrega de servicios rentables y de calidad y
asegura que se satisfacen los requerimientos del negocio de manera constante.
La implementación de enfoques coherentes y estándar para el diseño del servicio crea valor
mediante:
 Reducción del Coste Total de Propiedad (TCO): el coste de propiedad sólo se puede
minimizar si todos los aspectos de los servicios, procesos y tecnología se diseñan e
implementan adecuadamente con respecto al diseño.
 Mejora de la calidad del servicio: se mejorará la calidad del servicio y la calidad

operativa.
 Mejora de la consistencia del servicio: dado que los servicios se diseñan dentro de la
estrategia, arquitecturas y restricciones corporativas.
 Mejora de la facilidad de implementación de servicios nuevos o modificados: dado

que existe un Diseño del Servicio completo e integrado y la producción de SDPs
integrales.
 Mejora del alineamiento del servicio: implicación desde la concepción del servicio,
garantizando que los servicios nuevos o modificados se correspondan con las
necesidades del negocio, y que los servicios diseñados cumplan los Requisitos de Nivel
de Servicio.
 Rendimiento del servicio más eficaz: con la incorporación e identificación de la

Capacidad, Disponibilidad Financiera y Planes de Continuidad del Servicio de TI.
 Mejora del gobierno de TI: ayudar a la implementación y comunicación de un

conjunto de controles para el gobierno eficaz de TI.
 Procesos de Gestión del Servicio y de TI más eficaces: los procesos se diseñarán con la
rentabilidad y calidad óptimas.
 Mejora de la información y de la toma de decisiones: medidas y métricas más

integrales y eficaces permitirán una mejor toma de decisiones y una mejora continua
de las prácticas de Gestión del Servicio en la etapa de diseño del Ciclo de Vida del
Servicio.

5.4 ALCANCE EL DISEÑO DEL SERVICIO
 Diseño del servicio abarca los métodos, prácticas y herramientas requeridas para
aumentar o mantener el valor para los clientes a lo largo del ciclo de vida de los
servicios.
 Incluye los cambios y mejoras necesarias, la continuidad de los servicios, los logros de
los niveles del servicio, y la conformidad con normas, estándares y regulaciones.
 La fase de diseño del servicio se inicia con un conjunto de requerimientos del negocio
y termina con el desarrollo de una solución específicamente diseñada para satisfacer
las necesidades del negocio.
La siguiente figura muestra el alcance del diseño del servicio contemplando los 5 aspectos del
diseño, punto que estudiaremos a continuación.

5.5 ASPECTOS DEL DISEÑO
El alcance contempla los métodos, prácticas y herramientas para alcanzar la excelencia en el

diseño del servicio.
Diseño del servicio debe adoptar un enfoque general e integrado al diseño de las actividades y
debe también incluir los cinco aspectos del diseño del servicio.
En cada uno de estos aspectos, el enfoque está en los resultados del negocio planificados y
claramente definidos.
Solución del • Se requiere un método formal y estructurado para generar un nuevo servicio
servicio. al coste, funcionalidad y calidad adecuados y dentro de la franja de tiempo
correcta. Paquete de diseño del Servicio (SDP)
Herramientas y • Dar soporte a los servicios. (Cartera de servicios, Catálogo de Servicios,

sistemas de Sistema de Gestión de Información de Capacidad (CMIS), etc...)
gestión de la
información.
Arquitectura • Desarrollo y despliegue de una infraestructura de TI, un conjunto de

tecnológica aplicaciones y datos que satisfacen las necesidades actuales y futuras del
negocio.
Diseño de • Permite entender y ayudar a articular las operaciones distintivas de un

Procesos proceso.
Métodos de • Para gestionar y controlar los procesos de diseño, éstos tienen que
medición y monitorizarse y medirse. Asegurar que existen métodos de medida que
Métricas puedan proveer métricas requeridas por el servicio

5.5.1 SOLUCIÓN DEL SERVICIO
Existen muchas actividades que tienen que completarse dentro de la etapa de Diseño del
Servicio para un servicio nuevo o modificado. Se requiere un método formal y estructurado
para generar un nuevo servicio al coste, funcionalidad y calidad adecuados y dentro de la
franja de tiempo correcta. Este proceso y sus etapas se ilustran en la siguiente figura, junto con
las demás áreas principales que es necesario que se impliquen dentro del proceso. Este
proceso deberá ser iterativo/incremental para garantizar que el servicio entregado cumpla las
necesidades de evolución y cambio del negocio durante el desarrollo del proceso de negocio y
durante el Ciclo de Vida del Servicio de TI. Podría ser necesario que jefes de proyectos y
equipos de proyectos adicionales colaborasen para la gestión de las etapas dentro del ciclo de
vida para el despliegue de un nuevo servicio.

Las áreas que es necesario considerar dentro del diseño de la solución del servicio deberán
incluir:
 Analizar los requisitos de negocio acordados.
 Revisar los servicios e infraestructura de TI existentes
 Garantizar que se incorporen los contenidos de los Criterios de Aceptación del Servicio
(SAC)
 Evaluar y calcular el coste de diseños alternativos,.
 Acordar el gasto y los presupuestos.
 Acordar los plazos para: diseñar, desarrollar, construir, probar y desplegar el servicio.
 Garantizar que se incluyan con la solución todos los controles adecuados de seguridad,
de gobierno corporativos y TI.
 El montaje de un Paquete de Diseño del Servicio (SDP) para la posterior transición,

operación y mejora de la solución del servicio nueva o modificada.

5.5.2 HERRAMIENTAS Y SISTEMAS DE GESTIÓN DE INFORMACIÓN
La forma más eficaz de gestión de todos los aspectos de los servicios a través de su ciclo de
vida es utilizar los sistemas de gestión y herramientas apropiados para dar soporte y
automatizar los procesos eficientemente. El Portfolio de Servicios es el sistema de gestión más
esencial que se utiliza para dar soporte a todos los procesos y describe los servicios del
proveedor en términos de valor para el negocio. Articula las necesidades del negocio y la
respuesta del proveedor a esas necesidades. Por definición, los términos del valor para el
negocio se corresponden con términos del mercado, que proporcionan un medio para
comparar la competitividad del servicio entre proveedores alternativos. Al actuar como la base
fundamental para un marco de trabajo, un Portfolio de Servicios clarifica o ayuda a clarificar
las siguientes preguntas estratégicas:
 ¿Por qué debería adquirir un cliente estos servicios?

 ¿Por qué deberían comprar estos servicios?
 ¿Cuáles son los modelos de establecimiento de precios o reintegro?
 ¿Cuáles son mis fortalezas y debilidades, prioridades y riesgo?
 ¿Cómo deberían asignarse mis recursos y capacidades?
La siguiente figura nos ilustra un ejemplo del contenido del Porfolio o Cartera de Servicios y
otros ejemplos de Sistemas de Gestión de Información.

5.5.3 ARQUITECTURA TECNOLOGICA
Las actividades de diseño de la arquitectura dentro de una organización de TI están implicadas

con la provisión de las 'guías' estratégicas generales para el desarrollo y despliegue de una
infraestructura de TI, un conjunto de aplicaciones y datos que satisfacen las necesidades
actuales y futuras del negocio. Aunque estos aspectos dan soporte a la entrega de servicios de
TI de calidad, ellos solos no pueden entregar servicios de TI de calidad, y es esencial que
también se consideren los aspectos de las personas, del proceso y del socio/suministrador que
rodean a estos componentes tecnológicos (productos):
La siguiente estructura definiría los diferentes tipos de Arquitecturas que debemos considerar
en el diseño de un servicio.

Arquitecturas
Servicio • Aplicaciones, infraestructura, organización y actividades de soporte en

un conjunto de servicios.
Aplicaciones • Proporciona una guía para el desarrollo y despliegue de aplicaciones

individuales.
Datos/Información • Describe los activos de datos lógicos y físicos de la empresa y los

recursos de gestión de datos. Muestra cómo se gestionan y comparten
los recursos de la información para el beneficio de la empresa.
Infraestructura de TI • Describe la estructura, funcionalidad y distribución geográfica de los

componentes de hardware, software y comunicaciones que apoyan y
dan soporte a toda la arquitectura, junto con los estándares técnicos
que se les aplican.
Entorno • Describe todos los aspectos, tipos y niveles de los controles del entorno
y su gestión.

5.5.4 DISEÑO DE PROCESOS
Los procesos, una vez definidos, deberán documentarse y controlarse. Una vez bajo control,
pueden repetirse y es posible gestionarlos. Se pueden definir grados de control sobre los
procesos, y a continuación se pueden integrar las métricas y medidas del proceso en el propio
proceso para controlar y mejorar el proceso, como se ilustra en la siguiente figura
Los elementos genéricos del proceso muestran cómo los datos entran en el proceso, se
procesan, salen y se mide y revisa la salida. Esta descripción tan básica sustenta cualquier
descripción de proceso. Un proceso siempre se organiza alrededor de un conjunto de
objetivos. Las entradas principales de los procesos deberán estar dirigidas por los objetivos y
siempre deberán incluir medidas (métricas) de proceso, informes y mejora del proceso.
Cada proceso deberá contar con un propietario del proceso que será responsable del proceso
y de su mejora y asegurará que el proceso cumpla sus objetivos. Los objetivos de cualquier
proceso de TI deberán definirse en términos medibles y deberán expresarse en términos de
beneficios para el negocio y sustentar los objetivos y estrategia del negocio. Diseño del
Servicio debería ayudar a cada propietario del proceso en el diseño de procesos, para
garantizar que todos los procesos usen términos y plantillas estándar, que sean consistentes y
se integren con los demás para proveer una integración extremo a extremo en todas las áreas.
La salida generada por un proceso tiene que cumplir las normas operativas que se deriven de
los objetivos de negocio. Si los productos cumplen la norma establecida, el proceso podrá
considerarse eficaz (ya que puede repetirse, medirse y gestionarse). Si las actividades se
llevaran a cabo con un uso mínimo de recursos, el proceso también se puede considerar
eficiente. El análisis, resultados y métricas del proceso deberán incorporarse en informes
regulares de gestión y en mejoras del proceso.

5.5.5 METODOS DE MEDICIÓN Y METRICAS
Para gestionar y controlar los procesos de diseño, éstos tienen que monitorizarse y medirse.
Esto es válido para todos sus aspectos. Las medidas y métricas se tratan con detalle en la
publicación Mejora Continua del Servicio. Esta sección incluye aquellos aspectos que son
particularmente relevantes y apropiados para medir la calidad de los procesos de diseño y sus
entregables.
Deben tomarse las debidas precauciones al seleccionar las medidas y métricas, y los métodos
que se empleen para generarlas. Esto se debe a que las métricas y medidas elegidas afectarán
y cambiarán realmente el comportamiento de las personas que trabajarán dentro de las
actividades y procesos que se están midiendo, particularmente cuando esto se relaciona con
los objetivos, el rendimiento del personal y del equipo y con los planes de remuneración
asociados con el rendimiento. Por lo tanto, sólo deberán seleccionarse medidas que
promuevan la progresión hacia el cumplimiento de objetivos de negocio o el cambio de
comportamiento deseado.
 En todas las actividades de diseño, el requisito debería ser:
 Diseñar soluciones que se 'ajusten al propósito'.
 Diseñar según el nivel adecuado de calidad, no con exceso o defecto de diseño.
 Diseñar soluciones que sean 'acertadas la primera vez' y cumplan sus objetivos
esperados.
 Diseñar soluciones que minimicen la cantidad de 'mejoras' o 'añadidos' que tienen que
desarrollarse rápidamente después de que se hayan desplegado las soluciones.
 Diseñar soluciones que sean eficaces y eficientes desde la perspectiva del negocio y de
los clientes. El énfasis deberá ponerse sobre todo en soluciones que sean eficaces y
sean eficientes dentro de la restricción de la eficacia continua.
Las métricas y métodos de medida deberán reflejar estos requisitos y diseñarse para medir la
capacidad de diseño de procesos para que correspondan con estos requisitos. Todas las
medidas y métricas usadas deberán reflejar la calidad y éxito de los procesos de diseño desde
las perspectivas del negocio, los clientes y los usuarios. Deben reflejar la capacidad que las
soluciones entregadas tienen para cumplir los requisitos del negocio identificados y acordados.
Es necesario que las medidas del proceso seleccionadas sean adecuadas para la capacidad y
madurez de los procesos que se están midiendo. Los procesos inmaduros no pueden dar
soporte a medidas, métricas y métodos de medida sofisticados.

Existen cuatro tipos de métricas que se pueden usar para medir la capacidad y rendimiento de
los procesos
Progreso • hitos y entregables en la capacidad del proceso.
Conformidad • conformidad del proceso con requisitos de gobierno, requisitos regulatorios y

conformidad de las personas con respecto al uso del proceso.
Eficacia • la precisión y exactitud del proceso y su capacidad para entregar el 'resultado

correcto'.
Eficiencia • la productividad de los procesos, su velocidad, rendimiento y utilización de

recursos.

5.6 LAS 4 P´S DEL DISEÑO
Muchos diseños, planes y proyectos fracasan por la falta de preparación y gestión. La

implementación de ITSM como práctica se trata de la preparación y la planificación eficaz y
eficiente de las cuatro P: las personas, los procesos, los productos (servicios, tecnología y
herramientas) y los socios (proveedores, fabricantes y proveedores).

5.7 CRITEROS DE ACEPTACIÓN DEL SERVICIO (SAC)
Los criterios de aceptación del servicio (SAC) son un conjunto de criterios usados para asegurar
que los servicios logran su funcionalidad y calidad esperada y que el proveedor de servicios
está preparado para la entrega del nuevo servicio una vez éste se haya desplegado.
La siguiente tabla muestra un ejemplo de algunos de ellos.
Criterios Responsabilidad
Tener la fecha de lanzamiento ¿se han acordado el período de

garantía y los criterios de aceptación finales con las partes Cambios, Nivel del servicio
interesadas?
¿Se han documentado, acordado y hecho público a todo el

Cambios, Incidentes
personal afectado el proyecto y el programa de despliegue?
Se han revisado, repasado y acordado los acuerdos de nivel del

servicio (SLA) y los requerimientos de nivel del servicio (SLR) con Nivel del servicio
todas las partes implicadas?
¿Se ha introducido/actualizado el servicio en el catálogo/portfolio

de servicios dentro del Sistema de gestión de la configuración
Nivel del servicio, Configuración
(CMS) y se han establecido las relaciones apropiadas para todos
los componentes de soporte?
¿Se han identificado y registrado en el CMS todos los clientes y Nivel del servicio, Relaciones con
partes interesadas? el negocio

5.8 COMPOSICIÓN DEL SERVICIO
Diseño del servicio debe considerar todos estos aspectos al diseñar soluciones de servicio para
satisfacer las necesidades nuevas y cambiantes del negocio:
 Proceso de negocio: para definir las necesidades funcionales del servicio que se
entrega– ej., tele ventas, facturación, pedidos).
 Servicio: El servicio que se está entregando a los clientes y negocios, ej. correo
electrónico.
 Política, estrategia, gobernanza, conformidad: los elementos definidos por la

organización para dirigir la actividad y garantizar el cumplimiento de los objetivos y
metas organizacionales.
 SLA/SLR: Los documentos acordados con los clientes que especifican el nivel, alcance y
calidad del servicio que se va a entregar, ya sea ahora (SLA) o en el futuro para un
nuevo servicio (SLR).
 Infraestructura: Los equipos (tecnología, no personas) de TI necesarios para proveer el

servicio, incluyendo servidores, circuitos de red, switches, ordenadores personales
(PC), teléfonos.
 Entorno: El entorno requerido para asegurar y operar la infraestructura – por ejemplo,

centros de datos, energía, aire acondicionado.

 Datos: Los datos necesarios para dar soporte al servicio y proporcionar la información
requerida por los procesos del negocio – por ejemplo, registros de clientes, libros de
contabilidad.
 Aplicaciones: Las aplicaciones de software necesarias para manipular los datos y

proporcionar los requisitos funcionales de los procesos del negocio – ej. Gestión de
Recursos Empresariales.
 Servicios de Soporte o de Apoyo: servicios necesarios para soportar la operación del

servicio entregado, por ejemplo, servicios compartidos, servicios de red gestionados.
 OLAs y UCs: Los acuerdos de base necesarios para entregar la calidad de servicio
acordada en el SLA.
 Equipos de Apoyo o de Soporte: equipos internos de apoyo a cualquiera de los

componentes necesarios para la entrega del servicio – por ejemplo, Unix, mainframe,
redes
 Proveedores: terceros necesarios para prestar apoyo a cualquiera de los componentes

necesarios para la provisión del servicio – por ejemplo, redes, hardware, software
 Procesos de gestión de servicios: cualquier proceso requerido por el proveedor de

servicios para asegurar la provisión exitosa del servicio.

5.9 PAQUETE DE DISEÑO DEL SERVICIO (SDP)
Documentos que definen todos los aspectos de un Servicio de TI y sus Requisitos a través de
cada etapa de su Ciclo de Vida. durante la etapa de diseño debe generarse un 'Paquete de
Diseño del Servicio o SDP para cada:
 Nuevo servicio
 Cambio importante
 Retirada de un servicio
 Cambios en el propio Paquete de Diseño del Servicio
Este paquete pasa de Diseño del Servicio a Transición del Servicio y detalla los aspectos del
servicio y de sus requisitos a través de las etapas posteriores de su ciclo de vida.

5.10 RESTRICCIONES DEL SERVICIO
Todas las actividades de diseño se encuentran sometidas a muchas restricciones. Estas

restricciones proceden del negocio y de la Estrategia del Servicio y cubren muchas áreas
diferentes, como se ilustra en la siguiente figura. Las restricciones principales que determinan
los límites de un diseño de solución de servicio son la utilidad y la garantía deseada por el
cliente.
Esto significa que los diseñadores no siempre tienen libertad para diseñar la solución más
apropiada para el negocio ya que están sometidos a restricciones impuestas. La restricción
más obvia es la financiera. Puede que no haya suficiente presupuesto para la solución más
apropiada, por lo que tendría que identificarse y acordarse con el negocio un servicio
alternativo más barato. El diseñador sólo puede proporcionar la solución que se ajuste a todas
las restricciones conocidas actualmente, o también intentar elevar o renegociar algunas de las
restricciones, por ejemplo, obteniendo un presupuesto mayor.
Por lo tanto, los procesos de Diseño del Servicio deberán reconocer el hecho de que tienen
libertad para diseñar soluciones, pero que también están trabajando en un entorno donde
muchos factores externos pueden influir en el diseño.
Muchas de estas influencias externas proceden de la necesidad de un buen gobierno

corporativo y de TI, y otras proceden de los requisitos de conformidad con las regulaciones,
legislación y estándares internacionales. Por lo tanto, es fundamental que todos los
diseñadores reconozcan esto y se aseguren que los diseños y soluciones que propongan
tengan todos los controles y capacidad necesarios.

Procesos Diseño del Servicio


COORDINACIÓN DEL DISEÑO

5.11 COORDINACIÓN DEL DISEÑO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES
Este proceso, no incluido en el curso de fundamentos nos permite coordinar todas las
actividades del diseño a fin de generar diseños adecuados que apoyen los resultados
requeridos por el negocio.
Las actividades del diseño pueden ser muy detalladas y complejas y sin un proceso encargado
de realizar su coordinación, es posible que sea complicado alcanzar los objetivos deseados.
5.11.2 PROPÓSITO
El propósito del proceso de coordinación del diseño es asegurar que se cumplen los objetivos
de la fase de diseño del servicio al proporcionar un punto único de coordinación y control para
todas las actividades de diseño de servicios y procesos.
5.11.3 OBJETIVOS
A continuación enumeramos los objetivos principales de este proceso:
 Coordinar las actividades de diseño a través de proyectos, cambios, proveedores y

equipos de apoyo
 Planear y coordinar los recursos y capacidades necesarias para diseñar servicios

nuevos o modificados
 Asegurarse de que todas las partes adoptan un marco común de prácticas reutilizables
de diseño estándar, en forma de actividades, procesos y sistemas de soporte
 Asegurar el diseño consistente de servicios, arquitecturas, tecnología, procesos,

información, sistemas de información de gestión de servicios y métricas para satisfacer
las necesidades de negocio actuales y futuras
 Producir los diseños de servicio adecuados
 Gestionar los criterios de calidad, requisitos y puntos de entrega entre diseño del
servicio, estrategia del servicio y transición del servicio

 Producir paquetes de diseño del servicio (SDPs) y entregarlos a transición del servicio
según lo acordado.
5.11.4 ALCANCE
El alcance del proceso de coordinación incluye toda la actividad de diseño, especialmente las
soluciones de servicio nuevas o modificadas que están siendo diseñadas para su transición
hacia (o desde, en el caso de una retirada de servicio) el entorno operativo. Podemos destacar.
 Asistencia y soporte a proyectos o cambios a través de las actividades de diseño del

servicio.
 Coordinar, priorizar y programar el uso de todos los recursos de diseño del servicio.
 Mantener las políticas, directrices, estándares, presupuestos, modelos, recursos y

capacidades para las actividades y procesos de diseño del servicio.
 Asegurar que se aborden todos los requisitos de utilidad y garantía en el diseño de los
servicio.
 Asegurar la producción de paquetes de diseño del servicio (SDPs) y su entrega a

transición del servicio.
 Coordinación del diseño no tiene responsabilidad por el diseño de las soluciones de

servicio detalladas o la producción de los componentes individuales del SDP.

5.11.5 ACTIVIDADES
Las actividades de este proceso se dividen en dos categorías.
 Las relacionadas con la etapa del Ciclo de Vida de Servicio global de Diseño. Estas
actividades incluyen el desarrollo, implantación y mejora continua de las prácticas
apropiadas de servicio de diseño, así como la coordinación de la actividad de diseño
actual a través de proyectos y cambios. Estas actividades pueden ser realizadas por
Gestor de Coordinación de Procesos del diseño.
 las relacionadas con cada diseño individual. Estas actividades se centran en asegurar
que cada esfuerzo de diseño individual y SDP, ya sea parte de un proyecto o,
simplemente, asociado a un cambio, se ajusta a las prácticas definidas, y que producen
un diseño que va a apoyar el negocio que requiere esos resultados. Estas actividades
pueden ser realizadas por un Gestor de Proyecto o cualquier otra persona con
responsabilidad directa en el proyecto o el cambio, con la asistencia y orientación del
Gestor Coordinador de Procesos del Diseño.

GESTIÓN DEL CATALOGO DE SERVICIO

5.12 GESTIÓN DEL CATÁLOGO DEL SERVICIO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVO
 ALCANCE
 VISTAS DEL CATÁLOGO DE SERVICIOS
El Catálogo de servicios es uno de los elementos más importantes de un enfoque integral de

provisión de servicios. El proceso de gestión del Catálogo de servicios proporciona los medios
para asegurar que la organización acumula todos los beneficios potenciales de un Catálogo de
servicios de la manera más eficiente posible.
5.12.2 PROPÓSITO
El propósito de la gestión del Catálogo de servicios es proporcionar una fuente única de

información consistente de todos los servicios en activo y de aquellos que están listos para
pasar al entorno operativo, y asegurar que el Catálogo esté disponible para las personas
autorizadas a su acceso
5.12.3 OBJETIVO
 Asegurar que la información contenida en el Catálogo de servicios es precisa para

todos los servicios en activo y para aquellos que están listos para pasar al entorno
operativo.
 Asegurar que el Catálogo de servicios muestra la información, estado, interfaces y

dependencias actuales de todos los servicios en activo y de aquellos que están listos
para pasar al entorno operativo.
 Asegurar que el Catálogo de servicios cumple con la demanda cambiante, de

información del catálogo de servicios, interfaces y dependencias proveniente de los
otros procesos de Gestión de servicios

5.12.4 ALCANCE
Gestión del Catálogo de servicios abarca todos los servicios en activo y los que están
preparados para entrar en activo; enumerados éstos individualmente o en forma de paquetes
de servicios.
Las actividades de Gestión del Catálogo de Servicios deberán incluir:
 Contribución a la definición y descripción de servicios y paquetes de servicio

apropiados para el Catálogo.
 Producción y mantenimiento de un Catálogo preciso.
 Interfaces, dependencias y consistencia entre el Catálogo de servicios y el portfolio de

servicios.
 Interfaces y dependencias entre servicios y servicios de apoyo/soporte, componentes

y elementos de la configuración (CIs) dentro del Catálogo de servicios y del CMS
5.12.5 VISTAS DEL CATÁLOGO DE SERVICIOS
El Catálogo de Servicios puede contener diferentes vistas. Principalmente tendrá dos vistas,
una Negocio/Cliente y otra interna Técnica/Soporte.
 Catálogo de Servicios de Negocio: que contiene detalles de todos los servicios de TI

entregados al cliente, junto con las relaciones con las unidades de negocio y con el
proceso de negocio que se basan en los servicios de TI. Esta es la visión del cliente del
Catálogo de Servicios.
 Catálogo de Servicios Técnicos: que contiene detalles de todos los servicios de TI

entregados al cliente, junto con las relaciones con los servicios de soporte, servicios
compartidos, componentes y Cls necesarios para dar soporte a la provisión del servicio
al negocio. Esto deberá apoyar al Catálogo de Servicios de Negocio y no forma parte de
la visión del cliente.

Catálogo con 2 vistas Catálogo con 3 vistas
Vista Negocio/ • Detalles de todos Cliente Mayorista • Detalles de todos

cliente los servicios los servicios
entregados al entregados al
cliente
cliente mayorista
Vista servicios de • Detalles de todos Cliente Minorista • Detalles de todos

Técnico/Soporte los servicios de los servicios
soporte de TI. entregados al
cliente minorita
Vista servicios • Detalles de todos

Técnico/Soporte los servicios de
soporte de TI.


GESTIÓN DE NIVEL DE SERVICIO

5.13 GESTIÓN DE NIVEL DE SERVICIO
 INTRODUCCIÓN
 DEFINICIONES BÁSICAS
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES
 REQUERIMIENTOS DE NIVEL DE SERVICIO (SLR)
 MARCOS DEL ACUERDO DE NIVEL DE SERVICIO (SLA)
 SLA MULTINIVEL
 GENERAR INFORMES DE SERVICIO
 REVISIÓN DEL SERVICIO
 PROGRAMA DE MEJORA (SIP)
Gestión del Nivel de Servicio (SLM) negocia, acuerda y documenta objetivos apropiados del
servicio de TI con representantes del negocio, y a continuación monitoriza y genera informes
sobre la capacidad del proveedor de servicio a la hora de entregar el nivel de servicio
acordado. SLM es un proceso vital para toda organización del proveedor de servicios de TI en
la que es responsable de acordar y documentar objetivos de nivel de servicio y
responsabilidades dentro de SLAs y SLRs para cada actividad dentro de TI. Si estos objetivos
fueran apropiados y reflejaran con precisión los requisitos del negocio, entonces el servicio
entregado por los proveedores de servicio se alineará con los requisitos de negocio y cumplirá
las expectativas de los clientes y usuarios en términos de calidad del servicio. Si estos objetivos
no se alinearan con las necesidades del negocio, entonces las actividades del proveedor de
servicio y los niveles de servicio no se alinearán con las expectativas del negocio y se generarán
problemas. El SLA es un nivel de aseguramiento o garantía en relación con el nivel de calidad
del servicio entregado por el proveedor de servicio para cada uno de los servicios entregados
al negocio. El éxito de SLM depende en gran medida de la calidad del Porfolio de Servicios y del
Catálogo de Servicios y sus contenidos, ya que proporcionan la información necesaria sobre los
servicios a gestionar dentro del proceso de SLM.

5.13.2 DEFINICIONES BÁSICAS
SLR • Requisito del cliente para un determinado aspecto del servicio

(Requerimientos de nivel principalmente orientado a la garantía.
de servicio)
SLA • Acuerdo entre un proveedor de Servicios TI y los clientes de TI,

(Acuerdo de nivel de definiendo los objetivos y responsabilidades clave del servicio para
Servicio) ambas partes.
OLA • Acuerdo entre un proveedor de servicios de TI y otra parte de la

(Acuerdo de nivel misma organización que ayuda con la provisión de servicios.
operacional)
UC • Un contrato entre un proveedor de servicio TI y un suministrador

(Contrato de Soporte) externo que define los objetivos y responsabilidades requeridos
alcanzar los objetivos de un SLA
 SLR, Esta es una de las primeras actividades de la etapa de Diseño del Servicio del Ciclo
de Vida del Servicio. Una vez se haya generado el Catálogo de Servicios y se haya
acordado la estructura del SLA, deberá redactarse un primer SLR. Es aconsejable
implicar a los clientes desde el principio, pero antes de estar de acuerdo con una hoja
modelo con la que comenzar, podría ser más conveniente generar un primer borrador
con los objetivos de rendimiento y con los requisitos operativos y de gestión, como
punto de inicio para llevar a cabo un análisis en profundidad y detallado. Sin embargo,
tenga cuidado de no ir demasiado lejos y presentar al cliente un 'asunto hecho'.
 SLA, El énfasis deberá ponerse en alcanzar un acuerdo, y los SLAs no deberán usarse
como un tipo de chantaje. Deberá desarrollarse una asociación fiable entre el
proveedor de servicios de TI y el cliente para que se alcance un acuerdo mutuamente
beneficioso, de lo contrario, el SLA podría caer rápidamente en descrédito y se podría
generar una 'cultura del resentimiento' que evitaría cualquier mejora real de la calidad
del servicio.
 Un ejemplo de un OLA seria, un departamento de instalaciones que mantiene el aire

acondicionado, o el equipo de soporte de red que da soporte al servicio de red. Un
OLA debería contener objetivos que den apoyo a aquellos incluidos en un SLA para
garantizar que no se incumplan los objetivos por un fallo de la actividad de soporte.

5.13.3 PROPÓSITO
El propósito del proceso de SLM es garantizar que todos los servicios operativos y su
rendimiento se midan de forma profesional y consistente en toda la organización de TI, y que
los servicios y los informes generados satisfagan las necesidades del negocio y de los clientes.
5.13.4 OBJETIVOS
Los siguientes son los objetivos de Gestión de Nivel de Servicio:
 Garantizar que se proporcione un nivel acordado de servicio de TI para todos los

servicios de TI actuales.
 Definir, documentar, acordar, monitorizar, medir, presentar y revisar el nivel de

servicio proporcionado, e instigar medidas correctivas cuando se requiera.
 Establecer y mejorar la relación y comunicación con el negocio y los clientes, junto con
la gestión de las relaciones con el negocio.
 Asegurar que se desarrollan objetivos específicos y medibles para todos los servicios
TI.
 Monitorizar y mejorar la satisfacción del cliente con la calidad del servicio entregado.
 Asegurar que tanto TI como los clientes tienen una expectativa clara y no ambigua del
nivel de servicio a proveer.
 Asegurar una mejora continua rentable y proactiva de los niveles del servicio
entregados.
5.13.5 ALCANCE
SLM debería proporcionar una comunicación y punto de contacto regular con los clientes y
gestores de negocio de una organización. Deberá representar al proveedor de servicios de TI
en el negocio, y al negocio en el proveedor de servicios de TI. Esta actividad deberá abarcar el
uso de servicios existentes y los posibles futuros requisitos para servicios nuevos o
modificados. SLM necesita gestionar la expectativa y percepción del negocio, clientes y
usuarios y garantizar que la calidad del servicio entregada por el proveedor de servicio se
corresponda con esas expectativas y necesidades. Para hacerlo de forma eficiente, SLM deberá
establecer y mantener SLAs para todos los servicios reales actuales y gestionar el nivel de
servicio suministrado para cumplir los objetivos y medidas de calidad contenidos dentro de los
SLAs. SLM también deberá generar y acordar SLRs para todos los servicios nuevos o
modificados.

El alcance de SLM no incluye:
 Negociación y acuerdo de requerimientos de funcionalidad (utilidad).

 Negociación de UCs y acuerdos con suministradores/proveedores.
 Actividades necesarias para la entrega de niveles del servicio (Gestión de la
capacidad y Gestión de la disponibilidad).
Resumiendo los puntos dentro del alcance podríamos definir los siguientes:
 Cooperación con gestión de las relaciones con el negocio.
 Negociación, acuerdo y documentación de los SLRs para los servicios nuevos o

modificados propuestos.
 Negociación, acuerdo de SLRs y documentación de los SLAs actuales para servicios

operativos.
 Desarrollo y gestión de OLAs para asegurar que los objetivos están alineados con los
objetivos de los SLAs.
 Revisar los UCs junto con gestión de proveedores para asegurar que los objetivos
estén alineados con los objetivos de los SLAs.
 Prevención proactiva de fallos del servicio.
 Producción de informes de servicio y revisión de SLAs y OLAs.
 Examinar y priorizar las mejoras en el registro de CSI
 Promover y coordinar los SIP (Programa de Mejora del Servicio).
5.13.6 ACTIVIDADES
Los siguientes puntos son las actividades que realiza Gestión de Nivel de Servicio. Estas no son
secuenciales, por tanto es importante entender que algunas de ellas se realizaran en
diferentes fases de Ciclo de Vida. Lo primero que vamos a mostrar es un cuadro resumen de
todas las actividades, seguido del listado para a continuación entrar en profundidad en alguna
de ellas.

 Determinar, documentar y acordar los requisitos para los nuevos servicios y producir
los SLR.
 Diseñar los marcos del SLA.
 Negociar, documentar y acordar los SLA.
 Monitorizar el rendimiento del servicio y compararlo con el SLA.
 Generar los informes de servicio.
 Realización de revisiones de Servicio, identificando oportunidades de mejora para su

inclusión en SIP.
 Medir y mejorar la satisfacción del cliente, en cooperación con Gestión de Relaciones

con el Negocio (BRM).
 Examinar y revisar los SLA, el alcance del servicio, y los OLA.
 Ayudar a Gestión de proveedores en la revisión de los UC.

 Desarrollar y documentar los contactos y las relaciones con el negocio, los clientes y
partes interesadas, en cooperación con Gestión de Relaciones con el Negocio.
 Tratar las quejas y felicitaciones.
5.13.7 REQUERIMIENTOS DE NIVEL DE SERVICIO (SLR)
Una de las actividades importantes de Gestión de Nivel de Servicio es la definición de los

requerimientos,
 Los SLR deberán ser parte integral de los criterios de Diseño del Servicio, ya que son los
requisitos del cliente, siempre que el negocio tenga claro lo que quiere.
 Los SLR volverán a definirse gradualmente, puesto que el servicio progresa a través de
las etapas de su ciclo de vida, hasta que eventualmente se convierta en un SLA piloto
durante el periodo de garantía (ELS).
 Este piloto o borrador de SLA deberá desarrollarse junto con el propio servicio, y
deberá firmarse y formalizarse antes de que el servicio se introduzca en el uso real.
5.13.8 MARCOS DEL ACUERDO DE NIVEL DE SERVICIO (SLA)
Con el uso del Catálogo de Servicios como ayuda, SLM deberá diseñar la estructura del SLA
más apropiada para garantizar que todos los servicios y clientes se incluyan de la forma que
mejor se adecué a las necesidades de la organización.
Estos son los siguientes Marcos de SLA que se pueden definir.
MARCOS DEL SLA BASADOS EN:
Servicio • Cubre un servicio para todos los clientes de ese servicio. Por ejemplo, podría
establecerse un SLA para el servicio de correo electrónico de una organización que
incluya a todos los clientes de ese servicio.
Cliente • Representa un acuerdo con un grupo de clientes individuales que cubre todos los
servicios que usan. Por ejemplo, se podrían alcanzar acuerdos con un departamento
de finanzas de la organización
Multinivel • Nivel Corporativo o Empresarial
• Nivel Cliente
• Nivel Servicio

5.13.9 SLA MULTINIVEL
Esto es un ejemplo de un SLA Multinivel con una estructura de 3 Capas.
 Nivel corporativo: que cubre todos los aspectos

genéricos de SLM apropiados para cada cliente en toda la
organización. Es probable que estos aspectos sean menos
volátiles por lo que se requieren actualizaciones menos
frecuentes
 Nivel del cliente: que cubre todos los aspectos de SLM

pertinentes para el grupo particular de clientes o unidad
de negocio, independientemente del servicio que se esté
usando
 Nivel de servicio: que cubre todos los aspectos de SLM

pertinentes para el servicio específico, en relación con un
grupo específico de clientes (uno para cada servicio cubierto por el SLA).

5.13.10 GENERAR INFORMES DE SERVICIO
Inmediatamente después de que se acuerde y acepte el SLA, deberá impulsarse la

monitorización, y deberán generarse informes sobre los logros del servicio. Deberán generarse
informes operativos con regularidad (semanalmente, o incluso con más frecuencia) y, si fuera
posible, deberán generarse informes de excepciones siempre que se haya incumplido un SLA
(o haya amenaza de ello, si se hubieran establecido umbrales apropiados para poder obtener
una 'advertencia anticipada'). Algunas veces las dificultades se encuentran a la hora de cumplir
los objetivos de nuevos servicios durante el periodo de soporte post implantación debido a un
gran volumen de RFCs. Si se limita el número de RFCs procesadas durante el periodo de
soporte post implantación se podrá limitar el impacto de los cambios.
Los mecanismos de informes, intervalos y formatos de informes del SLA deberán definirse y
acordarse con los clientes. También deberán acordarse con los clientes la frecuencia y formato
de las Reuniones de Revisión del Servicio. Se recomiendan intervalos regulares, con informes
periódicos sincronizados con el ciclo de revisión.
Deberán generarse informes periódicos y suministrárselos a los clientes (o a sus

representantes) y a los gestores de TI apropiados con algunos días de antelación con respecto
a las revisiones del nivel de servicio, para que de esta forma se pueda resolver cualquier
cuestión o desacuerdo antes de la reunión de revisión. Por lo tanto, la reunión no se desviará
dedicándole tiempo a tales asuntos.
Los informes periódicos deben incorporar detalles del rendimiento con respecto a los objetivos
del SLA, junto con detalles de cualquier tendencia o acción específica que se esté tomando
para mejorar la calidad del servicio. Una técnica útil es incluir un gráfico de Monitorización del
SLA (SLAM) en la cabecera del informe de un servicio para ofrecer una descripción rápida
general de cómo se han medido los logros con respecto a los objetivos. Éstos son más eficaces
si se codifican en colores (rojo, ámbar, verde, y algunas veces se les denominan gráficos RAG).
Además, el gestor de TI también podría requerir otros informes temporales para OLAs o
revisiones internas de rendimiento y/o gestión de contratos o proveedores. Es probable que
este sea un proceso evolutivo, un primer esfuerzo que no es probable que sea el resultado
final.
No se deberían subestimar los recursos que se requieren para generar y verificar los informes.
Puede consumir mucho tiempo, y si los informes no reflejaran de forma precisa la propia
percepción del cliente de la calidad del servicio, podrían generar una situación peor. Es
fundamental que se analice información precisa de todas las áreas y procesos (p. ej., Gestión
de Incidencias, Gestión de Problemas, Gestión de la Disponibilidad, Gestión de Capacidad,
Gestión del Cambio y de la Configuración) y que se compare en un informe integral y conciso
sobre el rendimiento del servicio, y se mida con respecto a objetivos de negocio acordados.
SLM deberá identificar las necesidades específicas de información, y deberá automatizar la

producción de estos informes lo máximo posible. La amplitud, precisión y facilidad de estos
informes automatizados se puede lograr si formaran parte de los criterios de selección de las
herramientas de soporte integradas. Estos informes del servicio no deben incluir únicamente
detalles del rendimiento actual con respecto a los objetivos, también deberán proporcionar

información histórica sobre las tendencias y rendimientos pasados, para que el impacto de las
acciones de mejora puedan medirse y predecirse.

5.13.11 REVISIÓN DEL SERVICIO
 Deberán mantenerse reuniones periódicas de revisión con los clientes (o con sus
representantes) para revisar los logros del servicio en el último periodo y abordar
previamente cualquier aspecto correspondiente al próximo periodo (Mensuales o
mínimo trimestrales).
 Prestar atención a Incumplimientos, causas de pérdidas de servicio y que acciones

determinar para evitar la recurrencia
 Si el objetivo es inalcanzable revisar y renegociar SLA, OLA o UC
 Una Revisión puede justificar las acciones y actividades del SIP ( Programa de mejora
del servicio)
5.13.12 PROGRAMA DE MEJORA (SIP)
Un SIP o programa de mejora es un Plan formal para implementar mejoras en un Proceso o

Servicio de TI junto con los impactos y riegos asociados.
Son programas destinados a mejorar Áreas débiles donde los objetivos no se van a cumplir y
deberán realizarse informes sobre el progreso y el éxito de cada SIP:
 SIP que se completaron

 SIP que obtuvieron los objetivos esperados
El proceso de SLM a menudo genera un buen punto de inicio para un SIP, y puede que el
proceso de revisión del servicio lo impulse, pero todos los procesos y áreas de la organización
del proveedor de servicio deben estar implicados en el SIP.

GESTIÓN DE DISPONIBILIDAD

5.14 GESTIÓN DE LA DISPONIBILIDAD
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVO
 ALCANCE
 CONCEPTOS BÁSICOS
 FUNCIONES VITALES DEL NEGOCIO (VBF)
La disponibilidad es una de las partes más críticas de la garantía de un servicio. Si un servicio

no entrega los niveles de disponibilidad requeridos, el negocio no va a lograr el valor que se ha
asegurado.
Sin disponibilidad no se puede acceder a la utilidad del servicio, por ello las actividades de
Gestión de Disponibilidad se extienden a través de todo el ciclo de vida del servicio.
5.14.2 PROPÓSITO
El propósito del proceso de gestión de la disponibilidad es asegurar que todos los servicios
ofrecen el nivel de disponibilidad acordado con el negocio, para las necesidades actuales y
futuras, de forma rentable y oportuna.
Gestión de la disponibilidad define, analiza, planifica, mide y mejora todos los aspectos de la
disponibilidad de servicios de TI, asegurando que toda la infraestructura de TI, procesos,
herramientas, Roles, etc., son apropiados para cumplir los objetivos acordados de
disponibilidad.

5.14.3 OBJETIVO
Gestión de la Disponibilidad debe garantizar que se proporcione el nivel acordado de

disponibilidad. La medida y monitorización de la disponibilidad de TI es una actividad clave
para garantizar que se cumplan consistentemente los niveles de disponibilidad. Gestión de la
Disponibilidad debe buscar la optimización continua y mejorar proactivamente la
disponibilidad de la infraestructura de TI, de los servicios y de la organización de soporte para
proporcionar mejoras rentables de disponibilidad que puedan ofrecer beneficios al negocio y
al cliente.
Estos son los objetivos principales de este proceso:
 Producir y mantener un plan de disponibilidad actualizado que refleje la disponibilidad

actual y futura del negocio.
 Asegurar que los logros de disponibilidad cumplen todos los objetivos acordados.
Ayudar en el diagnóstico y resolución de incidentes y problemas relacionados con la
disponibilidad.
 Evaluar el impacto de todos los cambios en el plan de la disponibilidad y en la

disponibilidad de todos los servicios y recursos.
 Asegurar que se implementan medidas proactivas para mejorar la disponibilidad de los

servicios.
 Proporcionar asesoramiento y orientación al negocio y a TI en cuestiones relacionadas

con la disponibilidad.

5.14.4 ALCANCE
El ámbito del proceso de Gestión de la Disponibilidad incluye el diseño, implementación,

medida, gestión y mejora de la disponibilidad del servicio de TI y de los componentes.
El alcance de gestión de la disponibilidad debe aplicarse a:
 Tecnología y servicios operativos incluidos en SLA o no incluidos si son críticos

para el negocio
 Servicio nuevos y existentes con SLR o SLA
 Servicios de soporte y suministradores
 Cualquier actividad, servicio o componente con impacto en la disponibilidad.
El proceso Gestión de la Disponibilidad tiene dos elementos clave:
 Actividades reactivas: el aspecto reactivo de Gestión de la Disponibilidad implica la

monitorización, medida, análisis y gestión de todos los eventos, incidencias y
problemas que implican la indisponibilidad. Estas actividades se incluyen
principalmente dentro de los roles operativos.
 Actividades proactivas: las actividades proactivas de Gestión de la Disponibilidad

implican la planificación, diseño y mejora proactiva de la disponibilidad. Estas
actividades se incluyen principalmente dentro de los roles de diseño y planificación.
El siguiente grafico nos da una idea del Alcance de gestión de disponibilidad y estos dos
elementos mencionados.

Por otro lado Gestión de la Disponibilidad se completa en dos niveles interrelacionados:
Disponibilidad del • Implica todos los aspectos de la disponibilidad e indisponibilidad del

servicio servicio y el impacto de la disponibilidad del componente, o el impacto
potencial de la indisponibilidad del componente en la disponibilidad
del servicio
Disponibilidad del • implica todos los aspectos de la disponibilidad e indisponibilidad del

componente componente.

5.14.5 CONCEPTOS BÁSICOS
Gestión de la disponibilidad se basa en el seguimiento, medición, análisis y presentación de los

siguientes aspectos:
Disponibilidad • la capacidad de un servicio, componente o Cl para realizar su función acordada

cuando se requiere.
Confiabilidad • Medida de cuánto tiempo tarda un servicio, componente o Cl en realizar su

(Fiabilidad) función acordada sin interrupciones.
Mantenibilidad • Tiempo que se tarda en restaurar un servicio, componente o CI se pueden

restaurar en el funcionamiento normal después de una interrupción.
Capacidad de • la capacidad de un proveedor externo para cumplir los términos de su

Mantenimiento contrato. En muchas ocasiones este contrato incluirá niveles acordados de
disponibilidad, fiabilidad y/o capacidad de mantenimiento para un servicio de
soporte o componente.

5.14.6 FUNCIONES VITALES DEL NEGOCIO (VBF)
Las funciones Vitales del Negocio son elementos críticos del proceso de negocio al que da
soporte un servicio de TI.
Un servicio de TI podría dar soporte a varias funciones de negocio que sean menos críticas. Por
ejemplo, la VBF de un cajero automático (ATM) sería la de proporcionar efectivo. Sin embargo,
la capacidad de obtener un estado del ATM puede que no se considere como vital. Esta
distinción es importante y debe influir en el diseño de disponibilidad y en los costes asociados.
Cuanto más esencial sea la función de negocio, mayor será el nivel de capacidad de
recuperación y disponibilidad que es necesario incorporar en el diseño requerido en los
servicios de TI de soporte. Para todos los servicios, ya sean VBF o no, será el negocio, y no TI,
quién deberá determinar los requisitos de disponibilidad. Normalmente, los objetivos iniciales
de disponibilidad se establecen a un nivel demasiado alto, y esto conduce a servicios
demasiado caros o a una discusión iterativa entre el proveedor de servicio y el negocio para
acordar un compromiso apropiado entre la disponibilidad del servicio y el coste del mismo y su
tecnología de soporte.
Ciertas VBF podrían necesitar diseños especiales, que ahora se están utilizando como algo
natural dentro de los planes de Diseño del Servicio, y que incorporan:
Alta • Una característica del servicio de TI que minimiza u oculta los efectos del fallo
Disponibilidad del componente de TI a los usuarios de un servicio.
Tolerancia a • La capacidad de un servicio de TI, componente o Cl para continuar funcionando

Fallos correctamente después del fallo de una parte del componente
Operación • Método o diseño para eliminar la parada planificada de un servicio de TI.

Continua
Disponibilidad • Método o diseño para lograr el 100% de disponibilidad.

Continua

GESTIÓN DE CAPACIDAD

5.15 GESTIÓN DE CAPACIDAD
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVO
 ALCANCE
 SUB PROCESOS
 PLAN DE CAPACIDAD
Gestión de la Capacidad es un proceso que se extiende a través del Ciclo de Vida del Servicio.
Un factor clave del éxito es gestionar la capacidad para garantizar que sea incluida durante la
etapa de diseño.
Gestión de Capacidad se apoya inicialmente en Estrategia del Servicio donde las decisiones y el
análisis de los requisitos del negocio y de los resultados del cliente influyen en el desarrollo de
los modelos de actividades de negocio (PBA), Líneas de servicio (LOS) y paquete del nivel de
servicio (SLP).
5.15.2 PROPÓSITO
El propósito de Gestión de la Capacidad es proporcionar un punto de enfoque y gestión para

todos los aspectos asociados con la capacidad y el rendimiento en relación con los servicios y
recursos.

5.15.3 OBJETIVO
El principal objetivo del proceso de Gestión de la Capacidad es garantizar que siempre exista
capacidad de TI con costes justificables en todas las áreas de TI y que corresponda con las
necesidades actuales y futuras acordadas del negocio.
A continuación se describe una lista del resto de objetivos de este proceso.
 Generar y mantener un Plan de Capacidad actualizado
 Proporcionar asesoramiento y directrices para todas las demás áreas del negocio y de
TI en aspectos relacionados con la capacidad y el rendimiento
 Garantizar que los logros de rendimiento del servicio cumplan
 Colaborar con el diagnóstico y resolución de incidencias y problemas asociados con el

rendimiento y la capacidad
 Evaluar el impacto de todos los cambios en el Plan de Capacidad y rendimiento
 Asegurar que se implementen medidas proactivas para mejorar el rendimiento de los

servicios siempre que tengan un coste justificable.

5.15.4 ALCANCE
El proceso Gestión de la Capacidad deberá ser el punto central para todos los aspectos
relacionados con el rendimiento y capacidad de TI. Gestión de la capacidad considera todos los
recursos necesarios para prestar el servicio de TI, y los planes para cumplir con los
requerimientos del negocio a corto, medio y largo plazo. Funciones de gestión de la tecnología
como por ejemplo Soporte de Red, Soporte de Servidores o Gestión de Operaciones podrían
realizar tareas operativas masivas o diarias, aunque proporcionarán información del
rendimiento del proceso Gestión de la Capacidad. El proceso deberá abarcar todas las áreas de
la tecnología, tanto el hardware como el software, para todos los componentes y entornos
tecnológicos de TI.
Gestión de la Capacidad también deberá considerar la capacidad de la planificación del espacio

y de los sistemas de acondicionamiento además de ciertos aspectos asociados con los recursos
humanos, pero sólo si una falta de recursos humanos pudiera generar un incumplimiento de
objetivos de SLAs u OLAs, un retraso en el rendimiento extremo a extremo o en el tiempo de
respuesta del servicio, o una imposibilidad para cumplir los compromisos y planes futuros (p.
ej., la planificación de backups de datos no se completó en el tiempo porque no había
operadores para cargar las cintas).
Básicamente el Alcance de este proceso se centra en:
 Rendimiento y Capacidad de TI
 Áreas de tecnología (Hardware y Software)
 Planificación de espacio físico.
 Recursos humanos si se incumplen objetivos de SAL y OLA

El proceso de Gestión de la Capacidad deberá incluir:
 Monitorizar modelos de actividad del negocio y planes de nivel de servicio a través del
desempeño, utilización y rendimiento de servicios de TI y de
 la infraestructura de soporte, entorno, datos y componentes de las aplicaciones, y

generación de informes regulares y ad hoc sobre la capacidad y rendimiento de
componentes y servicios
 Emprender actividades de ajuste para lograr el uso más eficiente de recursos de TI

existentes
 Entender las demandas acordadas actuales y futuras del cliente con respecto a los
recursos de TI, y elaborar previsiones para futuros requisitos
 Influir en Gestión de la Demanda, quizás en colaboración con Gestión Financiera
 Elaborar un Plan de Capacidad que permita al proveedor de servicio continuar dando

servicios de la calidad definida en los SLAs y que cubra una franja de tiempo suficiente
de planificación para cumplir los futuros niveles de servicios requeridos como se define
en el Porfolio de Servicios y SLRs
 Colaborar con la identificación y resolución de cualquier incidencia y problema

asociados con el rendimiento del servicio o componente
 La mejora proactiva del rendimiento del servicio o componente siempre que sea
justificable en costes y cumpla las necesidades del negocio.

5.15.5 SUB PROCESOS
A continuación vamos a definir los tres subprocesos que incluye gestión de las Capacidad.
Gestión de la • Traduce las necesidades y planes de negocio en requisitos para el servicio e

capacidad del infraestructura de TI, garantizando que los futuros requisitos de negocio para los
Negocio servicios de TI se cuantifiquen, diseñen, planifiquen e implementen de forma
oportuna.
Gestión de la • Gestión, control y predicción de la capacidad y del rendimiento extremo a extremo

capacidad del de las cargas de trabajo y del uso de los servicios de TI operativos activos.
Servicio
Gestión de la • Gestión, control y predicción del rendimiento, utilización y capacidad de

capacidad del componentes tecnológicos de TI individuales.
Componente

5.15.6 PLAN DE CAPACIDAD
Una de las actividades clave de Gestión de Capacidad es generar un plan que documente los
niveles actuales de utilización de recursos y de rendimiento del servicio y, después de la
consideración de Estrategia del Servicio, la planificación y elaboración de previsiones de los
futuros requisitos para nuevos recursos de TI que darán soporte a los servicios de TI que
apoyarán las actividades de negocio. El plan debe indicar claramente cualquier suposición
hecha. También debe incluir cualquier recomendación cuantificada en términos de recursos
requeridos, coste, beneficios, impacto, etc.
La producción y mantenimiento de un Plan de Capacidad deberán producirse a intervalos

definidos previamente. Es esencialmente un plan de inversión y por lo tanto deberá publicarse
anualmente, en línea con el negocio o con el ciclo de vida presupuestario, y deberá
completarse antes del inicio de las negociaciones sobre futuros presupuestos. Podría ser
necesario una reedición trimestral del plan actualizado para tener en cuenta cambios en los
planes del servicio manteniendo de esta forma la precisión de las previsiones, y para hacer o
refinar recomendaciones. Esto implica un esfuerzo adicional, pero si se actualizara
regularmente, es más probable que el Plan de la Capacidad sea preciso y refleje la necesidad
cambiante del negocio.
 El plan de capacidad se utiliza para gestionar los recursos necesarios para la entrega de
servicios de TI y para la planificación de la capacidad de la infraestructura de TI
 Contiene información sobre el uso actual de servicios y componentes.
 Contiene planes para el desarrollo de la capacidad de TI para satisfacer las necesidades

en la expansión tanto de servicios existentes como de cualquier nuevo servicio
acordado
 Debe utilizarse activamente como base para la toma de decisiones. Éste se basa en los
tres Sub-procesos.

GESTIÓN DE CONTINUIDAD

5.16 GESTIÓN DE CONTINUIDAD
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVO
 ALCANCE
 ACTIVIDADES
 ANALISIS DE IMPACTO DEL NEGOCIO (BIA)
La meta de Gestión de Continuidad (ITSCM) es respaldar el proceso general de Gestión de la

Continuidad del Negocio asegurando que las instalaciones técnicas y del servicio de TI
requeridas (que incluyen sistemas informáticos, redes, aplicaciones, repositorios de datos,
telecomunicaciones, entorno, soporte técnico y Centro de Servicio al Usuario) puedan
reanudarse según los plazos de tiempo de negocio requeridos y acordados.
Puesto que la tecnología es un componente central de la mayoría de los procesos de negocio,

la disponibilidad alta o continua de TI es crítica para la supervivencia del negocio en su
totalidad. Esto se consigue introduciendo medidas de reducción del riesgo y opciones de
recuperación. Al igual que todos los elementos de ITSM, sólo puede realizarse con éxito la
implementación de ITSCM con el compromiso de la gestión sénior y con el respaldo de todos
los miembros de la organización. El mantenimiento continuo de la capacidad de recuperación
es esencial si se desea que este éxito se mantenga.
5.16.2 PROPÓSITO
El propósito de ITSCM es mantener la capacidad de recuperación continua necesaria dentro de

los servicios de TI y sus componentes de soporte.

5.16.3 OBJETIVO
 Mantener un conjunto de Planes de Continuidad de los Servicios y planes de

recuperación de TI que respalden los Planes de Continuidad del Negocio (BCP)
generales de la organización.
 Completar ejercicios regulares de Análisis de Impacto en el Negocio (BIA) para

asegurar que se mantengan todos los planes de continuidad alineados con los
impactos y requisitos cambiantes del negocio.
 Realizar ejercicios regulares de Análisis y Gestión del Riesgo, especialmente junto con
el negocio y los procesos de Gestión de la Disponibilidad y Gestión de la Seguridad,
que gestionen los servicios de TI dentro de un nivel de riesgo de negocio acordado.
 Proporcionar asesoramiento y directrices a todas las demás áreas del negocio y de TI

en todos los aspectos relacionados con la continuidad y la recuperación.
 Asegurar que se pongan en práctica los mecanismos de continuidad y recuperación

adecuados para satisfacer o superar los objetivos de continuidad del negocio
acordados.
 Evaluar el impacto de todos los cambios sobre los Planes de Continuidad de los
Servicios y planes de recuperación de TI.
 Asegurar que se implementen medidas proactivas para mejorar la disponibilidad de los

servicios siempre que tengan un coste justificable.
 Negociar y acordar los contratos necesarios con suministradores para la provisión de la

capacidad de recuperación necesaria para dar apoyo a todos los planes de continuidad
junto con el proceso de Gestión de Suministradores.

5.16.4 ALCANCE
ITSCM se centra en los eventos a los que el negocio concede suficiente importancia como para
que se consideren un desastre. Los eventos menos importantes se abordarán dentro del
proceso de Gestión de Incidencias. La definición de qué constituye un desastre diferirá de una
organización a otra. El impacto de una pérdida de un proceso de negocio, por ejemplo una
pérdida financiera, daño a la reputación o incumplimiento regulatorio, se mide a través de un
ejercicio BIA, que determina los requisitos críticos mínimos. ITSCM ofrece soporte a los
requisitos técnicos de TI y de servicio específicos.
El ámbito de ITSCM dentro de una organización se determina a través de la estructura

organizativa, cultura y dirección estratégica (del negocio y la tecnología) en términos de
servicios provistos y cómo se desarrollan y cambian con el paso del tiempo.
ITSCM tiene en cuenta principalmente los activos y configuraciones de TI que respaldan los
procesos de negocio. Si (después de un desastre) se requiere reasignar a una ubicación de
trabajo alternativa, también se requerirá la provisión de elementos como instalaciones y
alojamiento para el personal, copias de registros en papel críticos, servicios de mensajería e
instalaciones telefónicas para comunicarse con clientes y terceros.
El ámbito tendrá que tener en cuenta el número y ubicación de las oficinas de la organización y
los servicios realizados en cada una.
Normalmente, ITSCM no cubre directamente riesgos a más largo plazo, como los de los
cambios en la dirección del negocio, diversificación, reestructuración, fallo de un competidor
principal y demás. Aunque estos riesgos pueden tener un impacto importante en los
elementos del servicio de TI y sus mecanismos de continuidad, normalmente hay tiempo para
identificar y evaluar el riesgo e incluir la mitigación del riesgo a través de cambios o variaciones
en las estrategias del negocio y TI, formando parte en consecuencia del programa de Gestión
de Cambios general del negocio y TI.
De forma similar, ITSCM no trata normalmente fallos técnicos menores (por ejemplo, fallo de
disco no crítico), a menos que exista la posibilidad de que el impacto pueda tener un efecto
importante en el negocio. Se esperaría que estos riesgos se cubriesen principalmente a través
del Centro de Servicio al Usuario y del proceso de Gestión de Incidencias, o que se resolviesen
a través de la planificación asociada con los procesos de Gestión de la Disponibilidad, Gestión
de Problemas, Gestión de Cambios, Gestión de la Configuración y de la gestión operativa
'rutinaria'.

El proceso ITSCM incluye:
 El acuerdo del ámbito del proceso ITSCM y las políticas adoptadas.
 Análisis de Impacto en el Negocio (BIA) para cuantificar el impacto que tendría la

pérdida del servicio de TI sobre el negocio.
 Análisis de Riesgo (RA) - identificación y evaluación del riesgo para identificar

amenazas potenciales en la continuidad y la probabilidad de que las amenazas se
materialicen.
 Elaboración de una estrategia de ITSCM general que debe integrarse en la estrategia

de BCM.
 Elaboración de un plan de ITSCM, integrado en BCM.
 Pruebas de los planes.
 Operación y mantenimiento continúo de los planes.

5.16.5 ACTIVIDADES
Debería adoptarse una metodología de ciclo de vida a la configuración y operación de un

proceso ITSCM. La siguiente Figura muestra el ciclo de vida de ITSCM, desde el inicio hasta el
aseguramiento continuo de que la protección provista por el plan está actualizada y refleja
todos los cambios en los servicios y niveles de servicio. ITSCM es un proceso cíclico a lo largo
del ciclo de vida para asegurar que, una vez se hayan desarrollado planes de continuidad y
recuperación, se mantengan alineados con los Planes de continuidad del negocio (BCPs) y
prioridades del negocio. La Figura siguiente también muestra el rol desempeñado dentro del
proceso ITSCM de BCM.
INICIACIÓN. El proceso de iniciación cubre la totalidad de la organización y consta de las

siguientes actividades:
 Definición de la política. Debería definirse y comunicarse lo antes posible para que

todos los miembros de la organización implicados en, o afectados por, problemas de
Continuidad del Negocio sean conscientes de sus responsabilidades para cumplir y
respaldar ITSCM. Como mínimo, la política debería determinar la intención y los
objetivos de la gestión.

 Especificar términos de referencia y ámbito. Se incluye la definición del ámbito y las

responsabilidades de todo el personal de la organización. Cubre tareas tales como
realizar un Análisis del Riesgo y Análisis de Impacto en el Negocio y la determinación
de la estructura de orden y control requerida para respaldar una interrupción del
negocio. También existe la necesidad de tener en cuenta problemas como puntos de
auditoría pendientes, requisitos regulatorios o del cliente y estipulaciones de la
organización aseguradora, y conformidad con normas como ISO 27001, el Estándar
sobre Gestión de la Segundad de la Información, que también aborda requisitos de
Continuidad del Negocio.
 Asignar recursos. El establecimiento de un entorno de Continuidad del Negocio eficaz

requiere considerables recursos tanto económicos como de personal. En función de la
madurez de la organización con respecto a ITSCM, puede existir el requisito de
familiarizar y/o formar al personal para realizar las tareas de la Etapa 2. De forma
alternativa, el uso de consultores externos experimentados puede ayudar a realizar el
análisis con mayor rapidez. No obstante, es importante que la organización pueda
mantener el avance del proceso sin la necesidad de confiar, total o parcialmente, en
soporte externo.
 Definir la organización del proyecto y la estructura de control. Los proyectos de

ITSCM y BCM son potencialmente complejos y deben estar bien organizados y
controlados. Se recomienda encarecidamente utilizar una metodología de
planificación de proyectos estándar y reconocida, como Proyectos en Entornos
controlados (PRINCE2®) o Project Management Body Of Knowledge (PMBOK®).
 Acordar planes de proyecto y de calidad. los planes permiten controlar el proyecto y

abordar las variaciones. Los planes de calidad garantizan que se consigan los
resultados con un nivel de calidad aceptable. También facilitan un mecanismo para
comunicar los requisitos de recursos y entregables del proyecto, obteniéndose de esta
forma la aceptación de las partes necesarias.
REQUERIMIENTOS Y ESTRATEGIA. La determinación de los requisitos de negocio para la

continuidad del servicio de TI es un componente crítico para identificar la eficacia con la que
una organización sobrevivirá a una interrupción del negocio o desastre y los costes en los que
incurrirá. Si el análisis de los requisitos es incorrecto, o se ha perdido información clave,
podrían producirse graves consecuencias en la eficacia de los mecanismos de ITSCM.
 Requisitos - realizar un Análisis de Impacto en el Negocio (BIA) y una evaluación del

riesgo. El BIA lo estudiaremos en el punto siguiente.
 Estrategia - después del análisis de los requisitos, la estrategia debería documentar las
medidas requeridas de reducción del riesgo y las opciones de recuperación para
respaldar al negocio.

IMPLEMENTACIÓN. Una vez se haya aprobado la estrategia, deben elaborarse los Planes de
Continuidad de los Servicios de TI alineados con los Planes de Continuidad del Negocio.
Deben desarrollarse planes de ITSCM para permitir que la información necesaria para
sistemas, servicios e instalaciones críticas se continúe suministrando o sea restablecida en un
periodo de tiempo aceptable para el negocio. Generalmente, los Planes de Continuidad del
Negocio se basan en la disponibilidad de los servicios de TI, instalaciones y recursos. Como
consecuencia de lo anterior, los planes de ITSCM deben abordar todas las actividades para
asegurar que se entreguen los servicios, instalaciones y recursos requeridos en un estado
operativo aceptable y que estén 'ajustados al propósito' cuando sean aceptados por el
negocio. Esto no sólo incluye la restauración de servicios e instalaciones, sino también el
entendimiento de las dependencias entre ellos, las pruebas requeridas antes de la entrega
(pruebas de rendimiento, funcionales, operativas y de aceptación) y la validación de la
integridad y consistencia de datos.
OPERACIÓN CONTINUA. Esta etapa consiste en lo siguiente.
 Educación, concienciación y formación. Debería cubrir los elementos específicos de la

continuidad del servicio de la organización y, en particular, de la organización de TI.
Esto asegura que todo el personal sea consciente de las implicaciones de la
continuidad del negocio y del servicio, las tenga en cuenta dentro de su trabajo normal
y que todos los implicados en el plan hayan recibido formación para implementar sus
acciones.
 Revisión. Es necesario realizar la revisión regular de todos los entregables del proceso
de ITSCM para asegurar que siguen estando actualizados.
 Pruebas. Después de las pruebas iniciales, es necesario establecer un programa de

pruebas regulares para asegurar que se prueben los componentes críticos de la
estrategia, al menos anualmente si fuera posible, aunque las pruebas de los Planes de
Continuidad del Servicio de TI deberían organizarse en línea con las necesidades del
negocio y de los BCPs. También deberían probarse todos los planes después de cada
cambio de negocio importante. Es fundamental que también se incluya en la estrategia
cualquier cambio introducido en la tecnología de TI, que se implemente de una forma
adecuada y que se pruebe para garantizar que funciona correctamente dentro de la
provisión general de TI después de un desastre. El backup y la recuperación del
servicio de TI también deberían monitorizarse y probarse para asegurar que funcionen
tal y como se requiere durante una incidencia grave. Este aspecto se trata con mayor
detalle en la publicación Operación del Servicio.
 Gestión de cambios. El proceso Gestión de Cambios debería asegurarse de evaluar el

impacto potencial de todos los cambios en los planes de ITSCM. Si el cambio
planificado va a invalidar los planes, debe actualizarse el plan antes de que se
implemente el cambio y debería probarse dentro de las pruebas del cambio. Los
propios planes deben estar bajo un control muy estricto por parte de Gestión de
Cambios y Gestión de la Configuración. El fallo de los BCPs puede provocar que existan

planes imprecisos y capacidad de recuperación inadecuada. Además, de forma

continua, siempre que haya servicios nuevos o cuando se produzcan cambios
importantes en los mismos, es esencial que se realice un BIA y una evaluación de
riesgos en el servicio nuevo o modificado y que la estrategia
INVOCACIÓN. Invocación es la prueba final de los Planes de Continuidad del Negocio y ITSCM.
Si todo el trabajo de preparación ha concluido con éxito y se han desarrollado y probado los
planes, entonces una invocación de los Planes de Continuidad del Negocio debería ser un
proceso sencillo, aunque pueden esperarse fallos si no se hubieran probado los planes. Es
importante prestar la atención debida al diseño de todos los procesos de invocación para
asegurar que estén ajustados para su propósito e interactúen con todos los demás procesos de
invocación necesarios.
Invocación es un componente clave de los planes, que debe incluir el proceso y guía de la
invocación. Es necesario recordar que la decisión de realizar la invocación no debe tomarse a la
ligera, especialmente si se debe utilizar una instalación de recuperación externa. Existirán
costes y el proceso implicará alteraciones para el negocio. Esta decisión normalmente la
adopta un equipo de 'Gestión de crisis', integrado por gestores sénior del negocio y de
departamentos de soporte (incluyendo TI), que utilizan información recopilada a través de la
evaluación de daños y otras fuentes.

5.16.6 ANALISIS DE IMPACTO DEL NEGOCIO (BIA)
El propósito de un Análisis de impacto en el negocio es cuantificar el impacto en el negocio que

tendría la pérdida de servicio. Este impacto podría ser 'tangible' ya que puede identificarse con
precisión, como por ejemplo una pérdida financiera, o 'intangible', como por ejemplo
relaciones públicas, moral, seguridad y salud o pérdida de ventaja competitiva. El BIA
identificará los servicios más importantes para la organización y, en consecuencia, será una
entrada clave para la estrategia.
El BIA tiene que tener en cuenta una serie de consideraciones:
 La forma que el daño o pérdida puede adoptar (Pérdida de ingresos, Costes

adicionales, daño a la reputación, Pérdida de ventaja competitiva, etc.)
 Probabilidad de escalado del grado de daño o pérdida después de una interrupción del
servicio y las horas del día, semana, mes o año en la que la interrupción será más grave
 Plantilla, habilidades, instalaciones y servicios (incluyendo los servicios de TI)

necesarios para permitir que procesos de negocio críticos y esenciales continúen
operando en un nivel mínimo aceptable
 El tiempo en el que deberían recuperarse los niveles mínimos de personal,

instalaciones y servicios
 El tiempo en el que deberían recuperarse por completo todos los procesos de negocio,
personal, instalaciones y servicios requeridos
 La prioridad de recuperación de negocio relativa para cada uno de los servicios de TI.

GESTIÓN DE SEGURIDAD

5.17 GESTIÓN DE SEGURIDAD
 INTRODUCCIÓN
 PROPÓSITO Y OBJETIVO
 ALCANCE
 POLÍTICAS
 MARCO DE TRABAJO
La meta del proceso Gestión de la Seguridad de la Información (ISM), es alinear la seguridad de

TI con la seguridad del negocio, y garantizar que la seguridad de la información se gestione de
forma eficaz en todas las actividades del servicio y de Gestión del Servicio.
ISM Garantiza que se implementan las políticas de seguridad y que se da soporte a las
necesidades de políticas de seguridad del negocio
ISM debe estar incluido dentro del marco de trabajo de gobierno corporativo general. El
gobierno corporativo es el conjunto de responsabilidades y prácticas ejercidas por el consejo y
dirección ejecutiva con el objetivo de proporcionar dirección estratégica, asegurar la
consecución de los objetivos, verificar que los riesgos se estén gestionando de forma
conveniente y comprobar que los recursos de la empresa se utilicen de forma eficaz.
Seguridad de la información es una actividad de gestión dentro del marco de trabajo de

gobierno corporativo, que proporciona la dirección estratégica para las acciones de seguridad
y asegura que se alcancen los objetivos. Además, asegura que se gestionen adecuadamente los
riesgos de seguridad de la información y que los recursos de información de la empresa se
usen con responsabilidad. El propósito de ISM es proporcionar un enfoque para todos los
aspectos de seguridad de TI y gestionar todas las actividades de TI.
El término 'información' se utiliza como un término general e incluye almacenamiento de

datos, bases de datos y metadatos. El objetivo de seguridad de la información es proteger los
intereses de aquellos que se basen en la información, y los sistemas y comunicaciones que
proporcionan la información, del perjuicio provocado por los fallos de disponibilidad,
confidencialidad e integridad.

5.17.2 PROPÓSITO Y OBJETIVO
El proposito y Objetivo de Gestión de la seguridad es cumplir con la Confidencialidad,

Integridad, Disponibilidad y Autenticidad de la Información.
Confidencialidad • La información se observa o divulga exclusivamente a aquellas personas con

derecho a conocerla.
Integridad • La información es completa, precisa y está protegida frente a la modificación

no autorizada.
Disponibilidad • La información está disponible y se puede utilizar cuando se requiera, y los

sistemas que la proveen pueden resistir adecuadamente ataques y
recuperarse de fallos o evitarlos.
Autenticidad • Se puede confiar en las transacciones de negocio, así como en los

intercambios de información entre empresas o con socios.

5.17.3 ALCANCE
El alcance de este proceso se podría resumir en los siguientes puntos:
 Entendimiento de los requisitos de seguridad actuales y futuros acordados del negocio

y de la Política y planes de Seguridad del Negocio
 Implementación de un conjunto de controles de seguridad que respalde a la Política de

Seguridad de la Información y gestión de los riesgos asociados con el acceso a
servicios, información y sistemas
 Documentación de todos los controles de seguridad, junto con la operación y

mantenimiento de los controles y sus riesgos asociados
 Gestión de suministradores y contratos relacionados con el acceso a sistemas y

servicios, junto con Gestión de Suministradores
 Gestión de todas las violaciones e incidencias de seguridad asociadas con todos los
sistemas y servicios
 La mejora proactiva de los controles de seguridad, gestión del riesgo para la seguridad
y la reducción de los riesgos para la seguridad
 Integración de los aspectos de la seguridad dentro del resto de procesos de ITSCM.

5.17.4 POLÍTICAS
Las actividades de Gestión de la Seguridad de la Información deberían centrarse y estar

impulsadas por una política de Seguridad de la Información general y un conjunto de políticas
de seguridad específicas de soporte. La Política de Seguridad de la Información debería contar
con el respaldo absoluto de la alta dirección ejecutiva de TI, e idealmente, con el apoyo y el
compromiso de la alta dirección ejecutiva del negocio. La política debería cubrir todas las áreas
de seguridad, ser apropiada, y satisfacer las necesidades del negocio, y debería incluir:
 Uso y abuso de los activos de TI

 Una política de control de acceso
 Una política de control de contraseña
 Una política de email e Internet
 Una política antivirus
 Una política de clasificación de la información
 Una política de clasificación de documentos
 Una política de accesos remotos
 Una política relativa al acceso de los suministradores a los servicios TI,
información y componentes
 Una política de infracción de copyright de material electrónico
 Una política de eliminación de activos
 Una política de retención de registros

5.17.5 MARCO DE TRABAJO
El marco de trabajo o el SGSI proporciona a su vez una base para el desarrollo de un programa
de información económico que respalda los objetivos de negocio. Implicará las cuatro P de
personas (People), proceso (Process), productos (Products) y tecnología, así como socios
(Partners) y suministradores para asegurar la aplicación de niveles elevados de seguridad.
ISO 27001 es el estándar formal con el que las organizaciones pueden buscar la certificación
independiente de sus SGSI (esto es, sus marcos de trabajo para diseñar, implementar,
mantener y aplicar procesos y controles de seguridad de la información de forma sistemática y
uniforme en todas las organizaciones). El SGSI que se muestra en la siguiente figura contiene
una metodología que se utiliza ampliamente y que se basa en el asesoramiento y guía que se
describe en muchas fuentes, incluyendo ISO 27001.
Los cinco elementos que contiene este marco de trabajo son los siguientes:
Control. Los objetivos del elemento de control del SGSI son:
 Establecer un marco de trabajo para iniciar y gestionar la seguridad de la información

en la organización
 Establecer una estructura organizativa para preparar, aprobar e implementar la

Política de Seguridad de la Información
 Asignar responsabilidades
 Establecer y controlar documentación.

Plan. El objetivo del elemento del plan del SGSI es concebir y recomendar las medidas de
seguridad adecuadas, basándose en una comprensión de los requisitos de la organización.
Los requisitos se recopilarán de fuentes como riesgo de negocio y servicio, planes y

estrategias, SLAs y OLAs y de las responsabilidades legales, morales y éticas para la seguridad
de la información. Deben tenerse en cuenta otros factores, como la cantidad de financiación
disponible y la cultura y actitudes existentes hacia la seguridad.
La Política de Seguridad de la Información define la actitud y posición de la organización con

respecto a los asuntos de seguridad. Éste debería ser un documento para toda la organización,
no sólo aplicable al proveedor de servicios de TI. La responsabilidad de mantenimiento de los
documentos reside en el Gestor de la Seguridad de la Información.
Implementación. El objetivo de la implementación del SGSI es asegurar que se pongan en

práctica los procesos, herramientas y controles adecuados para apoyar la Política de Seguridad
de la Información.
Entre las medidas se incluyen:
 Responsabilidad para los activos - Aquí son inestimables Gestión de la Configuración y

el CMS
 Clasificación de la información - la información y los repositorios deberían clasificarse

de acuerdo con la sensibilidad y el impacto de la divulgación.
La implementación exitosa de los controles y medidas de seguridad depende de diversos

factores:
 Establecimiento de una política clara y acordada, integrada con las necesidades del
negocio
 Procedimientos de seguridad que estén justificados, sean apropiados y estén

respaldados por la gestión senior
 Marketing y formación eficaces en los requisitos de seguridad
 Un mecanismo de mejora.
Evaluación. Los objetivos del elemento de evaluación del SGSI son:
 Supervisar y comprobar la conformidad con la política de seguridad y los requisitos de

seguridad en SLAs y OLAs
 Realizar auditorías regulares de seguridad técnica de los sistemas de TI
 Proporcionar información a auditores y reguladores externos, si se requiere.

Mantenimiento. Los objetivos del elemento de mantenimiento del SGSI son:
 Mejorar los acuerdos de seguridad especificados en, por ejemplo, SLAs y OLAs
 Mejorar la implementación de medidas y controles de seguridad.
Lo anterior debería lograrse utilizando un ciclo PDCA (Planificar-Hacer-Verificar-Actuar), que es

una metodología formal sugerida por ISO 27001 para el establecimiento del Sistema de
Gestión de Seguridad de la Información (SGSI) o marco de trabajo. Este ciclo se describe con
más detalle en la publicación Mejora Continua del Servicio.

GESTIÓN DE PROVEEDORES

5.18 GESTIÓN DE PROVEEDORES
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVO
 ALCANCE
 CATEGORIZACIÓN DE PROVEEDORES
La meta del proceso de Gestión de suministradores es gestionar suministradores y los servicios

que suministran para proporcionar la calidad continua del servicio de TI para el negocio,
asegurando que se obtenga una buena relación calidad-precio.
El proceso Gestión de Suministradores asegura que se gestionen los suministradores y los

servicios que proveen para dar soporte a los objetivos del servicio de TI y expectativas del
negocio. El objetivo de esta sección es concienciar sobre el contexto de trabajo con socios y
suministradores del negocio, y cómo este trabajo puede dirigirse de la mejor forma para
materializar el beneficio de negocio en la organización.
Es muy importante que los procesos y planificación de Gestión de Suministradores se

impliquen en todas las etapas del Ciclo de Vida del Servicio, desde estrategia y diseño, a través
de transición y operación, hasta mejora del servicio. La complejidad de las exigencias de
negocio requiere un ámbito completo de habilidades y capacidades para dar soporte a la
provisión de un conjunto integral de servicios de TI a un negocio. En consecuencia, el uso de
redes de valor y los suministradores y servicios que proveen son una parte integral de
cualquier solución extremo a extremo. Los suministradores y la gestión de suministradores y
socios son esenciales para la provisión de servicios de TI de calidad.

5.18.2 PROPÓSITO
El propósito del proceso de Gestión de Suministradores es conseguir una buena relación

calidad-precio con los suministradores y garantizar que éstos se ciñan a los objetivos incluidos
en sus contratos y acuerdos, mientras cumplen todos los términos y condiciones.
5.18.3 OBJETIVO
Los principales objetivos de Gestión de Suministradores son:
 Conseguir una buena relación calidad-precio con el suministrador y contratos
 Asegurar que los acuerdos y contratos de soporte con suministradores estén alineados
con las necesidades de negocio, y den soporte y estén alineados con los objetivos de
los SLRs y SLAs, junto con SLM
 Gestionar relaciones con suministradores
 Gestionar el rendimiento de los suministradores
 Negociar y acordar contratos con suministradores y gestionarlos a lo largo de su ciclo

de vida
 Mantener una política de suministradores y una Base de Datos de Suministradores y

Contratos (SDC).

5.18.4 ALCANCE
El proceso Gestión de Suministradores debería incluir la gestión de todos los suministradores y

contratos para dar respaldo a la provisión de servicios de TI al negocio. Cada proveedor de
servicio debería contar con procesos formales para la gestión de todos los suministradores y
contratos. Sin embargo, los procesos deberían adaptarse en función de la importancia del
suministrador y/o el contrato y el impacto de negocio potencial sobre la provisión de servicios.
Muchos suministradores proporcionan soporte para servicios y productos que

independientemente tienen un rol relativamente menor e indirecto en la generación de valor,
pero que colectivamente realizan una contribución directa e importante a la generación de
valor y a la implementación de la estrategia general del negocio. Cuanto mayor sea la
contribución que el suministrador aporte al valor del negocio, más esfuerzo debería poner el
proveedor de servicio en la gestión del suministrador y más debería implicarse éste en el
desarrollo y realización de la estrategia del negocio. Cuanto menor sea la contribución de valor
del suministrador, más probable será que la relación se gestione principalmente a un nivel
operativo, con una interacción limitada con el negocio. En algunas organizaciones,
particularmente las grandes, podría ser apropiado la gestión de los equipos internos y
suministradores, en los que las unidades de negocio pueden dar soporte a elementos clave.
El proceso Gestión de Suministradores deberá incluir:
 Implementación y aplicación de la política del suministrador
 Mantenimiento de una Base de Datos de Suministradores y de Contratos (SCD)
 Categorización y evaluación del riesgo de suministradores y contratos
 Evaluación y selección de suministradores y contratos
 Desarrollo, negociación y acuerdo de contratos
 Revisión, renovación y finalización de contratos
 Gestión y rendimiento de los suministradores
 Acuerdo e implementación del servicio y planes de mejora del suministrador
 Mantenimiento de contratos, términos y condiciones estándar
 Gestión de resolución de conflictos contractuales
 Gestión de suministradores subcontratados.

La figura siguiente muestra las actividades de Gestión de suministradores:
Identificación de la necesidad del negocio y preparación del caso de negocio:
 Elaborar una Declaración de Requisitos (SOR) y/o Convocatoria de Licitación (ITT)
 Asegurar la conformidad con la estrategia/política
 Preparar el caso de negocio inicial, incluyendo opciones (internas y externas), costes,

plazos de tiempo, objetivos, beneficios y evaluación de riesgos.
Evaluación y aprovisionamiento de nuevos suministradores y contratos:
 Identificar el método de compra o aprovisionamiento

 Establecer criterios de evaluación - por ejemplo, servicios, capacidad (tanto personal

como organizativa), calidad y coste
 Evaluar opciones alternativas Seleccionar
 Negociar contratos, objetivos y los términos y condiciones, incluyendo

responsabilidades, cierre, renovación, extensión, disputa y transferencia Acordar y
conceder el contrato.
Establecer nuevos suministradores y contratos:
 Configurar el servicio y contrato del suministrador, dentro del SCD y cualquier otro
sistema corporativo asociado
 Transición del servicio
 Establecer contactos y relaciones.
Categorización de suministradores y contratos:
 Evaluación o reevaluación del suministrador y contrato
 Asegurar que los cambios progresen a lo largo de la Transición del Servicio

Categorización del suministrador
 Actualización del SCD
 Mantenimiento continúo del SCD.
Gestionar el rendimiento del suministrador y contrato:
 Gestión y control de la operación y entrega de servicios/productos
 Monitorizar e informar (servicio, calidad y costes) Revisar y mejorar (servicio, calidad y

costes) Gestión del suministrador y de la relación (comunicación, riesgos, cambios,
fallos, mejoras, contactos e interfaces)
 Revisar, al menos anualmente, el ámbito del servicio con respecto a la necesidad,

objetivos y acuerdos del negocio Planificar un cierre/renovación/extensión.
Fin de la vigencia:
 Revisar (determinar los beneficios entregados, requisitos continuos)
 Renegociar y renovar o rescindir y/o transferir.

5.18.5 CATEGORIZACIÓN DE PROVEEDORES
El proceso de Gestión de Suministradores debe ser adaptativo, dedicar más tiempo y esfuerzo
a la gestión de suministradores estratégicos (clave) que a los suministradores menos
importantes. Esto significa que debe existir alguna forma de subproceso de clasificación por
categorías dentro del proceso de Gestión de Suministradores para clasificar por categorías al
suministrador y su importancia para el proveedor de servicio y para los servicios suministrados
al negocio. Los suministradores pueden clasificarse por categorías de muchas formas, pero uno
de los mejores métodos se basa en la evaluación del riesgo e impacto asociados con el uso del
suministrador, y con el valor e importancia del suministrador y de sus servicios para el negocio,
como se ¡lustra en la siguiente figura.

Estratégico • Para relaciones significativas de 'asociación' que implican que los responsables
Senior compartan información estratégica para facilitar la concepción de planes a
largo plazo.
Táctico • Para relaciones que implican una actividad comercial importante e interacción con
el negocio.
Operativo • Para suministradores de productos o servicios operativos.
Commodity • Para suministradores que proporcionan productos y servicios disponibles de bajo

valor y/o ya disponibles fácilmente que podrían aprovisionarse alternativamente
con relativa facilidad

UNIDAD 6 – TRANSICIÓN DEL SERVICIO
Fundamentos
6 – TRANSICIÓN DEL SERVICIO

6 TRANSICIÓN DEL SERVICIO
 INTRODUCCIÓN A LA TRANSICIÓN
 PROPÓSITO DE LA TRANSICIÓN
 OBJETIVOS DE LA TRANSICIÓN DEL SERVICIO
 VALOR PARA EL NEGOCIO
 CONCEPTOS BÁSICOS
 ALCANCE DE LA TRANSICIÓN
 PLANIFICACIÓN Y SOPORTE DE LA TRANSICIÓN
 GESTIÓN DE CAMBIOS
 GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS DEL SERVICIO
 GESTIÓN DE VERSIONES Y DESPLIEGUES
 GESTIÓN DE VALIDACIÓN Y PRUEBAS
 GESTIÓN DE EVALUACIÓN DEL CAMBIO
 GESTIÓN DEL CONOCIMIENTO

6.1 INTRODUCCIÓN A LA TRANSICIÓN
 El objetivo principal de la etapa de Transición del Servicio es planificar y gestionar los

cambios del servicio así como desplegar entregas de servicio en un entorno de
producción
 Transición del Servicio proporciona una guía sobre cómo los requisitos de Estrategia
del Servicio que se codifican en Diseño del Servicio, se materializan de forma eficaz en
Operación del Servicio mientras se controlan los riesgos de fallo y discontinuidad.
 El objetivo de esta unidad es que el alumno entienda, cuales son todos los procesos
que intervienen en la transición del Servicio y elementos que intervienen a la hora de
Almacenar y registrar todas las actividades realizadas.
6.2 PROPÓSITO DE LA TRANSICIÓN
 Planificar y gestionar la capacidad y los recursos requeridos para empaquetar,

construir, probar y desplegar una entrega en producción y desplegar el servicio
especificado en los requisitos del cliente y de los interesados.
 Proporcionar un marco de trabajo consistente y riguroso para evaluar la capacidad del

servicio y el perfil del riesgo antes de que se entregue o despliegue un servicio nuevo o
modificado.
 Establecer y mantener la integridad de todos los activos y configuraciones

identificados del servicio a medida que evolucionan durante la transición del servicio.
 Proporcionar información y conocimiento de buena calidad para que Gestión de

Entregas y Despliegues y Gestión de Cambios puedan agilizar la toma de decisiones
eficaces con respecto a la promoción de una entrega, desde los entornos de prueba
hasta los de producción
 Proporcionar mecanismos eficientes y repetibles de construcción e instalación que se

puedan utilizar para desplegar entregas en los entornos de prueba y producción y dé
marcha atrás si se requiere restaurar el servicio a su estado anterior.
 Garantizar que se pueda gestionar, operar y dar soporte al servicio de acuerdo con los
requisitos y restricciones especificados dentro de Diseño del Servicio.

6.3 OBJETIVOS DE LA TRANSICIÓN DEL SERVICIO
 Planificar y coordinar los recursos para asegurar que los requisitos de la estrategia del
servicio codificados en el diseño del servicio se llevan a cabo eficazmente en operación
del servicio
 Coordinar actividades a través de proyectos, suministradores y equipos de servicio

cuando de requiera
 Planificar y gestionar los recursos para establecer satisfactoriamente un servicio nuevo

o modificado dentro de producción, de acuerdo con las estimaciones previstas de
coste, calidad y tiempo.
 Establecer sistemas nuevos o modificados de gestión de información y herramientas,

tecnología , arquitecturas, procesos, y los métodos de medición y métricas a fin de
cumplir con los requisitos establecidos en la fase del diseño del Servicio
 Identificar, gestionar y controlar los riesgos para minimizar las oportunidades de fallos
e interrupciones en las actividades de transición
 Monitorizar y mejorar el rendimiento de la fase del ciclo de vida transición del servicio
 Proporcionar planes claros y comprensibles que hagan posible que los clientes y el
negocio cambien proyectos para alinear sus actividades con los planes de transición
del servicio.
 Asegúrese de que todas las partes adoptan el marco común en cuanto a la reutilización
de procesos y sistemas de Soporte con el fin de mejorar la eficacia y eficiencia de las
actividades de planificación y coordinación

6.4 VALOR PARA EL NEGOCIO
 Utilizar proyectos para estimar costes, tiempos, necesidades de recursos y riesgos

asociados a la etapa de transición del servicio con mayor precisión
 Generar mayores volúmenes de cambios con éxito
 Compartir y reutilizar los activos de la transición en los proyectos y Servicios

Reducir los retrasos por enfrentamientos inesperados y dependencias. Por ejemplo, si
hay varios proyectos y deben utilizar el mismo entorno de prueba al mismo tiempo
 Aumentar la confianza para que el servicio nuevo o modificado puede ser entregado
cumpliendo las especificaciones sin afectar de forma inesperada a otros servicios o
grupos de interés
 Asegurar que los servicios nuevos o modificados serán Soportados y rentables
 Mejorar el control de las configuraciones y activos del servicio.
 Reducir el esfuerzo dedicado en los entornos de prueba y pilotos de la transición del

servicio
 Mejorar las expectativas de todos los interesados en la transición del servicio,

incluyendo clientes, usuarios, proveedores, socios y proyectos.

6.5 CONCEPTOS BÁSICOS
Sistema de Gestión de • Conjunto de herramientas y bases de datos usadas para gestionar los
la Configuración datos de Configuración de un Proveedor de Servicios de TI. El CMS
(CMS) también incluye información sobre Incidencias, Problemas, Errores
Conocidos, Cambios y Versiones; y puede contener datos sobre
empleados, Proveedores, ubicaciones, Unidades de Negocio, Clientes y
Usuarios. El CMS consta de herramientas para recopilar, almacenar,
gestionar, actualizar, y mostrar datos sobre todos los Elementos de
Configuración y sus Relaciones.
Sistema de Gestión de • Conjunto de herramientas y bases de datos que se emplean para

Conocimiento del gestionar el conocimiento y la información. El SKMS incluye tanto el
servicio (SKMS) Sistema de Gestión de la Configuración como otras herramientas y
bases de datos.
Cambio • Adición, modificación o eliminación de algo que podría afectar a los

Servicios de Ti. El Alcance debería incluir todos los Servicios de TI,
Elementos de Configuración, Procesos, Documentación, etc.
Petición de Cambio • Propuesta formal para que se realice un Cambio. Una RFC incluye
(RFC) detalles del Cambio propuesto, y puede registrarse en papel o
electrónicamente. El término RFC se suele confundir con Registro de
Cambio, o con el Cambio en sí.
Registro del Cambio • Contiene los detalles de un cambio.
Línea base (BL) • Una instantánea que se utiliza como punto de referencia:
 Punto de partida para medir el resultado de un Plan de Mejora

del Servicio
 Medir cambios en el Rendimiento de un Servicio de TI en un

periodo de tiempo
 Restablecer la Infraestructura de TI en una Configuración

conocida en caso de fallo de un Cambio o de un Entregable.

6.6 ALCANCE DE LA TRANSICIÓN
 Gestionar la complejidad asociada a cambios en los servicios y procesos de gestión de

servicios
 Reducir al mínimo las consecuencias no deseadas de cambio
 La introducción de nuevos servicios
 Los cambios en los servicios existentes, por ejemplo, ampliación, reducción, cambio de
proveedor, adquisición, cambio de requisitos o habilidades.
 Desmantelamiento e interrupción de los servicios, aplicaciones u otros componentes

de servicio
 La transferencia de servicios desde o hacia otros proveedores de servicios.
La siguiente figura muestra gráficamente el alcance de la Fase de Transición del Servicio. Este
diagrama se entenderá mejor cuando se hayan estudiado todos los procesos de esta fase.
Básicamente muestra cuales son las entradas y salidas de los procesos una vez que el servicio
está en la fase de transición.

Procesos Transición del Servicio

PLANIFICACIÓN Y SOPORTE DE LA TRANSICIÓN

6.7 PLANIFICACIÓN Y SOPORTE DE LA TRANSICIÓN
 INTRODUCCIÓN Y PROPÓSITO
 OBJETIVOS
 ALCANCE
6.7.1 INTRODUCCIÓN Y PROPÓSITO
 Este proceso corresponde a la propia transición del Servicio y su coordinación.
 Todas las actividades van enfocadas a poder realizar el despliegue del servicio
gestionando los recursos necesarios, con todas las garantías de que el usuario o el
cliente puedan utilizarlo de la manera prevista.
6.7.2 OBJETIVOS
Estos son los objetivos del proceso de Planificación y Soporte de la Transición:
 Planificar y coordinar los recursos para garantizar que los requisitos de la Estrategia del
Servicio codificados en el Diseño del Servicio se lleven a cabo eficazmente en la fase de
Operaciones del Servicio.
 Coordinar actividades a través de proyectos, suministradores y equipos de servicio

donde se requiera.
 Planificar y coordinar los recursos para establecer satisfactoriamente un servicio nuevo

o modificado en producción de acuerdo con las estimaciones de coste, calidad y
tiempo previstas
 Establecer sistemas nuevos o modificados de gestión de información y herramientas,

tecnología , arquitecturas, procesos, y los métodos de medición y métricas a fin de
cumplir con los requisitos establecidos en la fase del diseño del Servicio
 Garantizar que todas las partes adopten el marco de trabajo común de sistemas de
soporte y procesos reutilizables estándar para mejorar la eficacia y eficiencia de las
actividades de planificación y coordinación integradas.
 Proporcionar planes claros y exhaustivos que permitan al cliente y a los proyectos de

cambio del negocio alinear sus actividades con los planes de Transición del Servicio.
 Identificar, gestionar y controlar los riesgos de fallo e interrupción a través de las

actividades de transición.
 Monitorizar y mejorar el rendimiento de la transición del Servicio

6.7.3 ALCANCE
 Mantenimiento de las políticas, normas, modelos de las actividades y los procesos de

transición de servicio
 Guiar cada cambio importante o nuevo servicio a través de todos los procesos de
transición de servicio
 Coordinar los esfuerzos necesarios para permitir gestionar múltiples transiciones al

mismo tiempo
 Priorizar los recursos necesarios para realizar la transición del Servicio
 Planificación del presupuesto y los recursos necesarios para cumplir con las
necesidades futuras de la transición del servicio

Revisar y mejorar el rendimiento de la planificación de la transición y las actividades de
Soporte
 Asegurar que la transición del servicio se coordina con Gestión de proyectos y

Programas.

GESTIÓN DE CAMBIOS

GESTIÓN DE CAMBIOS
6.8 GESTIÓN DE CAMBIOS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 VALOR
 TIPOS DE CAMBIO
 MODELOS DE CAMBIOS
 PROPUESTAS DE CAMBIO
 PLANIFICACION DE CORRECCIONES
 ACTIVIDADES
 AUTORIZACIÓN DE UN CAMBIO
 COMITÉ DE CAMBIOS (CAB)
 CAMBIOS ESTÁNDAR
 CAMBIOS DE EMERGENCIA
 INTERFACES CON GESTIÓN DE LA CONFIGURACIÓN
6.8.1 INTRODUCCIÓN
El objetivo de esta unidad es entender los tipos de cambios que se realizan en una
organización y las actividades incluidas en este proceso.
Los cambios se gestionan para:
 Optimizar la exposición al riesgo (dando soporte al perfil de riesgo requerido por el

negocio)
 Minimizar la severidad de cualquier impacto e interrupción
 Tener éxito en el primer intento.
 Asegúrese de que todas las partes interesadas reciben una comunicación adecuada y
oportuna sobre el cambio.
Algunos cambios son proactivos, donde las organizaciones buscan beneficios como reducción
de costes, mejora de los servicios o mayor facilidad y eficacia de soporte. Otros cambios son
reactivos como medio de resolver errores y adaptarse a circunstancias cambiantes.
6.8.2 PROPÓSITO
El propósito del proceso de gestión del cambio es controlar el ciclo de vida de todos los
cambios, lo que nos permitirá realizar cambios con una interrupción mínima en los servicios de
TI.

GESTIÓN DE CAMBIOS
6.8.3 OBJETIVOS
Los objetivos de Gestión de Cambios son los siguientes:
 Responder a las diversas necesidades de negocio del cliente, al mismo tiempo que se
aumenta el valor y disminuyen los incidentes, interrupciones y revisiones.
 Responder a las Solicitudes de Cambio (RFC) del negocio y de TI que alinearan los
servicios con las necesidades del Negocio.
 Asegurarse de que las organizaciones registran, evalúan, priorizan, planifican, prueban,

implementan, documentan y los revisan los Cambios autorizados de una forma
organizada.
 Asegurarse de que las organizaciones registran todos los elementos de Configuración

del Cambio en el CMS.
 Optimizar el riesgo general del negocio, (En ocasiones es correcto aceptar un riesgo
asumiendo el valor potencial que ofrece).
6.8.4 ALCANCE
El ámbito de Gestión de Cambios debería incluir cambios en todas las arquitecturas, procesos,
herramientas, métricas y documentación, así como cambios en los servicios de TI y otros
elementos de configuración.
Gestión de cambios también abarca todos los cambios en cualquiera de los cinco aspectos del
diseño del servicio:
 Soluciones de servicio para servicios nuevos o modificados.
 Sistemas y herramientas de gestión de la información, particularmente el portfolio de

servicios.
 Arquitecturas de tecnología y de gestión.
 Procesos requeridos para el diseño, transición, operación y mejora de los servicios.
 Sistemas y métodos de medición y métricas.
La siguiente figura muestra el alcance típico de un proceso de gestión de Cambios para una
organización de TI y cómo interactúa con el negocio y proveedores a nivel Estratégico, Táctico
y Operacional. Contempla las interfaces con los proveedores de servicios internos y externos
en los que hay activos compartidos y elementos de configuración que necesitan estar bajo el
control de gestión de cambios.

GESTIÓN DE CAMBIOS
Gestión de Cambios debe interactuar con la gestión de Cambios en el negocio (a la izquierda

en la figura) y con la gestión del Cambio del proveedor (a la derecha en la figura).
Cada organización debe definir los cambios que se encuentran fuera del ámbito de su proceso
de Gestión de Cambios como por ejemplo los que tienen más impacto que un cambio del
Servicio. Pueden ser, Departamentales, de Políticas, Comerciales o de Estrategia de Negocio.

GESTIÓN DE CAMBIOS
6.8.5 VALOR
La fiabilidad y continuidad del negocio son esenciales para el éxito y supervivencia de cualquier
organización. Los cambios en el servicio y en la infraestructura pueden tener un impacto
negativo en el negocio por la interrupción del servicio y el retardo a la hora de identificar los
requisitos de negocio, aunque la Gestión de Cambios permite al proveedor de servicio añadir
valor al negocio:
 Protegiendo el negocio, y otros servicios, a la vez que ejecuta los cambios.
 Priorizando y respondiendo a las propuestas de cambio del negocio y del cliente
 Implementando cambios que cumplan los requisitos del servicio acordados del cliente
a la vez que se optimizan los costes
 Contribuir a cumplir los requisitos de gobierno, legales, contractuales y regúlatenos
 Reducir los cambios fallidos y por lo tanto la interrupción del servicio, los defectos y las
remodelaciones
 Entregar el cambio rápidamente para cumplir los plazos de tiempo del negocio
 Realizar el seguimiento de los cambios a través del ciclo de vida del servicio y hasta los
activos de sus clientes
 Contribuir a mejorar las estimaciones de la calidad, tiempo y coste del cambio
 Evaluar los riesgos asociados con la transición de los servicios (introducción o

eliminación)
 Ayudar a mejorar la productividad del personal minimizando las interrupciones

debidas a altos niveles de cambios de 'emergencia' o sin planificar y, por lo tanto,
maximizando la disponibilidad del servicio
 Reducir el Tiempo Medio de Restauración del Servicio (MTRS), a través de

implementaciones más rápidas y exitosas de cambios correctivos
 Actuar conjuntamente con el proceso de cambio del negocio para identificar

oportunidades de mejora del negocio.

GESTIÓN DE CAMBIOS
6.8.6 TIPOS DE CAMBIO
Una petición de cambio es una comunicación formal que busca una alteración en uno o más
elementos de configuración. Esto podría tener diferentes formas, por ejemplo, un documento
de 'Solicitud de Cambio', una llamada al centro de servicio al usuario, un documento de Inicio
de Proyecto. Diferentes tipos de cambio podrían requerir diferentes tipos de petición de
cambio. Es necesario que una organización garantice que los procedimientos y formularios
adecuados estén disponibles para recoger las peticiones anticipadas. Sería conveniente evitar
utilizar un método burocrático para documentar un cambio menor ya que eliminaría algunas
de las barreras culturales para adoptar el proceso de Gestión de Cambios.
Los cambios suelen clasificarse como importante, significativo o menor, dependiendo del nivel
de coste y riesgo, alcance y la relación con otros cambios. Esta categorización se puede utilizar
para identificar una autoridad apropiada para cada cambio.
Los tres tipos de Cambios que contempla ITIL® son:
Estándar • Cambio Pre autorizado de bajo riesgo, relativamente común y con un

procedimiento aceptado y establecido
Emergencia • Cambio que se debe implementar lo más rápido posible, por ejemplo un
parche de seguridad o la resolución de una incidencia
Normal • No es cambio ni estándar ni de emergencia.

GESTIÓN DE CAMBIOS
6.8.7 MODELOS DE CAMBIOS
Un modelo de proceso es una forma de predefinir los pasos que deben tomarse para manejar
un proceso (en este caso un proceso para abordar un tipo particular de cambio) de una forma
acordada.
 Los pasos que deben tomarse para gestionar el cambio incluyendo el

tratamiento de problemas y eventos inesperados
 El orden cronológico de estos pasos
 Responsabilidades
 Plazos de tiempo y umbrales para completar las acciones
 Procedimientos de escalado
Las organizaciones encontrarán útil predefinir modelos de proceso de cambio y aplicarlos a los
cambios apropiados cuando éstos se produzcan.
Los cambios que requieren un tratamiento especializado podrían tratarse de esta forma, como
por ejemplo cambios de emergencia que pueden tener una autorización diferente y que
pueden documentarse retrospectivamente.
6.8.8 PROPUESTAS DE CAMBIO
Los cambios mayores o importantes que impliquen costes, riesgos o impacto organizacional
significativos se inician mediante las propuestas de cambio.
Las propuestas de cambio son creadas por el proceso de gestión del portfolio de servicios y
autorizadas por Gestión de cambios.
 Una descripción de alto nivel del servicio o del cambio.

 Un caso de negocio.
 Un calendario previsto de implementación

GESTIÓN DE CAMBIOS
6.8.9 PLANIFICACION DE CORRECCIONES
Ningún cambio deberá aprobarse sin que se haya abordado explícitamente la pregunta de lo
que habría que hacer si no fuera satisfactorio.
Planificación de correcciones son las acciones que se realizan para recuperarnos después de
haber fallado con un cambio o el despliegue de una versión.
 Back-Out (Volver a una línea base de referencia)

 Ejecución de otro Cambio
 Un Plan de Contingencia

GESTIÓN DE CAMBIOS
6.8.10 ACTIVIDADES
Esta figura muestra las actividades que se realizaran en el proceso de Gestión de Cambios. A
continuación explicaremos más en profundidad cada una de ellas.
Crear y registrar Solicitudes de cambio
El cambio se propone mediante una petición por parte del iniciador (el grupo individual u
organizativo que requiere el cambio). Por ejemplo, podría ser una unidad de negocio que
requiere funcionalidades adicionales, o el personal de Gestión de Problemas que pide la
corrección de un error procedente de muchas otras fuentes.
En el caso de un cambio mayor, con implicaciones organizativas y/o financieras significativas,

podría requerirse una propuesta de cambio, que contendrá una descripción completa del

GESTIÓN DE CAMBIOS
cambio junto con una justificación de negocio y financiera para el cambio propuesto. La
propuesta de cambio incluirá la aprobación de los niveles apropiados de la dirección del
negocio.
Parte de la información se registra cuando el documento se inicia y cierta información podría

actualizarse cuando el documento de cambio evolucione a lo largo de su ciclo de vida. Parte de
la información se registra directamente en el formulario de Solicitud de Cambio, y los detalles
del cambio y de las acciones podrían registrarse en otros documentos a los que haría
referencia la RFC, por ejemplo, Caso de Negocio, ¡informe de evaluación del impacto.
El registro de cambio mantiene el histórico completo del cambio, incorporando información de

la RFC y registrando posteriormente parámetros acordados como la información de la
prioridad y autorización, implementación y revisión. Podrían utilizarse muchos tipos diferentes
de registros de cambio para registrar diferentes tipos de cambios. La documentación debe
definirse durante la etapa de planificación y diseño del proceso.
Cuando una RFC progresa a lo largo de su ciclo de vida, el documento del cambio, los registros
asociados (como por ejemplo órdenes de trabajo) y los elementos de configuración
relacionados se actualizan en el CMS, por lo que hay visibilidad de su estado. Las estimaciones
y los recursos, costes y salidas reales (exitosas o fallidas) se registran para permitir la
generación de informes de gestión.
Revisión de la Solicitud de Cambio
Los procedimientos deben estipular que, cuando se registren los cambios, Gestión de Cambios
debe considerar brevemente cada petición y filtrar cualquiera que fuera:
 Totalmente impracticable
 Una repetición de RFCs anteriores, aceptadas, rechazadas o todavía bajo consideración
 Presentación incompleta, es decir, con una descripción inadecuada sin la aprobación

presupuestaria necesaria.
Éstas deben devolverse al iniciador, junto con una breve descripción de los detalles de la razón
para el rechazo, y el registro debe registrar este hecho. Debe existir el derecho de recurso
contra el rechazo a través de los canales de gestión habituales, y debe incorporarse en los
procedimientos.
Análisis y evaluación del cambio
Será necesario considerar el posible impacto en los servicios de los cambios fallidos y su
impacto en los activos del servicio y en las configuraciones. Preguntas genéricas (por ejemplo,
las 'siete R') proporcionan un buen punto de inicio.
Debe responderse a las siguientes preguntas para todos los cambios. Sin esta información la
evaluación del impacto no podrá completarse, y no se entenderá el equilibrio entre riesgo y
beneficio para el servicio activo. Esto podría dar como resultado que el cambio no aporte

GESTIÓN DE CAMBIOS
todos los beneficios posibles o esperados para el negocio, o incluso que tuviera un efecto
perjudicial inesperado en el servicio activo.
 ¿Quién PRESENTA el cambio?
 ¿Cuál es la RAZON del cambio?
 ¿Cuál es el RETORNO requerido del cambio?
 ¿Cuáles son los RIESGOS que implica el cambio?
 ¿Qué RECURSOS se requieren para entregar el cambio?
 ¿Quién es RESPONSABLE de la construcción, prueba e implementación del cambio?
 ¿Cuál es la RELACIÓN entre este cambio y otros
Muchas organizaciones desarrollan cuestionarios específicos de evaluación del impacto para

capturar la información de los asesores del impacto sobre cuestiones específicas del cambio.
Esto puede ayudar con el proceso de aprendizaje, particularmente para nuevos servicios o al
implementar por primera vez una etapa formal de evaluación del impacto.
Debe definirse la responsabilidad para evaluar un cambio mayor. Esto no es un aspecto de

mejor práctica porque las organizaciones se diferencian tanto en tamaño, estructura y
complejidad que no hay una solución universal apropiada para todas las organizaciones. Sin
embargo, se recomienda que los cambios mayores se analicen desde el principio con todos los
interesados para llegar a límites sensatos de responsabilidad y mejorar la comunicación entre
todos los interesados.
Aunque Gestión de Cambios es responsable de garantizar que los cambios se evalúen y, si se

autorizan, desarrollen, prueben, implementen y revisen posteriormente, la responsabilidad
final del servicio de TI, incluyendo los cambios en el mismo, se encontrará en el gestor del
servicio y en el propietario del servicio. Ellos controlan la financiación disponible y se habrán
implicado en el proceso de cambio a través de su participación directa o delegada en el CAB.
Al realizar la avaluación del impacto y de los recursos para las RFC a las que se asocian, Gestión
de Cambios, CAB, ECAB y cualquier otro (nombrado por los miembros del CAB o por Gestión de
Cambios) que esté implicado en este proceso, deberá considerar aspectos relevantes tales
como:
 El impacto que tendrá el cambio en la operación del negocio del cliente
 El efecto en la infraestructura y en el servicio del cliente, como se define en la línea de

referencia de requisitos del servicio, en el modelo de servicio, SLA, y en la capacidad y
rendimiento, fiabilidad y capacidad de recuperación, planes de contingencia, y
seguridad el impacto en otros servicios que están activos en la misma infraestructura
(o en los proyectos) el impacto en infraestructuras que no son de TI dentro de la
organización, por ejemplo, seguridad, servicios de administración, transporte, centros
de atención al usuario

GESTIÓN DE CAMBIOS
 El efecto de no implementar el cambio los recursos de TI, del negocio y otros recursos
requeridos para implementar el cambio, incluyendo los posibles costes, el número y
disponibilidad de las personas requeridas, el tiempo transcurrido, y cualquier otro
nuevo elemento requerido de la infraestructura
 La planificación de cambios actual (CS) y la parada de servicio planificada (PSO)
 Recursos adicionales que se requerirán continuamente si se implementa el cambio
 Impacto en el plan de continuidad, plan de capacidad, plan de seguridad, datos y

scripts de pruebas de regresión y entorno de prueba, actividades de las operaciones
del servicio.
Autorización del cambio
La autorización formal se obtiene para cada cambio de una autoridad del cambio que podría
ser un rol, persona o un grupo de personas. Los niveles de autorización para un tipo particular
de cambio deben juzgarse por el tipo, tamaño o riesgo del cambio, por ejemplo, los cambios
en una gran empresa que afectan a varios emplazamientos distribuidos podrían necesitar la
autorización de una autoridad del cambio de mayor nivel, como por ejemplo un CAB global o el
Consejo de Administración.
La cultura de la organización dicta, hasta el máximo posible, la secuencia y procedimiento

mediante los que se autorizan los cambios. Las estructuras jerárquicas pueden llevar a
establecer muchos niveles sucesivos de aprobación del cambio, mientras que estructuras más
planas permiten un proceso de aprobación mucho más directo.
Podría existir un grado de autoridad delegada dentro de un nivel de autorización, por ejemplo,
delegar la autoridad a un gestor de cambios de acuerdo con parámetros preestablecidos
asociados con:
 Riesgo anticipado para el negocio
 Implicaciones financieras
 Ámbito del cambio (por ejemplo, sólo efectos internos, dentro del servicio financiero,
servicios específicos externalizados).
Coordinación de la implementación del cambio
Las RFC autorizadas deben enviarse a los grupos técnicos pertinentes para la construcción de
los cambios. Será una mejor práctica hacer esto formalmente para que se pueda realizar el
seguimiento, por ejemplo, utilizando órdenes de trabajo.
Gestión de Cambios tiene la responsabilidad de garantizar que los cambios se implementen

como se programó. Esto representa ampliamente un rol de coordinación ya que otros serán
responsables de la implementación real (por ejemplo, especialistas técnicos de hardware
implementarán los cambios de hardware).

GESTIÓN DE CAMBIOS
Los procedimientos de corrección deben prepararse y documentarse con anticipación para

cada cambio autorizado, de tal forma que, si se produjeran errores durante o después de la
implementación, estos procedimientos puedan activarse rápidamente con el mínimo impacto
en la calidad del servicio. La autoridad y responsabilidad para solicitar la corrección están
mencionadas específicamente en la documentación del cambio.
Gestión de Cambios tiene un rol de supervisión para garantizar que todos los cambios se
prueben con detenimiento. En todos los casos en los que los cambios implicados todavía no se
hubieran probado completamente, será necesario tomar precauciones especiales durante la
implementación.
Revisar y cerrar un registro de cambio
A la finalización del cambio, se deberá informar de los resultados a los responsables de la

gestión de cambios para que realicen una evaluación, y a continuación deberá presentarse
como un cambio completado para que lo acuerden los interesados (incluyendo el cierre de
incidencias, problemas o errores conocidos asociados). Es obvio que en el caso de los cambios
mayores existirán más entradas del cliente y de los interesados a lo largo de todo el proceso.
Una revisión también debe incluir cualquier incidencia que surja como resultado del cambio (si
fueran conocidas en esta etapa). Si el cambio formara parte de un servicio gestionado por un
proveedor externo, se requerirán los detalles de cualquier objetivo contractual del servicio
(por ejemplo, incidencias que no tienen prioridad 1 durante la primera semana después de la
implementación).
Debe realizarse una revisión del cambio (por ejemplo, revisión post-implementación, PIR) para
confirmar que el cambio ha cumplido sus objetivos, que el iniciador y los interesados están
satisfechos con los resultados; y que no se han producido efectos colaterales inesperados. Las
lecciones aprendidas deben servir como retroalimentación para futuros cambios. Las
organizaciones pequeñas podrían optar por utilizar la comprobación rápida de los cambios en
lugar de PIR de gran escala; en organizaciones mayores, el muestreo tendrá un valor cuando
tengan lugar muchos cambios similares.

GESTIÓN DE CAMBIOS
6.8.11 AUTORIZACIÓN DE UN CAMBIO
La autorización formal se obtiene para cada cambio de una autoridad del cambio que podría
ser un rol, persona o un grupo de personas. Los niveles de autorización para un tipo particular
de cambio deben juzgarse por el tipo, tamaño o riesgo del cambio, por ejemplo, los cambios
en una gran empresa que afectan a varios emplazamientos distribuidos podrían necesitar la
autorización de una autoridad del cambio de mayor nivel, como por ejemplo un CAB global o el
Consejo de Administración.
La siguiente figura muestra un ejemplo de niveles de Autoridades para el Cambio.

GESTIÓN DE CAMBIOS
6.8.12 COMITÉ DE CAMBIOS (CAB)
 El Comité de Cambios (CAB) es un organismo que existe para dar soporte a la

autorización de los cambios y para ayudar a Gestión de Cambios en la evaluación y
priorización de los cambio.
 Los miembros que se elijan deben ser capaces de asegurar que todos los cambios
dentro del ámbito del CAB sean evaluados adecuadamente desde el punto de vista
técnico y del negocio.
 es necesario que el CAB incluya a personas con un claro entendimiento de todo el

rango de las necesidades de los interesados.
 El gestor de cambios normalmente presidirá el CAB.
Los posibles miembros podrían ser los siguientes:
 Clientes
 Administradores de usuarios
 Representantes del grupo de usuarios
 Mantenedores y desabolladores de aplicaciones
 Consultores técnicos/especialistas
 Personal de servicios y operaciones, por ejemplo, centro de servicio al usuario, gestión

de pruebas, ITSCM, seguridad, capacidad
 Personal de servicios de oficina/instalaciones (donde los cambios pueden afectar a

desplazamientos/ acomodación y viceversa)
 Representantes de contratistas y de terceros, por ejemplo, en situaciones de

externalización
 Otras partes como sea aplicable a las circunstancias específicas (por ejemplo, policía si
fueran posibles interrupciones del tráfico, marketing si se vieran afectados productos
públicos)
Es importante resaltar que el CAB:
 Se compondrá de acuerdo con los cambios que se están considerando
 Podría variar considerablemente incluso en todo el rango de una única reunión
 Debe implicar suministradores en caso de ser útil
 Debe reflejar los puntos de vista de usuarios y clientes

GESTIÓN DE CAMBIOS
 Es probable que incluya al gestor de problemas, al gestor de nivel de servicio y al

personal de relaciones con el cliente durante al menos parte del tiempo.
6.8.13 CAMBIOS ESTÁNDAR
Un cambio estándar es un cambio en un servicio o infraestructura para el que Gestión de

Cambios ha autorizado previamente un método específico de tratamiento.
 Exista un disparador definido para iniciar la RFC
 Las tareas sean conocidas y estén documentadas y verificadas
 La autoridad se dé por anticipado
 La aprobación presupuestaria normalmente estará predeterminada o dentro del

control del solicitante del cambio
 El riesgo es normalmente bajo, y siempre se entenderá perfectamente.
Algunos Cambios estándar se pueden tramitar a través del proceso de peticiones de Servicio
Los ejemplos podrían incluir la actualización de un PC para utilizar software estándar específico
o presupuestado previamente, nuevos empleados dentro de una organización, o un cambio de
ordenador para un único usuario. Otros ejemplos incluyen el cambio en aplicaciones rutinarias
o de bajo impacto para abordar la variación estacional.
La aprobación de cada ocurrencia de un cambio estándar estará concedida por la autoridad

delegada para ese cambio estándar.

GESTIÓN DE CAMBIOS
6.8.14 CAMBIOS DE EMERGENCIA
 Un cambio de Emergencia está destinado a reparar un error que está causando un

impacto negativo de alto grado en el Negocio.
 El número de cambios de emergencia propuestos debe mantenerse absolutamente al

mínimo.
 Abordarlos rápidamente, sin sacrificar los controles normales de gestión.
 Impactan negativamente en el negocio hasta un grado importante
 En caso de que no haya tiempo para reunir un CAB (Comité de cambios) completo, se
recurrirá a un ECAB (Comité de cambios de emergencia)
 No todos los cambios de emergencia requerirán la implicación del ECAB.
Algunas veces se requieren cambios de emergencia que deben diseñarse detenidamente y

probarse antes de su uso, o en caso contrario el impacto del cambio de emergencia podría ser
mayor que la incidencia original. Los cambios de emergencia podrían documentar algunos
detalles retrospectivamente.
6.8.15 INTERFACES CON GESTIÓN DE LA CONFIGURACIÓN
El sistema de Gestión de la Configuración proporciona un acceso fiable, rápido y fácil a

información de la configuración precisa para permitir a los interesados y al personal evaluar el
impacto de los cambios propuestos y hacer el seguimiento del flujo de trabajo de los mismos.
Esta información permite entregar las versiones de componentes del servicio y los activos
correctos a la parte adecuada o al entorno correcto. Cuando se implementan los cambios,
también se actualiza la información de Gestión de la Configuración.

GESTIÓN DE CAMBIOS
En la siguiente figura vemos las relaciones de Gestión de Cambios con Gestión de la

Configuración.

GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS DEL SERVICIO

6.9 GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS DEL SERVICIO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 MODELO DE CONFIGURACIÓN
 SISTEMA DE GESTIÓN DE LA CONFIGURACIÓN (CMS)
 BIBLIOTECA DEFINITIVA DE MEDIOS (DML)
 ACTIVIDADES
6.9.1 INTRODUCCIÓN
 Ninguna organización puede ser completamente eficiente y eficaz a menos que

gestione adecuadamente sus activos, particularmente aquellos que sean vitales para el
funcionamiento del negocio del cliente o de la organización.
 Este proceso gestiona los activos del servicio para dar soporte a los demás procesos de
Gestión del Servicio.
 En este proceso entenderemos la importancia de términos como CMDB (Base de datos

de Gestión de la Configuración y CMS (Sistema de Gestión de la Configuración).
 En un proceso que gestiona los Elemento de Configuración (CI´s), activos, sus

relaciones, atributos, etc...
6.9.2 PROPÓSITO
El propósito del proceso de SACM es:
 Asegurar que los activos necesarios para prestar los servicios se controlan
adecuadamente
 Que la información sobre esos activos precisa y fiable.
 Que la información está disponible cuando y donde sea necesario.
 Esta información incluye detalles de cómo se han configurado los activos y las
relaciones entre ellos.

6.9.3 OBJETIVOS
Los objetivos de Gestión de la Configuración son los siguientes:
 Asegurar que los activos bajo el control de la organización de TI son identificados,

controlados y cuidados a lo largo de su ciclo de vida.
 Identificar, controlar, registrar, auditar y verificar servicios y otros elementos de

configuración (CIs), incluyendo versiones, líneas base, componentes, sus atributos y
relaciones.
 Asegurar que solamente se utilizan los componentes autorizados y que solamente se

realizan los cambios autorizados.
 Asegurar la integridad de los CIs y las configuraciones necesarias para controlar los
servicios mediante el establecimiento y mantenimiento de un sistema de gestión de la
configuración preciso y completo (CMS).
 Mantener información de configuración precisa del estado histórico, planificado y

actual de los servicios y otros CIs.
 Dar soporte a los procesos de gestión del servicio proporcionando información precisa
de la configuración, la cual permita a las personas tomar decisiones en el momento
oportuno
6.9.4 ALCANCE
Los activos del servicio que se deban gestionar con el fin de entregar servicios se conocen
como elementos de la configuración (CIs). Gestión de la Configuración garantiza que se
identifiquen los componentes de un servicio, sistema o producto completo (la configuración),
se les proporcione y mantenga una línea de referencia y que se controlen los cambios
realizados en ellos.
Este proceso proporciona un modelo de configuración de los servicios y activos del servicio
mediante el registro de las relaciones entre los elementos de configuración.
 . Todos los CI´s son Activos del Servicio, pero no todos los activos son CI´s

6.9.5 MODELO DE CONFIGURACIÓN
Gestión de la Configuración proporciona un modelo de los servicios, activos e infraestructura

registrando las relaciones entre los elementos de la configuración, tal y como se muestra en la
Figura siguiente. Es un ejemplo de un modelo de Configuración para un servicio de Banca.
Un Modelo de configuración nos permite:
 Evaluar el impacto y causas de incidencias y problemas
 Evaluar el impacto de cambios propuestos
 Planificar y diseñar servicios nuevos o modificados
 Planificar actualizaciones de tecnología y de software
 Planificar paquetes de la entrega y del despliegue y migrar activos del servicio a

diferentes ubicaciones y centros de servicio
 Optimizar la utilización y costes de los activos, es decir, consolidar centros.

6.9.6 SISTEMA DE GESTIÓN DE LA CONFIGURACIÓN (CMS)
El CMS dispone de toda la información de los Cls incluidos dentro del ámbito asignado.
Algunos de estos elementos tendrán especificaciones asociadas o archivos que contienen los
contenidos del elemento, por ejemplo, software, documento o fotografía. Por ejemplo, un Cl
del Servicio incluirá detalles, como por ejemplo, suministrador, coste, fecha de compra y fecha
de renovación de licencias y de contratos de mantenimiento; y la documentación asociada,
como por ejemplo SLAs y contratos de soporte.
El CMS:
 Forma parte del Sistema de Gestión del Conocimiento del Servicio (SKMS)
 Se utiliza para gestionar infraestructuras y servicios de TI grandes y complejos.
 Mantiene las relaciones entre todos los componentes del servicio y cualquier
incidencia, problema, error conocido, cambio y documentación de la entrega
asociados, y también podría contener datos corporativos sobre empleados,
suministradores, ubicaciones y unidades de negocio, clientes y usuarios.

6.9.7 BIBLIOTECA DEFINITIVA DE MEDIOS (DML)
 La Biblioteca Definitiva de Medios (DML) es la biblioteca segura en la que se

almacenan y protegen las versiones autorizadas y definitivas de los Cl de todos los
medios.
 Contiene las copias maestras de todo el software controlado en una organización y de

incluir las copias definitivas de software adquirido (junto con los documentos o
información de las licencias), además del software desarrollado in situ.
 Incluirá un almacén físico para mantener copias maestras, por ejemplo, una caja fuerte
a prueba de incendios.
 Sólo se aceptarán medios autorizados en el DML, controlados estrictamente por

SACM.
 Deberá establecerse un área independiente para el almacenamiento seguro de

repuestos de hardware definitivos.
 No se almacenarán las copias de seguridad, esto es competencia de Gestión de

Operaciones TI

6.9.8 ACTIVIDADES
En la siguiente figura se muestran las actividades de alto nivel para Gestión de la Configuración
y de los Activos en un ejemplo de modelo de actividad.
El modelo de actividad que se ilustra se utiliza habitualmente si existen muchas partes o

suministradores y es necesario establecer actividades para obtener la información y datos de
la configuración de terceros.
Gestión y planificación
No hay ninguna plantilla estándar para determinar el método óptimo de implantación y

ejecución de para SACM. El equipo de directivo y el de Gestión de la Configuración deberán
decidir el qué nivel de Gestión de la Configuración que se requiere para el servicio o proyecto
seleccionado que está entregando cambios, y cómo se alcanzará este nivel. Esto se documenta
en un Plan de Gestión de la Configuración. En muchas ocasiones habrá un Plan de Gestión de
la Configuración para un proyecto, servicio o grupos de servicios, por ejemplo, servicios de red.
Estos planes definen las actividades específicas de Gestión de la Configuración dentro del
contexto de la estrategia de Gestión de la Configuración y de los Activos.

Identificación de configuración
Al planificar la identificación de configuración es importante:
 Definir cómo se seleccionarán, agruparán, clasificarán y definirán las clases y tipos de

activos y elementos de configuración con las características apropiadas, por ejemplo,
garantías para un servicio, para asegurar que se puedan gestionar y trazar a través de
su ciclo de vida
 Definir el método de identificación, nombrando y etiquetando de forma única todos

los activos o componentes de interés del servicio a lo largo del ciclo de vida del servicio
y las relaciones entre ellos
 Definir los roles y responsabilidades del propietario o custodio del tipo de elemento de
configuración en cada etapa de su ciclo de vida, por ejemplo, el propietario del servicio
para una documentación del servicio o entrega en cada etapa del ciclo de vida del
servicio.
Control de configuración
El Control de configuración garantiza que existan los mecanismos de control adecuados sobre
los Cls a la vez que se mantiene un registro de cambios en Cls, versiones, ubicación y
custodia/propiedad. Sin el control de activos y componentes físicos o electrónicos, los datos y
la información de configuración no se corresponderán con el mundo físico. Ningún Cl deberá
añadirse, modificarse, sustituirse o retirarse sin una documentación de control apropiado o sin
seguir un procedimiento.
Seguimiento e información del estado
Cada activo o Cl tendrá uno o más estados discretos a través de los cuales podrá progresar. La
importancia de cada estado debe definirse en términos del uso que se puede hacer del activo
o Cl en ese estado. Normalmente habrá un rango de estados relevantes para el activo o Cls
individuales. Deberá definirse la forma en la que los Cl pasan de un estado a otro, por ejemplo,
la entrega de una aplicación podría registrarse, aceptarse, instalarse o retirarse.
Auditoría y verificación
Las actividades incluyen una serie de revisiones o auditorías para:
 Asegurar que haya conformidad entre las líneas de referencia documentadas (por
ejemplo, acuerdos, documentos de control de la interfaz) y el entorno de negocio real
al que hacen referencia
 Verificar la existencia física de Cls en la organización o en la DML y en los almacenes de

repuestos, las características funcionales y operativas de Cls y comprobar que los
registros en el CMS se corresponden con la infraestructura física
 Comprobar que se dispone de la documentación de la entrega y de la configuración

antes de llevar a cabo una entrega.

GESTIÓN DE VERSIONES Y DESPLIEGUES

6.10 GESTIÓN DE VERSIONES Y DESPLIEGUES
 INTRODUCCIÓN
 PROPÓSITO
 DEFINICIONES
 OBJETIVOS
 ALCANCE
 POLÍTICAS DE VERSIONES
 OPCIONES Y MÉTODOS DE DESPLIEGUES
 ACTIVIDADES
El objetivo de esta unidad es entender el papel del proceso de Versiones y Despliegues y las
diferentes actividades y conceptos incluidos en el, los cuales son necesarios para realizar la
entrega de componentes y servicios.
6.10.2 PROPÓSITO
El propósito del proceso de Gestión de Versiones y despliegues es planificar, programar y

controlar la construcción, prueba y despliegue de las entregas, a fin de ofrecer una nueva
funcionalidad que requiera el negocio, protegiendo la integridad de los servicios existentes.
6.10.3 DEFINICIONES
Versión • Uno o más cambios en un servicio de TI que se construyen, prueban y despliegan de

manera conjunta. Una única entrega puede incluir cambios en el hardware,
software, documentación, procesos y otros componentes.
Paquetes • Un conjunto de elementos de configuración que se construirán, probaran y

desplegaran en conjunto como una única. Cada paquete de la versión suele incluir
una o más unidades de la versión
Unidades • Componentes de un Servicio de Ti que normalmente se Entregan juntos. Una

Unidad de Versiones normalmente incluye componentes suficientes para realizar
una Función útil. Por ejemplo, una Unidad podría ser un PC de sobremesa,
incluyendo Hardware, Software, Licencias, Documentación, etc. Una Unidad
diferente puede ser la Aplicación de Nóminas completa, Incluyendo los
Procedimientos de Operaciones de TI y la formación del usuario.

6.10.4 OBJETIVOS
Los objetivos de Versiones y despliegues son los siguientes:
 Definir y acordar los planes de gestión de Versiones y despliegues con los clientes y
partes interesadas.
 Producir y probar los paquetes de versiones
 Asegurar que los servicios nuevos o modificados son capaces de entregar la utilidad y
garantía acordadas.
 Asegurar que todos los paquetes de Versiones se almacenan en una DML y se registran
con precisión en el CMS.
 Implementar los paquetes de Versiones desde la DML hacia el entorno operativo.
 Asegurar que a todos los paquetes de Versiones se les puede hacer seguimiento y que
pueden ser instalados, probados, verificados o desinstalados o retirados de ser
necesario.
 Registrar y gestionar las desviaciones, los riesgos y contingencias relacionadas con el

servicio nuevo o modificado, y adoptar medidas correctoras necesarias.
 Asegurar una transferencia del conocimiento que permita a clientes y usuarios utilizar
el servicio para dar soporte a sus actividades de negocio.
 Asegurar que se transfieren a operación de servicio las habilidades y conocimientos

requeridos para la entrega, soporte y mantenimiento del servicio
6.10.5 ALCANCE
El alcance de la gestión de entregas y despliegues incluye los procesos, sistemas y funciones

para Empaquetar, construir, probar y desplegar una versión especificado en el paquete de
diseño del servicio y entregarlo formalmente a las funciones de operación del servicio.
 Activos físicos (un servidor o una red).
 Activos virtuales (un servidor virtual o memoria virtual).
 Aplicaciones y software.
 Formación para usuarios y personal de TI.
 Servicios, todos relacionados con contratos y acuerdos

Versiones y Despliegues es el proceso responsable de que se realicen las pruebas de servicio,

pero no se encarga de hacerla, ello corresponde al proceso de Validación y Pruebas del
Servicio.
6.10.6 POLÍTICAS DE VERSIONES
A continuación describiremos las políticas aplicadas a este proceso.
 La identificación, numeración, convención sobre nomenclatura y descripción de los

diferentes tipos de entregas.
 Los roles y responsabilidades para cada fase del proceso.
 El requerimiento de utilizar sólo los activos de software contenidos en la biblioteca de

medios definitivos.
 La frecuencia esperada para cada tipo de entrega.
 Los criterios para aceptar, agrupar y priorizar los cambios en una entrega.
 El mecanismo para automatizar los procesos de distribución de estructuras físicas,

instalaciones y entregas.
 El mecanismo para capturar y verificar la línea base de la configuración de la entrega.
 Los criterios de salida, entrada y aceptación para cada etapa de la transición del
servicio.
 Criterios y autorización para el traspaso o cesión a la operación del servicio
Dentro de las Políticas es importante definir la clasificación de los despliegues.
Clasificación de Versiones
Principales • Normalmente contienen un gran número de nuevas funcionalidades, algunas de

las cuales podrían eliminar soluciones provisionales para problemas. Una
actualización o Versión principal normalmente sustituye a todas las
actualizaciones, Versiones y soluciones de emergencia menores anteriores.
Menores • Normalmente contienen pequeñas soluciones y mejoras, algunas de los cuales ya

se han utilizado como soluciones de emergencia. Una actualización o versión
menor normalmente sustituye a todas las soluciones de emergencia precedentes.
Emergencia • Normalmente contiene las correcciones a un pequeño número de errores

conocidos o algunas veces una mejora para cumplir un requisito de negocio de
alta prioridad.

6.10.7 OPCIONES Y MÉTODOS DE DESPLIEGUES
En este punto definimos las opciones que tenemos para realizar un despliegue y el método
Opciones
Big Bang • El servicio nuevo o modificado se despliega en todas las áreas de usuario en una
operación.
Por fases • El servicio se despliega inicialmente en una parte de la base de usuarios, y a

continuación se repite esta operación para las siguientes partes de la base de
usuarios a través de un plan de despliegue planificado.
Métodos
Push • El componente se despliega sin decisión del usuario.
Pull • El componente de despliega cuando lo decide el usuario.

6.10.8 ACTIVIDADES
La siguiente figura muestra las actividades del Proceso de Versiones y Despliegues. A

continuación detallaremos cada una de ellas.
Planificación • Se desarrollan planes para crear y desplegar la versión. Esta fase

comienza con la autorización de gestión de cambios en la planificación y
finaliza con la autorización de gestión de cambios para crear la Versión.
Construcción • El paquete de versiones está ya construido, probado y verificado en la
y DML. Esta fase comienza con la autorización de gestión de cambios para
pruebas construir la entrega y finaliza con la autorización de gestión de cambios
para establecer la línea base de la versión en la DML por parte de gestión
de la configuración y activos del servicio.
Despliegue • El paquete de versiones que se encuentra en la DML se despliega en el
entorno de explotación. Esta fase comienza con la autorización de gestión
de cambios para desplegar el paquete a uno o más entornos, y finaliza
con la entrega a las funciones de operación del servicio y soporte post-
implantación. Puede haber muchas fases de despliegue separadas para
cada entrega, dependiendo de las opciones de despliegue planificadas.
Revisión • Se captura la experiencia adquirida y la retroalimentación, se revisan los
y objetivos de rendimiento frente a los logros, y se registran las lecciones
cierre aprendidas.

GESTIÓN DE VALIDACIÓN Y PRUEBAS

6.11 GESTIÓN DE VALIDACIÓN Y PRUEBAS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
El concepto fundamental al que contribuye Validación y Pruebas del Servicio es asegurar la

calidad, estableciendo que el Diseño del Servicio y la Entrega proporcionarán un servicio nuevo
o modificado, u oferta de servicio que se ajuste al propósito y al uso (Utilidad y Garantía)
Si los servicios no se probaran suficientemente, entonces su introducción en el entorno

operativo implicará un incremento de:
 Incidencias
 Llamadas al CSU
 Problemas
 Incremento de Costes
 Servicios que no proporcionan el valor deseado
6.11.2 PROPÓSITO
El propósito del proceso de validación y pruebas del servicio es asegurar que un servicio nuevo
o modificado coincide con su especificación de diseño y que además cumple con los
requerimientos del negocio.

6.11.3 OBJETIVOS
Los objetivos del Proceso Validación y Pruebas del Servicio son los siguientes:
 Proporcionar confianza de que las versiones han de entregar los resultados esperados
dentro de los costes, capacidad y limitaciones establecidos.
 Asegurar la calidad para una entrega, así como para el servicio, sus componentes y su
capacidad.
 Validar que un servicio ha de ofrecer la utilidad requerida (adecuado al propósito).
 Asegurar que un servicio entrega la garantía acordada (adecuado para su uso).
 Confirmar que los requerimientos de servicio de las partes interesadas se definen

adecuadamente.
 Remediar los errores o las variaciones en los requerimientos del servicio en las fases
tempranas del ciclo de vida del servicio.
 Planificar e implementar un proceso de validación y pruebas.
 Identificar, evaluar y abordar todos los asuntos relacionados con errores y riesgos a lo
largo de la transición del servicio
6.11.4 ALCANCE
La realización de pruebas es aplicable para:
 Servicios, hardware, software o servicios basados en el conocimiento desarrollados

internamente o externamente
 Servicios o componentes nuevos o modificados.
 Modelos de servicio para asegurar que éstos se adecúan al propósito y uso.
Cuando se realiza la validación y pruebas de un servicio de extremo a extremo, las interfaces

con suministradores, clientes y asociados son fundamentales.

GESTIÓN DE EVALUACIÓN DEL CAMBIO

6.12 GESTIÓN DE EVALUACIÓN DEL CAMBIO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
Evaluación del cambio genera una gran cantidad de información para el proceso del cambio y
para las predicciones y mediciones del rendimiento del cambio del servicio.
Ayudará al proceso de Gestión de Cambios en la evaluación de los mismos y en la comparación

del rendimiento real con el que se tenía previsto
6.12.2 PROPÓSITO
El propósito del proceso de evaluación del cambio es proporcionar un medio consistente y

estandarizado para determinar el rendimiento de un cambio del servicio.
6.12.3 OBJETIVOS
Los objetivos de Evaluación del Cambio son los siguientes:
 Establecer correctamente las expectativas de las partes interesadas y Proporcionar

información a gestión de cambios para evitar la transición de aquellos cambios que
afecten negativamente la capacidad del servicio o que introduzcan riesgos.
 Evaluar los efectos de un cambio del servicio, tanto previstos como no.
 Proporcionar salidas de calidad para que gestión de cambios pueda decidir si autoriza
o no los cambios del servicio.

6.12.4 ALCANCE
Se requiere de una evaluación en muchos puntos a lo largo ciclo de vida del cambio, por
ejemplo:
 Antes de construir y probar.
 Antes de incorporar a la DML.
 Antes del despliegue en el entorno operativo
Evaluación del cambio es un proceso de evaluación formal y adecuado en la evaluación de

cambios importantes.
Cada organización debe decidir cuáles cambios pasan por el proceso de evaluación del cambio
y cuáles por el proceso de gestión de cambios.
Esto se deberá documentar en los modelos de cambios utilizados para cada tipo de cambio.

GESTIÓN DEL CONOCIMIENTO

6.13 GESTIÓN DEL CONOCIMIENTO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 SISTEMA DE GESTIÓN DEL CONOCIMIENTO (SKMS)
 MODELO DIKW
La capacidad para entregar un servicio o proceso de calidad radica en una ampliación

significativa de la capacidad de aquellos Implicados a la hora de responder a las circunstancias
(eso a su vez se apoya fuertemente en su entendimiento de la situación, opciones,
consecuencias y beneficios, como por ejemplo, su conocimiento de la situación en la que
están, o en la que podrían encontrase). Ese conocimiento dentro del dominio de Transición del
Servicio podría incluir:
 Identidad de los interesados.
 Niveles aceptables de riesgo y expectativas de rendimiento.
 Escalas de tiempo y recursos disponibles.
La calidad y relevancia del conocimiento radica a su vez en la accesibilidad, calidad y relevancia

continua de los datos de apoyo y de la Información disponible para el personal del servicio.
6.13.2 PROPÓSITO
El Propósito de gestión del conocimiento es compartir perspectivas, ideas, experiencias e

información y que estén disponibles en el lugar correcto y en el momento correcto a fin de
habilitar la toma de decisiones.

6.13.3 OBJETIVOS
El objetivo de Gestión del Conocimiento es permitir a las organizaciones mejorar la calidad de

la toma de decisiones de la dirección garantizando que estén disponibles datos e información
seguros y fiables a través del ciclo de vida del servicio.
Los objetivos de Gestión de Conocimiento incluyen:
 Permitir al proveedor de servicios ser más eficiente y mejorar la calidad del servicio al
reducir la necesidad de redescubrir el conocimiento.
 Asegurar que el personal tiene una comprensión clara y compartida del valor y
beneficios, que ofrecen sus servicios a los clientes.
 Reunir, analizar, almacenar, compartir, utilizar y mantener el conocimiento,

información y datos en toda la organización.
 Mantener un Sistema de Gestión del Conocimiento del Servicio (SKMS) que

proporcione acceso controlado a conocimiento, información y datos

6.13.4 ALCANCE
El Ámbito de Gestión del conocimiento es todo el ciclo de Vida del Servicio. Se trata
constantemente y es fundamental para entender todos los aspectos a cualquier nivel de una
Organización. La siguiente figura refleja el alcance de Gestión del Conocimiento.

6.13.5 SISTEMA DE GESTIÓN DEL CONOCIMIENTO (SKMS)
SKMS es el concepto más amplio en cuanto a la custodia de los datos, la información y el

conocimiento de TI. Engloba el CMS, DML, CMDB y muchas otras bases de datos y recursos
utilizados por el proveedor, como por ejemplo:
 La cartera de servicios
 Acuerdos de nivel de servicio (SLA), contratos de Soporte (UC) y acuerdos de nivel

Operacional(OLA)
 Las política de seguridad de la información
 El sistema de información de proveedores y gestión de contratos (SCMIS).
 Presupuestos y Modelos de costes
 Los planes de negocios
 Registro de CSI y Planes de mejora de servicio

6.13.6 MODELO DIKW
Gestión del Conocimiento normalmente se visualiza dentro de la estructura Datos para la

Información, Conocimiento y Saber (DIKW). El uso de estos términos se establece a
continuación de la figura que muestra el modelo.
Datos • Los Datos son un conjunto de hechos discretos sobre eventos. La mayoría de las
organizaciones capturan cantidades significativas de datos en bases de datos
muy estructuradas, como por ejemplo herramientas/sistemas y bases de datos
de Gestión del Servicio y de Gestión de la Configuración.
Información • La Información proviene al proporcionar contexto a los datos. La información
normalmente se almacena en lugares semiestructurados como por ejemplo
documentos, correos electrónicos y recipientes multimedia.
Conocimiento • El Conocimiento está compuesto por las experiencias, ideas, entendimientos,
valores y juicios de los individuos. Las personas obtienen conocimiento de su
propia experiencia y de la experiencia de sus colegas, además del análisis de la
información
Sabiduría • La Sabiduría ofrece el último criterio del material y dispone de la concienciación
de la aplicación y del contexto para proporcionar sentido común. Es lo único
que no puede ser gestionado por una herramienta

UNIDAD 7 – OPERACIÓN DEL SERVICIO
Fundamentos
7 – OPERACIÓN DEL SERVICIO

7 OPERACIÓN DEL SERVICIO
 INTRODUCCIÓN
 PROPÓSITO DE OPERACIÓN
 OBJETIVOS DE OPERACIÓN
 ALCANCE DE OPERACIÓN
 COMUNICACIÓN
 IMPLICACIÓN DE OPERACIONES EN EL CICLO DE VIDA
 GESTIÓN DE EVENTOS
 GESTIÓN DE INCIDENCIAS
 PETICIONES DE SERVICIO
 GESTIÓN DE PROBLEMAS
 GESTIÓN DE ACCESOS
 CENTRO DE SERVICIO AL USUARIO (CSU)
 GESTIÓN TÉCNICA
 GESTIÓN DE OPERACIONES TI
 GESTIÓN DE APLICACIONES

7.1 INTRODUCCIÓN
 Operación del Servicio es la Fase del Ciclo de Vida de ITSM que es responsable de las
actividades habituales del Negocio.
 Operación del Servicio es considerada como la “fábrica” de TI. Esto implica un enfoque
más cercano respecto a las actividades diarias y a la infraestructura que se utilizan
para entregar servicios.
 Los procesos bien implementados y planificados no serán útiles si la operación diaria

de esos procesos no se dirige, controla y gestiona adecuadamente.
7.2 PROPÓSITO DE OPERACIÓN
Los procesos bien implementados y diseñados serán de poco valor si la operación diaria de
esos procesos no se dirige, controla y gestiona adecuadamente. Tampoco será posible realizar
mejoras del servicio si no se realizan sistemáticamente las actividades diarias de
monitorización del rendimiento, las métricas de evaluación y la recopilación de datos durante
la Operación del Servicio.
 El propósito de la Operación del Servicio es coordinar y realizar las actividades y

procesos requeridos para entregar y gestionar servicios con los niveles acordados para
los usuarios y clientes del negocio.
 Operación del Servicio también es responsable de la gestión continua de la tecnología

que se utiliza para entregar y apoyar los servicios.
7.3 OBJETIVOS DE OPERACIÓN
 Mantener la satisfacción del negocio y la confianza en él mediante la entrega y el

apoyo a los servicios con eficacia y eficiencia.
 Minimizar el impacto de las interrupciones del servicio en las actividades comerciales.
 Asegurarse de que el acceso a los servicios de TI se concederá sólo a las personas

autorizadas para recibir esos servicios.

7.4 ALCANCE DE OPERACIÓN
El alcance de Operación del Servicio incluye:
 Los propios servicios. Cualquier actividad que forme parte de un servicio estará
incluida en la Operación del Servicio, independientemente de que la realice un
Proveedor de Servicios, un suministrador externo o el usuario o cliente de ese servicio.
 Procesos de Gestión del Servicio. La gestión y ejecución continua de muchos procesos

de la Gestión del Servicio se realiza en la Operación del Servicio, incluso cuando varios
procesos de ITIL (como por ejemplo Gestión de Capacidad y de Cambios) se originen
en las etapas de Diseño del Servicio o Transición del Servicio del Ciclo de Vida del
Servicio, éstos serán utilizados continuamente en la Operación del Servicio.
 Tecnología. Todos los servicios requieren alguna forma de tecnología para su entrega.
La gestión de esta tecnología no es un aspecto independiente, sino una parte integral
de la gestión de los propios servicios.
 Personas. Independientemente de los servicios, los procesos y la tecnología que se

gestione, todos éstos estarán relacionados con personas.
La operación del servicio es la fase en la que los planes, diseños y optimizaciones se ejecutan y
miden. Desde el punto de vista de un cliente, el valor real se ve en la Operación del Servicio

7.5 COMUNICACIÓN
Es necesaria una buena comunicación con otros equipos y departamentos de TI, con los
usuarios y los clientes internos, y entre los propios equipos y departamentos de Operación del
Servicio. Normalmente los problemas se pueden prevenir o evitar con una comunicación
adecuada.
 Comunicación de rutina operacional

 Comunicación entre turnos
 Información de rendimiento
 Comunicación en proyectos
 Comunicación asociada a los cambios
 Comunicación asociada a las excepciones
 Comunicación asociada a las emergencias
 Formación sobre nuevos procesos personalizados y diseños del servicio
 Comunicación de la estrategia y del diseño a los equipos de Operación del
Servicio.
 Toda la comunicación debe tener un propósito objetivo o una acción resultante y no

deberá comunicarse a menos que haya una audiencia clara.
 La audiencia debe saber la necesidad de esa comunicación y qué hacer con ella.
 Las comunicaciones en curso deben validarse periódicamente para asegurarse de que

siguen siendo pertinentes a la audiencia.

7.6 IMPLICACIÓN DE OPERACIONES EN EL CICLO DE VIDA
Es extremadamente importante que el personal de Operación del Servicio se implique en el

Diseño del Servicio y Transición del Servicio y potencial mente también en Estrategia del
Servicio cuando sea apropiado.
Una clave para lograr el equilibrio en Operación del Servicio es contar con un conjunto eficaz
de procesos de Diseño del Servicio. Éstos proporcionarán a Gestión de Operaciones de TI:
• Una definición clara de objetivos del servicio de TI y criterios de rendimiento
• Un vínculo de las especificaciones del servicio de TI con el rendimiento de la Infraestructura

de TI
• Definición de los requisitos operativos de rendimiento
• Una correspondencia de servicios y tecnología
• La capacidad de modelar el efecto de los cambios en la tecnología y de los cambios en los

requisitos de negocio
• Modelos apropiados de costes (p. ej., basados en el cliente o en el servicio) para evaluar el
Retorno de la Inversión y las estrategias de reducción de costes.
Estrategia • Identificar y comunicar las capacidades actuales de operación, niveles de recursos y

las habilidades del personal de operación a aquellas estrategias de desarrollo de TI
Diseño • Definición clara de los objetivos de servicio de TI y criterios de Diseño
Transición • Las actividades de formación para aprender a operar un nuevo servicio y los posibles
cambios con el fin de poder operar el mismo
CSI • Asegurar que los datos operativos se pone a disposición el personal involucrado en
las actividades de CSI

Procesos Operación del Servicio

GESTIÓN DE EVENTOS

GESTIÓN DE EVENTOS
7.7 GESTIÓN DE EVENTOS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 VALOR
 DEFINICIONES
7.7.1 INTRODUCCIÓN
Un evento se puede definir como hecho detectable o discernible que tiene relevancia para la
gestión de la Infraestructura de TI o para la entrega del servicio de TI, y para la evaluación del
impacto que una desviación podría provocar en los servicios. Los eventos son habitualmente
notificaciones generadas por un servicio de TI, Elemento de Configuración (Cl) o herramienta
de monitorización.
La Operación eficaz del servicio dependerá del grado de conocimiento del estado de la
infraestructura y de la detección de cualquier desviación de una operación normal o esperada.
Unos buenos sistemas de control y monitorización facilitan esta situación, que se basa en dos
tipos de herramientas:
 herramientas de monitorización activa que realizan un muestreo de los Cl clave

para determinar su estado y disponibilidad. Cualquier excepción generará un
alerta que será necesario comunicar a la herramienta o equipo apropiado para
adoptar una acción.
 herramientas de monitorización pasiva que detectan y asocian alertas o
comunicaciones operativas generadas por los Cls.
 Gestión de eventos ofrece la capacidad de detectar eventos, darles sentido y

determinar la acción de control apropiada.
 Gestión de Eventos es la base para la Monitorización y Control Operativo.
 Gestión de Eventos proporciona el punto de entrada para la ejecución de muchos

procesos y actividades de Operación del Servicio.
 Proporciona una forma de comparación del rendimiento y comportamiento reales con

respecto a los estándares de diseño y SLAs.

GESTIÓN DE EVENTOS
7.7.2 PROPÓSITO
 El propósito de gestión de eventos es gestionar los eventos a lo largo de su ciclo de

vida. El ciclo de vida del evento es coordinado por el proceso de gestión de eventos e
incluye actividades para
 Detectar eventos.
 Darles sentido.
 Determinar la acción de control apropiada.
7.7.3 OBJETIVOS
 Detectar cambios de estado que son importantes para la gestión de un CI o de un

servicio de TI.
 Determinar y comunicar la acción de control apropiada para cada evento.
 Proporcionar el disparador para la ejecución de muchas actividades y procesos

automatizados de gestión de la operación del servicio.
 Proporcionar los medios para comparar el rendimiento operativo con los SLAs y
normas.
 Proporcionar una base para la presentación de informes y mejora del servicio.
7.7.4 ALCANCE
Gestión de Eventos puede aplicarse a cualquier aspecto de Gestión del Servicio que sea
necesario controlar y que pueda automatizarse.
 Elementos de Configuración. Se incluirán algunos Cl ya que éstos deben permanecer

en un determinado estado (Un switch en una red necesita estar operativo y las
herramientas de Gestión de Eventos confirman este hecho monitorizando respuestas a
'pings'). Y otros Cl porque su estado necesita cambiar frecuentemente. Gestión de
Eventos puede servir para automatizar esto y actualizar el CMS (La actualización de un
servidor de archivos).
 Condiciones ambientales. (Detección de incendios y humos)
 Monitorización de las licencias de software. Para garantizar el uso y ubicación

óptimos/legales de las licencias
 Seguridad. (Detección de intrusiones)
 Actividad normal. (Seguimiento del uso de una aplicación o rendimiento de un

servidor).

GESTIÓN DE EVENTOS
7.7.5 VALOR
 Gestión de Eventos provee mecanismos para la detección anticipada de incidencias.
 Gestión de Eventos posibilita la monitorización de algunos tipos de actividades

automatizadas mediante excepciones.
 Gestión de Eventos proporciona una base para realizar operaciones automatizadas,

por lo que se aumenta la eficiencia y permite asignan los recursos humanos más
costosos a trabajos más innovadores.
7.7.6 DEFINICIONES
Estas son algunas definiciones importantes de este proceso. Entre ellas tenemos los tres tipos
de Eventos que vamos a considerar.
Evento • Hecho detectable o discernible que tiene relevancia para la gestión de la

Infraestructura de TI o para la entrega del servicio de TI, y para la evaluación del
impacto que una desviación podría provocar en los servicios
Evento • Eventos que implican una operación regular : Finalización de una Tarea
Informativo
Evento de • Eventos que implican una operación inusual pero no excepcional: El uso de la
Advertencia memoria de un servidor se acerca al 5% de su nivel de rendimiento más alto
aceptable
Evento de • Eventos que implican una excepción: la CPU de un dispositivo está por encima de
Excepción la tasa de uso aceptable
Alerta • Una notificación de que se ha alcanzado un umbral, algo ha cambiado o se ha

producido un fallo. Las alertas son a menudo creadas y gestionados con
herramientas de gestión de sistemas y son administradas por el proceso de
gestión de eventos.

GESTIÓN DE EVENTOS
INFORMATIVO: Hace referencia a un evento que no requiere ninguna acción y que no

representa una excepción. Éstos se almacenan típicamente en los archivos de registro del
sistema o servicio y se mantienen allí durante un periodo predeterminado. Los eventos
informativos se utilizan típicamente para comprobar el estado de un dispositivo o servicio o
para confirmar el resultado satisfactorio de una actividad. A continuación se muestran algunos
ejemplos de eventos informativos:
 Un usuario inicia sesión en una aplicación
 Un trabajo en la cola de lotes se completa satisfactoriamente
 Un dispositivo ha pasado a estar online
 Una transacción se completó satisfactoriamente.
ADVERTENCIA: Una advertencia es un evento que se genera cuando un servicio o dispositivo

se está aproximando a un umbral. Las advertencias tienen como objetivo enviar una
notificación a la persona, proceso o herramienta adecuada, de tal forma que se pueda
comprobar la situación y se pueda adoptar una acción para evitar una excepción.
Ejemplos de advertencias:
 El grado de utilización de la memoria en un servidor se encuentra actualmente al 65%

y está aumentando. Si alcanzara el 75%, los tiempos de respuesta serían
inaceptablemente largos y se podría incumplir el OLA para ese departamento.
 La tasa de colisiones en una red se ha incrementado en un 15% durante la última hora.
EXCEPCIÓN: Una excepción significa que un servicio o dispositivo está actualmente operando
anormalmente (aunque esto se haya definido). Habitualmente esto significa que se ha
incumplido un OLA o SLA y esto está generando un imparto en el negocio. A continuación se
muestran ejemplos de excepciones:
 Un servidor se ha caído
 El tiempo de respuesta de una transacción estándar a través de la red se ha

ralentizado a más de 15 segundos
 Más de 150 usuarios se han conectado simultáneamente en la aplicación contable

Libro Mayor
 Un segmento de la red no está respondiendo a solicitudes rutinarias.

GESTIÓN DE INCIDENCIAS

7.8 GESTIÓN DE INCIDENCIAS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 ESCALAS DE TIEMPO
 MODELOS DE INCIDENCIAS
 INCIDENCIAS MAYORES
 ACTIVIDADES
7.8.1 INTRODUCCIÓN
En la terminología de ITIL®, una incidencia se define como una interrupción no planificada de

un Servicio de TI o reducción en la calidad de un servicio de TI. El fallo de un elemento de
configuración que todavía no ha impacto en el servicio también se considera una incidencia,
por ejemplo el fallo de un disco de una configuración en espejo ('mirror').
Gestión de Incidencias es el proceso de tratamiento de todas las incidencias; esto puede incluir
fallos, preguntas o cuestiones reportadas por los usuarios (normalmente a través de una
llamada telefónica al Centro de Servicio al Usuario), personal técnico, o detectadas
automáticamente y reportadas por las herramientas de monitorización de eventos.
7.8.2 PROPÓSITO
El propósito de gestión de incidentes es restaurar el servicio a su nivel operativo normal lo

antes posible y minimizar el impacto adverso en las operaciones del negocio.
“Nivel operativo normal del servicio"
 El nivel operativo normal se define como un estado operativo donde servicios y CIs
tienen un rendimiento dentro de sus niveles operativos y de servicio acordados.

7.8.3 OBJETIVOS
Estos son los Objetivos de Gestión de Incidencias:
 El objetivo principal del proceso de Gestión de Incidencias es restaurar la operación

normal del servicio lo antes posible
 Asegurar que se utilizan procedimientos y métodos estandarizados para la

presentación de informes y gestión de incidentes.
 Alinear las actividades y prioridades de gestión de incidentes con los del negocio.
 Aumentar la visibilidad y comunicación de incidentes al personal de soporte de TI y del

negocio.
 Mejorar la percepción de TI en el negocio y mantener la satisfacción del usuario

mediante la resolución y comunicación rápida de los incidentes cuando estos ocurran.
7.8.4 ALCANCE
La Gestión de Incidencias incluye cualquier evento que afecte o pueda afectar negativamente a
un servicio. Esto incluye eventos que los usuarios comunican directamente, ya sea a través del
Centro de Servicio al Usuario o, a través de una interfaz, desde la Gestión de Eventos hasta las
herramientas de Gestión de Incidencias.
Además, el personal técnico también puede informar y/o registrar incidencias (si, por ejemplo,
tuvieran noticia de algo negativo con respecto a un componente de hardware o de red,
podrían registrar o informar de una incidencia y dirigirla al Centro de Servicio al Usuario). Sin
embargo, esto no significa que todos los eventos sean incidencias. Muchas clases de eventos
en modo alguno están asociadas con interrupciones, ya que son indicadores de la operación
normal o sólo tienen por objetivo informar.
Aunque se informa tanto de las incidencias como de las peticiones de servicio al Centro de
Servicio al Usuario, esto no significa que sean lo mismo. Las peticiones de servicio no
representan una interrupción del servicio acordado, pero representan una forma de satisfacer
las necesidades del cliente y podrían abordarse como un objetivo acordado en un SLA. Las
peticiones de servicio se tramitan mediante el proceso Gestión de Peticiones.

7.8.5 ESCALAS DE TIEMPO
Las escalas de tiempo deben acordarse para todas las etapas por las que pasa una incidencia
(éstas diferirán dependiendo del nivel de prioridad de la incidencia). Se basan en los objetivos
de respuesta y resolución de las incidencias dentro de los SLA, y se capturan como objetivos
dentro de los OLA y de los Contratos de Soporte (UCs).
Todos los grupos de soporte deben ser totalmente conscientes de estas escalas de tiempo. Las
herramientas de Gestión del Servicio deben usarse para automatizar escalas de tiempo y
escalar la incidencia como requieran unas reglas predefinidas.
7.8.6 MODELOS DE INCIDENCIAS
Muchas incidencias no son nuevas. Éstas implican tratar con algo que ha pasado antes y que
podría volver a pasar nuevamente. Por esta razón, muchas organizaciones encontrarán útil
predefinir Modelos de Incidencias 'estándar' y aplicarlos a las incidencias adecuadas cuando se
produzcan.
Un Modelo de Incidencias es una forma de predefinir los pasos que deben tomarse para
manejar un proceso (en este caso un proceso para tratar con un tipo particular de incidencia)
de una forma acordada. Por lo tanto, se pueden utilizar herramientas de soporte para
gestionar el proceso requerido. Esto garantizará que las incidencias 'estándar' se manejen de
forma predefinida y dentro de las escalas de tiempo también definidas previamente.
Las incidencias que podrían requerir un manejo especializado se pueden tratar de esta forma
(por ejemplo, las incidencias asociadas con la seguridad pueden reencaminarse a Gestión de la
Seguridad de la Información, y las incidencias asociadas con la capacidad o con el rendimiento
podrían reencaminarse a Gestión de la Capacidad).
El Modelo de Incidencias debe incluir:
 Los pasos que deben tomarse para manejar la incidencia
 El orden cronológico de estos pasos con cualquier dependencia o co-procesamiento

definidos
 Responsabilidades; quién debe hacer qué
 Escalas de tiempo y umbrales para completar las acciones
 Procedimientos de escalado; con quién hay que ponerse en contacto y cuándo
 Cualquier actividad de conservación de evidencias (particularmente relevante para

incidencias asociadas con la segundad y con la capacidad).
Los modelos deben ser la entrada a las herramientas de soporte de gestión de incidencias que
están en uso, y las herramientas deben automatizar el tratamiento, gestión y escalado del
proceso.

7.8.7 INCIDENCIAS MAYORES
Deberá usarse un procedimiento independiente para incidencias Mayores, con escalas de

tiempo más breves y con más urgencia. Deberá acordarse y trazarse idealmente una definición
de lo que constituye una incidencia grave para todo el sistema de priorización de incidencias,
de tal forma que se traten a través del proceso de incidencias graves.
Nota: A veces las personas usan una terminología inexacta y/o confunden una incidencia
Mayor con un problema. En realidad, una incidencia siempre será una incidencia. Ésta podría
crecer en impacto o prioridad hasta convertirse en una incidencia grave, pero una incidencia
nunca se convierte en un problema. Un problema es la causa subyacente de una o más
incidencias y siempre se corresponde con una entidad independiente.
Algunas incidencias de baja prioridad también podrían tener que manejarse a través de este
procedimiento debido al impacto potencial en el negocio, y puede que algunas incidencias
Mayores no necesiten manejarse de esta forma si la causa y resoluciones fueran obvias y el
proceso de incidencias normales pudiera hacerlas frente fácilmente dentro de los tiempos
objetivo de resolución acordados, siempre que el impacto permaneciera bajo.
Si fuera necesario, el procedimiento de gestión de incidencias Mayores debe incluir el

establecimiento dinámico de un equipo independiente de gestión de incidencias graves bajo la
dirección directa del Gestor de Incidencias. Formulado para concentrarse en esta única
incidencia con el fin de garantizar que se suministran los recursos y el enfoque adecuados para
encontrar una rápida resolución. Si el Responsable del Centro de Servicio al Usuario estuviera
también cumpliendo el rol de Gestor de Incidencias (como en una organización pequeña),
entonces podría ser necesario designar a una persona independiente para que dirija al equipo
de investigación de incidencias graves para evitar conflictos de tiempo o de prioridades, pero
en última instancia deberá informar al Gestor de Incidencias.
Si al mismo tiempo fuera necesario investigar la causa de la incidencia, entonces el Gestor de

Problemas también se implicaría aunque el Gestor de Incidencias debe garantizar que se
mantengan independientes la restauración del servicio y la causa subyacente. En todo el
proceso, el Centro de Servicio al Usuario garantizaría que todas las actividades se registren y
que los usuarios se mantengan completamente informados del progreso.
7.8.8 ACTIVIDADES
La siguiente figura muestra las actividades incluidas en el proceso de Gestión de incidencias. A

continuación explicaremos brevemente cada una de esas actividades.


Identificación • El trabajo no puede comenzar a tratar con una incidencia hasta que ésta no
se detecte.
Registro • Todas las incidencias deben ser registradas y selladas con fecha y hora
Categorización • Parte del registro inicial deberá asignar una codificación adecuada de la
categorización de incidencias para que se registre el tipo exacto de la llamada
Priorización • La prioridad se puede determinar al tener en cuenta el impacto (El grado del
efecto sobre el negocio y la urgencia (Tiempo que se requiere para encontrar
una solución).
Diagnostico • Si fuera posible, el Analista del Centro de Servicio al Usuario resolverá la

Inicial incidencia mientras el usuario todavía se encuentre al teléfono y cerrará la
incidencia si la resolución fuera satisfactoria
Escalado • En cuanto esté claro que el Centro de Servicio al Usuario es incapaz de resolver la
Funcional incidencia por sí mismo (o cuando se hayan superado los tiempos objetivo para
la resolución del primer punto), la incidencia deberá escalarse inmediatamente
para aplicar un soporte posterior.
Escalado • Si las incidencias fueran de naturaleza grave, este hecho se deberá notificar a los
Jerárquico directores de TI adecuados, por lo menos para mantenerlos informados.
• El escalado jerárquico también se utiliza si los pasos de 'Investigación y
Diagnóstico' y de 'Resolución y Recuperación' consumieran demasiado tiempo o
se probara que son demasiado difíciles de aplicar.
Investigación • Probablemente requiera algún grado mayor de esfuerzo técnico para resolver la
y incidencia
Diagnostico • Puede requerirse un nuevo escalado
Resolución • Si se hubiera identificado una posible resolución, ésta deberá aplicarse y

y probarse.
Recuperación • Las acciones específicas a emprender y las personas que estarán implicadas en
las acciones de recuperación podrían variar dependiendo de la naturaleza del
fallo.
Cierre • Categorización del cierre

• Encuesta de satisfacción del usuario
• Documentación de la incidencia
• ¿Problema recurrente o continuo?
• Cierre formal

GESTIÓN DE PETICIONES DE SERVICIO

7.9 PETICIONES DE SERVICIO
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 MODELOS DE PETICIONES
7.9.1 INTRODUCCIÓN
El término Petición de Servicio se utiliza como una descripción general para muchos tipos
diferentes de demandas planteadas por los usuarios en el Departamento de TI.
Muchos de estos tipos son realmente pequeños cambios, de bajo riesgo, que se producen con
frecuencia, de bajo coste, etc. (Una solicitud de cambio de una contraseña, o una solicitud para
instalar una aplicación de software adicional en una estación de trabajo particular, una
solicitud para reubicar algunos componentes del equipo informático) o quizás sólo una
pregunta que solicita información
Básicamente Gestión de peticiones atiende solicitudes de Información, asesoramiento o

Cambios Estándar, generalmente a través del Centro de Servicio al Usuario (CSU) sin requerir
una Solicitud de Cambio (RFC).
7.9.2 PROPÓSITO
El propósito del proceso de gestión de peticiones es gestionar el ciclo de vida de todas las
peticiones de servicio de los usuarios.

7.9.3 OBJETIVOS
Estos son los objetivos de Gestión de Peticiones de Servicio:
 Proporciona un canal para que los usuarios soliciten y reciban servicios estándar para
los cuales existe un proceso de autorización y calificación predefinido.
 Proporcionar información a los usuarios y clientes sobre la disponibilidad de servicios y

el procedimiento para obtenerlos.
 Servir de fuente y punto de entrega de los componentes de servicios estándar (p. ej.
licencias y software)
 Ayudar con información general, quejas o comentarios.
 Mantener la satisfacción a través del manejo profesional de todas las peticiones de

servicio.
7.9.4 ALCANCE
El proceso necesario para satisfacer una solicitud variará en función de lo que se está pidiendo
exactamente. Este proceso normalmente se podrá dividir en un conjunto de actividades que
tienen que realizarse. Algunas organizaciones se sentirán cómodas permitiendo que las
Peticiones de Servicio sean manejadas a través de sus procesos de Gestión de Incidencias (y
herramientas). En este caso las Peticiones de Servicio se manejan como un tipo particular de
'incidencia' (usando un sistema de categorización de alto nivel para identificar esas
'incidencias' que de hecho son Peticiones de Servicio). Sin embargo, existe una diferencia
significativa. Una incidencia normalmente es un evento sin planificar mientras que una
Petición de Servicio normalmente es algo que puede y debería planificarse.
Por lo tanto, en una organización donde se tienen que manejar un gran número de Peticiones
de Servicio, y donde las acciones a tomar para satisfacer esas peticiones son muy variadas y
especializadas, podría ser adecuado manejar Peticiones de Servicio como un flujo de trabajo
completamente independiente, y registrarlas y manejarlas como un tipo de registro
independiente.
7.9.5 MODELOS DE PETICIONES
Algunas Peticiones de Servicio se producirán frecuentemente y será necesario gestionarlas de

forma consistente para cumplir los niveles de servicio acordados. Para hacer esto, muchas
organizaciones desearán crear Modelos de Peticiones predefinidos (que típicamente incluyen
alguna forma de aprobación previa por parte de Gestión de Cambios).

GESTIÓN DE PROBLEMAS

7.10 GESTIÓN DE PROBLEMAS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES REACTIVAS Y PROACTIVAS DE PROBELMAS
 SOLUCIÓN PROVISIONAL (WORKAROUND)
 DEFINICIONES
 ACTIVIDADES
ITIL® define un "problema" como la causa subyacente de una o más incidencias.
Gestión de problemas es el proceso responsable de gestionar el ciclo de vida de todos los

problemas. Este proceso busca minimizar el impacto de los incidentes y problemas en el
negocio, y evitar la repetición de incidentes. Para lograr esto, gestión de problemas busca
identificar la causa raíz de los incidentes, documentar y comunicar errores conocidos e iniciar
acciones para corregir la situación
7.10.2 PROPÓSITO
El propósito de gestión de problemas es gestionar el ciclo de vida de todos los problemas,

desde su identificación, pasando por la investigación y documentación, hasta la eventual
eliminación del problema.
7.10.3 OBJETIVOS
 Minimizar el impacto adverso en el negocio de incidentes y problemas causados por

errores subyacentes en la infraestructura de TI.
 Evitar que ocurran problemas e incidentes.
 Eliminar incidentes recurrentes.
 Minimizar el impacto de los incidentes que no se pueden prevenir.

7.10.4 ALCANCE
Gestión de Problemas incluye las actividades requeridas para diagnosticar la causa raíz de las
incidencias y para determinar la resolución de esos problemas. También es responsable de
garantizar que se implemente la resolución a través de los procedimientos adecuados de
control, especialmente Gestión de Cambios y Gestión de Versiones y Despliegues.
Gestión de Problemas también mantendrá información sobre problemas y sobre las soluciones
provisionales y resoluciones apropiadas para que una organización pueda reducir el número e
impacto de las incidencias. A este respecto, Gestión de Problemas dispone de una fuerte
interfaz con Gestión del Conocimiento, y herramientas como Bases de Datos de Errores
Conocidos que se usarán en ambos.
Aunque Gestión de Incidencias y de Problemas son procesos independientes, están

estrechamente asociados y normalmente utilizarán las mismas herramientas, pudiendo definir
sistemas similares de codificación de prioridad, impacto y categorización. Esto garantizará una
comunicación eficaz al tratar con problemas e incidencias asociados.

7.10.5 ACTIVIDADES REACTIVAS Y PROACTIVAS DE PROBELMAS
Gestión de Problemas se puede tratar de manera reactiva o de manera proactiva. El

tratamiento reactivo del problema se lleva a cabo con las actividades que veremos más
adelante y coinciden prácticamente con las actividades de Gestión de Incidencias. La forma
proactiva se suele tratar a través de la Mejora Continua.
Reactivas • Las actividades del proceso se disparan por un incidente que ha sucedido.
• Las actividades se basan en la fase de operaciones del ciclo de vida.
• Es un complemento a la gestión de incidentes al centrarse en las causas
subyacentes de los incidentes para prevenir su recurrencia e identificar soluciones.
Proactivas • Las actividades del proceso se disparan por actividades que buscan mejorar los
servicios. (análisis de tendencias para encontrar las causas más frecuentes de
incidentes históricos)
• Las actividades se basan en las fases de diseño y de mejora continua del servicio
del ciclo de vida.
• Es un complemento a las actividades de CSI puesto que identifica soluciones
temporales y medidas que mejoran la calidad del servicio.
7.10.6 SOLUCIÓN PROVISIONAL (WORKAROUND)
En algunos casos, podría ser posible encontrar una solución provisional para las incidencias
provocadas por un problema (Una alternativa que reduzca o elimine el Impacto de un
Incidente o Problema cuya resolución completa aún no está disponible), básicamente, una
forma temporal de superar las dificultades. Por ejemplo, se podría realizar una corrección
manual en un archivo de entrada para permitir que un programa complete su ejecución con
éxito y permitir completar correctamente un proceso de facturación, pero es importante que
el trabajo en buscar una solución permanente continúe siempre y cuando esté justificado. En
este ejemplo, lo primero que habría que hacer es encontrar y corregir la razón de que el
archivo se corrompa para evitar que este hecho se produzca nuevamente.
En casos donde se encuentre una solución provisional, es importante que el registro del
problema siga abierto, y los detalles de la solución temporal siempre se documenten dentro
del Registro de Problemas.

7.10.7 DEFINICIONES
Como en el resto de los procesos, vamos a ver algunas definiciones importantes.
Error Conocido • Problema del que se tiene causa o Raíz documentada y solución Provisional
(KE) • Los Errores Conocidos se crean y gestionan a través de su Ciclo de Vida
mediante la Gestión de Problemas.
• Los equipos de Desarrollo o los Suministradores también podrían identificar
Errores Conocidos.
Base de Datos • Base de datos que contiene todos los Registros de Errores Conocidos.
de Errores • Esta base de datos está creada por Gestión de Problemas y la usan Gestión de
Conocido Incidencias y de Problemas.
(KEDB) • La Base de Datos de Errores Conocidos (KEDB) forma parte del Sistema de
Gestión del Conocimiento del Sistema (SKMS).
• La KEDB debe usarse durante las fases de Diagnóstico de Problemas e
Incidencias para intentar acelerar el proceso de resolución.
Registro de • Registro que contiene los detalles de un Error Conocido

Error conocido • En cuanto se complete el diagnóstico, y particularmente en el caso en el que
se haya encontrado una solución temporal (incluso cuando ésta no
constituyera una solución permanente), debe plantearse un Registro de
Errores Conocidos e introducirse en una Base de Datos de Errores Conocidos.
• Cada Registro de Errores Conocidos documenta el Ciclo de Vida de un Error
Conocido, incluyendo el Estado, Causa Raíz, y Solución Provisional.
• En algunos casos, podría ser ventajoso plantear un Registro de Errores
Conocidos incluso anticipadamente en el proceso general (Tan pronto como
sea útil)
Modelo de • Pasos predefinidos para tratar determinados tipos de problemas

problemas • Los modelos de problemas son útiles para facilitar el diagnostico de
incidencias recurrentes, cuya solución temporal será el único remedio que
tengamos en el futuro ( Por ejemplo, el coste excesivo en encontrar una
solución definitiva)
7.10.8 ACTIVIDADES
La siguiente figura muestra las actividades incluidas dentro de proceso de Gestión de

Problemas. A continuación explicaremos las más importantes.


Identificación • Sospecha o detección por el Centro de Servicio al Usuario de una causa

desconocida de una o más incidencias.
• El análisis de una incidencia por un grupo de soporte técnico.
• Detección automática del fallo de una infraestructura o aplicación.
• Una notificación de un suministrador o contratista de que existe un problema
que se tiene que resolver.
• Análisis de incidencias como parte de Gestión Proactiva de Problemas
Registro • Independientemente del método de detección, deberán registrarse todos los

detalles relevantes del problema para que exista un registro histórico completo.
• Cada registro debe marcarse con su fecha y hora para permitir el escalado y
control adecuados.
Categorización • Los problemas deberán categorizarse de la misma forma que las incidencias (y
es aconsejable utilizar el mismo sistema de codificación) de tal forma que se
pueda trazar fácilmente en el futuro la naturaleza real del problema y se pueda
obtener información de gestión significativa
Priorización • La priorización de problemas tiene que tener en cuenta la severidad de los

problemas. La severidad, en este contexto, hace referencia al grado de seriedad
del problema desde la perspectiva de una infraestructura, por ejemplo:
 ¿Se puede recuperar el sistema, o es necesario sustituirlo?
 ¿Cuánto costará?
 ¿Cuántas personas, con qué habilidades, serán necesarias para solucionar
el problema?
 ¿Cuánto tiempo se tardará en solucionar el problema?
 ¿Qué alcance tiene el problema (p. ej., ¿cuántos Cl se ven afectados)?
Resolución • Idealmente, en cuanto se encuentre una solución, ésta se debería aplicar

para resolver el problema, aunque en realidad, podría ser necesario tomar
precauciones para garantizar que no se provoquen dificultades posteriores.
• Si se requiriera algún cambio en la funcionalidad, será necesario plantear y
aprobar una RFC antes de que se pueda aplicar la resolución.
Cierre • Cuando se haya completado algún cambio (y revisado satisfactoriamente),

y se haya aplicado la resolución, el Registro de Problemas deberá cerrarse
formalmente, así como cualquier Registro de Incidencias relacionado que
todavía estuviera abierto. En ese momento deberá realizarse una
comprobación para garantizar que el registro contiene una descripción
histórica completa de todos los eventos, y si no fuera así, el registro deberá
actualizarse.

Revisión • Después de cualquier problema grave (determinados por el sistema de prioridades

Problemas de la organización), mientras la memoria todavía esté reciente, deberá realizarse
Mayores una revisión para aprender cualquier lección para el futuro. Específicamente, la
revisión deberá examinar:
 Aquellas cosas que se hicieron correctamente
 Aquellas cosas que se hicieron incorrectamente
 Qué podría hacerse mejor en el futuro
 Cómo evitar la repetición de Problemas
 Si hubiera habido alguna responsabilidad de terceros y si fueran necesarias
acciones de seguimiento.

GESTIÓN DE EVENTOS

GESTIÓN DE EVENTOS
7.11 GESTIÓN DE ACCESOS
 INTRODUCCIÓN
 PROPÓSITO
 OBJETIVOS
 ALCANCE
 DEFINICIONES
Gestión de Accesos es el proceso de concesión del derecho de uso de un servicio a usuarios

autorizados mientras que se evita el acceso a otros usuarios no autorizados. También se ha
hecho referencia a este proceso como Gestión de Derechos o Gestión de Identidades en
diferentes organizaciones.
7.11.2 PROPÓSITO
Gestión de Accesos proporciona el derecho de los usuarios a poder usar un servicio o grupo de
servicios. Por lo tanto, es la ejecución de políticas y acciones definidas en Gestión de la
Disponibilidad y de la Seguridad
7.11.3 OBJETIVOS
 Gestionar acceso a servicios basados en las políticas definidas en gestión de seguridad

de la información.
 Responder a las peticiones de concesión, cambio o restricción de los derechos de

acceso a los servicios.
 Asegurar que los derechos provistos o cambiados se conceden de forma apropiada.
 Supervisar el acceso a los servicios y asegurar que los derechos de acceso no se utilizan
incorrectamente.

GESTIÓN DE EVENTOS
7.11.4 ALCANCE
Gestión de Accesos es efectivamente la ejecución de Gestión de la Seguridad de la Información

y de Gestión de la Disponibilidad, y eso permite a la organización gestionar la confidencialidad,
disponibilidad e integridad de los datos y de la propiedad intelectual de la organización.
El proceso de gestión de acceso cubre todos los servicios y aplicaciones donde se necesita
autorizarse el acceso y garantiza que los usuarios autorizados tengan el derecho a utilizar un
servicio, teniendo en cuenta que no garantiza que este acceso esté disponible durante todo el
tiempo acordado. Esto lo proporcionará la Gestión de la Disponibilidad.
7.11.5 DEFINICIONES
Estas son algunas definiciones importantes del proceso Gestión de Eventos.
Acceso • hace referencia al nivel y amplitud de la funcionalidad de un servicio o de

los datos que el usuario tiene derecho a utilizar
Derecho • (también denominados privilegios) hacen referencia a los ajustes reales

por medio de los cuales a un usuario se le proporciona acceso a un
servicio o grupo de servicios. Los derechos típicos, o niveles de acceso,
incluyen leer, escribir, ejecutar, cambiar, eliminar.
Identidad • hace referencia a la información sobre aquellas personas que se

distinguen como un individuo, verificando su estado dentro de la
organización
Servicios o • La mayoría de los usuarios no usan sólo un servicio, y los usuarios que
Grupos de realizan un conjunto similar de actividades usarán un conjunto similar de
Servicios servicios
Servicios de • hace referencia a un tipo específico de herramienta que se utiliza para

Directorio gestionar el acceso y los derechos.

FUNCIONES
Funciones Operación del Servicio

CENTRO DE SERVICIO AL USUARIO (CSU)

7.12 CENTRO DE SERVICIO AL USUARIO (CSU)
 INTRODUCCIÓN
 OBJETIVOS
 BENEFICIOS
 CSU LOCAL
 CSU CENTRALIZADO
 CSU VIRTUAL
 CSU SIGUIENDO AL SOL Y ESPECIALIZADO
Un Centro de Servicio al Usuario es una unidad funcional compuesta por un número dedicado
de personal responsable de tratar diversos eventos del servicio, a través de llamadas
telefónicas, interfaz web o eventos de infraestructura sobre los que se informa
automáticamente.
El Centro de Servicio al Usuario tiene una importancia vital en el Departamento de TI de una

organización y debería ser el punto único de contacto diario para los usuarios de TI; y tratará
todas las incidencias y peticiones de servicio, utilizando habitualmente herramientas de
software especializado para registrar y gestionar todos esos eventos.
El valor de un Centro de Servicio al Usuario eficaz no debería ser subestimado. A menudo, un

buen Centro de Servicio al Usuario puede compensar las deficiencias en otros puntos de la
organización de TI; pero un Centro de Servicio al Usuario deficiente (o la falta de un Centro de
Servicio al Usuario) puede ofrecer una mala impresión de una organización de TI eficaz.
Por lo tanto, es muy importante que se utilice personal con la preparación adecuada en el
Centro de Servicio al Usuario y que los Gestores de TI hagan todo lo posible para que el centro
sea un lugar atractivo en el que trabajar y de esa forma mejorar la retención del personal.
La naturaleza, tipo, tamaño y ubicación exacta de un Centro de Servicio al Usuario diferirán en

función del tipo de negocio, número de usuarios, geografía, complejidad de las llamadas,
ámbito de los servicios y muchos otros factores.
Es el único punto de contacto para los usuarios de TI (SPOC), en el día a día que Tramitará
todos los Incidentes y Peticiones de Servicio.

7.12.2 OBJETIVOS
 Registro de todos los detalles importantes de la incidencia/petición de servicio,

asignando códigos de categorización y priorización
 Provisión de investigación y diagnóstico de primera línea
 Resolución de las incidencias/peticiones de servicio que puedan solucionar
 Escalado de las incidencias/peticiones de servicio que no puedan resolver dentro de

los plazos de tiempo acordados
 Mantener a los usuarios informados del progreso
 Cierre de todas las incidencias resueltas, peticiones y otras llamadas
 Realización de las devoluciones de llamadas/encuestas de satisfacción del

cliente/usuario acordadas
 Comunicación con los usuarios, manteniéndoles informados sobre el progreso de las

incidencias, notificándoles los cambios inminentes o las interrupciones del servicio
acordado, etc.
 Actualización del CMS, si se acuerda, bajo la dirección y aprobación de Gestión de la

Configuración y Activos del Servicio.
7.12.3 BENEFICIOS
 Mejora del servicio, de la percepción y de la satisfacción del cliente
 Incremento de la accesibilidad a través de un punto único de contacto, comunicación e

información
 Mejor calidad y capacidad de respuesta más rápida a las peticiones del cliente o
usuario
 Mejora del trabajo en equipo y de la comunicación
 Mejora del enfoque y puesta en marcha de una metodología proactiva para la

provisión del servicio
 Un reducido impacto negativo sobre el negocio
 Mejora de la gestión y control de la infraestructura
 Mejora del uso de los recursos de Soporte de TI y mejora de la productividad del

personal de negocio
 Información de gestión más significativa para apoyar la toma de decisiones

7.12.4 CSU LOCAL
Cuando un centro de servicio se ubica dentro, o físicamente cerca, de la comunidad de

usuarios a la que sirve.
Esto favorece con frecuencia la comunicación y proporciona una presencia claramente visible
que puede gustar a algunos clientes, pero que a menudo puede ser ineficiente y cara debido a
que el personal se encuentra inmovilizado a la espera de tratar las incidencias cuando el
volumen y la tasa de llegada de llamadas no justifiquen su presencia.

7.12.5 CSU CENTRALIZADO
Es posible reducir el número de Centros de Servicio al Usuario fusionándolos en una única

ubicación (o en un número inferior de ubicaciones) concentrando al personal en una o más
estructuras de Centro de Servicio al Usuario Centralizado.
Esto puede ser más eficiente y rentable, permitiendo menos personal general para tratar un
volumen superior de llamadas, y también puede permitir mayores niveles de habilidades a
través de un elevado grado de familiarización mediante la ocurrencia frecuente de eventos.
Aún podría ser necesario mantener alguna forma de 'presencia local' para gestionar los
requisitos de soporte físico, aunque ese personal puede controlarse y desplegarse desde el
centro de servicio central.

7.12.6 CSU VIRTUAL
Utilizando tecnologías y herramientas de soporte empresarial, es posible dar la impresión de

un único y centralizado Centro de Servicio al Usuario cuando el personal puede estar ubicado
en cualquier número de sitios
Utilizando tecnologías y herramientas de soporte empresarial, es posible dar la impresión de

un único y centralizado Centro de Servicio al Usuario cuando el personal puede estar ubicado
en cualquier número de sitios.

7.12.7 CSU SIGUIENDO AL SOL Y ESPECIALIZADO
Siguiendo al • Algunas organizaciones globales o internacionales pueden decidir combinar dos o

Sol más Centros de Servicio al Usuario dispersos geográficamente para proporcionar
un servicio que siga al sol durante las 24 horas.
• Por ejemplo, un Centro de Servicio al Usuario en Asia-Pacífico puede responder a
las llamadas durante su horario de oficina estándar y al final de este periodo
puede transferir la responsabilidad para cualquier incidencia abierta a un centro
de servicio con sede en Europa.
Especializado • En algunos casos sí puede justificarse crear grupos especializados dentro de la

estructura del Centro de Servicio al Usuario donde los incidentes relativos a un
determinado servicio se pueden re direccionar directamente a expertos en el
tema.

GESTIÓN TÉCNICA

GESTIÓN TÉCNICA
7.13 GESTIÓN TÉCNICA
 INTRODUCCIÓN
 OBJETIVOS
 ACTIVIDADES
Gestión Técnica hace referencia a los grupos, departamentos o equipos que ofrecen la
experiencia técnica y la gestión general de la Infraestructura de TI.
 Es el custodio del conocimiento y experiencia técnica asociados con la gestión de la

Infraestructura de TI. En este rol, Gestión Técnica garantiza el conocimiento necesario
para que se identifiquen, desarrollen y definan el diseño, las pruebas, la gestión y
mejora de los servicios de TI.
 Proporciona los recursos para apoyar el Ciclo de Vida de ITSM. En este rol, Gestión
Técnica garantiza que los recursos se formen y se desplieguen eficazmente para
diseñar, construir, realizar la transición, operar y mejorar la tecnología
Con estos dos roles, Gestión Técnica podrá garantizar que la organización tenga acceso al tipo
correcto de nivel de recursos humanos para gestionar la tecnología y, por lo tanto, cumplir los
objetivos de negocio. La definición de los requisitos de estos roles comienza con Estrategia del
Servicio, se amplía en Diseño del Servicio, se valida en Transición del Servicio y se perfecciona
en Mejora Continua del Servicio,
Parte de este rol también consiste en garantizar un equilibrio entre el nivel de habilidad,
utilización y el coste de estos recursos. Por ejemplo, no sería eficaz contratar un recurso de
alto nivel en el extremo más alto de la escala de salarios y, a continuación, sólo usar esa
habilidad el 10% del tiempo. Una estrategia más adecuada de Gestión Técnica sería identificar
los tiempos que se necesitará una determinada habilidad técnica y entonces contratar a un
proveedor sólo para esas tareas.
7.13.2 OBJETIVOS
 Una topología técnica rentable, con alta capacidad de recuperación y bien diseñada
 El uso de las habilidades técnicas adecuadas para mantener la infraestructura técnica

en condiciones óptimas
 Uso rápido de habilidades técnicas para acelerar el diagnóstico y resolver cualquier

fallo técnico que se produzca.

GESTIÓN TÉCNICA
7.13.3 ACTIVIDADES
 Definición y gestión de Estándares y herramientas de Gestión de Eventos.
 Soporte de Segundo nivel y niveles posteriores.
 Diseño y realización de pruebas de funcionalidad, rendimiento y capacidad de gestión

de servicios de TI (actividades de transición, implementación y despliegue).
 Evaluar los riesgos, identificando dependencias criticas del Sistema y del servicio y
definiendo e implementando contramedidas.
 Dar soporte a Gestión de Problemas a la hora de validar y mantener la KEDB.
 Dar soporte a Gestión de Problemas a la hora de validar y mantener la KEDB.
 Proporcionar los recursos y participar en el modelado y previsión de la carga de

trabajo necesario para definir los requisitos de Gestión de la Disponibilidad y de la
Capacidad.
 Monitorizar y responder ante muchas categorías de eventos.
 Identificar el conocimiento y experiencia requeridos para gestionar y operar la

infraestructura de TI y para entregar servicios de Ti.
 Contratación de recursos con habilidades que no se puedan desarrollar internamente.
 Gestión de proveedores de CIs específicos.
 Participar en el diseño y desarrollo de nuevos servicios.

GESTIÓN DE OPERACIONES TI

7.14 GESTIÓN DE OPERACIONES TI
 INTRODUCCIÓN
 OBJETIVOS
 SUBFUNCIONES DE OPERACIONES TI
Gestión de operaciones hace referencia al departamento, grupo o equipo de personas

encargado de realizar las actividades diarias de la organización.
Gestión de Operaciones de TI puede definirse como la función responsable de la gestión y

mantenimiento continua de la Infraestructura de TI de una organización para asegurar la
entrega del nivel acordado de los servicios de TI para el negocio.
Gestión de Operaciones generalmente tiene las siguientes características:
 Existe alguna forma de asegurar que un dispositivo, sistema o proceso está

funcionando o trabajando realmente (a diferencia de estrategia o planificación)
 Aquí es donde los planes se convierten en acciones
 El enfoque se centra en actividades diarias o a corto plazo, aunque debe tenerse en

cuenta que estas actividades generalmente se realizarán y repetirán durante un
periodo relativamente amplio (a diferencia de las actividades de proyectos
extraordinarios)
 Estas actividades las realiza personal técnico especializado, que con frecuencia tiene
que recibir formación técnica para aprender cómo realizar cada actividad
 Existe un enfoque sobre la generación de acciones repetibles y consistentes que, si se

repitieran con suficiente frecuencia al nivel correcto de calidad, garantizarán el éxito
de la operación
 Aquí es donde se provee y se mide el valor real de la organización
 Existe una dependencia con respecto a la inversión en equipos o en recursos humanos,

o en ambos

7.14.2 OBJETIVOS
 Mantenimiento del status quo para lograr estabilidad de los procesos y actividades
diarias de la organización
 Escrutinio regular y mejoras para lograr la mejora del servicio con costes reducidos, a
la vez que se mantiene la estabilidad
 La rápida aplicación de capacidades operativas para diagnosticar y resolver fallos

operativos de TI que se produzcan.
Gestión de Operaciones de TI se mide en términos de la ejecución eficaz de sus actividades y

procedimientos especificados, además de por la ejecución de sus actividades de proceso. A
continuación se muestran los siguientes ejemplos:
 Ejecución exitosa de los trabajos planificados
 Número de excepciones con respecto a las actividades y trabajos planificados
 Número de datos o restauraciones requeridas del sistema
 Estadísticas de instalación de equipos, incluyendo el número de elementos instalados

por tipo, instalaciones exitosas, etc.
 Métricas de proceso. Gestión de Operaciones de TI ejecuta muchas actividades de

proceso de Gestión del Servicio. Su disponibilidad para hacerlo se medirá como parte
de las métricas de proceso si fuera pertinente. Algunos ejemplos incluyen las
mostradas en la diapositiva.

7.14.3 SUBFUNCIONES DE OPERACIONES TI
Control de • Gestión de Consolas, que hace referencia a la definición de la capacidad de

Operaciones observación y monitorización central y al uso de esas consolas para realizar
TI actividades de monitorización y control
• Planificación de Trabajos, o la gestión de scripts o jobs por lotes rutinarios
• Backup y Restauración en nombre de todos los equipos y departamentos de
Gestión Técnica y de Aplicaciones y con frecuencia en nombre de los usuarios
• Gestión de la impresión y de la salida para el cotejo y distribución de toda la
impresión centralizada o salida electrónica
• Rendimiento de las actividades de mantenimiento en nombre de los equipos y
departamentos de Gestión Técnica o de Aplicaciones.
Gestión de • Hace referencia a la gestión del entorno físico de TI, típicamente un Centro de
Instalaciones Proceso de Datos o salas de ordenadores y emplazamientos de recuperación con
todos los equipos de alimentación y refrigeración.
• Gestión de las Instalaciones también incluye la coordinación de proyectos de
consolidación a gran escala, p. ej., consolidación del Centro de Proceso de Datos o
proyectos de consolidación de servidores.

GESTIÓN DE APLICACIONES

7.15 GESTIÓN DE APLICACIONES
 INTRODUCCIÓN
 OBJETIVOS
 CICLO DE VIDA DE UNA APLICACIÓN
Gestión de Aplicaciones será responsable de gestionar Aplicaciones a lo largo de su ciclo de

vida. Se realiza a través de algún departamento, grupo o equipo implicado en la gestión y
soporte de aplicaciones operativas.
Esta función también desempeña un rol importante en el diseño, prueba y mejora de

aplicaciones que forman parte de los servicios de TI. Como tal, podría estar implicada en
proyectos de desarrollo, pero normalmente no es lo mismo que los equipos de Desarrollo de
Aplicaciones.
7.15.2 OBJETIVOS
Los objetivos de Gestión de Aplicaciones consisten en dar soporte a los procesos de negocio de
la organización ayudando a identificar requisitos funcionales y de capacidad de gestión para el
software de aplicación, y a continuación ayudar en el diseño y despliegue de esas aplicaciones
y en el soporte y mejora continua de las mismas.
Todos estos objetivos se consiguen a través de:
 Aplicaciones que estén adecuadamente diseñadas y sean fiables y rentables
 Garantizar que la funcionalidad requerida esté disponible para lograr el resultado de

negocio requerido
 Organización de las capacidades técnicas adecuadas para mantener las aplicaciones en

condiciones óptimas
 Uso rápido de habilidades técnicas para acelerar el diagnóstico y resolver cualquier

fallo técnico que se produzca.

7.15.3 CICLO DE VIDA DE UNA APLICACIÓN
Se han utilizado muchos nombres para hacer referencia al ciclo de vida para desarrollar y
gestionar las aplicaciones, incluyendo Ciclo de Vida del Software (SLC), y Ciclo de Vida de
Desarrollo del Software (SDLC). Los equipos de Desarrollo de Aplicaciones y sus Gestores de
Proyectos los utilizan generalmente para definir su implicación en el diseño, construcción,
prueba, despliegue y soporte de las aplicaciones. Ejemplos de estos métodos son Método de
Análisis y Diseño de Sistemas Estructurados (SSADM), Método de Desarrollo de Sistemas
Dinámicos (DSDM), Desarrollo Rápido de Aplicaciones (RAD), etc.
ITIL® está principalmente interesado en la gestión global de aplicaciones como parte de

Servicios de TI, independientemente de que se hayan desarrollado internamente o hayan sido
adquiridas a un tercero. Por esta razón, se ha utilizado el término Ciclo de Vida de Gestión de
Aplicaciones debido a que implica una misión más integral.
Esto no debería sustituir el SDLC, que todavía es un método válido que utilizan los
desarrolladores, especialmente en empresas de software. Sin embargo, esto no significa que
debiera haber un mayor alineamiento entre la visión del desarrollo de las aplicaciones y la
gestión 'activa' de esas aplicaciones.
La siguiente figura muestra las fases del Ciclo de vida de una Aplicación.

Requisitos • Esta es la fase en la que se recopilarán los requisitos para una nueva aplicación
basándose en las necesidades de negocio de la organización.
Diseñar • Esta es la fase en la que los requisitos se traducen en especificaciones. Diseñar

incluye el diseño de la propia aplicación y el diseño del entorno, o el modelo
operativo sobre el que se tiene que ejecutar la aplicación.
Construir • En esta fase, tanto la aplicación como el modelo operativo se ponen a disposición
para el despliegue.
Desplegar • En esta fase se despliegan tanto el modelo operativo como la aplicación.
Operar • En esta fase la organización de servicios de TI opera la aplicación como parte de la

entrega de un servicio requerido por el negocio.
Optimizar • En la fase Optimizar, los resultados de las medidas del rendimiento de Nivel de
Servicio se miden, analizan y se ponen en práctica.

7.15.4 DESARROLLO DE APLICACIONES Y GESTIÓN DE APLICACIONES
El siguiente cuadro muestra la diferencia entre la gestión de aplicaciones y el desarrollo.
Desarrollo de aplicaciones Gestión de aplicaciones

Naturaleza de • Conjunto de actividades puntuales para • Conjunto de actividades continuas
actividades el diseño y construcción de soluciones para supervisar y gestionar las
de aplicaciones. aplicaciones a lo largo de su ciclo de
vida completo.
Alcance • Aplicaciones desarrolladas • Aplicaciones adquiridas de terceros o
internamente. desarrolladas internamente.
Se centra en: • La utilidad. (Lo que hace la aplicación) • La utilidad y garantía.
Cuál es la funcionalidad así como la
forma en que se entrega.
Modo de • La mayor parte del trabajo de desarrollo • La mayor parte del trabajo se realiza
Gestión se realiza en proyectos según las como parte de procesos repetibles y
especificaciones, a tiempo y dentro del continuos.
presupuesto.
Medición • Al personal normalmente se le • El personal normalmente es
recompensa por su creatividad y por recompensado por su consistencia y
completar un proyecto capacidad para prevenir situaciones
inesperadas o funcionalidad no
autorizada
Coste • Directo • Indirecto
Ciclos de vida • El personal de desarrollo se centra en • El personal involucrado en la gestión

los ciclos de desarrollo de software, continua normalmente controla sólo
una o dos etapas de estos ciclos de
vida –operación y mejora.

UNIDAD 8 – MEJORA CONTINUA DEL SERVICIO (CSI)
Fundamentos
8 – MEJORA CONTINUA DEL SERVICIO (CSI)

8 MEJORA CONTINUA DEL SERVICIO
 INTRODUCCIÓN
 PROPÓSITO DE CSI
 OBJETIVOS DE CSI
 ALCANCE DE CSI
 VALOR
 LÍNEA BASE
 CICLO DE DEMING
 MODELO DE MEJORA CONTINUA
 PROPIEDAD DE CSI
 REGISTRO DE CSI
 METRICAS
 FACTORES CRITICOS DE ÉXITO (CSF)
 PROCESO 7 PASOS DE MEJORA
 PROPOSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES

8.1 INTRODUCCIÓN
Esta fase toma la salida de las fases y procesos anteriores y se ocupa de las mejoras
incrementales en la calidad de los servicios. Generalmente las iniciativas de CSI se vinculan a la
fase de diseño donde se desarrollarán cambios o nuevas funcionalidades, para luego progresar
a través de las etapas de transición y operación.
La mejora continua no es solo una actividad sino una filosofía que aplican gran número de
organizaciones. Una cultura de mejora es fundamental para aumentar la calidad de los
servicios entregados.
Estandarizar y medir son las bases fundamentales para una Mejora gradual de los servicios

8.2 PROPÓSITO DE CSI
El propósito de la fase de mejora continua del servicio (de ahora en adelante, CSI) del ciclo de
vida es alinear los servicios de TI con las necesidades cambiantes del negocio mediante la
identificación e implementación de formas de mejorar los servicios, procesos y rentabilidad de
los servicios de TI que daba soporte a los procesos del negocio.
No se puede gestionar lo que no se puede controlar.

No se puede controlar lo que no se puede medir.
No se puede medir lo que no se puede definir.

8.3 OBJETIVOS DE CSI
 Revisar, analizar, priorizar y recomendar oportunidades de mejora en cada fase del

ciclo de vida.
 Revisar y analizar los logros del nivel del servicio.
 Identificar e implementar actividades para mejorar la calidad del servicio.
 Mejorar la eficiencia y eficacia de los procesos internos.
 Mejorar la rentabilidad de la entrega de los servicios de TI.
 Asegurar que se utilizan métodos de gestión de calidad para dar soporte a las
actividades de CSI.
 Asegurar que los procesos tienen medidas y objetivos claramente definidos.

8.4 ALCANCE DE CSI
 La salud global de ITSM como una disciplina
 La continua alineación del porfolio de servicios de TI con las necesidades de negocio

actuales y futuras
 La madurez de los procesos de TI adecuados para cada servicio en un modelo continuo

de ciclo de vida del servicio.
Para implementar CSI satisfactoriamente, es importante entender las diferentes actividades

que pueden competer a CSI. Las siguientes actividades conforman la base de un plan de
mejora continua de procesos:
 Revisión de la información de gestión y su evolución para garantizar que los servicios

están cumpliendo los niveles de servicio acordados
 Revisión de la información de gestión y su evolución para garantizar que el resultado

de los procesos de ITSM asociados obtienen los resultados deseados
 Realización periódica de evaluaciones de madurez con respecto a las actividades del

proceso y roles asociados con las actividades del proceso, para identificar tanto áreas
de mejora como áreas de riesgo.
 Realización periódica de auditorías internas para verificar la conformidad con los

procesos y la aptitud de los empleados
 Revisión de la relevancia de los entregables existentes
 Presentación de recomendaciones ad-hoc para su aprobación
 Realización de encuestas periódicas de satisfacción del cliente
 Realización de revisiones internas y externas del servicio para identificar las

oportunidades de CSI.

8.5 VALOR
 Guía a una mejora justificada, gradual y continua en la calidad del servicio
 Asegura que los servicios siguen estando continuamente alineados con los requisitos
de negocio
 Da como resultado mejoras graduales rentables a través de una reducción de los

costes
 Aporta la capacidad de efectuar más trabajo al mismo coste
 Usa la monitorización y la emisión de informes para identificar oportunidades de

mejora en todas las fases del ciclo de vida y en todos los procesos
 Identifica oportunidades de mejora en: Estructuras Organizativas, Recursos, Asociados,

Tecnología, Formación y aptitudes del personal y Comunicaciones.

8.6 LÍNEA BASE
Un punto de inicio importante para poner de relieve la mejora es establecer líneas Base que
sirvan de indicadores o puntos de partida para realizar una comparación posterior. Las líneas
Base también sirven para establecer un punto de partida de los datos, para determinar si un
servicio o proceso tiene que ser mejorado.
 Es importante que las líneas Base sean documentadas, reconocidas y aceptadas en

toda la organización.
 Las líneas base deben establecerse en cada nivel: metas y objetivos estratégicos,
madurez del proceso táctico, métricas operativas y KPI.
 Si no se establece inicialmente una línea de referencia, los primeros esfuerzos de

medida se convertirán en la línea de referencia.
8.7 CICLO DE DEMING
En CSI, el Ciclo de Deming es crítico en dos puntos: implementación de CSI, y aplicación de CSI
a los servicios y a los procesos de gestión del servicio. En la implementación, se usan las cuatro
etapas del Ciclo de Deming. Con la mejora continua, CSI se inspira en las etapas verificar y
actuar para monitorizar, medir, revisar e implementar iniciativas.
El ciclo se apoya en una gestión basada en un método orientado a procesos, donde se aplican
los procesos definidos, se miden las actividades para comprobar su conformidad con los
valores esperados y se auditan las salidas para validar y mejorar el proceso.
El CICLO DE DEMING es una parte fundamental de muchos estándares de calidad, incluyendo

la ISO /IEC 20000.
 Planificar - Establece los objetivos de mejora, incluyendo el análisis de gaps, la

definición de los pasos de acción para cerrar el gap y el establecimiento e
implementación de medidas para asegurar que el gap ha sido cerrado y se han
obtenido los beneficios.
 Hacer - Desarrollo e implementación de un proyecto para cerrar el gap.

Implementación o mejora de procesos y establecimiento de la operación eficaz del
proceso.
 Verificar - Comparación del entorno implementado con las medidas de éxito

establecidas en la fase Planificar. La comparación determina si continúa existiendo un
gap entre los objetivos de mejora del proceso y el estado del proceso operativo. Los
gaps no requieren ser cerrados necesariamente. Un gap puede ser considerado como
tolerable si el rendimiento real se encuentra dentro de los límites de rendimiento
permisibles.

 Actuar - El proceso de decisión determina si se requiere algún trabajo adicional para

cerrar los gaps restantes y para la asignación de recursos necesarios para dar apoyo a
otro círculo de mejora. Las decisiones de proyecto en esta etapa representan la
entrada en el siguiente círculo del ciclo de vida, cerrándose el bucle en forma de
entrada en Planificar.

8.8 MODELO DE MEJORA CONTINUA
La siguiente figura define el Modelo de Mejora,

¿Cuál es la • El proveedor de servicios de TI debe entender cuáles son los objetivos

visión? definitivos y de largo plazo. La visión debe alinear las estrategias de TI y del
negocio.
¿Dónde • El negocio debe empezar por hacerse esta pregunta a medida que establece
estamos ahora? una línea base de datos para los servicios que actualmente provee. Analizar su
posición actual en términos de negocio, organización, personas, procesos y
tecnología para establecer la línea base.
¿Dónde • Entender las prioridades y establecer objetivos intermedios y unos plazos para
queremos la mejora que sean gestionables. Esto a menudo se expresa en forma de
estar? requerimientos del negocio.
¿Cómo • ¿Se requiere de unas mejoras definidas en el corto, mediano y largo plazo?
llegamos? Detallar el plan de CSI para la implementación o mejora de los procesos de
ITSM.
¿Hemos • Esto se documenta mediante la monitorización, presentación de informes y

llegado? revisión de los logros de nivel del servicio reales contrastados con las metas
objetivas identificadas por los requerimientos del negocio.
• Verificar que se aplican las medidas y métricas, que se alcanzan los hitos, que
la conformidad de los procesos es alta y que se cumplen los objetivos del
negocio.
¿Cómo
• Asegurar que se mantiene el impulso para la mejora de la calidad a través de la
mantenemos el
internalización de los cambios dentro de la organización.
impulso?

8.9 PROPIEDAD DE CSI
El principio de propiedad es fundamental en cualquier estrategia de mejora; tener una persona

responsable de asegurar que las mejores prácticas se adoptan y apoyan es una de las claves
para una implementación exitosa.
El gestor de CSI es responsable y partícipe de CSI, sin embargo los propietarios de servicio son
responsables de la mejora de los servicios específicos.
 Es el principal defensor y dueño de todos los problemas de CSI.
 Es responsable del éxito de CSI en la organización.
 Es responsable de que las prácticas de CSI están integradas en la organización.
 Es responsable de asegurar que los recursos necesarios están disponibles para dar
soporte y permitir la realización de CSI.
8.10 REGISTRO DE CSI
 Una base de datos o un documento estructurado utilizado para registrar y gestionar

las oportunidades de mejora
 Cada iniciativa debe catalogarse como una mejora pequeña, mediana o grande
 Cada iniciativa debe categorizarse como iniciativas alcanzadas rápidamente, a medio o

largo plazo
 Cada iniciativa debe mostrar los beneficios logrados por su implementación.
 El registro CSI debe mantenerse y ser considerado como parte de la SKMS.
 La producción y el mantenimiento del registro de CSI es la responsabilidad del Gestor

de CSI.

8.11 METRICAS
Es importante recordar que existen tres tipos de métricas que una organización necesitará
recopilar para dar apoyo a las actividades de CSI, así como a otras actividades de proceso. Los
tipos de métricas son:
Métricas de • Métricas se vinculan con más frecuencia con las métricas basadas en
tecnología componente o aplicación, como el rendimiento, la disponibilidad, etc.
Métricas de • Métricas se capturan en la forma de CSF, KPI y métricas de actividad para los
proceso procesos de gestión del servicio.
• Estas métricas pueden ayudar a determinar la salud general de un proceso.
Cuatro preguntas clave que los KPI pueden ayudar a responder guardan
relación con la calidad, el rendimiento, el valor y la conformidad de
seguimiento del proceso.
• CSI utilizaría estas métricas como entrada en la identificación de
oportunidades de mejora para cada proceso.
Métricas de • Métricas del servicio extremo a extremo. Las métricas de componente se usan
servicio en el cálculo de las métricas de servicio.
8.12 FACTORES CRITICOS DE ÉXITO (CSF)
Algo que debe existir si un Proceso, Proyecto, Plan, o Servicio de TI desea ser exitoso.
Los KPI se utilizan para medir el alcance de cada CSF. Por ejemplo: un CSF de "proteger
servicios de TI cuando se hacen Cambios" podría ser medible por KPI tales como "porcentaje
de reducción de Cambios no exitosos", o "porcentaje de reducción de Cambios que causen
Incidencias", etc.
En la siguiente tabla vemos un ejemplo de factor Crítico de Éxito y como a partir de defirlo
llegamos a obtener las medidas.

CSF • Reducción de los costes de TI
KPI • Reducción del 10 por ciento en los costes de gestión de incidencias de

impresoras.
Métricas • Coste original de la gestión de las incidencias de una impresora

• Coste final de la gestión de las incidencias de una impresora
• Coste del esfuerzo de mejora.
Medidas • Tiempo invertido en la incidencia por el personal de primer nivel y su salario

medio
• Tiempo invertido en la incidencia por el personal de segundo nivel y su salario
medio
• Tiempo invertido en las actividades de Gestión de Problemas por el personal de
segundo nivel y su sueldo medio
• Tiempo invertido en la formación del personal de primer nivel sobre la solución
provisional

PROCESO 7 PASOS DE LA MEJORA
Proceso Mejora Continua del Servicio

8.13 PROCESO 7 PASOS DE MEJORA
 PROPOSITO
 OBJETIVOS
 ALCANCE
 ACTIVIDADES
8.13.1 PROPOSITO
El propósito del proceso de los siete pasos de mejora es definir y gestionar las medidas
necesarias para identificar, definir, recopilar, procesar, analizar, presentar e implementar
mejoras.
8.13.2 OBJETIVOS
 El proceso de Mejora en Siete Pasos incluye el análisis del rendimiento, las

capacidades de los servicios y los procesos en todo el ciclo de vida, así como los
asociados y la tecnología.
 Incluye la alineación continua de la Cartera de Servicios de TI con el negocio actual y

las futuras necesidades, así como la madurez de los procesos que hacen posible cada
servicio.
 También incluye hacer el mejor uso de la tecnología que la organización tiene y busca
explotar las nuevas en cuanto estén disponibles cuando hay un caso de negocio para
hacerlo.
8.13.3 ALCANCE
 El proceso de Mejora en Siete Pasos incluye el análisis del rendimiento, las

capacidades de los servicios y los procesos en todo el ciclo de vida, así como los
asociados y la tecnología.
 Incluye la alineación continua de la Cartera de Servicios de TI con el negocio actual y

las futuras necesidades, así como la madurez de los procesos que hacen posible cada
servicio.
 También incluye hacer el mejor uso de la tecnología que la organización tiene y busca
explotar las nuevas en cuanto estén disponibles cuando hay un caso de negocio para
hacerlo.

8.13.4 ACTIVIDADES
La siguiente figura muestra las actividades del Proceso de Mejora en 7 pasos asi como su
relación con el Modelo DIKW y el Ciclo PDCA. A continuación definiremos cada uno de los
pasos que forman el proceso.

Identificar • Antes se puede iniciar cualquier otra actividad es necesario identificar la visión en
la conjunto.
Estrategia • ¿Qué estamos tratando de lograr para el negocio?
de mejora • Las preguntas que debemos hacernos son: ¿Qué iniciativas tiene el negocio para
que le afecte negativamente la prestación de servicios? o, de forma más positiva:
¿Qué mejoras en TI pueden permitir alcanzar la visión y los objetivos del negocio?
Las respuestas a estas preguntas se irán contestando a medida que avancemos en
el proceso.
• Dicho de otra manera que deseamos medir
Definir que • Este paso está directamente relacionado con los objetivos estratégicos, tácticos y
se va a operativos que se han definido para la medición de los servicios y procesos de
medir gestión de servicios, así como la tecnología existente y la capacidad para apoyar
las actividades de medición y CSI.
• En este paso es necesario definir lo que se debe medir, debemos definir lo que en
realidad se puede medir y llevar a cabo un análisis de las deficiencias para luego
finalizar el plan de medición real.
Recopilar • La recopilación de datos requiere poder monitorizar.

datos • La monitorización puede ser ejecutada utilizando la tecnología como aplicaciones,
sistemas y las herramientas de supervisión de componentes que se utilizan en el
proceso de gestión de eventos, o incluso ser un proceso manual para ciertas
tareas.
• Es fundamental mantener la precisión y la integridad de los datos.
Procesar • Este paso es convertir los datos en el formato requerido y para el público
datos requerido
Analizar la • los datos se transforman en información a medida que son analizados para
información identificar los gaps del servicio, las tendencias y el impacto sobre el negocio.
y los datos • Este paso de análisis frecuentemente se pasa por alto u olvida debido a las prisas
a la hora de presentar los datos a la dirección.
Presentación • El sexto paso consiste en representar nuestro conocimiento en informes,

y uso de la indicando los planes de acción, críticas, evaluaciones y oportunidades, y
información presentarlo al público objetivo de una manera clara, entendible y oportuna.
• Considere el público objetivo. La recolección de datos se produce en el nivel
operativo de una organización. Adecuar el formato de estos datos para que
todos los niveles pueden apreciar y conocer mejor sus necesidades y
expectativas es fundamental.

Implementar • Esta etapa puede incluir gran número de actividades:

las mejoras  Aprobación de las actividades de mejora
 Establecimiento de prioridades
 Presentación de un caso de negocio
 Integración con la gestión del cambio
 Integración con otras etapas del ciclo de vida
 Orientación sobre cómo gestionar un proyecto de mejora en curso con
éxito
 Comprobación de si la mejora realmente logró su objetivo.


Manual+Completo+Alumno Fundamentos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual+Completo+Alumno Fundamentos

Cargado por

Copyright:

Formatos disponibles

®

GUIA PARA EL ALUMNO

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

1.1 PRESENTACIÓN DE LOS ALUMNOS .............................................................................. 12

2 MEJORES PRÁCTICAS DE ITIL® ......................................................................................... 16

2.1 OBJETIVOS DE APRENDIZAJE ....................................................................................... 17

2 GESTIÓN DEL SERVICIO COMO PRÁCTICA ....................................................................... 22

2.1 MEJORES PRÁCTICAS EN EL DOMINIO PÚBLICO ........................................................... 23

3 CICLO DE VIDA DEL SERVICIO ......................................................................................... 50

3.1 INTEGRACIÓN A TRAVÉS DEL CICLO DE VIDA ................................................................ 52

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

4 ESTRATEGIA DEL SERVICIO ............................................................................................. 60

4.1 INTRODUCCIÓN DE LA ESTRATEGIA ............................................................................. 61

5 DISEÑO DEL SERVICIO .................................................................................................. 109

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

5.1 INTRODUCCIÓN Y PROPÓSITO ................................................................................... 110

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

5.14.5 CONCEPTOS BÁSICOS .................................................................................................. 155

6 TRANSICIÓN DEL SERVICIO ........................................................................................... 191

6.1 INTRODUCCIÓN A LA TRANSICIÓN ............................................................................. 192

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

6.8.4 ALCANCE........................................................................................................................ 203

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

6.13.5 SISTEMA DE GESTIÓN DEL CONOCIMIENTO (SKMS).................................................... 243

7 OPERACIÓN DEL SERVICIO ........................................................................................... 246

7.1 INTRODUCCIÓN ........................................................................................................ 247

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

7.11.3 OBJETIVOS ................................................................................................................... 276

8 MEJORA CONTINUA DEL SERVICIO ............................................................................... 299

8.1 INTRODUCCIÓN ........................................................................................................ 300

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

Esta guía de aprendizaje está Orientada a la certificación de fundamentos de ITIL®, aunque

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

1.1 PRESENTACIÓN DE LOS ALUMNOS

“Esto es un curso y nuestro objetivo es aprender los fundamentos”.

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

1.2 OBJETIVOS DEL CURSO

El objetivo del certificado de Fundamentos de ITIL® en Gestión de los Servicios de TI es

Como hemos mencionado anteriormente la implementación de ITIL® nunca seguirá un orden

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

1.3 CARACTERÍSTICAS DE ITIL®

 Mejores prácticas para la gestión de servicios de TI.

En 2007, se publica seguramente la actualización más importante de ITIL® en respuesta a los

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

1.4 MEJORES PRÁCTICAS DE GESTIÓN (BMP)

El siguiente cuadro representa un ejemplo de Prácticas dentro del ámbito de la Gestión:

 MoR® (Risk Management of Risk) ofrece un marco para la administración de riesgos,

 El MoV® (Management of Value) ofrece orientación sobre maximizar el valor y hacer

 P3O®. (Portfolio,Programme and Project Offices) ofrece orientación para realizar

 MoP® (Management of Portfolios) ofrece orientación sobre manejar o cambiar

 MSP® (Managing Successful Programmes) consiste en un grupo de procesos y

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

2 MEJORES PRÁCTICAS DE ITIL®

A la hora de entender el concepto de ITIL® y asimilar lo que puede aportar su implementación

Una consideración importante es tener en cuenta que sin la implicación de la dirección de la

Based on AXELOS ITIL® material. Reproduced under licence from AXELOS

2.1 OBJETIVOS DE APRENDIZAJE

 Gestión del Servicio. Comprender la definición y significado de este concepto

 Principios y Modelos Clave. ITIL® se fundamenta en una

 Conceptos Genéricos. Son muchos pero fáciles de asimilar.

 Procesos Seleccionados. Después del Ciclo de Vida, será

 Roles Seleccionados. Es fundamental la definición de Roles.